Bonnes pratiques de chiffrement pour AWS Key Management Service - AWS Conseils prescriptifs

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 de chiffrement pour AWS Key Management Service

AWS Key Management Service (AWS KMS) vous aide à créer et à contrôler des clés cryptographiques afin de protéger vos données. AWS KMS s'intègre à la plupart des autres systèmes Services AWS capables de chiffrer vos données. Pour une liste complète, voir Services AWS intégré à AWS KMS. AWS KMS s'intègre également AWS CloudTrail pour enregistrer l'utilisation de vos KMS clés à des fins d'audit, de réglementation et de conformité.

KMSles clés constituent la ressource principale d'une clé cryptographique et elles sont des représentations logiques d'une clé cryptographique. AWS KMS Il existe trois principaux types de KMS clés :

  • Les clés gérées par le client sont KMS des clés que vous créez.

  • AWS les clés gérées sont Services AWS des KMS clés créées dans votre compte, en votre nom.

  • AWS les clés possédées sont KMS des clés qu'un Service AWS utilisateur possède et gère, destinées à être utilisées dans plusieurs domaines Comptes AWS.

Pour plus d'informations sur ces types de clés, veuillez consulter Clés de client et clés AWS.

Dans le AWS Cloud, les politiques sont utilisées pour contrôler qui peut accéder aux ressources et aux services. Par exemple, dans AWS Identity and Access Management (IAM), les politiques basées sur l'identité définissent les autorisations pour les utilisateurs, les groupes d'utilisateurs ou les rôles, et les politiques basées sur les ressources s'attachent à une ressource, telle qu'un compartiment S3, et définissent les principaux auxquels l'accès est autorisé, les actions prises en charge et toutes les autres conditions devant être remplies. À IAM l'instar des politiques, AWS KMS utilise des politiques clés pour contrôler l'accès à une KMS clé. Chaque KMS clé doit avoir une politique clé, et chaque clé ne peut avoir qu'une seule politique clé. Lorsque vous définissez des politiques autorisant ou refusant l'accès aux KMS clés, tenez compte des points suivants :

  • Vous pouvez contrôler la politique clé pour les clés gérées par le client, mais vous ne pouvez pas contrôler directement la politique clé pour les clés AWS gérées ou pour les clés AWS détenues.

  • Les politiques clés permettent d'accorder un accès granulaire aux AWS KMS API appels au sein d'un Compte AWS. À moins que la politique des clés ne l'autorise explicitement, vous ne pouvez pas utiliser de IAM politiques pour autoriser l'accès à une KMS clé. Sans l'autorisation de la politique clé, IAM les politiques qui autorisent les autorisations n'ont aucun effet. Pour plus d'informations, consultez la section Autoriser IAM les politiques pour autoriser l'accès à la KMS clé.

  • Vous pouvez utiliser une IAM politique pour refuser l'accès à une clé gérée par le client sans l'autorisation correspondante de la politique de clés.

  • Lorsque vous concevez des politiques clés et IAM des politiques pour des clés multirégionales, tenez compte des points suivants :

    • Les politiques de clé ne sont pas des propriétés partagées des clés multi-région et ne sont pas copiées ou synchronisées entre les clés multi-région associées.

    • Lorsqu'une clé multi-région est créée à l'aide des actions CreateKey et ReplicateKey, la politique de clé par défaut est appliquée, sauf si une politique de clé est spécifiée dans la demande.

    • Vous pouvez implémenter des clés de condition, telles que aws : RequestedRegion, pour limiter les autorisations à une personne en particulier Région AWS.

    • Vous pouvez utiliser des octrois pour autoriser des autorisations sur une clé principale ou une clé de réplica multi-région. Cependant, une seule autorisation ne peut pas être utilisée pour autoriser plusieurs KMS clés, même s'il s'agit de clés multirégionales associées.

Lorsque vous utilisez AWS KMS et créez des politiques clés, tenez compte des meilleures pratiques de chiffrement et autres bonnes pratiques de sécurité suivantes :

  • Respectez les recommandations des ressources suivantes pour connaître les AWS KMS meilleures pratiques :

  • Conformément aux bonnes pratiques en matière de séparation des tâches, maintenez des identités distinctes pour ceux qui administrent les clés et ceux qui les utilisent :

    • Les rôles d'administrateur qui créent et suppriment des clés ne doivent pas être autorisés à utiliser la clé.

    • Certains services peuvent uniquement avoir besoin de chiffrer les données et ne devraient pas être autorisés à les déchiffrer à l'aide de la clé.

  • Les politiques de clé devraient toujours suivre le modèle du moindre privilège. Ne l'utilisez pas kms:* pour des actions IAM ou des politiques clés, car cela donne au principal l'autorisation d'administrer et d'utiliser la clé.

  • Limitez l'utilisation des clés gérées Services AWS par le client à des éléments spécifiques en utilisant la clé de ViaService condition kms : dans le cadre de la politique des clés.

  • Si vous avez le choix entre plusieurs types de clé, les clés gérées par le client sont préférables, car elles fournissent les options de contrôle les plus détaillées, dont les suivantes :

  • AWS KMS les autorisations d'administration et de modification doivent être explicitement refusées aux principaux non approuvés et les autorisations de AWS KMS modification ne doivent pas exister dans une instruction d'autorisation pour les principaux non autorisés. Pour de plus amples informations, consultez Actions, ressources et clés de condition pour AWS Key Management Service

  • Afin de détecter toute utilisation non autorisée des KMS clés AWS Config, implémentez les règles iam-customer-policy-blocked-kms-actions et iam-inline-policy-blocked -kms-actions. Cela empêche les principaux d'utiliser les actions de AWS KMS déchiffrement sur toutes les ressources.

  • Mettez en œuvre des politiques de contrôle des services (SCPs) AWS Organizations pour empêcher les utilisateurs ou les rôles non autorisés de supprimer des KMS clés, soit directement sous forme de commande, soit via la console. Pour plus d'informations, voir Utilisation SCPs comme contrôles préventifs (article de AWS blog).

  • Enregistrez AWS KMS API les appels dans un CloudTrail journal. Cela permet d'enregistrer les attributs d'événement pertinents, tels que les demandes qui ont été effectuées, l'adresse IP source à partir de laquelle la demande a été faite, ainsi que l'auteur de la demande. Pour plus d'informations, consultez la section Enregistrement AWS KMS API des appels avec AWS CloudTrail.

  • Si vous utilisez un contexte de chiffrement, celui-ci ne doit contenir aucune information sensible. CloudTrail stocke le contexte de chiffrement dans des JSON fichiers en texte brut, qui peuvent être consultés par toute personne ayant accès au compartiment S3 contenant les informations.

  • Lorsque vous surveillez l'utilisation des clés gérées par le client, configurez des événements pour vous avertir si des actions spécifiques sont détectées, telles que la création de clés, les mises à jour apportées à des politiques de clés gérées par le client ou l'importation d'éléments de clé. Il est également recommandé de mettre en œuvre des réponses automatisées, telles qu'une fonction AWS Lambda qui désactive la clé ou exécute toute autre action de réponse aux incidents conformément à vos politiques organisationnelles.

  • Les clés multi-région sont recommandées pour des scénarios spécifiques, tels que la conformité, la reprise après sinistre ou les sauvegardes. Les propriétés de sécurité des clés multi-région sont très différentes de celles des clés à région unique. Les recommandations suivantes s'appliquent lors de l'autorisation de la création, de la gestion et de l'utilisation de clés multi-région :

    • Autoriser les principaux à répliquer une clé multi-région uniquement dans les Régions AWS qui l'exigent.

    • Donnez l'autorisation pour les clés multi-région uniquement aux principaux qui en ont besoin et uniquement pour les tâches qui en ont besoin.