Cloud Fundamentals for Security Engineers

TL;DR: Cloud security is now a core skill for security engineers. Understanding the shared responsibility model, identity as the new perimeter, and common cloud misconfigurations is essential for interviews and daily work. AWS is the market leader, so we start there.

Table of Contents

Quick Reference

AWS Security Services

Essential AWS CLI Commands

# Identity check
aws sts get-caller-identity

# List S3 buckets
aws s3 ls

# List IAM users
aws iam list-users

# Check bucket policy
aws s3api get-bucket-policy --bucket bucket-name

# Get CloudTrail events
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin

# List EC2 security groups
aws ec2 describe-security-groups

# Check for public snapshots
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?Public==`true`]'

Shared Responsibility Model

The Foundation of Cloud Security

The shared responsibility model defines who is responsible for what security:

┌─────────────────────────────────────────────────────────────┐
│                    CUSTOMER RESPONSIBILITY                   │
│         "Security IN the Cloud"                             │
├─────────────────────────────────────────────────────────────┤
│  • Customer Data                                            │
│  • Platform, Applications, Identity & Access Management     │
│  • Operating System, Network & Firewall Configuration       │
│  • Client-side Data Encryption                              │
│  • Server-side Encryption (file system and/or data)         │
│  • Network Traffic Protection (encryption, integrity)       │
├─────────────────────────────────────────────────────────────┤
│                      AWS RESPONSIBILITY                      │
│         "Security OF the Cloud"                             │
├─────────────────────────────────────────────────────────────┤
│  • Hardware/AWS Global Infrastructure                       │
│  • Regions, Availability Zones, Edge Locations              │
│  • Compute, Storage, Database, Networking (physical)        │
│  • Software (hypervisor, managed services)                  │
└─────────────────────────────────────────────────────────────┘

Responsibility Changes by Service Type

Security Implications

What AWS Handles:

• Physical security of data centers
• Hardware patching and maintenance
• Network infrastructure
• Hypervisor security
• Managed service patching (RDS, Lambda runtime)

What You Handle:

• IAM policies and access control
• Security group configurations
• Data encryption choices
• Application security
• OS patching (for EC2)
• Logging and monitoring setup

Interview Insight: “Explain the shared responsibility model” is a guaranteed cloud security interview question. Know it cold.

Core AWS Services Overview

Compute Services

EC2 (Elastic Compute Cloud)

Virtual machines in the cloud.

Security Considerations:

┌─────────────────────────────────────────┐
│              EC2 Security               │
├─────────────────────────────────────────┤
│ Security Groups (stateful firewall)     │
│ • Control inbound/outbound traffic      │
│ • DENY by default                       │
│ • Common mistake: 0.0.0.0/0 on SSH      │
├─────────────────────────────────────────┤
│ IAM Instance Profiles                   │
│ • Attach IAM role to EC2                │
│ • No hardcoded credentials              │
│ • Principle of least privilege          │
├─────────────────────────────────────────┤
│ AMIs (Amazon Machine Images)            │
│ • Base images can contain secrets       │
│ • Use hardened, approved AMIs           │
│ • Scan for vulnerabilities              │
├─────────────────────────────────────────┤
│ Metadata Service (IMDS)                 │
│ • http://169.254.169.254                │
│ • SSRF target for credential theft      │
│ • Use IMDSv2 (requires token)           │
└─────────────────────────────────────────┘

Key Security Commands:

# Check security groups for wide open access
aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]]'

# Check if IMDSv2 is required
aws ec2 describe-instances --query 'Reservations[].Instances[].{ID:InstanceId,IMDS:MetadataOptions.HttpTokens}'

Lambda (Serverless)

Run code without managing servers.

Security Considerations:

• Function IAM role permissions (over-permissioned is common)
• Environment variables (may contain secrets)
• VPC configuration (if accessing internal resources)
• Dependency vulnerabilities
• Cold start credential caching

Storage Services

S3 (Simple Storage Service)

Object storage with powerful access controls.

Security Checklist:

