Auswertungslogik für Richtlinien

Wenn ein Auftraggeber versucht, die AWS Management Console, die AWS-API oder die AWS CLI zu verwenden, sendet dieser Auftraggeber eine Anforderung an AWS. Wenn ein AWS-Service die Anforderung erhält, führt AWS mehrere Schritte durch, um festzustellen, ob die Anforderung zugelassen oder abgelehnt werden soll.

1. Authentication (Authentifizierung) – AWS authentifiziert zunächst den Auftraggeber, der die Anforderung gesendet hat, falls erforderlich. Dieser Schritt ist für einige wenige Services, wie z. B. Amazon S3, die einige Anforderungen von anonymen Benutzern erlauben, nicht notwendig.

2. Verarbeitung des AnforderungskontextsAWSverarbeitet die in der Anforderung erfassten Informationen, um festzustellen, welche Richtlinien für die Anforderung gelten.

3. Auswerten von Richtlinien in einem einzelnen KontoAWSwertet alle Richtlinientypen aus, die die Reihenfolge, in der die Richtlinien ausgewertet werden, beeinflussen.

4. Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wirdAWSverarbeitet dann die Richtlinien anhand des Anforderungskontexts, um festzustellen, ob die Anforderung erlaubt oder abgelehnt wird.

Verarbeitung des Anforderungskontexts

AWS verarbeitet die Anforderung, um die folgenden Informationen in einem Anforderungskontext:

• Aktionen (oder Operationen) – Die Aktionen oder Operationen, die der Auftraggeber durchführen möchte.

• Ressourcen – Das AWS-Ressourcenobjekt, mit dem die Aktionen oder Vorgänge durchgeführt werden.

• Auftraggeber – Der Benutzer, die Rolle, der Verbundbenutzer oder die Anwendung, der bzw. die die Anfrage gesendet hat. Informationen über den Auftraggeber beinhalten die Richtlinien, die diesem Auftraggeber zugeordnet sind.

• Umgebungsdaten – Informationen über die IP-Adresse, den Benutzeragent, den SSL-Status oder die Tageszeit.

• Ressourcendaten – Daten zu den angeforderten Ressourcen. Dies sind zum Beispiel Informationen wie ein DynamoDB-Tabellenname oder Tag auf einer Amazon EC2-Instance.

AWS verwendet diese Informationen dann, um Richtlinien zu finden, die für den Anforderungskontext zutreffen.

Auswerten von Richtlinien in einem einzelnen Konto

Wie AWS Richtlinien auswertet, hängt von den Typen von Richtlinien ab, die für den Anforderungskontext gelten. Die folgenden Richtlinientypen, aufgelistet in der Reihenfolge ihrer Häufigkeit, stehen für die Verwendung in einem einzelnen AWS-Konto zur Verfügung. Weitere Informationen zu diesen Richtlinientypen finden Sie unter Berechtigungen und Richtlinien in IAM. Wie AWS die Richtlinien für den kontenübergreifenden Zugriff auswertet, erfahren Sie unter Logik für die kontenübergreifende Richtlinienauswertung.

1. Identitätsbasierte Richtlinien – Identitätsbasierte Richtlinien werden einer IAM-Identität (Benutzer, Benutzergruppe oder Rolle) angefügt und gewähren IAM-Entitäten (Benutzer und Rollen) Berechtigungen. Wenn nur identitätsbasierte Richtlinien auf eine Anforderung anwendbar sind, überprüft AWS all diese Richtlinien auf mindestens ein Allow.

2. Ressourcenbasierte Richtlinien - Ressourcenbasierte Richtlinien erteilen dem angegebenen Auftraggeber (Konto, Benutzer, Rolle und Prizipalsitzungen wie Rollensitzungen und IAM-Verbundbenutzer) Berechtigungen, die als Prinzipal angegeben werden. Die Berechtigungen definieren, welche Aktionen der Auftraggeber mit der Ressource, der die Richtlinie zugewiesen ist. durchführen kann. Wenn sowohl ressourcenbasierte Richtlinien als auch identitätsbasierte Richtlinien auf eine Anforderung anwendbar sind, überprüft AWS alle Richtlinien auf mindestens ein Allow. Wenn ressourcenbasierte Richtlinien ausgewertet werden, bestimmt der in der Richtlinie angegebene Haupt-ARN, ob implizite Ablehnung in anderen Richtlinientypen auf die endgültige Entscheidung anwendbar sind.

