Cloud Security

Cloud security is governed by a shared responsibility model. The division of responsibility between The cloud provider and the customer depends on the service model (IaaS, PaaS, or SaaS). Misunderstanding this boundary is the single most common cause of cloud security incidents.

In IaaS (e.g., EC2, VMs), the provider secures the physical infrastructure: the data center, Servers, storage hardware, and the hypervisor. The customer is responsible for everything above the Hypervisor: the operating system, runtime, application, data, and network configuration (security Groups, NACLs).

In PaaS (e.g., Lambda, App Engine, Azure Functions), the provider also manages the operating system And runtime. The customer is responsible only for the application code, data, and access controls.

In SaaS (e.g., Office 365, Salesforce, Gmail), the provider manages nearly everything. The customer Is responsible only for data and access.

The provider secures the cloud. You secure what is in the cloud. Regardless of the service model, You always own the responsibility for:

• Data classification and protection
• Identity and access management (configuring who can access what)
• Network configuration (where applicable)
• Application security
• Compliance with regulatory requirements

IAM is the foundational security control in cloud environments. It determines who can do what to Which resources.

• Principal: An entity that can be authenticated (user, role, service account, group).
• Policy: A document that defines permissions (what actions are allowed or denied on which resources under what conditions).
• Role: An identity that can be assumed by a principal, a service, or an instance. Roles provide temporary credentials and are the primary mechanism for granting permissions to compute resources.
• Group: A collection of users that share the same permissions. Simplifies administration.
• MFA (Multi-Factor Authentication): Requires two or more verification factors. MFA should be enforced on all human accounts, especially those with elevated privileges.

Every principal should have only the permissions necessary to perform its intended function. This is The principle of least privilege. In practice, this means:

• Use read-only permissions for workloads that do not need to write.
• Scope permissions to specific resources, not wildcards (*).
• Use roles instead of long-lived access keys for services.
• Regularly audit permissions and remove unused ones.
• Implement permission boundaries to prevent privilege escalation.

1. Over-privileged service accounts. A Lambda function with s3:* on all buckets when it only needs s3:GetObject on one bucket.
2. Using root accounts for daily operations. The root account should be locked down with MFA and hardware key; all work should be done with IAM users or roles.
3. Long-lived access keys. Service accounts should use short-lived credentials (role assumption) rather than static access keys that never expire.
4. No permission boundary. Without boundaries, a user with iam:PutUserPolicy can grant themselves additional permissions, breaking least privilege.

AWS IAM is the central identity service. Key components:

• Users: Individual identities (human or service).
• Roles: Assumable identities for services (EC2, Lambda) or cross-account access.
• Policies: JSON documents with Effect (Allow/Deny), Action, Resource, and optional Condition.
• Groups: Collections of users with shared policies.
• Instance profiles: Containers for roles that EC2 instances can assume.

IAM policy evaluation follows a deterministic order:

1. Explicit deny (always wins)
2. Explicit allow
3. Default deny (implicit)

A policy that denies access to a resource will always override an allow, even if the allow comes From a higher-priority policy.

S3 bucket policies are resource-based policies attached to S3 buckets. They define what principals Can access the bucket and under what conditions.

Common misconfigurations:

• Public bucket. "Principal": "*" with "Effect": "Allow" makes the bucket publicly accessible. This is how millions of records have been exposed.
• Overly broad actions. "Action": "s3:*" grants all S3 permissions, including DeleteObject.
• Missing encryption requirements. Without a condition that requires aws:SecureTransport (TLS) or server-side encryption, data can be accessed over HTTP or stored unencrypted.

Secure bucket policy example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyAppRole" },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/app/*"
    }
  ]
}

Security groups are the primary defense. NACLs provide an additional layer but should not be relied Upon as the sole defense mechanism.

AWS KMS provides cryptographic key management. Key concepts:

• Customer Master Key (CMK): A logical key that is used to encrypt and decrypt data. The actual encryption is performed by the backing key material stored in HSMs (Hardware Security Modules).
• Envelope encryption: KMS does not encrypt data directly. Instead, it generates a data key, encrypts the data key with the CMK, and returns both the plaintext data key and the encrypted data key. The plaintext data key is used to encrypt the data and then discarded from memory. The encrypted data key is stored alongside the encrypted data.
• Key rotation: CMKs can be configured for automatic annual rotation. Rotating a CMK does not require re-encrypting existing data — KMS maintains multiple key versions.

AWS CloudTrail records API calls made in your account. It is essential for:

