Condividi tramite

Sicurezza in Database di Azure per PostgreSQL - Server flessibile

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Sono disponibili più livelli di sicurezza per proteggere i dati nell'istanza del Server flessibile di Database di Azure per PostgreSQL. Questo articolo descrive queste opzioni di sicurezza.

Poiché le organizzazioni fanno sempre più affidamento sui dati archiviati nei database nel prendere decisioni critiche che determinano un vantaggio competitivo, la necessità di misure di sicurezza solide per i database non è mai stata tanto importante. Un errore di sicurezza può causare conseguenze irreversibili, tra cui l'esposizione di dati riservati, causando danni alla reputazione all'organizzazione.

Crittografia e protezione delle informazioni

Database di Azure per PostgreSQL - Server flessibile crittografa i dati in due modi:

  • Dati in movimento: Database di Azure per PostgreSQL - Server Flessibile crittografa i dati in movimento con Secure Sockets Layer e Transport Layer Security (SSL/TLS). La crittografia viene applicata per impostazione predefinita. Per informazioni più dettagliate sulla sicurezza delle connessioni con SSL\TLS, vedere questa documentazione. Per una maggiore sicurezza, è possibile scegliere di abilitare l'autenticazione SCRAM in Database di Azure per PostgreSQL - Server flessibile.

    Sebbene sia altamente sconsigliato, se necessario a causa dell'incompatibilità del client legacy, è possibile disabilitare TLS\SSL per connessioni a Database di Azure per PostgreSQL - Server flessibile aggiornando il parametro del server require_secure_transport su OFF. È possibile impostare la versione di TLS anche impostando i parametri del server ssl_max_protocol_version.

  • Dati inattivi: per la crittografia di archiviazione, Database di Azure per PostgreSQL - Server flessibile usa il modulo di crittografia convalidato FIPS 140-2. I dati, inclusi i backup e i file temporanei creati durante l'esecuzione delle query, vengono crittografati su disco.

    Il servizio usa la crittografia AES a 256 bit inclusa nella crittografia di archiviazione di Azure e le chiavi vengono gestite dal sistema. È simile ad altre tecnologie di crittografia dei dati inattivi, ad esempio Transparent Data Encryption nei database Oracle o SQL Server. La crittografia dell'archiviazione è sempre attiva e non può essere disabilitata.

Sicurezza di rete

Quando è in esecuzione Database di Azure per PostgreSQL - Server flessibile, sono disponibili due opzioni di rete principali:

  • Accesso privato: è possibile distribuire il server in una rete virtuale di Azure. Le reti virtuali di Azure forniscono comunicazioni di rete private e sicure. Le risorse di una rete virtuale possono comunicare tramite indirizzi IP privati. Per ulteriori informazioni, vedere la panoramica della rete per Database di Azure per PostgreSQL - Server flessibile.

    Le regole di sicurezza dei gruppi di sicurezza di rete consentono di filtrare il tipo di traffico di rete consentito in ingresso e in uscita dalle subnet della rete virtuale e dalle interfacce di rete. Per altre informazioni, vedere la panoramica dei gruppi di sicurezza di rete.

  • Accesso pubblico: è possibile accedere al server tramite un endpoint pubblico. L'endpoint pubblico è un indirizzo DNS risolvibile pubblicamente. L'accesso ad esso è protetto tramite un firewall che blocca tutte le connessioni per impostazione predefinita.

    Le regole del firewall IP concedono l'accesso ai server in base all'indirizzo IP di origine di ogni richiesta. Per altre informazioni, vedere la panoramica delle regole del firewall.

Supporto di Microsoft Defender per il cloud

Microsoft Defender per i database relazionali open source rileva le attività anomale che indicano tentativi di accesso o exploit dei database insoliti e potenzialmente dannosi. Defender per il cloud fornisce avvisi di sicurezza sulle attività anomale in modo da poter rilevare potenziali minacce e rispondere ad esse man mano che si verificano. Quando si abilita questo piano, Defender per il cloud fornisce avvisi quando rileva accessi al database e modelli di query anomali e attività del database sospette.

