Modification de votre modèle de données

Note

Notre bibliothèque de chiffrement côté client a été renommée AWS Database Encryption SDK. La rubrique suivante fournit des informations sur les versions 1. x —2. x du client de chiffrement DynamoDB pour Java et versions 1. x —3. x du client de chiffrement DynamoDB pour Python. Pour plus d'informations, voir AWSDatabase Encryption SDK pour connaître la prise en charge des versions de DynamoDB.

Chaque fois que vous chiffrez ou déchiffrez un élément, vous devez fournir des actions attributaires qui indiquent au client de chiffrement DynamoDB quels attributs doivent être chiffrés et signés, quels attributs doivent être signés (mais pas chiffrés) et lesquels ignorer. Les actions attributaires ne sont pas enregistrées dans l'élément chiffré et le client de chiffrement DynamoDB ne met pas automatiquement à jour vos actions attributaires.

Important

Le client de chiffrement DynamoDB ne prend pas en charge le chiffrement des données de table DynamoDB non chiffrées existantes.

Chaque fois que vous modifiez votre modèle de données, c'est-à-dire lorsque vous ajoutez ou supprimez des attributs de vos éléments de table, vous risquez une erreur. Si les actions d'attribut que vous spécifiez ne rendent pas compte de tous les attributs de l'élément, l'élément peut ne pas être chiffré et signé comme vous l'escomptiez. Surtout, si les actions d'attribut que vous fournissez lors du déchiffrement d'un élément diffèrent des actions d'attribut que vous avez fournies lors du chiffrement de l'élément, la vérification de la signature peut échouer.

Par exemple, si les actions d'attribut utilisées pour chiffrer l'élément lui disent de signer l'attribut test, la signature de l'élément comportera l'attribut test. Cependant, si les actions d'attribut utilisées pour déchiffrer l'élément ne tiennent pas compte de l'attribut test, la vérification échouera parce que le client essaiera de vérifier une signature qui n'inclut pas l'attribut test.

Cela pose un problème particulier lorsque plusieurs applications lisent et écrivent les mêmes éléments DynamoDB, car le client de chiffrement DynamoDB doit calculer la même signature pour les éléments de toutes les applications. C'est également un problème pour toute application distribuée car les modifications dans les actions d'attribut doivent se propager à tous les hôtes. Même si un hôte accède à vos tables DynamoDB dans le cadre d'un seul processus, l'établissement d'un processus fondé sur les meilleures pratiques permettra d'éviter les erreurs si le projet devient plus complexe.

Pour éviter les erreurs de validation de signature qui vous empêchent de lire les éléments de votre tableau, suivez les instructions suivantes.

• Ajouter un attribut : si le nouvel attribut modifie vos actions attributaires, déployez entièrement la modification de l'action d'attribut avant d'inclure le nouvel attribut dans un élément.

• Supprimer un attribut : si vous arrêtez d'utiliser un attribut dans vos articles, ne modifiez pas les actions associées à cet attribut.

• Modification de l'action : après avoir utilisé une configuration d'actions attributaires pour chiffrer les éléments de votre tableau, vous ne pouvez pas modifier en toute sécurité l'action par défaut ou l'action pour un attribut existant sans crypter à nouveau chaque élément de votre tableau.

Les erreurs de validation de signature peuvent être extrêmement difficiles à résoudre, de sorte que la meilleure approche consiste à les prévenir.

Ajout d'un attribut

Lorsque vous ajouterez un nouvel attribut à des éléments de table, vous devrez peut-être modifier vos actions attributaires. Pour éviter les erreurs de validation de signature, nous vous recommandons d'implémenter cette modification en deux étapes. Vérifiez que la première étape est terminée avant de commencer la deuxième étape.

1. Modifiez les actions d'attribut dans toutes les applications qui lisent ou écrivent dans la table. Déployez ces modifications et confirmez que la mise à jour a été propagée à tous les hôtes de destination.

2. Écrire des valeurs dans le nouvel attribut dans vos éléments de table.

Cette approche en deux étapes garantit que toutes les applications et les hôtes ont les mêmes actions d'attribut et calculera la même signature, avant toute rencontre avec le nouvel attribut. Ceci est important même lorsque l'action de l'attribut est Ne rien faire (ne pas chiffrer ou signer), car la valeur par défaut de certains chiffreurs est de chiffrer et de signer.

Les exemples suivants montrent le code de la première étape de ce processus. Ils ajoutent un nouvel attribut d'élément link, qui stocke un lien vers un autre élément de table. Étant donné que ce lien doit rester en texte brut, l'exemple lui attribue l'action sign-only. Après avoir entièrement déployé cette modification, puis vérifié que toutes les applications et tous les hôtes possèdent les nouvelles actions attributaires, vous pouvez commencer à utiliser l'attribut link dans vos éléments de table.