## S3 Security Checklist
- [ ] Block Public Access enabled at account level
- [ ] Bucket policies follow least privilege
- [ ] No wildcard (*) principals without conditions
- [ ] Server-side encryption enabled (SSE-S3 or SSE-KMS)
- [ ] Versioning enabled for critical buckets
- [ ] Access logging enabled
- [ ] Object Lock for compliance (if needed)
- [ ] VPC endpoints for private access

Common Misconfigurations:

// BAD: Public read access
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

// BETTER: Restrict to specific accounts/roles
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/MyAppRole"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Security Commands:

# Find public buckets
aws s3api get-bucket-acl --bucket bucket-name
aws s3api get-bucket-policy-status --bucket bucket-name

# Check encryption
aws s3api get-bucket-encryption --bucket bucket-name

# Check public access block
aws s3api get-public-access-block --bucket bucket-name

Networking Services

VPC (Virtual Private Cloud)

Isolated network environment.

┌─────────────────────────────────────────────────────────────┐
│                         VPC                                  │
│  ┌─────────────────────┐    ┌─────────────────────┐        │
│  │   Public Subnet     │    │   Private Subnet    │        │
│  │   10.0.1.0/24       │    │   10.0.2.0/24       │        │
│  │                     │    │                     │        │
│  │   ┌───────────┐     │    │   ┌───────────┐     │        │
│  │   │  Web EC2  │     │    │   │  DB EC2   │     │        │
│  │   │  (public) │     │    │   │ (private) │     │        │
│  │   └───────────┘     │    │   └───────────┘     │        │
│  │         │           │    │         │           │        │
│  │   ┌─────┴─────┐     │    │   ┌─────┴─────┐     │        │
│  │   │   IGW     │     │    │   │   NAT     │     │        │
│  │   └───────────┘     │    │   └───────────┘     │        │
│  └─────────────────────┘    └─────────────────────┘        │
└─────────────────────────────────────────────────────────────┘

Security Concepts:

• Security Groups: Instance-level stateful firewall
• NACLs: Subnet-level stateless firewall
• VPC Flow Logs: Network traffic logging
• VPC Endpoints: Private access to AWS services
• Transit Gateway: Connect multiple VPCs

Database Services

RDS (Relational Database Service)

Managed databases (MySQL, PostgreSQL, etc.)

Security Best Practices:

• Never publicly accessible (use private subnets)
• Security groups restrict to application tier only
• Encryption at rest enabled
• SSL/TLS for connections
• IAM database authentication where possible
• Automated backups with encryption

Identity as the New Perimeter

Why Identity Matters Most in Cloud

In traditional networks, the perimeter was the firewall. In cloud:

Traditional:                    Cloud:

┌─────────────┐               ┌─────────────┐
│  Firewall   │               │     IAM     │
│  (Network)  │       vs      │ (Identity)  │
│             │               │             │
└─────────────┘               └─────────────┘
     │                              │
     │                              │
"If you're inside,          "Every request is
 you're trusted"             authenticated and
                             authorized"

Key Principle: In cloud, assume the network is compromised. Identity and authorization are your primary controls.

IAM Fundamentals

Principals (Who)

Policies (What They Can Do)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Read",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

Policy Evaluation Logic:

1. Explicit Deny? → DENY
2. Explicit Allow? → Check SCPs, Permission Boundaries
3. Neither? → Implicit DENY (default)

Result = Intersection of:
- Identity Policy (attached to user/role)
- Resource Policy (attached to resource)
- SCPs (Organization level)
- Permission Boundaries (limits for role)

IAM Best Practices

## IAM Security Checklist

### Root Account
- [ ] MFA enabled on root account
- [ ] Root access keys deleted
- [ ] Root account not used for daily operations
- [ ] Billing alerts configured

### Users and Authentication
- [ ] MFA required for all human users
- [ ] Password policy enforced (complexity, rotation)
- [ ] No shared credentials
- [ ] Access keys rotated regularly
- [ ] Unused credentials disabled

