Utilizzo della crittografia per rafforzare la sicurezza del database PostgreSQL

Nota:parti del blog contengono riferimenti ed esempi da "ANNOUNCING AVAILABILITY OF POSTGRESQL INSTANCE LEVEL ENCRYPTION" di CyberTec, una società che fornisce supporto, consulenza e formazione per PostgreSQL.

Le organizzazioni gestiscono diversi tipi di dati, comprese informazioni molto importanti che devono essere archiviate in un database. La sicurezza è un aspetto fondamentale da considerare per garantire che dati sensibili come cartelle cliniche e transazioni finanziarie non finiscano nelle mani di persone con mezzi nefasti. Nel corso degli anni, gli sviluppatori hanno escogitato molteplici misure per migliorare l'integrità e la protezione dei dati. Una delle tecniche più utilizzate è la crittografia per prevenire violazioni dei dati.

Per quanto tu possa aver utilizzato misure di protezione complesse, alcune persone potrebbero comunque finire per avere accesso al tuo sistema. La crittografia è un ulteriore livello di sicurezza. PostgreSQL offre crittografia a diversi livelli oltre a fornire flessibilità nella protezione dei dati dalla divulgazione a causa di amministratori inaffidabili, connessioni di rete non sicure e furto del server di database. PostgreSQL fornisce diverse opzioni di crittografia come:

• Autenticazione host SSL
• Crittografia dei dati attraverso una rete
• Crittografia partizione dati
• Crittografia per colonne specifiche
• Crittografia dell'archiviazione delle password
• Crittografia lato client

Tuttavia, più sofisticata è la strategia di crittografia che utilizzi, maggiore è la probabilità di essere bloccato fuori dai tuoi dati. Inoltre, il processo di lettura non solo sarà difficile, ma richiederà anche molte risorse per interrogare e decrittografare. L'opzione di crittografia che selezioni dipende dalla natura dei dati con cui hai a che fare in termini di sensibilità. Il diagramma seguente illustra la procedura generale di crittografia e decrittografia dei dati durante le transazioni del server.

Questo articolo discute i diversi modi in cui un'azienda può proteggere le informazioni riservate, ma il principale punto di interesse sarà la crittografia a livello di istanza menzionata in precedenza.

Crittografia

La crittografia è una pratica di codifica dei dati in modo che non siano più nel formato originale e non possano essere letti. Esistono 2 tipi di dati per quanto riguarda il database:dati inattivi e dati in movimento. Quando i dati sono archiviati nel database, si parla di dati inattivi. D'altra parte, se un client, ad esempio, invia una richiesta al database, se alcuni dati vengono restituiti e devono raggiungere il client, allora si parla di dati in movimento. I due diversi tipi di dati devono essere protetti utilizzando una tecnologia simile. Ad esempio, se un'applicazione è sviluppata in modo tale che un utente debba inviare una password, questa password non verrà archiviata nel database come testo normale. Esistono alcune procedure di codifica che vengono utilizzate per modificare questo testo normale in una stringa diversa prima dell'archiviazione. Inoltre, se l'utente ha bisogno di utilizzare questa password, ad esempio per un sistema di accesso, allora abbiamo bisogno di un modo per confrontare quella che verrà inviata nel processo di decrittazione.

La crittografia del database può essere implementata in diversi modi, ma molti sviluppatori non tengono conto del livello di trasporto. Tuttavia, i diversi approcci sono anche associati a diverse insidie ​​dovute a tempi di accesso ai dati rallentati, specialmente quando si accede pesantemente alla memoria virtuale.

Crittografia dei dati inattivi

Per dati inattivi si intendono i dati inattivi archiviati fisicamente su disco. Quando si tratta di ospitare un database in un ambiente cloud, in cui il fornitore di servizi cloud ha pieno accesso all'infrastruttura, la crittografia potrebbe essere una buona misura per mantenere il controllo sui dati. Alcune delle strategie di crittografia che puoi utilizzare sono discusse di seguito.

Crittografia completa del disco (FDE)

Il concetto alla base di FDE è generalmente quello di proteggere ogni file e memoria temporanea che può contenere parti dei dati. È abbastanza efficiente soprattutto quando hai difficoltà a selezionare ciò che vuoi proteggere o meglio se non vuoi perdere un file. Il vantaggio principale di questa strategia è che non richiede un'attenzione particolare da parte dell'utente finale dopo aver avuto accesso al sistema. Questo approccio ha però alcune insidie. Questi includono:

• Il processo di crittografia e decrittografia rallenta il tempo complessivo di accesso ai dati.
• I dati potrebbero non essere protetti quando il sistema è acceso poiché le informazioni verranno decrittografate e pronte per la lettura. È quindi necessario utilizzare alcune altre strategie di crittografia come la crittografia basata su file.