Java DynamoDB Mapper

Lors de l'utilisation de DynamoDB Mapper et AttributeEncryptor, par défaut, tous les attributs sont chiffrés et signés à l'exception des clés primaires, qui sont signées mais pas chiffrées. Pour spécifier une action de signature uniquement, utilisez l'annotation @DoNotEncrypt.

Cet exemple utilise l'annotation @DoNotEncrypt du nouvel attribut link.

@DynamoDBTable(tableName = "ExampleTable")
public static final class DataPoJo {
  private String partitionAttribute;
  private int sortAttribute;
  private String link;

  @DynamoDBHashKey(attributeName = "partition_attribute")
  public String getPartitionAttribute() {
    return partitionAttribute;
  }
    
  public void setPartitionAttribute(String partitionAttribute) {
    this.partitionAttribute = partitionAttribute;
  }

  @DynamoDBRangeKey(attributeName = "sort_attribute")
  public int getSortAttribute() {
    return sortAttribute;
  }

  public void setSortAttribute(int sortAttribute) {
    this.sortAttribute = sortAttribute;
  }

  @DynamoDBAttribute(attributeName = "link")
  @DoNotEncrypt
  public String getLink() {
    return link;
  }

  public void setLink(String link) {
    this.link = link;
  }

  @Override
  public String toString() {
    return "DataPoJo [partitionAttribute=" + partitionAttribute + ",
        sortAttribute=" + sortAttribute + ",
        link=" + link + "]";
  }
}            

Java DynamoDB encryptor

Dans le chiffreur DynamoDB de niveau inférieur, vous devez définir des actions pour chaque attribut. Cet exemple utilise une instruction switch où la valeur par défaut est encryptAndSign et des exceptions sont spécifiées pour la clé de partition, la clé de tri et le nouvel attribut link. Dans cet exemple, si le code d'attribut de lien n'était pas entièrement déployé avant son utilisation, l'attribut de lien serait chiffré et signé par certaines applications, mais seulement signé par d'autres.

for (final String attributeName : record.keySet()) {
    switch (attributeName) {
        case partitionKeyName:
            // fall through to the next case
        case sortKeyName:
            // partition and sort keys must be signed, but not encrypted
            actions.put(attributeName, signOnly);
            break;
        case "link":
            // only signed
            actions.put(attributeName, signOnly);
            break;
        default:
            // Encrypt and sign all other attributes
            actions.put(attributeName, encryptAndSign);
            break;
    }
}               

Python

Dans le client de chiffrement DynamoDB pour Python, vous pouvez spécifier une action par défaut pour tous les attributs, puis spécifier des exceptions.

Si vous utilisez une classe d'annotations clientes, vous n'avez pas besoin de spécifier une action d'attribut pour les attributs de clé primaire. Les classes d'annotations clients vous empêchent de chiffrer votre clé primaire. Toutefois, si vous n'utilisez pas de classes d'annotations clientes, vous devez définir l'action SIGN_ONLY sur votre clé de partition et la clé de tri. Si vous chiffrez accidentellement votre partition ou votre clé de tri, vous ne pourrez pas récupérer vos données sans une analyse complète de la table.

Cet exemple spécifie une exception pour le nouvel attribut link, qui obtient l'action SIGN_ONLY.

actions = AttributeActions(
    default_action=CryptoAction.ENCRYPT_AND_SIGN,
    attribute_actions={
      'example': CryptoAction.DO_NOTHING,  
      'link': CryptoAction.SIGN_ONLY
    }
)

Suppression d'un attribut

Si vous n'avez plus besoin d'un attribut dans les éléments qui ont été chiffrés avec le client de chiffrement DynamoDB, vous pouvez arrêter d'utiliser cet attribut. Toutefois, ne supprimez pas ou ne modifiez pas l'action de cet attribut. Si vous le faites, puis que vous rencontrez un élément avec cet attribut, la signature calculée pour l'élément ne correspondra pas à la signature d'origine et la validation de la signature échouera.

Bien que vous soyez tenté de supprimer toutes les traces de l'attribut de votre code, ajoutez un commentaire indiquant que l'élément n'est plus utilisé au lieu de le supprimer. Même si vous effectuez une analyse complète de table pour supprimer toutes les instances de l'attribut, un élément chiffré avec cet attribut peut être mis en cache ou en cours de traitement quelque part dans votre configuration.