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.

Migration du client de chiffrement Amazon S3 (V2 vers V3)

Cette rubrique explique comment migrer vos applications de la version 2 (V2) du client de chiffrement Amazon Simple Storage Service (Amazon S3) vers la version 3 (V3) et garantir la disponibilité des applications tout au long du processus de migration. La version 3 introduit l'AES GCM avec des politiques d'engagement et d'engagement clés visant à renforcer la sécurité et à protéger contre la falsification des clés de données.

Aperçu de la migration

La version 3 du client de chiffrement Amazon S3 introduit la technologie AES GCM avec Key Commitment pour une sécurité renforcée. Ce nouvel algorithme de chiffrement fournit une protection contre la falsification des clés de données et garantit l'intégrité des données cryptées. La migration vers la version V3 nécessite une planification minutieuse afin de maintenir la disponibilité des applications et l'accessibilité des données tout au long du processus.

Cette migration s'effectue en deux phases :

1. Mettez à jour les clients existants pour qu'ils puissent lire les nouveaux formats. Commencez par déployer une version mise à jour du AWS SDK pour Ruby dans votre application. Cela permettra aux clients de chiffrement V2 existants de déchiffrer les objets écrits par les nouveaux clients V3. Si votre application utilise plusieurs AWS kits de développement logiciel, vous devez les mettre à niveau séparément.

2. Migrez les clients de chiffrement et de déchiffrement vers la version V3. Une fois que tous vos clients de chiffrement V2 peuvent lire les nouveaux formats, vous pouvez migrer vos clients de chiffrement et de déchiffrement existants vers leurs versions V3 respectives. Cela inclut la configuration des politiques d'engagement et la mise à jour de votre code pour utiliser les nouvelles options de configuration du client.

Si vous n'avez pas encore migré de la V1 vers la V2, vous devez d'abord effectuer cette migration. Consultez Migration du client de chiffrement Amazon S3 (V1 vers V2) les instructions détaillées sur la migration de la V1 vers la V2.

Comprendre les fonctionnalités de la V3

La version 3 du client de chiffrement Amazon S3 introduit deux fonctionnalités de sécurité clés : les politiques d'engagement et l'AES GCM avec engagement clé. Il est essentiel de comprendre ces fonctionnalités pour planifier votre stratégie de migration et garantir la sécurité de vos données cryptées.

Politiques d'engagement

Les politiques d'engagement contrôlent la manière dont le client de chiffrement gère l'engagement des clés pendant les opérations de chiffrement et de déchiffrement. L'engagement clé garantit que les données cryptées ne peuvent être déchiffrées qu'avec la clé exacte qui a été utilisée pour les chiffrer, protégeant ainsi contre certains types d'attaques cryptographiques.

Le client de chiffrement V3 prend en charge trois options de politique d'engagement :

FORBID_ENCRYPT_ALLOW_DECRYPT

Cette politique chiffre les objets sans engagement de clé et permet le déchiffrement des objets avec et sans engagement de clé.

REQUIRE_ENCRYPT_ALLOW_DECRYPT

Cette politique chiffre les objets avec engagement de clé et permet le déchiffrement des objets avec et sans engagement de clé.

REQUIRE_ENCRYPT_REQUIRE_DECRYPT

Cette politique chiffre les objets avec un engagement de clé et n'autorise le déchiffrement que des objets qui ont été chiffrés avec un engagement de clé.

AES GCM avec un engagement clé

L'AES GCM avec Key Commitment (ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY) est un nouvel algorithme de cryptage introduit dans la version V3 qui fournit une sécurité renforcée en protégeant contre la falsification des clés de données. Il est important de comprendre comment fonctionne cet algorithme et quand il s'applique pour planifier votre migration.

En quoi ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY diffère-t-il des algorithmes précédents ?

