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.

Modification de votre modèle de données

Chaque fois que vous chiffrez ou déchiffrez un élément, vous devez fournir des actions attributaires qui indiquent au client de chiffrement DynamoDB les attributs à chiffrer et à signer, les attributs à signer (mais pas à chiffrer) et ceux à ignorer. Les actions d'attribut ne sont pas enregistrées dans l'élément chiffré et le client de chiffrement DynamoDB ne met pas automatiquement à jour vos actions d'attribut.

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, la mise en place d'un processus basé 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.

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.

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 définir 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 classe d'assistance client, vous devez définir l'ONLYaction SIGN _ sur votre clé de partition et votre 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 chiffrés avec le client de chiffrement DynamoDB, vous pouvez arrêter de l'utiliser. 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.