### Roles and Policies
- [ ] Prefer roles over users for services
- [ ] Least privilege policies
- [ ] No wildcard (*) actions without resource constraints
- [ ] Use AWS managed policies where appropriate
- [ ] Custom policies reviewed for over-permissions

### Monitoring
- [ ] CloudTrail enabled for IAM events
- [ ] Alerts for root login
- [ ] Access Advisor reviewed regularly
- [ ] Credential Report generated monthly

Common IAM Mistakes

Basic Cloud Logging

CloudTrail - The Audit Log

CloudTrail records API calls in your AWS account.

What It Captures:

• Who made the request (identity)
• What they requested (API call)
• When it happened (timestamp)
• From where (source IP)
• Response (success/failure)

Example CloudTrail Event:

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/alice",
    "accountId": "123456789012",
    "userName": "alice"
  },
  "eventTime": "2024-01-15T10:30:00Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "198.51.100.1",
  "requestParameters": {
    "bucketName": "sensitive-data",
    "key": "customers.csv"
  },
  "responseElements": null,
  "errorCode": null
}

CloudTrail Best Practices:

- [ ] Enabled in ALL regions
- [ ] Logging to secure S3 bucket
- [ ] Log file validation enabled
- [ ] S3 bucket has versioning
- [ ] S3 bucket denies public access
- [ ] Integrated with CloudWatch for alerts
- [ ] Retained for at least 1 year (compliance)

Critical Events to Monitor

CloudWatch Alarm for Root Login:

{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

VPC Flow Logs

Network traffic logging for VPCs.

Format: version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status

Example:
2 123456789012 eni-abc123 10.0.1.5 10.0.2.10 443 49152 6 25 5000 1620140761 1620140821 ACCEPT OK

Use Cases:

• Detect unusual traffic patterns
• Investigate security incidents
• Verify security group effectiveness
• Compliance auditing

Logging Architecture

┌─────────────────────────────────────────────────────────────┐
│                    AWS Account                               │
│                                                             │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐            │
│   │CloudTrail│    │VPC Flow  │    │ S3 Access│            │
│   │  Logs    │    │  Logs    │    │   Logs   │            │
│   └────┬─────┘    └────┬─────┘    └────┬─────┘            │
│        │               │               │                   │
│        └───────────────┼───────────────┘                   │
│                        │                                   │
│                        ▼                                   │
│              ┌─────────────────┐                          │
│              │   S3 Bucket     │                          │
│              │ (centralized)   │                          │
│              └────────┬────────┘                          │
│                       │                                   │
│        ┌──────────────┼──────────────┐                   │
│        ▼              ▼              ▼                   │
│   ┌─────────┐   ┌──────────┐   ┌──────────┐             │
│   │CloudWatch│   │  Athena  │   │   SIEM   │             │
│   │ Alarms  │   │ (Query)  │   │(External)│             │
│   └─────────┘   └──────────┘   └──────────┘             │
└─────────────────────────────────────────────────────────────┘

Common Cloud Security Mistakes

Top 10 AWS Security Mistakes

Real-World Breach Examples

Capital One (2019)

What Happened:

• SSRF vulnerability in web application
• Accessed EC2 metadata service (IMDSv1)
• Retrieved IAM role credentials
• Accessed S3 buckets with sensitive data
• 100+ million customer records exposed

Prevention:

• Use IMDSv2 (requires token)
• WAF rules for SSRF
• Least privilege IAM roles
• S3 bucket monitoring

Twitch (2021)

What Happened:

• Server misconfiguration exposed internal Git
• Included AWS credentials in code
• Full source code leaked

Prevention:

• Secret scanning in repositories
• No credentials in code
• Use secrets management
• Regular security audits

Security Misconfiguration Patterns

Common Pattern: "It works, ship it!"
                        │
                        ▼
┌─────────────────────────────────────────┐
│  Developer grants full permissions      │
│  "Action": "*", "Resource": "*"         │
├─────────────────────────────────────────┤
│  Security group opened to 0.0.0.0/0     │
│  "for testing"                          │
├─────────────────────────────────────────┤
│  S3 bucket made public for quick access │
│  "just temporarily"                     │
├─────────────────────────────────────────┤
│  Credentials stored in environment vars │
│  in plain text                          │
└─────────────────────────────────────────┘
                        │
                        ▼
              Security Incident

Hands-On Lab

Lab: Secure a Basic AWS Account

Objective: Apply fundamental security controls to a new AWS account.

Task 1: IAM Security

# Check for root access keys (should be none)
aws iam get-account-summary | grep AccountAccessKeysPresent

# Create IAM user with MFA
aws iam create-user --user-name security-admin
aws iam create-login-profile --user-name security-admin --password "TempP@ssw0rd!" --password-reset-required

# Enable virtual MFA (do via console for QR code)

# Apply password policy
aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --max-password-age 90 \
  --password-reuse-prevention 12

Task 2: CloudTrail Setup

# Create trail bucket
aws s3 mb s3://my-cloudtrail-logs-$(aws sts get-caller-identity --query Account --output text)

# Enable CloudTrail in all regions
aws cloudtrail create-trail \
  --name security-trail \
  --s3-bucket-name my-cloudtrail-logs-$(aws sts get-caller-identity --query Account --output text) \
  --is-multi-region-trail \
  --enable-log-file-validation

# Start logging
aws cloudtrail start-logging --name security-trail

Task 3: S3 Security

# Block public access at account level
aws s3control put-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Verify
aws s3control get-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text)

