Security Group and RAM Design for a Multi-Tier VPC
A three-tier application runs in a VPC: a public SLB, a web tier of 6 ECS instances in a public-facing vSwitch, an app tier of 4 ECS instances in a private vSwitch, and an RDS instance. Engineers currently use the root account's AccessKey in CI scripts and connect to ECS over SSH from the internet using a shared password. Security groups: the web tier allows 0.0.0.0/0 on 22 and 80; the app tier allows 0.0.0.0/0 on all ports; RDS allows 0.0.0.0/0 on 3306. An audit found no CloudMonitor alerts on security group changes.
1. Identify the highest-risk findings and propose a least-privilege security group redesign.
Read the worked answer
Highest-risk findings, in order:
- Root AccessKey in CI - full account compromise potential; no attribution, no rotation.
- App tier open to 0.0.0.0/0 on all ports and RDS open on 3306 - direct database exposure to the internet.
- Shared SSH password over the internet - credential sharing, no audit trail, brute-force exposure.
Least-privilege redesign:
- SLB SG: allow 80/443 from 0.0.0.0/0 only.
- Web tier SG: allow 80/443 from the SLB's security group (or SLB backend address range) only; no SSH from the internet - use Cloud Assistant or a bastion/jump host in a dedicated subnet.
- App tier SG: allow application port only from the web tier SG; no internet ingress.
- RDS: allow 3306 only from the app tier SG; use a private vSwitch and RDS whitelist restricted to the app tier CIDR/SG.
- Add a default-deny posture and document each rule with a purpose; review quarterly.
Use security-group referencing rather than CIDR where possible so membership changes propagate automatically.
2. Propose an identity and monitoring remediation plan covering AccessKeys, SSH access, and detection of future drift.
Read the worked answer
Identity remediation:
- Create RAM users for CI with programmatic access only, scoped by RAM policy to the specific actions/resources needed (e.g., ECS start/stop on tagged instances, OSS put to a specific bucket). Never use root AccessKeys; enable MFA on the root account and restrict its use.
- Rotate AccessKeys on a schedule and alert on keys older than the policy threshold. Use STS temporary credentials for CI where possible.
- For human access, use RAM users with MFA and role-based permissions; replace shared SSH passwords with key-based access via a bastion or Cloud Assistant sessions, and log sessions.
Monitoring and drift detection:
- Enable ActionTrail to capture RAM, security group, and ECS API changes; ship to Log Service and alert on security-group ingress changes, root logins, and AccessKey creation.
- Configure CloudMonitor event alerts for security group rule changes and RDS whitelist changes.
- Use Config-like periodic checks (or a scheduled script via Cloud Assistant) to compare live security groups against a baseline and report drift.
- Alert on unusual 3306 connection attempts and on SSH brute-force patterns from VPC flow logs if available.