Utilizzo della crittografia modulare Parquet

IBM Analytics Engine Serverless supporta la crittografia modulare Parquet, una nuova aggiunta allo standard Parquet che permette di crittografare le colonne sensibili durante la scrittura dei file Parquet e decrittografare queste colonne durante la lettura dei file crittografati. Vedere Parquet modular encryption.

Oltre a garantire la privacy, la crittografia Parquet protegge anche l'integrità dei dati memorizzati. Viene rilevata qualsiasi manomissione del contenuto del file e viene attivata un'eccezione lato lettore.

Le funzioni principali includono:

La crittografia e la decrittografia del parquet vengono eseguite nei lavoratori Spark. Pertanto, i dati sensibili e le chiavi di cifratura non sono visibili all'archiviazione.
Le caratteristiche standard di Parquet, come la codifica, la compressione, la proiezione colonnare e il predicato push - down, continuano a funzionare come al solito sui file con il formato di crittografia modulare Parquet.
È possibile scegliere uno dei due algoritmi di crittografia definiti nella specifica Parquet. Entrambi gli algoritmi supportano la crittografia delle colonne, tuttavia:
- L'algoritmo predefinito AES-GCM fornisce una protezione completa contro la manomissione di parti di dati e metadati nei file Parquet.
- L'algoritmo alternativo AES-GCM-CTR supporta la protezione dell'integrità parziale dei file Parquet. Solo le parti di metadati sono protette contro la manomissione, non le parti di dati. Un vantaggio di questo algoritmo è che ha un sovraccarico della velocità di trasmissione inferiore rispetto all'algoritmo AES-GCM.
È possibile scegliere quali colonne codificare. Le altre colonne non verranno codificate, riducendo il sovraccarico della velocità di trasmissione.
Diverse colonne possono essere codificate con chiavi differenti.
Per impostazione predefinita, il modulo principale dei metadati Parquet (il piè di pagina del file) è codificato per nascondere lo schema di file e l'elenco di colonne sensibili. Tuttavia, puoi scegliere di non crittografare i piè di pagina dei file per consentire ai lettori legacy (come altre distribuzioni Spark che non supportano ancora la crittografia Parquet) di leggere le colonne non crittografate nei file crittografati.
Le chiavi di codifica possono essere gestite in uno dei seguenti due modi:
- Direttamente dalla tua applicazione. Vedere Gestione chiavi per applicazione.
- Con IBM® Key Protect for IBM Cloud®, un KMS (key management system) centralizzato per la creazione, la gestione e l'eliminazione delle chiavi di codifica utilizzate da IBM Analytics Engine. Vedi Key management by Key Protect{: {: external}}.
IBM® Key Protect for IBM Cloud® ti aiuta a gestire le tue chiavi crittografate allineandole con i ruoli IBM Cloud Identity and Access Management (IAM).

Nota: solo le MEK (master encryption key) devono essere gestite (dalla tua applicazione o da Key Protect). Le chiavi di crittografia dei dati (DEK) sono gestite automaticamente da Spark / Parquet. Per i dettagli sulla gestione delle chiavi all'interno della crittografia Parquet, vedi Internals of encryption key handling.

Per ogni colonna sensibile, è necessario specificare quale chiave master utilizzare per la codifica. Inoltre, è necessario specificare una chiave principale per il piè di pagina di ciascun file codificato (frame di dati), poiché i piè di pagina conservano metadati come lo schema e l'elenco di colonne sensibili, che possono essere anche sensibili. Per impostazione predefinita, la chiave del piè di pagina verrà utilizzata per la codifica del piè di pagina. Tuttavia, se si sceglie una modalità piè di pagina di testo semplice, il piè di pagina non verrà codificato e la chiave verrà utilizzata solo per la verifica dell'integrità del piè di pagina.