• Forensic investigation: Determining who did what and when.
• Compliance: Providing an audit trail of all API activity.
• Security monitoring: Detecting anomalous API calls (e.g., creating a new user, changing a security group, deleting a log).

CloudTrail should be enabled in all regions with log file validation and multi-region trails. Integrate with CloudWatch Logs or an external SIEM for real-time alerting.

GuardDuty is a threat detection service that uses ML and threat intelligence feeds to identify:

• Unauthorized behavior (e.g., unusual API calls, deployments in unusual regions)
• Compromised credentials (e.g., credential exfiltration, brute force)
• Instance compromise (e.g., cryptocurrency mining, port scanning from an EC2 instance)
• Reconnaissance (e.g., port probes, unusual DNS queries)

AWS Config records configuration changes to AWS resources and evaluates them against compliance Rules. It provides a historical timeline of configuration changes and can trigger automated Remediation actions when a resource drifts from its desired state.

AWS WAF provides rule-based HTTP request filtering. It integrates with CloudFront, ALB, and API Gateway. Use managed rule groups (AWSManagedRulesCommonRuleSet, AWSManagedRulesSQLiRuleSet) and Custom rules to block common web attacks (SQL injection, XSS, LFI/RFI).

Azure Active Directory (now Microsoft Entra ID) is the identity service for Azure and Microsoft 365.

• Users, Groups, and Service Principals: Equivalent to IAM users, groups, and roles.
• App Registrations: Represent applications that need to authenticate with Azure AD.
• Managed Identities: System-assigned or user-assigned identities for Azure resources (equivalent to IAM roles). They eliminate the need for stored credentials.
• Conditional Access: Policies that evaluate sign-in risk, device compliance, location, and other factors before granting access.

Azure RBAC defines permissions at the resource, resource group, or subscription scope.

• Built-in roles: Owner, Contributor, Reader, User Access Administrator, and many service-specific roles (e.g., Storage Blob Data Contributor).
• Custom roles: JSON-defined roles with actions``notActions``dataActionsAnd assignableScopes.
• Key principle: Use the most restrictive built-in role, and create custom roles only when necessary.

Azure Policy enforces organizational standards. It evaluates resources against policy definitions And can enforce or audit compliance. Examples:

• Require encryption on storage accounts.
• Restrict VM sizes to approved SKUs.
• Require tags on all resources.
• Deny public IP addresses on certain resource types.

Azure Key Vault stores secrets, keys, and certificates. Access is controlled through Azure RBAC or Key Vault access policies. Key Vault supports:

• Secrets management: Store connection strings, API keys, and other sensitive values.
• Key management: Create and manage RSA and EC keys for encryption and signing.
• Certificate management: Provision and manage TLS/SSL certificates.
• HSM-backed keys: Premium tier uses FIPS 140-2 Level 2 HSMs for key storage.

Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) service. It ingests logs from Azure services, Microsoft 365, AWS, GCP, and on-premises systems. Sentinel uses built-in workbooks, analytics rules, and Automation playbooks to detect and respond to threats.

GCP IAM follows a resource-hierarchy model: Organization > Folder > Project > Resource.

• Primitive roles: Owner, Editor, Viewer. These are overly broad and should be avoided in production.
• Predefined roles: Granular roles for specific services (e.g., roles/storage.objectViewer roles/cloudsql.client).
• Custom roles: Define specific permissions for your organization”s needs.
• Service accounts: Used by applications and compute resources. Should be configured with the minimum permissions required.

GCP IAM evaluation follows the same deny-override principle as AWS: if any policy denies an action, The action is denied regardless of allow policies.

VPC Service Controls create a security perimeter around GCP resources (BigQuery, Cloud Storage, Data ML). They prevent data exfiltration by restricting API access to resources within the perimeter, Even from authenticated users outside the perimeter.

Use cases:

• Prevent a compromised VM from copying data from BigQuery to an external storage bucket.
• Restrict access to sensitive datasets to specific VPC networks.
• Enforce that data can only flow between approved services.

Security Command Center (SCC) provides a centralized view of your GCP security posture. It includes:

• Security Health Analytics: Detects misconfigured resources (public buckets, open firewall rules, overly permissive IAM).
• Web Security Scanner: Scans web applications for vulnerabilities (XSS, SQL injection, etc.).
• Event Threat Detection: Identifies threats from audit logs (brute force, malware, cryptocurrency mining).

GCP has specific patterns that differ from AWS and Azure:

