Unit 1: Understanding Cloud Security

1. Cloud Security Foundations & Threat Landscape

Cloud computing shifts traditional on-premises enterprise workloads into shared, multi-tenant virtualized environments managed by Cloud Service Providers (CSPs) such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

While cloud adoption delivers unprecedented elasticity, scalability, and geographic distribution, it fundamentally alters the enterprise security perimeter. In traditional corporate datacenters, security relied primarily on physical isolation, perimeter firewalls, and network demilitarized zones (DMZs). In modern cloud environments, Identity is the new primary security perimeter, and boundaries are enforced via software-defined virtualization, encryption, micro-segmentation, and policy-driven governance.

CODECopy Code
+--------------------------------------------------------------------------+
|                  Traditional vs. Cloud Security Paradigm                 |
|                                                                          |
|   Traditional On-Premises:             Modern Cloud Computing:           |
|   +----------------------------+       +----------------------------+    |
|   | Physical Perimeter (Walls) |       |   Identity & Access (IAM)  |    |
|   +----------------------------+       +----------------------------+    |
|   | Network Firewalls & DMZs   |       | Data Encryption & Key Mgmt |    |
|   +----------------------------+       +----------------------------+    |
|   | Hypervisors & Servers      |       | Micro-Segmentation / NSGs  |    |
|   +----------------------------+       +----------------------------+    |
|   | Applications & Databases   |       | Zero-Trust Network Access  |    |
|   +----------------------------+       +----------------------------+    |
|   | Corporate Data             |       | Continuous Compliance & SIEM|   |
|   +----------------------------+       +----------------------------+    |
+--------------------------------------------------------------------------+

The Core CIA Triad in the Cloud

1. Confidentiality: Ensuring that customer data, proprietary algorithms, and access tokens are shielded from unauthorized disclosure through robust cryptography (AES-256, TLS 1.3), granular authorization policies, and hardware isolation (confidential computing).
2. Integrity: Protecting data and system configurations against unauthorized modification, tampering, or deletion via digital signatures, cryptographic hashes, immutable storage tiers, and strict versioning.
3. Availability: Guaranteeing continuous, resilient access to cloud services, virtual machines, and analytical pipelines through multi-region replication, automated failover, load balancing, and proactive DDoS mitigation.

2. The Shared Responsibility Model

The Shared Responsibility Model is the foundational legal and architectural construct defining the division of security obligations between the Cloud Service Provider (CSP) and the customer organization.

Security in the cloud is never entirely the provider's responsibility, nor is it entirely the customer's. The boundary of responsibility shifts depending on the service deployment model:

CODECopy Code
+-------------------------------------------------------------------------+
|                  The Shared Responsibility Spectrum                     |
|                                                                         |
| Responsibility Tier      On-Premises   IaaS        PaaS        SaaS     |
| -------------------      -----------   ----        ----        ----     |
| Information & Data        Customer    Customer    Customer    Customer  |
| Devices (Endpoints)       Customer    Customer    Customer    Customer  |
| Accounts & Identities     Customer    Customer    Customer    Customer  |
| Applications              Customer    Customer    Shared      Provider  |
| Network Controls          Customer    Customer    Shared      Provider  |
| Operating System          Customer    Customer    Provider    Provider  |
| Hypervisor & Virtual      Customer    Provider    Provider    Provider  |
| Physical Network/Hosts    Customer    Provider    Provider    Provider  |
| Physical Datacenter       Customer    Provider    Provider    Provider  |
+-------------------------------------------------------------------------+

Detailed Breakdown by Deployment Model

1. Infrastructure as a Service (IaaS) (e.g., Azure Virtual Machines, AWS EC2):
   • Provider Responsibilities: Physical facility security, power, climate control, physical server hardware, storage hardware, and the core virtualization hypervisor.
   • Customer Responsibilities: Guest operating system installation, OS security patch management, host firewall configuration, virtual network routing, application runtimes, database security, credentials, and data protection.
