Back

Unit_7_Cloud_Security

Loading views...
← Previous

Unit 7: Cloud Security

7.1 Introduction to Cloud Security

The Internet was designed primarily to be resilient, not secure. Any distributed application has a much greater attack surface than an application running on a private Local Area Network.

Cloud computing inherits all vulnerabilities of Internet applications plus unique new vulnerabilities that arise from:

  • Pooled resources — shared hardware between untrusted tenants
  • Virtualized environments — hypervisor and VM attack surfaces
  • Outsourced operations — you are not in physical control of your data
Security is not just about perimeter defense anymore. Cloud computing blurs the traditional network perimeter (firewall/DMZ). The perimeter is now dynamic and ill-defined.

7.1.1 Gartner Group's Seven Cloud Security Risks

The Gartner Group (Heiser & Nicolett) identified these uniquely troublesome areas:

Risk Area Why It's Unique in the Cloud
Auditing Logs may be spread across multisite, multitenant infrastructure. Forensic investigation is difficult.
Data Integrity Data stored across many nodes — validating that no corruption or tampering occurred is complex.
e-Discovery Legal processes require producing specific data records. In the cloud, data location is not transparent.
Privacy Multi-tenancy means co-mingling data from different organizations on the same physical hardware.
Recovery Disaster recovery must work across multiple cloud regions and may not meet strict RTO/RPO requirements.
Regulatory Compliance Laws (HIPAA, GDPR, PCI-DSS) govern where data can be stored/processed. Cloud providers may span many jurisdictions.

7.2 Security Risk Assessment Framework

Before migrating any workload to the cloud, a structured security assessment is mandatory:

  STEP 1: Identify Resources
  ┌────────────────────────────────────────────────────┐
  │  What data, services, or applications are moving   │
  │  to the cloud?                                     │
  └────────────────────────────────────────────────────┘
                         │
  STEP 2: Classify Sensitivity
  ┌────────────────────────────────────────────────────┐
  │  What is the risk if this data is lost, stolen,   │
  │  or made unavailable?                              │
  │  (Loss of privacy / Unauthorized access / Outage)  │
  └────────────────────────────────────────────────────┘
                         │
  STEP 3: Evaluate Cloud Type Risk
  ┌────────────────────────────────────────────────────┐
  │  Public Cloud: Highest risk                         │
  │  Private (external): Medium risk                   │
  │  Private (internal): Lowest risk                   │
  │  Hybrid: Mixed risk depending on data flow         │
  └────────────────────────────────────────────────────┘
                         │
  STEP 4: Map to Service Model (IaaS / PaaS / SaaS)
  ┌────────────────────────────────────────────────────┐
  │  Determines which party (CSP vs. customer)         │
  │  is responsible for each security layer            │
  └────────────────────────────────────────────────────┘
                         │
  STEP 5: Analyze the Specific Provider
  ┌────────────────────────────────────────────────────┐
  │  How is data transferred in/out?                   │
  │  Where is data stored physically?                  │
  │  How does this provider do data segregation?       │
  └────────────────────────────────────────────────────┘

7.3 The Security Boundary

The security boundary is the line that separates what the Cloud Service Provider (CSP) is responsible for securing from what the customer is responsible for.

  CLOUD REFERENCE MODEL — SECURITY BOUNDARIES
  ┌─────────────────────────────────────────────────┐
  │  PRESENTATION / MOBILITY (UI)                   │ ← Customer owns
  ├─────────────────────────────────────────────────┤
  │  APPLICATION LAYER (Business Logic)             │ ← Customer owns
  ├──────────────────────────────── SaaS BOUNDARY ──┤
  │  APIs + INTEGRATION + MIDDLEWARE                │
  ├──────────────────────────────── PaaS BOUNDARY ──┤
  │  CORE CONNECTIVITY + ABSTRACTION (Hypervisor)   │
  ├──────────────────────────────── IaaS BOUNDARY ──┤
  │  HARDWARE + FACILITIES + NETWORKING             │ ← CSP owns
  └─────────────────────────────────────────────────┘

Security Responsibility by Service Model

