Lab 05: Cloud Security Architecture
Time: 50 minutes | Level: Architect | Docker: docker run -it --rm zchencow/innozverse-cybersec:latest bash
Objectives
Understand CSPM, CWPP, and CASB in cloud security
Apply the shared responsibility model
Analyse IAM policies for least-privilege compliance
Evaluate CIS Benchmarks for cloud
Step 1: Shared Responsibility Model
Physical infrastructure
✅ Provider
Virtualisation/Hypervisor
✅ Provider
OS (managed services)
✅ Provider (e.g., RDS)
OS (IaaS VMs)
✅ Customer
Middleware/Runtime
✅ Customer
Application code
✅ Customer
Data
✅ Customer
IAM / Access Control
✅ Customer
Network configuration
Shared
Shared
Encryption in transit/rest
Shared
Shared
💡 The most common cloud breaches involve customer-managed layers: misconfigured S3 buckets, overly permissive IAM roles, and exposed management ports. The provider's infrastructure is rarely compromised.
Step 2: CSPM / CWPP / CASB
Cloud Security Posture Management (CSPM):
Continuously scans cloud resources for misconfigurations
Checks against CIS Benchmarks, NIST, PCI DSS
Examples: Prisma Cloud, AWS Security Hub, Wiz
Cloud Workload Protection Platform (CWPP):
Protects cloud workloads at runtime
Vulnerability scanning, EDR for cloud instances, container security
Examples: CrowdStrike Falcon Cloud, Lacework, Aqua Security
Cloud Access Security Broker (CASB):
Visibility and control over SaaS applications
Shadow IT discovery, DLP for cloud, UEBA
Examples: Microsoft Defender for Cloud Apps, Netskope, McAfee MVISION
Step 3: CIS Benchmarks for Cloud
CIS AWS Foundations Benchmark (Level 1 critical controls):
1.1
Avoid use of root account
CloudTrail + CloudWatch alarm
1.4
MFA on root account
IAM credential report
1.14
Hardware MFA for root
IAM MFA device
2.1.2
S3 buckets not publicly accessible
S3 Block Public Access
2.2.1
EBS volumes encrypted
EC2 API check
3.1
CloudTrail enabled in all regions
CloudTrail config
3.4
CloudTrail log file validation
CloudTrail setting
4.1
No unrestricted SSH (0.0.0.0/0:22)
Security Group rules
4.2
No unrestricted RDP (0.0.0.0/0:3389)
Security Group rules
Step 4: IAM Least-Privilege Analyser
📸 Verified Output:
Step 5: IAM Design Principles
Principle of Least Privilege (PoLP):
IAM at scale — service accounts:
Use IAM roles (not access keys) for EC2/Lambda/ECS workloads
Rotate access keys every 90 days
Use AWS Organizations SCPs to enforce guardrails across all accounts
Enable AWS IAM Access Analyzer to detect external access
Permission boundary pattern:
Step 6: Cloud Network Security Architecture
Multi-account architecture (AWS Landing Zone):
VPC security layers:
💡 Security groups are stateful; NACLs are stateless. Use security groups for application-level rules; use NACLs as an additional layer for subnet-level blocking (e.g., block known-malicious CIDRs).
Step 7: Cloud Security Monitoring
Key log sources for cloud SIEM:
AWS
CloudTrail
API calls, IAM changes, console logins
AWS
VPC Flow Logs
Network traffic accept/reject
AWS
GuardDuty
Threat detection (crypto mining, C2, anomalies)
AWS
Config
Configuration changes, compliance drift
Azure
Azure AD Audit
Login events, role changes
GCP
Cloud Audit Logs
Admin activity, data access
Critical CloudTrail alerts:
Root account login
MFA disabled
IAM policy change
S3 bucket ACL change to public
CloudTrail stopped/deleted
Console login from new country
Step 8: Capstone — Multi-Cloud Security Architecture
Scenario: Financial services firm running AWS (primary) + Azure (M365/Entra ID)
Summary
Shared Responsibility
Cloud secures infrastructure; customer secures data/IAM/config
CSPM
Continuous posture scanning against CIS/NIST benchmarks
CWPP
Runtime protection for cloud workloads
CASB
SaaS visibility, shadow IT, DLP
IAM PoLP
No wildcards; use conditions; roles not keys
Multi-account
Separate accounts per environment/function
Monitoring
CloudTrail + GuardDuty + Config = cloud security telemetry
Last updated
