AWS Cloud Practitioner 02: IAM und Identity

Bei jeder Aktion in AWS wird zuerst geklärt, wer anfragt und ob er das darf. Diese Prüfung übernimmt AWS Identity and Access Management (IAM). Im ersten Teil haben wir gesehen, dass die Zugriffsrechte im Shared-Responsibility-Modell immer beim Kunden bleiben, egal wie weit oben der Dienst abstrahiert. IAM ist das Werkzeug, mit dem wir diese Pflicht erfüllen. In der Zertifizierung wiegt das Thema schwer, denn die Domäne Security and Compliance macht laut Exam Guide 30 % der gewerteten Inhalte aus.

User, Gruppen und Policies

Fangen wir mit den Bausteinen an. Ein IAM User steht für eine Person oder eine Anwendung, die dauerhaft auf den Account zugreift. Eine Gruppe fasst User zusammen, damit wir Rechte nicht jedem einzeln zuweisen müssen. Rechte selbst stehen in Policies, das sind Dokumente, die beschreiben, welche Aktionen auf welchen Ressourcen erlaubt sind.

Gruppen enthalten nur User, verschachteln lassen sie sich nicht. Ein User darf dagegen in mehreren Gruppen stecken oder in gar keiner.

Eine Policy, die fest in genau eine Identität eingebettet ist, also in einen User, eine Gruppe oder eine Role, heißt Inline-Policy. Sie verschwindet mit dieser Identität. Das Gegenstück sind Managed Policies, die als eigenständige Objekte an beliebig viele Identitäten gehängt werden, etwa die von AWS gepflegten Policies wie AmazonS3ReadOnlyAccess.

Eine Policy besteht aus wenigen Elementen:

Hinter allem steht das Prinzip Least Privilege. Jede Identität bekommt nur die Rechte, die sie für ihre Aufgabe braucht. Was keine Policy erlaubt, ist abgelehnt. Im Hands-on unten sehen wir das als implicitDeny schwarz auf weiß.

Für den Zugriff gibt es zwei Wege. In der Management Console melden sich User mit Passwort und MFA an. Die CLI und die SDKs arbeiten mit Access Keys, einem Schlüsselpaar aus Access Key ID und Secret Access Key. Das Paar funktioniert wie ein dauerhaftes Passwort für Programme. Deshalb sind Access Keys heikel. Wer sie kopiert, hat die Rechte des Users.

Für die Passwörter der IAM-User legen wir eine IAM Password Policy fest. Sie legt Mindestlänge und Zeichentypen fest, lässt Passwörter nach einer Frist ablaufen, verhindert die Wiederverwendung alter Passwörter und regelt, ob User ihr eigenes Passwort ändern dürfen. Ohne eigene Policy gilt die Vorgabe von AWS mit 8 bis 128 Zeichen aus mindestens drei der vier Zeichenklassen Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen (IAM User Guide). Die Password Policy gilt weder für das Passwort des Root Users noch für Access Keys. Eine Sperre nach mehreren fehlgeschlagenen Anmeldeversuchen lässt sich damit nicht einrichten.

Roles statt Schlüssel auf der Maschine

Hier setzen IAM Roles an. Eine Role ist eine Identität mit Policies, die keiner bestimmten Person gehört. Wer die Role annimmt, bekommt für begrenzte Zeit ihre Rechte. Typische Nutzer sind AWS-Services selbst, etwa eine EC2-Instanz, eine Lambda-Funktion oder CloudFormation. Die Instanz braucht damit keinen Access Key, der auf ihrer Festplatte liegt und irgendwann in einem Backup oder Repository landet.

Die Credentials für eine angenommene Role kommen vom AWS Security Token Service (STS). STS stellt temporäre, eingeschränkte Credentials aus. Neben EC2-Roles nutzen auch Federation (Anmeldung über einen externen Identity Provider) und Cross-Account-Roles diesen Weg. Bei Cross-Account-Roles nimmt eine Identität aus einem Account eine Role in einem anderen Account an. Der Exam Guide führt föderierte Identitäten und Cross-Account-Roles in Task 2.3 als Authentifizierungsmethoden auf.

Ein User ist eine dauerhafte Identität mit eigenen Credentials, eine Role ist eine Identität zum Annehmen, deren Credentials ablaufen. Wenn in einer Prüfungsfrage ein AWS-Service auf einen anderen zugreifen soll, ist die Antwort fast immer eine Role.

Bleibt die Frage, wo Anwendungen Passwörter und Schlüssel ablegen, die sie trotzdem brauchen, etwa für eine Datenbank. Task 2.3 nennt dafür AWS Secrets Manager und AWS Systems Manager, in dem der Parameter Store diese Aufgabe übernimmt. Beide schauen wir uns in späteren Teilen genauer an.

Der Root User und MFA

Beim Anlegen eines AWS-Accounts entsteht der Root User. Er hat uneingeschränkten Zugriff auf alles im Account. Den Root User nutzen wir deshalb nur zum Einrichten des Accounts. Seine Zugangsdaten teilen wir nie, Access Keys für Root legen wir nicht an, vorhandene löschen wir. Für die tägliche Arbeit legen wir IAM-Identitäten mit passenden Rechten an.

