SQL Academy · Lezione

Permessi a livello di colonna

Nasconda le colonne sensibili

Permessi a livello di colonna è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Academy include 4 lezioni in totale.

Perché sono importanti le autorizzazioni a livello di colonna

Non tutti gli utenti dovrebbero poter vedere ogni colonna di una tabella. Una colonna salary, un password_hash o un credit_card_number possono trovarsi nella stessa tabella di dati completamente pubblici, come un nome utente o un indirizzo email.

Le autorizzazioni a livello di colonna consentono di concedere l'accesso a colonne specifiche anziché all'intera tabella, mantenendo nascosti i dati sensibili agli utenti che non hanno una ragione legittima per visualizzarli.

GRANT per un'intera tabella

Per impostazione predefinita, GRANT SELECT ON table consente a un ruolo di leggere tutte le colonne. Questo va bene per i dati pubblici, ma è problematico quando una tabella combina colonne sensibili e non sensibili.

La query seguente concede al ruolo analyst l'accesso completo in lettura alla tabella employees, inclusi stipendio e SSN.

GRANT SELECT ON employees TO analyst;

Sintassi di GRANT a livello di colonna

PostgreSQL, come lo standard SQL, consente di elencare nomi di colonne specifici all'interno di un'istruzione GRANT. La sintassi è:

GRANT privilege (col1, col2) ON table TO role;

L'esempio seguente concede al ruolo analyst l'autorizzazione a leggere solo id, name e department, ma NON salary o ssn.

GRANT SELECT (id, name, department) ON employees TO analyst;

Verificare le autorizzazioni a livello di colonna

È possibile esaminare i privilegi a livello di colonna in PostgreSQL interrogando la vista information_schema.column_privileges. Questa elenca quale beneficiario dispone di quale privilegio su quale colonna.

SELECT grantee, table_name, column_name, privilege_type
FROM information_schema.column_privileges
WHERE table_name = 'employees'
ORDER BY grantee, column_name;

Cosa accade senza le colonne corrette

Se un ruolo prova a leggere una colonna per la quale non ha ricevuto l'accesso, il database restituisce un errore permission denied. Solo i riferimenti alle colonne consentite andranno a buon fine.

Supponendo che a analyst siano state concesse solo id, name e department, la prima query seguente non va a buon fine, mentre la seconda sì.

-- This will fail for analyst (no permission on salary):
-- SELECT id, name, salary FROM employees;

-- This succeeds:
SELECT id, name, department FROM employees;

Autorizzazione UPDATE a livello di colonna

Le restrizioni a livello di colonna si applicano anche a UPDATE. È possibile consentire a un ruolo di aggiornare solo colonne specifiche, ad esempio permettendo a un ruolo dell'help desk di aggiornare lo status di un utente senza poter modificare il suo email o password_hash.

GRANT UPDATE (status) ON users TO helpdesk;

-- helpdesk can now run:
UPDATE users SET status = 'suspended' WHERE id = 42;

Nascondere le colonne con le viste

Un altro approccio comune consiste nel creare una vista che esponga solo le colonne sicure e nel concedere l'accesso alla vista invece che alla tabella di base. Funziona in tutti i database, non solo in quelli che supportano GRANT a livello di colonna.

CREATE VIEW public_employees AS
SELECT id, name, department, hire_date
FROM employees;

GRANT SELECT ON public_employees TO analyst;

Revocare l'accesso a livello di colonna

Proprio come GRANT, è possibile usare REVOKE con un elenco di colonne per rimuovere l'accesso a colonne specifiche. Se un ruolo disponeva di un accesso ampio a livello di tabella, potrebbe essere necessario revocarlo completamente prima di concedere un accesso limitato a livello di colonna.

-- Remove all SELECT on the table first
REVOKE SELECT ON employees FROM analyst;

-- Then grant only safe columns
GRANT SELECT (id, name, department) ON employees TO analyst;

Autorizzazioni a livello di colonna e sicurezza a livello di riga insieme

