IAM ist der Teil von AWS, an dem die meisten zuerst verzweifeln. Nicht weil es schwer wäre, sondern weil das mentale Modell fehlt. Wer einmal verstanden hat, wie AWS eine Anfrage bewertet, schreibt Policies in Minuten statt in Stunden. Dieser Beitrag bringt das Modell auf den Punkt und zeigt die Fehler, die immer wieder auftauchen.

Das Modell: Principal, Action, Resource, Condition

Jede Anfrage an AWS lässt sich auf vier Fragen reduzieren. Wer fragt an (Principal), was will er tun (Action), worauf (Resource) und unter welchen Bedingungen (Condition). Eine IAM-Policy ist nichts anderes als die Antwort auf diese Fragen in JSON. Sobald das sitzt, liest sich jede Policy wie ein Satz.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::mein-bucket/uploads/*",
      "Condition": {
        "StringEquals": { "aws:SourceVpc": "vpc-0a1b2c3d" }
      }
    }
  ]
}

Diese Policy erlaubt Lesen und Schreiben, aber nur im Unterordner uploads und nur aus einem bestimmten VPC. Die Condition ist der Hebel, mit dem aus einer groben Erlaubnis eine präzise wird.

Rollen statt Langzeit-Keys

Der größte Hebel für Sicherheit ist die Abkehr von dauerhaften Access Keys. Ein Key, der in einer Umgebungsvariable oder gar im Code liegt, ist ein Dauerproblem. Er läuft nicht ab, er taucht in Logs auf und er wandert in Backups. Rollen lösen das, weil sie kurzlebige Credentials über STS ausgeben.

Eine Rolle braucht zwei Policies. Die Trust Policy legt fest, wer die Rolle annehmen darf. Die Permission Policy legt fest, was die Rolle dann tun kann. Die Trust Policy wird gerne vergessen, dabei ist sie die eigentliche Eintrittstür.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Diese Trust Policy erlaubt EC2-Instanzen, die Rolle anzunehmen. Die Anwendung auf der Instanz bekommt ihre Credentials dann automatisch über das Instance Metadata Service, ohne dass irgendwo ein Key liegt. Für CI/CD-Pipelines gilt dasselbe Prinzip über OIDC, was ich an anderer Stelle bereits beschrieben habe.

Least Privilege ohne Verzweiflung

Least Privilege klingt nach endloser Feinarbeit, ist aber ein Prozess mit zwei Schritten. Erst breit anfangen, dann einkochen. AWS liefert die Daten dafür selbst. Der IAM Access Analyzer wertet CloudTrail aus und schlägt eine Policy vor, die nur die tatsächlich genutzten Aktionen enthält.

Wichtig ist die Reihenfolge der Auswertung. AWS wertet ein explizites Deny immer höher als jedes Allow. Wer also eine Schutzplanke braucht, setzt ein Deny mit Condition, das selbst ein Admin nicht versehentlich umgeht.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

Dieses Statement blockiert jeden S3-Zugriff, der nicht über TLS läuft, unabhängig davon, was andere Policies erlauben. Solche Leitplanken gehören in eine Service Control Policy auf Organisationsebene, nicht in jede Einzel-Policy.

Die häufigsten Fehler

Drei Muster sehe ich immer wieder. Erstens der Stern bei Action und Resource zugleich, also "Action": "*" auf "Resource": "*". Das ist kein Setup, das ist ein offenes Scheunentor. Zweitens das Verwechseln von identity-based und resource-based Policies. Ein S3-Bucket hat eine eigene Bucket Policy, die unabhängig von der Nutzer-Policy greift. Wer nur auf einer Seite sucht, findet den Fehler nicht.

Drittens vergessene Inline Policies. Sie hängen direkt an einem Nutzer oder einer Rolle und tauchen in keiner Übersicht der verwalteten Policies auf. Bei einem Audit sind sie der blinde Fleck. Meine Empfehlung ist klar: verwaltete Policies bevorzugen, Inline nur wo es technisch nötig ist, und alles versioniert in Terraform statt per Klick in der Konsole.

Fazit

IAM wird beherrschbar, sobald man es als Beantwortung von vier Fragen begreift und konsequent auf Rollen statt Keys setzt. Der Rest ist Disziplin: breit starten, mit Access Analyzer einkochen, Leitplanken per Deny setzen und Inline Policies meiden. Wie sich dieses Vorgehen in einen sauberen Freigabe- und Auditprozess einbettet, vertiefe ich auf digital-business.blog.