Beispiele für Berechtigungsrichtlinien für AWS Secrets Manager - AWS Secrets Manager
Beispiel: Berechtigung zum Abrufen von einzelnen Secret-WertenBeispiel: Erlaubnis, einzelne Geheimnisse zu lesen und zu beschreibenBeispiel: Berechtigung zum Abrufen einer Gruppe geheimer Werte in einem BatchBeispiel: PlatzhalterBeispiel: Berechtigung zum Erstellen von SecretsBeispiel: Verweigern Sie einen bestimmten AWS KMS Schlüssel zur Verschlüsselung von GeheimnissenBeispiel: Berechtigungen und VPCsBeispiel: Steuern des Zugriffs auf Secrets mit TagsBeispiel: Beschränken Sie den Zugriff auf Identitäten mit Tags, die mit den Tags der Secrets übereinstimmenBeispiel: Service-Prinzipal

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.

Beispiele für Berechtigungsrichtlinien für AWS Secrets Manager

Eine Berechtigungsrichtlinie ist JSON-strukturierter Text. Weitere Informationen finden Sie unter JSON policy document structure (JSON-Richtliniendokumentstruktur).

Berechtigungsrichtlinien, die Sie Ressourcen und Identitäten anhängen, sind sehr ähnlich. Einige Elemente, die Sie in eine Richtlinie für den Zugriff auf Secrets einschließen, umfassen:

  • Principal: wem der Zugriff gewährt werden soll. Weitere Informationen finden Sie unter Specify a principal (Angeben eines Prinzipals) im IAM-Benutzerhandbuch. Wenn Sie eine Richtlinie an eine Identität anfügen, fügen Sie kein Principal-Element zur Richtlinie hinzu.

  • Action: was sie tun können. Siehe Secrets-Manager-Aktionen.

  • Resource: auf welche Geheimnisse sie zugreifen können. Siehe Secrets-Manager-Ressourcen.

    Das Platzhalterzeichen (*) hat je nachdem, was Sie an die Richtlinie anhängen, eine andere Bedeutung:

    • In einer Richtlinie, die einem Secret zugeordnet ist, bedeutet *, dass die Richtlinie auf dieses Secret angewendet wird.

    • In einer Richtlinie, die einer Identität zugeordnet ist, bedeutet *, dass die Richtlinie für alle Ressourcen, einschließlich Secrets, im Konto gilt.

Informationen zum Anfügen einer Richtlinie an ein Secret finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret.

So können Sie eine Richtlinie an eine Anhängen einer Berechtigungsrichtlinie an eine Identität-Identität anfügen.

Beispiel: Berechtigung zum Abrufen von einzelnen Secret-Werten

Um die Berechtigung zum Abrufen von Secret-Werten zu erteilen, können Sie Secrets oder Identitäten Richtlinien zuordnen. Hilfe zum Festlegen des zu verwendenden Richtlinientyps finden Sie unter Identity-based policies and resource-based policies (Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien). Informationen zum Erstellen von Richtlinien finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret und Anhängen einer Berechtigungsrichtlinie an eine Identität.

Die folgenden Beispiele zeigen zwei verschiedene Möglichkeiten, Zugriff auf ein Secret zu gewähren. Das erste Beispiel ist eine ressourcenbasierte Richtlinie, die Sie an ein Secret anfügen können. Dieses Beispiel ist nützlich, wenn Sie mehreren Benutzern oder Rollen Zugriff auf ein einzelnes Secret gewähren möchten. Das zweite Beispiel ist eine identitätsbasierte Richtlinie, die Sie einem Benutzer oder einer Rolle in IAM zuordnen können. Dieses Beispiel ist nützlich, wenn Sie Zugriff auf eine IAM-Gruppe gewähren möchten. Informationen zum Gewähren der Berechtigung zum Abrufen einer Gruppe von Secrets in einem Batch-API-Aufruf finden Sie unter Beispiel: Berechtigung zum Abrufen einer Gruppe geheimer Werte in einem Batch.

Beispiel Lesen Sie eines Secrets (Zuordnung zu einem Secret)

Sie können Zugriff auf ein Secret gewähren, indem Sie die folgende Richtlinie an das Secret anfügen. Informationen zur Verwendung dieser Richtlinie finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
Beispiel Auslesen eines Secrets, das mit einem vom Kunden verwalteten Schlüssel verschlüsselt ist (Zuordnung zu Identität)

