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 modalità Galois/Counter Mode (GCM) con crittografia AES a 256 bit inclusa nella crittografia di archiviazione di Azure e le chiavi sono 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

Recentemente è stata abilitata la possibilità di creare comandi CAST nel Server Flessibile di Database di Azure per PostgreSQL. Per eseguire l'istruzione CREATE CAST, l'utente deve essere membro del gruppo azure_pg_admin . In altre parole, non è attualmente possibile eliminare un CAST dopo la creazione.

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

Supporto di Criteri di Azure

Criteri di Azure è un servizio che consente di applicare gli standard aziendali e di valutare la conformità su larga scala. Il dashboard di conformità fornisce una visualizzazione aggregata per valutare lo stato complessivo dell'ambiente, con la possibilità di eseguire il drill-down con granularità per risorsa e per criterio. Consente inoltre di ottenere la conformità delle risorse tramite la correzione in blocco per le risorse esistenti e la correzione automatica per le nuove risorse.

Definizioni di criteri predefiniti

I criteri predefiniti vengono sviluppati e testati da Microsoft, assicurandosi che soddisfino standard e procedure consigliate comuni, una distribuzione rapida senza la necessità di una configurazione aggiuntiva, rendendoli ideali per i requisiti di conformità standard. I criteri predefiniti spesso riguardano standard e framework di conformità ampiamente riconosciuti.

La sezione seguente fornisce un indice delle definizioni di criteri predefiniti di Criteri di Azure per il server flessibile di Database di Azure per PostgreSQL. Usare il collegamento nella colonna Origine per visualizzare l'origine nel repository GitHub di Criteri di Azure.

Nome (portale di Azure) Descrizione Effetti Versione (GitHub)
È necessario effettuare il provisioning di un amministratore di Microsoft Entra per i server flessibili PostgreSQL Controllare il provisioning di un amministratore di Microsoft Entra per il server flessibile PostgreSQL per abilitare l'autenticazione di Microsoft Entra. L'autenticazione di Microsoft Entra consente una gestione semplificata delle autorizzazioni e una gestione centralizzata delle identità di utenti di database e di altri servizi Microsoft AuditIfNotExists, Disabled 1.0.0
Il controllo con PgAudit deve essere abilitato per i server flessibili PostgreSQL Questo criterio consente di controllare tutti i server flessibili PostgreSQL nell'ambiente che non è abilitato per l'uso di pgaudit. AuditIfNotExists, Disabled 1.0.0
La limitazione delle connessioni per i server flessibili PostgreSQL deve essere abilitata Questo criterio consente di controllare tutti i server flessibili PostgreSQL nell'ambiente senza la limitazione della connessione abilitata. Questa impostazione abilita la limitazione delle connessioni temporanea per indirizzo IP nel caso di un numero eccessivo di errori di accesso con password non valida AuditIfNotExists, Disabled 1.0.0
Distribuire le impostazioni di diagnostica per i server flessibili PostgreSQL nell'area di lavoro Log Analytics Distribuisce le impostazioni di diagnostica per i server flessibili PostgreSQL per lo streaming in un'area di lavoro Log Analytics a livello di area quando vengono creati o aggiornati i server flessibili PostgreSQL, che non dispone di questa impostazione di diagnostica DeployIfNotExists, Disabled 1.0.0
L'impostazione di registrazione delle disconnessioni deve essere abilitata per i server flessibili PostgreSQL Questo criterio consente di controllare i server flessibili PostgreSQL nell'ambiente corrente in cui l'impostazione log_disconnections non è abilitata AuditIfNotExists, Disabled 1.0.0
Il criterio Imponi connessione SSL deve essere abilitato per i server di server flessibili PostgreSQL Il database di Azure per PostgreSQL supporta la connessione del server flessibile di database di Azure per PostgreSQL alle applicazioni client tramite SSL (Secure Sockets Layer). L'imposizione di connessioni SSL tra il server flessibile di database e le applicazioni client garantisce la protezione da attacchi 'man in the middle' tramite la crittografia del flusso di dati tra il server e l'applicazione. Questa configurazione impone che SSL sia sempre abilitato per l'accesso al server flessibile PostgreSQL AuditIfNotExists, Disabled 1.0.0
Il backup con ridondanza geografica deve essere abilitato per i server flessibili di Azure per PostgreSQL I server flessibili di Database di Azure per PostgreSQL consentono di scegliere l'opzione di ridondanza per il server di database. Può essere impostato sull'archiviazione di backup con ridondanza geografica in cui i dati non solo vengono archiviati all'interno dell'area in cui è ospitato il server, ma vengono anche replicati in un'area associata per fornire un'opzione di ripristino in caso di errore di un'area. La configurazione dell'archiviazione con ridondanza geografica per il backup è consentita solo durante la creazione del server Audit, Disabled 1.0.0
L'impostazione di registrazione dei punti di controllo deve essere abilitata per i server flessibili di PostgreSQL Questo criterio consente di controllare i server flessibili di PostgreSQL nell'ambiente corrente in cui l'impostazione log_checkpoints non è abilitata AuditIfNotExists, Disabled 1.0.0
L'impostazione di registrazione delle connessioni deve essere abilitata per i server flessibili di PostgreSQL Questo criterio consente di controllare i server flessibili di PostgreSQL nell'ambiente corrente in cui l'impostazione log_connections non è abilitata AuditIfNotExists, Disabled 1.0.0
I server flessibili di PostgreSQL devono usare chiavi gestite dal cliente per crittografare i dati inattivi Usare le chiavi gestite dal cliente per gestire la crittografia dei dati inattivi dei server flessibili PostgreSQL. Per impostazione predefinita, i dati sono crittografati quando inattivi con chiavi gestite dal servizio, ma le chiavi gestite dal cliente sono comunemente richieste per soddisfare gli standard di conformità alle normative. Le chiavi gestite dal cliente consentono di crittografare i dati con una chiave di Azure Key Vault creata dall'utente e di sua proprietà. L'utente dispone del controllo completo e della piena responsabilità in merito al ciclo di vita della chiave, incluse le operazioni di rotazione e gestione Audit, Deny, Disabled 1.0.0
I server flessibili PostgreSQL devono eseguire TLS versione 1.2 o successiva Questo criterio consente di controllare tutti i server flessibili PostgreSQL nell'ambiente in esecuzione con la versione TLS precedente alla 1.2 AuditIfNotExists, Disabled 1.0.0
L'endpoint privato deve essere abilitato per i server flessibili PostgreSQL Le connessioni endpoint privato impongono una comunicazione sicura tramite l'abilitazione della connettività privata al database di Azure per PostgreSQL. Configurare una connessione endpoint privato per consentire l'accesso al traffico proveniente solo da reti note e impedire l'accesso da tutti gli altri indirizzi IP, inclusi quelli all'interno di Azure AuditIfNotExists, Disabled 1.0.0

Definizioni di criteri personalizzati

I criteri personalizzati possono essere personalizzati in modo preciso in base ai requisiti specifici dell'organizzazione, inclusi criteri di sicurezza univoci o obblighi di conformità. Con i criteri personalizzati è possibile controllare completamente la logica e i parametri dei criteri, consentendo definizioni di criteri sofisticate e con granularità fine.

Contenuto correlato