I parametri di crittografia possono essere passati tramite la configurazione Hadoop Spark standard, ad esempio impostando i valori di configurazione nella configurazione Hadoop di SparkContextdell'applicazione:
```
sc.hadoopConfiguration.set("<parameter name>" , "<parameter value>")
```
In alternativa, è possibile passare i valori dei parametri tramite le opzioni di scrittura:
```
<data frame name>.write
.option("<parameter name>" , "<parameter value>")
.parquet("<write path>")
```

Parametri obbligatori per l'esecuzione con la crittografia Parquet

Per la scrittura di dati codificati sono necessari i seguenti parametri:

Elenco di colonne da codificare, con le chiavi di codifica master:

parameter name: "parquet.encryption.column.keys"
parameter value: "<master key ID>:<column>,<column>;<master key ID>:<column>,.."

La chiave del piè di pagina:
```
parameter name: "parquet.encryption.footer.key"
parameter value: "<master key ID>"
```
Ad esempio:
```
dataFrame.write
.option("parquet.encryption.footer.key" , "k1")
.option("parquet.encryption.column.keys" , "k2:SSN,Address;k3:CreditCard")
.parquet("<path to encrypted files>")
```
Importante: se non è impostato né il parametro "parquet.encryption.column.keys" né il parametro "parquet.encryption.footer.key", il file non verrà codificato. Se è impostato solo uno di questi parametri, viene generata un'eccezione, poiché questi parametri sono obbligatori per i file codificati.
La classe che implementa EncryptionPropertiesFactory:
```
parameter name: "parquet.crypto.factory.class"
parameter value: "com.ibm.parquet.key.management.IBMKeyToolsFactory"
```
Importante: se "parquet.crypto.factory.class" non è impostato, il file non verrà codificato da un factory di crittografia.

Parametri facoltativi

I seguenti parametri facoltativi possono essere utilizzati durante la scrittura di dati codificati:

L'algoritmo di codifica AES-GCM-CTR

Per impostazione predefinita, la codifica Parquet utilizza l'algoritmo AES-GCM che fornisce una protezione completa contro la manomissione di dati e metadati nei file Parquet. Tuttavia, poiché Spark 2.3.0 viene eseguito su Java 8, che non supporta l'accelerazione AES nell'hardware della CPU (aggiunta solo in Java 9), il sovraccarico di verifica dell'integrità dei dati può influire sulla velocità di trasmissione del workload in alcune situazioni.

Per compensare ciò, è possibile disattivare il supporto di verifica dell'integrità dei dati e scrivere i file crittografati con l'algoritmo alternativo AES-GCM-CTR, che verifica solo l'integrità delle parti di metadati e non quella delle parti di dati e ha un sovraccarico della velocità di trasmissione inferiore rispetto all'algoritmo AES-GCM.
```
parameter name: "parquet.encryption.algorithm"
parameter value: "AES_GCM_CTR_V1"
```
Modalità piè di pagina di testo semplice per i lettori legacy

Per impostazione predefinita, il modulo principale dei metadati Parquet (il piè di pagina del file) è codificato per nascondere lo schema di file e l'elenco di colonne sensibili. Tuttavia, puoi decidere di non crittografare i piè di pagina dei file per consentire ad altri lettori Spark e Parquet (che non supportano ancora la crittografia Parquet) di leggere le colonne non crittografate nei file crittografati. Per disattivare la codifica del piè di pagina, impostare il seguente parametro:
```
parameter name: "parquet.encryption.plaintext.footer"
parameter value: "true"
```
Importante: il parametro "parquet.encryption.footer.key" deve essere specificato anche in modalità piè di pagina di testo semplice. Sebbene il piè di pagina non sia codificato, la chiave viene utilizzata per firmare il contenuto del piè di pagina, il che significa che i nuovi lettori potrebbero verificarne l'integrità. I lettori legacy non sono interessati dall'aggiunta della firma del piè di pagina.

Esempi di utilizzo

I seguenti frammenti di codice di esempio per Python e Scala mostrano come creare i frame di dati, scritti in file parquet crittografati e letti da file parquet crittografati.

