Cloud Security Posture

Least privilege, network policies, security baselines — defense in depth for cloud workloads.

The Cloud Security Mindset

Cloud security is layered. No single control is sufficient. The goal: even if one layer fails, others contain the damage.

The big categories:
1. Identity & Access (who can do what)
2. Network (what can talk to what)
3. Data protection (encryption, backups)
4. Configuration (cloud resources set up safely)
5. Monitoring & response (detect and act on threats)

Done badly, the cloud is wide open. The infamous breaches — leaked S3 buckets, misconfigured Elasticsearch, exposed databases — almost always trace back to a single misconfiguration that defense in depth would have caught.

Least Privilege — IAM Done Right

The most common cloud security failure: over-permissioned identities.

The principle: every identity (user, role, service) should have only the permissions it actually needs. Nothing more.

Bad IAM:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This grants everything. If this role is compromised, the attacker has god-mode.

Good IAM:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-uploads/*"
}

Specific actions, specific resources. Limited blast radius.

Practices:
1. Start with deny. Grant specific allows.
2. Use AWS-managed policies as starting points, then narrow.
3. Use IAM Access Analyzer to find unused permissions.
4. Review IAM quarterly.
5. Avoid wildcards in production roles.
6. Service-specific roles, not shared roles.

For humans:
• AWS SSO / Identity Center for federated login
• MFA mandatory
• Time-bound elevated access (just-in-time, not standing admin rights)
• Tools: AWS IAM Identity Center + Granted, Vault, or Teleport

Network Security

Already covered VPCs, security groups, NACLs in Module 3. The security perspective:

Default deny. Security groups should be minimal.

Common security group patterns:

Web tier:
  Ingress:  80, 443 from 0.0.0.0/0
            22 from bastion-sg
  Egress:   all (default)

App tier:
  Ingress:  3000 from web-tier-sg
            22 from bastion-sg

Database tier:
  Ingress:  5432 from app-tier-sg
            (no SSH — accessed via app tier or via Session Manager)
  Egress:   none (databases shouldn't make outbound calls)

Defense in depth:
• Security groups (instance-level, stateful, allow-only)
• NACLs (subnet-level, stateless, allow or deny)
• Network policies in K8s (Pod-level)
• Service mesh policies (application-level)

VPC isolation:
• Production in its own VPC, separate from staging/dev
• In multi-account setups, separate accounts entirely
• Connect via Transit Gateway or peering only when needed

Bastion hosts:
• Production servers don't accept SSH from the internet
• Engineers SSH to a hardened bastion, then forward
• OR use cloud-native session managers: AWS Session Manager (no SSH at all), Cloudflare Access, Tailscale, Teleport

The 2026 trend: kill the bastion entirely. Session Manager and equivalents let engineers shell into instances via the cloud's API — audited, no inbound network access required.

Data Protection

Encryption at rest:
• EBS volumes — encrypt by default (set the account-level setting)
• S3 buckets — enable default encryption with SSE-S3 or SSE-KMS
• RDS — enable encryption when creating the instance
• Snapshots — also encrypted

Encryption in transit:
• TLS for all external traffic (obvious)
• TLS for internal traffic too (compliance often requires it)
• Service mesh automates mTLS between services
• AWS PrivateLink, GCP Private Service Connect for private connections

Key management:
• AWS KMS, GCP KMS — cloud-native. Customer Master Keys (CMKs).
• Customer Managed Keys vs AWS Managed Keys — CMKs let you control rotation, deletion, access policies.
• KMS access is itself an IAM-controlled action. Lock it down.

Backups & disaster recovery:
• Automated backups for everything stateful
• Test restores regularly
• Cross-region copies for critical data
• Some sensitive data may require offline / air-gapped backups for compliance

Configuration Auditing

The cloud has thousands of dials. Misconfigurations cause most breaches.

Tools that audit your cloud configuration:
• AWS Config — records resource state, evaluates against rules
• AWS Security Hub — aggregates findings
• GCP Security Command Center — equivalent
• Azure Security Center
• Open source: Prowler, ScoutSuite, Cloudsplaining

Standards to check against:
• CIS Benchmarks — Center for Internet Security best practices
• AWS Well-Architected Framework — security pillar
• PCI-DSS, HIPAA, SOC 2 — if relevant

Common misconfigurations they catch:
• Public S3 buckets
• EBS volumes not encrypted
• Security groups open to 0.0.0.0/0 on sensitive ports
• Root account without MFA
• IAM policies with wildcards
• Logging not enabled (CloudTrail off, VPC Flow Logs off)
• RDS publicly accessible

Set this up early. Findings start at hundreds and decrease as you fix them. Track the count over time as a security KPI.

Threat Detection & Compliance

Configuration audits catch what's wrong with your setup. Threat detection catches active attacks.

AWS GuardDuty — continuous threat detection looking at:
• CloudTrail logs (API call patterns)
• VPC Flow Logs (network traffic)
• DNS logs (queries to known-bad domains)

What it catches:
• Cryptocurrency mining (unusual EC2 spending)
• Compromised credentials (logins from unexpected locations)
• EC2 instances exfiltrating data
• Reconnaissance activity (port scans)

Beyond cloud-native:
• Wiz, Lacework, Sysdig, Orca — unified Cloud-Native Application Protection Platforms (CNAPP)
• Open source: Falco for K8s runtime detection

Compliance frameworks make security explicit and auditable. The big ones:
• SOC 2 — security, availability, confidentiality. Most B2B SaaS gets it.
• PCI-DSS — handling credit card data.
• HIPAA — US health data.
• GDPR — EU privacy.
• ISO 27001 — international info security.

Tools that help:
• Vanta, Drata, Secureframe — automate evidence collection

Real talk:
• Compliance is the floor, not the ceiling.
• A SOC 2-certified company can still be insecure.
• DO aim for compliance if customers require it.
• DON'T mistake compliance certifications for actual security.

The next lessons cover deployment strategies, incidents, disaster recovery, and FinOps — completing the operational picture.