Task 4: Security Audit

# Generate credential report
aws iam generate-credential-report
sleep 10
aws iam get-credential-report --query Content --output text | base64 -d

# Check for overly permissive policies
aws iam list-policies --scope Local --query 'Policies[*].PolicyName'

# Find public S3 buckets
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  echo "Checking $bucket"
  aws s3api get-bucket-policy-status --bucket $bucket 2>/dev/null || echo "  No policy"
done

Interview Questions & Answers

Basic Questions

Q1: Explain the AWS shared responsibility model.

Strong Answer: “The shared responsibility model divides security duties between AWS and the customer.

AWS is responsible for security OF the cloud:

• Physical security of data centers
• Hardware and infrastructure
• Hypervisor and managed service internals
• Network infrastructure

Customers are responsible for security IN the cloud:

• IAM configurations and access control
• Data encryption and protection
• Security group and network configs
• Operating system patching (for EC2)
• Application security

The division shifts based on service type - with EC2 (IaaS) you manage more; with Lambda (serverless) AWS manages more. But IAM and data protection are always your responsibility.”

Q2: What makes identity ‘the new perimeter’ in cloud security?

Strong Answer: “In traditional on-premises environments, we relied on network perimeter defenses - firewalls, IDS, DMZs. If you were on the internal network, you had implicit trust.

In cloud environments, this model breaks down because:

1. Resources are accessible over the internet
2. Networks are software-defined and can be misconfigured
3. Workloads span multiple environments
4. SSRF and credential theft can bypass network controls

Identity becomes the perimeter because every API call requires authentication and authorization. IAM controls WHO can do WHAT to WHICH resources. If an attacker compromises credentials with broad permissions, network security is irrelevant - they have legitimate access.

This is why we focus on least privilege IAM, MFA, short-lived credentials, and continuous monitoring of identity-based activity.”

Q3: How would you secure an S3 bucket containing sensitive data?

Strong Answer: “I’d implement multiple layers:

Access Control:

• Block Public Access at account and bucket level
• Bucket policy with explicit principal restrictions (no wildcards)
• Use VPC endpoints for private access from applications

Encryption:

• Server-side encryption (SSE-KMS for audit trail)
• Bucket policy requiring encryption

Monitoring:

• S3 access logging enabled
• CloudTrail data events for object-level logging
• GuardDuty for anomaly detection

Additional Controls:

• Versioning to protect against deletion
• Object Lock for compliance (if needed)
• Cross-account access only via roles, not bucket policies

