Condividi tramite

Proteggere il server Database di Azure per PostgreSQL

Database di Azure per PostgreSQL è un servizio di database completamente gestito che offre funzionalità predefinite di disponibilità elevata, backup automatizzati e scalabilità. La protezione delle distribuzioni di database PostgreSQL è fondamentale per proteggere i dati sensibili e mantenere la conformità agli standard di settore.

Questo articolo illustra come proteggere la distribuzione del server di Database di Azure per PostgreSQL.

Importante

A partire dal 11 novembre 2025, le aree di Azure nell'elenco seguente sono pianificate per una rotazione dei certificati TLS/SSL che usa nuovi certificati CA intermedi.

  • Stati Uniti centro-occidentali
  • East Asia
  • UK South

A partire dal 19 gennaio 2026, questa rotazione è pianificata per estendersi a tutte le aree di Azure rimanenti, tra cui Azure per enti pubblici e tutte le altre aree.

Per informazioni sulla risoluzione dei problemi, vedere Problemi di associazione del certificato.

Sicurezza della rete

La sezione Sicurezza di rete illustra come impedire l'accesso pubblico e usare le funzionalità di rete per integrare PostgreSQL in un'architettura di rete cloud sicura e segmentata.

  • Disabilitare l'accesso alla rete pubblica: disabilitare l'accesso alla rete pubblica per PostgreSQL per impedire l'esposizione a Internet. Questa azione garantisce che solo le reti attendibili possano accedere al database.

  • Endpoint privati: usare endpoint privati per connettersi in modo sicuro a PostgreSQL dall'interno della rete virtuale.

  • In alternativa, usare l'integrazione della rete virtuale: usare l'integrazione della rete virtuale per connettere PostgreSQL alla rete virtuale. Questa integrazione consente l'accesso sicuro dalle risorse di Azure e dal server alle risorse utilizzate, ad esempio l'intelligenza artificiale.

  • Regole del firewall legacy ed endpoint di servizio: se è necessario consentire l'accesso da indirizzi IP specifici, usare le regole del firewall legacy e gli endpoint di servizio. Tuttavia, questo approccio non è consigliato. È consigliabile preferire invece l'uso di endpoint privati o integrazione di rete virtuale.

Gli articoli sulla sicurezza di rete sono disponibili nelle sezioni di rete:

Gestione delle identità

La sezione Gestione delle identità è incentrata sull'autenticazione, sulla protezione delle identità e sui controlli di accesso usando sistemi centralizzati di gestione delle identità e degli accessi. Vengono illustrate le procedure consigliate, ad esempio meccanismi di autenticazione avanzata e identità gestite per le applicazioni.

Ecco alcuni possibili servizi, funzionalità e procedure consigliate per la sicurezza della Gestione delle identità:

  • Usare Entra anziché l'autenticazione locale del database: è consigliabile non consentire l'autenticazione locale per il server PostgreSQL. Usare invece solo l'autenticazione di Microsoft Entra (non la modalità mista) per gestire l'accesso al database. Microsoft Entra offre l'autenticazione centralizzata con controlli di sicurezza avanzati e Defender per la protezione in tempo reale dell'identità. Per altre informazioni, visitare Microsoft Entra in generale e l'autenticazione di Microsoft Entra con Database di Azure per PostgreSQL.

  • Usare le identità gestite per l'accesso sicuro alle applicazioni: usare le identità gestite in Azure per autenticare in modo sicuro applicazioni e servizi senza la necessità di gestire le credenziali. In questo modo è possibile accedere a risorse come Database di Azure per PostgreSQL in modo sicuro e semplificato. Per altre informazioni, visitare Identità gestite.

  • Applicare la sicurezza tramite i criteri di accesso condizionale: configurare i criteri di accesso condizionale in Microsoft Entra per applicare i controlli di sicurezza in base a utente, posizione o contesto del dispositivo. Questi criteri consentono l'applicazione dinamica dei requisiti di sicurezza in base al rischio, migliorando la postura di sicurezza complessiva. Per altre informazioni, vedere Accesso condizionale di Microsoft Entra.

  • L'autenticazione locale deve usare l'autenticazione SCRAM: se è necessario usare l'autenticazione locale, assicurarsi che vengano applicati criteri password sicuri. Usare i requisiti di complessità delle password ed eseguire regolarmente la rotazione delle password per ridurre al minimo il rischio di account compromessi. Per altre informazioni, visitare Autenticazione SCRAM in Database di Azure per PostgreSQL.

Controllo di accesso

La sezione controllo di accesso è incentrata sulla protezione del livello di accesso in base al principio dei privilegi minimi. Sottolinea il rischio di accesso non autorizzato alle risorse sensibili limitando e gestendo autorizzazioni elevate, applicando l'autenticazione a più fattori e assicurando che le azioni con privilegi vengano registrate e controllate.