Crittografia basata su file

In questo caso, i file o le directory vengono crittografati dal file system crittografico impilabile stesso. In PostgreSQL, utilizziamo spesso l'approccio pg_crypto come discusso in questo articolo.

Alcuni dei vantaggi della crittografia del file system includono:

• Il controllo delle azioni può essere imposto tramite l'uso della crittografia a chiave pubblica
• Gestione separata dei file crittografati in modo tale che i backup dei file modificati singolarmente anche in forma crittografata, anziché il backup dell'intero volume crittografato.

Tuttavia, questo non è un metodo di crittografia molto affidabile che puoi utilizzare per i tuoi dati in cluster. Il motivo è che alcune soluzioni di crittografia basate su file possono lasciare un residuo di file crittografati su cui un utente malintenzionato potrebbe eseguire il ripristino. L'approccio di combinazione migliore è quindi quello di combinare questo con la crittografia completa del disco.

Crittografia a livello di istanza

Il livello di istanza utilizza i buffer in modo tale che tutti i file che compongono il cluster PostgreSQL siano archiviati su disco come crittografia dei dati inattivi. Vengono quindi presentati come blocchi di decrittografia mentre vengono letti dal disco nei buffer condivisi. Dopo aver scritto questi blocchi su disco dai buffer condivisi, vengono nuovamente crittografati automaticamente. Il database viene prima inizializzato con la crittografia utilizzando il comando initdb. In secondo luogo, durante l'avvio, la chiave di crittografia viene recuperata dal server in uno di questi due modi; tramite il parametro pgcrypto.keysetup_command o tramite una variabile di ambiente.

Impostazione della crittografia a livello di istanza

Un piccolo riepilogo su come impostare la crittografia a livello di istanza è descritto nei passaggi seguenti:

1. Controlla se hai "contrib" installato usando il comando rpm -qa |grep contrib per il sistema operativo basato su RedHat o dpkg -l |grep contrib per il sistema operativo basato su Debian. Se non è nell'elenco, installalo con apt-get install postgresql-contrib se stai usando l'ambiente basato su Debian o yum install postgresql-contrib se stai usando un sistema operativo basato su RedHat.
2. Costruisci il codice PostgreSQL.
3. Inizializzazione del cluster stabilendo la chiave di crittografia ed eseguendo il comando he initdb

   read -sp "Postgres passphrase: " PGENCRYPTIONKEY
   export PGENCRYPTIONKEY=$PGENCRYPTIONKEY
   initdb –data-encryption pgcrypto --data-checksums -D cryptotest

4. Avviare il server con il comando

   $ postgres -D /usr/local/pgsql/data

5. Impostazione della variabile di ambiente PGENCRYPTIONKEY con il comando:

   export PGENCRYPTIONKEY=topsecret pg_ctl -D cryptotest start

   La chiave può anche essere impostata attraverso una procedura di lettura della chiave personalizzata e più sicura tramite il sopra menzionato comando "pgcrypto.keysetup_command" parametro postgresql.conf.

Aspettative di prestazione

La crittografia viene sempre a scapito delle prestazioni, poiché non ci sono opzioni senza un costo. Se il tuo carico di lavoro è orientato all'IO, potresti aspettarti prestazioni notevolmente ridotte, ma potrebbe non essere così. A volte sull'hardware del server tipico, se il set di dati è meno condiviso nei buffer o se il tempo di permanenza nei buffer è ridotto, il calo delle prestazioni potrebbe essere trascurabile.

Dopo aver eseguito la crittografia del mio database, ho eseguito alcuni piccoli test per verificare se la crittografia influisce davvero sulle prestazioni e i risultati sono elencati di seguito.

Come illustrato nella tabella sopra, possiamo vedere che la performance non è lineare poiché a volte salta dal 161% allo 0,7%. Questa è una semplice indicazione che le prestazioni di crittografia sono specifiche del carico di lavoro oltre a essere sensibili alla quantità di pagine spostate tra i buffer condivisi e il disco. Ciò può anche influire sulla potenza della CPU a seconda del carico di lavoro coinvolto. La crittografia a livello di istanza è un'opzione abbastanza praticabile e l'approccio più semplice per numerosi ambienti.

Conclusione

La crittografia dei dati è un'impresa importante soprattutto per le informazioni sensibili nella gestione dei database. Ci sono una serie di opzioni disponibili per la crittografia dei dati per quanto riguarda PostgreSQL. Quando si determina quale approccio utilizzare, è importante comprendere i dati, l'architettura dell'applicazione e l'utilizzo dei dati poiché la crittografia va a scapito delle prestazioni. In questo modo sarai in grado di capire:quando abilitare la crittografia, dove sono esposti i tuoi dati e dove sono al sicuro, qual è il miglior approccio di crittografia da utilizzare.