Wenn ein Secret mit einem vom Kunden verwalteten Schlüssel verschlüsselt ist, können Sie Zugriff zum Auslesen des Secrets gewähren, indem Sie die folgende Richtlinie an eine Identität anfügen. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "SecretARN"
    },
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "KMSKeyARN"
    }
  ]
}

Beispiel: Erlaubnis, einzelne Geheimnisse zu lesen und zu beschreiben

Beispiel Lies und beschreibe ein Geheimnis (füge es einer Identität hinzu)

Sie können Zugriff auf ein Secret gewähren, indem Sie die folgende Richtlinie an eine Identität anfügen. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität. 

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "secretsmanager:GetSecretValue",
          "secretsmanager:DescribeSecret"
          ],
        "Resource": "SecretARN"
      }
    ]
  }

Beispiel: Berechtigung zum Abrufen einer Gruppe geheimer Werte in einem Batch

Beispiel Lesen einer Gruppe von Secrets in einem Batch (Anhang an Identität)

Sie können den Zugriff auf den Abruf einer Gruppe von Secrets in einem Batch-API-Aufruf gewähren, indem Sie die folgende Richtlinie an eine Identität anhängen. Die Richtlinie schränkt den Aufrufer so ein, dass er nur die von SecretARN1, SecretARN2 und SecretARN3 angegebenen Secrets abrufen kann, auch wenn der Batch-Aufruf andere Secrets enthält. Wenn der Aufrufer im Batch-API-Aufruf auch andere Secrets anfordert, gibt Secrets Manager diese nicht zurück. Weitere Informationen finden Sie unter BatchGetSecretValue. . Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität. 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:BatchGetSecretValue",
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "SecretARN1",
        "SecretARN2",
        "SecretARN3"
        ]
    }
  ]
}

Beispiel: Platzhalter

Sie können Platzhalter verwenden, um einen Satz von Werten in ein Richtlinienelement aufzunehmen.

Beispiel Zugriff auf alle Secrets in einem Pfad (Zuordnung zu Identität)

Die folgende Richtlinie gewährt Zugriff auf das Abrufen aller Geheimnisse, deren Name mit "TestEnv/“ beginnt. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
  }
}
Beispiel Zugriff auf Metadaten in allen Secrets (Zuordnung zu Identität)

Die folgenden Richtlinien gewährt DescribeSecret und Berechtigungen beginnend mitList: ListSecrets und ListSecretVersionIds. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:DescribeSecret",
      "secretsmanager:List*"
    ],
    "Resource": "*"
  }
}
Beispiel Zuordnen eines Secret-Namen (Zuordnung zu Identität)

Die folgende Richtlinie gewährt allen Secrets-Manager-Berechtigungen für ein Secret nach Namen. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

Um einen Secret-Namen zuzuordnen, erstellen Sie den ARN für das Secret, indem Sie Region, Konto-ID, Secret-Namen und Platzhalter (?) zusammenstellen, um einzelne zufällige Zeichen zuzuordnen. Secrets Manager fügt sechs zufällige Zeichen zu geheimen Namen als Teil ihres ARN an, sodass Sie diesen Platzhalter verwenden können, um diese Zeichen zu vergleichen. Bei Verwendung der Syntax "another_secret_name-*" gleicht Secrets Manager nicht nur das vorgesehene Secret mit den 6 zufälligen Zeichen, sondern auch ""another_secret_name-<anything-here>a1b2c3"" ab.

Da Sie alle Teile des ARN eines Secret mit Ausnahme der 6 zufälligen Zeichen vorhersagen können, ermöglicht Ihnen das Platzhalterzeichen '??????' das sichere Erteilen von Berechtigungen für ein noch nicht bestehendes Secret. Beachten Sie jedoch Folgendes: Wenn Sie das Secret löschen und mit demselben Namen neu erstellen, erhält der Benutzer automatisch die Berechtigung für das neue Secret, auch wenn die 6 Zeichen geändert wurden. 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:*",
      "Resource": [
        "arn:aws:secretsmanager:Region:AccountId:secret:a_specific_secret_name-a1b2c3",
        "arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????"
      ]
    }
  ]
}

Beispiel: Berechtigung zum Erstellen von Secrets

Um einem Benutzer Berechtigungen für die Erstellung eines Secrets zu gewähren, empfehlen wir Ihnen, eine Berechtigungsrichtlinie an eine IAM-Gruppe anzufügen, der der Benutzer angehört. Weitere Informationen zu IAM-Benutzergruppen.

Beispiel Erstellen von Secrets (Zuordnung zu Identität)

Die folgende Richtlinie erteilt die Berechtigung zum Erstellen von Secrets und zum Anzeigen einer Liste von Secrets. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    }
  ]
}