2. Platform as a Service (PaaS) (e.g., Azure SQL Database, AWS Elastic Beanstalk):
   • Provider Responsibilities: Physical infrastructure, hypervisor, host OS, guest OS patching, hardware maintenance, and database engine maintenance.
   • Customer Responsibilities: Application code, business logic, API security, database schema permissions, access management, and sensitive data classification.
3. Software as a Service (SaaS) (e.g., Microsoft 365, Salesforce):
   • Provider Responsibilities: Manages virtually the entire application stack: infrastructure, OS, database, application uptime, software patching, and feature releases.
   • Customer Responsibilities: User account provisioning, identity lifecycle, multi-factor authentication, device endpoint compliance, and governance over data shared within the platform.

Universal Invariant: Across all cloud deployment models (IaaS, PaaS, SaaS), the Customer retains 100% accountability for:

• Customer Data and Classification
• User Accounts and Identity Access Management
• Client Endpoints and Device Security

3. Cloud Security Challenges, Threats, and Governance

1. Data Breaches & Storage Misconfigurations

The leading cause of cloud data breaches is not sophisticated cryptographic cracking, but mundane customer misconfiguration:

• Publicly Accessible Buckets/Blobs: Deploying storage containers (e.g., Amazon S3 buckets or Azure Blob Storage accounts) without restricting anonymous public read access.
• Overly Permissive Access Rules: Granting wildcard permissions ("Action": "*") in IAM policies.
• Inadequate Encryption: Storing sensitive records in plaintext without server-side encryption (SSE) or using unmanaged default keys.

2. Insider Threats

Insider threats originate from individuals with legitimate, authorized access to organizational systems (employees, contractors, cloud administrators):

• Malicious Insiders: Disgruntled personnel intentionally exfiltrating sensitive intellectual property, sabotaging cloud infrastructure, or implanting backdoors.
• Compromised Insiders: Legitimate credentials stolen via phishing, credential stuffing, or session hijacking.
• Careless Insiders: Well-intentioned users accidentally exposing API credentials in public GitHub repositories or bypassing security controls to expedite testing.

3. Compliance Risks and Global Regulatory Standards

Operating across distributed multi-region clouds requires rigorous alignment with statutory frameworks:

• GDPR (General Data Protection Regulation): Enforces European data sovereignty, strict consent management, breach notification within 72 hours, and the 'Right to be Forgotten'. Requires explicit guarantees when transferring personal data outside the EEA.
• HIPAA (Health Insurance Portability and Accountability Act): Mandates administrative, physical, and technical safeguards (including end-to-end encryption and audit logging) for Protected Health Information (PHI) within US healthcare clouds.
• PCI-DSS (Payment Card Industry Data Security Standard): Demands strict isolation of cardholder data environments (CDE), continuous network monitoring, vulnerability scanning, and multi-factor authentication.
• SOC 2 Type II: Evaluates an organization's controls over time across five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
• ISO/IEC 27001 & 27017: International benchmarks for Information Security Management Systems (ISMS) specifically tailored for cloud computing environments.

4. Identity Security in Microsoft Azure: Microsoft Entra ID (Azure AD)

In Microsoft Azure, identity and access management is powered by Microsoft Entra ID (formerly known as Azure Active Directory or Azure AD). It is an enterprise multi-tenant, cloud-based identity and access management directory service.

CODECopy Code
+--------------------------------------------------------------------------+
|                  Microsoft Entra ID Hierarchy & Scopes                   |
|                                                                          |
|   +------------------------------------------------------------------+   |
|   |                      Root Management Group                       |   |
|   +------------------------------------------------------------------+   |
|                                    |                                     |
|               +--------------------+--------------------+                |
|               v                                         v                |
|   +-----------------------+                 +-----------------------+    |
|   | Management Group (Dev)|                 | Management Group(Prod)|    |
|   +-----------------------+                 +-----------------------+    |
|               |                                         |                |
|               v                                         v                |
|   +-----------------------+                 +-----------------------+    |
|   | Azure Subscription A  |                 | Azure Subscription B  |    |
|   +-----------------------+                 +-----------------------+    |
|               |                                         |                |
|               v                                         v                |
|   +-----------------------+                 +-----------------------+    |
|   |  Resource Group (RG)  |                 |  Resource Group (RG)  |    |
|   +-----------------------+                 +-----------------------+    |
|               |                                         |                |
|               v                                         v                |
|   +-----------------------+                 +-----------------------+    |
|   | Individual Resources  |                 | Individual Resources  |    |
|   | (VMs, DBs, Storage)   |                 | (VMs, DBs, Storage)   |    |
|   +-----------------------+                 +-----------------------+    |
+--------------------------------------------------------------------------+

Entra ID vs. Traditional On-Premises Windows Server Active Directory (AD DS)

5. User and Group Management

Account Types in Entra ID

1. Cloud-Only Identities: Users created directly in the cloud directory (e.g., analyst@corp.onmicrosoft.com). Common for external contractors, cloud administrators, and cloud-native organizations.
2. Directory-Synchronized Identities: Users provisioned in an on-premises Active Directory and synchronized to Entra ID via Microsoft Entra Connect (using Password Hash Synchronization or Pass-Through Authentication).
3. Guest / B2B Identities: External collaborator identities (e.g., vendor emails) invited into the tenant using Microsoft Entra B2B collaboration, allowing cross-organization access without creating secondary accounts.

Group Types and Assignment Models

• Security Groups: Used to assign access to Azure resources, applications, and licensing.
• Microsoft 365 Groups: Collaboration groups providing shared mailboxes, SharePoint sites, and Teams channels.
• Assignment Methodologies:
  • Assigned Membership: Administrators manually add specific users. High administrative overhead; error-prone during role transitions.
  • Dynamic User Membership: Uses attribute-based membership rules evaluated automatically. For example:

    user.department -eq "Finance" and user.country -eq "USA"
    

    When an employee transfers departments in HR, their group memberships and associated role assignments update automatically.

6. Azure Role-Based Access Control (Azure RBAC)

Azure RBAC is an authorization system built on Azure Resource Manager (ARM) that provides fine-grained access management of Azure cloud resources.

The RBAC Assignment Structure

An Azure RBAC assignment consists of three components:
$\text{Role Assignment} = \text{Security Principal} + \text{Role Definition} + \text{Scope}$