3. IAM-Berechtigungsgrenzen – Berechtigungsgrenzen sind eine erweiterte Funktionalität, die die maximalen Berechtigungen festlegt, die eine identitätsbasierte Richtlinie einer IAM-Entität (Benutzer oder Rolle) erteilen kann. Wenn Sie eine Berechtigungsgrenze für eine Entität festlegen, kann die Entität nur die Aktionen durchführen, die sowohl von den identitätsbasierten Richtlinien als auch den Berechtigungsgrenzen erlaubt werden. In einigen Fällen kann eine implizite Verweigerung in einer Berechtigungsgrenze die Berechtigungen nicht bechränken, die von einer ressourcenbasierten Richtlinie gewährt werden. Weitere Informationen finden Sie unter Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird weiter unten in diesem Thema.

4. AWS Organizations Service-Kontrollrichtlinien (Service Control Policies, SCPs) – -SCPs legen die maximalen Berechtigungen für eine Organisation oder Organisationseinheit (OU) fest. Das SCP-Maximum gilt für Prinzipale in Mitgliedskonten, einschließlich eines jeden Root-Benutzer des AWS-Kontos. Wenn eine SCP vorhanden ist, erteilen identitätsbasierte und ressourcenbasierte Richtlinien Auftraggeber in Mitgliedskonten nur dann Berechtigungen, wenn diese Richtlinien und die SCP die Aktion zulassen. Wenn sowohl eine Berechtigungsgrenze als auch eine SCP vorhanden sind, muss die Grenze, die SCP und die identitätsbasierte Richtlinie die Aktion zulassen.

5. Sitzungsrichtlinien – Sitzungsrichtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie eine temporäre Sitzung für eine Rolle oder einen Verbundbenutzer programmgesteuert erstellen. Um eine Rollensitzung programmgesteuert zu erstellen, verwenden Sie eine der AssumeRole*-API-Operationen. Wenn Sie dies tun und Richtlinien für die Sitzung übergeben, sind die resultierenden Sitzungsberechtigungen eine Schnittmenge der identitätsbasierten Richtlinie der IAM-Entität und der Sitzungsrichtlinien. Um eine Sitzung eines Verbundbenutzers zu erstellen, verwenden Sie die Zugriffsschlüssel eines IAM-Benutzers, um den API-Vorgang GetFederationToken programmatisch aufzurufen. Eine ressourcenbasierte Richtlinie hat andere Auswirkungen auf die Auswertung der Sitzungsrichtlinienberechtigungen. Der Unterschied hängt davon ab, ob der ARN des Benutzers oder der Sitzung in der ressourcenbasierten Richtlinie als Auftraggeber aufgeführt wird. Weitere Informationen finden Sie unter Sitzungsrichtlinien.

Denken Sie daran, dass eine explizite Zugriffsverweigerung in all diesen Richtlinien eine Zugriffserlaubnis überschreibt.

Auswerten identitätsbasierter Richtlinien mit ressourcenbasierten Richtlinien

Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien erteilen Identitäten oder Ressourcen, an die sie angefügt sind, Berechtigungen. Wenn eine IAM-Entität (Benutzer oder Rolle) Zugriff auf eine Ressource innerhalb desselben Kontos anfordert, wertet AWS all die Berechtigungen aus, die von den identitätsbasierten Richtlinien und den ressourcenbasierten Richtlinien erteilt wurden. Die so entstehenden Berechtigungen ergeben sich aus den gesamten Berechtigungen der beiden Typen. Wenn eine Aktion von einer identitätsbasierten Richtlinie, einer ressourcenbasierten Richtlinie oder von beiden erlaubt wird, dann lässt AWS die Aktion zu. Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis.

Auswerten von identitätsbasierten Richtlinien mit Berechtigungsgrenzen

