Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Kontrollieren Sie den Zugriff auf AWS STS mit VPC-Endpunktrichtlinien
Wenn Sie einen Schnittstellen-VPC-Endpunkt für AWS -Security-Token-Service (AWS STS) erstellen, können Sie eine Endpunktrichtlinie anhängen. Die Richtlinie steuert, welche Principals den Endpoint verwenden können und welche AWS STS Aktionen sie ausführen können. Wenn Sie keine Richtlinie anhängen, verwendet der Endpunkt die Standardrichtlinie, die allen Prinzipalen uneingeschränkten Zugriff auf alle AWS STS Aktionen gewährt.
VPC-Endpunktrichtlinien gewähren keine eigenen Berechtigungen. Sie dienen als zusätzliche Grenze, die zusammen mit anderen Richtlinien funktioniert. Sowohl die Endpunktrichtlinie als auch die geltenden Richtlinien des Anrufers müssen eine Anfrage zulassen, damit sie erfolgreich ist.
Weitere Informationen zu VPC-Endpunktrichtlinien finden Sie unter Steuern des Zugriffs auf VPC-Endpunkte mithilfe von Endpunktrichtlinien im Amazon VPC-Benutzerhandbuch.
Themen
Standard-VPC-Endpunktrichtlinie
Wenn Sie beim Erstellen des Endpoints keine benutzerdefinierte Richtlinie AWS anhängen, hängt die folgende Standardrichtlinie an. Diese Richtlinie ermöglicht den uneingeschränkten Zugriff auf den Endpunkt.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] }
Um den Zugriff auf den Endpunkt einzuschränken, fügen Sie eine benutzerdefinierte Endpunktrichtlinie hinzu.
Wichtige Überlegungen für AWS STS VPC-Endpunktrichtlinien
AWS STS bearbeitet Anfragen von zwei grundlegend unterschiedlichen Anrufertypen. Ihre VPC-Endpunktrichtlinie muss beide Typen berücksichtigen, um zu verhindern, dass legitime Anfragen unbeabsichtigt blockiert werden.
- Authentifizierte Principals AWS
-
IAM-Benutzer und IAM-Rollen, die Anfragen mit AWS Signature Version 4 (Sigv4) signieren. Diese Aufrufer verfügen über Standardbedingungsschlüssel wie
aws:PrincipalOrgID, undaws:PrincipalAccount, die im Anforderungskontextaws:PrincipalArnverfügbar sind. - Föderierte Anrufer
-
SAML 2.0- und OpenID Connect (OIDC) -Prinzipale, die oder aufrufen.
AssumeRoleWithSAMLAssumeRoleWithWebIdentityDiese Anrufer authentifizieren sich mit SAML-Assertionen oder JSON Web Tokens (JWTs), nicht mit SigV4-Signaturen. Da sie zum Zeitpunkt der Anfrage keine AWS Identität haben, enthält der Anforderungskontext keine prinzipalbasierten Bedingungsschlüssel wie, und.aws:PrincipalOrgIDaws:PrincipalAccountaws:PrincipalArn
Wichtig
Wenn sich Ihre VPC-Endpunktrichtlinie ausschließlich darauf stützt, Zugriff aws:PrincipalOrgID zu gewähren, werden AssumeRoleWithSAML Verbund- und AssumeRoleWithWebIdentity Aufrufe implizit verweigert, da der Bedingungsschlüssel für Nicht-Hauptbenutzer fehlt.AWS
Wie AWS STS evaluiert VPC-Endpunktrichtlinien für Verbundanrufer
Wenn ein Verbundanrufer einen VPC-Endpunkt aufruft AssumeRoleWithSAML oder diesen nutzt, AssumeRoleWithWebIdentity gilt Folgendes:
-
Der Anrufer ist kein Principal. AWS Bedingungsschlüssel wie
aws:PrincipalOrgIDaws:PrincipalAccount, undaws:PrincipalArnsind im Anforderungskontext nicht verfügbar. -
Verbundanrufer haben den Bedingungsschlüssel
aws:PrincipalIsAWSServiceim Anforderungskontext nicht. -
Die übernommene Rolle ist eine AWS Ressource. Resource-based Bedingungsschlüssel wie
aws:ResourceOrgIDundaws:ResourceAccountsind verfügbar und beziehen sich auf die Zielrolle. -
Die Vertrauensrichtlinie der Rolle bleibt die primäre Autorisierungsstelle für den Verbundzugriff. Die VPC-Endpunktrichtlinie bietet eine zusätzliche Grenze auf Netzwerkebene.
Es wird empfohlen, aws:ResourceAccount beim Verfassen von VPC-Endpunktrichtlinien, die für Verbundanrufer gelten müssen, aws:ResourceOrgID oder beim Schreiben zu verwenden, da für diese Anrufer keine prinzipalbasierten Bedingungsschlüssel verfügbar sind.
Bedingungsschlüssel sind verfügbar für AWS STS VPC-Endpunktrichtlinien
Die folgende Tabelle zeigt häufig verwendete Bedingungsschlüssel und ihre Verfügbarkeit im Anforderungskontext für jeden Anrufertyp, wenn Anfragen über einen AWS STS VPC-Endpunkt gestellt werden. Neben den hier aufgeführten sind weitere Bedingungsschlüssel verfügbar.
Bedingungsschlüssel |
Authentifizierte Prinzipale AWS |
Föderierte Anrufer |
Description |
|---|---|---|---|
|
Ja |
Nein |
Die Organisations-ID des anrufenden Prinzipals |
|
Ja |
Nein |
Die Konto-ID des aufrufenden Prinzipals |
|
Ja |
Nein |
Die ARN des aufrufenden Prinzipals |
|
Ja (wird als falsch ausgewertet) |
Nein (Schlüssel fehlt) |
Ob der Anrufer ein AWS Service Principal ist |
|
Ja |
Ja |
Die Organisations-ID des Kontos, dem die angeforderte Ressource gehört |
|
Ja |
Ja |
Die Konto-ID, die die angeforderte Ressource besitzt |
Anmerkung
Ist für authentifizierte AWS Principals (IAM-Benutzer und -Rollen) im Anforderungskontext vorhanden und aws:PrincipalIsAWSService wird als falsch ausgewertet. Bei Verbundanrufern fehlt dieser Schlüssel vollständig im Anforderungskontext. Eine Bedingung, bei der geprüft "Bool":
{"aws:PrincipalIsAWSService": "false"} wird, dass sie nicht mit verbundenen Anrufern übereinstimmt, da der Schlüssel nicht vorhanden ist.
Beispiel: Alle zulassen AWS STS Aktionen für Ihre Organisation
Die folgende Endpunktrichtlinie beschränkt Ihren AWS STS VPC-Endpunkt auf Ihre Organisation und unterstützt gleichzeitig den Verbundzugriff. Sie ermöglicht alle AWS STS Aktionen für authentifizierte Principals in Ihrer Organisation und gestattet Verbundanrufern separat, Rollen innerhalb Ihrer Organisation zu übernehmen. Verbundanrufer (AssumeRoleWithSAMLundAssumeRoleWithWebIdentity) benötigen eine separate Anweisung, da sie im Anforderungskontext keine haben. aws:PrincipalOrgID
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOrganizationPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] }
In der ersten Anweisung wird "Principal": {"AWS": "*"} with verwendetaws:PrincipalOrgID, um authentifizierte AWS Hauptbenutzer aus Ihrer Organisation zuzulassen. Die zweite Anweisung dient "Principal": "*" dazu, Verbundanrufer zuzuordnen und beschränkt die Zielrolle auf die Verwendung durch Ihr Unternehmen. aws:ResourceOrgID Die Vertrauensrichtlinie der Rolle bleibt die primäre Steuerung dafür, welche föderierten Identitäten welche Rollen übernehmen können.
Weitere Informationen zur Implementierung von Netzwerkperimeterkontrollen finden Sie unter Aufbau eines Datenperimeters AWS und in den Beispielen für Datenumkreisrichtlinien auf der Website.
Beispiel: Alle zulassen AWS STS Aktionen für bestimmte Konten
Die folgende Endpunktrichtlinie ermöglicht alle AWS STS Aktionen für Hauptbenutzer in bestimmten Konten. Verwenden Sie diese Richtlinie, wenn Ihre Konten nicht Teil einer Organisation sind. Verbundanrufer sind in einer separaten Anweisung zulässig, da sie aws:PrincipalAccount im Anforderungskontext keinen haben.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSpecificAccountPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": [ "111122223333", "444455556666" ] } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": [ "111122223333", "444455556666" ] } } } ] }
In der ersten Anweisung wird "Principal": {"AWS": "*"} with verwendetaws:PrincipalAccount, um authentifizierte Hauptbenutzer aus den AWS angegebenen Konten zuzulassen. Die zweite Anweisung verwendet"Principal": "*", um Verbundanrufer zuzuordnen, und beschränkt die Zielrolle auf dieselben Konten, die verwendet werden. aws:ResourceAccount Die Vertrauensrichtlinie der Rolle bleibt die primäre Steuerung dafür, welche Verbundidentitäten welche Rollen übernehmen können.
Beispiel: Auf bestimmte beschränken AWS STS actions
Die folgende Endpunktrichtlinie lässt nur AssumeRole authentifizierte Hauptbenutzer und Verbundanrufer AssumeRoleWithSAML zu, die beide auf Rollen in Ihrer Organisation beschränkt sind.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRoleByOrgPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowSAMLFederation", "Effect": "Allow", "Principal": "*", "Action": "sts:AssumeRoleWithSAML", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] }
Diese Richtlinie blockiert andere AWS STS Aktionen wieGetCallerIdentity, GetSessionToken und über diesen Endpunkt. AssumeRoleWithWebIdentity Passen Sie die Action Elemente an Ihre Anforderungen an.
Beispiel: Verweigern Sie den Zugriff außerhalb der Organisation, während Sie den Verbund zulassen
Die folgende Endpunktrichtlinie verwendet eine explizite Verweigerung, um authentifizierte Prinzipale außerhalb Ihrer Organisation zu blockieren und gleichzeitig den Zugriff für Verbundanrufer beizubehalten. Dieser Ansatz beginnt mit einer allgemeinen Zulassung und fügt eine gezielte Ablehnungserklärung hinzu.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" }, { "Sid": "DenyNonOrgPrincipals", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } } ] }
Die Ablehnungsanweisung verwendet"Principal": {"AWS": "*"}, wodurch sie nur für authentifizierte AWS Hauptbenutzer gilt. Verbundanrufer (SAML und OIDC) sind keine AWS
Prinzipale und dieses Principal Element entspricht nicht, sodass die Ablehnung nicht auf sie zutrifft. Bei diesem Ansatz wird vermieden, dass komplexe Null oder Bool Bedingungen erforderlich sind, um Ausnahmen für Verbundanrufer festzulegen.
Anmerkung
Die erste Anweisung erlaubt alle Aktionen für alle Principals. Die Ablehnung in der zweiten Anweisung hat Vorrang für authentifizierte Hauptbenutzer außerhalb Ihrer AWS Organisation. Verbundanrufer sind nach der ersten Anweisung zugelassen und von der Ablehnung nicht betroffen, da das Principal Element in der Ablehnungsanweisung nicht mit ihnen übereinstimmt.