Les versions précédentes du client de chiffrement S3 utilisaient l'AES CBC ou l'AES GCM sans engagement de clé pour chiffrer la clé de données dans les fichiers d'instructions. ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEYajoute un engagement cryptographique au processus de chiffrement, qui lie les données chiffrées à une clé spécifique. Cela empêche un attaquant de modifier la clé de données chiffrée dans le fichier d'instructions et d'amener le client à déchiffrer les données avec une clé incorrecte.

Sans engagement de clé, il est possible pour un attaquant de modifier la clé de données chiffrée d'un fichier d'instructions afin qu'elle soit déchiffrée sur une clé différente, ce qui pourrait permettre un accès non autorisé ou une corruption des données. ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEYempêche cette attaque en s'assurant que la clé de données chiffrée ne peut être déchiffrée que sur la clé d'origine utilisée lors du chiffrement.

Compatibilité des versions

Les objets chiffrés avec ne ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY peuvent être déchiffrés que par les implémentations V3 du client de chiffrement S3 et certaines versions de transition de V2 qui incluent la prise en charge de la lecture des formats V3. Les clients V2 qui ne disposent pas de cette prise en charge de la transition ne peuvent pas déchiffrer les fichiers d'instructions chiffrés avecALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY.

Pendant la migration, vous pouvez utiliser la politique d'FORBID_ENCRYPT_ALLOW_DECRYPTengagement pour poursuivre le chiffrement sans ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY autoriser vos clients V3 à lire les objets chiffrés avec un engagement de clé. Cela fournit un chemin de migration sécurisé dans lequel vous devez d'abord mettre à niveau tous les lecteurs, puis passer au chiffrement avec engagement de clé.

Mettre à jour les clients existants pour lire les nouveaux formats

Le client de chiffrement V3 utilise des algorithmes de chiffrement et des fonctionnalités d'engagement clés que les clients V2 ne prennent pas en charge par défaut. La première étape de la migration consiste à mettre à jour vos clients de déchiffrement V2 vers une version du AWS SDK pour Ruby capable de lire les objets chiffrés de la V3. Une fois cette étape terminée, les clients V2 de votre application seront en mesure de déchiffrer les objets chiffrés par les clients de chiffrement V3.

Pour lire les objets chiffrés par les clients V3 (ceux qui utilisent des politiques d'REQUIRE_ENCRYPT_REQUIRE_DECRYPTengagement REQUIRE_ENCRYPT_ALLOW_DECRYPT ou d'engagement), vous devez utiliser la version 1.93.0 ou ultérieure de la aws-sdk-s3 gemme. Cette version inclut la prise en charge du déchiffrement des objets chiffrés avec AES GCM avec Key Commitment.

Installation depuis la ligne de commande

Pour les projets qui installent la aws-sdk-s3 gemme à partir de la ligne de commande, utilisez l'option de version pour vérifier que la version minimale de 1.208.0 est installée.

gem install aws-sdk-s3 -v '>= 1.208.0'

Utilisation de Gemfiles

Pour les projets qui utilisent un Gemfile pour gérer les dépendances, définissez la version minimale du aws-sdk-s3 gem sur 1.208.0. Par exemple :

gem 'aws-sdk-s3', '>= 1.208.0'

Migrer les clients de chiffrement et de déchiffrement vers la version V3

Après avoir mis à jour vos clients pour qu'ils puissent lire les nouveaux formats de chiffrement, vous pouvez mettre à jour vos applications vers les clients de chiffrement et de déchiffrement V3. Les étapes suivantes vous montrent comment réussir la migration de votre code de la V2 vers la V3.

Avant de mettre à jour votre code pour utiliser le client de chiffrement V3, assurez-vous d'avoir suivi les étapes précédentes et que vous utilisez la version 1.93.0 ou ultérieure de aws-sdk-s3 gem.

Configuration des clients V3

Le client de chiffrement V3 introduit de nouvelles options de configuration qui contrôlent le comportement d'engagement des clés et la rétrocompatibilité. Il est essentiel de comprendre ces options pour réussir la migration.

politique_d'engagement

Le commitment_policy paramètre contrôle la manière dont le client de chiffrement gère l'engagement des clés pendant les opérations de chiffrement et de déchiffrement. Il s'agit de l'option de configuration la plus importante pour les clients V3.