Le autorizzazioni a livello di colonna e Row-Level Security (RLS) sono complementari. RLS controlla quali righe un utente può vedere; le autorizzazioni a livello di colonna controllano quali colonne di quelle righe sono visibili.

Insieme formano un potente controllo degli accessi a due dimensioni: limitare l'insieme di righe E nascondere i campi sensibili all'interno di ogni riga.

-- RLS policy: employees can see only their own row
CREATE POLICY own_row ON employees
  FOR SELECT
  USING (user_id = current_user_id());

-- Column grant: hide salary even for own row
GRANT SELECT (id, name, department) ON employees TO employee_role;

Usare funzioni SECURITY DEFINER

Quando desidera una logica granulare che vada oltre i semplici elenchi di colonne, una funzione SECURITY DEFINER può fungere da collegamento. La funzione viene eseguita con i privilegi del proprietario, che dispone dell'accesso completo alle colonne, e restituisce solo ciò che sceglie di esporre, indipendentemente da chi la chiama.

CREATE OR REPLACE FUNCTION get_employee_summary(emp_id INT)
RETURNS TABLE(id INT, name TEXT, department TEXT)
SECURITY DEFINER
LANGUAGE sql AS
$$
  SELECT id, name, department
  FROM employees
  WHERE id = emp_id;
$$;

GRANT EXECUTE ON FUNCTION get_employee_summary(INT) TO analyst;

Progettazione pratica: sicurezza delle colonne a più livelli

Un solido modello per gli ambienti di produzione combina tre livelli:

Proprietà della tabella — solo l'account di servizio dell'applicazione è proprietario della tabella di base.
Viste o GRANT a livello di colonna — i ruoli di lettura accedono solo alle colonne non sensibili.
Colonne di audit — registrano quale utente e quale timestamp hanno modificato dati sensibili tramite trigger.

In questo modo, anche se a un ruolo vengono accidentalmente concessi privilegi eccessivi a un livello, gli altri livelli continuano a proteggere i dati.

-- Layer 1: revoke public access
REVOKE ALL ON employees FROM PUBLIC;

-- Layer 2: expose safe columns via view
CREATE VIEW employee_public AS
SELECT id, name, department, hire_date FROM employees;

GRANT SELECT ON employee_public TO reporting_role;

-- Layer 3: audit trigger logs sensitive field reads (pseudocode)
-- CREATE TRIGGER audit_salary AFTER SELECT ON employees ...

Controllo rapido

Quale istruzione SQL concede correttamente al ruolo hr_viewer la possibilità di leggere solo le colonne name e department della tabella employees?

Riepilogo: autorizzazioni a livello di colonna

Le autorizzazioni a livello di colonna consentono di limitare l'accesso a singoli campi anziché a intere tabelle, mantenendo nascosti da ruoli privi dei privilegi dati sensibili come stipendi, SSN e hash delle password.

Punti chiave:

Usare GRANT SELECT (col1, col2) ON table TO role per limitare le colonne leggibili.
Usare REVOKE con un elenco di colonne per rimuovere l'accesso a colonne specifiche.
Le viste sono un'alternativa portabile che funziona in tutti i database.
Combinare le autorizzazioni a livello di colonna con RLS per ottenere un controllo degli accessi a due dimensioni.
Le funzioni SECURITY DEFINER forniscono un filtraggio programmatico a livello di colonna con logica aggiuntiva.

Se applicata in modo coerente, la sicurezza a livello di colonna è uno dei modi più semplici ed efficaci per applicare il principio del privilegio minimo a livello di dati.

Domande Frequenti

La lezione «Permessi a livello di colonna» è gratuita?

Sì — il testo completo di «Permessi a livello di colonna» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Academy, passa a CoddyKit PRO. Il corso SQL Academy include 4 lezioni in totale.

Cosa imparerò in «Permessi a livello di colonna»?

Nasconda le colonne sensibili Eserciti SQL Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare SQL Academy?

Non è richiesta alcuna esperienza precedente. SQL Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Permessi a livello di colonna»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione SQL Academy?

Sì. Ogni lezione SQL Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a SQL Academy