Una volta terminato il processo di installazione del server del database PostgreSQL è necessario proteggerlo prima di entrare in produzione. In questo post, ti mostreremo come rafforzare la sicurezza del tuo database per mantenere i tuoi dati al sicuro.
1. Controllo dell'autenticazione del cliente
Quando si installa PostgreSQL, viene creato un file denominato pg_hba.conf nella directory dei dati del cluster di database. Questo file controlla l'autenticazione del client.
Dalla documentazione ufficiale di postgresql possiamo definire il file pg_hba.conf come un insieme di record, uno per riga, dove ogni record specifica un tipo di connessione, un intervallo di indirizzi IP del client (se rilevante per il tipo di connessione), un nome di database, un nome utente e il metodo di autenticazione da utilizzare per le connessioni che corrispondono a questi parametri. Per eseguire l'autenticazione viene utilizzato il primo record con un tipo di connessione, un indirizzo client, un database richiesto e un nome utente corrispondenti.
Quindi il formato generale sarà qualcosa del genere:
# TYPE DATABASE USER ADDRESS METHODUn esempio di configurazione può essere il seguente:
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.94.0/24 rejectCi sono molte combinazioni che puoi fare per perfezionare le regole (la documentazione ufficiale descrive ogni opzione in dettaglio e contiene alcuni ottimi esempi), ma ricorda di evitare regole troppo permissive, come consentire l'accesso alle linee usando DATABASE all o ADDRESS 0.0.0.0/0.
Per garantire la sicurezza, anche se ti stai dimenticando di aggiungere una regola, puoi aggiungere la seguente riga in basso:
# TYPE DATABASE USER ADDRESS METHOD
host all all 0.0.0.0/0 rejectPoiché il file viene letto dall'alto verso il basso per trovare le regole di corrispondenza, in questo modo ti assicuri che per consentire l'autorizzazione dovrai aggiungere esplicitamente la regola di corrispondenza sopra.
2. Configurazione del server
Ci sono alcuni parametri su postgresql.conf che possiamo modificare per migliorare la sicurezza.
È possibile utilizzare il parametro listen_address per controllare a quali IP sarà consentito connettersi al server. Ecco una buona pratica per consentire le connessioni solo dagli IP noti o dalla tua rete ed evitare valori generali come "*","0.0.0.0:0" o "::", che diranno a PostgreSQL di accettare la connessione da qualsiasi IP.
Anche la modifica della porta su cui Postgresql ascolterà (per impostazione predefinita 5432) è un'opzione. Puoi farlo modificando il valore del parametro port.
Parametri come work_mem, Maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit sono importanti da tenere a mente in caso di attacco Denial of Service. Questi sono parametri di istruzione/sessione che possono essere impostati a diversi livelli (db, utente, sessione), quindi gestirli con saggezza può aiutarci a ridurre al minimo l'impatto dell'attacco.
3. Gestione utenti e ruoli
La regola d'oro per la sicurezza relativa alla gestione degli utenti è garantire agli utenti la quantità minima di accesso di cui hanno bisogno.
Gestire questo non è sempre facile e può diventare davvero complicato se non fatto bene dall'inizio.
Un buon modo per tenere sotto controllo i privilegi è utilizzare il ruolo, il gruppo, la strategia dell'utente.
In postgresql tutto è considerato un ruolo, ma apporteremo alcune modifiche a questo.
In questa strategia creerai tre diversi tipi o ruoli:
- ruolo (identificato dal prefisso r_)
- ruolo del gruppo (identificato dal prefisso g_)
- ruolo utente (generalmente nomi personali o dell'applicazione)
I ruoli (r_ruoli) saranno quelli che avranno i privilegi sugli oggetti. I ruoli di gruppo ( g_ ruoli ) verranno assegnati con i ruoli r, quindi saranno una raccolta di ruoli r. Infine, i ruoli utente verranno assegnati con uno o più ruoli di gruppo e saranno quelli con il privilegio di accesso.
Mostriamo un esempio di questo. Creeremo un gruppo di sola lettura per lo schema_esempio e quindi lo concederemo a un utente:
Creiamo il ruolo di sola lettura e gli concediamo i privilegi dell'oggetto
CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;Creiamo il gruppo di sola lettura e assegniamo il ruolo a quel gruppo
CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;Creiamo il ruolo app_user e lo facciamo "unire" al gruppo di sola lettura
CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;Utilizzando questo metodo puoi gestire la granularità dei privilegi e puoi facilmente concedere e revocare gruppi di accesso agli utenti. Ricorda di concedere solo privilegi oggetto ai ruoli invece di farlo direttamente per gli utenti e di concedere il privilegio di accesso solo agli utenti.
Questa è una buona pratica per revocare esplicitamente i privilegi pubblici sugli oggetti, come revocare l'accesso pubblico a un database specifico e concederlo solo tramite un ruolo.
REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;Limita l'accesso SUPERUSER, consenti connessioni superuser solo dal dominio localhost/unix.
Utilizza utenti specifici per scopi diversi, come utenti di app specifici o utenti di backup, e limita le connessioni per quell'utente solo dagli IP richiesti.
4. Super User Management
Mantenere una policy password forte è un must per mantenere i database al sicuro ed evitare gli hack delle password. Per una politica forte, utilizzare preferibilmente caratteri speciali, numeri, caratteri maiuscoli e minuscoli e avere almeno 10 caratteri.
Esistono anche strumenti di autenticazione esterni, come LDAP o PAM, che possono aiutarti a garantire la scadenza della password e la politica di riutilizzo, e anche a gestire il blocco dell'account in caso di errori di autenticazione.
5. Crittografia dati (su connessione SSL)
PostgreSQL ha il supporto nativo per l'utilizzo delle connessioni SSL per crittografare le comunicazioni client/server per una maggiore sicurezza. SSL (Secure Sockets Layer) è la tecnologia di sicurezza standard per stabilire un collegamento crittografato tra un server Web e un browser. Questo collegamento garantisce che tutti i dati passati tra il server web e i browser rimangano privati e integri.
Poiché i client postgresql inviano query in testo normale e anche i dati vengono inviati non crittografati, è vulnerabile allo spoofing di rete.
Puoi abilitare SSL impostando il parametro SSL su on in postgresql.conf.
Il server ascolterà le connessioni normali e SSL sulla stessa porta TCP e negozierà con qualsiasi client di connessione se utilizzare SSL. Per impostazione predefinita, questo è a scelta del client, ma hai la possibilità di configurare il server per richiedere l'uso di SSL per alcune o tutte le connessioni utilizzando il file di configurazione pg_hba descritto sopra.
6. Crittografia dati inattivi (pg_crypto)
Esistono due tipi di crittografia di base, unidirezionale e bidirezionale. In un certo senso non ti interessa mai decifrare i dati in una forma leggibile, ma vuoi solo verificare che l'utente sappia qual è il testo segreto sottostante. Questo è normalmente utilizzato per le password. Nella crittografia a due vie, vuoi la possibilità di crittografare i dati e consentire agli utenti autorizzati di decrittografarli in una forma significativa. Dati come carte di credito e SSN rientrerebbero in questa categoria.
Per la crittografia unidirezionale, la funzione crypt inclusa in pgcrypto fornisce un ulteriore livello di sicurezza al di sopra della modalità md5. Il motivo è che con md5 puoi dire chi ha la stessa password perché non c'è salt (in crittografia, un salt è un dato casuale che viene utilizzato come input aggiuntivo per una funzione unidirezionale che "hash" i dati, una password o passphrase), quindi tutte le persone con la stessa password avranno la stessa stringa md5 codificata. Con crypt, saranno diversi.
Per i dati che ti interessa recuperare, non vuoi sapere se le due informazioni sono uguali, ma non conosci quelle informazioni e vuoi che solo gli utenti autorizzati possano recuperarle. Pgcrypto fornisce diversi modi per farlo, quindi per ulteriori letture su come usarlo puoi controllare la documentazione ufficiale di postgresql su https://www.postgresql.org/docs/current/static/pgcrypto.html.
7. Registrazione
Postgresql fornisce un'ampia varietà di parametri di configurazione per controllare cosa, quando e dove registrare.
È possibile abilitare la connessione/disconnessioni della sessione, le query di lunga durata, le dimensioni dei file temporanei e così via. Questo può aiutarti a conoscere meglio il tuo carico di lavoro per identificare comportamenti strani. Puoi ottenere tutte le opzioni per l'accesso al seguente link https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html
Per informazioni più dettagliate sul carico di lavoro, è possibile abilitare il modulo pg_stat_statements, che fornisce un mezzo per tenere traccia delle statistiche di esecuzione di tutte le istruzioni SQL eseguite da un server. Esistono alcuni strumenti di sicurezza che possono acquisire i dati da questa tabella e genereranno una whitelist sql, in modo da aiutarti a identificare le query che non seguono gli schemi previsti.
Per ulteriori informazioni https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.
Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper8. Controllo
L'estensione di controllo PostgreSQL (pgAudit) fornisce una registrazione dettagliata della sessione e/o dell'audit degli oggetti tramite la funzione di registrazione standard di PostgreSQL.
La registrazione delle istruzioni di base può essere fornita dalla funzione di registrazione standard con log_statement =all. Ciò è accettabile per il monitoraggio e altri usi, ma non fornisce il livello di dettaglio generalmente richiesto per un audit. Non è sufficiente avere un elenco di tutte le operazioni eseguite sul database. Deve inoltre essere possibile trovare dichiarazioni particolari che interessano un revisore dei conti. La funzione di registrazione standard mostra ciò che l'utente ha richiesto, mentre pgAudit si concentra sui dettagli di ciò che è accaduto mentre il database stava soddisfacendo la richiesta.
9. Applicazione di patch
Controlla regolarmente e frequentemente la pagina delle informazioni sulla sicurezza di PostgreSQL per aggiornamenti e patch di sicurezza critici.
Tieni presente che i bug di sicurezza del sistema operativo o delle librerie possono anche portare a una perdita di database, quindi assicurati di mantenere aggiornate le patch per questi.
ClusterControl fornisce un rapporto operativo che fornisce queste informazioni ed eseguirà le patch e gli aggiornamenti per te.
10. Sicurezza a livello di riga
Oltre al sistema di privilegi SQL standard disponibile tramite GRANT, le tabelle possono avere criteri di sicurezza delle righe che limitano, in base all'utente, quali righe possono essere restituite da query normali o inserite, aggiornate o eliminate da comandi di modifica dei dati. Questa funzionalità è anche nota come sicurezza a livello di riga.
Quando la sicurezza delle righe è abilitata su una tabella, tutto il normale accesso alla tabella per la selezione delle righe o la modifica delle righe deve essere consentito da una politica di sicurezza delle righe.
Ecco un semplice esempio di come creare una policy sulla relazione account per consentire solo ai membri del ruolo di manager di accedere alle righe e solo alle righe dei loro account:
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);Puoi ottenere maggiori informazioni su questa funzione nella documentazione ufficiale di postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
Se vuoi saperne di più, ecco alcune risorse che possono aiutarti a rafforzare meglio la sicurezza del tuo database...
- https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
- https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
- https://www.postgresql.org/docs/current/static/pgcrypto.html
- http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
- https://github.com/pgaudit/pgaudit
- https://www.postgresql.org/docs/9.6/static/pgstatstatements.html
Conclusione
Se segui i suggerimenti sopra, il tuo server sarà più sicuro, ma ciò non significa che sarà infrangibile.
Per la tua sicurezza ti consigliamo di utilizzare uno strumento di test di sicurezza come Nessus, per sapere quali sono le tue principali vulnerabilità e provare a risolverle.
Puoi anche monitorare il tuo database con ClusterControl. Con questo puoi vedere in tempo reale cosa sta succedendo all'interno del tuo database e analizzarlo.
