# AWS Security Baseline and Top Misconfigurations

> **Intro:** In AWS, security quality is determined less by individual services and more by whether identity, organization-level guardrails, logging, and network defaults are coherent. This page is written as an operator’s baseline rather than a generic checklist.
>
> **What this page includes**
>
> * a practical AWS security baseline
> * top 10 AWS misconfigurations
> * why they matter
> * short remediation guidance

## Recommended AWS baseline

### Identity

* prefer federation and short-lived credentials
* minimize the use of long-lived IAM users
* separate human admin access from workload access
* use IAM Identity Center and role-based access patterns
* enable IAM Access Analyzer for external and unintended access review

### Organization guardrails

* use AWS Organizations
* apply SCPs for high-risk actions
* standardize account vending and account ownership
* separate production, non-production, and security accounts

### Logging and visibility

* enable organization-wide CloudTrail
* centralize logs to a protected account
* enable GuardDuty and Security Hub in all relevant regions
* enable Config for configuration visibility and conformance tracking

### Data protection

* default to encryption with KMS where appropriate
* review bucket policies and block public access settings
* use Secrets Manager or Parameter Store instead of hardcoded secrets

### Network

* avoid broad public exposure
* review security groups and NACLs deliberately
* use private connectivity patterns where possible
* restrict egress for sensitive workloads

## Top 10 AWS misconfigurations

| #  | Misconfiguration                                    | Why it is dangerous                                        | Short fix                                                        |
| -- | --------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------- |
| 1  | Overuse of `AdministratorAccess`                    | Makes lateral movement and privilege misuse trivial        | Replace with role families and scoped permissions                |
| 2  | Long-lived access keys                              | Keys leak and survive longer than people expect            | Move to federation, roles, and short-lived tokens                |
| 3  | Public S3 exposure                                  | Direct data leakage path                                   | Block public access, review bucket policies, use Access Analyzer |
| 4  | GuardDuty / Security Hub not enabled everywhere     | You lose posture and detection visibility                  | Enable at org level and aggregate centrally                      |
| 5  | Broad `0.0.0.0/0` inbound SG rules                  | Creates internet-facing attack paths                       | Narrow CIDRs, use ALBs/WAFs/bastions/private access              |
| 6  | Broad egress rules                                  | Makes exfiltration and unexpected dependency growth easier | Restrict egress for high-value environments                      |
| 7  | No CloudTrail centralization or weak log protection | Attackers can hide by altering weakly protected logs       | Send logs to a hardened log archive account                      |
| 8  | No SCP guardrails for dangerous actions             | A single over-privileged principal can do too much         | Block or constrain risky org-wide actions with SCPs              |
| 9  | Workload roles too broad                            | Workload compromise turns into cloud compromise            | Scope roles tightly and review trust policies                    |
| 10 | Secrets stored in user data, env files, or repos    | Easy theft path                                            | Use Secrets Manager / Parameter Store and rotate                 |

## Typical attacker path in AWS

A common path looks like:

1. steal a key or role credential
2. enumerate IAM and account inventory
3. find assumable roles or weak trust policies
4. read exposed storage or secrets
5. use the CI/CD role or deployment path to persist

## Commands and checks worth running

```bash
aws organizations list-accounts
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:role/app-prod
aws accessanalyzer list-findings --analyzer-name org-analyzer
aws securityhub get-enabled-standards
aws guardduty list-detectors
aws cloudtrail describe-trails
```

## Design comments

* **SCPs are not a substitute for IAM.** They are coarse guardrails, not day-to-day access design.
* **Security groups are easier to reason about than NACLs** for many application use cases, but both still require intentional design.
* **Access Analyzer is high-value** because it helps surface trust and exposure mistakes humans routinely miss.

## Official and primary references

* AWS Well-Architected Security Pillar
* AWS Security Hub
* IAM best practices
* IAM Access Analyzer
* CloudSecDocs AWS best practices and VPC security references


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index/aws-security-baseline-and-top-misconfigurations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.