Questi avvisi vengono visualizzati nella pagina degli avvisi di sicurezza di Defender per il cloud e includono:

  • Dettagli dell'attività sospetta che li ha attivati
  • La tattica MITRE ATT&CK associata
  • Azioni consigliate per l'analisi e la mitigazione della minaccia
  • Opzioni per continuare le indagini con Microsoft Sentinel

Microsoft Defender per il cloud e attacchi di forza bruta

Un attacco di forza bruta è tra i metodi di hacking più comuni e abbastanza efficaci, nonostante sia un metodo di hacking poco sofisticato. La teoria dietro un attacco di questo consiste in: se si impiega un numero infinito di tentativi di indovinare una password, si troverà prima o poi la soluzione corretta. Quando Microsoft Defender per il cloud rileva un attacco di forza bruta, attiva un avviso per informare l'utente che si è verificato un attacco di forza bruta. Può anche separare un semplice attacco di forza bruta da un attacco di forza bruta a un utente valido o un attacco di forza bruta riuscito.

Per ricevere avvisi dal piano di Microsoft Defender, è prima necessario abilitarlo come illustrato nella sezione successiva.

Abilitare la sicurezza avanzata con Microsoft Defender per il cloud

  1. Nel portale di Azure, passare al menu Sicurezza nel riquadro sinistro
  2. Microsoft Defender per il cloud
  3. Nel riquadro di destra, selezionare Abilita.

Screenshot del portale di Azure che mostra come abilitare Cloud Defender.

Nota

Se nel piano di Microsoft Defender è abilitata la funzionalità "database relazionali open source", si noterà che Microsoft Defender è abilitato automaticamente per impostazione predefinita per la risorsa server flessibile di Database di Azure per PostgreSQL.

Gestione degli accessi

Il modo migliore per gestire le autorizzazioni di accesso a Database di Azure per PostgreSQL - Server flessibile 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. È anche possibile concedere l'appartenenza a un ruolo a un altro ruolo, consentendo così al ruolo membro di usare i privilegi assegnati all’altro. Database di Azure per PostgreSQL - Server flessibile consente di fornire autorizzazioni direttamente agli utenti del database. Come procedura di sicurezza consigliata, è indicato creare ruoli con set specifici di autorizzazioni in base ai requisiti minimi di applicazione e accesso. È quindi possibile assegnare i ruoli appropriati a ciascun utente. I ruoli vengono usati per applicare un modello con privilegi minimi per l'accesso ad oggetti di database.

L'istanza del server flessibile di Database di Azure per PostgreSQL viene creata con i tre ruoli predefiniti definiti, oltre a quelli creati da PostgreSQL. Per visualizzare questi ruoli, eseguire il comando:

SELECT rolname FROM pg_roles;

I ruoli sono elencati di seguito:

  • azure_pg_admin
  • azuresu
  • Ruolo amministratore

Durante la creazione di Database di Azure per PostgreSQL - Server flessibile, l'utente inserisce le credenziali per un ruolo di amministratore. Il ruolo di amministratore può essere usato per creare altri ruoli PostgreSQL.

Ad esempio, di seguito è possibile creare un utente/ruolo campione denominato "demouser"


 CREATE USER demouser PASSWORD password123;

Il ruolo di amministratore non deve mai essere usato dall'applicazione.

Negli ambienti PaaS basati sul cloud, l'accesso a Database di Azure per PostgreSQL - Account utente con privilegi avanzati di Server flessibile è limitato a operazioni del piano di controllo solo da operatori cloud. Pertanto, l'account azure_pg_admin esiste come account pseudoutente. 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, la quale elenca tutti i ruoli insieme ai privilegi, ad esempio creare altri ruoli, creare database, replicare e così via.


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

È importante notare che alcune autorizzazioni solo per utente con privilegi avanzati, ad esempio la creazione di determinati cast impliciti coercibili a binarismo, non sono disponibili con Database di Azure per PostgreSQL - Server flessibile, poiché il ruolo azure_pg_admin non è conforme alle autorizzazioni del ruolo utente con privilegi avanzati di PostgreSQL. Un cast coercibile a binarismo è un tipo di cast che non richiede alcuna funzione per eseguire la conversione, poiché i tipi di origine e di destinazione hanno la stessa rappresentazione interna di cast non coercibili a binarismo e le opzioni contenenti IN OUT e WITH FUNCTION sono supportate.

