Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Création d'octrois
Avant de créer un octroi, découvrez ses options de personnalisation. Vous pouvez utiliser des contraintes d'octroi pour limiter les autorisations dans l'octroi. En outre, renseignez-vous sur l'autorisation CreateGrant
d'octroi. Les principaux qui obtiennent l'autorisation de créer des octrois à partir d'un octroi sont limités au niveau des octrois qu'ils peuvent créer.
Création d'un octroi
Pour créer une subvention, appelez l'CreateGrantopération. Spécifiez une KMS clé, le principal du bénéficiaire et une liste des opérations de subvention autorisées. Vous pouvez également désigner un principal de retrait facultatif. Pour personnaliser l'octroi, utilisez des paramètres Constraints
facultatifs pour définir les contraintes d'octroi.
Lorsque vous créez, retirez ou révoquez une subvention, il peut s'écouler un bref délai, généralement moins de cinq minutes, avant que la modification ne soit entièrement disponible AWS KMS. Pour plus d'informations, voir Cohérence éventuelle (pour les subventions).
Par exemple, la CreateGrant
commande suivante crée une autorisation qui permet aux utilisateurs autorisés à assumer le keyUserRole
rôle d'appeler l'opération de déchiffrement sur la clé symétrique KMS spécifiée. L'autorisation utilise le paramètre RetiringPrincipal
pour désigner un principal qui peut retirer l'autorisation. Elle inclut également une contrainte d'autorisation qui l'autorise uniquement lorsque le contexte de chiffrement de la requête inclut "Department": "IT"
.
$
aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextSubset={Department=IT}
Si votre code tente à nouveau l'CreateGrant
opération ou utilise un AWS SDKqui réessaie automatiquement les demandes, utilisez le paramètre facultatif Name pour empêcher la création de licences dupliquées. If AWS KMS reçoit une CreateGrant
demande de subvention ayant les mêmes propriétés qu'une subvention existante, y compris le nom, il reconnaît la demande comme une nouvelle tentative et ne crée pas de nouvelle subvention. Vous ne pouvez pas utiliser la Name
valeur pour identifier la subvention dans aucun AWS KMS
opérations.
Important
N'incluez pas d'informations confidentielles ou sensibles dans le nom de l’octroi. Il peut apparaître en texte brut dans CloudTrail les journaux et autres sorties.
$
aws kms create-grant \ --name IT-1234abcd-keyUserRole-decrypt \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextSubset={Department=IT}
Pour des exemples de code qui montrent comment créer des subventions dans plusieurs langages de programmation, voirÀ utiliser CreateGrant avec un AWS SDKou CLI.
Utilisation des contraintes d'octroi
Les contraintes d'octroi définissent les conditions des autorisations que l'octroi donne au principal bénéficiaire. Les contraintes de subvention remplacent les clés de condition dans une politique ou une IAMpolitique clé. Chaque valeur de contrainte d'octroi peut inclure jusqu'à 8 paires de contextes de chiffrement. La valeur de contexte de chiffrement dans chaque contrainte d'octroi ne peut pas dépasser 384 caractères.
Important
N'incluez pas d'informations confidentielles ou sensibles dans ce champ. Ce champ peut être affiché en texte brut dans les CloudTrail journaux et autres sorties.
AWS KMS prend en charge deux contraintes EncryptionContextEquals
d'autorisationEncryptionContextSubset
, qui établissent toutes deux des exigences relatives au contexte de chiffrement dans une demande d'opération cryptographique.
Les contraintes d'octroi du contexte de chiffrement sont conçues pour être utilisées avec des opérations d'octroi qui ont un paramètre de contexte de chiffrement.
-
Les contraintes de contexte de chiffrement ne sont valides que dans le cadre de l'attribution d'une KMS clé de chiffrement symétrique. Les opérations cryptographiques avec d'autres KMS clés ne prennent pas en charge un contexte de chiffrement.
-
La contrainte de contexte de chiffrement est ignorée pour les opérations
DescribeKey
etRetireGrant
.DescribeKey
etRetireGrant
n'ont pas de paramètre de contexte de chiffrement, mais vous pouvez inclure ces opérations dans un octroi qui a une contrainte de contexte de chiffrement. -
Vous pouvez utiliser une contrainte de contexte de chiffrement dans un octroi pour l'opération
CreateGrant
. La contrainte de contexte de chiffrement nécessite que tous les octrois créés avec l'autorisationCreateGrant
aient une contrainte de contexte de chiffrement tout aussi stricte ou plus stricte.
AWS KMS prend en charge les contraintes d'octroi de contexte de chiffrement suivantes.
- EncryptionContextEquals
-
Utilisez
EncryptionContextEquals
pour spécifier le contexte de chiffrement exact pour les demandes autorisées.EncryptionContextEquals
exige que les paires de contexte de chiffrement de la requête correspondent exactement, y compris au niveau des minuscules/majuscules, aux paires de contexte de chiffrement de la contrainte d'octroi. Les paires peuvent apparaître dans n'importe quel ordre, mais les clés et valeurs dans chaque paire ne peuvent pas varier.Par exemple, si l'a contrainte d'octroi
EncryptionContextEquals
exige la paire de contextes de chiffrement"Department": "IT"
, l'octroi autorise les demandes du type spécifié uniquement lorsque le contexte de chiffrement de la requête est exactement"Department": "IT"
. - EncryptionContextSubset
-
Utilisez
EncryptionContextSubset
pour exiger que les demandes incluent des paires de contexte de chiffrement particulières.EncryptionContextSubset
exige que la demande inclue toutes les paires de contexte de chiffrement de la contrainte d'octroi (une correspondance exacte sensible à la casse), mais la demande peut avoir des paires de contexte de chiffrement supplémentaires. Les paires peuvent apparaître dans n'importe quel ordre, mais les clés et valeurs dans chaque paire ne peuvent pas varier.Par exemple, si l'a contrainte d'octroi
EncryptionContextSubset
exige la paire de contextes de chiffrementDepartment=IT
, l'octroi autorise les demandes du type spécifié uniquement lorsque le contexte de chiffrement de la requête est"Department": "IT"
ou inclut"Department": "IT"
, ainsi que d'autres paires de contexte de chiffrement, telles que"Department": "IT","Purpose": "Test"
.
Pour spécifier une contrainte de contexte de chiffrement dans l'attribution d'une KMS clé de chiffrement symétrique, utilisez le Constraints
paramètre dans l'CreateGrantopération. L'octroi créé par cette commande accorde aux utilisateurs qui sont autorisés à assumer le rôle keyUserRole
l'autorisation d'appeler l'opération Decrypt (Déchiffrer). Toutefois, cette autorisation est effective uniquement lorsque le contexte de chiffrement de la demande Decrypt
est une paire de contextes de chiffrement "Department": "IT"
.
$
aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextEquals={Department=IT}
L'octroi obtenu ressemble à ce qui suit. Notez que l'autorisation accordée au rôle keyUserRole
n'est effective que lorsque la demande Decrypt
utilise la même paire de contextes de chiffrement que celle spécifiée dans la contrainte d'octroi. Pour trouver les subventions sur une KMS clé, utilisez l'ListGrantsopération.
$
aws kms list-grants --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
{ "Grants": [ { "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GrantId": "abcde1237f76e4ba7987489ac329fbfba6ad343d6f7075dbd1ef191f0120514a", "Operations": [ "Decrypt" ], "GranteePrincipal": "arn:aws:iam::111122223333:role/keyUserRole", "Constraints": { "EncryptionContextEquals": { "Department": "IT" } }, "CreationDate": 1568565290.0, "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "RetiringPrincipal": "arn:aws:iam::111122223333:role/adminRole" } ] }
Pour satisfaire la contrainte d'octroi EncryptionContextEquals
, le contexte de chiffrement dans la demande pour l'opération Decrypt
doit être une paire "Department":
"IT"
. Une demande telle que la suivante émanant du principal bénéficiaire satisferait à la contrainte d'octroi EncryptionContextEquals
.
$
aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab\ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT
Lorsque la contrainte d'octroi est EncryptionContextSubset
, les paires de contexte de chiffrement de la demande doivent inclure les paires de contexte de chiffrement dans la contrainte d'octroi, mais la demande peut également inclure d'autres paires de contexte de chiffrement. La contrainte d'octroi suivante nécessite que l'une des paires de contexte de chiffrement dans la demande soit "Deparment": "IT"
.
"Constraints": { "EncryptionContextSubset": { "Department": "IT" } }
La demande suivante émanant du principal bénéficiaire satisferait à la fois aux contraintes d'octroi EncryptionContextEqual
et EncryptionContextSubset
dans cet exemple.
$
aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT
Toutefois, une demande comme celle qui suit émanant du principal bénéficiaire satisferait à la contrainte d'octroi EncryptionContextSubset
, mais pas à la contrainte d'octroi EncryptionContextEquals
.
$
aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT,Purpose=Test
AWS les services utilisent souvent des contraintes contextuelles de chiffrement dans les autorisations qui leur donnent l'autorisation d'utiliser KMS des clés dans votre Compte AWS. Par exemple, Amazon DynamoDB utilise une autorisation telle que la suivante pour obtenir l'autorisation d'utiliser Clé gérée par AWSpour DynamoDB dans votre compte. La contrainte d'octroi EncryptionContextSubset
de cet octroi rend les autorisations de l'octroi effectives uniquement lorsque le contexte de chiffrement de la demande inclut les paires"subscriberID": "111122223333"
et "tableName":
"Services"
. Cette contrainte de subvention signifie que l'autorisation autorise DynamoDB à utiliser la clé KMS spécifiée uniquement pour une table particulière de votre Compte AWS.
Pour obtenir ce résultat, exécutez l'ListGrantsopération sur Clé gérée par AWS pour DynamoDB dans votre compte.
$
aws kms list-grants --key-id 0987dcba-09fe-87dc-65ba-ab0987654321 { "Grants": [ { "Operations": [ "Decrypt", "Encrypt", "GenerateDataKey", "ReEncryptFrom", "ReEncryptTo", "RetireGrant", "DescribeKey" ], "IssuingAccount": "arn:aws:iam::111122223333:root", "Constraints": { "EncryptionContextSubset": { "aws:dynamodb:tableName": "Services", "aws:dynamodb:subscriberId": "111122223333" } }, "CreationDate": 1518567315.0, "KeyId": "arn:aws:kms:us-west-2:111122223333:key/0987dcba-09fe-87dc-65ba-ab0987654321", "GranteePrincipal": "dynamodb.us-west-2.amazonaws.com", "RetiringPrincipal": "dynamodb.us-west-2.amazonaws.com", "Name": "8276b9a6-6cf0-46f1-b2f0-7993a7f8c89a", "GrantId": "1667b97d27cf748cf05b487217dd4179526c949d14fb3903858e25193253fe59" } ] }
Octroi CreateGrant d'autorisation
Un octroi peut inclure l'autorisation d'appeler l'opération CreateGrant
. Toutefois, quand un principal bénéficiaire obtient l'autorisation d'appeler CreateGrant
à partir d'un octroi, plutôt que d'une politique, cette autorisation est limitée.
-
Le principal bénéficiaire peut uniquement créer des octrois qui permettent une partie ou la totalité des opérations de l'octroi parent.
-
Les contraintes d'octroi dans les octrois qu'elles créent doivent être au moins aussi strictes que celles de l'octroi parent.
Ces limites ne s'appliquent pas aux principaux qui obtiennent l'autorisation CreateGrant
à partir d'une politique, bien que leurs autorisations puissent être limitées par des conditions de politique.
Par exemple, imaginons un octroi qui autorise le principal bénéficiaire à appeler les opérations GenerateDataKey
, Decrypt
et CreateGrant
. Nous appelons un octroi qui autorise l'autorisation CreateGrant
d'un octroi parent.
# The original grant in a ListGrants response. { "Grants": [ { "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1572216195.0, "GrantId": "abcde1237f76e4ba7987489ac329fbfba6ad343d6f7075dbd1ef191f0120514a", "Operations": [ "GenerateDataKey", "Decrypt", "CreateGrant ] "RetiringPrincipal": "arn:aws:iam::111122223333:role/adminRole", "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GranteePrincipal": "arn:aws:iam::111122223333:role/keyUserRole", "Constraints": { "EncryptionContextSubset": { "Department": "IT" } }, } ] }
Le principal du bénéficiaire peut utiliser cette autorisation pour créer une subvention qui inclut n'importe quel sous-ensemble des opérations spécifiées dans la subvention d'origine, telles que CreateGrant
et. exampleUser Decrypt
L'octroi enfant ne peut pas inclure d'autres opérations, comme ScheduleKeyDeletion
ou ReEncrypt
.
De plus, les contraintes d'octroi des octrois enfants doivent être aussi restrictives, voire plus, que celles de l'octroi parent. Par exemple, l'octroi enfant peut ajouter des paires dans une contrainte EncryptionContextSubset
de l'octroi parent, mais ne peut pas les supprimer. L'octroi enfant peut modifier une contrainte EncryptionContextSubset
en contrainte EncryptionContextEquals
, mais pas l'inverse.
Par exemple, le principal bénéficiaire peut utiliser l'autorisation CreateGrant
qu'il a obtenue de l'octroi parent pour créer l'octroi enfant suivant. Les opérations de l'octroi enfant sont un sous-ensemble des opérations de l'octroi parent et les contraintes d'octroi sont plus restrictives.
# The child grant in a ListGrants response. { "Grants": [ { "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1572249600.0, "GrantId": "fedcba9999c1e2e9876abcde6e9d6c9b6a1987650000abcee009abcdef40183f", "Operations": [ "CreateGrant" "Decrypt" ] "RetiringPrincipal": "arn:aws:iam::111122223333:user/exampleUser", "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GranteePrincipal": "arn:aws:iam::111122223333:user/anotherUser", "Constraints": { IAM best practices discourage the use of IAM users with long-term credentials. Whenever possible, use IAM roles, which provide temporary credentials. For details, see Security best practices in IAM in the IAM User Guide. "EncryptionContextEquals": { "Department": "IT" } }, } ] }
Le principal bénéficiaire de l'octroi enfant ,anotherUser
, peut utiliser son autorisation CreateGrant
pour créer des octrois. Cependant, les octrois que anotherUser
crée doit inclure les opérations dans leur octroi parent ou un sous-ensemble, et les contraintes d'octroi doivent être les mêmes ou plus strictes.