Service Model CSP Responsibility Customer Responsibility
IaaS Physical hardware, networking, hypervisor, data center OS, patching, middleware, application, data, identity, access
PaaS Everything up to and including the runtime/framework Application code, data, user identity management, access control
SaaS Entire stack (hardware → application → governance) User access control, which users can see what data
Key Rule: As you move up the stack from IaaS → PaaS → SaaS, more security is built in by the provider, and less is your responsibility — but you also have less control and visibility over how security is implemented.

Security Responsibilities by Deployment Type

Cloud Model Infrastructure Security Owner Infrastructure Manager Data Location Trust Level
Public Vendor Vendor Off-premises Untrusted
Private (internal) Customer Customer On-premises Trusted
Private (external) Vendor Vendor Off-premises Trusted (contractual)
Hybrid Both Both Both Mixed
Community Shared Shared Off- or on-premises Trusted

7.4 Cloud Security Alliance (CSA) Guidance Domains

The Cloud Security Alliance (CSA) is the industry body that studies and publishes guidance on cloud security. It partitions its guidance into 12 operational domains:

Domain Description
1. Governance & Enterprise Risk Risk management frameworks and controls adapted for cloud environments
2. Legal & e-Discovery Handling legal hold, forensics, and jurisdictional compliance
3. Compliance & Audit Meeting industry and government regulations, audit logs
4. Information Lifecycle Management Data classification, handling, retention, and disposal
5. Portability & Interoperability Avoiding lock-in; standards for migrating between cloud providers
6. Security, Business Continuity & DR Traditional security translated to cloud; disaster recovery planning
7. Datacenter Operations Physical security, power, cooling, and geographic diversity
8. Incident Response Detecting, responding, and recovering from security incidents in cloud
9. Application Security Secure SDLC, vulnerability management, API security
10. Encryption & Key Management Protecting data at rest and in transit; key lifecycle management
11. Identity & Access Management Authentication, authorization, federation, SSO
12. Virtualization Hypervisor security, VM isolation, side-channel attacks
CSA vs. NIST: A key difference: CSA considers multi-tenancy an essential element of cloud computing, adding important security concerns that the NIST model doesn't mandate.

7.5 Securing Data in the Cloud

Securing data is the single largest security concern in cloud computing. Data in the cloud is:

  • Located anywhere (another datacenter, another country)
  • Accessible over the public internet
  • Shared on hardware with other tenants

7.5.1 The Four Pillars of Data Security

Mechanism What It Does
Access Control Restricts who can read or write specific data
Authentication Verifies that a user or system is who they claim to be
Authorization Determines what an authenticated entity is permitted to do
Auditing Records all access events for later review or forensic analysis

7.5.2 Brokered Storage Access (Gatekeeper / KeyMaster Model)

Traditional firewalls can't protect cloud storage. An alternative architecture uses layered intermediary services:

Two-Key Single-Zone Model:

  [ CLIENT ]
       |
       | (1) Data request
       v
  [ PROXY (Gatekeeper) ]         ← Has PARTIAL trust only
  (validates client request,      ← Has NO direct storage access
   enforces rules, rate limits)   ← Sits on external network edge
       |
       | (2) Forwards validated request
       v
  [ BROKER (KeyMaster) ]         ← Has FULL storage access
  (holds trusted keys,            ← Has NO direct client contact
   controls READ/QUERY ops)       ← Runs in the cloud / internal network
       |
       | (3) Retrieves data from storage
       v
  [ CLOUD STORAGE ]              ← Never directly accessible by client

Flow of a data request:

  1. Client sends data request to Proxy's external endpoint.
  2. Proxy applies rules (identity check, rate limiting), validates request.
  3. Proxy forwards to Broker using internal interface.
  4. Broker requests actual data from Cloud Storage using trusted key.
  5. Cloud Storage returns data to Broker.
  6. Broker relays data to Proxy.
  7. Proxy returns data to Client.
Security benefit: Even if the Proxy is fully compromised, the attacker cannot access Cloud Storage — they do not have the trusted keys held by the Broker.

Advanced: Two-Key Multi-Zone Model (maximum isolation)

  [ CLIENT ]
       |
  [ PROXY ] ←─── Untrusted Zone (Key 1) ──────────────→ [ Untrusted Storage, Key 1 ]
       |                                                        |
       |                                                 Relay (no direct access)
       |                                                        |
  [ BROKER ] ←─── Trusted Zone (Key 2) ─────────────→  [ Trusted Storage, Key 2 ]