Beispiel: Verweigern Sie einen bestimmten AWS KMS Schlüssel zur Verschlüsselung von Geheimnissen

Wichtig

Um einem vom Kunden verwalteten Schlüssel zu verweigern, empfehlen wir Ihnen, den Zugriff mithilfe einer Schlüsselrichtlinie oder einer Schlüsselgewährung einzuschränken. Weitere Informationen finden Sie AWS KMS im AWS Key Management Service Entwicklerhandbuch unter Authentifizierung und Zugriffskontrolle für.

Beispiel Den AWS verwalteten Schlüssel ablehnen aws/secretsmanager (an die Identität anhängen)

Die folgende Richtlinie zeigt, wie die Verwendung des AWS verwalteten Schlüssels aws/secretsmanager für die Erstellung oder Aktualisierung von Geheimnissen verweigert werden kann. Das bedeutet, dass Geheimnisse mit einem vom Kunden verwalteten Schlüssel verschlüsselt werden müssen. Wenn der aws/secretsmanager Schlüssel existiert, müssen Sie auch seine Schlüssel-ID angeben. Sie fügen auch die leere Zeichenfolge hinzu, da Secrets Manager diese als AWS verwalteten Schlüssel aws/secretsmanager interpretiert. Die zweite Anweisung lehnt Anfragen zur Erstellung von Geheimnissen ab, die keinen KMS-Schlüssel enthalten, da Secrets Manager diesen als AWS verwalteten Schlüssel interpretiert. aws/secretsmanager

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "RequireCustomerManagedKeysOnSecrets",
          "Effect": "Deny",
          "Action": [
              "secretsmanager:CreateSecret",
              "secretsmanager:UpdateSecret"
          ],
          "Resource": "*",
          "Condition": {
              "ForAnyValue:StringLikeIfExists": {
                  "secretsmanager:KmsKeyId": [
                      "*alias/aws/secretsmanager",
                      "*<key_ID_of_the_AWS_managed_key>",
                      ""
                  ]
              }
          }
      },
      {
          "Sid": "RequireKmsKeyIdParameterOnCreate",
          "Effect": "Deny",
          "Action": "secretsmanager:CreateSecret",
          "Resource": "*",
          "Condition": {
              "Null": {
                  "secretsmanager:KmsKeyId": "true"
              }
          }
      }
  ]
}

Beispiel: Berechtigungen und VPCs

Wenn Sie innerhalb einer VPC auf Secrets Manager zugreifen müssen, können Sie sicherstellen, dass Anforderungen an Secrets Manager von der VPC stammen, indem Sie eine Bedingung in Ihre Berechtigungsrichtlinien aufnehmen. Weitere Informationen finden Sie unter VPC-Endpunktbedingungen und Verwenden eines AWS Secrets Manager-VPC-Endpunkts.

Stellen Sie sicher, dass Anfragen für den Zugriff auf das Secret von anderen AWS Diensten auch von der VPC kommen, da ihnen diese Richtlinie andernfalls den Zugriff verweigert.

Beispiel Anforderungen müssen über einen VPC-Endpunkt kommen (Zuordnung zu Secret)

Die folgende Richtlinie erlaubt es einem Benutzer z. B. nur dann, Secrets-Manager-Operationen auszuführen, wenn die Anforderung durch den angegebenen VPC-Endpunkt vpce-1234a5678b9012c geleitet wird. Informationen zur Verwendung dieser Richtlinie finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret.

{
  "Id": "example-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictGetSecretValueoperation",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1234a5678b9012c"
        }
      }
    }
  ]
}
Beispiel Anforderungen müssen über einen VPC kommen (Zuordnung zu Secret)

Die folgende Richtlinie lässt nur dann Befehle zur Erstellung und Verwaltung von Secrets zu, wenn sie von vpc-12345678 stammen. Darüber hinaus erlaubt die Richtlinie Operationen, die auf den verschlüsselten Wert des Secrets zugreifen, nur dann, wenn die Anforderungen von vpc-2b2b2b2b stammen. Sie verwenden eine solche Richtlinie wie diese möglicherweise, wenn Sie eine Anwendung in einer VPC ausführen, aber eine zweite, isolierte VPC für die Verwaltungsfunktionen genutzt wird. Informationen zur Verwendung dieser Richtlinie finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret.