• Workload Identity: For GKE workloads, use Workload Identity (GKE service account to GCP service account mapping) instead of exporting service account keys.
• Service account key management: Never export service account keys. If you must, set an expiration date and rotate regularly. Monitor key usage with audit logs.
• Organization Policies: Define constraints at the organization level (e.g., restrict VM creation to approved regions, disable public IP assignment, restrict service account creation).
• Folder hierarchy: Use folders to map organizational structure (e.g., Production, Staging, Development) and apply different policies at each level.

The most common cloud data breach is a publicly accessible storage bucket or blob container.

Attack vectors:

• S3 bucket policy with "Principal": "*" and "Effect": "Allow"
• Azure Blob container set to “Blob” or “Container” access level instead of “Private”
• GCP Cloud Storage bucket with allUsers granted objectViewer or objectCreator roles

Prevention:

• Block public access at the account level (AWS S3 Block Public Access)
• Use resource-based policies that require specific principals
• Enable server-side encryption by default
• Regularly audit storage configurations with CSPM tools

Credentials in code, configuration files, CI/CD pipelines, and public repositories.

Common sources:

• Hardcoded AWS access keys in source code committed to GitHub
• Service account keys stored in Docker images or Kubernetes ConfigMaps
• .env files committed to version control
• Credentials in CI/CD pipeline environment variables visible in build logs

Prevention:

• Use managed identities (IAM roles, Managed Identities, service accounts) instead of static keys
• Scan repositories for secrets (git-secrets, truffleHog, Gitleaks)
• Rotate keys regularly and revoke unused keys
• Use secret management services (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)

Overprivileged identities are the gateway to most cloud attacks. An attacker who compromises a Single credential with broad permissions can pivot to compromise the entire environment.

Common patterns:

• Service accounts with *:* permissions
• Developers with AdministratorAccess or Owner roles
• CI/CD pipelines with production write access
• Cross-account roles with overly broad trust policies

Prevention:

• Conduct regular IAM access reviews
• Use permission boundaries to cap maximum permissions
• Implement just-in-time (JIT) access for elevated privileges
• Use AWS IAM Access Analyzer, Azure Permissions Management, or GCP IAM Recommender

Server-Side Request Forgery (SSRF) is particularly dangerous in cloud environments because the cloud Metadata service is accessible from within the instance.

• AWS: http://169.254.169.254/latest/meta-data/ provides instance metadata including IAM role credentials.
• Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01
• GCP: http://metadata.google.internal/computeMetadata/v1/

An attacker who can trigger an SSRF vulnerability in your application can query the metadata service And steal IAM credentials.

Prevention:

• Use IMDSv2 (Instance Metadata Service v2) on AWS, which requires a session token obtained via a PUT request
• Restrict metadata service access with a hop count of 1 (prevents SSRF via proxies)
• Use network policies to restrict outbound access from application tiers
• Validate and sanitize all user-supplied URLs

Data exfiltration from cloud environments can occur through:

• Direct download from compromised storage
• DNS exfiltration (encoding data in DNS queries)
• Cloud API calls to external services
• Encrypted channels (HTTPS to attacker-controlled endpoints)

Detection:

• Monitor egress traffic patterns (unexpected volume or destinations)
• Use VPC Flow Logs, NSG Flow Logs, or VPC Flow Logs
• Implement DNS query logging and analysis
• Use GuardDuty, Sentinel, or Security Command Center for anomaly detection

Cloud environments are increasingly targeted by supply chain attacks that compromise dependencies or Infrastructure:

• Container image poisoning. An attacker pushes a malicious image to a public registry with a tag matching a legitimate image (e.g., library/nginx:latest). Automated deployments pull the poisoned image.
• Dependency confusion. An attacker publishes a package with the same name as an internal package to a public registry. Build systems that check public registries first will install the malicious version.
• Terraform/IaC module tampering. Compromised Terraform modules or providers that inject backdoor resources (e.g., a security group rule that allows SSH from any IP).

Prevention:

• Pin image digests (e.g., nginx@sha256:abc123...) instead of tags
• Use private registries and mirror approved images
• Configure package managers to check private registries before public ones
• Sign and verify images (cosign, Notary)
• Review IaC modules before use and pin module versions

Docker containers share the host kernel. Container escape is possible if the container is Misconfigured.

Key security controls:

