Gestione degli accessi e sicurezza

Immagina un incubo: sei l’amministratore del database e una tabella importante con i dati dei clienti... puff, sparisce. Chi l’ha fatto? Perché? Forse è stato uno stagista inesperto che ha scritto per sbaglio DROP TABLE. O magari un utente malintenzionato che aveva accesso al database... Qualunque cosa sia stata, ormai è tardi per correre ai ripari! Non ti resta che svegliarti, riprenderti e iniziare a studiare la sicurezza dei database. Perché un database senza sicurezza è come una casa senza fondamenta.

Per i database la sicurezza deve essere al top, per prevenire minacce come:

• Accesso non autorizzato: qualcuno ottiene accesso a dati a cui non dovrebbe accedere.
• Fuga di dati: password, carte di credito o info riservate finiscono nelle mani sbagliate.
• SQL-injection: un metodo subdolo che permette a un attaccante di manipolare il tuo database tramite query poco protette.
• Errori umani: cancellazione accidentale di dati o modifiche irreversibili.

In PostgreSQL la sicurezza è implementata su più livelli: dalla creazione dei ruoli e gestione dei permessi fino alle restrizioni di accesso di rete. Questo ti permette di configurare in modo flessibile chi può fare cosa con i tuoi dati.

Principali livelli di sicurezza in PostgreSQL

In PostgreSQL ci sono tre livelli principali su cui puoi gestire l’accesso:

1. Gestione degli accessi a livello di database. A questo livello decidi chi può connettersi al tuo database e cosa può fare una volta connesso. Ad esempio, puoi vietare l’accesso a certi utenti. Ad altri — permettere solo la lettura. Lo strumento chiave qui sono i ruoli.

2. Controllo degli accessi a livello di tabelle, righe e colonne.

In PostgreSQL puoi limitare l’accesso ai dati in modo molto preciso. Puoi:

• Permettere a un utente di leggere solo certe colonne.
• Permettere di leggere dati in una tabella solo se l’utente è il proprietario della riga. Questo si chiama ROW LEVEL SECURITY (RLS), e lo vedremo meglio nelle prossime lezioni.
• Limitare l’accesso solo a certe parti del database (schemi) dove ci sono dati importanti.

3. Configurazione dell’accesso di rete. Il database può essere configurato per accettare richieste solo da client fidati. Questo si fa tramite il file di configurazione di PostgreSQL chiamato pg_hba.conf. Con questo file puoi, ad esempio, permettere la connessione solo dalla macchina locale o da certi indirizzi IP.

Strumenti di sicurezza di PostgreSQL

Vediamo quali strumenti di sicurezza offre PostgreSQL e come funzionano nella pratica.

Partiamo da ruoli e privilegi — la base del sistema di gestione degli accessi. In PostgreSQL un ruolo non è solo un utente, ma qualcosa di più flessibile. Può rappresentare sia una persona che un intero gruppo. Ad esempio, puoi creare un ruolo chiamato manager che ha pieno accesso alla tabella degli ordini, mentre allo stagista assegni il ruolo intern che ha solo permessi di lettura — così non può fare danni per sbaglio.

I ruoli si possono configurare in modo molto flessibile: a qualcuno dai più permessi, a qualcun altro meno, e puoi anche permettere a un ruolo di ereditare i permessi di un altro. Attraverso i ruoli decidi chi può connettersi al database, quali schemi e tabelle sono accessibili, e persino quali righe si possono vedere o modificare.

Poi ci sono i file di configurazione. In PostgreSQL ci sono due file di configurazione chiave che giocano un ruolo importante nella sicurezza.

Il primo è pg_hba.conf. Si occupa dell’accesso di rete al database. Qui imposti chi può connettersi al server, da quale indirizzo IP e con quale metodo di autenticazione. Se vuoi limitare l’accesso solo a certe macchine o utenti — si fa qui.

Il secondo file è postgresql.conf. Gestisce le impostazioni generali del server, e tra le altre cose qui imposti i parametri di logging e audit. Questo ti permette di monitorare chi fa cosa, notare attività sospette e, se serve, indagare nei dettagli.

Infine, logging e audit. "I log sono i tuoi migliori amici". Sembra strano, ma per un admin di database è la regola numero uno. In PostgreSQL puoi configurare il logging di tutte le query e azioni degli utenti. Questo ti aiuta a capire chi ha fatto cosa nel database se qualcosa va storto.

Esempio: protezione dei dati dalle SQL-injection

Le SQL-injection sono uno dei metodi di attacco più diffusi contro i database. E saperle prevenire è davvero fondamentale. Immagina di avere un’app dove l’utente inserisce l’ID del suo account per vedere il profilo. E l’app esegue una query tipo:

SELECT * FROM users WHERE id = 123;

Ma cosa succede se l’utente inserisce 123 OR 1=1 invece di un numero? La query diventa tipo:

SELECT * FROM users WHERE id = 123 OR 1=1;

E invece di una sola riga tutta la tabella users diventa accessibile.

Come difendersi? PostgreSQL ti permette di usare query parametrizzate o comandi preparati (PREPARE e EXECUTE), così i dati inseriti dall’utente non si mischiano mai con il codice SQL. Ecco come si fa:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

Altri esempi di minacce reali

Per farti capire bene perché serve la sicurezza, ti racconto due scenari reali:

Esempio 1: "Un dipendente ha cancellato tutta la tabella"

Una volta in un’azienda (in realtà, è successo più volte e in tante aziende...) uno stagista ha scritto per sbaglio in console:

DROP TABLE employees;

E 10 anni di dati sui dipendenti sono spariti nel nulla. Come evitarlo?

• Gestisci i permessi! Ad esempio, al ruolo intern dai solo lettura.
• Configura l’audit! I log ti diranno chi ha lanciato la query fatale.

Esempio 2: "Fuga di dati tramite connessione non cifrata"

Se un utente si connette al server PostgreSQL senza cifratura, login e password possono essere intercettati da un attaccante. Configura SSL e assicurati che le connessioni siano protette.

Compiti chiave per gli amministratori

Per chiudere questa introduzione, ecco i tre compiti principali di ogni admin PostgreSQL:

• Separazione degli accessi. Assicurati che solo gli utenti autorizzati possano fare certe azioni.
• Cifratura. I dati sensibili devono sempre essere archiviati e trasmessi in modo cifrato.
• Monitoraggio. Configura l’audit e tieni d’occhio le attività sospette nei log.

Nelle prossime lezioni imparerai a creare ruoli, gestire gli accessi con GRANT e REVOKE, implementare il controllo a livello di riga e usare la cifratura per proteggere i dati.