Cloud Security Guide
IAM Best Practices
- Never use root account for daily tasks; create IAM users/roles
- Enable MFA on all human accounts, especially root
- Apply least privilege: grant minimum permissions required
- Use roles for EC2/Lambda/containers, not access keys
- Rotate access keys every 90 days; delete unused ones
- Use AWS SCPs / Azure Policy to enforce org-wide guardrails
- Review and audit permissions quarterly
- Use permission boundaries for delegated administration
IAM Policy Example (Least Privilege S3)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-specific-bucket",
"arn:aws:s3:::my-specific-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}
Network Security
| Control | Purpose | Best Practice |
|---|---|---|
| Security Groups | Instance-level firewall (stateful) | Whitelist only needed ports/sources; no 0.0.0.0/0 for SSH/RDP |
| NACLs | Subnet-level firewall (stateless) | Additional defense layer; block known bad IP ranges |
| VPC | Isolated network environment | Separate VPCs per environment (prod/staging/dev) |
| Private Subnets | No direct internet access | Place databases and internal services in private subnets |
| NAT Gateway | Outbound internet for private subnets | Use NAT for outbound; never expose internal services directly |
| VPC Flow Logs | Network traffic logging | Enable on all VPCs for security analysis and compliance |
Data Encryption
- Enable encryption at rest for all storage (S3, EBS, RDS, DynamoDB)
- Use customer-managed KMS keys for sensitive data
- Enforce TLS 1.2+ for all data in transit
- Enable S3 bucket encryption and block public access by default
- Rotate encryption keys annually or as required by policy
- Use secrets manager for DB credentials, not hardcoded in code