In the multi-zone model:

  • Key 1: Encrypts communication between Proxy and Broker (untrusted zone).
  • Key 2: Encrypts the actual data in the Trusted Storage Account.
  • Even if Key 1 is compromised, the attacker cannot decrypt data in the Trusted Storage Account.

7.5.3 Storage Tenancy and Location

Concern What You Should Know
Data segregation How does the CSP keep your data separate from other tenants? (Physical storage zones, encryption per customer, access control policies)
Privileged access Who at the CSP can access your data? What background checks are done on their staff?
Data location In what countries is your data stored? Which privacy laws apply?
Disaster recovery Can the CSP replicate data and apps across multiple geographic sites?
Data portability If the CSP fails or you leave, can you retrieve your data in a usable format?

7.6 Encryption and Key Management

7.6.1 Why Encryption is Essential

  • Data in Transit: Assume any data crossing the internet can be intercepted (Man-in-the-Middle attack). Must use TLS/HTTPS for all cloud API calls and data transfers.
  • Data at Rest: Data stored in cloud object stores (S3, Azure Blob) must be encrypted so that physical access to the disk does not expose data.

7.6.2 The CIA Triad Applied to Cloud

  ┌─────────────────────────────────────┐
  │   CONFIDENTIALITY                   │
  │   Data is only accessible to        │
  │   authorized parties.               │
  │   Mechanism: Encryption             │
  ├─────────────────────────────────────┤
  │   INTEGRITY                         │
  │   Data has not been tampered with.  │
  │   Mechanism: Digital signatures,    │
  │   hashing (SHA-256), checksums      │
  ├─────────────────────────────────────┤
  │   AVAILABILITY                      │
  │   Data and services are accessible  │
  │   when needed.                      │
  │   Mechanism: Replication, DR sites, │
  │   redundant networking              │
  └─────────────────────────────────────┘

7.6.3 Key Management Best Practices

Practice Why It Matters
Define a key lifecycle Keys must be created, used, rotated, and eventually revoked in a controlled way.
Separate key management from storage Never let the same provider hold both the data AND the encryption keys. If they are compromised, all data is lost.
Rotate keys regularly Limits the exposure window if a key is compromised.
Secure key stores Role-based access to key management systems; automated backup of keys.
Use standard protocols OASIS KMIP (Key Management Interoperability Protocol); IEEE 1619.3 for storage encryption
Most catastrophic failure mode: Losing the encryption keys = losing the data permanently. Key management failures are responsible for more data loss than encryption algorithm weaknesses.

7.7 Auditing, Logging, and Regulatory Compliance

7.7.1 Logging vs. Auditing

Term Definition
Logging Recording events (accesses, writes, errors, system events) into a repository.
Auditing Analyzing logged events to understand performance, detect anomalies, or support a legal investigation.

Minimum events that must be logged:

  • System events (start/stop, configuration changes)
  • Application events (user logins, data access, transactions)
  • Security events (failed logins, access denied, policy violations)

7.7.2 Cloud Auditing Challenges

Challenge Impact
Proprietary log formats Vendor-specific log structures that require specialized parsing tools.
Multisite, multitenant logs A single audit trail may span multiple physical sites and be co-mingled with other tenants' data.
Log access You may not have the right to access raw server logs unless it is negotiated in the SLA.
Timing If an investigation is launched weeks after an incident, logs may have been overwritten.
Best practice: Negotiate a right-to-audit clause in your SLA. Verify that the provider has successfully supported investigations in the past.

7.7.3 Regulatory Compliance Frameworks

Regulation Industry Key Requirement
PCI-DSS Payment Card Encrypt cardholder data at rest and in transit, quarterly vulnerability scans
HIPAA Healthcare (US) Protect patient health information (PHI), strict access controls
GDPR EU Citizens Data residency in EU, right to erasure, 72-hour breach notification
SOX Publicly Traded Companies (US) Financial audit trails, internal controls
GLBA Financial Services (US) Consumer financial data privacy
ISO/IEC 27001 Any industry International standard for Information Security Management Systems (ISMS)
SAS 70 Type II Any industry Auditor's report on internal controls at service organizations
Critical Rule: Regulations were written without cloud computing in mind. A regulator will not accept "the cloud provider has it" as a defense. The client is always responsible for their own compliance, even if they've outsourced operations.

