jan-karel.nl

AWS Hardening

AWS Hardening

Cloud Snel, Cloud Strak

Cloudomgevingen veranderen snel. Daarom moet beveiliging hier standaard en geautomatiseerd meebewegen.

Voor AWS Hardening is automatisering leidend: guardrails in code, least privilege en continue driftcontrole.

Zo houd je snelheid in de cloud, zonder dat veiligheid afhankelijk wordt van handmatig geluk.

Directe maatregelen (15 minuten)

Waarom dit telt

De kern van AWS Hardening is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdedigingsmaatregelen: een samenhangend beeld

De verdediging van een AWS-omgeving rust op vier pijlers:

Service Control Policies (SCPs)

SCPs zijn de nucleaire optie van AWS-beveiliging. Ze worden toegepast op accountniveau in AWS Organizations en overschrijven alle andere permissies. Als een SCP iets verbiedt, kan niemand het doen – zelfs niet de root user van het account.

// SCP: voorkom dat CloudTrail wordt uitgeschakeld
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Action": [
            "cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail"
        ],
        "Resource": "*"
    }]
}

// SCP: beperk activiteiten tot specifieke regio's
{
    "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 zijn IAM-policies die een plafond zetten op de rechten die een user of role kan hebben. Zelfs als een user AdministratorAccess heeft, beperkt de Permission Boundary wat ze daadwerkelijk kunnen doen.

// Permission Boundary: maximaal S3 en Lambda
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "s3:*",
            "lambda:*",
            "logs:*"
        ],
        "Resource": "*"
    }]
}
// Zelfs met AdministratorAccess kan deze user geen EC2, IAM, etc. gebruiken

IMDSv2 enforcement

# Forceer IMDSv2 voor alle nieuwe EC2-instanties
aws ec2 modify-instance-metadata-options \
    --instance-id i-0abcdef1234567890 \
    --http-tokens required \
    --http-put-response-hop-limit 1
# http-tokens required = alleen IMDSv2
# http-put-response-hop-limit 1 = blokkeert container-naar-metadata requests

GuardDuty en monitoring

# Activeer GuardDuty in alle regio's
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

De ongemakkelijke waarheid over AWS-beveiliging

AWS biedt alle tools die je nodig hebt om een veilige omgeving op te bouwen. SCPs, Permission Boundaries, IMDSv2, GuardDuty, CloudTrail, Config Rules, Access Analyzer, IAM Access Advisor – het arsenaal is indrukwekkend. Het probleem is niet het gereedschap. Het probleem is de vakman.

De gemiddelde AWS-omgeving lijdt niet aan een gebrek aan beveiligingsopties. Het lijdt aan een gebrek aan discipline. Iemand heeft AdministratorAccess gekoppeld aan een development-user “omdat het anders niet werkte.” Iemand heeft IMDSv1 laten staan “omdat de applicatie dat nodig had.” Iemand heeft een S3 bucket publiekelijk gemaakt “voor testing” en het nooit teruggedraaid.

Het patroon is altijd hetzelfde. De technologie is er. Het beleid is er. De procedure is er. Maar de menselijke neiging om de makkelijkste weg te kiezen, wint het elke keer van het beveiligingsbeleid.

De enige verdediging die werkelijk werkt, is automatisering. Niet beleid dat op papier staat, maar beleid dat in code staat. SCPs die voorkomen dat CloudTrail wordt uitgeschakeld. AWS Config rules die automatisch detecteren wanneer een S3 bucket publiekelijk wordt. Permission Boundaries die voorkomen dat developers hun eigen rechten kunnen escaleren.

Automatiseer het. Want mensen vergeten. Code niet.

Referentietabel

Techniek Tool/Commando Doel MITRE ATT&CK
Identity Discovery aws sts get-caller-identity Identificeer huidige AWS-identiteit T1087.004
IAM Permission Enum enumerate-iam Ontdek alle beschikbare API-calls T1087.004
IAM User/Role Enum aws iam list-users/roles Enumereer IAM-entiteiten T1087.004
IAM Policy Analysis aws iam get-account-authorization-details Volledige IAM-dump T1087.004
IAM Privesc Scan Pacu iam__privesc_scan Identificeer privilege escalation-paden T1078.004
CreatePolicyVersion aws iam create-policy-version Policy inhoud wijzigen T1098.003
PassRole + Lambda aws lambda create-function Privilege escalation via Lambda T1078.004
AssumeRole aws sts assume-role Cross-account of role-escalatie T1550.001
S3 Public Bucket aws s3 ls --no-sign-request Publiekelijk toegankelijke buckets T1530
S3 Object Download aws s3 cp --no-sign-request Data exfiltratie uit open buckets T1530
EC2 IMDS Credentials curl 169.254.169.254 IAM credentials via metadata service T1552.005
EC2 User-Data curl .../user-data/ Credentials in startup scripts T1552.005
EBS Snapshot Access aws ec2 describe-snapshots Data van publieke snapshots T1530
Lambda Env Vars aws lambda get-function-configuration Credentials in environment variables T1552.001
Lambda Source Code aws lambda get-function Download Lambda-code voor analyse T1213.003
Lambda Event Injection Function URL Command injection via event-data T1059
Secrets Manager Enum aws secretsmanager list-secrets Secrets enumeratie en exfiltratie T1552.001
Parameter Store Enum aws ssm get-parameters-by-path Credentials in Parameter Store T1552.001
CloudTrail Evasion Gebruik niet-gemonitorde regio’s Logging-evasie T1562.008
Pacu Framework pacu Geautomatiseerde AWS exploitation
Cross-Account Abuse sts:AssumeRole + trust policies Laterale beweging tussen accounts T1550.001
Confused Deputy Ontbrekende ExternalId Cross-account trust misbruik T1199

Volgende hoofdstuk: Hoofdstuk 4 – Azure Aanvallen

Op de hoogte blijven?

Ontvang maandelijks cybersecurity-inzichten in je inbox.

← Cloudbeveiliging ← Home