Vertrauensrichtlinien und wer eine Rolle übernehmen darf

Eine Vertrauensrichtlinie ist das einer Rolle zugewiesene Dokument, das genau festlegt, welche Principals sie annehmen dürfen. Sie ist der Gatekeeper: Selbst wenn eine Berechtigungsrichtlinie weitreichenden Zugriff gewährt, kann niemand die Rolle verwenden, solange die Vertrauensrichtlinie diese Person oder Entität nicht aufführt. In der Prüfung sind Fehler in Vertrauensrichtlinien eine häufige Ursache sowohl für nicht funktionierenden Zugriff als auch für gefährlich weitreichende Berechtigungen.

Das Element Principal einer Vertrauensrichtlinie kann auf Folgendes verweisen:

• AWS — ein Konto, einen Benutzer oder die ARN (Amazon Resource Name) einer Rolle.
• Service — einen AWS-Service wie lambda.amazonaws.com.
• Federated — einen SAML-Provider oder einen Web-Identitätsprovider.

Die Wahl des richtigen Principal-Typs und eine möglichst spezifische Angabe sind entscheidend, damit nicht mehr Vertrauen als beabsichtigt gewährt wird.

Das kontoübergreifende Annehmen einer Rolle erfordert die Zustimmung beider Seiten. Die Vertrauensrichtlinie der Rolle im Zielkonto muss den aufrufenden Principal zulassen, und dieser Principal muss über eine Identitätsrichtlinie verfügen, die sts:AssumeRole für die ARN der Rolle erlaubt. Fehlt eine der beiden Voraussetzungen, wird die Anfrage blockiert. Dieser beidseitige Handshake ist eine typische Prüfungsfalle.

Diese Vertrauensrichtlinie erlaubt einer bestimmten Rolle im Konto 111122223333, die Rolle anzunehmen. Die Angabe einer exakten ARN statt des gesamten Kontos ist restriktiver und sicherer.

Wenn Sie einen Principal als arn:aws:iam::ACCOUNT:root angeben, vertrauen Sie dem gesamten Konto: Jeder Principal in diesem Konto, der ebenfalls über die Berechtigung sts:AssumeRole verfügt, kann die Rolle annehmen. Das ist weitreichend. Geben Sie nach Möglichkeit die exakte ARN des Benutzers oder der Rolle an, um dem Prinzip der geringsten Berechtigungen zu folgen und die Vertrauensfläche zu verkleinern.

Vertrauensrichtlinien unterstützen Condition-Blöcke, mit denen Sie genauer festlegen können, wer eine Rolle unter welchen Umständen annehmen darf. Zu den häufig verwendeten Schlüsseln gehören sts:ExternalId (zum Verhindern des Confused-Deputy-Problems), aws:MultiFactorAuthPresent (zum Erzwingen von MFA) und aws:SourceIp. Mit Bedingungen können Sie das Annehmen einer Rolle auf bestimmte, überprüfbare Umstände beschränken.

Ein leistungsfähiges Muster besteht darin, MFA vorauszusetzen, bevor eine sensible Rolle angenommen werden kann. Die Bedingung der Vertrauensrichtlinie prüft, ob die aufrufende Sitzung mit MFA authentifiziert wurde. Dadurch kann selbst ein gestohlener langfristig gültiger Berechtigungsnachweis die privilegierte Rolle ohne den zweiten Faktor nicht annehmen, was die Hürde für Angreifer deutlich erhöht.

Einige Rollen sind serviceverknüpfte Rollen, die von AWS vordefiniert werden und deren Vertrauensrichtlinie Sie nicht bearbeiten können. Sie ermöglichen es einem Service, Ressourcen in Ihrem Namen mit genau dem von AWS benötigten Vertrauen zu verwalten. Es ist wichtig, sie zu erkennen, da ihre Berechtigungen und ihr Vertrauen streng kontrolliert und an den Lebenszyklus des Services gebunden sind.

Das Vertrauen in einen internen Principal (im selben Konto) ist im Allgemeinen weniger riskant als das Vertrauen in ein externes Konto oder einen SaaS-Anbieter eines Drittanbieters. Bei externem Vertrauen sollten Sie immer einen spezifischen Principal mit Bedingungen wie ExternalId kombinieren. Betrachten Sie jede externe Vertrauensregel als einen Einstiegspunkt, den ein Angreifer nur zu gern ausnutzen würde.

IAM Access Analyzer überprüft Vertrauensrichtlinien und Ressourcenrichtlinien automatisch, um Rollen zu finden, die von externen Konten oder der Öffentlichkeit angenommen werden können. Das Tool markiert unbeabsichtigtes kontoübergreifendes oder öffentliches Vertrauen, damit Sie es einschränken können. Die Überprüfung der Ergebnisse von Access Analyzer ist eine empfohlene und prüfungsrelevante Maßnahme, um zu weit gefasstes Vertrauen zu erkennen.

Für ein sicheres Vertrauensdesign sollten Sie den spezifischsten möglichen Principal angeben, bei Bedarf Bedingungen wie ExternalId und MFA hinzufügen, Rollen gegenüber dem Vertrauen in den Konto-Root bevorzugen und die Konfiguration mit Access Analyzer überprüfen. Denken Sie daran: Die Vertrauensrichtlinie beantwortet die Frage wer, während Berechtigungsrichtlinien die Frage was beantworten. Beide müssen übereinstimmen, damit der Zugriff funktioniert und dauerhaft dem Prinzip der geringsten Berechtigungen entspricht.

Testen Sie Ihr Wissen über Vertrauensrichtlinien.

Eine Vertrauensrichtlinie legt fest, welche Principals eine Rolle annehmen dürfen, und fungiert unabhängig von den Berechtigungsrichtlinien als Gatekeeper. Das kontoübergreifende Annehmen einer Rolle erfordert einen beidseitigen Handshake: die Vertrauensrichtlinie sowie die sts:AssumeRole-Berechtigung des Aufrufers. Bevorzugen Sie spezifische Principal-ARNs gegenüber dem Konto-Root, fügen Sie Bedingungen wie ExternalId und MFA hinzu und führen Sie Prüfungen mit IAM Access Analyzer durch.