AWS Hardening

Cloud Fast, Cloud Tight

Cloud environments change rapidly. That's why security here must move along as a standard and automated practice.

For AWS Hardening, automation is leading: guardrails in code, least privilege and continuous drift detection.

This way you maintain speed in the cloud without security depending on manual luck.

Immediate measures (15 minutes)

• Implement IAM least privilege and enforcing guardrails per account/project.
• Use secret management with rotation instead of static credentials.
• Require CI/CD and IaC controls for deployment to production.

Why this matters

The core of AWS Hardening is risk reduction in practice. Technical context supports the choice of measures, but implementation and embedding are central.

Defense measures: a coherent picture

The defense of an AWS environment rests on four pillars:

Service Control Policies (SCPs)

SCPs are the nuclear option of AWS security. They are applied at the account level in AWS Organizations and override all other permissions. If an SCP prohibits something, nobody can do it -- not even the root user of the account.

// SCP: prevent CloudTrail from being disabled
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Action": [
            "cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail"
        ],
        "Resource": "*"
    }]
}

// SCP: restrict activities to specific regions
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotAction": [
            "iam:*",
            "sts:*",
            "s3:*",
            "cloudfront:*"
        ],
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "aws:RequestedRegion": [
                    "eu-west-1",
                    "eu-central-1"
                ]
            }
        }
    }]
}

Permission Boundaries

Permission Boundaries are IAM policies that set a ceiling on the rights a user or role can have. Even if a user has AdministratorAccess, the Permission Boundary limits what they can actually do.

// Permission Boundary: maximum S3 and Lambda
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "s3:*",
            "lambda:*",
            "logs:*"
        ],
        "Resource": "*"
    }]
}
// Even with AdministratorAccess, this user cannot use EC2, IAM, etc.

IMDSv2 enforcement

# Force IMDSv2 for all new EC2 instances
aws ec2 modify-instance-metadata-options \
    --instance-id i-0abcdef1234567890 \
    --http-tokens required \
    --http-put-response-hop-limit 1
# http-tokens required = IMDSv2 only
# http-put-response-hop-limit 1 = blocks container-to-metadata requests

GuardDuty and monitoring

# Enable GuardDuty in all regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
    aws guardduty create-detector --enable --region "$region" 2>/dev/null
    echo "GuardDuty enabled in $region"
done

The uncomfortable truth about AWS security

AWS provides all the tools you need to build a secure environment. SCPs, Permission Boundaries, IMDSv2, GuardDuty, CloudTrail, Config Rules, Access Analyzer, IAM Access Advisor -- the arsenal is impressive. The problem is not the tools. The problem is the craftsman.

The average AWS environment doesn't suffer from a lack of security options. It suffers from a lack of discipline. Someone attached AdministratorAccess to a development user "because it wouldn't work otherwise." Someone left IMDSv1 enabled "because the application needed it." Someone made an S3 bucket public "for testing" and never reverted it.

The pattern is always the same. The technology is there. The policy is there. The procedure is there. But the human tendency to take the easiest path wins over the security policy every time.

The only defense that truly works is automation. Not policy on paper, but policy in code. SCPs that prevent CloudTrail from being disabled. AWS Config rules that automatically detect when an S3 bucket becomes public. Permission Boundaries that prevent developers from escalating their own privileges.

Automate it. Because people forget. Code doesn't.

Reference table

Next chapter: Chapter 4 -- Azure Attacks