Python: scrittura di dati codificati

from pyspark.sql import

RowsquaresDF = spark.createDataFrame(
    sc.parallelize(range(1, 6))
    .map(lambda i: Row(int_column=i,  square_int_column=i ** 2)))

sc._jsc.hadoopConfiguration().set("parquet.crypto.factory.class",
    "com.ibm.parquet.key.management.IBMKeyToolsFactory")
sc._jsc.hadoopConfiguration().set("encryption.key.list",
    "key1: AAECAwQFBgcICQoLDA0ODw==, key2: AAECAAECAAECAAECAAECAA==")

encryptedParquetPath = "squares.parquet.encrypted"squaresDF.write\
   .option("parquet.encryption.column.keys", "key1:square_int_column")\
   .option("parquet.encryption.footer.key", "key2")\
   .parquet(encryptedParquetPath)

Python: lettura dei dati codificati

sc._jsc.hadoopConfiguration().set("parquet.crypto.factory.class",
    "com.ibm.parquet.key.management.IBMKeyToolsFactory")
sc._jsc.hadoopConfiguration().set("parquet.encryption.key.list",
     "key1: AAECAwQFBgcICQoLDA0ODw==, key2: AAECAAECAAECAAECAAECAA==")

encryptedParquetPath = "squares.parquet.encrypted"
parquetFile = spark.read.parquet(encryptedParquetPath)
parquetFile.show()

Scala: scrittura di dati codificati

case class SquareItem(int_column: Int, square_int_column: Double)
val dataRange = (1 to 6).toList
val squares = sc.parallelize(dataRange.map(i => new SquareItem(i, scala.math.pow(i,2))))
sc.hadoopConfiguration.set("parquet.crypto.factory.class","com.ibm.parquet.key.management.IBMKeyToolsFactory")
sc.hadoopConfiguration.set("parquet.encryption.key.list","key1: AAECAwQFBgcICQoLDA0ODw==, key2: AAECAAECAAECAAECAAECAA==")
val encryptedParquetPath = "squares.parquet.encrypted"
squares.toDS().write
  .option("parquet.encryption.column.keys", "key1:square_int_column")
  .option("parquet.encryption.footer.key", "key2")
  .parquet(encryptedParquetPath)

Scala: lettura dei dati crittografati

sc.hadoopConfiguration.set("parquet.crypto.factory.class","com.ibm.parquet.key.management.IBMKeyToolsFactory")
sc.hadoopConfiguration.set("parquet.encryption.key.list","key1: AAECAwQFBgcICQoLDA0ODw==, key2: AAECAAECAAECAAECAAECAA==")
val encryptedParquetPath = "squares.parquet.encrypted"
val parquetFile = spark.read.parquet(encryptedParquetPath)
parquetFile.show()

Elementi interni della gestione delle chiavi di crittografia

Quando si scrive un file Parquet, viene generata una chiave di crittografia dati casuale (DEK) per ogni colonna crittografata e per il piè di pagina. Queste chiavi vengono utilizzate per codificare i moduli di dati e metadati nel file Parquet.

La chiave di crittografia dei dati viene quindi crittografata con una chiave di crittografia (KEK), generata anche all'interno di Spark / Parquet per ogni chiave master. La chiave di crittografia della chiave viene crittografata con una chiave di crittografia master (MEK), localmente se le chiavi master sono gestite dall'applicazione, o in un servizio KeyProtect se le chiavi master sono gestite da IBM® Key Protect for IBM Cloud®.

Le chiavi di crittografia dei dati crittografate e le chiavi di crittografia delle chiavi vengono memorizzate nei metadati del file Parquet, insieme all'identità della chiave principale. Ogni chiave di crittografia ha un'identità univoca (generata localmente come un valore casuale sicuro a 16 byte), memorizzata anche nei metadati del file. Le chiavi di crittografia delle chiavi vengono memorizzate nella cache dal token di accesso, quindi non è necessario interagire con il servizio KeyProtect per ogni colonna o file crittografato se utilizzano la stessa chiave di crittografia master.