Ecco alcuni possibili servizi di sicurezza, funzionalità e procedure consigliate per la sezione controllo di accesso:

  • Usare i ruoli Entra per il controllo di accesso: implementare Controllo degli accessi in base al ruolo (RBAC) per gestire l'accesso alle risorse di Database di Azure per PostgreSQL. Assegnare i ruoli in base al principio dei privilegi minimi, assicurandosi che gli utenti e le applicazioni dispongano solo delle autorizzazioni necessarie. Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Azure (RBAC) in generale e Gestire i ruoli di Microsoft Entra in Database di Azure per PostgreSQL.

  • Seguire le procedure consigliate per Entra: utilizzare MFA, criteri di Accesso condizionale, accesso JIT (just-in-time) per proteggere utenti e database.

  • Gestire utenti, ruoli e autorizzazioni del database locale: usare la gestione dei ruoli predefinita di PostgreSQL per controllare l'accesso a livello di database. Creare ruoli personalizzati con autorizzazioni specifiche per applicare il principio dei privilegi minimi. Rivedere e controllare regolarmente questi ruoli per garantire la conformità ai criteri di sicurezza. Per altre informazioni, vedere Creare utenti in Database di Azure per PostgreSQL.

Protezione dei dati

La sezione relativa alla protezione dei dati è incentrata sulla protezione dei dati inattivi e in transito sensibili. Garantisce che i dati siano crittografati, l'accesso sia controllato e che le informazioni riservate siano protette dall'accesso non autorizzato. Sottolinea l'uso della crittografia, delle connessioni sicure e della maschera dati per proteggere l'integrità e la riservatezza dei dati.

Ecco alcuni possibili servizi di sicurezza, funzionalità e procedure consigliate per la sezione relativa alla protezione dati:

Crittografa i dati in transito

  • Verificare le connessioni TLS: Azure PostgreSQL usa sempre SSL o TLS per crittografare i dati in transito tra l'applicazione e il database. È necessario configurare l'applicazione per verificare il certificato usato, ad esempio la CA radice, i certificati scaduti, la mancata corrispondenza del nome host e la revoca dei certificati. Questa procedura consente di proteggere le informazioni sensibili da attacchi di intercettazione e man-in-the-middle. Per altre informazioni, vedere Proteggere la connettività con TLS e SSL in Database di Azure per PostgreSQL.

  • Assicurarsi che il client abbia installato i certificati TLS più recenti: assicurarsi che le applicazioni client dispongano dei certificati TLS più recenti installati per supportare connessioni sicure. Questa procedura consente di evitare errori di connessione e assicura che l'applicazione possa stabilire connessioni sicure con il server PostgreSQL. Per altre informazioni, vedere Scaricare i certificati CA radice e aggiornare i client dell'applicazione.

  • Richiedere l'uso di TLS 1.3: configurare il server PostgreSQL per richiedere TLS 1.3 per tutte le connessioni. Questa configurazione garantisce che venga usata solo la versione più recente e più sicura del protocollo, garantendo sicurezza e prestazioni migliori. Per altre informazioni, vedere Versioni di TLS.

Crittografia di dati inattivi

  • La crittografia avviene sempre con dati inattivi con SMK: Database di Azure per PostgreSQL crittografa automaticamente i dati inattivi usando chiavi gestite dal servizio (SMK). Questa crittografia garantisce che i dati siano protetti senza richiedere una configurazione aggiuntiva. Si basa sull'infrastruttura di Archiviazione di Azure sottostante. Copre il server primario, le repliche, il ripristino temporizzato (PITR) e i backup. Per altre informazioni, vedere Crittografia dei dati in Database di Azure per PostgreSQL.

  • Usare le chiavi gestite dal cliente per un controllo aggiuntivo: se è necessario un maggiore controllo sulle chiavi di crittografia (CMK), usare le chiavi gestite dal cliente archiviate in Azure Key Vault o in Azure HSM. Questa opzione consente di gestire le chiavi di crittografia e offre più opzioni di sicurezza e conformità. Per altre informazioni, vedere Chiavi gestite dal cliente in Database di Azure per PostgreSQL e Configurare la crittografia dei dati in Database di Azure per PostgreSQL.

  • Configurare la rotazione automatica delle chiavi in KV o HSM gestito: se si usano le chiavi gestite dal cliente, configurare la rotazione automatica delle chiavi in Azure Key Vault per assicurarsi che le chiavi di crittografia vengano aggiornate regolarmente. Database di Azure per PostgreSQL supporta gli aggiornamenti automatici delle versioni delle chiavi dopo la rotazione di una chiave. Per altre informazioni, vedere Configurare l'auto-rotazione delle chiavi in HSM gestito di Azure o Riconoscimento dell'auto-rotazione in Azure Key Vault per altri dettagli su Key Vault. Per altre informazioni, vedere Configurare la crittografia dei dati con la chiave gestita dal cliente durante il provisioning del server per sapere come configurare la rotazione automatica delle chiavi.

  • Crittografare i dati ultra sensibili con la crittografia lato client: per i dati ultra sensibili, è consigliabile implementare la crittografia lato client. Questo approccio prevede la crittografia dei dati prima di inviarli al database, assicurandosi che nel database vengano archiviati solo i dati crittografati. Questa procedura offre un livello di sicurezza maggiore, perché il database stesso, e pertanto l'amministratore del database, non hanno accesso ai dati non crittografati.