Einige Aufgaben kann nur der Root User erledigen. Die aktuelle IAM-Dokumentation nennt unter anderem diese:

Andere Account-Einstellungen wie Support-Plan, Account-Name, Kontaktdaten oder aktivierte Regionen brauchen laut Dokumentation keinen Root.

Für Accounts in AWS Organizations gibt es inzwischen eine zentrale Root-Verwaltung. Damit lassen sich die Root-Credentials von Member-Accounts entfernen und einige privilegierte Aufgaben zentral ausführen. Berechtigte IAM-User oder Roles im Management-Account können Member-Accounts außerdem ohne Root schließen und deren Root-E-Mail-Adresse, Kontaktdaten und Regionen ändern.

Multi-Factor Authentication (MFA) ergänzt das Passwort um einen zweiten Faktor. IAM unterstützt aktuell drei Arten:

SMS als zweiter Faktor wird nicht mehr unterstützt. Root User und IAM-User können jeweils bis zu acht MFA-Geräte registrieren. Für den Root User erzwingt AWS MFA inzwischen bei allen Account-Typen.

Access Reports für den Überblick

Rechte zu vergeben ist der leichte Teil. Schwieriger ist es, später zu wissen, wer was darf und was davon noch gebraucht wird. IAM bringt dafür drei Werkzeuge mit, die sich im Namen ähneln und in der Prüfung häufig vertauscht werden. Der Exam Guide fasst sie in Task 2.2 als „access reports“ zusammen.

Die Merkhilfe liegt in der Ebene. Der Credentials Report blickt auf den ganzen Account und beantwortet Audit-Fragen zu Passwörtern und Schlüsseln. Access Advisor blickt auf einen User und zeigt, welche Services er tatsächlich nutzt. Das hilft bei Least Privilege, weil Rechte für nie genutzte Services auffallen. Access Analyzer blickt auf die Ressourcen und findet, was über die Zone of Trust hinaus geteilt ist, also mit Principals außerhalb des eigenen Vertrauensbereichs.

Identitäten außerhalb von IAM

IAM-User sind für Menschen und Programme gedacht, die in AWS arbeiten. Für andere Fälle gibt es eigene Dienste, deren Namen sich leicht verwechseln lassen.

Amazon Cognito ist für die Kunden einer Anwendung da, nicht für die eigenen Mitarbeitenden. Wer eine App mit tausenden Endkunden betreibt, legt dafür keine IAM-User an. Cognito verwaltet diese Nutzer und erlaubt die Anmeldung über Social Login.

AWS Directory Service bringt Active Directory nach AWS, in drei Varianten:

AWS IAM Identity Center ist der Nachfolger von AWS Single Sign-On. Es gibt Mitarbeitenden einen einzigen Login für alle Accounts in AWS Organizations und für Business-Anwendungen, die SAML sprechen. Die Identitäten dafür stammen aus einer Identitätsquelle, entweder dem eingebauten Identity-Center-Verzeichnis, einem Active Directory oder einem externen Identity Provider wie Okta oder Microsoft Entra ID. Der Exam Guide nennt Identity Center in Task 2.3 ausdrücklich. Sobald eine Frage mehrere Accounts und einen gemeinsamen Login erwähnt, ist das die Antwort.

Hands-on

Legen wir im Demo-Account eine Gruppe mit Leserechten für S3 an, stecken einen User hinein und prüfen, was er darf. IAM ist ein globaler Dienst. Den Parameter --region eu-central-1 setzen wir nur, damit alle Befehle der Serie gleich aussehen, am Ergebnis ändert er nichts.

Zuerst die Gruppe mit der AWS-verwalteten Policy AmazonS3ReadOnlyAccess, danach der User:

aws iam create-group --group-name ccp-demo-readers --region eu-central-1

aws iam attach-group-policy \
  --group-name ccp-demo-readers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --region eu-central-1

aws iam create-user --user-name ccp-demo-user --region eu-central-1

aws iam add-user-to-group \
  --group-name ccp-demo-readers \
  --user-name ccp-demo-user \
  --region eu-central-1

In der Konsole: IAM → IAM user groups → Create group, dort User group name eintragen, unter „Attach permissions policies“ nach AmazonS3ReadOnlyAccess suchen, anhaken und Create user group. Den User legen wir mit IAM → IAM users → Create user ohne Konsolenzugang an und haken unter „Add user to group“ die Gruppe an.

Der User hat keine eigene Policy. Seine Rechte erbt er vollständig aus der Gruppe. Ob das so funktioniert, prüfen wir mit dem Policy Simulator, ohne eine einzige echte Aktion auszuführen. Den ARN des Users ermitteln wir vorher, weil er die eigene Account-ID enthält:

USER_ARN=$(aws iam get-user --user-name ccp-demo-user \
  --query User.Arn --output text)

