Utilizzo dei beacon - AWS SDK per la crittografia del database
Interrogazione dei beacon

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à.

Utilizzo dei beacon

La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul DynamoDB Encryption Client.

I beacon consentono di cercare record crittografati senza decrittografare l'intero database su cui viene eseguita la query. I beacon sono progettati per essere implementati in nuovi database non popolati. Qualsiasi beacon configurato in un database esistente mapperà solo i nuovi record scritti nel database. I beacon vengono calcolati in base al valore in chiaro di un campo, una volta crittografato il campo non è più possibile per il beacon di mappare i dati esistenti. Dopo aver scritto nuovi record con un beacon, non è possibile aggiornare la configurazione del beacon. Tuttavia, puoi aggiungere nuovi beacon per i nuovi campi che aggiungi al tuo record.

Dopo aver configurato i beacon, è necessario completare i seguenti passaggi prima di iniziare a popolare il database ed eseguire query sui beacon.

  1. AWS KMS Crea un portachiavi gerarchico

    Per utilizzare la crittografia ricercabile, è necessario utilizzare il portachiavi AWS KMS gerarchico per generare, crittografare e decrittografare le chiavi dati utilizzate per proteggere i record.

    Dopo aver configurato i beacon, assemblate i prerequisiti del portachiavi gerarchico e create il portachiavi gerarchico.

    Per maggiori dettagli sul motivo per cui è necessario il portachiavi gerarchico, consulta Utilizzo del portachiavi gerarchico per la crittografia ricercabile.

  2. Definisci la versione del beacon

    Specificate il vostro keyStorekeySource, un elenco di tutti i beacon standard che avete configurato, un elenco di tutti i beacon composti che avete configurato, un elenco di parti crittografate, un elenco di parti firmate e una versione del beacon. È necessario specificare la versione beacon. 1 Per indicazioni sulla definizione del tuokeySource, vedi. Definizione della fonte della chiave del beacon

    Il seguente esempio di Java definisce la versione beacon per un database a tenant singolo. Per informazioni sulla definizione della versione beacon per un database multitenant, vedere Crittografia ricercabile per database multitenant.

    Java
     List<BeaconVersion> beaconVersions = new ArrayList<>();
beaconVersions.add(
    BeaconVersion.builder()
        .standardBeacons(standardBeaconList)
        .compoundBeacons(compoundBeaconList)
        .encryptedParts(encryptedPartsList)
        .signedParts(signedPartsList)
        .version(1) // MUST be 1
        .keyStore(keyStore)
        .keySource(BeaconKeySource.builder()
            .single(SingleKeyStore.builder()
                .keyId(branchKeyId)
                .cacheTTL(6000)
                .build())
            .build())
        .build()
);
    C# / .NET
    var beaconVersions = new List<BeaconVersion>
{
    new BeaconVersion
    {
        StandardBeacons = standardBeaconList,
        CompoundBeacons = compoundBeaconList,
        EncryptedParts = encryptedPartsList,
        SignedParts = signedPartsList,
        Version = 1, // MUST be 1
        KeyStore = branchKeyStoreName,
        KeySource = new BeaconKeySource
        {
            Single = new SingleKeyStore
            {
                KeyId = branch-key-id,
                CacheTTL = 6000
            }
        }
    }
};

  3. Configura gli indici secondari

    Dopo aver configurato i beacon, è necessario configurare un indice secondario che rifletta ogni beacon prima di poter eseguire la ricerca nei campi crittografati. Per ulteriori informazioni, consulta Configurazione degli indici secondari con beacon.

  4. Definisci le tue azioni crittografiche

    Tutti i campi utilizzati per costruire un beacon standard devono essere contrassegnati. ENCRYPT_AND_SIGN Tutti gli altri campi utilizzati per costruire i beacon devono essere contrassegnati o. SIGN_ONLY SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT

  5. Configurare un client AWS Database Encryption SDK

    Per configurare un client AWS Database Encryption SDK che protegge gli elementi della tabella DynamoDB, consulta Libreria di crittografia lato client Java per DynamoDB.

Interrogazione dei beacon

Il tipo di beacon configurato determina il tipo di interrogazioni che è possibile eseguire. I beacon standard utilizzano espressioni di filtro per eseguire ricerche di uguaglianza. I beacon composti combinano stringhe letterali in chiaro e beacon standard per eseguire query complesse. Quando si interrogano dati crittografati, si esegue la ricerca in base al nome del beacon.

Non è possibile confrontare i valori di due beacon standard, anche se contengono lo stesso testo in chiaro sottostante. I due beacon standard produrranno due tag HMAC diversi per gli stessi valori di testo in chiaro. Di conseguenza, i beacon standard non possono eseguire le seguenti interrogazioni.

  • beacon1 = beacon2

  • beacon1 IN (beacon2)

  • value IN (beacon1, beacon2, ...)

  • CONTAINS(beacon1, beacon2)

I beacon composti possono eseguire le seguenti interrogazioni.

  • BEGINS_WITH(a), dove a riflette l'intero valore del campo con cui inizia il faro composto assemblato. Non è possibile utilizzare l'BEGINS_WITHoperatore per identificare un valore che inizia con una particolare sottostringa. Tuttavia, è possibile utilizzareBEGINS_WITH(S_), where S_ riflette il prefisso per una parte con cui inizia il faro composto assemblato.

  • CONTAINS(a), dove a riflette l'intero valore di un campo contenuto nel beacon composto assemblato. Non è possibile utilizzare l'CONTAINSoperatore per identificare un record che contiene una particolare sottostringa o un valore all'interno di un set.

    Ad esempio, non è possibile eseguire un'interrogazione CONTAINS(path, "a" in cui a rifletta il valore in un set.

  • È possibile confrontare parti firmate di beacon composti. Quando si confrontano parti firmate, è possibile aggiungere facoltativamente il prefisso di una parte crittografata a una o più parti firmate, ma non è possibile includere il valore di un campo crittografato in nessuna query.

    Ad esempio, è possibile confrontare parti firmate ed eseguire una query su o. signedField1 = signedField2 value IN (signedField1, signedField2, ...)

    È inoltre possibile confrontare le parti firmate e il prefisso di una parte crittografata mediante interrogazione susignedField1.A_ = signedField2.B_.

  • field BETWEEN a AND b, dove a e b sono le parti firmate. È possibile aggiungere facoltativamente il prefisso di una parte crittografata a una o più parti firmate, ma non è possibile includere il valore di un campo crittografato in nessuna query.

È necessario includere il prefisso per ogni parte inclusa in una query su un beacon composto. Ad esempio, se avete creato un beacon composto a partire da due campi encryptedField e compoundBeaconsignedField, dovete includere i prefissi configurati per queste due parti quando interrogate il beacon.

compoundBeacon = E_encryptedFieldValue.S_signedFieldValue