Utilisation de balises pour contrôler l'accès aux clés KMS - AWS Key Management Service

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.

Utilisation de balises pour contrôler l'accès aux clés KMS

Vous pouvez contrôler l'accès à AWS KMS keys en fonction des balises de la clé KMS. Par exemple, vous pouvez écrire une politique IAM qui permet aux principaux d'activer et de désactiver uniquement les clés KMS possédant une balise particulière. Vous pouvez également utiliser une politique IAM pour empêcher les principaux d'utiliser des clés KMS dans les opérations de chiffrement, sauf si la clé KMS possède une balise particulière.

Cette fonction fait partie de la prise en charge d'AWS KMS pour le contrôle d'accès basé sur les attributs (ABAC). Pour plus d'informations sur l'utilisation des balises pour contrôler l'accès aux ressources AWS, veuillez consulter Qu'est-ce que le contrôle d'accès basé sur les attributs (ABAC) pour AWS ? et Contrôle de l'accès aux ressources AWS à l'aide de balises dans le Guide de l'utilisateur IAM. Pour obtenir de l'aide pour résoudre les problèmes d'accès liés à l'ABAC, veuillez consulter Résolution des problèmes liés à l'ABAC pour AWS KMS.

Note

Les modifications d'alias et de balises peuvent prendre jusqu'à cinq minutes pour affecter l'autorisation de clé KMS. Les modifications récentes peuvent être visibles dans les opérations d'API avant qu'elles n'affectent l'autorisation.

AWS KMSprend en charge la clé contextuelle de condition globale aws :ResourceTag/tag-key, qui vous permet de contrôler l'accès aux clés KMS en fonction des balises figurant sur la clé KMS. Étant donné que plusieurs clés KMS peuvent avoir la même balise, cette fonction vous permet d'appliquer l'autorisation à un ensemble sélectionné de clés KMS. Vous pouvez également facilement modifier les clés KMS dans l'ensemble en changeant leurs balises.

Dans AWS KMS, la clé de condition aws:ResourceTag/tag-key est prise en charge uniquement dans les politiques IAM. Il n'est pas pris en charge dans les politiques clés, qui ne s'appliquent qu'à une seule clé KMS, ni dans les opérations qui n'utilisent pas une clé KMS particulière, telles que les ListAliasesopérations ListKeysor.

Le contrôle de l'accès à l'aide de balises offre un moyen simple, évolutif et flexible de gérer les autorisations. Toutefois, s'il n'est pas correctement conçu et géré, il peut autoriser ou refuser l'accès à vos clés KMS par inadvertance. Si vous utilisez des balises pour contrôler l'accès, tenez compte des pratiques suivantes.

  • Utilisez des balises pour renforcer la bonne pratique de l'accès le moins privilégié. Accordez uniquement aux principaux IAM les autorisations dont ils ont besoin sur les clés KMS qu'ils doivent utiliser ou gérer. Par exemple, utilisez des balises pour étiqueter les clés KMS utilisées pour un projet. Donnez ensuite à l'équipe de projet l'autorisation d'utiliser uniquement les clés KMS avec la balise de projet.

  • Soyez prudent lorsque vous donnez aux principaux les autorisations kms:TagResource et kms:UntagResource qui leur permettent d'ajouter, de modifier et de supprimer des balises. Lorsque vous utilisez des balises pour contrôler l'accès aux clés KMS, la modification d'une balise peut donner aux principaux l'autorisation d'utiliser des clés KMS qu'ils n'avaient alors pas l'autorisation d'utiliser. Elle peut également refuser l'accès aux clés KMS dont d'autres principaux ont besoin pour réaliser leurs tâches. Les administrateurs de clés qui n'ont pas l'autorisation de modifier les politiques de clé ou de créer des octrois peuvent contrôler l'accès aux clés KMS s'ils sont autorisés à gérer les balises.

    Dans la mesure du possible, utilisez une condition de politique, telle que aws:RequestTag/tag-key ou aws:TagKeys pour limiter les autorisations d'étiquetage d'un principal à des balises ou des modèles de balises spécifiques sur des clés KMS particulières.

  • Passez en revue les principaux de votre Compte AWS qui disposent actuellement d'autorisations d'étiquetage et de désétiquetage et ajustez-les, si nécessaire. Par exemple, la politique de clé par défaut pour les administrateurs de clés de la console inclut les autorisations kms:TagResource et kms:UntagResource sur cette clé KMS. Les politiques IAM peuvent autoriser les autorisations d'étiquetage et de désétiquetage sur toutes les clés KMS. Par exemple, la politique AWSKeyManagementServicePowerUsergérée permet aux principaux de baliser, de débaliser et de répertorier les balises sur toutes les clés KMS.

  • Avant de définir une politique qui dépend d'une balise, examinez les balises des clés KMS dans votre Compte AWS. Assurez-vous que votre politique s'applique uniquement aux balises que vous avez l'intention d'inclure. Utilisez CloudTrail les journaux et les CloudWatch alarmes pour vous avertir des modifications de balises susceptibles d'affecter l'accès à vos clés KMS.

  • Les conditions de politique de balise utilisent la correspondance de modèles ; elles ne sont pas liées à une instance particulière d'une balise. Une politique qui utilise des clés de condition basées sur des balises affecte toutes les balises nouvelles et existantes qui correspondent au modèle. Si vous supprimez et recréez une balise qui correspond à une condition de politique, la condition s'applique à la nouvelle balise, comme elle l'a fait pour l'ancienne.

Prenons l'exemple de la politique IAM suivante : Il permet aux principaux d'appeler les opérations GenerateDataKeyWithoutPlaintextet de déchiffrer uniquement sur les clés KMS de votre compte appartenant à la région Asie-Pacifique (Singapour) et dotées d'un "Project"="Alpha" tag. Vous pouvez attacher cette politique à des rôles dans l'exemple de projet Alpha.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] }

L'exemple de politique IAM suivant autorise les principaux à utiliser n'importe quelle clé KMS dans le compte pour les opérations de chiffrement. Mais il interdit aux principaux d'utiliser ces opérations de chiffrement sur les clés KMS avec une identification "Type"="Reserved" ou sans identification "Type".

{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMAllowCryptographicOperations", "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey*", "kms:Decrypt", "kms:ReEncrypt*" ], "Resource": "arn:aws:kms:*:111122223333:key/*" }, { "Sid": "IAMDenyOnTag", "Effect": "Deny", "Action": [ "kms:Encrypt", "kms:GenerateDataKey*", "kms:Decrypt", "kms:ReEncrypt*" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Type": "Reserved" } } }, { "Sid": "IAMDenyNoTag", "Effect": "Deny", "Action": [ "kms:Encrypt", "kms:GenerateDataKey*", "kms:Decrypt", "kms:ReEncrypt*" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "Null": { "aws:ResourceTag/Type": "true" } } } ] }