"La sicurezza del database è come una buona password: puoi inventarti la chiave più complicata, ma se la scrivi su un post-it e la attacchi al monitor — non serve a niente." Quindi il nostro obiettivo è imparare non solo a configurare i meccanismi di protezione, ma anche a evitare gli errori banali che possono mandare tutto all’aria.
1. Uso di ruoli con permessi eccessivi
Spesso gli sviluppatori hanno paura di limitare l’accesso e creano ruoli con privilegi troppo ampi, tipo dare SUPERUSER o ALL PRIVILEGES. Il loro ragionamento è: "Beh, magari servirà!". Però i ruoli con troppi permessi sono una voragine nella sicurezza.
Esempio di permessi eccessivi:
GRANT ALL PRIVILEGES ON DATABASE university TO student_role;
In questo caso student_role ha accesso totale a tutti i dati del database. Anche se il ruolo doveva solo leggere i dati, ora può cancellare tabelle, cambiare la struttura e persino togliere l’accesso all’amministratore.
Come evitarlo?
Crea ruoli con il minimo indispensabile di permessi. Si chiama principio del minimo privilegio. Per esempio, un ruolo che deve solo leggere i dati dovrebbe essere così:GRANT CONNECT ON DATABASE university TO student_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO student_role;
Così è chiaro che student_role può solo connettersi al database e leggere i dati.
2. Mancanza di cifratura dei dati sensibili
Immagina la tabella users dove salviamo le password in chiaro:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username TEXT NOT NULL,
password TEXT NOT NULL
);
Se qualcuno riesce ad accedere a questa tabella, si prende tutte le password degli utenti. È come lasciare le chiavi di casa sotto lo zerbino.
Per evitarlo usa la cifratura delle password con pgcrypto. Per esempio:
CREATE EXTENSION IF NOT EXISTS pgcrypto;
INSERT INTO users (username, password)
VALUES ('johndoe', pgp_sym_encrypt('secure_password', 'encryption_key'));Per controllare la password puoi usare la decifratura:
SELECT username
FROM users
WHERE pgp_sym_decrypt(password::BYTEA, 'encryption_key') = 'secure_password';
Non salvare mai informazioni sensibili in chiaro!
3. Ignorare le SQL-injection
Le SQL-injection sono ancora uno dei metodi di attacco più diffusi, e il motivo è che gli sviluppatori continuano a costruire query usando l’interpolazione di stringhe. Ecco un esempio:
DO $$
DECLARE
username TEXT := 'John';
query TEXT;
BEGIN
query := 'SELECT * FROM users WHERE username = ''' || username || ''';';
EXECUTE query;
END $$;
Se un attaccante invece del nome utente invia John' OR '1'='1, il risultato sarà la fuga di tutti i dati dalla tabella users.
Come evitarlo? Usa query parametrizzate:
PREPARE user_query (TEXT) AS
SELECT * FROM users WHERE username = $1;
EXECUTE user_query('John');Qui la variabile viene inserita in modo sicuro, senza rischio di injection.
4. Configurazione sbagliata di pg_hba.conf
pg_hba.conf è lo strumento principale per controllare l’accesso tramite indirizzi IP. Errori nella configurazione possono aprire l’accesso molto più di quanto vorresti.
Esempio di configurazione sbagliata:
host all all 0.0.0.0/0 trust
Questa riga permette a chiunque di connettersi a qualsiasi database da qualsiasi IP senza password.
Come evitarlo? Configura l’accesso solo per IP specifici e usa il metodo di autenticazione md5 o scram-sha-256:
host university student_role 192.168.1.0/24 md5
Così student_role può accedere solo dalla rete locale e con password.
Dopo aver cambiato pg_hba.conf, ricordati di applicare le modifiche con il comando:
pg_ctl reload
5. Uso sbagliato di ROW LEVEL SECURITY
RLS è uno strumento potente, ma non serve a nulla se lo configuri male o ti dimentichi di attivarlo. Per esempio, anche dopo aver scritto la policy di accesso, non funziona se RLS è spento:
CREATE POLICY my_policy ON users
USING (username = current_user);
-- Ma RLS non è attivo!
SELECT * FROM users; -- Vedi tutte le righe!Come evitarlo? Non dimenticare di attivare RLS:
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
E controlla come viene applicata la policy:
SET ROLE student_role;
SELECT * FROM users; -- Vedi solo le righe permesse dalla policy.6. Azioni degli amministratori non considerate
A volte gli amministratori del database hanno accesso completo a tutti i dati, anche se non serve per il loro lavoro. Questo crea un rischio in più di fuga di dati se l’account admin viene compromesso.
Come evitarlo? Usa la separazione dei ruoli. Per i compiti di amministrazione crea un ruolo separato senza accesso ai dati:
CREATE ROLE admin_role WITH LOGIN CREATEDB CREATEROLE;
Per accedere ai dati crea un altro ruolo con permessi minimi:
CREATE ROLE data_analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO data_analyst_role;
Assegna i ruoli agli utenti in base ai loro compiti:
GRANT admin_role TO some_user;
GRANT data_analyst_role TO another_user;
7. Log insufficiente
Se non configuri il logging, non saprai mai di attività sospette finché non sarà troppo tardi.
Esempio di assenza di logging:
-- Nessuna impostazione in postgresql.conf
log_statement = 'none';
Come evitarlo? Attiva almeno il logging di base:
log_statement = 'all'
log_connections = on
log_disconnections = on
Così puoi vedere tutte le query eseguite, le connessioni e le disconnessioni.
Puoi anche configurare l’audit con l’estensione pgAudit per un controllo più dettagliato:
CREATE EXTENSION pgaudit;
8. Uso di metodi di autenticazione obsoleti
Usare metodi di autenticazione vecchi come password non offre abbastanza protezione.
Come evitarlo? Passa a metodi più sicuri come scram-sha-256:
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
E aggiorna le password degli utenti:
ALTER USER student_role WITH PASSWORD 'new_secure_password';
Questi problemi possono sembrare piccoli, ma ognuno di loro può diventare una falla di sicurezza seria. Il tuo compito è gestire il database come se ogni utente che prova a connettersi fosse sospetto. Come si dice, "fidati, ma controlla". Ora hai gli strumenti non solo per configurare la sicurezza, ma anche per evitare gli errori più comuni. Acchiappa la fortuna per la coda, e che i tuoi dati siano al sicuro!
GO TO FULL VERSION