Condividi tramite


Procedure consigliate per la protezione di database PaaS in Azure

Questo articolo illustra una raccolta di database SQL di Azure e procedure consigliate per la sicurezza di Azure Synapse Analytics per proteggere le applicazioni Web e per dispositivi mobili (PaaS) della piattaforma distribuita come servizio. Le procedure consigliate si basano sull'esperienza di tecnici e clienti con Azure.

database SQL di Azure e Azure Synapse Analytics forniscono un servizio di database relazionale per le applicazioni basate su Internet. Verranno ora esaminati i servizi che consentono di proteggere le applicazioni e i dati quando si usano database SQL di Azure e Azure Synapse Analytics in una distribuzione PaaS:

  • Autenticazione di Microsoft Entra (anziché autenticazione di SQL Server)
  • Firewall SQL di Azure
  • Transparent Data Encryption (TDE)

Usare un repository delle identità centralizzato

database SQL di Azure può essere configurato per l'uso di uno dei due tipi di autenticazione:

  • Autenticazione SQL usa nome utente e password. Quando è stato creato il server per il database, è stato specificato un account di accesso "amministratore server" con nome utente e password. Usando queste credenziali, è possibile essere autenticati in qualsiasi database di tale server in qualità di proprietario del database.

  • L'autenticazione di Microsoft Entra usa le identità gestite dall'ID Microsoft Entra ed è supportata per i domini gestiti e integrati. Per usare l'autenticazione di Microsoft Entra, è necessario creare un altro amministratore del server denominato "Microsoft Entra admin", che può amministrare utenti e gruppi di Microsoft Entra. Questo amministratore può eseguire anche tutte le operazioni eseguite da un normale amministratore del server.

L'autenticazione di Microsoft Entra è un meccanismo di connessione a database SQL di Azure e Azure Synapse Analytics usando le identità in Microsoft Entra ID. Microsoft Entra ID offre un'alternativa all'autenticazione di SQL Server in modo da impedire la proliferazione delle identità utente tra server di database. L'autenticazione di Microsoft Entra consente di gestire centralmente le identità degli utenti del database e di altri servizi Microsoft in una posizione centrale. La gestione centrale degli ID consente di gestire gli utenti del database da un unico punto e semplifica la gestione delle autorizzazioni.

Vantaggi dell'uso dell'ID Microsoft Entra invece dell'autenticazione SQL

  • Consente la rotazione delle password in un'unica posizione.
  • Gestisce le autorizzazioni del database usando gruppi esterni di Microsoft Entra.
  • Elimina l'archiviazione delle password abilitando autenticazione di Windows integrata e altre forme di autenticazione supportate dall'ID Microsoft Entra.
  • Usa gli utenti di database indipendente per autenticare le identità a livello di database.
  • Supporta l'autenticazione basata su token per le applicazioni che si connettono al database SQL.
  • Supporta la federazione del dominio con Active Directory Federation Services (ADFS) o l'autenticazione nativa dell'utente/password per un ID Microsoft Entra locale senza sincronizzazione del dominio.
  • Supporta le connessioni da SQL Server Management Studio che utilizzano l'autenticazione universale di Active Directory, che include l'autenticazione MFA (Multi-Factor Authentication). L'autenticazione a più fattori include un'autenticazione avanzata con una gamma di opzioni di verifica semplici. Le opzioni di verifica sono chiamate telefoniche, SMS, smart card con pin o notifica dell'app per dispositivi mobili. Per altre informazioni, vedere Autenticazione universale con database SQL e Azure Synapse Analytics.

Per altre informazioni sull'autenticazione di Microsoft Entra, vedere:

Nota

Per garantire che Microsoft Entra ID sia adatto per l'ambiente in uso, vedere Funzionalità e limitazioni di Microsoft Entra.

Limitare l'accesso in base all'indirizzo IP

È possibile creare regole del firewall che specificano gli intervalli di indirizzi IP accettabili. Queste regole possono essere destinate a livello di server e database. È consigliabile usare le regole del firewall a livello di database quando è possibile, allo scopo di migliorare la sicurezza e la portabilità del database. Le regole del firewall a livello di server sono utili per gli amministratori e in presenza di molti molti database che presentano gli stessi requisiti di accesso ma non si vuole dedicare tempo alla configurazione di ogni singolo database.

Le restrizioni predefinite agli indirizzi IP di origine del database SQL consentono l'accesso da qualsiasi indirizzo di Azure, inclusi altri tenant e sottoscrizioni. È possibile modificare le restrizioni per consentire l'accesso all'istanza solo ai propri indirizzi IP. Anche in presenza del firewall SQL e delle restrizioni per gli indirizzi IP, è comunque necessaria un'autenticazione avanzata. Vedere le indicazioni riportate in precedenza in questo articolo.

Per altre informazioni sul firewall SQL di Azure e sulle restrizioni per gli indirizzi IP, vedere:

Crittografare i dati inattivi

La funzionalità Transparent Data Encryption (TDE) è abilitata per impostazione predefinita. TDE crittografa in modo trasparente i file di dati e di log di SQL Server, database SQL di Azure e Azure Synapse Analytics. Questa crittografia consente di proteggere da una violazione di accesso diretto ai file o ai backup. Ciò consente di crittografare i dati inattivi senza modificare le applicazioni esistenti. La funzionalità Transparent Data Encryption deve essere sempre attivata; un malintenzionato potrà comunque eseguire un attacco tramite il percorso di accesso normale. Offre inoltre la possibilità di conformarsi a diverse leggi, normative e linee guida stabilite in vari settori.

Azure SQL gestisce i principali problemi correlati per TDE. Come con TDE, è necessario prestare particolare attenzione al livello locale per garantire la recuperabilità e lo spostamento di database. In scenari più sofisticati, le chiavi possono essere gestite in modo esplicito in Azure Key Vault tramite Extensible Key Management. Vedere Abilitare TDE in SQL Server con EKM. Ciò consente anche l'uso di Bring Your Own Key (BYOK) tramite la capacità BYOK di Azure Key Vault.

Azure SQL fornisce la crittografia per le colonne tramite Always Encrypted. Questa crittografia consente solo alle applicazioni autorizzate l'accesso alle colonne sensibili. L'uso di questo tipo di crittografia limita le query SQL per le colonne crittografate a valori basati sull'uguaglianza.

La crittografia a livello di applicazione deve essere usata anche per dati selettivi. I problemi di sovranità dei dati possono talvolta essere mitigati crittografando i dati con una chiave mantenuta nel paese/area geografica corretta. In questo modo si impedisce anche che un trasferimento accidentale dei dati possa rappresentare un problema, perché è comunque impossibile decrittografarli senza la chiave, presupponendo che venga usato un algoritmo avanzato come AES 256.

È possibile usare diverse precauzioni per proteggere il database, ad esempio la progettazione di un sistema sicuro, la crittografia di risorse riservate e la creazione di un firewall che protegga i server di database.

Passaggi successivi

Questo articolo illustra una raccolta di procedure consigliate per la sicurezza di Database SQL e Azure Synapse Analytics per proteggere le applicazioni Web e per dispositivi mobili PaaS. Per ulteriori informazioni sulla protezione delle distribuzioni PaaS, vedere: