ABACpour AWS KMS - AWS Key Management Service
ABACclés de condition pour AWS KMSDes balises ou des alias ?

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.

ABACpour AWS KMS

Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit les autorisations en fonction des attributs. AWS KMS vous aide ABAC en vous permettant de contrôler l'accès aux clés gérées par vos clients en fonction des balises et des alias associés aux KMS clés. Les clés de condition associées aux balises et ABAC aux alias AWS KMS fournissent un moyen puissant et flexible d'autoriser les principaux à utiliser les KMS clés sans modifier les politiques ni gérer les subventions. Toutefois, vous devriez utiliser cette fonction avec précaution, afin que les principaux ne soient pas autorisés ou refusés par inadvertance.

Si vous l'utilisezABAC, sachez que l'autorisation de gérer les balises et les alias est désormais une autorisation de contrôle d'accès. Assurez-vous de connaître les balises et alias existants sur toutes les KMS clés avant de déployer une politique qui dépend des balises ou des alias. Prenez des précautions raisonnables lors de l'ajout, de la suppression et de la mise à jour des alias, ainsi que lors de l'étiquetage et du désétiquetage des clés. Accordez des autorisations pour gérer les balises et les alias uniquement aux principaux qui en ont besoin, et limitez les balises et les alias qu'ils peuvent gérer.

Remarques

Lorsque vous utilisez ABAC for AWS KMS, veillez à ne pas autoriser les principaux à gérer les balises et les alias. La modification d'un tag ou d'un alias peut autoriser ou refuser l'accès à une KMS clé. Les administrateurs clés qui ne sont pas autorisés à modifier les politiques clés ou à créer des autorisations peuvent contrôler l'accès aux KMS clés s'ils sont autorisés à gérer les balises ou les alias.

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

Pour contrôler l'accès à une KMS clé en fonction de son alias, vous devez utiliser une clé de condition. Vous ne pouvez pas utiliser d'alias pour représenter une KMS clé dans l'Resourceélément d'une déclaration de politique. Lorsqu'un alias apparaît dans l'Resourceélément, la déclaration de politique s'applique à l'alias, et non à la KMS clé associée.

En savoir plus

ABACclés de condition pour AWS KMS

Pour autoriser l'accès aux KMS clés en fonction de leurs balises et de leurs alias, utilisez les clés de condition suivantes dans une politique ou IAM une politique clé.

ABACclé de condition Description Type de stratégie AWS KMS opérations
lois : ResourceTag La balise (clé et valeur) figurant sur la KMS clé correspond à la balise (clé et valeur) ou au modèle de balise de la politique IAMpolitique uniquement KMSopérations relatives aux ressources clés 2
aws :RequestTag//tag-key La balise (clé et valeur) dans la demande correspond à la balise (clé et valeur) ou au modèle de balise dans la politique. Politiques et IAM politiques clés 1 TagResource, UntagResource
lois : TagKeys Dans la demande, les clés de balise correspondent à celles de la politique. Politiques et IAM politiques clés 1 TagResource, UntagResource
km : ResourceAliases Les alias associés à la KMS clé correspondent aux alias ou aux modèles d'alias de la politique IAMpolitique uniquement KMSopérations relatives aux ressources clés 2
km : RequestAlias L'alias qui représente la KMS clé de la demande correspond à l'alias ou aux modèles d'alias de la politique. Politiques et IAM politiques clés 1 opérations cryptographiques, DescribeKeyGetPublicKey

1 Toute clé de condition qui peut être utilisée dans une politique clé peut également être utilisée dans une IAM politique, mais uniquement si la politique clé le permet.

2 Une opération sur une ressource KMS clé est une opération autorisée pour une KMS clé particulière. Pour identifier les KMS principales opérations sur les ressources, dans le tableau AWS KMS des autorisations, recherchez la valeur KMS clé dans la Resources colonne correspondant à l'opération.

Par exemple, vous pouvez utiliser ces clés de condition pour créer les politiques suivantes.

  • Une IAM politique kms:ResourceAliases qui autorise l'utilisation de KMS clés avec un alias ou un modèle d'alias particulier. Cela est un peu différent des politiques qui reposent sur des balises : bien que vous puissiez utiliser des modèles d'alias dans une politique, chaque alias doit être unique dans une région Compte AWS et. Cela vous permet d'appliquer une politique à un ensemble de KMS clés sélectionné sans répertorier la clé ARNs des KMS clés dans la déclaration de stratégie. Pour ajouter ou supprimer KMS des clés de l'ensemble, modifiez l'alias de la KMS clé.

  • Une politique clé kms:RequestAlias qui permet aux principaux d'utiliser une KMS clé dans une Encrypt opération, mais uniquement lorsque la Encrypt demande utilise cet alias pour identifier la KMS clé.

  • Une IAM politique aws:ResourceTag/tag-key qui refuse l'autorisation d'utiliser des KMS clés associées à une clé de balise et à une valeur de balise spécifiques. Cela vous permet d'appliquer une politique à un ensemble de KMS clés sélectionné sans répertorier la clé ARNs des KMS clés dans la déclaration de stratégie. Pour ajouter ou supprimer KMS des clés de l'ensemble, étiquetez ou décochez la KMS clé.

  • Une IAM politique aws:RequestTag/tag-key qui permet aux principaux de supprimer uniquement les tags "Purpose"="Test" KMS clés.

  • Une IAM politique aws:TagKeys qui refuse l'autorisation de baliser ou de débaliser une KMS clé avec une clé de Restricted balise.