aws iam simulate-principal-policy \
  --policy-source-arn "$USER_ARN" \
  --action-names s3:ListAllMyBuckets s3:GetObject s3:PutObject s3:DeleteBucket ec2:RunInstances \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output text \
  --region eu-central-1

s3:ListAllMyBuckets   allowed
s3:GetObject          allowed
s3:PutObject          implicitDeny
s3:DeleteBucket       implicitDeny
ec2:RunInstances      implicitDeny

In der Konsole: IAM → Access reports → Policy simulator → Add identity → Add actions → Simulate, die Aktionen wählen wir je Dienst über „Specify“. Die EC2-Zeile müssen wir aufklappen, weil die Konsole RunInstances pro Resource type bewertet.

Lesen und Auflisten erlaubt die Policy. Schreiben und Löschen tauchen in ihr nicht auf, also lehnt IAM sie ab. Den Start einer EC2-Instanz erst recht, weil die Policy nur S3 betrifft. Niemand hat hier ein Deny geschrieben. implicitDeny heißt, dass schlicht keine Erlaubnis existiert. Least Privilege ist in IAM der Normalzustand.

Aufgeräumt wird in umgekehrter Reihenfolge. Zuerst lösen wir den User aus der Gruppe und löschen ihn, dann nehmen wir die Policy von der Gruppe und löschen die Gruppe.

aws iam remove-user-from-group \
  --group-name ccp-demo-readers \
  --user-name ccp-demo-user \
  --region eu-central-1

aws iam delete-user --user-name ccp-demo-user --region eu-central-1

aws iam detach-group-policy \
  --group-name ccp-demo-readers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --region eu-central-1

aws iam delete-group --group-name ccp-demo-readers --region eu-central-1

Zum Schluss ein Blick auf die Kennzahlen des Accounts:

aws iam get-account-summary --region eu-central-1

{
    "SummaryMap": {
        "Users": 1,
        "Groups": 2,
        "Roles": 11,
        "AccountMFAEnabled": 1,
        "AccountAccessKeysPresent": 0
    }
}

Die Ausgabe ist gekürzt. Die beiden letzten Werte beziehen sich auf den Root User. AccountMFAEnabled mit 1 bedeutet, dass Root MFA aktiviert hat, und AccountAccessKeysPresent mit 0, dass für Root keine Access Keys existieren. So soll ein Account aussehen.

In der Konsole: IAM → Dashboard, die Kästen „Security recommendations“ und „IAM resources“.

IAM selbst kostet nichts. Ein vergessener IAM-User kostet vor allem Sicherheit, deshalb räumen wir auch hier vollständig auf.

Für die Prüfung

Typische Fallen:

• Gruppen in Gruppen. Gruppen enthalten nur User. Eine Antwort, die Gruppen verschachtelt, ist falsch.
• Support-Plan als Root-Aufgabe. Steht nicht mehr in der Liste der IAM-Dokumentation. Account schließen, MFA Delete für S3 und das Wiederherstellen ausgesperrter IAM-Rechte stehen dort weiterhin.
• SMS als MFA. Wird nicht mehr unterstützt. Gültig sind Passkeys bzw. FIDO-Schlüssel, Authenticator-Apps und Hardware-TOTP-Token.
• Cognito gegen Identity Center. Cognito ist für Kunden einer App, Identity Center für die eigenen Mitarbeitenden über mehrere Accounts.
• Access Advisor gegen Access Analyzer. Advisor blickt auf einen User und seine genutzten Services, Analyzer auf Ressourcen, die nach außen geteilt sind.
• Ein IAM-User für das ganze Team. Jede Person bekommt eine eigene Identität, Zugangsdaten werden nie geteilt. Eine Antwort, in der sich mehrere Menschen einen User teilen, ist falsch.
• Account kompromittiert. Gefragt sind mehrere Schritte zusammen. Wir ersetzen und löschen betroffene Access Keys, ändern die Passwörter der IAM-User, suchen in CloudTrail nach unbekannten Keys, Roles und Ressourcen, sichern den Root User mit MFA und bestätigen die Schritte im AWS Support Center, falls AWS uns benachrichtigt hat.

Quellen

• Exam Guide CLF-C02, Domain 2, Tasks 2.2 und 2.3 (Stand 2026-10-25)
• In-Scope-Services CLF-C02
• IAM User Guide: Root User
• IAM User Guide: MFA
• AWS Security Blog: mehrere MFA-Geräte in IAM
• IAM User Guide: User Groups
• IAM User Guide: Managed und Inline Policies
• IAM User Guide: Policy-Element Resource
• IAM User Guide: Password Policy für IAM-User
• IAM User Guide: Access Keys verwalten
• IAM User Guide: Security Best Practices
• Shared Responsibility Model
• IAM Identity Center: Identitätsquelle verwalten
• AWS re:Post Knowledge Center: Vorgehen bei kompromittiertem Account

Im nächsten Teil geht es um Compute, also EC2, Lambda und Container, die Dienste, denen wir die Roles aus diesem Teil zuweisen.