1. Minimal base image. Use scratch``alpineOr distroless images. Do not install unnecessary packages.
2. Run as non-root. The default Dockerfile USER root is dangerous. Always create a non-root user and use USER <username>.
3. Read-only filesystem. Use --read-only flag to prevent runtime modifications to the filesystem.
4. Drop capabilities. Use --cap-drop ALL and add only the specific capabilities needed (--cap-add NET_BIND_SERVICEFor example).
5. Resource limits. Set CPU and memory limits (--cpus``--memory) to prevent resource exhaustion.
6. Network isolation. Use user-defined bridge networks instead of the default bridge. Use network policies to restrict inter-container communication.
7. Secret management. Never store secrets in Docker images or environment variables. Use Docker secrets, HashiCorp Vault, or cloud secret management services.

Kubernetes adds its own security layer on top of containers.

• RBAC: Define ClusterRoles and Roles with the minimum permissions. Use RoleBindings to bind roles to specific namespaces.
• Network Policies: Default deny all ingress and egress. Explicitly allow only the traffic that is needed.
• Pod Security Standards: Enforce baseline, restricted, or privileged policies. The restricted profile requires non-root containers, read-only root filesystem, and dropped capabilities.
• Image security: Use a private registry with image signing (cosign, Notary). Scan images for vulnerabilities (Trivy, Grype, Snyk).
• Service account tokens. Disable automounting of service account tokens for pods that do not need them (automountServiceAccountToken: false).

Image scanning detects known vulnerabilities (CVEs) in container images.

• Scan during build. Integrate Trivy or Grype into CI/CD pipelines. Fail the build if critical or high vulnerabilities are found.
• Scan in the registry. Use registry-level scanning (AWS ECR, GCP Artifact Registry, Azure Container Registry) to detect vulnerabilities in images already pushed.
• Scan at runtime. Use admission controllers (OPA Gatekeeper, Kyverno) to prevent deployment of vulnerable images.

Runtime security detects anomalous behavior in running containers.

• Falco: Open-source runtime security tool that monitors system calls and detects suspicious behavior (shell spawned in a container, unexpected network connections, file system modifications).
• Seccomp: Restricts the system calls a container can make. Use the default Docker seccomp profile or create custom profiles.
• AppArmor/SELinux: Mandatory Access Control for containers. Confine the container’s access to host resources.

Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) have a different threat Model than traditional compute:

• Injection. User input passed to eval, exec, or unsanitized queries.
• Dependency vulnerabilities. Malicious or vulnerable packages in the deployment package.
• Permission issues. Overprivileged execution roles that allow access to resources beyond what the function needs.
• Event injection. Malicious payloads in trigger events (S3 object uploads, SQS messages, API Gateway requests).
• DoS via event flooding. Triggering a function millions of times, exhausting the account’s concurrency limit or running up costs.

1. Least privilege IAM role. The Lambda execution role should have only the permissions the function needs. Use specific resource ARNs, not wildcards.
2. Environment variable encryption. Encrypt sensitive environment variables using KMS.
3. VPC placement. Place the function in a VPC with security groups that restrict its outbound access. If the function does not need VPC access, keep it outside the VPC for better performance.
4. Code signing. Use Lambda code signing to ensure only trusted code is deployed.
5. Reserved concurrency. Set reserved concurrency to prevent runaway cost from DoS or bugs.
6. Input validation. Validate and sanitize all input, including event payloads.
7. Dependency scanning. Scan the deployment package for vulnerabilities before deployment.

CSPM tools continuously monitor cloud environments for misconfigurations and compliance violations.

• Asset discovery: Inventory all cloud resources across accounts and regions.
• Configuration assessment: Evaluate resources against security benchmarks (CIS, NIST, vendor best practices).
• Compliance monitoring: Track compliance with regulatory frameworks (SOC 2, PCI DSS, HIPAA, FedRAMP).
• Alerting and remediation: Alert on misconfigurations and optionally auto-remediate.

Deploying CSPM in phases provides the best results:

1. Discovery phase (week 1-2): Enable the CSPM tool and let it discover all resources across all accounts and regions. Expect a large number of findings — this is normal for a first scan.
2. Triage phase (week 2-4): Classify findings by severity and resource owner. Focus on critical and high findings first (public storage, open security groups, exposed credentials).
3. Remediation phase (week 4-8): Fix findings. Use automated remediation where possible (e.g., close unused security groups, enable encryption on storage). Manual remediation for findings that require application changes.
4. Prevention phase (ongoing): Shift left by integrating CSPM checks into CI/CD pipelines. Prevent misconfigured resources from being deployed in the first place. Use policy-as-code tools (Open Policy Agent, Checkov, tfsec) to validate IaC before apply.
5. Monitoring phase (ongoing): Configure real-time alerts for new findings. Integrate CSPM alerts with your SIEM and incident response workflow.