La registrazione di controllo in Database di Azure per PostgreSQL - Server flessibile è disponibile anche con Database di Azure per PostgreSQL - Server flessibile per tenere traccia delle attività nei database.

Controllare l'accesso allo schema

I database appena creati in Database di Azure per PostgreSQL - Server flessibile hanno un set predefinito di privilegi nello schema pubblico del database che consente a tutti gli utenti e ai ruoli del database di creare oggetti. Per limitare più efficacemente l'accesso utente dell'applicazione ai database creati nell'istanza di Database di Azure per PostgreSQL - Server flessibile, è consigliabile revocare questi privilegi pubblici predefiniti. Successivamente, è possibile concedere privilegi specifici per utenti del database in modo più granulare. Ad esempio:

  • Per impedire agli utenti del database dell'applicazione di creare oggetti nello schema pubblico, revocare i privilegi di creazione allo schema public dal ruolo public.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Creare quindi 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 applicazioni

    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 gode di tutti i privilegi nel database di test Test_db, ma non in qualsiasi altro database nel server. È consigliabile, invece di concedere a questo utente\ruolo ALL PRIVILEGES nel database e sui relativi oggetti, fornire autorizzazioni più selettive, ad esempio SELECT, INSERT, EXECUTE e così via. 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 PostgreSQL 15

Da Postgres versione 15, la proprietà dello schema pubblico è stata modificata nel nuovo ruolo di pg_database_owner. Esso consente a ogni proprietario del database di possedere lo schema pubblico del database.
Altre informazioni sono disponibili nelle note sulla versione di PostgreSQL.

Modifiche a PostgreSQL 16 con sicurezza basata su ruoli

Un ruolo del database PostgreSQL può avere molti attributi che ne definiscono i privilegi. Un attributo di questo tipo è CREATEROLE, importante per la gestione di utenti e ruoli del database PostgreSQL. In PostgreSQL 16 sono state introdotte modifiche significative a questo attributo. In PostgreSQL 16, gli utenti con attributo CREATEROLE non hanno più la possibilità di distribuire l'appartenenza ad alcun ruolo ad alcun utente. Invece, come altri utenti senza questo attributo, possono distribuire solo le appartenenze ai ruoli per cui possiedono ADMIN OPTION. Inoltre, in PostgreSQL 16, l'attributo CREATEROLE consente comunque a un utente non autorizzato di effettuare il provisioning di nuovi utenti, ma consente di rimuovere solo utenti da lui stesso creati. Eventuali tentativi di rimuovere utenti che non sono sati creati dall'utente con l'attributo CREATEROLE genereranno un errore.

PostgreSQL 16 ha anche introdotto nuovi ruoli integrati ottimizzati. Il nuovo ruolo pg_use_reserved_connections in PostgreSQL 16 consente l'uso di slot di connessione riservati tramite reserved_connections. Il ruolo pg_create_subscription consente agli utenti con privilegi avanzati di creare sottoscrizioni.

Importante

Database di Azure per PostgreSQL - Server flessibile non permette agli utenti di ricevere l‘attributo pg_write_all_data, il quale consente all'utente di scrivere tutti i dati (tabelle, viste, sequenze) come se si disponesse dei diritti INSERT, UPDATE e DELETE per tali oggetti e dei diritti USAGE per tutti gli schemi, anche senza che ciò venga concesso in modo esplicito. Come soluzione alternativa consigliata per concedere autorizzazioni simili a un livello più limitato per database e oggetto.

Protezione a livello di riga

La sicurezza a livello di riga (RLS) è una funzionalità di sicurezza di Database di Azure per PostgreSQL - Server flessibile che consente agli amministratori di database di definire i criteri per controllare la modalità di visualizzazione e funzionamento di righe di dati specifiche per uno o più ruoli. La sicurezza a livello di riga è un filtro aggiuntivo che è possibile applicare a una tabella di database di Azure per PostgreSQL - Server flessibile, 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 vengono limitati o 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; ciò deve essere specificato per TUTTI i comandi. I casi d'uso per la sicurezza a livello di riga includono implementazioni conformi a PCI, ambienti riservati e hosting condiviso/applicazioni multi-tenant.