profil_de sécurité

Le security_profile paramètre détermine la prise en charge de la lecture d'objets écrits par les anciennes versions du client de chiffrement. Ce paramètre est essentiel pour maintenir la rétrocompatibilité pendant la migration.

emplacement_de_enveloppe

Le envelope_location paramètre détermine où les métadonnées de chiffrement (y compris la clé de données cryptée) sont stockées. Ce paramètre affecte les objets qui sont protégés par AES GCM avec Key Commitment.

Lors de l'utilisation:instruction_file, vous pouvez éventuellement spécifier le instruction_file_suffix paramètre pour personnaliser le suffixe utilisé pour les objets du fichier d'instructions. Le suffixe par défaut est.instruction.

Quand utiliser chaque option de configuration

Pendant la migration, suivez cette stratégie de configuration recommandée :

Pourenvelope_location, continuez à utiliser votre méthode de stockage existante (:metadataou:instruction_file) sauf si vous avez une raison précise de la modifier. Si vous utilisez actuellement le stockage de métadonnées et souhaitez bénéficier de la sécurité supplémentaire d'AES GCM avec Key Commitment pour la clé de données, vous pouvez passer à:instruction_file, mais notez que cela nécessitera la mise à jour de tous les clients qui lisent ces objets.

Migrer les clients de chiffrement et de déchiffrement vers la version V3

Après avoir mis à jour vos clients pour qu'ils puissent lire les nouveaux formats de chiffrement, vous pouvez mettre à jour vos applications vers les clients de chiffrement et de déchiffrement V3. Les exemples suivants vous montrent comment réussir la migration de votre code de la V2 vers la V3.

Utilisation de clients de chiffrement V3

Pre-migration (V2)

require 'aws-sdk-s3'

# Create V2 encryption client with KMS
client = Aws::S3::EncryptionV2::Client.new(
  kms_key_id: kms_key_id,
  key_wrap_schema: :kms_context,
  content_encryption_schema: :aes_gcm_no_padding,
  security_profile: :v2_and_legacy,
  commitment_policy: :forbid_encrypt_allow_decrypt
)

# Encrypt and upload object
client.put_object(bucket: 'my-bucket', key: 'my-object', body: 'secret data')

# Download and decrypt object
resp = client.get_object(bucket: 'my-bucket', key: 'my-object')
decrypted_data = resp.body.read

Pendant la migration (V3 avec rétrocompatibilité)

require 'aws-sdk-s3'

# Create V3 encryption client with KMS
client = Aws::S3::EncryptionV3::Client.new(
  kms_key_id: kms_key_id,
  key_wrap_schema: :kms_context,
  content_encryption_schema: :aes_gcm_no_padding,
  security_profile: :v3_and_legacy,
  commitment_policy: :require_encrypt_allow_decrypt
)

# Encrypt and upload object
client.put_object(bucket: 'my-bucket', key: 'my-object', body: 'secret data')

# Download and decrypt object
resp = client.get_object(bucket: 'my-bucket', key: 'my-object')
decrypted_data = resp.body.read

Post-migration (V3)

require 'aws-sdk-s3'

# Create V3 encryption client with KMS
client = Aws::S3::EncryptionV3::Client.new(
  kms_key_id: kms_key_id,
  key_wrap_schema: :kms_context,
  content_encryption_schema: :aes_gcm_no_padding,
  security_profile: :v3,
  # Use the commitment policy (REQUIRE_ENCRYPT_REQUIRE_DECRYPT)
  # This encrypts with key commitment and does not decrypt V2 objects
  commitment_policy: :require_encrypt_require_decrypt
)

# Encrypt and upload object
client.put_object(bucket: 'my-bucket', key: 'my-object', body: 'secret data')

# Download and decrypt object
resp = client.get_object(bucket: 'my-bucket', key: 'my-object')
decrypted_data = resp.body.read

