Bonnes pratiques en matière de IAM politiques - 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.

Bonnes pratiques en matière de IAM politiques

La sécurisation de l'accès AWS KMS keys est essentielle à la sécurité de toutes vos AWS ressources. KMSles clés sont utilisées pour protéger la plupart des ressources les plus sensibles de votre ordinateur Compte AWS. Prenez le temps de concevoir les politiques clés, les IAM politiques, les autorisations et les politiques relatives aux VPC terminaux qui contrôlent l'accès à vos KMS clés.

Dans les déclarations de IAM politique qui contrôlent l'accès aux KMS clés, utilisez le principe du moins privilégié. IAMAccordez aux directeurs uniquement les autorisations dont ils ont besoin sur les KMS clés qu'ils doivent utiliser ou gérer.

Les meilleures pratiques suivantes s'appliquent aux IAM politiques qui contrôlent l'accès aux AWS KMS clés et aux alias. Pour obtenir des conseils généraux IAM sur les meilleures pratiques en matière de politique, consultez la section Bonnes pratiques en matière de sécurité IAM dans le guide de IAM l'utilisateur.

Utilisation de politiques de clé

Dans la mesure du possible, accordez des autorisations dans des politiques clés qui affectent une KMS clé, plutôt que dans une IAM politique qui peut s'appliquer à de nombreuses KMS clés, y compris celles d'autres clés Comptes AWS. Cela est particulièrement important pour les autorisations sensibles telles que kms : PutKeyPolicy et kms : ScheduleKeyDeletion mais également pour les opérations cryptographiques qui déterminent la manière dont vos données sont protégées.

Limiter CreateKey l'autorisation

Donnez l'autorisation de créer des clés (kms : CreateKey) uniquement aux principaux qui en ont besoin. Les directeurs qui créent une KMS clé définissent également sa politique en matière de clés, afin qu'ils puissent se donner, ainsi qu'à d'autres, l'autorisation d'utiliser et de gérer les KMS clés qu'ils créent. Lorsque vous accordez cette autorisation, envisagez de la limiter en utilisant les conditions de politique. Par exemple, vous pouvez utiliser la KeySpec condition kms : pour limiter l'autorisation aux KMS clés de chiffrement symétriques.

Spécifier KMS les clés dans une IAM politique

La meilleure pratique consiste à spécifier la clé ARN de chaque KMS clé à laquelle l'autorisation s'applique dans l'Resourceélément de la déclaration de politique. Cette pratique limite l'autorisation aux KMS clés requises par le principal. Par exemple, cet Resource élément répertorie uniquement les KMS clés que le principal doit utiliser.

"Resource": [ "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "arn:aws:kms:us-west-2:111122223333:key/0987dcba-09fe-87dc-65ba-ab0987654321" ]

Lorsque la spécification de KMS clés n'est pas pratique, utilisez une Resource valeur qui limite l'accès aux KMS clés dans une région sécurisée Compte AWS , telle quearn:aws:kms:region:account:key/*. Ou limitez l'accès aux KMS clés dans toutes les régions (*) d'une personne de confiance Compte AWS, telle quearn:aws:kms:*:account:key/*.

Vous ne pouvez pas utiliser un identifiant de clé, un nom d'alias ou un alias ARN pour représenter une KMS clé dans le Resource champ d'une IAM politique. Si vous spécifiez un aliasARN, la politique s'applique à l'alias, et non à la KMS clé. Pour plus d'informations sur IAM les politiques relatives aux alias, voir Contrôle de l'accès aux alias

Évitez « Ressource » : « * » dans une IAM politique

Utilisez judicieusement les caractères génériques (*). Dans une politique clé, le caractère générique de l'Resourceélément représente la KMS clé à laquelle la politique clé est attachée. Mais dans une IAM politique, un caractère générique seul dans l'Resourceélément ("Resource": "*") applique les autorisations à toutes les KMS clés de toutes les clés Comptes AWS que le compte du principal est autorisé à utiliser. Cela peut inclure des KMSclés dans d'autres comptes Comptes AWS, ainsi que KMS des clés du compte du principal.

Par exemple, pour utiliser une KMS clé dans un autre compte Compte AWS, un mandant doit obtenir l'autorisation de la politique de KMS clé du compte externe et d'une IAM politique de son propre compte. Supposons qu'un compte arbitraire ait autorisé vos clés à Compte AWS KMS:Decrypt. KMS Si tel est le cas, une IAM politique de votre compte accordant une kms:Decrypt autorisation de rôle sur toutes les KMS clés ("Resource": "*") satisferait à la IAM partie de l'exigence. Par conséquent, les principaux habilités à assumer ce rôle peuvent désormais déchiffrer les textes chiffrés à l'aide de la KMS clé du compte non fiable. Les entrées relatives à leurs opérations apparaissent dans les CloudTrail journaux des deux comptes.

En particulier, évitez de l'utiliser "Resource": "*" dans une déclaration de politique qui autorise les API opérations suivantes. Ces opérations peuvent être appelées sur des KMS touches dans d'autres Comptes AWS.

Quand utiliser « Resource » : « * »

Dans une IAM politique, utilisez un caractère générique dans l'Resourceélément uniquement pour les autorisations qui l'exigent. Seules les autorisations suivantes nécessitent l'élément "Resource": "*".

Note

Les autorisations pour les opérations d'alias (kms : CreateAlias, kms : UpdateAlias, kms : DeleteAlias) doivent être associées à l'alias et à la KMS clé. Vous pouvez les utiliser "Resource": "*" dans une IAM politique pour représenter les alias et les KMS clés, ou pour spécifier les alias et les KMS clés de l'Resourceélément. Pour obtenir des exemples, consultez Contrôle de l'accès aux alias.

 

Les exemples présentés dans cette rubrique fournissent des informations et des conseils supplémentaires pour la conception de IAM politiques relatives aux KMS clés. Pour connaître les IAM meilleures pratiques pour toutes les AWS ressources, consultez la section Bonnes pratiques en matière de sécurité IAM dans le guide de IAM l'utilisateur.