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.
Résolution des problèmes liés à ABAC pour AWS KMS
Le contrôle de l'accès aux clés KMS en fonction de leurs balises et alias est pratique et puissant. Cependant, cette méthode est sujette à quelques erreurs prévisibles que vous voudrez éviter.
Accès modifié en raison d'un changement de balise
Si une balise est supprimée ou si sa valeur est modifiée, les principaux qui ont accès à une clé KMS basée uniquement sur cette balise se verront refuser l'accès à la clé KMS. Cela peut également se produire lorsqu'une balise incluse dans une instruction de politique de refus est ajoutée à une clé KMS. L'ajout d'une balise liée à une politique à une clé KMS peut permettre l'accès aux principaux qui devraient se voir refuser l'accès à une clé KMS.
Supposons, par exemple, qu'un principal ait accès à une clé KMS basée sur la balise Project=Alpha, par exemple l'autorisation fournie par l'exemple d'instruction de politique IAM suivant.
Si la balise est supprimée de cette clé KMS ou si la valeur de la balise est modifiée, le principal n'a plus l'autorisation d'utiliser la clé KMS pour les opérations spécifiées. Cela peut devenir évident lorsque le directeur essaie de lire ou d'écrire des données dans un AWS service qui utilise une clé gérée par le client. Pour suivre le changement de balise, consultez vos CloudTrail journaux TagResourceou UntagResource entrées.
Pour restaurer l'accès sans mettre à jour la politique, modifiez les balises de la clé KMS. Cette mesure a un impact minime sur une brève période et elle prend effet sur l'ensemble de AWS KMS. Pour éviter une erreur comme celle-ci, accordez des autorisations d'étiquetage et de désétiquetage uniquement aux principaux qui en ont besoin et limitez leurs autorisations d'étiquetage aux balises qu'ils doivent gérer. Avant de modifier une balise, recherchez des politiques pour détecter l'accès qui dépend de la balise et obtenir des clés KMS dans toutes les régions qui possèdent la balise. Vous pouvez envisager de créer une CloudWatch alarme Amazon lorsque des balises spécifiques sont modifiées.
Changement d'accès dû à un changement d'alias
Si un alias est supprimé ou associé à une autre clé KMS, les principaux qui ont accès à la clé KMS basée uniquement sur cet alias se verront refuser l'accès à la clé KMS. Cela peut également se produire lorsqu'un alias associé à une clé KMS est inclus dans une instruction de politique de refus. L'ajout d'un alias lié à une politique à une clé KMS peut également permettre l'accès aux principaux qui devraient se voir refuser l'accès à une clé KMS.
Par exemple, la déclaration de politique IAM suivante utilise la clé de ResourceAliases condition kms : pour autoriser l'accès aux clés KMS dans les différentes régions du compte avec l'un des alias spécifiés.
Pour suivre le changement d'alias, consultez vos CloudTrail journaux pour CreateAliasUpdateAlias, et vos DeleteAliasentrées.
Pour restaurer l'accès sans mettre à jour la politique, modifiez les alias associés à la clé KMS. Étant donné que chaque alias ne peut être associé qu'à une seule clé KMS dans un compte et une région, la gestion des alias est un peu plus difficile que la gestion des balises. La restauration de l'accès de certains principaux sur une clé KMS peut refuser au même ou à d'autres principaux l'accès à une autre clé KMS.
Pour éviter cette erreur, n'accordez des autorisations de gestion d'alias qu'aux principaux qui en ont besoin et limitez leurs autorisations de gestion des alias aux alias qu'ils doivent gérer. Avant de mettre à jour ou de supprimer un alias, recherchez des politiques pour détecter l'accès qui dépend de l'alias et recherchez les clés KMS dans toutes les régions associées à l'alias.
Accès refusé en raison d'un quota d'alias
Les utilisateurs autorisés à utiliser une clé KMS dans une limite de kilomètres bénéficieront ResourceAliases d'une AccessDenied exception si la clé KMS dépasse les alias par défaut par quota de clé KMS pour ce compte et cette région.
Pour restaurer l'accès, supprimez les alias associés à la clé KMS afin qu'elle soit conforme au quota. Sinon, utilisez un autre mécanisme pour accorder aux utilisateurs l'accès à la clé KMS.
Modification retardée de l'autorisation
Les modifications que vous apportez aux balises et aux alias peuvent prendre jusqu'à cinq minutes pour affecter l'autorisation des clés KMS. Par conséquent, un changement de balise ou d'alias peut être reflété dans les réponses des opérations d'API avant qu'elles n'affectent l'autorisation. Ce délai est susceptible d'être plus long que le bref délai de cohérence éventuel qui affecte la plupart des AWS KMS opérations.
Par exemple, vous disposez peut-être d'une politique IAM qui autorise certains principaux à utiliser n'importe quelle clé KMS avec une balise "Purpose"="Test". Ensuite, vous ajoutez la balise "Purpose"="Test" sur une clé KMS. Bien que l'TagResourceopération soit terminée et que la ListResourceTagsréponse confirme que la balise est attribuée à la clé KMS, les principaux peuvent ne pas avoir accès à la clé KMS pendant cinq minutes au maximum.
Pour éviter les erreurs, intégrez ce délai attendu à votre code.
Demandes ayant échoué en raison des mises à jour d'alias
Lorsque vous mettez à jour un alias, vous associez un alias existant à une autre clé KMS.
Le déchiffrement et les ReEncryptdemandes spécifiant le nom d'alias ou l'ARN de l'alias peuvent échouer car l'alias est désormais associé à une clé KMS qui n'a pas chiffré le texte chiffré. Cette situation renvoie généralement un IncorrectKeyException ou NotFoundException. Si la demande n'a pas de paramètre KeyId ou DestinationKeyId, l'opération peut échouer avec l'exception AccessDenied, car l'appelant n'a plus accès à la clé KMS qui a chiffré le texte chiffré.
Vous pouvez suivre les modifications en consultant CloudTrail les journaux et CreateAliasUpdateAliasles entrées des DeleteAliasjournaux. Vous pouvez également utiliser la valeur du LastUpdatedDate champ dans la ListAliasesréponse pour détecter un changement.
Par exemple, l'ListAliasesexemple de réponse suivant montre que l'ProjectAlpha_Testalias de la kms:ResourceAliases condition a été mis à jour. Par conséquent, les principaux qui ont un accès en fonction de l'alias perdent leur accès à la clé KMS précédemment associée. Au lieu de cela, ils ont accès à la clé KMS nouvellement associée.
$aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'{ "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] }
La solution à ce problème n'est pas simple. Vous pouvez à nouveau mettre à jour l'alias pour l'associer à la clé KMS d'origine. Toutefois, avant d'agir, vous devez tenir compte de l'effet de cette modification sur la clé KMS actuellement associée. Si les principaux utilisent cette dernière clé KMS dans des opérations de chiffrement, ils peuvent avoir besoin d'un accès continu à celle-ci. Dans ce cas, vous pouvez mettre à jour la politique pour vous assurer que les principaux ont l'autorisation d'utiliser les deux clés KMS.
Vous pouvez empêcher une erreur comme celle-ci : avant de mettre à jour un alias, examinez les politiques pour détecter l'accès qui dépend de l'alias. Obtenez ensuite les clés KMS dans toutes les régions associées à l'alias. Accordez des autorisations de gestion d'alias uniquement aux principaux qui en ont besoin et limitez leurs autorisations de gestion d'alias aux alias qu'ils doivent gérer.