Wenn AWS die identitätsbasierten Richtlinien und die Berechtigungsgrenze für einen Benutzer auswertet, sind die resultierenden Berechtigungen die Schnittmenge der beiden Kategorien. Das heißt, wenn Sie einem Benutzer mit bestehenden identitätsbasierten Richtlinien eine Berechtigungsgrenze hinzufügen, reduzieren Sie möglicherweise die Aktionen, die der Benutzer ausführen kann. Wenn Sie andererseits eine Berechtigungsgrenze von einem Benutzer entfernen, können Sie die Aktionen erweitern, die dieser ausführen kann. Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis. Informationen darüber, wie andere Richtlinientypen mit Berechtigungsgrenzen ausgewertet werden, finden Sie unter Auswerten von effektiven Berechtigungen mit Grenzen.

Bewertung von identitätsbasierten Richtlinien mit Organizations-SCPs

Wenn ein Benutzer zu einem Konto gehört, das Mitglied einer Organisation ist, bilden die resultierenden Berechtigungen eine Schnittmenge aus den Richtlinien des Benutzers und der SCP. Das bedeutet, dass eine Aktion sowohl von der identitätsbasierten Richtlinie als auch von der SCP erlaubt sein muss. Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis.

Sie können erfahren ob Ihr Konto als Mitgliedskonto einer Organisation in AWS Organizations eingerichtet ist. Eine SCP hat möglicherweise Auswirkungen auf Mitglieder einer Organisation. Zum Anzeigen der Daten mit dem AWS CLI-Befehl oder einer AWS-API-Operation, benötigen Sie Berechtigungen für die organizations:DescribeOrganization-Aktion für Ihre Organizations-Entität. Sie müssen über zusätzliche Berechtigungen verfügen, um die Operation in der Organizations-Konsole auszuführen. Wenden Sie sich an IhrenAWS Organizations-Administrator, wenn Sie wissen möchten, ob eine SCP den Zugriff auf eine bestimmte Anfrage verweigert oder wenn Sie Ihre effektiven Berechtigungen ändern möchten.

Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird

Angenommen, ein Auftraggeber sendet eine Anfrage an AWS, um auf eine Ressource in dem Konto zuzugreifen, in dem sich auch die Entität des Auftraggebers befindet. Der AWS-Durchführungscode entscheidet, ob die Anfrage zugelassen oder abgelehnt wird. AWS erfasst alle Richtlinien, die für den Anfragekontext gelten. Im Folgenden finden Sie einen allgemeine Überblick über die AWS-Auswertungslogik für diese Richtlinien innerhalb eines einzelnen Kontos.

• Standardmäßig werden alle Anforderungen implizit verweigert, mit Ausnahme des Root-Benutzer des AWS-Kontoss, der vollen Zugriff hat.

• Eine explizite Zugriffserlaubnis in einer identitätsbasierten oder ressourcenbasierten Richtlinie hat Vorrang vor diesem Standardwert.

• Wenn eine Berechtigungsgrenze, Organizations-SCP oder Sitzungsrichtlinie vorhanden ist, kann sie die Zugriffserlaubnis mit einer impliziten Zugriffsverweigerung überschreiben.

• Eine explizite Zugriffsverweigerung überschreibt jede Zugriffserlaubnis in einer Richtlinie.

Das folgende Flussdiagramm enthält einen Überblick über den Entscheidungsprozess. Dieses Flussdiagramm deckt nicht die Auswirkungen ressourcenbasierter Richtlinien und impliziter Ablehnungen in anderen Arten von Richtlinien ab.

1. Auswertung für eine Zugriffsverweigerung – Standardmäßig werden alle Anforderungen verweigert. Dieser Vorgang wird als implizite Zugriffsverweigerung bezeichnet. Durch den AWS-Durchführungscode werden alle Richtlinien innerhalb des Kontos ausgewertet, die auf die Anforderung zutreffen. Darunter fallen AWS Organizations-SCPs, ressourcenbasierte Richtlinien, IAM-Berechtigungsgrenzen und Sitzungsrichtlinien. Der Durchführungscode sucht in allen diesen Richtlinien nach einer Deny-Anweisung, die für die Anforderung gilt. Dieser Vorgang wird als explizite Zugriffsverweigerung bezeichnet. Wenn der Code auch nur eine gültige explizite Zugriffsverweigerung findet, wird final Zugriffsverweigerung zurückgegeben und die Anforderung wird abgelehnt. Wenn es keine ausdrückliche Verweigerung gibt, wird die Auswertung des Erzwingungscodes fortgesetzt.

