Sicurezza in Database di Azure per PostgreSQL - Server flessibile

Articolo
04/19/2024

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 Database di Azure per PostgreSQL. Questo articolo descrive queste opzioni di sicurezza.

Crittografia e protezione delle informazioni

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

Dati in transito: Database di Azure per PostgreSQL - Server flessibile crittografa i dati in transito 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 non sia consigliabile, se necessario, a causa dell'incompatibilità del client legacy, è possibile disabilitare TLS\SSL per le connessioni a Database di Azure per PostgreSQL - Server flessibile aggiornando il parametro del require_secure_transport server su OFF. È anche possibile impostare la versione TLS impostando ssl_max_protocol_version i parametri del server.
Dati inattivi: per la crittografia dell'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 altre informazioni, vedere 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 a è 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 Microsoft Defender per il cloud

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

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
Tattiche MITRE ATT&CK associate
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 tipo è che, se si prende un numero infinito di tentativi di indovinare una password, si è vincolati a essere corretti alla fine. 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

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

Nota

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

Gestione degli accessi

Il modo migliore per gestire Database di Azure per PostgreSQL - Autorizzazioni di accesso al database del server flessibile su larga scala consiste nell'usare il concetto di ruoli. Un ruolo può essere un utente del database o un gruppo di utenti del database. I ruoli possono possedere gli oggetti di database e assegnare privilegi a tali oggetti ad altri ruoli per controllare chi può accedere agli oggetti. È anche possibile concedere l'appartenenza a un ruolo a un altro ruolo, consentendo così al ruolo membro di usare i privilegi assegnati a un altro ruolo. Database di Azure per PostgreSQL - Server flessibile consente di concedere le autorizzazioni direttamente agli utenti del database. Come procedura di sicurezza consigliata, è consigliabile creare ruoli con set specifici di autorizzazioni in base ai requisiti minimi di applicazione e accesso. È quindi possibile assegnare i ruoli appropriati a ogni utente. I ruoli vengono usati per applicare un modello con privilegi minimi per l'accesso agli oggetti di database.

L'istanza del server flessibile Database di Azure per PostgreSQL viene creata con i tre ruoli predefiniti definiti. È possibile visualizzare questi ruoli eseguendo il comando :

SELECT rolname FROM pg_roles;

azure_pg_admin
azuresu
ruolo amministratore

Durante la creazione dell'istanza del server flessibile Database di Azure per PostgreSQL, è possibile specificare 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 di esempio denominato demouser,

postgres=> 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 un account superutente server flessibile Database di Azure per PostgreSQL è limitato alle 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 azure_pg_admin ruolo.
Tuttavia, l'account amministratore del server non fa parte del azuresu ruolo, che dispone di privilegi con privilegi avanzati e viene usato per eseguire operazioni del piano di controllo. Poiché questo servizio è un servizio PaaS gestito, solo Microsoft fa parte del ruolo di utente con privilegi avanzati.

Nota

Il numero di autorizzazioni solo per l'utente con privilegi avanzati, ad esempio la creazione di determinati cast impliciti, non è disponibile con Database di Azure per PostgreSQL - Server flessibile, perché azure_pg_admin il ruolo non è allineato alle autorizzazioni del ruolo utente con privilegi avanzati di PostgreSQL.

È possibile controllare periodicamente l'elenco dei ruoli nel server. Ad esempio, è possibile connettersi usando psql il client ed eseguire una query sulla pg_roles tabella che elenca tutti i ruoli insieme ai privilegi, ad esempio creare ruoli aggiuntivi, creare database, replica e così via.

postgres=> \x
Expanded display is on.
postgres=> 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

Registrazione di controllo in Database di Azure per PostgreSQL : il 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 - Il server flessibile dispone di 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 meglio l'accesso utente dell'applicazione ai database creati nell'istanza del server flessibile Database di Azure per PostgreSQL, è consigliabile revocare questi privilegi pubblici predefiniti. Successivamente, è possibile concedere privilegi specifici per gli 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 public schema dal public ruolo.
```
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
```
Creare quindi un nuovo database.
```
CREATE DATABASE Test_db;
```
Revocare tutti i privilegi dallo schema PUBLIC in questo nuovo database.
```
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 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 la connessione e selezionare i privilegi per l'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 qualsiasi altro database nel server. È consigliabile, invece di assegnare a questo utente\ruolo ALL PRIVILEGES su tale database e ai relativi oggetti, per fornire autorizzazioni più selettive, ad esempio edizione Standard LECT,IN edizione Standard RT, EXECUTE e così via. Per altre informazioni sui privilegi nei database PostgreSQL, vedere i comandi GRANT e REVOKE nella documentazione di PostgreSQL.

Modifiche di PostgreSQL 16 con sicurezza basata sui ruoli

Nel ruolo del database PostgreSQL possono avere molti attributi che ne definiscono i privilegi. Un attributo di questo tipo è l'attributo CREATEROLE, 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 attributo CREATEROLE non hanno più la possibilità di distribuire l'appartenenza a nessun ruolo a nessuno. 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 può eliminare solo gli utenti creati. I tentativi di eliminare gli utenti, che non vengono creati dall'utente con l'attributo CREATEROLE , genereranno un errore.

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

Protezione a livello di riga

La sicurezza a livello di riga (RLS) è una funzionalità di sicurezza server flessibile Database di Azure per PostgreSQL che consente agli amministratori di database di definire i criteri per controllare la visualizzazione e il 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 server flessibile 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 vengono limitati o rifiutati in base ai criteri di sicurezza. È possibile creare criteri di sicurezza a livello di riga per comandi specifici, ad esempio edizione Standard LECT, IN edizione Standard RT, UPDATE e DELETE, specificarlo 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/applicazioni multi-tenant.

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

Di seguito è riportato un esempio che illustra come creare un criterio che garantisce che solo i membri del ruolo "manager" creato personalizzato 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 WITH CHECK clausola, assicurandosi che i membri del ruolo di manager non possano eseguire SELECToperazioni , DELETEo UPDATE su righe appartenenti ad altri manager e non INSERT possano creare nuove righe appartenenti a un altro manager. È possibile eliminare un criterio di sicurezza delle righe usando il comando DROP POLICY , come nell'esempio seguente:



DROP POLICY account_managers ON accounts;

Anche se il criterio potrebbe essere stato eliminato, il responsabile dei ruoli non è ancora in grado di visualizzare i dati appartenenti ad altri manager. Questo perché 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 di negazione predefinito. È possibile disabilitare la sicurezza a livello di riga, come nell'esempio seguente:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Bypass della sicurezza a livello di riga

PostgreSQL dispone di autorizzazioni BYPASSRLS e NOBYPASSRLS , che possono essere assegnate 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 - Il server flessibile ignora i privilegi di sicurezza a livello di riga (BYPASSRLS) viene implementato come segue:

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

Aggiornare le password

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

Usare SCRAM

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

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

Reimpostare la password dell'amministratore

Seguire la guida alla reimpostazione della password amministratore.

Aggiornare la password utente del database

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

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE