Les meilleures pratiques pour AWS Encryption SDK

Lorsque vous commencez à utiliser le AWS Encryption SDK, utilisez la dernière version proposée dans votre langage de programmation préféré. Si vous utilisez le AWS Encryption SDK, passez à la dernière version dès que possible. Cela garantit que vous utilisez la configuration recommandée et que vous tirez parti des nouvelles propriétés de sécurité pour protéger vos données. Pour plus de détails sur les versions prises en charge, y compris des conseils pour la migration et le déploiement, consultez Support et maintenance etVersions du AWS Encryption SDK.

Si une nouvelle version rend obsolètes des éléments de votre code, remplacez-les dès que possible. Les avertissements de dépréciation et les commentaires de code recommandent généralement une bonne alternative.

Pour faciliter les mises à niveau importantes et réduire le risque d'erreurs, nous proposons occasionnellement une version temporaire ou transitoire. Utilisez ces versions et la documentation qui les accompagne pour vous assurer de pouvoir mettre à niveau votre application sans perturber votre flux de production.

Les meilleures pratiques de AWS Encryption SDK conception sont intégrées à ses valeurs par défaut. Dans la mesure du possible, utilisez-les. Dans les cas où la valeur par défaut n'est pas pratique, nous proposons des alternatives, telles que des suites d'algorithmes sans signature. Nous offrons également aux utilisateurs avancés des possibilités de personnalisation, telles que des porte-clés personnalisés, des fournisseurs de clés principales et des gestionnaires de matériel cryptographique (MMM). Utilisez ces alternatives avancées avec prudence et faites vérifier vos choix par un ingénieur en sécurité dans la mesure du possible.

Pour améliorer la sécurité de vos opérations cryptographiques, incluez un contexte de chiffrement avec une valeur significative dans toutes les demandes de chiffrement de données. L'utilisation d'un contexte de chiffrement est facultative, mais nous vous recommandons un contexte cryptographique dans le cadre des bonnes pratiques. Un contexte de chiffrement fournit des données authentifiées supplémentaires (AAD) pour le chiffrement authentifié dans le. AWS Encryption SDK Bien qu'il ne soit pas secret, le contexte de chiffrement peut vous aider à protéger l'intégrité et l'authenticité de vos données chiffrées.

Dans le AWS Encryption SDK, vous ne spécifiez un contexte de chiffrement que lors du chiffrement. Lors du déchiffrement, le AWS Encryption SDK utilise le contexte de chiffrement dans l'en-tête du message chiffré qu'il renvoie. AWS Encryption SDK Avant que votre application ne renvoie des données en texte brut, vérifiez que le contexte de chiffrement que vous avez utilisé pour chiffrer le message est inclus dans le contexte de cryptage utilisé pour déchiffrer le message. Pour plus de détails, consultez les exemples de votre langage de programmation.

Lorsque vous utilisez l'interface de ligne de commande, le contexte AWS Encryption SDK de chiffrement est vérifié pour vous.

Contexte de chiffrement requis avec la Material Providers Library

En commençant par les versions AWS Encryption SDK qui intègrent la bibliothèque MPL (AWS Cryptographic Material Providers Library) (par exemple, la version 3). x et versions ultérieures de la Kit SDK de chiffrement AWS pour Java et version 4. x et versions ultérieures du Kit SDK de chiffrement AWS pour Python), vous pouvez configurer une CMM de contexte de chiffrement requise qui marque les clés de contexte de chiffrement sélectionnées comme requises. Les clés de contexte de chiffrement requises et leurs valeurs sont toujours liées au texte chiffré en tant que données authentifiées supplémentaires (AAD), mais les clés ne sont pas stockées dans l'en-tête du message chiffré. L'appelant doit fournir les mêmes clés et valeurs de contexte de chiffrement requises lors du déchiffrement ; sinon, le déchiffrement échoue. Cela réduit la taille du texte chiffré pour le contexte de chiffrement dont dispose déjà l'appelant, tout en préservant les propriétés d'authentification et d'intégrité du contexte de chiffrement.

