Condividi tramite

Procedure consigliate per la protezione dei database PaaS in Azure

In questo articolo viene descritta una raccolta di procedure consigliate per la sicurezza di Database SQL di Azure e Azure Synapse Analytics per proteggere le applicazioni Web e per dispositivi mobili paaS (Platform-as-a-Service). Le procedure consigliate si basano sull'esperienza di tecnici e clienti con Azure.

Il 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 usa il 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 archivio di identità centralizzato

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

  • L'autenticazione SQL usa un nome utente e una 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 eseguire l'autenticazione a qualsiasi database in tale server come 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 al database SQL di Azure e ad Azure Synapse Analytics usando le identità nell'ID Microsoft Entra. 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 l'autenticazione integrata di Windows e altre forme di autenticazione supportate dall'ID Microsoft Entra.
  • Usa gli utenti di un 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 usano l'autenticazione universale di Active Directory, che include Multi-Factor Authentication (MFA). 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 il database SQL e Azure Synapse Analytics.

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

Annotazioni

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 intervalli di indirizzi IP accettabili. Queste regole possono essere destinate sia a livello di server che di database. È consigliabile usare le regole del firewall a livello di database quando possibile per migliorare la sicurezza e rendere il database più portabile. Le regole del firewall a livello di server vengono usate meglio per gli amministratori e quando si dispone di molti database con gli stessi requisiti di accesso, ma non si vuole dedicare tempo alla configurazione di ogni database singolarmente.

Le restrizioni degli indirizzi IP di origine predefinite del database SQL consentono l'accesso da qualsiasi indirizzo di Azure, incluse altre sottoscrizioni e tenant. È possibile limitare questa operazione in modo da consentire solo agli indirizzi IP di accedere all'istanza. Anche con il firewall SQL e le restrizioni relative all'indirizzo IP, è comunque necessaria l'autenticazione avanzata. Vedere le raccomandazioni apportate in precedenza in questo articolo.

Per altre informazioni sulle restrizioni IP e firewall SQL di Azure, vedere:

Crittografare i dati a riposo

Transparent Data Encryption (TDE) è abilitato per impostazione predefinita. TDE crittografa in modo trasparente SQL Server, database SQL di Azure e file di log e dati di Azure Synapse Analytics. TDE protegge da una compromissione dell'accesso diretto ai file o al relativo backup. In questo modo è possibile crittografare i dati archiviati senza modificare le applicazioni esistenti. TDE deve sempre rimanere abilitato; Tuttavia, questo non arresterà un utente malintenzionato usando il normale percorso di accesso. TDE offre la possibilità di rispettare molte leggi, normative e linee guida stabilite in vari settori.

Azure SQL gestisce i problemi correlati alle chiavi per TDE. Come per TDE, è necessario prestare particolare attenzione in locale per garantire la recuperabilità e quando si spostano i database. In scenari più sofisticati, le chiavi possono essere gestite in modo esplicito in Azure Key Vault tramite la gestione estendibile delle chiavi. Vedere Abilitare TDE in SQL Server tramite EKM. Ciò consente anche la funzionalità BYOK (Bring Your Own Key) tramite la funzionalità BYOK di Azure Key Vaults.

Sql di Azure fornisce la crittografia per le colonne tramite Always Encrypted. Ciò consente solo alle applicazioni autorizzate di accedere alle colonne sensibili. L'uso di questo tipo di crittografia limita le query SQL per le colonne crittografate ai valori basati sull'uguaglianza.

La crittografia a livello di applicazione deve essere usata anche per i dati selettivi. I problemi di sovranità dei dati possono talvolta essere mitigati crittografando i dati con una chiave mantenuta nel paese/area geografica corretta. Ciò impedisce anche il trasferimento accidentale dei dati a causa di un problema poiché non è possibile decrittografare i dati senza la chiave, presupponendo che venga usato un algoritmo sicuro (ad esempio AES 256).

È possibile usare precauzioni aggiuntive per proteggere il database, ad esempio la progettazione di un sistema sicuro, la crittografia degli asset riservati e la creazione di un firewall intorno ai 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:

  • Last updated on