Cloud Security Best Practices: Secure AWS, Azure & GCP

The Shared Responsibility Model

Cloud security starts with understanding who protects what. The shared responsibility model divides duties between provider and customer:

Provider secures: Physical data centers, network infrastructure, hypervisor, global services (DNS, CDN).

You secure: Data, identity and access management, application-level configuration, OS patching (for IaaS), encryption.

Misunderstanding this model causes the majority of cloud breaches. The provider doesn't protect your S3 buckets — you do.

IAM Best Practices

Identity and Access Management is your first line of defense.

Least Privilege — Grant only the permissions needed for a specific task. A web server doesn't need full database admin access. Use IAM policies with explicit deny-by-default.

Multi-Factor Authentication — Enable MFA on all human accounts, especially root and admin. Hardware keys (YubiKey) beat SMS-based MFA.

Service Accounts — Rotate credentials regularly. Use short-lived tokens instead of long-lived keys. AWS STS, Azure Managed Identity, and GCP Service Accounts all support this.

Role-Based Access — Create roles for job functions (developer, auditor, admin) instead of assigning permissions to individuals.

VPC Security

Network Segmentation — Isolate workloads in separate subnets. Production, staging, and development should never share a VPC without strict controls.

Security Groups — Act as virtual firewalls. Deny all inbound by default, then allow only necessary traffic. Never open port 22 (SSH) to 0.0.0.0/0.

Private Subnets — Place databases and internal services in private subnets with no internet gateway. Access them through bastion hosts or VPNs.

Flow Logs — Enable VPC flow logs to capture all network traffic. Store them in a centralized logging account for analysis.

Encryption

At Rest — Encrypt all storage volumes, databases, and object storage. Use customer-managed keys (CMK) for sensitive data instead of provider-managed defaults.

In Transit — Enforce TLS 1.2+ everywhere. Use ACM (AWS), Key Vault (Azure), or Managed SSL (GCP) for certificate management.

Key Management — Never hardcode keys in application code. Use cloud KMS services. Rotate keys on a defined schedule.

Logging and Monitoring

CloudTrail / Activity Log / Audit Log — Enable API logging across all accounts. Store logs in a dedicated, immutable account.

GuardDuty / Defender for Cloud / Security Command Center — Enable cloud-native threat detection. These services catch anomalous behavior automatically.

Centralized SIEM — Forward cloud logs to a SIEM (Splunk, ELK, Sentinel) for correlation with on-premises data.

Alerting — Set up alerts for high-severity events: root login, security group changes, IAM modifications, data exfiltration patterns.

Common Cloud Misconfigurations

1. Public S3/Blob/GCS buckets containing sensitive data
2. Overly permissive IAM policies (* actions on * resources)
3. SSH/RDP open to the internet
4. Unencrypted EBS/Disk volumes
5. Missing MFA on root accounts
6. Default VPC used for production workloads
7. No logging enabled
8. Hardcoded credentials in code repositories

Compliance Frameworks

Map your cloud security controls to relevant frameworks:

• SOC 2 — Trust service criteria for service organizations
• ISO 27001 — Information security management
• PCI DSS — Payment card data requirements
• HIPAA — Healthcare data protection
• CIS Benchmarks — Vendor-specific configuration hardening guides

Hands-On Practice

Build a security lab in your cloud provider's free tier:

1. Set up a VPC with public and private subnets
2. Deploy an EC2/VM in the public subnet as a bastion
3. Place a database in the private subnet
4. Configure security groups to restrict traffic
5. Enable logging and monitoring
6. Attempt to access the database from outside — verify it fails

This exercise teaches fundamental cloud security architecture that applies across all three major providers.