Compliance Checklist for Cloud Deployments:

  1. Have contracts reviewed by legal staff.
  2. Include a right-to-audit clause in the SLA.
  3. Assess all third-party sub-processors of the CSP.
  4. Understand which regulations apply to where your data is processed.
  5. Determine whether your CSP provides a SAS 70 Type II-compliant audit statement.
  6. Collect and maintain evidence of your compliance over time.

7.8 Infrastructure Security

7.8.1 Network-Level Security

Threat Description Defense
DoS/DDoS Flooding a server with traffic to exhaust resources Rate limiting, Cloud-scale scrubbing centers, CDN-based mitigation
DNS Attacks (DNS Spoofing) Redirecting traffic to a malicious server by poisoning DNS cache DNSSEC, monitoring DNS resolution anomalies
Man-in-the-Middle (MITM) Intercepting communications between client and cloud TLS/HTTPS for all traffic, certificate pinning
IP Spoofing Forging source IP addresses to impersonate trusted systems Ingress filtering at the cloud provider's network edge

Cloud network security mechanisms:

  • Virtual Private Networks (VPNs): Encrypted tunnel from your premises to the cloud.
  • VLANs (Virtual LANs): Network segmentation at the virtual switch level to isolate tenants.
  • Security Groups / Firewall Rules: Stateful packet filtering applied to each VM instance.
  • Network ACLs (Access Control Lists): Stateless filtering at the subnet level.

7.8.2 Host-Level Security (Hypervisor Security)

The hypervisor (VMM) is the most sensitive component in cloud infrastructure. A compromised hypervisor can expose ALL VMs running on that physical host.

  VM A (Tenant X)    VM B (Tenant Y)    VM C (Tenant Z)
      |                   |                   |
      +---------+---------+---------+---------+
                          |
              [ HYPERVISOR (VMM) ]   ← Attack target
                          |
             [ Physical Hardware ]

Key Threats:

Attack Description
VM Escape A guest VM exploits a hypervisor vulnerability to gain access to the host OS or other VMs. Extremely critical — bypasses all tenant isolation.
Side-Channel Attacks Exploiting shared CPU cache (e.g., Spectre, Meltdown) to leak information across VM boundaries without "escaping."
Hyperjacking Replacing or subverting the hypervisor itself with a malicious version (advanced persistent threat).
VM Hopping Compromising one VM and using it as a pivot point to attack adjacent VMs on the same host.

Defenses:

  • Keep hypervisor software patched to latest versions.
  • Use hardware-enforced memory isolation (Intel VT-d, AMD-Vi).
  • Employ Trusted Platform Module (TPM) for verified boot chains.
  • "Golden image" references: Take snapshots of known-good states; replace compromised VMs from snapshots.

7.9 Identity and Access Management (IAM)

Identity management controls who can do what in a cloud environment. The four requirements for cloud identity:

  1. ESTABLISH:    Create a verifiable digital identity
  2. AUTHENTICATE: Prove the identity is genuine
  3. PORTABLE:     Authentication works across multiple services/clouds
  4. AUTHORIZE:    Identity grants specific access to cloud resources

7.9.1 OpenID 2.0 — Single Sign-On (SSO)

OpenID is the standard for federated identity and SSO. A user's identity is verified by a third-party Identity Provider (IdP) and that authentication is trusted by multiple Service Providers (SPs) — so you only log in once.

OpenID Authentication Flow:

  1. User opens browser → enters OpenID identifier (URL-like: user.provider.org)
              |
  2. User Agent presents OpenID to Relying Party (service they want access to)
              |
  3. Relying Party queries the OpenID Identity Provider to verify the credentials
              |
  4. Identity Provider authenticates the user (CHAP, smart card, biometric, etc.)
              |
  5. Authentication result sent back to Relying Party → access granted or denied
Scale: Over 1 billion OpenID accounts accepted by 9 million websites.

7.9.2 SAML — Security Assertion Markup Language

