Das Problem des verwirrten Stellvertreters
Das Problem des verwirrten Stellvertreters ist ein Sicherheitsproblem, bei dem eine Entität, die keine Berechtigung zur Durchführung einer Aktion hat, eine privilegiertere Entität zur Durchführung der Aktion zwingen kann. Um dies zu verhindern, bietet AWS Tools, mit denen Sie Ihr Konto schützen können, wenn Sie Dritten (d. h. kontoübergreifend) oder anderen AWS-Diensten (d. h. dienstübergreifend) Zugriff auf Ressourcen in Ihrem Konto bereitstellen.
Es kann vorkommen, dass Sie Dritten Zugriff auf Ihre AWS-Ressourcen gewähren müssen, also Zugriff delegieren müssen. Sie beauftragen beispielsweise das externe Unternehmen Example Corp damit, Ihr AWS-Konto zu überwachen und zur Kostenoptimierung beizutragen. Um Ihre täglichen Ausgaben zu überwachen, benötigt Example Corp Zugriff auf Ihre AWS-Ressourcen. Example Corp überwacht zudem viele weitere AWS-Konten anderer Kunden. Etablieren Sie mithilfe einer IAM-Rolle eine Vertrauensbeziehung zwischen Ihrem AWS-Konto und dem Konto von Example Corp. Ein wichtiger Faktor hierbei ist die externe ID, eine optionale Kennung, mit der Sie in Vertrauensrichtlinien von IAM-Rollen festlegen können, wer die Rolle übernehmen kann. Die Hauptfunktion des externen Ausweises besteht darin, das Problem des verwirrten Stellvertreters zu lösen und zu verhindern.
Einige AWS-Services (aufrufende Services) verwenden ihren AWS-Service-Prinzipal, um auf AWS-Ressourcen anderer AWS-Services (aufgerufene Services) zuzugreifen. Bei manchen dieser Serviceinteraktionen können Sie aufrufende Services so konfigurieren, dass sie mit den Ressourcen eines aufgerufenen Services in einem anderen AWS-Konto kommunizieren. Ein Beispiel hierfür ist die Konfiguration von AWS CloudTrail für das Schreiben in einen zentralen Amazon-S3-Bucket in einem anderen AWS-Konto. Dem aufrufenden Service CloudTrail wird der Zugriff auf Ihren S3-Bucket über die Richtlinie des S3-Buckets gewährt, indem eine Zugriffserlaubnis für cloudtrail.amazonaws.com hinzugefügt wird.
Wenn ein AWS-Service-Prinzipal eines aufrufenden Services auf eine Ressource eines aufgerufenen Services zugreift, autorisiert die Ressourcenrichtlinie des aufgerufenen Services nur den AWS-Service-Prinzipal, nicht aber den Akteur, der den aufrufenden Service konfiguriert hat. Beispielsweise kann ein S3-Bucket, der dem CloudTrail-Service-Prinzipal bedingungslos vertraut, CloudTrail-Protokolle von den AWS-Konten empfangen, die ein vertrauenswürdiger Administrator konfiguriert hat, aber auch CloudTrail-Protokolle von einem nicht autorisierten Akteur in seinem AWS-Konto, sofern dieser den Namen des S3-Buckets kennt.
Das Confused-Deputy-Problem tritt auf, wenn ein Akteur das Vertrauen eines AWS-Service-Prinzipals missbraucht, um Zugriff auf Ressourcen zu erlangen, für die er nicht berechtigt ist.
Vermeidung des Problems des verwirrten Stellvertreters (kontoübergreifend)
In der nachfolgenden Abbildung wird das verwirrte Stellvertreter-Problem dargestellt.
In diesem Szenario wird von Folgendem ausgegangen:
-
AWS1 ist Ihr AWS-Konto.
-
AWS1:ExampleRole ist eine Rolle in Ihrem Konto. Über die Vertrauensrichtlinie dieser Rolle wird das AWS-Konto von Example Corp angegeben und kann somit die Rolle übernehmen.
Es passiert Folgendes:
-
Wenn Sie die Zusammenarbeit mit Example Corp beginnen, stellen Sie Example Corp den ARN von AWS1:ExampleRole bereit.
-
Example Corp verwendet den Rollen-ARN, um temporäre Sicherheitsanmeldeinformationen abzurufen und damit auf die Ressourcen in Ihrem AWS-Konto zuzugreifen. Sie machen Example Corp also zu Ihrem "Stellvertreter", der in Ihrem Namen handeln darf.
-
Ein anderer AWS-Kunde beginnt ebenfalls mit Example Corp zu arbeiten und stellt Example Corp ebenfalls den ARN von AWS1:ExampleRole bereit. Dabei gehen wir davon aus, dass der andere Kunde den ARN von AWS1:ExampleRole in Erfahrung gebracht hat, der ja nicht geheim ist.
-
Wenn der andere Kunde Example Corp Zugriff auf die AWS-Ressourcen in (scheinbar) seinem Konto gewährt, greift Beispielunternehmen mithilfe von AWS1:ExampleRole auf die Ressourcen in Ihrem Konto zu.
So kann der andere Kunde unautorisiert Zugriff auf Ihre Ressourcen erlangen. Da der Kunde Example Corp dahingehend manipuliert hat, unwissentlich auf Ihre Ressourcen zuzugreifen, ist Beispielunternehmen nun ein "verwirrter Stellvertreter".
Example Corp vermeidet dieses Problem zum Beispiel, indem sie verlangt, in der Vertrauensrichtlinie der Rolle eine ExternalId-Bedingungsprüfung aufzunehmen. Example Corp generiert zum Beispiel einen einzigartigenExternalId-Wert für jeden Kunden und verwendet diesen Wert in seiner Anforderung, um die Rolle zu übernehmen. Der ExternalId-Wert muss unter den Kunden von Example Corp eindeutig sein und von Example Corp kontrolliert werden, nicht von seinen Kunden. Deshalb erhalten Sie diese ID auch von Example Corp und können sie nicht selbst erstellen. Dies verhindert, dass Example Corp ein verwirrter Stellvertreter wird und Zugang zu AWS-Ressourcen eines anderen Kontos gewährt.
Stellen Sie sich in unserem Szenario vor, dass Ihre eindeutige ID beim Example Corp 12345 lautet und die ID des anderen Kunden 67890. Die IDs sind für dieses Szenario vereinfacht. Im Allgemeinen sind diese IDs GUIDs. Angenommen, diese IDs sind innerhalb des Kundenstamms von Example Corp eindeutig und es handelt sich um sinnvolle externe ID-Werte.
Example Corp teilt Ihnen den externen ID-Wert 12345 mit. Sie fügen nun ein Condition-Element zur Vertrauensrichtlinie der Rolle hinzu, dessen sts:ExternalId-Wert 12345 lauten muss. Beispiel:
Aufgrund des Condition-Elements in dieser Richtlinie kann Example Corp die Rolle nur übernehmen, wenn der AssumeRole-API-Aufruf den externen ID-Wert 12345 enthält. Example Corp gibt immer, wenn es für einen Kunden eine Rolle übernimmt, den externen ID-Wert des Kunden im AssumeRole-Aufruf mit an. Selbst wenn ein anderer Kunde Example Corp Ihren ARN bereitstellt, kann er die externe ID, die Example Corp in seine Anforderung an AWS aufnimmt, nicht kontrollieren. So wird verhindert, dass nicht autorisierte Kunden Zugriff auf Ihre Ressourcen erhalten.
Das folgende Diagramm verdeutlicht dieses Konzept.
-
Wie zuvor stellen Sie, wenn Sie die Zusammenarbeit mit Example Corp beginnen, dem Unternehmen den ARN von AWS1:ExampleRole bereit.
-
Wenn das Example Corp den Rollen-ARN nutzt, um die Rolle AWS1:ExampleRole anzunehmen, gibt das Example Corp Ihre externe ID (12345) im AssumeRole-API-Aufruf mit an. Die externe ID stimmt mit der Vertrauensrichtlinie der Rolle überein, sodass der AssumeRole-API-Aufruf erfolgreich ist und Example Corp temporäre Sicherheitsanmeldeinformationen für den Zugriff auf Ressourcen in Ihrem AWS-Konto erhält.
-
Ein anderer AWS-Kunde beginnt ebenfalls wie zuvor mit Example Corp zu arbeiten und stellt Example Corp ebenfalls den ARN von AWS1:ExampleRole bereit.
-
Wenn das Example Corp jedoch diesmal versucht, die Rolle AWS1:ExampleRole anzunehmen, gibt es die dem anderen Kunden zugeordnete externe ID (67890) an. Der andere Kunde hat keinen Einfluss darauf. Example Corp gibt dies an, da die Anforderung zur Verwendung der Rolle von dem anderen Kunden stammte und 67890 somit die Umstände angibt, unter denen Example Corp handelt. Da Sie eine Bedingung mit Ihrer eigenen externen ID (12345) zur Vertrauensrichtlinie von AWS1:ExampleRole hinzugefügt haben, schlägt der AssumeRole-API-Aufruf fehl. Der andere Kunde wird daran gehindert, unbefugten Zugriff auf Ressourcen in Ihrem Konto zu erhalten (gekennzeichnet durch das rote "X" in der Grafik).
Die externe ID verhindert, dass andere Kunden Example Corp manipuliert, und unwissentlich Zugriff auf Ihre Ressourcen gewährt.
Vermeidung des Problems des verwirrten Stellvertreters (dienstübergreifend)
Das folgende Diagramm veranschaulicht das serviceübergreifende Confused-Deputy-Problem am Beispiel der Interaktion zwischen CloudTrail und Amazon S3. Hierbei schreibt ein nicht autorisierter Akteur CloudTrail-Protokolle in einen Amazon-S3-Bucket, auf den er keinen Zugriff hat.
Um zu verhindern, dass ein nicht autorisierter Akteur das Vertrauen eines AWS-Prinzipals missbraucht, um Zugriff auf Ihre Ressourcen zu erlangen, enthalten AWS-Service-Prinzipale Informationen über die AWS-Ressource, das AWS-Konto und die AWS-Organisation, in deren Namen sie handeln.
Diese Informationen sind in globalen Bedingungsschlüsselwerten verfügbar, die in einer Ressourcenrichtlinie oder einer Ressourcen-Kontrollrichtlinie für Anfragen von AWS-Service-Prinzipalen verwendet werden können. Wir empfehlen die Verwendung von aws:SourceArn, aws:SourceAccount, aws:SourceOrgID oder aws:SourceOrgPaths in Ihren Ressourcenrichtlinien, wenn einem AWS-Service-Prinzipal Zugriff auf Ihre Ressourcen gewährt wird. Mit diesen Bedingungsschlüsseln können Sie in Ihren Ressourcenrichtlinien oder Ressourcen-Kontrollrichtlinien testen, ob AWS-Service-Prinzipale, die auf Ihre Ressourcen zugreifen, dies im Namen der erwarteten AWS-Ressourcen, AWS-Konten oder AWS Organizations tun.
-
Verwenden Sie
aws:SourceArn, um einem AWS-Service-Prinzipal den Zugriff auf Ihre Ressourcen im Namen einer bestimmten Ressource zu erlauben, z. B. eines bestimmten Pfads von AWS CloudTrail oder einer AppStream-Flotte. -
Verwenden Sie
aws:SourceAccount, um einem AWS-Service-Prinzipal den Zugriff auf Ihre Ressourcen im Namen eines bestimmten AWS-Konto zu erlauben. -
Verwenden Sie
aws:SourceOrgID, um einem AWS-Service-Prinzipal den Zugriff auf Ihre Ressourcen im Namen bestimmter AWS Organizations zu erlauben. -
Verwenden Sie
aws:SourceOrgPaths, um einem AWS-Service-Prinzipal den Zugriff auf Ihre Ressourcen im Namen eines bestimmten Pfads von AWS Organizations zu erlauben.
Das folgende Diagramm veranschaulicht das serviceübergreifende Confused-Deputy-Szenario, wenn eine Ressource mit dem globalen Bedingungskontextschlüssel aws:SourceAccount konfiguriert ist und ein nicht autorisierter Akteur von einem anderen Konto versucht, auf AWS-Ressourcen zuzugreifen, für die er keine Zugriffsberechtigung hat.
Mit der Verwendung der globalen Bedingungsschlüssel aws:SourceArn, aws:SourceAccount, aws:SourceOrgID und aws:SourceOrgPaths in einer Richtlinie können Sie sicherstellen, dass Service-Prinzipale in Ihrem Namen auf Ihre Ressourcen zugreifen. Wir empfehlen die Verwendung dieser Bedingungsschlüssel immer dann, wenn einem AWS-Service-Prinzipal Zugriff auf eine Ihrer Ressourcen gewährt wird.
Anmerkung
Einige Interaktionen des AWS-Service verfügen über zusätzliche Kontrollen, um serviceübergreifende Confused-Deputy-Probleme zu verhindern, die den Benutzerzugriff auf eine Ressource testen. Wenn beispielsweise ein KMS-Schlüssel für einen AWS-Service erteilt wird, verwendet AWS KMS den mit der Ressource verknüpften Verschlüsselungskontext und die Schlüsselgewährung, um serviceübergreifende Confused-Deputy-Probleme zu verhindern.
Weitere Informationen zu servicespezifischen Mechanismen, die dazu beitragen, serviceübergreifende Confused-Deputy-Risiken zu vermeiden, sowie zur Unterstützung von aws:SourceArn, aws:SourceAccount, aws:SourceOrgID und aws:SourceOrgPaths finden Sie in der Dokumentation der von Ihnen verwendeten Services.
Serviceübergreifender Confused-Deputy-Schutz mithilfe ressourcenbasierter Richtlinien
Die folgende Beispielrichtlinie gewährt dem Service-Prinzipal cloudtrail.amazonaws.com Zugriff auf den Amazon-S3-Bucket, arn:aws:s3:::amzn-s3-demo-bucket1, jedoch nur, wenn der Service-Prinzipal im Namen von AWS-Konto 111122223333 handelt.
Diese Beispiel-Bucket-Richtlinie gewährt dem Service-Prinzipal appstream.amazonaws.com Zugriff auf das PowerShell-Skript examplefile.psh im Bucket s3://amzn-s3-demo-bucket2, jedoch nur, wenn er im Namen der angegebenen Amazon-AppStream-Flotte handelt, indem der Flotten-ARN mit aws:SourceArn angegeben wird.
Serviceübergreifender Confused-Deputy-Schutz mithilfe von Ressourcen-Kontrollrichtlinien
Sie können Ressourcen-Kontrollrichtlinien (RCP) verwenden, um serviceübergreifende Confused-Deputy-Kontrollen auf Ressourcen unterstützter AWS-Services anzuwenden. RCPs ermöglichen die zentrale Anwendung serviceübergreifender Confused-Deputy-Kontrollen auf Ihre Ressourcen. Sie können Bedingungsschlüssel wie aws:SourceOrgId und aws:SourceOrgPaths mit RCPs verwenden, die an Ihre AWS Organizations, Organisationseinheiten (OU) oder AWS-Konten in Ihrer Organisation angehängt sind, ohne Anweisungen zu spezifischen ressourcenbasierten Richtlinien hinzuzufügen. Weitere Informationen zu Ressourcen-Kontrollrichtlinien (RCPs) und unterstützten Services finden Sie unter Ressourcen-Kontrollrichtlinien im AWS Organizations-Benutzerhandbuch.
Die folgende Beispiel-RCP verweigert AWS-Service-Prinzipalen den Zugriff auf Amazon-S3-Buckets in Ihren Mitgliedskonten, wenn aws:SourceOrgID nicht gleich o-ExampleOrg ist. Eine entsprechende Zugriffserlaubnis muss in der ressourcenbasierten Richtlinie des S3-Buckets vorhanden sein, um Prinzipale des AWS-Service mit SourceOrgID = o-ExampleOrg zuzulassen.
Diese Richtlinie wendet die Steuerung nur auf Anfragen von Service-Prinzipalen ("Bool":
{"aws:PrincipalIsAWSService": "true"}) an, bei denen der Schlüssel aws:SourceAccount vorhanden ist ("Null": {"aws:SourceAccount":
"false"}), sodass Service-Integrationen, für die die Verwendung des Bedingungsschlüssels nicht erforderlich ist, und Aufrufe Ihrer Prinzipale nicht betroffen sind. Wenn der Bedingungsschlüssel aws:SourceAccount im Anfragekontext vorhanden ist, wird die Null-Bedingung als wahr ausgewertet, wodurch aws:SourceOrgID erzwungen wird. Wir verwenden aws:SourceAccount anstelle von aws:SourceOrgID im Null-Bedingungsoperator, sodass die Kontrolle auch dann gilt, wenn die Anfrage von einem Konto stammt, das keiner Organisation angehört.
