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. # Steuern Sie den Zugriff auf AWS STS mit VPC-Endpunktrichtlinien Wenn Sie einen VPC-Schnittstellen-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 den uneingeschränkten Zugriff auf alle AWS STS Aktionen ermöglicht. VPC-Endpunktrichtlinien gewähren keine eigenständigen Berechtigungen. Sie bilden eine zusätzliche Grenze, die mit anderen Richtlinien einhergeht. 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](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) im *Amazon VPC-Benutzerhandbuch*. **Topics** + [Standard-VPC-Endpunktrichtlinie](#reference_sts_vpc_endpoint_policies_default) + [Wichtige Überlegungen für AWS STS VPC-Endpunktrichtlinien](#reference_sts_vpc_endpoint_policies_considerations) + [Bedingungsschlüssel sind verfügbar für AWS STS VPC-Endpunktrichtlinien](#reference_sts_vpc_endpoint_policies_condition_keys) + [Beispiel: Alle zulassen AWS STS Aktionen für Ihre Organisation](#reference_sts_vpc_endpoint_policies_example_org) + [Beispiel: Alles zulassen AWS STS Aktionen für bestimmte Konten](#reference_sts_vpc_endpoint_policies_example_accounts) + [Beispiel: Beschränken Sie sich auf bestimmte AWS STS actions](#reference_sts_vpc_endpoint_policies_example_actions) + [Beispiel: Verweigern Sie organisationsfremden Benutzern den Zugriff und erlauben Sie gleichzeitig den Verbund](#reference_sts_vpc_endpoint_policies_example_deny) ## Standard-VPC-Endpunktrichtlinie Wenn Sie bei der Erstellung des Endpunkts keine benutzerdefinierte Richtlinie AWS anhängen, wird die folgende Standardrichtlinie angehängt. Diese Richtlinie ermöglicht 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 Anrufer verfügen über Standardbedingungsschlüssel wie `aws:PrincipalOrgID``aws:PrincipalAccount`, und `aws:PrincipalArn` sind im Anforderungskontext verfügbar. **Verbundene Anrufer** SAML 2.0- und OpenID Connect (OIDC) -Prinzipale, die oder aufrufen. `AssumeRoleWithSAML` `AssumeRoleWithWebIdentity` Diese 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:PrincipalOrgID` `aws:PrincipalAccount` `aws:PrincipalArn` **Wichtig** Wenn sich Ihre VPC-Endpunktrichtlinie ausschließlich darauf `aws:PrincipalOrgID` stützt, Zugriff zuzulassen, werden `AssumeRoleWithSAML` Verbund- und `AssumeRoleWithWebIdentity` Aufrufe implizit verweigert, da der Bedingungsschlüssel für Nichtprinzipale fehlt.AWS ### Wie AWS STS bewertet VPC-Endpunktrichtlinien für Verbundaufrufer Wenn ein Verbundaufrufer einen VPC-Endpunkt aufruft `AssumeRoleWithSAML` oder `AssumeRoleWithWebIdentity` über einen VPC-Endpunkt verwendet, gilt Folgendes: + Der Anrufer ist kein Principal. AWS Bedingungsschlüssel wie `aws:PrincipalOrgID``aws:PrincipalAccount`, und `aws:PrincipalArn` sind im Anforderungskontext nicht verfügbar. + Verbundene Anrufer verfügen nicht über den Bedingungsschlüssel `aws:PrincipalIsAWSService` im Anforderungskontext. + Bei der Rolle, die übernommen wird, handelt es sich um eine Ressource AWS . Resource-based Bedingungsschlüssel wie `aws:ResourceOrgID` und `aws:ResourceAccount` sind verfügbar und beziehen sich auf die Zielrolle. + Die Vertrauensrichtlinie der Rolle bleibt das primäre Autorisierungstor für den Verbundzugriff. Die VPC-Endpunktrichtlinie bietet eine zusätzliche Grenze auf Netzwerkebene. Wir empfehlen, `aws:ResourceAccount` beim Schreiben von VPC-Endpunkt-Richtlinienanweisungen, die für Verbundaufrufer gelten müssen, `aws:ResourceOrgID` oder 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. **Verfügbarkeit der Bedingungsschlüssel nach Anrufertyp** | Bedingungsschlüssel | Authentifizierte AWS Principals | Verbundene Anrufer | Description | | --- | --- | --- | --- | | `aws:PrincipalOrgID` | Ja | Nein | Die Organisations-ID des anrufenden Prinzipals | | `aws:PrincipalAccount` | Ja | Nein | Die Konto-ID des anrufenden Prinzipals | | `aws:PrincipalArn` | Ja | Nein | Der ARN des aufrufenden Prinzipals | | `aws:PrincipalIsAWSService` | Ja (wird als falsch ausgewertet) | Nein (Schlüssel fehlt) | Ob der Anrufer ein AWS Service Principal ist | | `aws:ResourceOrgID` | Ja | Ja | Die Organisations-ID des Kontos, dem die angeforderte Ressource gehört | | `aws:ResourceAccount` | Ja | Ja | Die Konto-ID, der die angeforderte Ressource gehört | **Anmerkung** Bei authentifizierten AWS Principals (IAM-Benutzer und -Rollen) `aws:PrincipalIsAWSService` ist sie im Anforderungskontext vorhanden und wird als falsch ausgewertet. Bei Verbundaufrufern fehlt dieser Schlüssel vollständig im Anforderungskontext. Eine Bedingung, die überprüft, ob `"Bool": {"aws:PrincipalIsAWSService": "false"}` sie nicht auf Verbundaufrufer passt, weil 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 ermöglicht es Verbundaufrufern separat, Rollen innerhalb Ihrer Organisation zu übernehmen. Verbundene Anrufer (`AssumeRoleWithSAML`und`AssumeRoleWithWebIdentity`) benötigen eine separate Anweisung, da sie in der Anfrage keinen Kontext 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" } } } ] } ``` Die erste Anweisung verwendet `"Principal": {"AWS": "*"}` with, `aws:PrincipalOrgID` um authentifizierte AWS Principals aus Ihrer Organisation zuzulassen. Die zweite Anweisung verwendet`"Principal": "*"`, um Verbundaufrufer zuzuordnen und beschränkt die Zielrolle auf die Verwendung durch Ihre Organisation. `aws:ResourceOrgID` Die Vertrauensrichtlinie der Rolle bleibt die primäre Kontrolle, für die föderierte Identitäten welche Rollen übernehmen können. Weitere Informationen zur Implementierung von Netzwerkperimeterkontrollen finden Sie auf der Website unter [Aufbau eines Datenperimeters auf AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) und Beispiele für [Richtlinien zur Datenperimeterbegrenzung](https://github.com/aws-samples/data-perimeter-policy-examples). GitHub ## Beispiel: Alles zulassen AWS STS Aktionen für bestimmte Konten Die folgende Endpunktrichtlinie erlaubt alle AWS STS Aktionen für Prinzipale in bestimmten Konten. Verwenden Sie diese Richtlinie, wenn Ihre Konten nicht Teil einer Organisation sind. Verbundene Anrufer sind in einer separaten Erklärung zulässig, da sie `aws:PrincipalAccount` in der Anfrage keinen Kontext 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" ] } } } ] } ``` Die erste Anweisung verwendet `"Principal": {"AWS": "*"}` with, `aws:PrincipalAccount` um authentifizierte AWS Principals von den angegebenen Konten aus zuzulassen. Die zweite Anweisung verwendet`"Principal": "*"`, um Verbundaufrufer zuzuordnen und beschränkt die Zielrolle auf dieselben Konten mithilfe von. `aws:ResourceAccount` Die Vertrauensrichtlinie der Rolle bleibt die primäre Kontrolle, für die föderierte Identitäten welche Rollen übernehmen können. ## Beispiel: Beschränken Sie sich auf bestimmte AWS STS actions Die folgende Endpunktrichtlinie erlaubt nur `AssumeRole` authentifizierte Principals und `AssumeRoleWithSAML` Verbundanrufer, wobei beide Rollen in Ihrer Organisation zugewiesen 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 wie`GetCallerIdentity`, `GetSessionToken` und über diesen Endpunkt. `AssumeRoleWithWebIdentity` Passen Sie die `Action` Elemente an Ihre Anforderungen an. ## Beispiel: Verweigern Sie organisationsfremden Benutzern den Zugriff und erlauben Sie gleichzeitig den Verbund Die folgende Endpunktrichtlinie verwendet eine ausdrückliche Ablehnung, um authentifizierte Principals außerhalb Ihrer Organisation zu blockieren, während der Zugriff für Verbundanrufer erhalten bleibt. Dieser Ansatz beginnt mit einer umfassenden Zulassung und fügt eine gezielte Ablehnungsklausel 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 Deny-Anweisung verwendet`"Principal": {"AWS": "*"}`, wodurch sie nur authentifizierten AWS Prinzipalen zur Verfügung steht. Verbundaufrufer (SAML und OIDC) sind keine AWS Principals und werden von diesem `Principal` Element nicht abgeglichen. Daher gilt die Ablehnung nicht für sie. Dieser Ansatz vermeidet die Notwendigkeit komplexer `Null` oder `Bool` bedingter Ausnahmeregelungen für verbundene Anrufer. **Anmerkung** Die erste Anweisung erlaubt alle Aktionen für alle Principals. Die Ablehnung in der zweiten Anweisung hat Vorrang für authentifizierte AWS Prinzipale außerhalb Ihrer Organisation. Verbundene Anrufer sind bei der ersten Anweisung zugelassen und von der Ablehnung nicht betroffen, da das `Principal` Element in der Ablehnungsanweisung nicht mit ihnen übereinstimmt.