La principale différence dans la V3 est l'ajout du commitment_policy paramètre. Le paramétrer pour :require_encrypt_require_decrypt garantir que les nouveaux objets sont chiffrés avec un engagement de clé et que le client ne déchiffre que les objets chiffrés avec un engagement de clé, offrant ainsi une sécurité renforcée contre la falsification des clés de données.

L'put_objectappel lui-même reste inchangé. Toutes les améliorations de sécurité sont configurées au niveau du client.

Exemples supplémentaires

Cette section fournit des exemples supplémentaires de scénarios de migration et d'options de configuration spécifiques qui peuvent être utiles lors de votre migration de la V2 vers la V3.

Fichier d'instructions ou stockage de métadonnées

Le client de chiffrement S3 peut stocker les métadonnées de chiffrement (y compris la clé de données chiffrée) à deux emplacements différents : dans les en-têtes de métadonnées de l'objet S3 ou dans un fichier d'instructions distinct. Le choix de la méthode de stockage détermine les objets qui bénéficient de la protection AES GCM avec Key Commitment.

Stockage des métadonnées (par défaut)

Par défaut, le client de chiffrement stocke les métadonnées de chiffrement dans les en-têtes de métadonnées de l'objet S3. Il s'agit de l'approche recommandée dans la plupart des cas d'utilisation, car elle conserve les métadonnées de chiffrement associées à l'objet et ne nécessite pas la gestion d'objets de fichier d'instructions distincts.

require 'aws-sdk-s3'

# Create V3 encryption client with metadata storage (default)
client = Aws::S3::EncryptionV3::Client.new(
  kms_key_id: kms_key_id,
  key_wrap_schema: :kms_context,
  content_encryption_schema: :aes_gcm_no_padding,
  security_profile: :v3_and_legacy,
  commitment_policy: :require_encrypt_allow_decrypt,
  envelope_location: :metadata # Explicitly set to metadata (this is the default)
)

# Encrypt and upload object
# Encryption metadata is stored in the object's metadata headers
client.put_object(bucket: 'my-bucket', key: 'my-object',body: 'secret data')

Lorsque vous utilisez le stockage de métadonnées, l'AES GCM avec Key Commitment ne s'applique pas à la clé de données chiffrée. Cependant, le chiffrement du contenu bénéficie toujours d'un engagement clé lors de l'utilisation de commitment_policy: :require_encrypt_allow_decrypt ou:require_encrypt_require_decrypt.

Stockage des fichiers d'instructions

Vous pouvez également configurer le client de chiffrement pour stocker les métadonnées de chiffrement dans un objet S3 distinct appelé fichier d'instructions. Lorsque vous utilisez des fichiers d'instructions avec la version V3, la clé de données cryptée est protégée par AES GCM avec Key Commitment, offrant une sécurité supplémentaire contre la falsification des clés de données.

require 'aws-sdk-s3'

# Create V3 encryption client with instruction file storage
client = Aws::S3::EncryptionV3::Client.new(
  kms_key_id: kms_key_id,
  key_wrap_schema: :kms_context,
  content_encryption_schema: :aes_gcm_no_padding,
  security_profile: :v3_and_legacy,
  commitment_policy: :require_encrypt_allow_decrypt,
  envelope_location: :instruction_file, # Store metadata in separate instruction file
  instruction_file_suffix: '.instruction' # Optional: customize the suffix (default is '.instruction')
)

# Encrypt and upload object
# Encryption metadata is stored in a separate object: 'my-object.instruction'
client.put_object(bucket: 'my-bucket', key: 'my-object', body: 'secret data')

# When retrieving the object, the client automatically reads the instruction file
resp = client.get_object(bucket: 'my-bucket', key: 'my-object')
decrypted_data = resp.body.read

Lors de l'utilisationenvelope_location: :instruction_file, le client de chiffrement crée deux objets S3 :

Le instruction_file_suffix paramètre vous permet de personnaliser le suffixe utilisé pour les fichiers d'instructions. La valeur par défaut est .instruction.

Quand utiliser chaque méthode de stockage