Cloud Security Engineer Training

The shared responsibility model defines which security tasks the cloud provider handles and which fall to you. IaaS (EC2/Azure VMs): provider owns hardware, hypervisor, global network. You own: OS patching, firewall rules, application code, data. PaaS (RDS/App Service): provider takes the OS and runtime too. You own: app code and data. SaaS (Microsoft 365): provider handles almost everything. You own: user management, access controls, data classification.

Most cloud breaches do not exploit provider infrastructure — they exploit customer misconfigurations. S3 buckets left public, IAM roles with wildcard permissions, unencrypted databases, open security groups. These are your responsibility, not the provider's.

The most important cloud architecture security principle is account isolation. Workloads in separate AWS accounts cannot interact unless explicitly configured to do so. A compromised credential in dev cannot reach production if they are in separate accounts. Running everything in one account means one compromised IAM key can affect everything.

AWS Organizations + Service Control Policies (SCPs) enforce security guardrails across all accounts — regardless of IAM permissions. An SCP that denies CloudTrail deletion cannot be bypassed even by an account administrator. This is the cloud equivalent of a hardware security control.

Cloud attacks rarely use malware. An attacker with valid IAM credentials uses legitimate AWS APIs to enumerate, escalate privileges, persist, and exfiltrate. No exploit. No EDR alert. The attack logs like a legitimate user — just with unusual timing, scope, or volume. This is why detection in cloud is API-log-based, not endpoint-based.

AWS IAM policy evaluation order: (1) Explicit Deny wins everywhere, always. (2) SCPs — if an SCP does not allow the action, it is denied regardless of IAM. (3) Resource-based policies. (4) Identity-based policies. (5) Permission boundaries. (6) Session policies. (7) Default deny — if nothing allows, it is denied.

The most dangerous IAM patterns: Wildcard actions (Action: "*") — grants everything. Wildcard resources (Resource: "*") — grants access to all resources. iam:PassRole + ec2:RunInstances — classic privilege escalation path. iam:CreateAccessKey — can create new credentials for any user including admins. Overpermissive trust policies — roles that any account principal can assume.

Long-lived credentials (AWS access keys, GCP service account keys, Azure service principal secrets) are the most common source of cloud credential theft. They end up in Git repos, CI/CD logs, Lambda environment variables, and developer laptops. The solution: Workload Identity Federation — temporary credentials issued automatically, rotated hourly, and tied to the workload's identity.

AWS: IAM Roles — EC2 instance profiles, ECS task roles, Lambda execution roles, IRSA for Kubernetes. No access keys needed. Azure: Managed Identities — the resource has an identity, no credentials stored anywhere. GCP: Workload Identity Federation, attached service accounts. The rule: if a workload needs cloud API access, use federation. If a human needs API access, use short-lived SSO credentials. Static credentials should not exist in production.

Security Groups are stateful, allow-only controls applied to individual resources. NACLs are stateless, allow+deny controls applied to subnets. Use Security Groups for application-level access control (RDS only accepts traffic from the application-tier SG). Use NACLs for coarse subnet-level blocks (deny all Tor exit node IPs at the subnet perimeter).

Critical rule: Reference security groups in rules — never IP ranges for internal traffic. Allowing traffic from the LB security group means new LBs automatically get access and removed LBs automatically lose it. Allowing by IP range means any instance in that range can reach your database — including compromised ones.

A WAF inspects HTTP/HTTPS at Layer 7 and blocks requests matching attack patterns before they reach your application. AWS WAF, Azure Front Door WAF, and GCP Cloud Armor are all managed — you configure rule groups, they handle signatures. The critical work: selecting rule groups, tuning sensitivity to reduce false positives, writing custom rules for your specific application, and ensuring attackers cannot bypass the WAF by targeting your origin directly.

S3 is involved in more cloud data breaches than any other service. The access control model has six layers: account-level public access block, bucket-level block, bucket policy, ACLs (deprecated), IAM policies, and VPC endpoint policies. Any misconfigured layer exposes data. The most dangerous combination: disabled account-level block + bucket policy with Principal:* = publicly accessible to the entire internet.

Encryption is only as strong as key management. Encrypting data with a key stored alongside the data is no protection. AWS KMS stores keys in HSMs physically separate from the data they protect. Every encrypt/decrypt operation is logged in CloudTrail — you have a complete record of who accessed what data and when. This is the audit capability that PCI DSS, HIPAA, and most enterprise compliance frameworks require.

Secrets Manager solves the application credential problem — database passwords, API keys, OAuth secrets — by letting applications call the API at runtime instead of storing secrets in code or environment variables. Secrets are automatically rotated on a schedule (Secrets Manager can rotate RDS passwords automatically every 30 days). Applications always have the current credential without any human intervention.

CloudTrail logs every AWS API call: who made it, what service, what action, what resource, when, from where, and whether it succeeded. It is the single most important evidence source for cloud investigation. Management events are free and on by default. Data events (S3 GetObject, Lambda invocations) cost extra but are required for detecting data exfiltration.

Cloud IR differs from on-premise IR in three critical ways: containment is API-based (deny-all SCP, revoke IAM credentials, modify security groups — all in seconds, at scale, with no physical access), evidence is in cloud logs that can be deleted by the attacker (preserve CloudTrail to immutable S3 with Object Lock before the attacker disables logging), and the blast radius may span multiple regions or accounts that the attacker created during the incident.

Infrastructure as Code lets you scan every infrastructure change before it is deployed. A security group opened to 0.0.0.0/0, an S3 bucket without Block Public Access, a KMS key without rotation — all catchable in a CI/CD pipeline before terraform apply runs. The shift-left principle: the earlier in the development cycle you catch a vulnerability, the cheaper it is to fix. A misconfiguration caught in a PR review costs minutes. The same misconfiguration found post-breach costs millions.

Cloud compliance means demonstrating that your environment meets applicable regulatory requirements — PCI DSS for payments, HIPAA for health data, GDPR for EU personal data, RBI IT Framework for Indian banking, and SOC 2 for SaaS products sold to enterprises. The good news: build a strong technical baseline and most frameworks are largely satisfied. The controls overlap significantly.