

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.

# Mettre à jour votre modèle de données
<a name="ddb-update-data-model"></a>


****  

|  | 
| --- |
| Notre bibliothèque de chiffrement côté client a été renommée SDK de chiffrement de AWS base de données. Ce guide du développeur fournit toujours des informations sur le client de [chiffrement DynamoDB](legacy-dynamodb-encryption-client.md). | 

[Lorsque vous configurez le SDK AWS de chiffrement de base de données pour DynamoDB, vous fournissez des actions attributaires.](concepts.md#crypt-actions) Lors du chiffrement, le SDK AWS de chiffrement de base de données utilise les actions d'attributs pour identifier les attributs à chiffrer et à signer, les attributs à signer (mais pas à chiffrer) et ceux à ignorer. Vous définissez également les [attributs non signés autorisés](ddb-java-using.md#allowed-unauth) pour indiquer explicitement au client quels attributs sont exclus des signatures. Lors du déchiffrement, le SDK AWS de chiffrement de base de données utilise les attributs non signés autorisés que vous avez définis pour identifier les attributs qui ne sont pas inclus dans les signatures. Les actions d'attribut ne sont pas enregistrées dans l'élément chiffré et le SDK AWS de chiffrement de base de données ne met pas automatiquement à jour vos actions d'attribut.

Choisissez soigneusement vos actions d'attribut. En cas de doute, utilisez **Chiffrer et signer**. Une fois que vous avez utilisé le SDK AWS de chiffrement de base de données pour protéger vos éléments, vous ne pouvez pas modifier un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut ou un attribut existant `ENCRYPT_AND_SIGN` en`DO_NOTHING`. `SIGN_ONLY` Cependant, vous pouvez effectuer les modifications suivantes en toute sécurité.
+ [Ajouter `ENCRYPT_AND_SIGN` de `SIGN_ONLY` nouveaux `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attributs et](#ddb-add-auth-attribute)
+ [Supprimer les attributs existants](#ddb-remove-attribute)
+ [Remplacer un `ENCRYPT_AND_SIGN` attribut existant par `SIGN_ONLY` ou `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`](#ddb-encrypt-to-sign)
+ [Modifier un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut `SIGN_ONLY` ou un existant en `ENCRYPT_AND_SIGN`](#ddb-sign-to-encrypt)
+ [Ajouter un nouvel `DO_NOTHING` attribut](#ddb-add-unauth-attribute)
+ [Modifier un `SIGN_ONLY` attribut existant en `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`](#ddb-signOnly-to-signInclude)
+ [Modifier un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut existant en `SIGN_ONLY`](#ddb-signInclude-to-signOnly)

**Considérations relatives au chiffrement consultable**  
Avant de mettre à jour votre modèle de données, réfléchissez bien à l'impact que vos mises à jour peuvent avoir sur les [balises](beacons.md) que vous avez créées à partir des attributs. Une fois que vous avez écrit de nouveaux enregistrements avec une balise, vous ne pouvez pas mettre à jour la configuration de la balise. Vous ne pouvez pas mettre à jour les actions d'attribut associées aux attributs que vous avez utilisés pour créer des balises. Si vous supprimez un attribut existant et sa balise associée, vous ne pourrez pas interroger les enregistrements existants à l'aide de cette balise. Vous pouvez créer de nouvelles balises pour les nouveaux champs que vous ajoutez à votre enregistrement, mais vous ne pouvez pas mettre à jour les balises existantes pour inclure le nouveau champ.

**Considérations relatives aux `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attributs**  
Par défaut, les clés de partition et de tri sont les seuls attributs inclus dans le contexte de chiffrement. Vous pouvez envisager de définir des champs supplémentaires `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` afin que le fournisseur d'ID de clé de branche pour votre jeu de [clés AWS KMS hiérarchique](use-hierarchical-keyring.md) puisse identifier la clé de branche requise pour le déchiffrement à partir du contexte de chiffrement. Pour plus d'informations, consultez le [fournisseur d'ID de clé de branche](use-hierarchical-keyring.md#branch-key-id-supplier). Si vous spécifiez des `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attributs, les attributs de partition et de tri doivent également l'être`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`.

**Note**  
Pour utiliser l'action `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` cryptographique, vous devez utiliser la version 3.3 ou ultérieure du SDK AWS Database Encryption. Déployez la nouvelle version sur tous les lecteurs avant de [mettre à jour votre modèle de données](#ddb-update-data-model) pour l'inclure`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`.

## Ajouter `ENCRYPT_AND_SIGN` de `SIGN_ONLY` nouveaux `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attributs et
<a name="ddb-add-auth-attribute"></a>

Pour ajouter un nouvel attribut `ENCRYPT_AND_SIGN``SIGN_ONLY`, ou un nouvel `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut, définissez-le dans vos actions d'attribut.

Vous ne pouvez pas supprimer un `DO_NOTHING` attribut existant et le réajouter en tant qu'`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`attribut `ENCRYPT_AND_SIGN``SIGN_ONLY`, ou.

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, ajoutez le nouvel attribut à votre classe de données annotée. Si vous ne spécifiez aucune annotation d'action d'attribut pour le nouvel attribut, le client chiffrera et signera le nouvel attribut par défaut (sauf si l'attribut fait partie de la clé primaire). Si vous souhaitez uniquement signer le nouvel attribut, vous devez l'ajouter avec l'`@DynamoDBEncryptionSignAndIncludeInEncryptionContext`annotation `@DynamoDBEncryptionSignOnly` or.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, ajoutez le nouvel attribut aux actions d'attribut de votre modèle d'objet et spécifiez `ENCRYPT_AND_SIGN``SIGN_ONLY`, ou `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` en tant qu'action d'attribut.

## Supprimer les attributs existants
<a name="ddb-remove-attribute"></a>

Si vous décidez que vous n'avez plus besoin d'un attribut, vous pouvez arrêter d'écrire des données dans cet attribut ou vous pouvez le supprimer officiellement de vos actions d'attribut. Lorsque vous arrêtez d'écrire de nouvelles données dans un attribut, celui-ci apparaît toujours dans vos actions d'attribut. Cela peut être utile si vous devez recommencer à utiliser l'attribut à l'avenir. La suppression officielle de l'attribut de vos actions d'attribut ne le supprime pas de votre ensemble de données. Votre jeu de données contiendra toujours des éléments qui incluent cet attribut.

Pour supprimer officiellement un attribut existant`ENCRYPT_AND_SIGN`, `SIGN_ONLY``SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`, ou un `DO_NOTHING` attribut, mettez à jour vos actions d'attribut.

Si vous supprimez un `DO_NOTHING` attribut, vous ne devez pas le supprimer de vos [attributs non signés autorisés](ddb-java-using.md#allowed-unauth). Même si vous n'écrivez plus de nouvelles valeurs dans cet attribut, le client doit tout de même savoir que l'attribut n'est pas signé pour pouvoir lire les éléments existants qui le contiennent.

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, supprimez l'attribut de votre classe de données annotée.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, supprimez l'attribut des actions d'attribut de votre modèle d'objet.

## Remplacer un `ENCRYPT_AND_SIGN` attribut existant par `SIGN_ONLY` ou `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`
<a name="ddb-encrypt-to-sign"></a>

Pour remplacer un `ENCRYPT_AND_SIGN` attribut existant par `SIGN_ONLY` ou`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`, vous devez mettre à jour vos actions d'attribut. Une fois la mise à jour déployée, le client sera en mesure de vérifier et de déchiffrer les valeurs existantes écrites dans l'attribut, mais il ne signera que les nouvelles valeurs écrites dans l'attribut.

**Note**  
Réfléchissez bien à vos exigences de sécurité avant de remplacer un `ENCRYPT_AND_SIGN` attribut existant par `SIGN_ONLY` ou`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`. Tout attribut susceptible de stocker des données sensibles doit être chiffré.

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, mettez à jour l'attribut existant pour inclure l'`@DynamoDBEncryptionSignAndIncludeInEncryptionContext`annotation `@DynamoDBEncryptionSignOnly` ou dans votre classe de données annotée.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, mettez à jour l'action d'attribut associée à l'attribut existant depuis `SIGN_ONLY` ou `ENCRYPT_AND_SIGN` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` vers votre modèle d'objet.

## Modifier un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut `SIGN_ONLY` ou un existant en `ENCRYPT_AND_SIGN`
<a name="ddb-sign-to-encrypt"></a>

Pour remplacer un attribut existant `SIGN_ONLY` ou par un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut`ENCRYPT_AND_SIGN`, vous devez mettre à jour vos actions d'attribut. Une fois la mise à jour déployée, le client sera en mesure de vérifier les valeurs existantes écrites dans l'attribut, puis de chiffrer et de signer les nouvelles valeurs écrites dans l'attribut.

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, supprimez l'`@DynamoDBEncryptionSignAndIncludeInEncryptionContext`annotation `@DynamoDBEncryptionSignOnly` ou de l'attribut existant.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, mettez à jour l'action d'attribut associée à l'attribut depuis `SIGN_ONLY` ou `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` vers `ENCRYPT_AND_SIGN` dans votre modèle d'objet.

## Ajouter un nouvel `DO_NOTHING` attribut
<a name="ddb-add-unauth-attribute"></a>

Pour réduire le risque d'erreur lors de l'ajout d'un nouvel `DO_NOTHING` attribut, nous vous recommandons de spécifier un préfixe distinct lorsque vous nommez vos `DO_NOTHING` attributs, puis d'utiliser ce préfixe pour définir les attributs [non signés autorisés](ddb-java-using.md#allowed-unauth).

Vous ne pouvez pas supprimer un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut ou un attribut existant `ENCRYPT_AND_SIGN` de votre classe de données annotée, puis le réintégrer en tant qu'`DO_NOTHING`attribut. `SIGN_ONLY` Vous ne pouvez ajouter que des `DO_NOTHING` attributs entièrement nouveaux.

Les étapes à suivre pour ajouter un nouvel `DO_NOTHING` attribut varient selon que vous avez défini vos attributs non signés autorisés de manière explicite dans une liste ou à l'aide d'un préfixe.

**Utilisation d'un préfixe d'attributs non signés autorisé**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, ajoutez le nouvel `DO_NOTHING` attribut à votre classe de données annotée avec l'`@DynamoDBEncryptionDoNothing`annotation. Si vous avez défini manuellement vos actions d'attribut, mettez-les à jour pour inclure le nouvel attribut. Assurez-vous de configurer explicitement le nouvel attribut avec l'action d'`DO_NOTHING`attribut. Vous devez inclure le même préfixe distinct dans le nom du nouvel attribut.

**Utilisation d'une liste d'attributs non signés autorisés**

1. Ajoutez le nouvel `DO_NOTHING` attribut à votre liste d'attributs non signés autorisés et déployez la liste mise à jour.

1. Déployez la modification depuis **l'étape 1**.

   Vous ne pouvez pas passer à l'**étape 3** tant que la modification ne s'est pas propagée à tous les hôtes qui ont besoin de lire ces données.

1. Ajoutez le nouvel `DO_NOTHING` attribut à vos actions d'attribut.

   1. Si vous avez défini vos actions d'attribut avec un`TableSchema`, ajoutez le nouvel `DO_NOTHING` attribut à votre classe de données annotée avec l'`@DynamoDBEncryptionDoNothing`annotation.

   1. Si vous avez défini manuellement vos actions d'attribut, mettez-les à jour pour inclure le nouvel attribut. Assurez-vous de configurer explicitement le nouvel attribut avec l'action d'`DO_NOTHING`attribut.

1. Déployez la modification depuis **l'étape 3**.

## Modifier un `SIGN_ONLY` attribut existant en `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`
<a name="ddb-signOnly-to-signInclude"></a>

Pour remplacer un `SIGN_ONLY` attribut existant par`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`, vous devez mettre à jour vos actions d'attribut. Une fois la mise à jour déployée, le client sera en mesure de vérifier les valeurs existantes écrites dans l'attribut et continuera à signer les nouvelles valeurs écrites dans l'attribut. Les nouvelles valeurs écrites dans l'attribut seront incluses dans le [contexte de chiffrement](concepts.md#encryption-context).

Si vous spécifiez des `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attributs, les attributs de partition et de tri doivent également l'être`SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`.

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, mettez à jour l'action d'attribut associée à l'attribut de `@DynamoDBEncryptionSignOnly` à`@DynamoDBEncryptionSignAndIncludeInEncryptionContext`.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, mettez à jour l'action d'attribut associée à l'attribut de `SIGN_ONLY` à `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` dans votre modèle d'objet.

## Modifier un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut existant en `SIGN_ONLY`
<a name="ddb-signInclude-to-signOnly"></a>

Pour remplacer un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut existant par`SIGN_ONLY`, vous devez mettre à jour vos actions d'attribut. Une fois la mise à jour déployée, le client sera en mesure de vérifier les valeurs existantes écrites dans l'attribut et continuera à signer les nouvelles valeurs écrites dans l'attribut. Les nouvelles valeurs écrites dans l'attribut ne seront pas incluses dans le [contexte de chiffrement](concepts.md#encryption-context).

Avant de remplacer un `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` attribut existant par`SIGN_ONLY`, réfléchissez bien à l'impact que vos mises à jour peuvent avoir sur les fonctionnalités de votre [fournisseur d'ID de clé de succursale](use-hierarchical-keyring.md#branch-key-id-supplier).

**Utilisation d'une classe de données annotée**  
Si vous avez défini vos actions d'attribut avec un`TableSchema`, mettez à jour l'action d'attribut associée à l'attribut de `@DynamoDBEncryptionSignAndIncludeInEncryptionContext` à`@DynamoDBEncryptionSignOnly`.

**Utilisation d'un modèle d'objet**  
Si vous avez défini manuellement vos actions d'attribut, mettez à jour l'action d'attribut associée à l'attribut de `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` à `SIGN_ONLY` dans votre modèle d'objet.