Cross-version et compatibilité multilingue

Les messages qui incluent l'intégralité du contexte de chiffrement dans l'en-tête (produits par des AWS Encryption SDK versions qui ne configurent pas un contexte de chiffrement CMM requis) peuvent être déchiffrés par n'importe quelle AWS Encryption SDK version compatible, y compris les versions antérieures à l'intégration MPL. Les messages produits avec un contexte de chiffrement CMM requis ne peuvent être déchiffrés que par des AWS Encryption SDK versions intégrant le MPL, et l'appelant doit fournir les clés et valeurs de contexte de cryptage requises au moment du déchiffrement. Pour plus d'informations sur les versions linguistiques qui intègrent le MPL, consultezAWS Encryption SDK langages de programmation. Pour plus de détails sur la compatibilité entre versions, consultezVersions du AWS Encryption SDK.

AWS Encryption SDK Génère une clé de données unique pour crypter chaque message en texte brut. Ensuite, il chiffre la clé de données à l'aide des clés d'encapsulage que vous fournissez. Si vos clés d'emballage sont perdues ou supprimées, vos données cryptées ne peuvent pas être récupérées. Si vos clés ne sont pas sécurisées, vos données peuvent être vulnérables.

Utilisez des clés d'encapsulage protégées par une infrastructure de clés sécurisée, telle que AWS Key Management Service (AWS KMS). Lorsque vous utilisez des clés AES ou RSA brutes, utilisez une source aléatoire et un stockage durable qui répond à vos exigences de sécurité. Il est recommandé de générer et de stocker des clés d'encapsulation dans un module de sécurité matériel (HSM) ou un service fournissant des HSM AWS CloudHSM, par exemple.

Utilisez les mécanismes d'autorisation de votre infrastructure de clés pour limiter l'accès à vos clés d'emballage aux seuls utilisateurs qui en ont besoin. Mettez en œuvre les principes des meilleures pratiques, tels que le principe du moindre privilège. Lors de l'utilisation AWS KMS keys, utilisez des politiques clés et des politiques IAM qui mettent en œuvre les principes des meilleures pratiques.

Il est toujours recommandé de spécifier explicitement vos clés d'emballage lors du déchiffrement et du chiffrement. Lorsque vous le faites, il AWS Encryption SDK utilise uniquement les touches que vous spécifiez. Cette pratique garantit que vous n'utilisez que les clés de chiffrement que vous souhaitez. Pour les clés AWS KMS encapsulées, cela améliore également les performances en vous empêchant d'utiliser par inadvertance des clés situées dans une autre région Compte AWS ou d'essayer de déchiffrer avec des clés que vous n'êtes pas autorisé à utiliser.

Lors du chiffrement, vous devez spécifier des clés d'emballage pour les trousseaux de clés et les fournisseurs de clés principales que les fournisseurs AWS Encryption SDK fournissent. Ils utilisent toutes et uniquement les clés d'emballage que vous spécifiez. Vous devez également spécifier des clés d'encapsulation lors du chiffrement et du déchiffrement avec des porte-clés AES bruts, des porte-clés RSA bruts et. JCEMasterKeys

Toutefois, lors du déchiffrement à l'aide de AWS KMS porte-clés et de fournisseurs de clés principales, vous n'êtes pas obligé de spécifier des clés d'emballage. AWS Encryption SDK Vous pouvez obtenir l'identifiant de clé à partir des métadonnées de la clé de données cryptée. Toutefois, la spécification des clés d'emballage est une bonne pratique que nous recommandons.

Pour appliquer cette bonne pratique lorsque vous utilisez des clés d' AWS KMS encapsulage, nous vous recommandons ce qui suit :