2. Organisations-SCPs – Der Code wertet dann AWS Organizations-Service-Kontrollrichtlinien (SCPs) aus, die für die Anforderung gelten. SCPs gelten für Auftraggeber des Kontos, dem die SCPs zugewiesen sind. Wenn der Durchführungscode keine gültigen Allow-Anweisungen in den SCPs findet, wird die Anforderung explizit abgelehnt, selbst wenn die Ablehnung implizit ist. Der Code gibt die finale Entscheidung Zugriffsverweigerung zurück. Wenn keine SCP vorhanden ist oder wenn die SCP die angeforderte Aktion zulässt, wird die Erzwingungscodeauswertung fortgesetzt.

3. Ressourcenbasierte Richtlinien - Innerhalb desselben Kontos wirken sich ressourcenbasierte Richtlinien unterschiedlich aus, abhängig von der Art des Prinzipals, der auf die Ressource zugreift, und dem Prinzipal, der in der ressourcenbasierten Richtlinie zulässig ist. Abhängig von der Art des Prinzipals, kann ein Allow in einer ressourcenbasierten Richtlinie zu einer endgültigen Entscheidung von Allow führen, auch wenn eine implizite Ablehnung in einer identitätsbasierten Richtlinie, Berechtigungsgrenze oder Sitzungsrichtlinie vorhanden ist.

   Für die meisten Ressourcen benötigen Sie nur eine explizite Genehmigung für den Prinzipal entweder in einer identitätsbasierten Richtlinie oder in einer ressourcenbasierten Richtlinie, um Zugriff zu gewähren. IAM-Rollenvertrauensrichtlinien und KMS-Schlüsselrichtlinien sind Ausnahmen von dieser Logik, da sie den Zugriff für Auftraggeber ausdrücklich zulassen müssen.

   Die ressourcenbasierte Richtlinienlogik unterscheidet sich von anderen Richtlinientypen, wenn der angegebene Prinzipal ein IAM-Benutzer, eine IAM-Rolle oder ein Sitzungsprinzipal ist. Zu den Sitzungsprinzipalen gehören IAM-Rollensitzungen oder ein IAM-Verbundbenutzer-Sitzung. Wenn eine ressourcenbasierte Richtlinie dem IAM-Benutzer oder dem Sitzungssprinzipal, der die Anforderung stellt, die Berechtigung direkt erteilt, wirkt sich eine implizite Ablehnung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie nicht auf die endgültige Entscheidung aus.

   Die folgende Tabelle hilft Ihnen, die Auswirkungen ressourcenbasierter Richtlinien für verschiedene Haupttypen zu verstehen, wenn implizite Ablehnungen in identitätsbasierten Richtlinien, Berechtigungsgrenzen und Sitzungsrichtlinien implizite Ablehnungen vorhanden sind.

   Ressourcenbasierte Richtlinien und implizite Verweigerungen in anderen Richtlinientypen (dasselbe Konto)
   Prinzipal, der die Anforderung stellt	Ressourcenbasierte Richtlinie	Identitätsbasierte Richtlinien	Berechtigungsgrenze	Sitzungsrichtlinie	Ergebnis	Grund
   IAM role (IAM-Rolle)	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Eine Rolle selbst kann keine Anfrage stellen. Anfragen werden mit der Rollensitzung gestellt, nachdem eine Rolle angenommen wurde.
   IAM-Rollensitzung	Erlaubt -Rollen-ARN	Implizite Verweigerung	Implizite Verweigerung	Implizite Verweigerung	DENY	Berechtigungsgrenze und Sitzungsrichtlinie werden im Rahmen der endgültigen Entscheidung ausgewertet. Eine implizite Ablehnung in beiden Richtlinien führt zu einer VERWEIGERN-Entscheidung.
   IAM-Rollensitzung	Erlaubt Rollensitzungs-ARN	Implizite Verweigerung	Implizite Verweigerung	Implizite Verweigerung	ERLAUBEN	Berechtigungen werden direkt für die Sitzung erteilt. Andere Richtlinientypen haben keinen Einfluss auf die Entscheidung.
   IAM-Benutzer	Ermöglicht ARN für IAM-Benutzer	Implizite Verweigerung	Implizite Verweigerung	Nicht zutreffend	ERLAUBEN	Berechtigungen werden direkt an den Benutzer erteilt. Andere Richtlinientypen haben keinen Einfluss auf die Entscheidung.
   IAM-Verbundbenutzer (GetFederationToken)	Ermöglicht ARN für IAM-Benutzer	Implizite Verweigerung	Implizite Verweigerung	Implizite Verweigerung	DENY	Eine implizite Verweigerung in der Berechtigungsgrenze oder in der Sitzungsrichtlinie führt zu einem VERWEIGERN.
   IAM-Verbundbenutzer (GetFederationToken)	Ermöglicht ARN für IAM-Verbundbenutzersitzungen	Implizite Verweigerung	Implizite Verweigerung	Implizite Verweigerung	ERLAUBEN	Berechtigungen werden direkt für die Sitzung erteilt. Andere Richtlinientypen haben keinen Einfluss auf die Entscheidung.
   Root-Benutzer	Ermöglicht ARN für Stammbenutzer	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	ERLAUBEN	Das Root-Konto hat vollständigen und uneingeschränkten Zugriff auf alle Ressourcen in Ihrem AWS-Konto. Um zu erfahren, wie Sie den Zugriff auf Root-Benutzer für Konten in AWS Organizations kontrollieren können, finden Sie unter Service-Kontrollrichtlinien (SCPs) im Benutzerhandbuch für Organisationen.
   AWS-Service-Prinzipal	Ermöglicht eineAWS-Service-Prinzipal	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	ERLAUBEN	Wenn eine ressourcenbasierte Richtlinie Berechtigungen direkt an AWS-Service-Prinzipal erteilen, haben andere Richtlinientypen keinen Einfluss auf die Entscheidung.

   • IAM-Rolle - Ressourcenbasierte Richtlinien, die Berechtigungen für eine IAM-Rolle ARN erteilen, sind durch eine implizite Verweigerung in einer Berechtigungsgrenze oder einer Sitzungsrichtlinie begrenzt.

     Beispielrolle ARN

     arn:aws:iam::111122223333:role/examplerole

   • IAM-Rollensitzung – Innerhalb desselben Kontos gewähren ressourcenbasierte Richtlinien, die einem IAM-Rollensitzungs-ARN Berechtigungen erteilen, auch direkt Berechtigungen für die angenommene Rollensitzung. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt. Wenn Sie eine Rolle übernehmen und eine Anfrage stellen, ist der Prinzipal, der die Anfrage stellt, der ARN der IAM-Rollensitzung und nicht der ARN der Rolle selbst.

     Beispiel für eine Rollensitzung ARN

     arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

   • IAM-Benutzer - Innerhalb desselben Kontos sind ressourcenbasierte Richtlinien, die einem IAM-Benutzer-ARN (das kein Verbundbenutzersitzung ist) Berechtigungen erteilt, nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie oder Berechtigungsgrenze beschränkt.

     Beispiel eines IAM-Benutzer-ARN

     arn:aws:iam::111122223333:user/exampleuser

   • IAM-Verbundbenutzersitzung – Eine IAM-Verbundbenutzersitzung ist eine Sitzung, die durch Aufruf von GetFederationToken erstellt wurde. Wenn ein Verbundbenutzer eine Anfrage stellt, ist der Prinzipal, der die Anfrage stellt, der ARN des Verbundbenutzers und nicht der ARN des IAM-Benutzers, der den Verbund erstellt hat. Innerhalb desselben Kontos erteilen ressourcenbasierte Richtlinien, die einem Verbundbenutzer-ARN Berechtigungen gewähren, der Sitzung direkt Berechtigungen. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt.

     Wenn jedoch eine ressourcenbasierte Richtlinie dem ARN des IAM-Benutzers, der den Verbund erstellt hat, die Berechtigung erteilt, werden Anfragen des Verbundbenutzers während der Sitzung durch eine implizite Verweigerung in einer Berechtigungsgrenze oder Sitzungsrichtlinie eingeschränkt.

     Beispiel für IAM-Verbundbenutzersitzung ARN

     arn:aws:sts::111122223333:federated-user/exampleuser