Solo gli utenti con diritti SET ROW SECURITY possono applicare diritti di sicurezza delle righe a una tabella. Il proprietario della tabella potrebbe impostare la sicurezza delle righe su una tabella. Come OVERRIDE ROW SECURITY, questo è attualmente un diritto implicito. La sicurezza a livello di riga non esegue l'override delle autorizzazioni GRANT esistenti, ma aggiunge un livello di controllo più granulare. Ad esempio, l'impostazione di ROW SECURITY FOR SELECT per consentire a un determinato utente di assegnare righe concederebbe l'accesso all'utente solo se dispone anche dei privilegi SELECT per la colonna o la tabella in questione.

Di seguito è riportato un esempio che illustra come creare un criterio che garantisca che solo membri del ruolo "manager" creato su misura possano accedere solo alle righe per un account specifico. Il codice nell'esempio seguente è stato 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, assicurandosi che i membri del ruolo manager non possano eseguire operazioni SELECT, DELETE o UPDATE su righe appartenenti ad altri manager e non possano INSERT nuove righe appartenenti a un altro manager. È possibile rimuovere un criterio di sicurezza delle righe usando il comando DROP POLICY, come nell'esempio seguente:



DROP POLICY account_managers ON accounts;

Anche se è possibile che il criterio sia stato rimosso, il gestore dei ruoli non è ancora in grado di visualizzare i dati appartenenti ad altri manager. La ragione di ciò è che i criteri di sicurezza a livello di riga sono ancora abilitati 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 nell'esempio seguente:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Bypassare la Sicurezza a livello di riga

PostgreSQL dispone di autorizzazioni BYPASSRLS e NOBYPASSRLS, le quali possono essere assegnate a un ruolo; NOBYPASSRLS viene assegnato per impostazione predefinita. Con server di cui è stato recentemente effettuato il provisioning in Database di Azure per PostgreSQL - Server flessibile, il bypass dei privilegi di sicurezza a livello di riga (BYPASSRLS) viene implementato come segue:

  • Per server Postgres 16 e versioni successive, viene seguito il comportamento standard di PostgreSQL 16. Gli utenti non amministrativi creati dal ruolo di amministratore azure_pg_admin consentono di creare ruoli con attributo\privilegio BYPASSRLS in base alle esigenze.
  • Per server Postgres 15 e versioni precedenti. È possibile usare l’utente azure_pg_admin per eseguire attività amministrative che richiedono privilegi BYPASSRLS, ma non è possibile creare utenti non amministratori con privilegi BypassRLS, poiché il ruolo di amministratore non ha privilegi di utente con privilegi avanzati, come di norma nei servizi PaaS PostgreSQL basati sul cloud.

Aggiornare password

Per una maggiore sicurezza, è consigliabile cambiare periodicamente la password amministratore e le password degli utenti del database. È consigliabile usare password complesse che contengano maiuscole e minuscole, numeri e caratteri speciali.

Usare SCRAM

Il Salted Challenge Response Authentication Mechanism (SCRAM) migliora notevolmente la sicurezza dell'autenticazione utente basata su password, aggiungendo diverse funzionalità di sicurezza di chiave che impediscono attacchi rainbow-table, man-in-the-middle e a password archiviate, aggiungendo al tempo stesso supporto per più algoritmi hash e password che contengono caratteri non ASCII.

Nell'autenticazione SCRAM, il client partecipa al lavoro di crittografia per produrre la prova di identità. L'autenticazione SCRAM esegue quindi l'offload di parte del costo di calcolo ai client, che nella maggior parte dei casi sono server applicazioni. L'adozione di SCRAM, oltre a un algoritmo hash più avanzato, offre pertanto anche protezione da Distributed Denial of Service (DDoS) contro PostgreSQL, impedendo un overload della CPU del server per calcolare gli hash delle password.

Se il driver client supporta SCRAM, è possibile configurare l'accesso a Database di Azure per PostgreSQL - Server flessibile usando SCRAM come scram-sha-256 invece di md5 predefinito.

Reimpostare la password dell'amministratore

Seguire la guida alla reimpostazione della password amministratore.

Aggiornare la password utente del database

È possibile usare strumenti client per aggiornare le password utente del database.
ad esempio:

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Contenuto correlato