Gestione degli accessi in Azure HorizonDB (anteprima)

La gestione dell'accesso al Azure HorizonDB è 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 Azure autorizzazioni di accesso al database HorizonDB su larga scala consiste nell'usare il concetto di roles. 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. Azure HorizonDB 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, il cluster Azure HorizonDB include tre ruoli predefiniti. È possibile visualizzare tali ruoli eseguendo il comando seguente:

SELECT rolname FROM pg_roles;

I ruoli sono:

  • azure_pg_admin
  • azuresu
  • administrator role

Quando si crea il cluster Azure HorizonDB, si specificano le credenziali per un oggetto administrator role. Usare questa opzione administrator role per creare altri ruoli PostgreSQL.

Ad esempio, è possibile creare un utente o un ruolo denominato exampleuser.

CREATE USER exampleuser 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 di HorizonDB Azure è limitato solo alle operazioni del piano di controllo. Il ruolo azuresu dispone di privilegi avanzati per l'utente, ma l'account amministratore del cluster Azure HorizonDB non fa parte del ruolo di amministratore del cluster azuresu.

Il ruolo azure_pg_admin esiste come account pseudo-superutente. L'account di accesso amministratore configurato durante la creazione del cluster è un membro del azure_pg_admin ruolo.

È possibile controllare periodicamente l'elenco dei ruoli nel cluster.

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

Azure HorizonDB consente di creare comandi CAST. Per eseguire l'istruzione CREATE CAST , l'utente deve essere membro del azure_pg_admin ruolo. Attualmente non è possibile rimuovere un cast dopo averlo creato.

Azure HorizonDB supporta solo i comandi CAST che usano le opzioni WITH FUNCTION e WITH INOUT. L'opzione WITHOUT FUNCTION non è supportata.

Controllare l'accesso allo schema

I database appena creati in Azure HorizonDB 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 Azure HorizonDB, è 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 public schema dal public ruolo per 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, user user1 può connettersi e disporre di tutti i privilegi nel database di test Test_db, ma non di qualsiasi altro database nel cluster. 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 Azure HorizonDB

In Azure HorizonDB lo schema pubblico è di proprietà del ruolo azure_pg_admin in tutte le versioni di PostgreSQL supportate.

Controllo migliorato per azure_pg_admin

In Azure HorizonDB il azure_pg_admin ruolo è un ruolo con restrizioni gestito dal sistema che non è possibile modificare. Se si tenta di modificarlo, ad esempio concedendole un altro ruolo, viene visualizzato un errore simile al seguente:

GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

Questa restrizione è 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.

Azure HorizonDB migliora le funzionalità del azure_pg_admin ruolo in tutte le versioni di PostgreSQL. I membri del azure_pg_admin ruolo possono gestire i ruoli e accedere agli oggetti di proprietà di qualsiasi ruolo senza restrizioni, anche se tali ruoli sono membri di azure_pg_admin. Questa funzionalità 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

Azure HorizonDB non consente che agli utenti venga concesso l'attributo pg_write_all_data, che permette all'utente di modificare tutti i dati (tabelle, viste, sequenze), come se disponesse dei diritti INSERT, UPDATE e DELETE su tali oggetti e dei diritti USAGE su tutti gli schemi, anche senza una concessione esplicita. Come soluzione alternativa consigliata, concedere autorizzazioni simili a un livello più granulare per ogni database e oggetto.

Sicurezza a livello di riga

Sicurezza a livello di riga (RLS) è una funzionalità di sicurezza Azure HorizonDB che consente agli amministratori di database di definire 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 Azure HorizonDB. 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 include le autorizzazioni BYPASSRLS e NOBYPASSRLS che è possibile assegnare a un ruolo. Per impostazione predefinita, viene assegnata l'autorizzazione NOBYPASSRLS . In Azure HorizonDB, il privilegio di sicurezza a livello di riga bypass (BYPASSRLS) funziona come segue:

  • Gli utenti non amministrativi creati dal azure_pg_admin ruolo di amministratore possono creare ruoli con l'attributo o il BYPASSRLS privilegio in base alle esigenze.

  • Usare l'utente azure_pg_admin per eseguire attività amministrative che richiedono il BYPASSRLS privilegio .

Contenuti correlati

  • Last updated on