Key takeaway
Identify assets and owners first, then review IAM, network, storage and change workflows according to risk.
Establish visibility and account governance
Inventory production, test and supporting AWS accounts, regions, resource types and accountable owners in one place. Define how accounts and resources are created, and regularly review unused accounts and abandoned resources. Centralize CloudTrail events and assign an owner to each finding. AWS Config recording and rule evaluation do not preventively block every misconfiguration. CloudTrail data events such as S3 object activity require explicit selection.
| Control | What it answers | Coverage to verify |
|---|---|---|
| AWS Config | Resource configuration and evaluated rules | Supported resource types, recorder, accounts and Regions |
| CloudTrail | API and account activity | Selected event types, trails or event data stores, retention, accounts and Regions |
| IAM and network controls | Who may act and which traffic may pass | Effective policies, roles and explicit network rules |
Narrow IAM and network permissions
Use federated sign-in and required MFA for people, and suitable roles with short-lived credentials for workloads. Avoid long-lived access keys; review the owner, use and rotation needs of any that remain. Scope policies to the actions and resources required for each task. Block internet access to administrative ports in security groups and network ACLs; document necessary exceptions with narrow source and expiry limits.
Assess data exposure and encryption
For S3, inspect Object Ownership first: new buckets disable ACLs by default, so review ACLs only where enabled. Check Public Access Block and bucket policies; public read does not grant upload or write permission. Keep public access only for an approved business purpose under the data owner’s control. New S3 object uploads receive default server-side encryption; still verify required encryption and key policies, legacy data, access and transport protection. Separate key duties and match rotation to service requirements. Apply the same access and retention rules to snapshots, logs and backups.
Review changes and verify remediation
Add security checks to infrastructure-as-code, retain review and change approval, and compare configurations with an approved baseline where possible. Prioritize findings by severity, internet exposure, data sensitivity and likelihood of exploitation. Test automated remediation in a sandbox account first; confirm its effect in production and record the outcome. A scan detects a problem, but remediation must be verified separately.
Secure deployment pipelines and common configurations
Look for unexpected public ports in EC2 security groups, unauthorized public reads in S3, broad IAM Action/Resource permissions and paths to the instance metadata service. Limit CI/CD build identities, scan code and secrets, and protect artifacts and release approvals. Assess findings by internet exposure, data sensitivity and permission scope; one generic score does not fit every environment.