Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La gestione dell'accesso alle risorse di Database di Azure per PostgreSQL è una parte importante della gestione della sicurezza e della conformità. Questo articolo spiega come usare i ruoli di PostgreSQL e le funzionalità di Azure per controllare le autorizzazioni e implementare le procedure consigliate per la gestione dell'accesso.
Gestione dei ruoli
Il modo migliore per gestire le autorizzazioni di accesso al database di Database di Azure per PostgreSQL su larga scala consiste nell'usare il concetto di ruoli. Un ruolo può essere un utente o un gruppo di utenti del database. I ruoli possono possedere oggetti di database e assegnare privilegi su tali oggetti ad altri ruoli per controllare chi possa accedere a determinati oggetti. È possibile concedere l'appartenenza a un ruolo a un altro ruolo per consentire al ruolo membro di usare i privilegi assegnati a un altro ruolo. Database di Azure per PostgreSQL consente di concedere le autorizzazioni direttamente agli utenti del database. Come procedura consigliata per la sicurezza, creare ruoli con set specifici di autorizzazioni in base ai requisiti minimi di applicazione e accesso. Assegnare i ruoli appropriati a ogni utente. Usare i ruoli per applicare un modello con privilegi minimi per l'accesso agli oggetti di database.
Oltre ai ruoli predefiniti creati da PostgreSQL, l'istanza di Database di Azure per PostgreSQL include tre ruoli predefiniti. È possibile visualizzare tali ruoli eseguendo il comando seguente:
SELECT rolname FROM pg_roles;
I ruoli sono:
azure_pg_adminazuresu- Ruolo amministratore
Quando si crea l'istanza di Database di Azure per PostgreSQL, si specificano le credenziali per un ruolo di amministratore. Usare questo ruolo di amministratore per creare altri ruoli PostgreSQL.
Ad esempio, è possibile creare un utente o un ruolo denominato demouser.
CREATE USER demouser PASSWORD password123;
Non usare il ruolo amministratore per l'applicazione.
Negli ambienti PaaS basati sul cloud, l'accesso a un account utente con privilegi avanzati per Database di Azure per PostgreSQL è limitato alle operazioni del piano di controllo solo da parte di operatori cloud. Pertanto, l'account azure_pg_admin esiste come account pseudo-utente con privilegi avanzati. Il ruolo di amministratore è membro del ruolo azure_pg_admin.
Tuttavia, l'account amministratore del server non fa parte del ruolo azuresu, il quale dispone dei privilegi dell’utente con privilegi avanzati e viene usato per eseguire operazioni del piano di controllo. Poiché questo è un servizio PaaS gestito, solo Microsoft fa parte del ruolo utente con privilegi avanzati.
È possibile controllare periodicamente l'elenco dei ruoli nel server.
Ad esempio, è possibile connettersi usando il client psql ed eseguire query sulla tabella pg_roles, che elenca tutti i ruoli insieme ai privilegi, ad esempio creare altri ruoli, creare database, eseguire repliche e altro ancora.
select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname | demouser
rolsuper | f
rolinherit | t
rolcreaterole | f
rolcreatedb | f
rolcanlogin | f
rolreplication | f
rolconnlimit | -1
rolpassword | ********
rolvaliduntil |
rolbypassrls | f
rolconfig |
oid | 24827
Importante
Di recente, Database di Azure per PostgreSQL ha abilitato la possibilità di creare comandi CAST. Per eseguire l'istruzione CAST CREATE, l'utente deve essere membro del gruppo azure_pg_admin. Attualmente non è possibile rimuovere un cast dopo averlo creato.
Database di Azure per PostgreSQL supporta solo i comandi CAST che usano le opzioni WITH FUNCTION e WITH INOUT. L'opzione WITHOUT FUNCTION non è supportata.
La registrazione di controllo in Database di Azure per PostgreSQL per tenere traccia delle attività nei database è disponibile anche in Database di Azure per PostgreSQL.
Controllare l'accesso allo schema
I database appena creati in Database di Azure per PostgreSQL includono un set predefinito di privilegi nello schema pubblico del database che concede a tutti gli utenti e ai ruoli del database la possibilità di creare oggetti. Per limitare meglio l'accesso utente dell'applicazione ai database creati nell'istanza di Database di Azure per PostgreSQL, è consigliabile revocare questi privilegi pubblici predefiniti. Dopo aver revocato questi privilegi, concedere privilegi specifici agli utenti del database in modo più granulare. Per esempio:
Revocare i privilegi di creazione allo schema
publicdal ruolopublicper impedire agli utenti del database dell'applicazione di creare oggetti nello schema pubblico.REVOKE CREATE ON SCHEMA public FROM PUBLIC;Creare un nuovo database .
CREATE DATABASE Test_db;In questo nuovo database, revocare tutti i privilegi allo schema PUBLIC.
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;Creare un ruolo personalizzato per gli utenti del database dell'applicazione.
CREATE ROLE Test_db_user;Concedere agli utenti del database con questo ruolo la possibilità di connettersi al database.
GRANT CONNECT ON DATABASE Test_db TO Test_db_user; GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;Creare un utente del database.
CREATE USER user1 PASSWORD 'Password_to_change'Assegnare il ruolo, con i relativi privilegi di connessione e selezione, all'utente.
GRANT Test_db_user TO user1;
In questo esempio, l'utente user1 può connettersi e disporre di tutti i privilegi nel database di test Test_db, ma non in qualsiasi altro database nel server. Invece di assegnare a questo utente o ruolo ALL PRIVILEGES per tale database e i relativi oggetti, valutare la possibilità di fornire autorizzazioni più selettive, ad esempio SELECT, INSERT, EXECUTE e altre. Per altre informazioni sui privilegi nei database PostgreSQL, vedere i comandi GRANT e REVOKE nella documentazione di PostgreSQL.
Modifiche alla proprietà dello schema pubblico in Database di Azure per PostgreSQL
In PostgreSQL 15 e versioni successive, la proprietà dello schema pubblico è cambiata nel nuovo ruolo pg_database_owner, che consente ai proprietari del database di controllarlo. Per altre informazioni, vedere le note sulla versione di PostgreSQL.
Tuttavia, questa modifica non si applica in Database di Azure per PostgreSQL. Lo schema pubblico è di proprietà del ruolo azure_pg_admin in tutte le versioni di PostgreSQL supportate. Questo comportamento del servizio gestito garantisce sicurezza e coerenza.
Modifiche a PostgreSQL 16 con sicurezza basata su ruoli
In PostgreSQL il ruolo del database può includere molti attributi che ne definiscono i privilegi. Un attributo di questo tipo è l'attributoCREATEROLE, che è importante per la gestione del database PostgreSQL di utenti e ruoli. In PostgreSQL 16 sono state introdotte modifiche significative a questo attributo.
In PostgreSQL 16 gli utenti con l'attributo CREATEROLE non hanno più la possibilità di distribuire l'appartenenza a qualsiasi ruolo a nessuno. Al contrario, come gli altri utenti senza tale attributo, possono assegnare le appartenenze solo ai ruoli per i quali possiedono ADMIN OPTION. Inoltre, in PostgreSQL 16, l'attributo CREATEROLE consente comunque a un utente senza privilegi avanzati di effettuare il provisioning di nuovi utenti. Tuttavia, possono eliminare solo gli utenti creati. I tentativi di eliminazione degli utenti generano un errore quando l'utente non è stato creato da un utente con l'attributo CREATEROLE.
PostgreSQL 16 introduce anche un ruolo predefinito nuovo e migliorato. Il ruolo pg_create_subscription consente agli utenti con privilegi avanzati di creare sottoscrizioni.
Nel server flessibile di Database di Azure per PostgreSQL il ruolo azure_pg_admin è un ruolo con restrizioni gestito dal sistema e non può essere modificato dagli utenti. I tentativi di modificarla, ad esempio assegnandole un altro ruolo, genereranno un errore simile al seguente:
GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"
Si tratta di una protezione predefinita per impedire modifiche ai ruoli amministrativi critici. Se è necessario assegnare privilegi o ruoli, prendere in considerazione la creazione di un ruolo personalizzato e la concessione delle autorizzazioni necessarie a tale ruolo.
Controllo migliorato per azure_pg_admin
In PostgreSQL 16 viene implementata una struttura rigorosa della gerarchia dei ruoli per gli utenti con privilegi CREATEROLE, in particolare per quelli correlati alla concessione dei ruoli. Per migliorare la flessibilità amministrativa e risolvere una limitazione introdotta in PostgreSQL 16, Database di Azure per PostgreSQL migliora le funzionalità del ruolo azure_pg_admin in tutte le versioni di PostgreSQL. Con questo aggiornamento, i membri del ruolo azure_pg_admin possono gestire i ruoli e accedere agli oggetti di proprietà di qualsiasi ruolo non limitato, anche se tali ruoli sono membri di azure_pg_admin. Questo miglioramento garantisce che gli utenti amministratori mantengano un controllo coerente e completo sulla gestione dei ruoli e delle autorizzazioni, offrendo un'esperienza semplice e affidabile senza richiedere l'accesso con privilegi avanzati.
Importante
Database di Azure per PostgreSQL non consente agli utenti di concedere l'attributo pg_write_all_data, che consente all'utente di scrivere tutti i dati (tabelle, visualizzazioni, sequenze), come se si disponesse dei diritti INSERT, UPDATE e DELETE per tali oggetti e i diritti USAGE per tutti gli schemi, anche senza che vengano concessi in modo esplicito. Come soluzione alternativa suggerita, è consigliabile concedere autorizzazioni simili a un livello più limitato per ogni database e oggetto.
Sicurezza a livello di riga
La sicurezza a livello di riga (RLS) è una funzionalità di sicurezza di Database di Azure per PostgreSQL che consente agli amministratori di database di definire i criteri che controllano la modalità di visualizzazione e funzionamento di righe di dati specifiche per uno o più ruoli. La sicurezza a livello di riga aggiunge un filtro aggiuntivo a una tabella di database di Database di Azure per PostgreSQL. Quando un utente tenta di eseguire un'azione su una tabella, questo filtro viene applicato prima dei criteri di query o di altri filtri e i dati si restringono o vengono rifiutati in base ai criteri di sicurezza. È possibile creare criteri di sicurezza a livello di riga per comandi specifici, ad esempio SELECT, INSERT, UPDATE e DELETE o specificarli per tutti i comandi. I casi d'uso per la sicurezza a livello di riga includono implementazioni conformi a PCI, ambienti classificati e hosting condiviso o applicazioni multi-tenant.
Solo gli utenti con diritti SET ROW SECURITY possono applicare diritti di sicurezza a livello di riga a una tabella. Il proprietario della tabella può impostare la sicurezza delle righe in una tabella. Come OVERRIDE ROW SECURITY, questo diritto è attualmente un diritto implicito. La sicurezza a livello di riga non esegue l'override delle autorizzazioni GRANT esistenti. Aggiungere un livello di controllo più granulare. Ad esempio, l'impostazione ROW SECURITY FOR SELECT, per consentire a un determinato utente di accedere solo alle righe, concede tale accesso all'utente solo se l'utente dispone anche dei privilegi SELECT per la colonna o la tabella in questione.
Nell'esempio seguente viene spiegato come creare un criterio che garantisca che solo i membri del ruolomanager personalizzato creato possano accedere solo alle righe per un account specifico. Il codice nell'esempio seguente viene condiviso nella documentazione di PostgreSQL.
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers
USING (manager = current_user);
La clausola USING aggiunge in modo implicito una clausola WITH CHECK, che assicura che i membri del ruolo manager non possano eseguire operazioni SELECT, DELETE o UPDATE su righe appartenenti ad altri manager e che non possano INSERT nuove righe appartenenti a un altro manager.
È possibile eliminare un criterio di sicurezza a livello di riga usando il comando DROP POLICY, come illustrato in questo esempio:
DROP POLICY account_managers ON accounts;
Anche se è possibile rimuovere i criteri, il manager dei ruoli non può ancora visualizzare i dati appartenenti ad altri manager. Questa restrizione esiste perché il criterio di sicurezza a livello di riga è ancora abilitato nella tabella degli account. Se la sicurezza a livello di riga è abilitata per impostazione predefinita, PostgreSQL usa un criterio rifiuto predefinito.
È possibile disabilitare la sicurezza a livello di riga, come illustrato nell'esempio seguente:
ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;
Ignorare la sicurezza a livello di riga
PostgreSQL dispone di autorizzazioni BYPASSRLS e NOBYPASSRLS, che è possibile assegnare a un ruolo. NOBYPASSRLS viene assegnato per impostazione predefinita. Con i server di cui è stato appena effettuato il provisioning in Database di Azure per PostgreSQL, l'esclusione dei privilegi di sicurezza a livello di riga (BYPASSRLS) viene implementata come segue:
Per i server Postgres 16 e versioni successive, viene seguito il comportamento di PostgreSQL 16 standard. Gli utenti non amministrativi creati dal ruolo di amministratore azure_pg_admin consentono di creare ruoli con l'attributo o il privilegio BYPASSRLS in base alle esigenze.
Per i server Postgres 15 e versioni precedenti, è possibile usare l'utente azure_pg_admin per eseguire attività amministrative che richiedono il privilegio BYPASSRLS. Tuttavia, non è possibile creare utenti non amministratori con il privilegio BypassRLS, poiché il ruolo di amministratore non dispone di privilegi di utente con privilegi avanzati, cosa comune nei servizi PaaS PostgreSQL basati sul cloud.