SOC 2 defines criteria for managing customer data based on five Trust Services Criteria:

1. Security: Protection against unauthorized access (logical and physical).
2. Availability: System availability for operation and use.
3. Processing Integrity: System processing is accurate, timely, and authorized.
4. Confidentiality: Information designated as confidential is protected.
5. Privacy: Personal information is collected, used, retained, and disposed of appropriately.

ISO 27001 is an international standard for information security management systems (ISMS). It Provides a framework for establishing, implementing, maintaining, and continually improving an ISMS. Cloud providers (AWS, Azure, GCP) are ISO 27001 certified, but the customer’s use of cloud services Must also comply.

The Federal Risk and Authorization Management Program (FedRAMP) is a US government program that Provides a standardized approach to security assessment for cloud products. Levels:

• Low Impact: Basic security controls.
• Moderate Impact: Additional controls for sensitive data.
• High Impact: Stringent controls for law enforcement, emergency services, and national security.

AWS GovCloud, Azure Government, and GCP FedRAMP programs provide compliant environments.

The General Data Protection Regulation (GDPR) applies to any organization processing personal data Of EU residents, regardless of where the organization is located. In cloud environments, GDPR Compliance requires:

• Data residency. Know where data is stored and processed. Use region-locked deployments.
• Data portability. Ensure data can be exported in a machine-readable format.
• Right to erasure. Implement processes to delete all copies of personal data on request, including backups, logs, and replicas.
• Data Processing Agreements (DPAs). Ensure DPAs are in place with the cloud provider and any sub-processors.
• Breach notification. Report data breaches to the relevant authority within 72 hours.

All three major cloud providers offer GDPR-compliant services and provide DPAs, but compliance Ultimately depends on how the customer configures and uses the services.

Cloud services default to permissive settings for convenience, not security. S3 buckets, Azure Storage accounts, and GCP Storage buckets do not default to private in all contexts. Security groups Default to allow all outbound traffic. Always review and harden defaults.

Without CloudTrail, Azure Activity Logs, or GCP Audit Logs, you have no visibility into who is doing What in your environment. After a breach, you will not be able to determine the scope or timeline of The attack.

Cross-account IAM roles with wildcard principals ("Principal": {"AWS": "*"}) can be assumed by any AWS account, not just the intended one. Always restrict trust policies to specific account ARNs.

Most cloud security focuses on ingress (blocking incoming attacks). But data exfiltration happens on Egress. Monitor and restrict outbound traffic, especially to unexpected IP ranges or regions.

Service account keys, access keys, and certificates that are never rotated or revoked. A key that Was created 3 years ago and has not been used in 2 years should be deleted.

A company uses AWS Lambda to run an API backend. The Lambda function reads from an S3 bucket and Writes to a DynamoDB table. Who is responsible for patching the operating system? Who is responsible For securing the API endpoint?

A user has two policies attached:

Policy A (Allow): s3:GetObject on arn:aws:s3:::prod-data/* Policy B (Deny): s3:GetObject on arn:aws:s3:::prod-data/secret/*

The user attempts to access s3://prod-data/secret/report.pdf. Is the access granted or denied?

An attacker discovers an SSRF vulnerability in a web application running on an EC2 instance. The Application takes a URL parameter and fetches the content. The attacker sends:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

What information can the attacker obtain? How would you prevent this with IMDSv2?

http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

A Docker container is running with the following flags:

docker run --privileged -v /:/host-root alpine

An attacker gains code execution inside the container. What can they do?

A CSPM tool reports the following finding in your AWS account:

“Security group sg-0abc1234 attached to EC2 instance i-0def5678 allows inbound SSH (TCP/22) from 0.0.0.0/0.”

What is the risk, and what is the correct remediation?

An S3 bucket policy contains the following statement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-data/*"
    }
  ]
}

Identify the security issues and provide a corrected policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::company-data", "arn:aws:s3:::company-data/*"],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/AppRole" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-data/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0abc1234"
        }
      }
    }
  ]
}

This topic covers the essential concepts and techniques related to cloud security, including key principles and practical applications.

Key concepts include:

• core concepts and definitions
• key principles and frameworks
• practical applications
• common techniques and methods
• evaluation and critical analysis

A thorough understanding of these concepts, combined with regular practice and review, is essential for mastery of this topic.

Worked examples demonstrating the application of key concepts are covered in the detailed sub-pages linked above.