Calcolo riservato

Computing riservato di Azure consente alle organizzazioni di elaborare e collaborare in modo sicuro su dati sensibili, ad esempio dati personali o informazioni sanitarie protette. L'ACC offre protezione predefinita da accessi non autorizzati proteggendo i dati in uso tramite ambienti di esecuzione attendibili (TEE).

  • SaaS e provider di hosting considerano la possibilità di configurare l'ambiente di calcolo riservato: se si è software come servizio (SaaS) o un provider di hosting e i carichi di lavoro PostgreSQL comportano l'elaborazione di dati sensibili, è consigliabile usare Computing riservato di Azure per proteggere i dati in uso. Questa soluzione offre un livello di sicurezza maggiore assicurandosi che i dati vengano elaborati in un ambiente sicuro, impedendo l'accesso non autorizzato anche agli utenti con privilegi. Per altre informazioni, vedere Computing riservato di Azure per Database di Azure per PostgreSQL per altri dettagli.

Maschera dati e offuscamento

  • Implementare la maschera dati: utilizzare lo strumento per la navigazione in anonimato di PostgreSQL per supportare:

  • Dump anonimi: esportare i dati mascherati in un file SQL.

  • Maschera statica: rimuovere i dati personali in base alle regole.

  • Maschera dinamica: nasconde i dati personali solo per gli utenti mascherati.

  • Maschera visualizzazioni: consente di creare visualizzazioni dedicate per gli utenti mascherati.

  • Mascheramento dei wrapper dati: applicare regole di maschera ai dati esterni.

Registrazione e rilevamento delle minacce

La sezione relativa alla registrazione e al rilevamento delle minacce illustra i controlli per rilevare le minacce negli ambienti Azure. Vengono illustrati l'abilitazione, la raccolta e l'archiviazione dei log di controllo per i servizi di Azure. Sottolinea l'uso delle funzionalità di rilevamento delle minacce native, la gestione centralizzata dei log e la conservazione dei log appropriata per le indagini e la conformità della sicurezza. Questa sezione è incentrata sulla generazione di avvisi di alta qualità, centralizzando l'analisi della sicurezza tramite gli strumenti di Azure, mantenendo la gestione accurata della sincronizzazione del time e sulla garanzia di strategie di conservazione dei log efficaci.

Ecco alcuni possibili servizi di sicurezza, funzionalità e procedure consigliate per la sezione di registrazione e rilevamento delle minacce:

Backup e ripristino

La sezione relativa al backup e al ripristino è incentrata sulla garanzia che i dati e le configurazioni nei servizi di Azure vengano sottoposti regolarmente a backup, protetti e ripristinabili in caso di errori o emergenze. Sottolinea l'automazione dei backup, la protezione dei dati di backup e la garanzia che i processi di ripristino vengano testati e convalidati per soddisfare gli obiettivi del tempo di ripristino (RTO) e gli obiettivi del punto di ripristino (RPO). La sezione evidenzia anche l'importanza del monitoraggio e del controllo dei processi di backup per garantire la conformità e la conformità. Per una panoramica, vedere Panoramica della continuità aziendale con Database di Azure per PostgreSQL.

Ecco alcuni possibili servizi di sicurezza, funzionalità e procedure consigliate per la sezione relativa al rilevamento di backup e ripristino:

  • Usare la disponibilità elevata: implementare configurazioni a disponibilità elevata per l'istanza del server flessibile PostgreSQL per ridurre al minimo i tempi di inattività e garantire l'accesso continuo al database. Per altre informazioni, vedere Disponibilità elevata (affidabilità) in Database di Azure per PostgreSQL e Configurare la disponibilità elevata.

  • Configurare i backup automatizzati: Database di Azure per PostgreSQL esegue automaticamente backup giornalieri dei file di database e esegue continuamente il backup dei log delle transazioni. È possibile conservare i backup da sette fino a 35 giorni. È possibile ripristinare il server di database in qualsiasi momento entro il periodo di conservazione dei backup. L'obiettivo RTO dipende dalle dimensioni dei dati da ripristinare e dal tempo necessario per eseguire il ripristino del log. Può variare da pochi minuti fino a 12 ore. Per altre informazioni, vedere Backup e ripristino in Database di Azure per PostgreSQL.

  • Configurare le repliche in lettura: usare le repliche in lettura per eseguire l'offload delle operazioni di lettura dal server primario, migliorando le prestazioni e la disponibilità. È anche possibile usare le repliche in lettura per gli scenari di ripristino di emergenza, consentendo di passare rapidamente a una replica con un errore del server primario. Per altre informazioni, vedere Repliche in lettura in Database di Azure per PostgreSQL.

  • Proteggere i dati di backup con la crittografia della chiave gestita dal cliente: proteggere i dati di backup usando la crittografia dei dati inattivi.

Contenuti correlati

  • Last updated on