Ruolo PUBLIC in Oracle

I ruoli rendono più semplice concedere e revocare i privilegi agli utenti di un database relazionale. Invece di gestire i privilegi per ogni utente singolarmente, si gestiscono i privilegi per ogni ruolo e tutte le modifiche si applicano a tutti gli utenti che sono assegnati a quel ruolo. Le organizzazioni spesso creano più ruoli per adattarsi alle loro esigenze uniche.

Tuttavia, la maggior parte dei database include un ruolo predefinito chiamato PUBLIC. In questo blog, spieghiamo cosa significa il ruolo PUBLIC in Oracle e le principali migliori pratiche per utilizzarlo.

Cos'è il ruolo PUBLIC in Oracle?

Il ruolo PUBLIC è un ruolo speciale che ogni utente del database eredita implicitamente al momento della creazione. La documentazione di Oracle 11g specifica che il ruolo PUBLIC è accessibile a tutti gli utenti del database e, di conseguenza, tutti i privilegi e i ruoli concessi al ruolo PUBLIC sono accessibili a ogni utente del database. Sebbene un amministratore possa eseguire un comando per concedere o revocare il ruolo PUBLIC a un determinato utente, tali comandi non hanno alcun effetto pratico; l’utente avrà sempre questo ruolo.

È interessante notare che la vista DBA_ROLES non elenca il ruolo PUBLIC:

      SQL> SELECT * FROM DBA_ROLES WHERE ROLE =’PUBLIC’;

no rows selected
      

Tuttavia, interrogando la tabella SYS.USER$ si nota che PUBLIC esiste ed il suo valore di type# pari a 0 indica che si tratta di un ruolo:

      SQL> SELECT user#, type#, name FROM SYS.USER$ WHERE type# = 0 ORDER BY 1;
      

La natura implicita dell'assegnazione del ruolo PUBLIC a tutti gli utenti del database può essere osservata nel seguente esempio. Concedere il privilegio CONNECT al ruolo PUBLIC permetterà che sia ereditato dal nuovo utente senza che venga concesso esplicitamente.

      SQL> CREATE USER bob IDENTIFIED BY MyPassword;

SQL> conn bob/MyPassword;
      

Migliori pratiche per il ruolo PUBLIC

Il ruolo PUBLIC non dovrebbe essere utilizzato per la gestione dei privilegi degli utenti. In altre parole, non assegnare mai un privilegio o ruolo a PUBLIC a meno che l'intento non sia quello di concedere tali privilegi e ruoli a tutti gli attuali utenti del database e a qualsiasi nuovo utente che potrebbe essere creato in futuro.

Infatti, l'assegnazione di privilegi e ruoli direttamente al ruolo PUBLIC è classificata come una finding dall'Agenzia per i Sistemi Informativi della Difesa (DISA): la guida DISA Security Technical Implementation Guide (STIG) ID vulnerabilità V-61435 afferma che i privilegi di database o di sistema non dovrebbero essere concessi a PUBLIC, e V-61443 afferma che i permessi dei ruoli applicativi non dovrebbero essere assegnati a PUBLIC.

Per comprendere il motivo è necessario un po' di contesto. In un ambiente di database container (CDB) o pluggable database (PDB), esiste il concetto di ruoli comuni e ruoli locali. In un CDB, i ruoli comuni vengono creati nella radice e sono noti a tutti i container attuali e futuri. In un ambiente PDB, i ruoli locali sono specifici per un PDB; possono essere utilizzati solo all'interno del PDB in cui sono definiti.

Tuttavia, in un ambiente Oracle multi-tenant, i ruoli sono un po' più complicati. Per impostazione predefinita, tutti i privilegi che Oracle concede al ruolo PUBLIC vengono concessi localmente e in comune. Secondo Oracle, i privilegi non dovrebbero mai essere concessi al ruolo PUBLIC in modo comune. In altre parole, non concedere mai alcun tipo di privilegio al ruolo PUBLIC nella root o nel CDB. Sebbene sia possibile modificare il ruolo PUBLIC all'interno di ogni CDB separatamente, ciò non è consigliato a meno che non sia necessario.

Qualsiasi privilegio concesso agli utenti per il ruolo PUBLIC può essere revocato senza conseguenze negative. Tuttavia, si dovrebbe prestare attenzione quando si revocano i privilegi predefiniti concessi al ruolo PUBLIC come parte della creazione del database, poiché tali privilegi potrebbero essere riconcessi durante un futuro aggiornamento o processo di patch.

Per assistenza nell'elencazione di tutti i ruoli e privilegi Oracle, inclusi quelli del ruolo PUBLIC, prendi in considerazione l'investimento in una soluzione di terze parti come Netwrix StealthAUDIT, che può generare rapporti dettagliati sui diritti di accesso chiavi in mano.