ABAC pour AWS KMS

Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit des autorisations en fonction des attributs. AWS KMS prend en charge l'ABAC en vous permettant de contrôler l'accès à vos clés gérées par le client en fonction des balises et alias associés aux clés KMS. Les clés de condition de balise et d'alias qui activent l'ABAC dans AWS KMS offrent un moyen puissant et flexible d'autoriser les principaux à utiliser les clés KMS sans modifier les politiques ou gérer les octrois. 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 utilisez l'ABAC, 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 clés KMS avant de déployer une politique qui en dépend. 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

Lors de l'utilisation d'ABAC pour AWS KMS, soyez prudent lorsque vous autorisez les principaux à gérer les balises et les alias. La modification d'une balise ou d'un alias peut autoriser ou refuser l'accès à une clé KMS. 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 ou les alias.

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.

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

En savoir plus

• Pour plus de détails sur la prise en charge de AWS KMS pour l'ABAC, y compris des exemples, veuillez consulter Utilisation d'alias pour contrôler l'accès aux clés KMS et Utilisation de balises pour contrôler l'accès aux clés KMS.

• Pour plus d'informations générales 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.

Clés de condition ABAC pour AWS KMS

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

Clé de condition ABAC	Description	Type de stratégie	Opérations AWS KMS
lois : ResourceTag	La balise (clé et valeur) de la clé KMS correspond à la balise (clé et valeur) ou au modèle de balise dans la politique.	Politique IAM uniquement	Opérations liées aux ressources de clé KMS 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.	Politique de clé et politiques IAM1	TagResource, UntagResource
lois : TagKeys	Dans la demande, les clés de balise correspondent à celles de la politique.	Politique de clé et politiques IAM1	TagResource, UntagResource
km : ResourceAliases	Les alias associés à la clé KMS correspondent aux alias ou aux modèles d'alias de la politique.	Politique IAM uniquement	Opérations liées aux ressources de clé KMS 2
km : RequestAlias	L'alias qui représente la clé KMS dans la demande correspond à l'alias ou aux modèles d'alias de la politique.	Politique de clé et politiques IAM1	opérations cryptographiques, DescribeKeyGetPublicKey

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

²Une opération de ressource de clé KMS est une opération autorisée pour une clé KMS particulière. Pour identifier les opérations de ressources de clés KMS, dans la table AWS KMS des autorisations, recherchez la valeur de la clé KMS dans la colonne Resources de l'opération.

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

• Une politique IAM avec kms:ResourceAliases qui autorise l'utilisation de clés KMS 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 un Compte AWS et une région. Cela vous permet d'appliquer une politique à un ensemble de clés KMS sélectionné sans répertorier les ARN des clés KMS dans l'instruction de politique. Pour ajouter ou supprimer des clés KMS de l'ensemble, modifiez l'alias de la clé KMS.

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

• Une politique IAM avec aws:ResourceTag/tag-key qui refuse l'autorisation d'utiliser des clés KMS avec une clé et une valeur de balise particulières. Cela vous permet d'appliquer une politique à un ensemble de clés KMS sélectionné sans répertorier les ARN des clés KMS dans l'instruction de politique. Pour ajouter ou supprimer des clés KMS de l'ensemble, étiquetez ou désétiquetez la clé KMS.

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

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

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

Lorsqu'elle est attachée à un utilisateur ou à un rôle, la politique IAM suivante permet aux principaux d'utiliser toutes les clés KMS existantes avec une balise Purpose=Test pour les opérations spécifiées. Pour autoriser cet accès à des clés KMS nouvelles ou existantes, vous n'avez pas besoin de modifier la politique. Il suffit de joindre la balise Purpose=Test aux clés KMS. De même, pour supprimer cet accès des clés KMS avec une balise Purpose=Test, modifiez ou supprimez la balise.

{
  "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'une balise ou d'un alias peut autoriser ou refuser l'accès à une clé KMS par inadvertance. 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 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 Utilisation d'alias pour contrôler l'accès aux clés KMS et Utilisation de balises pour contrôler l'accès aux clés KMS.

Des balises ou des alias ?

AWS KMS prend en charge l'ABAC avec des balises et des 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 modèles d'utilisation AWS particuliers. 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 approchez du quota pour le nombre d'alias par clé KMS, vous pouvez préférer une stratégie d'autorisation basée sur des 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 ressources AWS.

  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 (Amazon RDS), un volume Amazon Elastic Block Store (Amazon EBS) et une clé KMS. Cette fonction permet plusieurs modèles d'autorisation plus flexibles que le contrôle d'accès classique basé sur les rôles.

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

  Vous pouvez utiliser des balises pour gérer l'accès à un groupe de clés KMS dans le même Compte AWS et la même région. Attribuez la même balise ou la même clé de balise aux clés KMS 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 clé KMS de votre groupe d'autorisations, ajoutez ou supprimez la balise ; vous n'avez pas besoin 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 clé KMS dans la demande. Par exemple, vous pouvez accorder à un principal l'autorisation d'utiliser une clé KMS dans une opération Encrypt mais uniquement lorsque la valeur du paramètre KeyId est alias/restricted-key-1. Cette condition nécessite tous les éléments suivants pour répondre aux exigences :

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

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

  • Le principal doit être autorisé à utiliser la clé KMS sujette à la condition kms:RequestAlias.

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

• Fournir des autorisations très limitées.

  Un alias doit être unique dans le compte et la région Compte AWS. Par conséquent, donner aux principaux accès à une clé KMS 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 affectées à plusieurs clés KMS dans le même compte et la même région. Si vous le souhaitez, vous pouvez utiliser un modèle d'alias, tel que alias/test*, pour donner aux principaux accès à un groupe de clés KMS dans le même compte et la même région. Cependant, autoriser ou refuser l'accès à un alias particulier permet un contrôle très strict sur les clés KMS.

Résolution des problèmes liés à l'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.

{
  "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"
        }
      }
    }
  ]
}

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.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:List*",
        "kms:Describe*",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:ResourceAliases": [
            "alias/ProjectAlpha",
            "alias/ProjectAlpha_Test",
            "alias/ProjectAlpha_Dev"
          ]
        }
      }
    }
  ]
}

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 opérations AWS KMS.

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.