SAML is an XML-based standard (by OASIS) for exchanging authentication and authorization data between an Identity Provider and a Service Provider.

  • Used to create SSO systems — a user authenticates once; SAML assertions are passed to other services.
  • Complementary to OpenID: OpenID identifies the user; SAML carries claims about the user.
  • Gaining growing acceptance among cloud service providers.
  SAML SSO Flow:
  
  User ──(login once)──► Identity Provider (e.g., corporate Active Directory)
                              |
                   SAML Assertion (XML token signed by IdP)
                              |
                              ▼
                       Service Provider (cloud app)
                   (trusts the IdP signature, grants access)

7.9.3 OAuth 2.0 — Token-Based Authorization

OAuth provides delegated authorization — it lets an application access resources on behalf of a user without receiving the user's password.

Feature OAuth 2.0
What it issues Access tokens (time-limited bearer tokens)
What it protects User credentials (passwords never shared with third-party app)
When token expires Access is automatically revoked — reducing long-term exposure
Adopted by Facebook Graph API, Google Data API, Twitter API, AWS 
  OAuth 2.0 Flow:
  
  User → authorizes Third-Party App → App receives ACCESS TOKEN
                                              |
                                              ▼
                              App uses token to call Cloud API
                    (API validates token with Authorization Server)

7.9.4 Comparison: OpenID vs. SAML vs. OAuth

Protocol Purpose Format Typical Use
OpenID Authentication (who are you?) URL-based identifier SSO login across web services
SAML Authentication + Authorization assertions XML Enterprise SSO, federated identity
OAuth 2.0 Delegated authorization (can this app act for you?) JSON (JWT tokens) API access, mobile apps, mashups

7.10 Presence in Cloud Computing

Presence = Mapping an authenticated identity to a known status and location in real time.

Term Definition
Presence State The current status of a user/device (online, away, busy, offline)
Presentity The entity whose presence is being tracked (a user, device, service)
Presence Service The service managing and broadcasting presence information
Watcher A small program that monitors and relays a client's connectivity status

7.10.1 Why Presence Matters for Cloud

Presence adds context that modifies service delivery:

  • A VoIP call is routed to your mobile if your desktop presence shows "offline."
  • A geo-location app shows nearby restaurants based on your GPS coordinates.
  • A cloud streaming service adjusts video quality based on your network presence (bandwidth).

7.10.2 XMPP — The Presence Protocol

XMPP (Extensible Messaging and Presence Protocol) — An IETF standard originally built for Jabber instant messaging, now the backbone for presence-aware cloud services.

Feature Detail
Protocol type Open standard, XML-based
Transport TCP (persistent connection, unlike HTTP's request-response)
Real-time True bidirectional data push — unlike SOA (SOAP/REST) which is request-response only
Firewall friendly Designed to traverse firewalls that block most other real-time protocols

Services using XMPP/Jabber:

  • Google Talk, Facebook Chat
  • AOL Instant Messenger
  • U.S. Government agencies (DISA, U.S. Marine Corps, USJFCOM)
  • National Weather Service

Why not SOA (SOAP/REST) for presence?

  SOA (HTTP Request-Response):          XMPP (Persistent Connection):
  
  Client ──request──► Server            Client ←──── Server PUSHES
         ◄──response──                  (bidirectional, real-time)
  
  Problem: Not designed for continuous  Advantage: Status updates arrive
  streaming. Doesn't scale for          immediately without polling.
  real-time collaboration.

7.11 Security Summary Table

Area Key Concern Primary Mechanism
Data in Transit Interception / MITM TLS/HTTPS encryption
Data at Rest Unauthorized access to storage AES encryption, key management
Identity Impersonation / unauthorized access OpenID, SAML, OAuth 2.0, MFA
Network DDoS, IP spoofing, VLAN hopping Firewalls, VPNs, VLANs, security groups
Hypervisor VM Escape, side-channel attacks Patching, hardware isolation, snapshots
Compliance Regulatory violations SAS 70 Type II, ISO 27001, right-to-audit clause
Auditing Inability to investigate incidents SLA-negotiated log access, SIEM tools
Key Management Loss of encryption keys = loss of data KMIP, separate key store from data store

Navigation

Previous Unit: Cloud Computing Management

← Previous