Configurare i permessi con GRANT e REVOKE

Pensa ai tuoi dati come a una fortezza, e ogni abitante della fortezza ha i suoi permessi: c’è chi può solo passeggiare nel cortile, chi custodisce le chiavi del tesoro, e chi siede nella sala del trono e comanda tutto. Nel nostro database, questo ruolo lo svolgono i comandi GRANT e REVOKE. Sono proprio loro che decidono chi può andare dove e perché.

Il comando GRANT, come ogni grant che si rispetti, permette di dare accesso alle risorse (tipo database, tabelle, schemi) a certi ruoli. È un po’ come “l’invito alla festa”, dove decidi chi può leggere, scrivere o anche rompere i mobili.

Il comando REVOKE, invece, toglie i permessi dati prima. È come dire: “Ehi, la festa per te è finita, lascia le chiavi all’uscita”.

Dare i permessi con GRANT

Partiamo dal livello più alto — il database. Per permettere a un utente di collegarsi al database, bisogna dargli il permesso di connessione. Si fa così:

GRANT CONNECT ON DATABASE database_name TO role_name;

Per esempio, se abbiamo il database university e il ruolo student, possiamo permettere agli studenti di collegarsi con questa query:

GRANT CONNECT ON DATABASE university TO student;

Ma solo collegarsi non vuol dire poter fare tutto quello che si vuole. Per permettere a un utente di creare oggetti nel database, serve anche il permesso di creazione:

GRANT CREATE ON DATABASE university TO student;

Puoi controllare i permessi sul database con questo comando:

\l+ university

Revocare i permessi con REVOKE

Se lo studente inizia a comportarsi in modo sospetto (tipo, vuole creare più tabelle di quanto ci aspettassimo), possiamo togliergli il permesso di creazione con questo comando:

REVOKE CREATE ON DATABASE university FROM student;

Dopo questo, lo studente potrà solo collegarsi, ma niente più “libertà creative”.

Configurare i permessi a livello di schema

Uno schema è, in pratica, una “stanza” dentro il nostro database, dove ci sono tabelle, viste e altri oggetti. Per permettere a un utente di lavorare con gli oggetti dentro uno schema, puoi configurare i permessi di lettura, scrittura o creazione di oggetti.

Dare i permessi sullo schema

Supponiamo di avere lo schema public (che viene creato di default in ogni database). Possiamo permettere a un utente di vedere il contenuto dello schema così:

GRANT USAGE ON SCHEMA public TO student;

Ma solo USAGE non basta per lavorare con le tabelle. Per permettere la creazione di nuovi oggetti, aggiungiamo:

GRANT CREATE ON SCHEMA public TO student;

Così, lo studente può non solo leggere, ma anche creare tabelle nello schema public.

Revocare i permessi sullo schema

Se lo studente inizia a riempire lo schema di tabelle strane tipo bad_idea_01, possiamo limitare i suoi permessi:

REVOKE CREATE ON SCHEMA public FROM student;

Ora lo studente non potrà più aggiungere nuove tabelle. Ordine ristabilito!

Configurare i permessi a livello di tabella

La tabella è probabilmente l’oggetto più usato del database. Vediamo come configurare l’accesso alle tabelle. Qui ci sono tre categorie principali di azioni: lettura, scrittura e modifica.

Permessi di lettura

Per permettere a un utente di leggere il contenuto di una tabella, si usa:

GRANT SELECT ON TABLE table_name TO role_name;

Per esempio, per permettere agli studenti di leggere i dati dalla tabella courses:

GRANT SELECT ON TABLE courses TO student;

Ora l’utente student può fare query SELECT sulla tabella courses.

Permessi di scrittura

Se vuoi che un utente possa inserire nuove righe in una tabella, puoi configurarlo così:

GRANT INSERT ON TABLE table_name TO role_name;

Esempio:

GRANT INSERT ON TABLE courses TO student;

Ora gli studenti possono aggiungere nuovi corsi nella tabella. Ma aspetta... Siamo sicuri che sia una buona idea?

Permessi di modifica e cancellazione

Se un utente deve poter aggiornare o cancellare righe esistenti, bisogna dargli i permessi UPDATE e DELETE rispettivamente.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Consiglio: non esagerare con questi permessi. Se dai agli studenti il permesso di cancellare dati, potrebbero rovinare tutto per sbaglio (o apposta).

Esempi: creare un ruolo con permessi limitati

Immagina di dover creare un ruolo per i docenti, che devono poter leggere i dati su studenti e corsi, ma non cancellare record. Ecco come si fa:

1. Crea il ruolo:

CREATE ROLE teacher;

2. Dai i permessi di lettura sulle tabelle students e courses:

GRANT SELECT ON TABLE students, courses TO teacher;

3. Limita il permesso di cancellazione:

REVOKE DELETE ON TABLE students, courses FROM teacher;

Ora i nostri docenti avranno solo i permessi necessari e niente di più.

Come combinare GRANT e REVOKE per una configurazione flessibile

Supponiamo di avere il ruolo intern, che vogliamo limitare. Deve poter accedere solo ai dati dei corsi, ma mai a quelli degli studenti. Ecco come si fa:

1. Permetti l’accesso solo alla tabella courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Assicurati che il ruolo intern non abbia permessi sulla tabella students:

REVOKE ALL ON TABLE students FROM intern;

Questa combinazione ti permette di configurare i permessi in modo preciso.

Esempi di utilizzo in progetti reali

Questo sistema di gestione dei permessi si usa spesso nei progetti veri. Per esempio:

1. Negli e-commerce, i permessi sulle tabelle utenti e ordini sono divisi tra i ruoli "amministratore", "operatore" e "ospite".
2. Nelle piattaforme universitarie, gli amministratori possono aggiungere e modificare corsi, mentre gli studenti possono solo vederli.
3. Nei sistemi bancari, l’accesso ai conti dei clienti è separato tra i dipendenti dei vari reparti.