Lorsque la spécification de clés AWS KMS d'encapsulation pour le déchiffrement n'est pas pratique, vous pouvez utiliser des fournisseurs de découverte. Les porte-clés AWS Encryption SDK en C et JavaScript Support AWS KMS Discovery. Des fournisseurs de clés principales dotés d'un mode découverte sont disponibles pour Java et Python dans les versions 1.7. x et versions ultérieures. Ces fournisseurs de découverte, qui ne sont utilisés que pour le déchiffrement à l'aide de clés d' AWS KMS encapsulation, leur indiquent explicitement d'utiliser toute clé d'encapsulation chiffrant une clé de données. AWS Encryption SDK

Si vous devez utiliser un fournisseur de découverte, utilisez ses fonctionnalités de filtre de découverte pour limiter les clés d'encapsulation qu'il utilise. Par exemple, le trousseau de clés de découverte AWS KMS régionale utilise uniquement les clés d'encapsulation d'un objet en particulier Région AWS. Vous pouvez également configurer des AWS KMS porte-clés et des fournisseurs de clés AWS KMS principales pour n'utiliser que les clés d'emballage en particulier Comptes AWS. Comme toujours, utilisez également des politiques clés et des politiques IAM pour contrôler l'accès à vos clés AWS KMS d'emballage.

Il est recommandé d'utiliser une suite d'algorithmes avec signature. Les signatures numériques permettent de vérifier que l'expéditeur du message était autorisé à envoyer le message et de protéger l'intégrité du message. Toutes les versions AWS Encryption SDK utilisent des suites d'algorithmes avec signature par défaut.

Si vos exigences de sécurité n'incluent pas les signatures numériques, vous pouvez sélectionner une suite d'algorithmes sans signatures numériques. Nous vous recommandons toutefois d'utiliser des signatures numériques, en particulier lorsqu'un groupe d'utilisateurs chiffre des données et qu'un autre groupe d'utilisateurs les déchiffre.

Il est recommandé d'utiliser la fonctionnalité de sécurité des engagements clés. En vérifiant l'identité de la clé de données unique qui a chiffré vos données, l'engagement de clé vous empêche de déchiffrer tout texte chiffré susceptible de générer plus d'un message en texte brut.

AWS Encryption SDK Il fournit un support complet pour le chiffrement et le déchiffrement avec un engagement clé à compter de la version 2.0. x. Par défaut, tous vos messages sont chiffrés et déchiffrés avec un engagement clé. La version 1.7. x d'entre eux AWS Encryption SDK peuvent déchiffrer les textes chiffrés avec un engagement clé. Il est conçu pour aider les utilisateurs des versions précédentes à déployer la version 2.0. x avec succès.

La prise en charge de l'engagement clé inclut de nouvelles suites d'algorithmes et un nouveau format de message qui produit un texte chiffré de seulement 30 octets de plus qu'un texte chiffré sans engagement clé. La conception minimise son impact sur les performances afin que la plupart des utilisateurs puissent profiter des avantages d'un engagement clé. Si votre application est très sensible à la taille et aux performances, vous pouvez décider d'utiliser le paramètre de politique d'engagement pour désactiver l'engagement par clé ou AWS Encryption SDK autoriser le déchiffrement des messages sans engagement, mais ne le faites que si nécessaire.

Il est recommandé de limiter le nombre de clés de données chiffrées dans les messages que vous déchiffrez, en particulier les messages provenant de sources non fiables. Le déchiffrement d'un message contenant de nombreuses clés de données chiffrées que vous ne pouvez pas déchiffrer peut entraîner des retards prolongés, augmenter les dépenses, ralentir votre application et les autres applications qui partagent votre compte, et potentiellement épuiser votre infrastructure de clés. Sans limites, un message chiffré peut contenir jusqu'à 65 535 (2^16 - 1) clés de données cryptées. Pour en savoir plus, consultez Limiter les clés de données chiffrées.