Quando si legge un file Parquet, l'identificativo della chiave di codifica principale (MEK) e la chiave di codifica della chiave codificata (KEK) con il relativo identificativo e la chiave di codifica dei dati codificati (DEK) vengono estratti dai metadati del file.

La chiave di crittografia della chiave viene decrittografata con la chiave di crittografia master, localmente se le chiavi master sono gestite dall'applicazione o in un servizio KeyProtect se le chiavi master sono gestite da IBM® Key Protect for IBM Cloud®. Le chiavi di crittografia della chiave sono memorizzate nella cache dal token di accesso, quindi non è necessario interagire con il servizio KeyProtect per ogni file o colonna decrittografata se utilizzano la stessa chiave di crittografia della chiave. Quindi la chiave di codifica dei dati (DEK) viene decodificata localmente, utilizzando la chiave di codifica delle chiavi (KEK).

Rotazione chiave (funzione facoltativa)

La pratica di crittografia envelope ha un'opzione avanzata per ruotare (modificare) le chiavi principali per ridurre al minimo il rischio di perdita di dati sensibili a causa di MEK compromessi. Le DEK non possono essere modificate, perché ciò significa crittografare completamente di nuovo i file Parquet. Le nuove MEK (e le KEK rigenerate in modo trasparente) vengono utilizzate per codificare nuovamente le DEK.

Per abilitare la rotazione delle chiavi nei file Parquet, è necessario impostare il parametro "parquet.encryption.key.material.store.internally" su "false" nella configurazione Hadoop quando si scrivono i file parquet.

Con questo parametro impostato, Parquet memorizza le chiavi (avvolte con MEK) in piccoli file separati, invece che all'interno dei file Parquet. Quando si esegue la rotazione della chiave, vengono sostituiti solo i piccoli file di materiale della chiave. Non è necessario modificare i file Parquet (che sono spesso immutabili). La maggior parte dei sistemi KMS supporta la rotazione delle chiavi sostituendo il contenuto delle chiavi principali memorizzate e mantenendo intatto l'ID MEK (ma aggiornando la versione della chiave). Una volta che un utente o un amministratore ha eseguito la rotazione della chiave master all'interno dell'istanza KMS utilizzando l'API specifica di KMS, il meccanismo di rotazione della chiave Parquet può essere attivato (ad esempio, dallo stesso amministratore) chiamando:

public static void KeyToolkit.rotateMasterKeys(String folderPath, Configuration hadoopConfig)

Quando viene eseguita la rotazione della chiave, ogni KEK in tutti i file di materiale della chiave in folderPath viene scartato con la vecchia versione MEK per consentire la decodifica della DEK. Viene generata una nuova KEK per ogni ID chiave principale e viene inclusa la nuova versione MEK. La creazione di una nuova KEK, invece di riutilizzare quella precedente, non significa solo che la sicurezza è migliorata, ma anche che le prestazioni delle successive operazioni di lettura dei dati sono aumentate. Questo perché un singolo processo di rotazione della chiave, eseguito dall'amministratore, opera su più file creati da processi diversi, il che significa molte KEK diverse per lo stesso ID MEK. Il processo di rotazione della chiave sostituisce le vecchie KEK con una singola nuova KEK, che consente ai lettori di eseguire una singola interazione unwrap con KMS per ogni chiave master.

Per esempi su come utilizzare la rotazione chiave:

Per la gestione delle chiavi per applicazione, consulta rotazione delle chiavi nella gestione delle chiavi per applicazione.
Per la gestione delle chiavi tramite Key Protect, consulta Key rotation key management by Key Protect.

Ulteriori informazioni

Consulta il seguente notebook di esempio per informazioni su come utilizzare Parquet Encryption:

Codifica parquet per applicazione di gestione chiavi