CODECopy Code
+------------------+         +--------------------+         +------------------+
|Security Principal|  +--->  |  Role Definition   |  +--->  |      Scope       |
| (User, Group, SP,|         | (Owner, Reader,    |         | (Management Group|
| Managed Identity)|         |  Custom Role)      |         |  Sub, RG, Resource|
+------------------+         +--------------------+         +------------------+

1. Security Principal: An object representing who is requesting access:
   • User, Group, Service Principal (application identity), or Managed Identity (identity assigned to Azure resources).
2. Role Definition: A collection of permissions (Actions, NotActions, DataActions, NotDataActions):
   • Owner: Full access to all resources, including permission to delegate access to others.
   • Contributor: Can create and manage all types of Azure resources, but cannot grant access to others.
   • Reader: View existing Azure resources; cannot make changes.
   • User Access Administrator: Manage user access to Azure resources; cannot manage resources themselves.
3. Scope: The boundary where access applies. Scopes form a strict inheritance hierarchy:
   $\text{Management Group} \longrightarrow \text{Subscription} \longrightarrow \text{Resource Group} \longrightarrow \text{Individual Resource}$
   Permissions granted at a higher scope are inherited by all child scopes below it.

Principle of Least Privilege (PoLP)

Administrators must always assign users the minimum necessary permissions required to execute their specific job duties, scoped at the lowest practical boundary (e.g., granting Contributor on a single Resource Group rather than on the entire Subscription).

7. Multi-Factor Authentication (MFA) and Conditional Access

Password authentication alone is acutely vulnerable to phishing, credential stuffing, and keylogging attacks. Modern cloud identity enforces multi-layered verification:

The Authentication Factor Categories

Multi-Factor Authentication requires presenting two or more independent authentication factors:

1. Something you know (Knowledge): Password, PIN, security passphrase.
2. Something you have (Possession): Hardware security key (FIDO2), smartphone running Microsoft Authenticator app, SMS code, software TOTP token.
3. Something you are (Inherence): Biometric data (fingerprint scan, facial recognition, iris scan).

CODECopy Code
+--------------------------------------------------------------------------+
|                  Conditional Access Decision Engine                      |
|                                                                          |
|   SIGNALS (Real-Time Context)                                            |
|   +------------------------------------+                                 |
|   | - User / Group Identity            |                                 |
|   | - IP Location (Trusted / Risky)    |                                 |
|   | - Device State (Compliant / Intune)|                                 |
|   | - Client App (Browser / Legacy)    |                                 |
|   | - Real-time Identity Risk Level    |                                 |
|   +------------------------------------+                                 |
|                     |                                                    |
|                     v                                                    |
|   +------------------------------------+                                 |
|   |    Conditional Access Policy Engine|                                 |
|   +------------------------------------+                                 |
|                     |                                                    |
|                     v                                                    |
|   DECISION / ENFORCEMENT                                                 |
|   +------------------------------------+                                 |
|   | [ Block Access Completely ]        |                                 |
|   | [ Grant Access ]                   |                                 |
|   | [ Grant Access with Controls: ]    |                                 |
|   |   - Require Multi-Factor Auth (MFA)|                                 |
|   |   - Require Compliant Device       |                                 |
|   |   - Require Password Reset         |                                 |
|   +------------------------------------+                                 |
+--------------------------------------------------------------------------+

Conditional Access Policies: "If-Then" Security

Conditional Access is Entra ID’s Zero-Trust policy engine. Rather than enforcing static security rules, it dynamically evaluates real-time Signals to enforce Controls:

1. Signals (Conditions):
   • User identity and assigned roles (e.g., Global Admin vs. standard employee).
   • Network location (corporate trusted network IP range vs. anonymous Tor exit node).
   • Device compliance status (managed via Microsoft Intune vs. unmanaged personal PC).
   • Application accessed (low-risk portal vs. high-risk production database).
   • Real-time identity risk score (detected impossible travel or leaked credentials).
2. Access Controls (Decisions):
   • Block Access: Terminate connection immediately if conditions are hostile.
   • Grant Access with Restrictions:
     • Require Multi-Factor Authentication (MFA).
     • Require the device to be marked as compliant.
     • Require Hybrid Entra ID join.
     • Require Terms of Use acceptance.

8. Privileged Identity Management (PIM) and Zero-Trust

Privileged Identity Management (PIM)

Permanent administrative access ("standing access") creates an enormous attack surface. If a global administrator's account is compromised, the attacker retains unrestricted domain access indefinitely.

Microsoft Entra Privileged Identity Management (PIM) eliminates standing privileges through Just-In-Time (JIT) role activation:

• Users are designated as Eligible for a role (e.g., Eligible Contributor) rather than permanently assigned.
• When elevated access is needed, the user activates the role through the portal, supplying:
  1. Mandatory Multi-Factor Authentication.
  2. A valid business justification or ticketing ID.
  3. A time-bounded activation duration (e.g., 2 hours).
  4. Optional peer/manager approval.
• Once the time expires, permissions automatically revoke, eliminating orphaned elevated rights.
• Access Reviews: Automated periodic audits forcing managers to re-certify whether employees still require access to privileged roles.

Core Principles of Zero-Trust

1. Verify Explicitly: Always authenticate and authorize based on all available data points (identity, location, device health, resource, data classification, and anomalies).
2. Use Least Privilege Access: Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection.
3. Assume Breach: Minimize blast radius by segmenting access, verifying end-to-end encryption, and utilizing analytics to gain visibility and drive threat detection.

9. Comprehensive Troubleshooting Guide