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.

IAMJSONpolitische Elemente: Bedingungsoperatoren

Verwenden Sie Bedingungsoperatoren im Condition-Element, um den Bedingungsschlüssel und -wert in der Richtlinie mit den Werten im Anforderungskontext abzugleichen. Weitere Informationen zum Condition-Element finden Sie unter IAMJSONpolitische Elemente: Condition.

Der Bedingungsoperator, den Sie in einer Richtlinie verwenden können, hängt vom ausgewählten Bedingungsschlüssel ab. Sie können einen globalen Bedingungsschlüssel oder einen servicespezifischen Bedingungsschlüssel auswählen. Informationen dazu, welchen Bedingungsoperator Sie für einen globalen Bedingungsschlüssel verwenden können, finden Sie unter AWS Kontextschlüssel für globale Bedingungen. Informationen darüber, welchen Bedingungsoperator Sie für einen dienstspezifischen Bedingungsschlüssel verwenden können, finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste und wählen Sie den Dienst aus, den Sie sich ansehen möchten.

Die Bedingungsoperatoren können in folgende Kategorien gruppiert werden:

Bedingungsoperatoren für Zeichenfolgen

Mit String-Bedingungsoperatoren können Sie Condition-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem Zeichenfolgewert einschränken.

Zum Beispiel enthält die folgende Anweisung ein Condition-Element, das den aws:PrincipalTag-Schlüssel verwendet, um anzugeben, dass der anfordernde Prinzipal mit der iamuser-admin-Aufgabenkategorie getaggt sein muss.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/*",
    "Condition": {"StringEquals": {"aws:PrincipalTag/job-category": "iamuser-admin"}}
  }
}

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. In diesem Beispiel ist der aws:PrincipalTag/job-category Schlüssel im Anforderungskontext vorhanden, wenn der Principal einen IAM Benutzer mit angehängten Tags verwendet. Er ist auch für einen Prinzipal enthalten, der eine IAM Rolle mit angehängten Tags oder Sitzungs-Tags verwendet. Wenn ein Benutzer ohne das Tag versucht, einen Zugriffsschlüssel anzuzeigen oder zu bearbeiten, gibt die Bedingung false zurück und die Anforderung wird durch diese Anweisung implizit abgelehnt.

Sie können eine Richtlinienvariable mit dem StringBedingungsoperator verwenden.

Im folgenden Beispiel wird der StringLike Bedingungsoperator verwendet, um einen Zeichenkettenabgleich mit einer Richtlinienvariablen durchzuführen, um eine Richtlinie zu erstellen, die es einem IAM Benutzer ermöglicht, sein eigenes „Home-Verzeichnis“ in einem Amazon S3-Bucket mit der Amazon S3-Konsole zu verwalten. Die Richtlinie lässt die angegebenen Aktionen für ein S3-Bucket zu, solange s3:prefix einem angegebenen Muster entspricht.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
      "Condition": {"StringLike": {"s3:prefix": [
        "",
        "home/",
        "home/${aws:username}/"
      ]}}
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
        "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
      ]
    }
  ]
}

Ein Beispiel für eine Richtlinie, die zeigt, wie das Condition Element verwendet wird, um den Zugriff auf Ressourcen auf der Grundlage einer Anwendungs-ID und einer Benutzer-ID für den OIDC Verbund einzuschränken, finden Sie unterAmazon S3: Ermöglicht Amazon Cognito-Benutzern den Zugriff auf Objekte in ihrem Bucket.

Platzhalterabgleich

Operatoren für Zeichenfolgenbedingungen führen einen musterlosen Abgleich durch, der kein vordefiniertes Format erzwingt. ARNund Operatoren für Datumsbedingungen sind eine Teilmenge von Zeichenkettenoperatoren, die eine Struktur für den Bedingungsschlüsselwert erzwingen. Wenn Sie StringNotLike Operatoren StringLike oder für teilweise übereinstimmende Zeichenfolgen eines ARN Or-Datums verwenden, wird beim Abgleich ignoriert, welcher Teil der Struktur Platzhalter enthält.

Die folgenden Bedingungen suchen beispielsweise ARN mithilfe verschiedener Bedingungsoperatoren nach einer teilweisen Übereinstimmung mit einem.

Wenn verwendet ArnLike wird, müssen die Partition, der Dienst, die Konto-ID, der Ressourcentyp und der Teil der Ressourcen-ID exakt mit dem im ARN Anforderungskontext übereinstimmen. ARN Nur die Region und der Ressourcenpfad lassen einen teilweisen Abgleich zu.

"Condition": {"ArnLike": {"aws:SourceArn": "arn:aws:cloudtrail:*:111122223333:trail/*"}}

Wenn anstelle von verwendet StringLike wird ArnLike, ignoriert der Abgleich die ARN Struktur und ermöglicht einen teilweisen Abgleich, unabhängig davon, welcher Teil mit einem Platzhalter versehen wurde.

"Condition": {"StringLike": {"aws:SourceArn": "arn:aws:cloudtrail:*:111122223333:trail/*"}}

Numerische Bedingungsoperatoren

Mit numerischen Bedingungsoperatoren können Sie Condition-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem Ganzzahl- oder Dezimalzahlwert einschränken.

Die folgende Anweisung enthält beispielsweise ein Condition-Element, das den Bedingungsoperator NumericLessThanEquals mit dem Schlüssel s3:max-keys enthält, um anzugeben, dass der Anforderer bis zu 10 Objekte gleichzeitig im amzn-s3-demo-bucket aufnehmen kann.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
  }
}

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. In diesem Beispiel ist der s3:max-keys-Schlüssel immer in der Anforderung vorhanden, wenn Sie die Operation ListBucket ausführen. Wenn diese Richtlinie alle Amazon S3-Operationen zulässt, sind nur die Operationen zulässig, die den max-keys-Kontextschlüssel mit einem Wert von kleiner oder gleich 10 enthalten.

Sie können eine Richtlinienvariable mit dem NumericBedingungsoperator verwenden.

Bedingungsoperatoren für Datum

Mit Date-Bedingungsoperatoren können Sie Condition-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem Datums-/Uhrzeitwert einschränken. Diese Bedingungsoperatoren werden mit dem Schlüssel aws:CurrentTime oder aws:EpochTime verwendet. Sie müssen Datums-/Uhrzeitwerte mit einer der W3C-Implementierungen der ISO 8601-Datumsformate oder in epoch () -Zeit angeben. UNIX

Beispielsweise enthält die folgende Anweisung ein Condition-Element, das den Bedingungsoperator DateGreaterThan mit dem aws:TokenIssueTime-Schlüssel verwendet. Diese Bedingung gibt an, dass die temporären Sicherheitsanmeldeinformationen, die für die Anforderung verwendet wurden, im Jahr 2020 ausgegeben wurden. Diese Richtlinie kann täglich programmgesteuert aktualisiert werden, um sicherzustellen, dass Kontomitglieder neue Anmeldeinformationen verwenden.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/*",
    "Condition": {"DateGreaterThan": {"aws:TokenIssueTime": "2020-01-01T00:00:01Z"}}
  }
}

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der aws:TokenIssueTime-Schlüssel ist im Anforderungskontext nur dann vorhanden, wenn der Auftraggeber temporäre Anmeldeinformationen für die Anforderung verwendet. Der Schlüssel ist nicht vorhanden in AWS CLI, AWS API, oder AWS SDKAnfragen, die unter Verwendung von Zugriffsschlüsseln gestellt werden. Wenn in diesem Beispiel ein IAM Benutzer versucht, einen Zugriffsschlüssel anzuzeigen oder zu bearbeiten, wird die Anfrage abgelehnt.

Sie können eine Richtlinienvariable mit dem DateBedingungsoperator verwenden.

Boolesche Bedingungsoperatoren

Mit booleschen Bedingungsoperatoren können Sie Condition-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit "true" oder "false" einschränken.

Diese identitätsbasierte Richtlinie verwendet beispielsweise den Bool Bedingungsoperator mit dem aws:SecureTransportSchlüssel, um zu verhindern, dass Objekte und Objekt-Tags in den Ziel-Bucket und dessen Inhalt repliziert werden, wenn die Anfrage noch nicht abgeschlossen ist. SSL

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BooleanExample",
      "Action": "s3:ReplicateObject",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket",
        "arn:aws:s3:::amzn-s3-demo-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der aws:SecureTransport-Anforderungskontext gibt „true“ oder „false“ zurück.

Sie können eine Richtlinienvariable mit dem BooleanBedingungsoperator verwenden.

Binäre Bedingungsoperatoren

Mit dem Bedingungsoperator BinaryEquals können Sie Condition-Elemente zum Prüfen von binären Schlüsselwerten erstellen. Er vergleicht den Wert des angegebenen Schlüssel Byte für Byte mit einer base-64-kodierten Darstellung des Binärwertes in der Richtlinie.

"Condition" : {
  "BinaryEquals": {
    "key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
  }
}     

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein.

Sie können eine Richtlinienvariable mit dem BinaryBedingungsoperator verwenden.

Bedingungsoperatoren für IP-Adressen

Mit Operatoren für IP-Adressbedingungen können Sie Condition Elemente erstellen, die den Zugriff einschränken, indem Sie einen Schlüssel mit einer oder einer IPv6 Adresse IPv4 oder einem Bereich von IP-Adressen vergleichen. Verwenden Sie sie mit dem Schlüssel aws:SourceIp. Der Wert muss im CIDR Standardformat vorliegen (z. B. 203.0.113.0/24 oder 2001:: 1234:5678: DB8 :/64). Wenn Sie eine IP-Adresse ohne das zugehörige Routingpräfix angeben, wird der Standardpräfixwert von verwendet. IAM /32

Etwas AWS Unterstützung von DienstenIPv6, wobei:: verwendet wird, um einen Bereich von 0s darzustellen. Informationen darüber, ob ein Dienst dies unterstütztIPv6, finden Sie in der Dokumentation zu diesem Dienst.

In der folgenden Anweisung wird beispielsweise der Bedingungsoperator IpAddress mit dem Schlüssel aws:SourceIp verwendet, um anzugeben, dass die Anforderung von einer IP-Adresse zwischen 203.0.113.0 und 203.0.113.255 kommen muss.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/*",
    "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
  }
}

Der Bedingungsschlüssel aws:SourceIp wird auf die IP-Adresse aufgelöst, von der die Anforderung kommt. Wenn die Anfragen von einer EC2 Amazon-Instance stammen, wird die öffentliche IP-Adresse der Instance aws:SourceIp ausgewertet.

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der aws:SourceIp Schlüssel ist im Anforderungskontext immer vorhanden, es sei denn, der Anforderer verwendet einen VPC Endpunkt, um die Anfrage zu stellen. In diesem Fall gibt die Bedingung false zurück und die Anforderung wird durch diese Anweisung implizit abgelehnt.

Sie können eine Richtlinienvariable mit dem IpAddressBedingungsoperator verwenden.

Das folgende Beispiel zeigt, wie Sie IPv6 Adressen kombinieren IPv4 können, um alle gültigen IP-Adressen Ihrer Organisation abzudecken. Wir empfehlen Ihnen, die Richtlinien Ihrer Organisation mit Ihren IPv6 Adressbereichen zu aktualisieren, zusätzlich zu den IPv4 Bereichen, die Sie bereits haben, um sicherzustellen, dass die Richtlinien auch bei der Umstellung weiterhin funktionierenIPv6.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "someservice:*",
    "Resource": "*",
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": [
          "203.0.113.0/24",
          "2001:DB8:1234:5678::/64"
        ]
      }
    }
  }
}

Der aws:SourceIp Bedingungsschlüssel funktioniert in einer JSON Richtlinie nur, wenn Sie die getestete API Person direkt als Benutzer anrufen. Wenn Sie stattdessen einen Service verwenden, um den Zielservice in Ihrem Namen aufzurufen, erkennt der Zielservice die IP-Adresse des aufrufenden Services und nicht die IP-Adresse des verursachenden Benutzers. Dies kann beispielsweise passieren, wenn Sie AWS CloudFormation um Amazon anzurufenEC2, um Instances für Sie zu erstellen. Derzeit gibt es keine Möglichkeit, die ursprüngliche IP-Adresse über einen Anrufdienst an den Zieldienst zur Auswertung in einer JSON Richtlinie weiterzuleiten. Verwenden Sie für diese Art von API Serviceaufrufen nicht den aws:SourceIp Bedingungsschlüssel.

Bedingungsoperatoren für Amazon Resource Name (ARN)

Mit den Bedingungsoperatoren von Amazon Resource Name (ARN) können Sie Condition Elemente erstellen, die den Zugriff einschränken, indem Sie einen Schlüssel mit einem vergleichenARN. Das ARN wird als Zeichenfolge betrachtet.

Sie können eine Richtlinienvariable mit dem ARNBedingungsoperator verwenden.

Das folgende Beispiel für eine ressourcenbasierte Richtlinie zeigt eine Richtlinie, die an eine SQS Amazon-Warteschlange angehängt ist, an die Sie Nachrichten senden SNS möchten. Es gibt Amazon die SNS Erlaubnis, Nachrichten an die Warteschlange (oder Warteschlangen) Ihrer Wahl zu senden, aber nur, wenn der Service die Nachrichten im Namen eines bestimmten SNS Amazon-Themas (oder mehrerer Themen) sendet. Sie geben die Warteschlange im Resource Feld und das SNS Amazon-Thema als Wert für den SourceArn Schlüssel an.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "123456789012"},
    "Action": "SQS:SendMessage",
    "Resource": "arn:aws:sqs:REGION:123456789012:QUEUE-ID",
    "Condition": {"ArnEquals": {"aws:SourceArn": "arn:aws:sns:REGION:123456789012:TOPIC-ID"}}
  }
}

Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der aws:SourceArn-Schlüssel ist im Anforderungskontext nur dann vorhanden, wenn eine Ressource einen Service auslöst, um einen anderen Service im Namen des Ressourcenbesitzers aufzurufen. Wenn ein IAM Benutzer versucht, diesen Vorgang direkt auszuführen, kehrt die Bedingung zurück false und die Anfrage wird durch diese Anweisung implizit abgelehnt.

... IfExists Bedingungsoperatoren

Sie können IfExists an das Ende jedes Bedingungsoperatornamens hinzufügen, abgesehen von der Null-Bedingung wie z. B. StringLikeIfExists. Sie tun dies, um zu sagen: „Wenn der Bedingungsschlüssel im Kontext der Anfrage vorhanden ist, verarbeiten Sie den Schlüssel wie in der Richtlinie angegeben. Wenn der Schlüssel nicht vorhanden ist, wird das Bedingungselement als "true" ausgewertet. Andere Bedingungselemente in der Anweisung können weiterhin zu einer Nichtübereinstimmung führen, nicht jedoch ein fehlender Schlüssel bei einer Prüfung mit ...IfExists. Wenn Sie ein "Effect": "Deny" Element mit einem negierten Bedingungsoperator wie verwendenStringNotEqualsIfExists, wird die Anfrage trotzdem abgelehnt, auch wenn der Bedingungsschlüssel nicht vorhanden ist.

Beispiel mit IfExists

Viele Bedingungsschlüssel beschreiben einen bestimmten Ressourcentyp und existieren nur beim Zugriff auf diesen Ressourcentyp. Diese Bedingungsschlüssel sind bei anderen Ressourcentypen nicht vorhanden. Dies stellt kein Problem dar, wenn die Richtlinienanweisung nur für einen Ressourcentyp gültig ist. Es gibt jedoch Fälle, bei denen eine einzelne Anweisung auf mehrere Ressourcentypen zutrifft, wenn beispielsweise die Richtlinienanweisung auf Aktionen aus mehreren Services Bezug nimmt oder wenn eine bestimmte Aktion innerhalb eines Services auf mehrere verschiedene Ressourcentypen in demselben Service zugreift. In solchen Fällen kann ein nur für eine Ressource gültiger Bedingungsschlüssel in einer Richtlinienanweisung dazu führen, dass das Element Condition in der Richtlinienanweisung fehlschlägt, sodass der "Effect" der Anweisung nicht angewendet wird.

Betrachten Sie beispielsweise das folgende einfache Richtlinienbeispiel:

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "THISPOLICYDOESNOTWORK",
    "Effect": "Allow",
    "Action": "ec2:RunInstances",
    "Resource": "*",
    "Condition": {"StringLike": {"ec2:InstanceType": [
      "t1.*",
      "t2.*",
      "m3.*"
    ]}}
  }
}

Der Zweck der vorangegangenen Richtlinie besteht darin, den Benutzer zum Starten einer beliebigen Instance vom Typ t1, t2 oder m3 zu befähigen. Zum Starten einer Instance ist jedoch auch der Zugriff auf viele Ressourcen zusätzlich zu der Instance selbst erforderlich, wie z. B. Images, Schlüsselpaare, Sicherheitsgruppen usw. Die gesamte Anweisung wird gegen alle Ressourcen geprüft, die zum Starten der Instance erforderlich sind. Diese zusätzlichen Ressourcen verfügen nicht über den Bedingungsschlüssel ec2:InstanceType, sodass die Prüfung StringLike fehlschlägt und der Benutzer nicht zum Starten eines beliebigen Instance-Typs befähigt wird.

Um dieses Problem zu beheben, verwenden Sie stattdessen den Bedingungsoperator StringLikeIfExists. Auf diese Weise findet die Prüfung nur dann statt, wenn der Bedingungsschlüssel existiert. Sie können nachstehende Richtlinie folgendermaßen interpretieren: „Wenn die zu prüfende Ressource den Bedingungsschlüssel „ec2:InstanceType„ enthält, wird die Aktion nur zugelassen, wenn der Schlüsselwert mit t1., t2. oder m3. beginnt.“ Wenn die zu prüfende Ressource nicht über diesen Bedingungsschlüssel verfügt, ist dies belanglos." Das Sternchen (*) in den Bedingungsschlüsselwerten wird, wenn es mit dem StringLikeIfExists-Bedingungsoperator verwendet wird, als Platzhalter interpretiert, um teilweise übereinstimmende Zeichenfolgen zu erzielen. Die Anweisung DescribeActions enthält die Aktionen, die erforderlich sind, um die Instance in der Konsole anzeigen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RunInstance",
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "StringLikeIfExists": {
                    "ec2:InstanceType": [
                        "t1.*",
                        "t2.*",
                        "m3.*"
             ]}}
        },
        {
            "Sid": "DescribeActions",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeVpcs",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": "*"
        }]
}

Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren

Verwenden Sie einen Bedingungsoperator Null, um zu prüfen, ob ein Bedingungsschlüssel zum Zeitpunkt der Autorisierung abwesend ist. Verwenden Sie in der Richtlinienanweisung entweder true (der Schlüssel ist nicht vorhanden – der Wert beträgt null) oder false (der Schlüssel ist vorhanden und sein Wert ist ungleich null).

Sie können eine Richtlinienvariable mit dem NullBedingungsoperator verwenden.

Beispielsweise können Sie mit diesem Bedingungsoperator bestimmen, ob ein Benutzer seine eigenen oder temporäre Anmeldeinformationen für den Vorgang benutzt. Wenn der Benutzer temporäre Anmeldeinformationen benutzt, ist der Schlüssel aws:TokenIssueTime vorhanden und hat einen Wert. Das folgende Beispiel zeigt eine Bedingung, die besagt, dass der Benutzer keine temporären Anmeldeinformationen verwenden darf (der Schlüssel darf nicht existieren), damit der Benutzer Amazon verwenden kann EC2API.

{
  "Version": "2012-10-17",
  "Statement":{
      "Action":"ec2:*",
      "Effect":"Allow",
      "Resource":"*",
      "Condition":{"Null":{"aws:TokenIssueTime":"true"}}
  }
}