4. Identitätsbasierte Richtlinien – Der Code überprüft dann die identitätsbasierten Richtlinien auf den Auftraggeber. Für einen IAM-Benutzer gehören hierzu Benutzerrichtlinien und Richtlinien von Gruppen, zu denen der Benutzer gehört. Wenn es keine Anweisungen gibt, die die angeforderte Aktion zulassen, dann wird die Anforderung implizit verweigert und der Code gibt die finale Entscheidung Deny (Zugriffsverweigerung) zurück. Wenn eine Anweisung in einer geltenden identitätsbasierten Richtlinie die angeforderte Aktion zulässt, dann wird der Code weitergeführt.

5. IAM-Berechtigungsgrenzen - Der Durchführungscode überprüft dann, ob die IAM-Entität, die vom Auftraggeber verwendet wird, eine Berechtigungsgrenze aufweist. Wenn die Richtlinie, die verwendet wird, um die Berechtigungsgrenze festzulegen, die angeforderte Aktion nicht zulässt, dann wird die Anforderung implizit verweigert. Der Code gibt die finale Entscheidung Deny (Zugriffsverweigerung) zurück. Wenn es keine Berechtigungsgrenze gibt oder wenn die Berechtigungsgrenze die angeforderte Aktion zulässt, wird der Code fortgesetzt.