ABACrend la gestion des accès flexible et évolutive. Par exemple, vous pouvez utiliser la clé de aws:ResourceTag/tag-key condition pour créer une IAM politique qui autorise les principaux à utiliser une KMS clé pour des opérations spécifiques uniquement lorsque la KMS clé possède une Purpose=Test balise. La politique s'applique à toutes les KMS clés dans toutes les régions du Compte AWS.

Lorsqu'ils sont attachés à un utilisateur ou à un rôle, la IAM politique suivante permet aux principaux d'utiliser toutes les KMS clés existantes avec une Purpose=Test balise pour les opérations spécifiées. Pour fournir cet accès à des KMS clés nouvelles ou existantes, il n'est pas nécessaire de modifier la politique. Il suffit de fixer l'Purpose=Testétiquette aux KMS clés. De même, pour supprimer cet accès des KMS clés comportant un Purpose=Test tag, modifiez ou supprimez le tag. 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Purpose": "Test"
        }
      }
    }
  ]
}

Toutefois, si vous utilisez cette fonction, faites attention lors de la gestion des balises et des alias. L'ajout, la modification ou la suppression d'un tag ou d'un alias peut autoriser ou refuser par inadvertance l'accès à une KMS clé. Les administrateurs clés qui ne sont pas autorisés à modifier les politiques clés ou à créer des autorisations peuvent contrôler l'accès aux KMS clés s'ils sont autorisés à gérer les balises et les alias. Pour atténuer ce risque, envisagez de limiter les autorisations de gestion des balises et des alias. Par exemple, vous pouvez autoriser uniquement les principaux sélectionnés à gérer les balises Purpose=Test. Pour plus de détails, veuillez consulter Utiliser des alias pour contrôler l'accès aux clés KMS et Utiliser des balises pour contrôler l'accès aux KMS clés.

Des balises ou des alias ?

AWS KMS supports ABAC avec tags et alias. Les deux options offrent une stratégie de contrôle d'accès flexible et évolutive, mais elles sont légèrement différentes l'une de l'autre.

Vous pouvez décider d'utiliser des balises ou des alias en fonction de vos habitudes AWS d'utilisation particulières. Par exemple, si vous avez déjà accordé des autorisations d'étiquetage à la plupart des administrateurs, il peut être plus facile de contrôler une stratégie d'autorisation basée sur des alias. Ou, si vous êtes proche du quota d'alias par KMS clé, vous préférerez peut-être une stratégie d'autorisation basée sur les balises.

Les avantages suivants sont d'intérêt général.

Avantages du contrôle d'accès basé sur les identifications

  • Même mécanisme d'autorisation pour différents types de AWS ressources.

    Vous pouvez utiliser la même balise ou clé de balise pour contrôler l'accès à plusieurs types de ressources, tels qu'un cluster Amazon Relational Database Service (RDSAmazon), un volume Amazon Elastic Block Store (EBSAmazon) et KMS une clé. Cette fonction permet plusieurs modèles d'autorisation plus flexibles que le contrôle d'accès classique basé sur les rôles.

  • Autorisez l'accès à un groupe de KMS clés.

    Vous pouvez utiliser des balises pour gérer l'accès à un groupe de KMS clés dans la même Compte AWS région. Attribuez le même tag ou la même clé de tag aux KMS clés que vous choisissez. Créez ensuite une déclaration de easy-to-maintain politique simple basée sur le tag ou la clé du tag. Pour ajouter ou supprimer une KMS clé de votre groupe d'autorisation, ajoutez ou supprimez la balise ; il n'est pas nécessaire de modifier la politique.

Avantages du contrôle d'accès basé sur les alias

  • Autoriser l'accès aux opérations cryptographiques en fonction des alias.

    La plupart des conditions de politique basées sur les demandes pour les attributs, y compris aws :RequestTag/tag-key, affectent uniquement les opérations qui ajoutent, modifient ou suppriment l'attribut. Mais la clé de RequestAlias condition kms : contrôle l'accès aux opérations cryptographiques en fonction de l'alias utilisé pour identifier la KMS clé dans la demande. Par exemple, vous pouvez autoriser un principal à utiliser une KMS clé dans une Encrypt opération, mais uniquement lorsque la valeur du KeyId paramètre estalias/restricted-key-1. Cette condition nécessite tous les éléments suivants pour répondre aux exigences :

    • La KMS clé doit être associée à cet alias.

    • La demande doit utiliser l'alias pour identifier la KMS clé.

    • Le directeur doit être autorisé à utiliser la KMS clé sous réserve de kms:RequestAlias cette condition.

    Cela est particulièrement utile si vos applications utilisent fréquemment des noms d'alias ou des alias ARNs pour faire référence à KMS des clés.

  • Fournir des autorisations très limitées.

    Un alias doit être unique dans une région Compte AWS et. Par conséquent, donner aux principaux accès à une KMS clé basée sur un alias peut être beaucoup plus restrictif que leur donner un accès basé sur une balise. Contrairement aux alias, les balises peuvent être attribuées à plusieurs KMS clés dans le même compte et dans la même région. Si vous le souhaitez, vous pouvez utiliser un modèle d'alias, par exemple pour permettre aux principaux d'accéder à un groupe de KMS clés dans le même compte et dans la même région. alias/test* Cependant, autoriser ou refuser l'accès à un alias particulier permet un contrôle très strict des KMS clés.