I’d also regularly audit with Access Analyzer to detect unintended external access.”

Intermediate Questions

Q4: Walk me through how you’d investigate a potential AWS credential compromise.

Strong Answer: “I’d follow a structured approach:

1. Identify Scope:

• Which credential? (Access key, role, user)
• When was it potentially exposed?

2. Immediate Containment:

• Deactivate the compromised access keys
• Revoke active sessions if possible (for roles)
• Don’t delete yet - preserve evidence

3. Investigate with CloudTrail:

# Find all actions by compromised credential
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... \
  --start-time 2024-01-01T00:00:00Z

4. Look for:

• Unusual API calls (CreateUser, CreateAccessKey)
• Access from unusual IPs or regions
• Resource creation (EC2, Lambda for crypto mining)
• Data access (S3 GetObject)
• Privilege escalation attempts

5. Remediate:

• Delete compromised credentials
• Rotate any potentially exposed secrets
• Remove any attacker persistence (users, keys, roles)
• Review and strengthen IAM policies

6. Document and improve detection capabilities.”

Q5: What’s the difference between Security Groups and NACLs?

Strong Answer: “Both are network security controls but operate differently:

Security Groups:

• Instance-level (attached to ENI)
• Stateful - return traffic automatically allowed
• Allow rules only (implicit deny)
• All rules evaluated before decision
• Better for application-level controls

Network ACLs:

• Subnet-level
• Stateless - must explicitly allow return traffic
• Allow and deny rules
• Rules processed in order (lowest number first)
• Better for broad subnet-level controls

In practice, I use Security Groups as the primary control for application access (e.g., only web tier can access app tier) and NACLs for broader subnet isolation or blocking known malicious IPs.

A common mistake is relying only on Security Groups and having no NACL rules, missing a defense-in-depth opportunity.”

Advanced Questions

Q6: How would you design a secure multi-account AWS architecture?

Strong Answer: “I’d implement AWS Organizations with a multi-account strategy:

Account Structure:

Management Account (billing, SCPs only)
  ├── Security OU
  │   ├── Log Archive Account (centralized logs)
  │   ├── Security Tooling Account (GuardDuty, Security Hub)
  │   └── Audit Account (read-only cross-account access)
  ├── Workloads OU
  │   ├── Production OU
  │   │   ├── Prod Account A
  │   │   └── Prod Account B
  │   └── Non-Production OU
  │       ├── Dev Account
  │       └── Staging Account
  └── Sandbox OU (experimentation)

Security Controls:

• SCPs to enforce guardrails (no disabling CloudTrail, require encryption)
• Cross-account roles for admin access (no IAM users in workload accounts)
• Centralized CloudTrail to Log Archive account
• GuardDuty delegated admin in Security account
• VPC sharing or Transit Gateway for connectivity

Key Benefits:

• Blast radius containment (compromise limited to one account)
• Clear separation of duties
• Centralized security visibility
• Consistent policy enforcement”

Q7: How do you approach cloud security posture management at scale?

Strong Answer: “I’d implement a continuous security assessment program:

Tooling:

• AWS Security Hub as the aggregation point
• AWS Config for resource compliance
• GuardDuty for threat detection
• IAM Access Analyzer for access review
• Custom Lambda functions for specific checks

Process:

1. Define security baselines (CIS Benchmarks, custom standards)
2. Implement as Config Rules
3. Aggregate findings in Security Hub
4. Prioritize by severity and resource criticality
5. Automate remediation where safe
6. Track metrics (findings over time, MTTR)

Key Metrics:

• % of resources compliant
• Critical/high findings count
• Mean time to remediate
• Coverage (% of accounts monitored)

The goal is continuous visibility and rapid response, not point-in-time assessments.”

Glossary

What’s Next

Continue building your cloud security expertise:

1. Cloud IAM Misconfigurations - Deep dive into IAM attack paths
2. Securing CI/CD Pipelines - Cloud-native security
3. Detection Engineering - Build cloud detections

Questions or feedback? Open an issue on GitHub.