6. Sitzungsrichtlinien – Der Code überprüft dann, ob der Prinzipal ein Sitzungsprinzipal ist. Sitzungsprinzipale umfassen eine IAM-Rollensitzung oder eine IAM-Verbundbenutzersitzung. Wenn der Prinzipal kein Sitzungsprinzipal ist, gibt der Durchsetzungscode eine endgültige Entscheidung vonErlauben zurück.

   Für Sitzungsprinzipale, der Code prüft, ob eine Sitzungsrichtlinie in der Anforderung übergeben wurde. Sie können eine Sitzungsrichtlinie während der Verwendung der AWS CLI oder der AWS-API übergeben, um temporäre Anmeldeinformationen für eine Rolle oder einen IAM-Vebundbenutzer zu erhalten.

   • Wenn die Sitzungsrichtlinie vorhanden ist und die angeforderte Aktion nicht zulässt, dann wird die Anforderung implizit verweigert. Der Code gibt die finale Entscheidung Deny (Zugriffsverweigerung) zurück.

   • Wenn keine Sitzungsrichtlinie vorhanden ist, prüft der Code, ob der Prinzipal eine Rollensitzung ist. Wenn der Prinzipal eine Rollensitzung ist, lautet die Anforderung Erlaubt. Daher wird die Anforderung implizit abgelehnt und der Code gibt eine endgültige Entscheidung von Verweigern zurück.

   • Wenn eine Sitzungsrichtlinie vorhanden ist und die angeforderte Aktion erlaubt, dann gibt der Durchführungscode eine endgültige Entscheidung von Erlauben zurück.

7. Fehler – Wenn der AWS-Durchführungscode zu irgendeinem Zeitpunkt während der Auswertung auf einen Fehler stößt, erzeugt er eine Ausnahme und wird beendet.

Beispielauswertung identitätsbasierter Richtlinien und ressourcenbasierter Richtlinien

Die gebräuchlichsten Richtlinientypen sind identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien. Wenn Zugriff auf eine Ressource angefordert wird, wertet AWS alle Berechtigungen aus, die durch die Richtlinien für mindestens ein Allow innerhalb desselben Kontos gewährt wurden. Eine explizite Zugriffsverweigerung in einer der Richtlinien setzt eine Zugriffserlaubnis außer Kraft.

Wichtig

Wenn entweder die identitätsbasierte Richtlinie oder die ressourcenbasierte Richtlinie innerhalb desselben Kontos die Anforderung zulässt und die andere nicht, ist die Anforderung trotzdem zulässig.

Angenommen, Carlos hat den Benutzernamen carlossalazar, und er versucht, eine Datei im Amazon S3-Bucket carlossalazar-logs zu speichern.

Außerdem wird davon ausgegangen, dass die folgende Richtlinie dem IAM-Benutzer carlossalazar zugeordnet ist.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

