Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modifica del modello di dati

Ogni volta che si crittografa o decrittografa un elemento, è necessario fornire azioni di attributo che indichino al DynamoDB Encryption Client quali attributi crittografare e firmare, quali attributi firmare (ma non crittografare) e quali ignorare. Le azioni degli attributi non vengono salvate nell'elemento crittografato e il DynamoDB Encryption Client non aggiorna automaticamente le azioni degli attributi.

Ogni volta che modifichi il modello di dati, ovvero quando aggiungi o rimuovi attributi dagli item della tabella, rischi di incorrere un errore. Se le operazioni di attributo specificate non valgono per tutti gli attributi nell'item, l'item potrebbe non essere crittografato e firmato secondo le tue intenzioni. E, cosa più importante, se le operazioni di attributo che fornisci quando decrittografi un item sono diverse da quelle che hai fornito quando lo hai crittografato, la verifica della firma potrebbe non andare a buon fine.

Ad esempio, se le operazioni di attributo usate per crittografare l'item gli comunicano di firmare l'attributo test, la firma nell'item comprenderà l'attributo test. Ma se le operazioni di attributo usate per decrittografare l'item non valgono per l'attributo test, la verifica non andrà a buon fine, perché il client proverà a verificare una firma che non comprende l'attributo test.

Questo è un problema particolare quando più applicazioni leggono e scrivono gli stessi elementi di DynamoDB, perché il DynamoDB Encryption Client deve calcolare la stessa firma per gli elementi in tutte le applicazioni. È anche un problema per qualsiasi applicazione distribuita perché le modifiche nelle operazioni di attributo devono propagarsi a tutti gli host. Anche se alle tabelle DynamoDB accede un solo host in un unico processo, stabilire una procedura basata sulle best practice aiuterà a prevenire gli errori nel caso in cui il progetto dovesse diventare più complesso.

Per evitare errori di convalida delle firme che impediscono la lettura degli item della tabella, utilizza le istruzioni riportate di seguito.

Gli errori di convalida delle firme possono essere estremamente difficili da risolvere, quindi l'approccio migliore è prevenirli.

Aggiunta di un attributo

Quando aggiungi un nuovo attributo agli item della tabella, potrebbe essere necessario modificare le operazioni di attributo. Per evitare errori di convalida delle firme, ti consigliamo di implementare questa modifica in un processo a due fasi. Verifica che la prima fase sia completata prima di iniziare la seconda fase.

Questo approccio in due fasi garantisce che tutte le applicazioni e gli host abbiano le stesse operazioni di attributo e calcolerà la stessa firma prima che qualsiasi elemento incontri il nuovo attributo. Ciò è importante anche quando l'operazione di attributo è Non fare nulla (non crittografare o firmare), perché l'impostazione predefinita per alcuni sistemi di crittografia è crittografare e firmare.

Negli esempi seguenti viene illustrato il codice per la prima fase di questo processo. Viene aggiunto un nuovo attributo dell’item, link, che memorizza un collegamento a un altro item della tabella. Poiché questo collegamento deve rimanere in testo normale, l'esempio assegna l'operazione di sola firma. Dopo aver distribuito completamente questa modifica e aver verificato che tutte le applicazioni e gli host abbiano le nuove operazioni di attributo, puoi iniziare a utilizzare l'attributo link negli item della tabella.

Java DynamoDB Mapper

Quando utilizzi DynamoDB Mapper e AttributeEncryptor, per impostazione predefinita, tutti gli attributi sono crittografati e firmati, tranne le chiavi primarie, che sono firmate ma non crittografate. Per specificare un'operazione di sola firma, utilizza l'annotazione @DoNotEncrypt.

In questo esempio viene utilizzata l'annotazione @DoNotEncrypt per il nuovo attributo 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

Nel criptatore DynamoDB di livello inferiore, è necessario impostare azioni per ogni attributo. In questo esempio viene utilizzata un'istruzione switch in cui l'impostazione predefinita è encryptAndSign e vengono specificate eccezioni per la chiave di partizione, la chiave di ordinamento e il nuovo attributo link. In questo esempio, se il codice attributo di collegamento non è stato distribuito completamente prima dell'utilizzo, l'attributo di collegamento verrà crittografato e firmato da alcune applicazioni, mentre verrà solo firmato da altre applicazioni.

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

Nel DynamoDB Encryption Client for Python, è possibile specificare un'azione predefinita per tutti gli attributi e quindi specificare le eccezioni.

Se utilizzi una classe helper del client Python, non devi specificare un'operazione di attributo per gli attributi della chiave primaria. Le classi helper del client impediscono la crittografia della chiave primaria. Tuttavia, se non si utilizza una classe client helper, è necessario impostare l'ONLYazione SIGN _ sulla chiave di partizione e sulla chiave di ordinamento. Se esegui accidentalmente la crittografia della partizione o della chiave di ordinamento, non potrai recuperare i dati senza una scansione completa della tabella.

In questo esempio viene specificata un'eccezione per il nuovo attributo link, che ottiene l'operazione SIGN_ONLY.

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

Rimozione di un attributo

Se non è più necessario un attributo negli elementi che sono stati crittografati con il DynamoDB Encryption Client, è possibile smettere di utilizzare l'attributo. Tuttavia, non eliminare o modificare l'operazione per tale attributo. In tal caso, se viene riscontrato un item con tale attributo, la firma calcolata per l'item non corrisponderà alla firma originale e la convalida della firma avrà esito negativo.

Anche se potresti essere tentato di rimuovere tutte le tracce dell'attributo dal tuo codice, aggiungi un commento che indica che l'item non è più utilizzato invece di eliminarlo. Anche se esegui una scansione completa della tabella per eliminare tutte le istanze dell'attributo, un item crittografato con tale attributo potrebbe essere memorizzato nella cache o in fase di elaborazione in qualche punto della configurazione.