IAM verstehen: Die häufigsten Fehler von AWS-Einsteigern

AWS-Einsteiger stoßen schnell auf die Access Denied-Fehlermeldung. Statt die Ursache zu verstehen, wird oft der einfache Weg gewählt: Der Administrator-Zugriff wird aktiviert. Doch diese Lösung ist wie ein Schloss mit einem riesigen Schlüssel – gefährlich und unnötig.

Stellen Sie sich vor, Sie erstellen eine Lambda-Funktion, die auf eine S3-Bucket zugreifen soll. Ohne die richtigen Berechtigungen erhalten Sie eine Fehlermeldung. Der intuitive Impuls? Schnell AdministratorAccess zuweisen und weitermachen. Doch was passiert dabei? Die Funktion erhält Zugriff auf alles in Ihrem AWS-Konto – inklusive teurer Ressourcen oder sensibler Daten.

Die eigentliche Botschaft hinter Access Denied ist jedoch eine andere: Sie zeigt Ihnen genau, welche Berechtigung fehlt. Der Fehler ist kein Hindernis, sondern ein Hinweis. Mit dem richtigen mentalen Modell wird IAM von einer undurchdringlichen Mauer zu einem nützlichen Werkzeug.

Was IAM wirklich ist: Der Türsteher Ihrer AWS-Umgebung

IAM steht für Identity and Access Management – ein sperriger Name für eine einfache Funktion. Stellen Sie sich IAM als den Türsteher vor, der vor jedem AWS-Service steht. Jede Aktion in Ihrem Konto – ob manuell über die Konsole, programmatisch via API oder automatisch durch eine Lambda-Funktion – wird von IAM überprüft.

Dabei stellt IAM zwei kritische Fragen:

• Wer möchte handeln? (Identität)
• Darf diese Identität diese Aktion ausführen? (Berechtigung)

Fällt die Antwort auf eine der Fragen negativ aus, erhalten Sie die Access Denied-Meldung. Diese beiden Fragen bilden das Fundament von IAM. Alles andere ist nur eine Ausprägung dieser Logik.

Die drei Säulen: Benutzer, Rollen und Richtlinien

Für AWS-Einsteiger reichen drei Konzepte, um IAM zu verstehen.

IAM-Benutzer: Der dauerhafte Ausweis für Menschen

Ein IAM-Benutzer ist eine persistente Identität – also ein dauerhafter Zugang für Personen, die sich in der AWS-Konsole anmelden oder die CLI nutzen. Jeder Benutzer hat eigene Anmeldedaten, bestehend aus Benutzername/Passwort für die Konsole oder Zugriffsschlüsseln für die API.

Denken Sie an einen Firmenausweis: Er gehört Ihnen, trägt Ihren Namen und ist so lange gültig, bis die IT-Abteilung ihn deaktiviert.

IAM-Rollen: Der temporäre Besucherausweis für Dienste

Eine IAM-Rolle ist dagegen zeitlich begrenzt. Sie wird nicht einer Person dauerhaft zugewiesen, sondern von einer Entität – etwa einer Lambda-Funktion oder einem EC2-Instanzen – angenommen (engl. assumed). Die Rolle vergibt dann temporäre Zugangsdaten, die nach einigen Stunden oder Tagen automatisch ablaufen.

Stellen Sie sich vor, Sie besuchen ein Büro als Gast: Sie melden sich an, erhalten einen Besucherausweis, der nach einigen Stunden ungültig wird. Genau so funktionieren IAM-Rollen für AWS-Dienste.

Merksatz:

• Menschen erhalten Benutzer.
• Dienste (Lambda, EC2, andere AWS-Konten) erhalten Rollen.

Der Vorteil: Da die Anmeldedaten kurzlebig sind, sinkt das Risiko eines Missbrauchs – selbst wenn ein Dienst kompromittiert wird.

Richtlinien: Der offizielle Erlaubnisschein in JSON

Eine Richtlinie ist ein JSON-Dokument, das definiert, welche Aktionen eine Identität auf welchen Ressourcen ausführen darf. Ohne eine angebrachte Richtlinie hat ein IAM-Benutzer oder eine Rolle keinerlei Rechte – nicht einmal das Lesen eines Buckets.

Ein einfaches Beispiel für eine Richtlinie, die das Lesen aus einem S3-Bucket erlaubt:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::mein-bucket/*"
    }
  ]
}

Diese Richtlinie erlaubt nur das Herunterladen von Objekten aus dem Bucket mein-bucket. Alles andere bleibt gesperrt.

Das mentale Modell: Identität + Berechtigung = Zugang

Zusammengefasst:

• Benutzer/Rolle = Wer?
• Richtlinie = Was darf ich?

Das ist die gesamte IAM-Logik. Alles andere baut darauf auf.

Das Prinzip der minimalen Rechte: Warum weniger mehr ist

Das Prinzip der minimalen Rechte (engl. least privilege) ist der entscheidende Grundsatz nicht nur für IAM, sondern für die gesamte IT-Sicherheit. Es lautet:

Gewähren Sie jeder Identität nur die Berechtigungen, die sie für ihre Aufgabe benötigt – nicht mehr.

Der Fehler vieler AWS-Einsteiger? Sie vergeben AdministratorAccess, weil es schneller geht. Doch damit öffnen Sie Tür und Tor für:

• Löschung ganzer Datenbanken
• Erstellung teurer Ressourcen
• Zugriff auf sensible Daten anderer Dienste

Stellen Sie sich vor, in einem Unternehmen erhält jeder Mitarbeiter einen Generalschlüssel, nur weil einer einen Raum betreten muss. Das ist nicht nur unsicher, sondern auch unnötig.

Die korrekte Lösung für die Lambda-Funktion aus dem Anfangsbeispiel wäre eine minimalistische Richtlinie wie diese:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mein-bucket/*"
}

Selbst wenn diese Funktion kompromittiert wird, kann der Angreifer nur Dateien aus diesem einen Bucket lesen – nicht mehr.

Aber das klingt nach viel Aufwand!

Ja, die Einrichtung präziser Richtlinien erfordert etwas mehr Planung. Doch AWS bietet Tools, die diesen Prozess erleichtern:

• IAM Access Analyzer: Analysiert, welche Aktionen eine Identität tatsächlich nutzt, und generiert eine passende Richtlinie.
• Richtlinien-Simulator: Testet, ob eine Richtlinie die gewünschten Berechtigungen gewährt, bevor sie angewendet wird.

Der Aufwand lohnt sich: Weniger Rechte bedeuten weniger Angriffsfläche – und mehr Kontrolle über Ihre Cloud-Umgebung.

IAM muss keine undurchsichtige Hürde sein. Mit dem richtigen mentalen Modell wird es zu einem mächtigen Werkzeug, das Ihre AWS-Umgebung nicht nur sicherer, sondern auch transparenter macht. Beginnen Sie mit minimalen Rechten, nutzen Sie die Analyse-Tools von AWS, und Sie vermeiden die typischen Fallstricke, die viele Einsteiger in die Sicherheitsfalle locken.