Die AllowS3ListRead -Anweisung in dieser Richtlinie erlaubt Carlos, eine Liste aller Buckets im Konto anzuzeigen. Die AllowS3Self-Anweisung erlaubt Carlos vollständigen Zugriff auf den Bucket mit demselben Namen wie seinem Benutzernamen. Die DenyS3Logs-Anweisung verweigert Carlos den Zugriff auf S3-Buckets mit der Zeichenfolge log im Namen.

Außerdem ist die folgende ressourcenbasierte Richtlinie (eine sogenannte Bucket-Richtlinie) dem Bucket carlossalazar zugeordnet.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

Diese Richtlinie gibt an, dass nur der Benutzer carlossalazar auf den Bucket carlossalazar zugreifen kann.

Wenn Carlos seine Anforderung sendet, eine Datei im Bucket carlossalazar-logs zu speichern, bestimmt AWS, welche Richtlinien für die Anforderung gelten. In diesem Fall gelten nur die identitätsbasierte Richtlinie und die ressourcenbasierte Richtlinie. Beides sind Berechtigungsrichtlinien. Da keine Berechtigungsgrenzen gelten, wird die Auswertungslogik auf die folgende Logik reduziert.

AWS sucht zunächst nach einer Deny-Anweisung, die für den Kontext der Anforderung gilt. Es findet einen, weil die identitätsbasierte Richtlinie Carlos explizit den Zugriff auf alle S3-Buckets verweigert, die für die Protokollierung verwendet werden. Carlos wird der Zugriff verweigert.

Angenommen, er erkennt dann seinen Fehler und versucht, die Datei in den Bucket carlossalazar zu speichern. AWS sucht nach einer Deny-Anweisung und findet keine. Dann überprüft es die Berechtigungsrichtlinien. Sowohl die identitätsbasierte Richtlinie, als auch die ressourcenbasierte Richtlinie lassen die Anforderung zu. Daher lässt AWS die Anforderung zu. Hätte eine von ihnen die Anweisung ausdrücklich abgelehnt, wäre die Anforderung abgelehnt worden. Wenn einer der Richtlinientypen die Anforderung zulässt und der andere nicht, ist die Anforderung weiterhin zulässig.

Der Unterschied zwischen expliziten und impliziten Zugriffsverweigerungen

Eine Anforderung führt zu einer expliziten Zugriffsverweigerung, wenn eine anwendbare Richtlinie eine Deny-Anweisung enthält. Wenn Richtlinien, die auf eine Anforderung anwendbar sind, eine Allow-Anweisung und eine Deny-Anweisung enthalten, übersteuert die Deny -Anweisung die Allow -Anweisung. Die Anforderung wird abgelehnt.

Eine implizite Verweigerung tritt auf, wenn es keine entsprechende Deny-Anweisung, aber auch keine anwendbare Allow-Anweisung gibt. Da einem IAM-Prinzipal standardmäßig der Zugriff verweigert wird, muss ihm explizit erlaubt werden, eine Aktion auszuführen. Andernfalls wird ihnen der Zugriff implizit verweigert.

Bei der Planung Ihrer Autorisierungsstrategie müssen Sie Richtlinien mit Allow-Anweisungen erstellen, um Ihren Auftraggeber zu gestatten, erfolgreich Anforderungen durchzuführen. Sie können jedoch eine beliebige Kombination von expliziten und impliziten Zugriffsverweigerungen wählen.

Sie können beispielsweise die folgende Richtlinie erstellen, die zulässige Aktionen, implizit verweigerte Aktionen und explizit verweigerte Aktionen enthält. Die AllowGetList-Aussage erlaubt Lesezugriff auf IAM-Aktionen, die mit den Präfixen Get und List beginnen. Alle anderen Aktionen in IAM, wie iam:CreatePolicy sind implizit abgelehnt. Die DenyReports-Aussage verweigert explizit Zugriff auf IAM-Berichte durch Verweigern des Zugriffs auf Aktionen, die den Report-Suffix, wie iam:GetOrganizationsAccessReport enthalten. Wenn jemand diesem Prinzipal eine andere Richtlinie hinzufügt, um ihm Zugriff auf IAM-Berichte zu gewähren, z. B. iam:GenerateCredentialReport, werden berichtsbezogene Anfragen aufgrund dieser ausdrücklichen Ablehnung immer noch abgelehnt.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}