Identitätsbasierte und ressourcenbasierte Richtlinien

Berechtigungen in AWS stammen aus Policies, die an einer von zwei Stellen angehängt werden: an eine Identität (Benutzer, Gruppe oder Rolle) oder an eine Ressource (etwa einen S3-Bucket oder KMS-Schlüssel). Für die Prüfung ist es entscheidend zu wissen, welcher Typ gilt und wie beide Typen zusammenwirken, da der kontenübergreifende Zugriff vollständig von dieser Unterscheidung abhängt.

Eine Identity-basierte Policy wird an einen IAM-Principal angehängt und definiert, welche Aktionen dieser Principal ausführen darf. Sie enthält kein Principal-Element, da der Principal durch das Ziel des Anhängens festgelegt ist. Diese Policies können von AWS verwaltet, kundenverwaltet oder inline sein und sind die häufigste Methode, Berechtigungen zu gewähren.

Eine ressourcenbasierte Policy wird direkt an eine Ressource angehängt und enthält ein Principal-Element, das angibt, wem Zugriff gewährt wird. Beispiele sind S3-Bucket-Policies, KMS-Key-Policies, SQS-Queue-Policies und Lambda-Funktions-Policies. Sie legen sowohl fest, wer (Principal) welche Aktion (Action) für diese Ressource ausführen darf.

Diese S3-Bucket-Policy gewährt einem anderen Konto Lesezugriff. Der Principal benennt das vertrauenswürdige Konto – dazu ist nur eine ressourcenbasierte Policy in der Lage.

Innerhalb eines einzelnen Kontos bilden identity-basierte und ressourcenbasierte Policies eine Vereinigung: Eine Anfrage ist zulässig, wenn eine der beiden Policies sie erlaubt und keine Policy sie verweigert. Ein S3-Objekt kann also erreicht werden, wenn entweder die Policy des Benutzers oder die Bucket-Policy den Zugriff erlaubt. Es genügt, wenn eine Seite den Zugriff ermöglicht.

Für den kontenübergreifenden Zugriff gilt eine strengere Regel: Beide Seiten müssen ihn erlauben. Der Principal benötigt eine identity-basierte Policy, die die Aktion zulässt, und die ressourcenbasierte Policy im anderen Konto muss diesem Principal Zugriff gewähren. Fehlt eine der beiden Voraussetzungen, wird die Anfrage abgelehnt. Diese Unterscheidung wird sehr häufig geprüft.

Vertrauens-Policies von Rollen sind technisch eine Art ressourcenbasierter Policy. Deshalb erfordert die kontenübergreifende Übernahme einer Rolle sowohl die Vertrauens-Policy als auch die identity-basierte Berechtigung des Aufrufers für sts:AssumeRole. Wenn Sie die Vertrauens-Policy als ressourcenbasierte Policy erkennen, können Sie Ihr Verständnis davon vereinheitlichen, wie Zugriffsrechte gewährt werden.

Nicht jeder Service unterstützt ressourcenbasierte Policies. Zu den wichtigsten gehören S3, KMS, SQS, SNS, Lambda, Secrets Manager und ECR. Wenn ein Service keine Ressourcen-Policies unterstützt, muss der kontenübergreifende Zugriff stattdessen durch die Übernahme einer Rolle gewährt werden. In der Prüfung kann getestet werden, ob ein gewählter Ansatz für einen bestimmten Service überhaupt möglich ist.

Verwenden Sie identity-basierte Policies für allgemeine Berechtigungen nach dem Muster „Dieses Team darf diese Aktionen ausführen“. Verwenden Sie ressourcenbasierte Policies, wenn Sie einem bestimmten externen Principal Zugriff gewähren, kontenübergreifendes Teilen bei einem unterstützten Service ermöglichen oder Berechtigungen festlegen müssen, die zusammen mit der Ressource gelten.

Da der Zugriff von beiden Seiten kommen kann, müssen Sie bei einer Überprüfung beide Seiten untersuchen. IAM Access Analyzer prüft ressourcenbasierte Policies, um Ressourcen zu finden, die extern oder öffentlich geteilt werden. Auf der Identitätsseite helfen die Policy-Simulation und Daten zu zuletzt verwendeten Berechtigungen. Eine vollständige Überprüfung betrachtet niemals nur einen Policy-Typ.

Der Zugriff innerhalb eines Kontos ist eine Vereinigung (jede der beiden Policies kann ihn erlauben), während der kontenübergreifende Zugriff erfordert, dass sowohl die Identity-Policy als auch die Ressourcen-Policy ihn erlauben. Identity-Policies enthalten keinen Principal, Ressourcen-Policies dagegen schon. Wählen Sie den Policy-Typ passend zum Szenario und behalten Sie im Blick, welche Services ressourcenbasierte Policies überhaupt unterstützen.

Testen Sie Ihr Verständnis der Policy-Typen.

Identity-basierte Policies werden an Principals angehängt und enthalten kein Principal-Element; ressourcenbasierte Policies werden an Ressourcen angehängt und nennen einen Principal. Der Zugriff innerhalb eines Kontos ist eine Vereinigung beider Policy-Typen; für den kontenübergreifenden Zugriff müssen beide den Zugriff erlauben. Nur einige Services (S3, KMS, SQS, SNS, Lambda, Secrets Manager und ECR) unterstützen Ressourcen-Policies. Andernfalls müssen Sie eine Rolle übernehmen.