{
  "Id": "example-policy-2",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:Create*",
        "secretsmanager:Put*",
        "secretsmanager:Update*",
        "secretsmanager:Delete*",
        "secretsmanager:Restore*",
        "secretsmanager:RotateSecret",
        "secretsmanager:CancelRotate*",
        "secretsmanager:TagResource",
        "secretsmanager:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-12345678"
        }
      }
    },
    {
      "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-2b2b2b2b"
        }
      }
    }
  ]
}

Beispiel: Steuern des Zugriffs auf Secrets mit Tags

Sie können Tags verwenden, um den Zugriff auf Ihre Secrets zu steuern. Die Verwendung von Tags zur Kontrolle von Berechtigungen in Umgebungen, die schnell wachsen, ist hilfreich und unterstützt Sie in Situationen, in denen die Richtlinienverwaltung mühsam wird. Eine Strategie besteht darin, Tags Secrets zuzuordnen und dann Berechtigungen für eine Identität zu erteilen, wenn ein Secret ein bestimmtes Tag hat.

Beispiel Gewähren von Zugriff auf Secrets mit einem bestimmten Tag (Zuordnung zu Identität)

Die folgende Richtlinie erlaubt geheime DescribeSecret Daten mit einem Tag mit dem Schlüssel "" und dem Wert ServerName"ServerABC“. Informationen zur Verwendung dieser Richtlinie finden Sie unter Anhängen einer Berechtigungsrichtlinie an eine Identität.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:DescribeSecret",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "secretsmanager:ResourceTag/ServerName": "ServerABC"
      }
    }
  }
}

Beispiel: Beschränken Sie den Zugriff auf Identitäten mit Tags, die mit den Tags der Secrets übereinstimmen

Eine Strategie besteht darin, Tags sowohl Secrets als auch IAM-Identitäten zuzuordnen. Anschließend erstellen Sie Berechtigungsrichtlinien, um Operationen zuzulassen, wenn das Tag der Identität mit dem Tag des Secret übereinstimmt. Ein vollständiges Tutorial finden Sie unter Define permissions to access secrets based on tags (Definieren Sie Berechtigungen für den Zugriff auf Secrets basierend auf Tags).

Die Verwendung von Tags zur Kontrolle von Berechtigungen in Umgebungen, die schnell wachsen, ist hilfreich und unterstützt Sie in Situationen, in denen die Richtlinienverwaltung mühsam wird. Weitere Informationen finden Sie unter Was ist ABAC für AWS?

Beispiel Zugriff auf Rollen zulassen, die dieselben Tags wie Secrets haben (Zuordnung zu Secret)

Die folgende Richtlinie gewährt GetSecretValue Zugriff auf das Konto 123456789012, sofern das Tag AccessProject den gleichen Wert für das Geheimnis und die Rolle aufweist. Informationen zur Verwendung dieser Richtlinie finden Sie unter Zuordnen einer Berechtigungsrichtlinie zu einem AWS Secrets Manager -Secret.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "123456789012"
    },
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }"
      }
    },
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "*"
  }
}

Beispiel: Service-Prinzipal

Wenn die mit Ihrem Secret verknüpfte Ressourcenrichtlinie einen AWS Service Principal beinhaltet, empfehlen wir Ihnen, die SourceAccount globalen Bedingungsschlüssel aws: SourceArn und aws: zu verwenden. Die ARN- und Kontowerte werden nur dann in den Autorisierungskontext aufgenommen, wenn eine Anforderung von einem anderen AWS -Service an Secrets Manager eingeht. Diese Kombination von Bedingungen vermeidet ein potenziell verwirrtes Stellvertreterszenario..

Wenn ein Ressourcen-ARN Zeichen enthält, die in einer Ressourcenrichtlinie nicht zugelassen sind, können Sie diesen Ressourcen-ARN nicht im Wert des aws:SourceArn-Bedingungsschlüssel verwenden. Verwenden Sie stattdessen den Bedingungsschlüssel aws:SourceAccount. Weitere Informationen finden Sie unter IAM-Anforderungen.

Dienstprinzipale werden normalerweise nicht als Prinzipale in einer Richtlinie verwendet, die an ein Geheimnis angehängt ist, aber für einige AWS Dienste ist dies erforderlich. Informationen zu Ressourcenrichtlinien, die ein Service an ein Geheimnis anhängen muss, finden Sie in der Dokumentation des Services.

Beispiel Erlauben Sie einem Service den Zugriff auf ein Geheimnis mit einem Serviceprinzipal (an ein Geheimnis anhängen)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "service-name.amazonaws.com"
        ]
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:sourceArn": "arn:aws:service-name::123456789012:*"
        },
        "StringEquals": {
          "aws:sourceAccount": "123456789012"
        }
      }

    }
  ]
}