Condividi tramite

Playbook per la gestione dei requisiti di sicurezza comuni con Database SQL di Azure e Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Database SQL di AzureIstanza gestita di SQL di Azure

Questo articolo illustra le procedure consigliate per soddisfare i requisiti di sicurezza comuni. Non tutti i requisiti sono applicabili a tutti gli ambienti, quindi è necessario consultare i team di database e di sicurezza per capire quali funzionalità implementare.

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

Soddisfare i requisiti di sicurezza comuni

Questo documento fornisce indicazioni su come soddisfare i requisiti di sicurezza comuni per le applicazioni nuove o esistenti usando il database SQL di Azure e Istanza gestita di SQL di Azure. È organizzato in base ad aree di sicurezza di alto livello. Per affrontare minacce specifiche, vedere la sezione Minacce comuni e potenziali mitigazioni per la sicurezza. Anche se alcuni dei consigli presentati sono applicabili durante la migrazione delle applicazioni da locale ad Azure, lo scopo di questo documento non riguarda gli scenari di migrazione.

Offerte di distribuzione del database SQL di Azure descritte in questa guida

Offerte di distribuzione non presenti in questa guida

  • Azure Synapse Analytics
  • Azure SQL VMs (IaaS)
  • SQL Server

Destinatari

I destinatari di questa guida sono i clienti che hanno domande su come proteggere il database SQL di Azure. I ruoli interessati a questo articolo sulle procedure consigliate includono, ma non sono limitati a:

  • Architetti della sicurezza
  • Responsabili della sicurezza
  • Responsabili della conformità
  • Responsabili della privacy
  • Ingegneri della sicurezza

Come utilizzare questa guida

Questo documento è da intendersi come un complemento alla documentazione esistente sulla sicurezza del database SQL di Azure.

Se non diversamente specificato, si consiglia di seguire tutte le procedure consigliate elencate in ogni sezione per raggiungere il rispettivo obiettivo o requisito. Per soddisfare specifici standard o procedure consigliate per la conformità ai requisiti di sicurezza, i controlli di conformità alle normative importanti sono elencati nella sezione Requisiti o Obiettivi, dove applicabile. Gli standard e le normative di sicurezza a cui si fa riferimento in questo documento sono i seguenti:

È previsto che i consigli e le procedure consigliate qui elencate vengano continuamente aggiornate. Per fornire input o correzioni a questo documento, si può usare il collegamento per il Feedback in fondo a questo articolo.

Autenticazione

L'autenticazione è il processo atto a dimostrare che l'utente sia effettivamente chi dichiara di essere. Il database SQL di Azure e Istanza gestita di SQL supportano due tipi di autenticazione:

  • Autenticazione SQL
  • Autenticazione Microsoft Entra

Nota

L'autenticazione di Microsoft Entra potrebbe non essere supportata per tutti gli strumenti e le applicazioni di terze parti.

Gestione centralizzata per le identità

La gestione centralizzata delle identità offre i seguenti vantaggi:

  • Gestione degli account di gruppo e controllo delle autorizzazioni utente senza duplicare gli account di accesso tra server, database e istanze gestite.
  • Gestione semplificata e flessibile delle autorizzazioni.
  • Gestione delle applicazioni su larga scala.

Come implementarla

  • Usare l'autenticazione di Microsoft Entra per la gestione delle identità centralizzata.

Procedure consigliate

  • Creare un tenant di Microsoft Entra e creare utenti per rappresentare gli utenti umani e creare entità servizio per rappresentare app, servizi e strumenti di automazione. Le entità servizio sono equivalenti agli account del servizio in Windows e Linux.

  • Assegnare alle entità di accesso a Microsoft Entra i diritti di accesso alle risorse tramite l'assegnazione di gruppo: creare gruppi di Microsoft Entra, concedere l'accesso ai gruppi e aggiungere singoli membri ai gruppi. Creare utenti di database indipendente nel proprio database mappati ai gruppi di Microsoft Entra. Per assegnare autorizzazioni all'interno del database, aggiungere gli utenti del database indipendente che rappresentano i gruppi ai ruoli del database o concedere direttamente loro le autorizzazioni.

    Nota

    In Istanza gestita di SQL è anche possibile creare account di accesso mappati alle entità di sicurezza di Microsoft Entra nel database master. Vedere CREATE LOGIN (Transact-SQL).

  • L'uso dei gruppi di Microsoft Entra semplifica la gestione delle autorizzazioni, consentendo al proprietario del gruppo e al proprietario della risorsa di aggiungere o rimuovere membri del gruppo.

  • Creare un gruppo separato per gli amministratori di Microsoft Entra per ogni server o istanza gestita.

  • Monitorare le modifiche all'appartenenza ai gruppi di Microsoft Entra usando i report sulle attività di controllo di Microsoft Entra ID.

  • Per creare un amministratore di Microsoft Entra nel caso di un'istanza gestita, è necessario un passaggio separato.

Nota

  • L'autenticazione di Microsoft Entra viene registrata nei log di controllo di Azure SQL, ma non nei log di accesso di Microsoft Entra.
  • Le autorizzazioni di controllo degli accessi in base al ruolo concesse in Azure non si applicano alle autorizzazioni di database SQL di Azure o Istanza gestita di SQL. Tali autorizzazioni devono essere create o mappate manualmente usando le autorizzazioni SQL esistenti.
  • Sul lato client, l'autenticazione di Microsoft Entra ha bisogno dell'accesso a Internet o a una rete virtuale tramite route definita dall'utente (UDR).
  • Il token di accesso di Microsoft Entra viene memorizzato nella cache sul lato client e la sua durata dipende dalla configurazione del token. Vedere l'articolo Durate dei token configurabili in Microsoft Entra ID
  • Per indicazioni sulla risoluzione dei problemi di autenticazione di Microsoft Entra, vedere il seguente blog: Risoluzione dei problemi relativi all'ID Microsoft Entra.

Autenticazione a più fattori Microsoft Entra

Menzionato in: Pratica OSA #2, ISO Controllo di accesso

L'autenticazione a più fattori Microsoft Entra consente di ottenere maggiore sicurezza richiedendo più di una forma di autenticazione.

Come implementarla

  • Abilitare l'autenticazione a più fattori in Microsoft Entra ID usando l'accesso condizionale e usare l'autenticazione interattiva.

  • L'alternativa consiste nell'abilitare l'autenticazione a più fattori per l'intero tenant di Microsoft Entra o per il dominio Active Directory.

Procedure consigliate

Ridurre al minimo l'uso dell'autenticazione basata su password per gli utenti

Menzionato in: Pratica OSA #4, ISO Controllo di accesso

I metodi di autenticazione basati su password sono una forma di autenticazione più debole. Le credenziali possono essere compromesse o cedute per errore.

Come implementarla

  • Usare l'autenticazione integrata di Microsoft Entra che elimina l'uso delle password.

Procedure consigliate

  • Usare l'autenticazione Single Sign-On usando le credenziali di Windows. Federare il dominio di Active Directory locale con Microsoft Entra ID e usare l'autenticazione integrata di Windows (per i computer aggiunti a un dominio con il Microsoft Entra ID).

Ridurre al minimo l'uso dell'autenticazione basata su password per le applicazioni

Menzionato in: Pratica OSA #4, ISO Controllo di accesso

Come implementarla

  • Abilitare identità gestita di Azure. È possibile usare anche l'autenticazione integrata o basata su certificati.

Procedure consigliate

Proteggere password e segreti

Per i casi in cui non è possibile evitare l'uso di password, assicurarsi che queste siano sicure.

Come implementarla

  • Usare Azure Key Vault per archiviare password e segreti. Quando applicabile, usare l'autenticazione a più fattori per il database SQL di Azure con gli utenti di Microsoft Entra.

Procedure consigliate

  • Se non è possibile evitare password o segreti, archiviare le password utente e i segreti delle applicazioni in Azure Key Vault e gestire l'accesso tramite i criteri di accesso di Key Vault.

  • Vari framework di sviluppo di app possono anche offrire meccanismi specifici del framework per la protezione dei segreti nell'app. Ad esempio l'app ASP.NET Core.

Usare l'autenticazione SQL per le applicazioni precedenti.

L'autenticazione SQL si riferisce all'autenticazione di un utente durante la connessione al database SQL di Azure o all'Istanza gestita di SQL usando nome utente e password. È necessario creare un account di accesso in ogni server o istanza gestita e un utente in ogni database.

Come implementarla

  • Usare l'autenticazione di SQL.

Procedure consigliate

Gestione degli accessi

La gestione degli accessi (detta anche Autorizzazione) è il processo di controllo e gestione degli accessi e dei privilegi degli utenti autorizzati per il database SQL di Azure o per Istanza gestita di SQL.

Implementare il principio del privilegio minimo

Menzionato in: Controlli FedRamp AC-06, NIST: AC-6, Pratica OSA #3

Il principio dei privilegi minimi indica che gli utenti non devono avere più privilegi di quelli necessari per completare i task. Per ulteriori informazioni, vedere l'articolo Just Enough Administration

Come implementarla

Assegnare solo le autorizzazioni necessarie per completare i task richiesti:

Procedure consigliate

Le seguenti procedure consigliate sono facoltative, ma migliorano la gestibilità e la supportabilità della strategia di sicurezza:

  • Se possibile, iniziare con il set più piccolo possibile di autorizzazioni e iniziare ad aggiungere le autorizzazioni una alla volta, se è davvero necessario (e se c'è una giustificazione), anziché seguire l'approccio opposto che consiste nel rimuovere le autorizzazioni passo dopo passo.

  • Non assegnare autorizzazioni a singoli utenti. Usare invece i ruoli (ruoli del database o del server) in modo coerente. I ruoli contribuiscono in modo significativo alla creazione di report e alla risoluzione dei problemi delle autorizzazioni. (Il controllo degli accessi in base al ruolo di Azure supporta solo l'assegnazione di autorizzazioni tramite ruoli.)

  • Creare e usare i ruoli personalizzati con le autorizzazioni esatte necessarie. Ruoli tipici usati in pratica:

    • Distribuzione della sicurezza
    • Amministratore
    • Sviluppatore
    • Personale di supporto
    • Revisore
    • Processi automatizzati
    • Utente finale

  • Usare i ruoli predefiniti solo quando le autorizzazioni dei ruoli corrispondono esattamente alle autorizzazioni necessarie per l'utente. È possibile assegnare più ruoli agli utenti.

  • Tenere presente che le autorizzazioni nel motore di database possono essere applicate all'interno dei seguenti ambiti (più piccolo è l'ambito, minore è l'impatto delle autorizzazioni concesse):

    • Server (ruoli speciali nel database master) in Azure
    • Database
    • Schema
      • Per concedere autorizzazioni all'interno di un database è consigliabile usare gli schemi.
    • Oggetto (tabella, vista, procedura e così via)

    Nota

    Non è consigliabile applicare le autorizzazioni a livello di oggetto, perché questo livello aggiunge una complessità non necessaria per l'implementazione complessiva. Se si decide di usare le autorizzazioni a livello di oggetto, tali autorizzazioni devono essere chiaramente documentate. Lo stesso vale per le autorizzazioni a livello di colonna, che sono ancora meno consigliate per gli stessi motivi. Tenere inoltre presente che, per impostazione predefinita, un'istruzione DENY a livello di tabella non esegue l'override di un'istruzione GRANT a livello di colonna. Ciò richiede l'attivazione della configurazione del server di conformità ai criteri comuni.

  • Eseguire controlli regolari usando la valutazione della vulnerabilità per verificare che non ci siano troppe autorizzazioni.

Implementare la separazione dei compiti

'Menzionato in: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

La separazione dei compiti descrive la necessità di suddividere le attività sensibili in più task assegnati a utenti diversi. La separazione dei compiti consente di evitare violazioni dei dati.

Come implementarla

  • Identificare il livello di separazione dei compiti richiesto. Esempi:

    • tra gli ambienti di sviluppo/test e produzione.
    • Confronto tra i task sensibili dal punto di vista della sicurezza, i task di gestione dell'amministratore di database e le attività di sviluppo.
      • Esempi: revisore, creazione di criteri di sicurezza per la sicurezza a livello di ruolo, implementazione di oggetti database SQL con autorizzazioni DDL.

  • Identificare una gerarchia completa di utenti (e processi automatizzati) che accedono al sistema.

  • Creare ruoli in base ai gruppi utenti necessari e assegnare le autorizzazioni ai ruoli.

    • Per i task a livello di gestione nel portale di Azure o tramite l'automazione di PowerShell, usare i ruoli di Azure. Trovare un ruolo predefinito che corrisponda al requisito oppure creare un ruolo personalizzato di Azure usando le autorizzazioni disponibili
    • Creare ruoli del server per i task a livello di server (creazione di nuovi account di accesso e database) in un'istanza gestita.
    • Creare ruoli del database per i task a livello di database.

  • Per alcuni task sensibili, è consigliabile creare stored procedure speciali firmate da un certificato per eseguire i task per conto degli utenti. Un importante vantaggio delle stored procedure firmate digitalmente è che se la procedura viene modificata, le autorizzazioni concesse alla versione precedente della procedura vengono immediatamente rimosse.

  • Implementare Transparent Data Encryption (TDE) con chiavi gestite dal cliente in Azure Key Vault per abilitare la separazione dei compiti tra il proprietario dei dati e il proprietario della sicurezza.

  • Per assicurarsi che un amministratore del database non possa visualizzare i dati considerati altamente sensibili e che possa comunque eseguire task da amministratore del database, è possibile usare Always Encrypted con la separazione dei ruoli.

  • Nei casi in cui non è possibile usare Always Encrypted, o almeno non senza costi e sforzi importanti che potrebbero persino rendere il sistema quasi inutilizzabile, i compromessi possono essere realizzati e mitigati attraverso l'uso di controlli di compensazione come:

Procedure consigliate

  • Assicurarsi che vengano usati account diversi per gli ambienti di sviluppo/test e produzione. Account diversi consentono di rispettare la separazione dei sistemi di test e di produzione.

  • Non assegnare autorizzazioni a singoli utenti. Usare invece i ruoli (ruoli del database o del server) in modo coerente. L'esistenza dei ruoli consente di creare report e risolvere i problemi relativi alle autorizzazioni.

  • Usare i ruoli predefiniti quando le autorizzazioni corrispondono esattamente a quelle necessarie: se l'unione di tutte le autorizzazioni di più ruoli predefiniti determina una corrispondenza del 100%, è possibile assegnare più ruoli contemporaneamente.

  • Creare e usare ruoli definiti dall'utente quando i ruoli predefiniti concedono troppe autorizzazioni o autorizzazioni insufficienti.

  • Le assegnazioni di ruolo possono anche essere effettuate temporaneamente, con la cosiddetta separazione dinamica dei compiti, sia all'interno dei passaggi di lavoro di SQL Agent in T-SQL sia usando Azure PIM per i ruoli di Azure.

  • Assicurarsi che gli amministratori di database non abbiano accesso alle chiavi di crittografia o agli archivi di chiavi e che gli amministratori della sicurezza con accesso alle chiavi non abbiano accesso al database. L'uso di Extensible Key Management può semplificare questa separazione. Azure Key Vault può essere usato per implementare Extensible Key Management .

  • Assicurarsi sempre di disporre di un audit trail per le azioni relative alla sicurezza.

  • È possibile recuperare la definizione dei ruoli predefiniti di Azure per vedere le autorizzazioni usate e creare un ruolo personalizzato in base a estratti e gruppi di questi tramite PowerShell.

  • Poiché qualsiasi membro del ruolo del database db_owner può modificare le impostazioni di sicurezza come Transparent Data Encryption (TDE) o modificare lo SLO, l'appartenenza a questo ruolo deve essere concessa con attenzione. Tuttavia, sono molti i task che richiedono privilegi db_owner. Task come la modifica di qualsiasi impostazione del database, ad esempio la modifica delle opzioni del database. Il controllo svolge un ruolo chiave in qualsiasi soluzione.

  • Non è possibile limitare le autorizzazioni di un ruolo db_owner e quindi impedire a un account amministrativo di visualizzare i dati utente. Se in un database sono presenti dati estremamente sensibili, è possibile usare Always Encrypted per evitare che i db_owner o qualsiasi altro amministratore di database li visualizzino.

Nota

Per i task correlati alla sicurezza o alla risoluzione dei problemi, il raggiungimento della separazione dei compiti è complesso. In altre aree, come lo sviluppo e i ruoli degli utenti finali, la separazione è più facile. La maggior parte dei controlli correlati alla conformità consente l'uso di funzioni di controllo alternative, ad esempio l'audit, quando altre soluzioni non sono praticabili.

Per i lettori che vogliono approfondire la separazione dei compiti, si consigliano le seguenti risorse:

Eseguire revisioni regolari del codice

'Menzionato in: PCI: 6.3.2, SOC: SDL-3

La separazione dei compiti non si limita ai dati di un database, ma include anche il codice dell'applicazione. Potenzialmente, il codice dannoso può eludere i controlli di sicurezza. Prima di distribuire codice personalizzato nell'ambiente di produzione, è fondamentale esaminare gli elementi distribuiti.

Come implementarla

  • Usare uno strumento di database come Azure Data Studio che supporti il controllo del codice sorgente.

  • Implementare un processo di distribuzione del codice separato.

  • Prima di eseguire il commit nel ramo principale, una persona (diversa dall'autore del codice stesso) deve ispezionare il codice per individuare potenziali rischi di elevazione dei privilegi e modifiche dannose dei dati per proteggersi da frodi e accessi non autorizzati. Questa operazione può essere eseguita usando meccanismi di controllo del codice sorgente.

Procedure consigliate

  • Standardizzazione: aiuta a implementare una procedura standard da seguire per tutti gli aggiornamenti del codice.

  • Valutazione della vulnerabilità contiene regole che verificano che non ci siano autorizzazioni eccessive, che non vengano utilizzati algoritmi di crittografia obsoleti e che non ci siano altri problemi di sicurezza all'interno di uno schema del database.

  • È possibile eseguire ulteriori controlli in un ambiente di controllo di qualità o di test usando Advanced Threat Protection, che esegue una scansione per individuare codici vulnerabili a SQL-injection.

  • Esempi di cosa cercare:

    • Creazione di un utente o modifica delle impostazioni di sicurezza dall'interno di una distribuzione automatizzata di aggiornamento del codice SQL.
    • Una stored procedure che, in base ai parametri forniti, aggiorna un valore monetario in una cella in modo non conforme.

  • Assicurarsi che la persona che esegue la revisione sia un individuo diverso dall'autore del codice di origine e che sia esperta di revisione del codice e di codifica sicura.

  • Assicurarsi di conoscere tutte le origini delle modifiche al codice. Il codice può essere incluso negli script T-SQL. Può trattarsi di un comando ad hoc da eseguire o da distribuire sotto forma di visualizzazioni, funzioni, trigger e stored procedure. Può far parte delle definizioni del processo di SQL Agent (sottoattività). Può anche essere eseguito da pacchetti SSIS, Azure Data Factory e altri servizi.

Protezione dei dati

La protezione dei dati personali è un set di funzionalità per la sicurezza delle informazioni importanti dalla compromissione mediante crittografia o offuscamento.

Nota

Microsoft attesta il database SQL di Azure e Istanza gestita di SQL come conformi a FIPS 140-2 Level 1. Ciò avviene dopo aver verificato l'uso rigoroso di algoritmi accettabili FIPS 140-2 Livello 1 e di istanze convalidate FIPS 140-2 Livello 1 per tali algoritmi, compresa la coerenza con le lunghezze delle chiavi richieste, la gestione delle chiavi, la generazione e l'archiviazione delle chiavi. Questa attestazione ha lo scopo di consentire ai clienti di rispondere alla necessità o al requisito di utilizzare istanze convalidate FIPS 140-2 di livello 1 nell'elaborazione dei dati o nella fornitura di sistemi o applicazioni. Si definiscono i termini "conforme a FIPS 140-2 Livello 1" e "conformità a FIPS 140-2 Livello 1" utilizzati nella dichiarazione di cui sopra per dimostrarne l'applicabilità all'uso del diverso termine "convalidato per FIPS 140-2 Livello 1" da parte del governo statunitense e canadese.

Crittografare i dati in movimento

'Menzionato in: Pratica OSA #6, Controllo ISO: crittografia

Protegge i dati mentre i dati si spostano tra il client e il server. Fare riferimento a Sicurezza di rete.

Crittografare i dati inattivi

'Menzionato in: Pratica OSA #6, Controllo ISO: crittografia

La crittografia dei dati inattivi è la protezione crittografica dei dati quando sono salvati in modo permanente nei file di backup, database e log.

Come implementarla

  • Transparent Data Encryption (TDE) con chiavi gestite del servizio è abilitata per impostazione predefinita per tutti i database creati dopo il 2017 nel database SQL di Azure e in Istanza gestita di SQL.
  • In un'istanza gestita, se il database viene creato da un'operazione di ripristino usando un server locale, l'impostazione Transparent Data Encryption del database originale verrà rispettata. Se nel database originale non è abilitata l'impostazione TDE, è consigliabile attivarla manualmente per l'istanza gestita.

Procedure consigliate

  • Non archiviare i dati che richiedono la crittografia dei dati inattivi nel database master. Il database master non può essere crittografato con Transparent Data Encryption.

  • Usare le chiavi gestite dal cliente in Azure Key Vault se è necessario aumentare la trasparenza e il controllo granulare sulla protezione TDE. Azure Key Vault consente di revocare le autorizzazioni in qualsiasi momento per rendere il database inaccessibile. È possibile gestire le protezioni TDE centralmente insieme ad altre chiavi, oppure ruotare la protezione TDE in base al proprio piano usando Azure Key Vault.

  • Se si usano chiavi gestite dal cliente in Azure Key Vault, seguire gli articoli Linee guida per la configurazione di TDE con Azure Key Vault e Come configurare il ripristino di emergenza geografico con Azure Key Vault.

Nota

Alcuni elementi considerati contenuto dei clienti, ad esempio nomi di tabella, nomi di oggetti e nomi di indice, possono essere trasmessi nei file di resoconto per il supporto e la risoluzione dei problemi da parte di Microsoft.

Proteggere i dati sensibili in uso da utenti con privilegi elevati e non autorizzati

I dati in uso sono i dati archiviati nella memoria del sistema di database durante l'esecuzione di query SQL. Se il database archivia dati sensibili, l'organizzazione potrebbe essere tenuta a garantire che agli utenti con privilegi elevati sia impedita la visualizzazione dei dati sensibili nel database. Gli utenti con privilegi elevati, come gli operatori Microsoft o gli amministratori di database dell'organizzazione, devono essere in grado di gestire il database, ma non possono visualizzare e potenzialmente esfiltrare dati sensibili dalla memoria del processo SQL o eseguendo query sul database.

I criteri che determinano quali dati sono sensibili e se i dati sensibili devono essere crittografati in memoria e non devono essere accessibili agli amministratori in testo non crittografato, dipendono dall'organizzazione specifica e dalle normative di conformità da rispettare. Vedere il requisito correlato: Identificare e contrassegnare i dati sensibili.

Come implementarla

  • Usare Always Encrypted per garantire che i dati sensibili non vengano esposti in testo non crittografato nel database SQL di Azure o in Istanza gestita di SQL, anche in memoria/in uso. Always Encrypted protegge i dati dagli amministratori di database e dagli amministratori cloud (o da malintenzionati che possono rappresentare utenti con privilegi elevati senza essere autorizzati) e offre un maggiore controllo su chi può accedere ai dati.

Procedure consigliate

  • Always Encrypted non sostituisce le funzionalità per crittografare i dati inattivi (TDE) o in transito (SSL/TLS). Always Encrypted non deve essere usato per i dati non sensibili, in modo da ridurre al minimo l'impatto sulle prestazioni e sulle funzionalità. L'uso di Always Encrypted in combinazione con TDE e Transport Layer Security è consigliato per la protezione completa dei dati inattivi, in transito e in uso.

  • Valutare l'impatto della crittografia delle colonne di dati sensibili identificate prima di distribuire Always Encrypted in un database di produzione. In generale, Always Encrypted riduce la funzionalità delle query sulle colonne crittografate e presenta altre limitazioni, che sono elencate nella pagina Always Encrypted: Dettagli sulla funzionalità. Potrebbe quindi essere necessario riprogettare l'applicazione per riabilitare le funzionalità non supportate da una query sul lato client e/o effettuare il refactoring dello schema del database, comprese le definizioni di stored procedure, funzioni, visualizzazioni e trigger. Le applicazioni esistenti potrebbero non funzionare con colonne crittografate se non rispettano le restrizioni e le limitazioni di Always Encrypted. Anche se l'ecosistema di strumenti, prodotti e servizi Microsoft che supportano Always Encrypted è in crescita, molti di essi non funzionano con le colonne crittografate. A seconda delle caratteristiche del carico di lavoro, la crittografia di una colonna può influire anche sulle prestazioni delle query.

  • Gestire le chiavi Always Encrypted con la separazione dei ruoli se si usa Always Encrypted per proteggere i dati da amministratori di database malintenzionati. Con la separazione dei ruoli, un amministratore della sicurezza crea le chiavi fisiche. L'amministratore di database crea gli oggetti metadati della chiave master e della chiave di crittografia della colonna che descrivono le chiavi fisiche nel database. Durante questo processo, l'amministratore della sicurezza non ha bisogno di accedere al database e l'amministratore di database non ha bisogno di accedere alle chiavi fisiche in testo non crittografato.

  • Archiviare le chiavi master della colonna in Azure Key Vault per semplificare la gestione. Evitare di usare l'archivio certificati windows (e, in generale, le soluzioni di archivio delle chiavi distribuite invece delle soluzioni di gestione delle chiavi centrali) che rendono difficile la gestione delle chiavi.

  • Valutare attentamente i vantaggi e gli svantaggi dell'uso di più chiavi (chiave master della colonna o chiavi di crittografia della colonna). Mantenere un numero ridotto di chiavi per ridurre i costi di gestione delle chiavi. In genere, in ambienti stabili sono sufficienti una chiave master della colonna e una chiave di crittografia della colonna per ogni database (non al centro di una rotazione delle chiavi). Potrebbero essere necessarie chiavi aggiuntive se sono presenti gruppi di utenti diversi, ognuno dei quali usa chiavi diverse e accede a dati diversi.

  • Ruotare le chiavi master della colonna in base ai requisiti di conformità. Se è anche necessario ruotare le chiavi di crittografia della colonna, è consigliabile usare la crittografia online per ridurre al minimo i tempi di inattività dell'applicazione.

  • Usare la crittografia deterministica se è necessario supportare calcoli (uguaglianza) sui dati. In caso contrario, usare la crittografia casuale. Evitare di usare la crittografia deterministica per set di dati a bassa entropia o con distribuzione nota pubblicamente.

  • Se si teme che terzi possano accedere legalmente ai dati senza il consenso dell'utente, assicurarsi che tutte le applicazioni e gli strumenti che hanno accesso alle chiavi e ai dati in testo non crittografato siano eseguiti al di fuori di Microsoft Azure Cloud. Senza accesso alle chiavi, i soggetti terzi non avranno modo di decifrare i dati, a meno che non bypassino la crittografia.

  • Always Encrypted non supporta facilmente la concessione dell'accesso temporaneo alle chiavi (e ai dati protetti). Ad esempio, nel caso in cui fosse necessario condividere le chiavi con un amministratore di database per consentirgli di eseguire alcune operazioni di pulizia sui dati sensibili e crittografati. L'unico modo per revocare in modo affidabile l'accesso ai dati all'amministratore di database sarà quello di ruotare sia le chiavi di crittografia della colonna che le chiavi master della colonna che proteggono i dati, il che è molto costoso.

  • Per accedere ai valori di testo non crittografato nelle colonne crittografate, un utente deve avere accesso alla chiave master della colonna che protegge le colonne, configurata nell'archivio di chiavi che contiene la chiave. L'utente deve inoltre disporre delle autorizzazioni di database VIEW ANY COLUMN MASTER KEY DEFINITION e VIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

Controllare l'accesso degli utenti dell'applicazione ai dati sensibili tramite la crittografia

La crittografia può essere usata come modo per garantire che solo specifici utenti dell'applicazione che hanno accesso alle chiavi crittografiche possano visualizzare o aggiornare i dati.

Come implementarla

  • Usare la crittografia a livello di cella. Per informazioni dettagliate, vedere l'articolo Crittografia di una colonna di dati.
  • Usare Always Encrypted, tenendo però in considerazione i suoi limiti. Le limitazioni sono elencate di seguito.

Procedure consigliate:

Quando si usa la crittografia CLE:

  • Controllare l'accesso alle chiavi tramite autorizzazioni e ruoli SQL.

  • Usare AES (AES 256 consigliato) per la crittografia dei dati. Algoritmi come RC4, DES e TripleDES sono deprecati e non devono essere usati a causa di vulnerabilità note.

  • Proteggere le chiavi simmetriche con chiavi/certificati asimmetrici (e non password) per evitare l'uso di 3DES.

  • Fare attenzione quando si esegue la migrazione di un database usando la crittografia a livello di cella tramite esportazione/importazione (file bacpac).

Tenere presente che Always Encrypted è stato progettato principalmente per proteggere i dati sensibili in uso da utenti di Azure SQL Database con privilegi elevati (operatori cloud, amministratori di database): vedere Proteggere i dati sensibili in uso da utenti con privilegi elevati e non autorizzati. Quando si utilizza Always Encrypted per proteggere i dati dagli utenti delle applicazioni, occorre tenere presente i seguenti problemi:

  • Per impostazione predefinita, tutti i driver client Microsoft che supportano Always Encrypted mantengono una cache globale (una per applicazione) delle chiavi di crittografia della colonna. Quando un driver client acquisisce una chiave di crittografia della colonna in testo non crittografato contattando un archivio di chiavi che contiene una chiave master della colonna, la chiave di crittografia della colonna in testo non crittografato viene memorizzata nella cache. Ciò rende difficile isolare i dati dagli utenti di un'applicazione multiutente. Se l'applicazione rappresenta gli utenti finali durante l'interazione con un archivio di chiavi (ad esempio Azure Key Vault), dopo che la query di un utente popola la cache con una chiave di crittografia della colonna, una query successiva che richiede la stessa chiave ma viene attivata da un altro utente userà la chiave memorizzata nella cache. Il driver non chiamerà l'archivio di chiavi e non verificherà se il secondo utente dispone dell'autorizzazione per accedere alla chiave di crittografia della colonna. Di conseguenza, l'utente può visualizzare i dati crittografati anche se non ha accesso alle chiavi. Per ottenere l'isolamento degli utenti in un'applicazione multiutente, è possibile disabilitare la il caching della chiave di crittografia della colonna. La disabilitazione del caching causerà un sovraccarico aggiuntivo delle prestazioni, perché il driver dovrà contattare l'archivio di chiavi per ogni operazione di crittografia o decrittazione dei dati.

Proteggere i dati dalle visualizzazioni non autorizzate da parte degli utenti dell'applicazione, preservando il formato dati.

Un'altra tecnica per impedire agli utenti non autorizzati di visualizzare i dati consiste nell'offuscare o mascherare i dati preservandone i tipi e i formati per garantire che le applicazioni utente possano continuare a gestire e visualizzare i dati.

Come implementarla

Nota

Always Encrypted non è compatibile con Dynamic Data Masking. Non è possibile crittografare e mascherare la stessa colonna. Questo implica che è necessario dare priorità alla protezione dei dati in uso rispetto all'applicazione di una maschera ai dati per gli utenti dell'app tramite Dynamic Data Masking.

Procedure consigliate

Nota

Dynamic Data Masking non può essere usato per proteggere i dati da utenti con privilegi elevati. I criteri di mascheratura non si applicano agli utenti con accesso amministrativo come db_owner.

  • Non consentire agli utenti dell'app di eseguire query ad hoc (perché potrebbero essere in grado di aggirare Dynamic Data Masking).

  • Usare un criterio di controllo di accesso appropriato (tramite autorizzazioni SQL, ruoli, sicurezza a livello di riga) per limitare le autorizzazioni degli utenti ed effetturare aggiornamenti nelle colonne con maschera. La creazione di una maschera in una colonna non ne impedisce l'aggiornamento. Gli utenti che ricevono dati mascherati quando eseguono una query sulla colonna con maschera possono aggiornare i dati se dispongono di autorizzazioni di scrittura.

  • Dynamic Data Masking non mantiene le proprietà statistiche dei valori con maschera. Ciò può avere un impatto sui risultati delle query (ad esempio, query contenenti predicati di filtraggio o join sui dati mascherati).

Sicurezza di rete

La sicurezza di rete si riferisce ai controlli di accesso e alle procedure consigliate per proteggere i dati in movimento verso database SQL di Azure.

Configurare il client per la connessione sicura al database SQL o a Istanza gestita di SQL

Procedure consigliate su come impedire ai computer client e alle applicazioni con vulnerabilità note (ad esempio, che usano protocolli TLS e pacchetti di crittografia meno recenti) di connettersi al database SQL di Azure e a Istanza gestita di SQL.

Come implementarla

  • Assicurarsi che i computer client che si connettono al database SQL di Azure e a Istanza gestita di SQL usino la versione più recente di Transport Layer Security (TLS).

Procedure consigliate

  • Applicare una versione minima di Transport Layer Security a livello di server di database SQL o Istanza gestita di SQL usando l'impostazione della versione minima di TLS. Dopo aver verificato che sia supportata dalle applicazioni, è consigliabile impostare la versione minima di TLS su 1.2. TLS 1.2 include correzioni per le vulnerabilità rilevate nelle versioni precedenti.

  • Configurare tutte le app e gli strumenti per la connessione a database SQL con la crittografia abilitata

    • Encrypt = On, TrustServerCertificate = Off (o equivalente con driver non Microsoft).

  • Se l'app usa un driver che non supporta TLS o supporta una versione precedente di TLS, sostituire il driver, se possibile. Se ciò non è possibile, valutare attentamente i rischi per la sicurezza.

Ridurre al minimo la superficie di attacco

Ridurre al minimo il numero di funzionalità che possono essere attaccate da un utente malintenzionato. Implementare i controlli di accesso alla rete per il database SQL di Azure

Menzionato in: Pratica OSA #5

Come implementarla

Nel database SQL:

  • Impostare Consenti l'accesso ai servizi di Azure su OFF a livello di server.
  • Usare gli endpoint servizio di rete virtuale e le regole del firewall della rete virtuale.
  • Usare Collegamento privato.

In Istanza gestita di SQL:

Procedure consigliate

  • Limitare l'accesso al database SQL di Azure e a Istanza gestita di SQL connettendosi su un endpoint privato, ad esempio usando un percorso dati privato:

    • Un'istanza gestita può essere isolata all'interno di una rete virtuale per impedire l'accesso esterno. Le applicazioni e gli strumenti che si trovano nella stessa rete virtuale o con peering nella stessa area possono accedervi direttamente. Le applicazioni e gli strumenti che si trovano in un'area diversa possono usare la connessione da rete virtuale a rete virtuale o il peering del circuito ExpressRoute per stabilire la connessione. Il cliente deve usare i gruppi di sicurezza di rete per limitare l'accesso alla porta 1433 solo alle risorse che richiedono l'accesso a un'istanza gestita.
    • Per un database SQL, usare la funzionalità collegamento privato che fornisce un indirizzo IP privato dedicato per il server all'interno della rete virtuale. È anche possibile usare gli endpoint servizio di rete virtuale con regole del firewall della rete virtuale per limitare l'accesso ai server.
    • Gli utenti mobili devono usare connessioni VPN da punto a sito per connettersi tramite il percorso dati.
    • Gli utenti connessi alla rete locale devono usare la connessione VPN da sito a sito o ExpressRoute per connettersi tramite il percorso dati.

  • È possibile accedere al database SQL di Azure e a Istanza gestita di SQL connettendosi a un endpoint pubblico, ad esempio usando un percorso dati pubblico. È bene prendere in considerazione le seguenti procedure consigliate:

    Nota

    L'endpoint pubblico Istanza gestita di SQL non è abilitato per impostazione predefinita e deve essere abilitato in modo esplicito. Se i criteri aziendali non consentono l'uso di endpoint pubblici, usare i Criteri di Azure per impedire del tutto l'abilitazione degli endpoint pubblici.

  • Configurare i componenti di Rete di Azure:

Configurare Power BI per connessioni sicure al database SQL e a Istanza gestita di SQL

Procedure consigliate

Configurare servizio app per connessioni sicure al database SQL e a Istanza gestita di SQL

Procedure consigliate

Configurare l'hosting delle macchine virtuali di Azure per connessioni sicure al database SQL o a Istanza gestita di SQL

Procedure consigliate

  • Utilizzare una combinazione di regole di autorizzazione e rifiuto sugli NSG delle macchine virtuali di Azure per controllare quali aree sono accessibili dalla macchina virtuale.

  • Assicurarsi che la macchina virtuale sia configurata in base all'articolo Procedure consigliate per la sicurezza dei carichi di lavoro IaaS in Azure.

  • Assicurarsi che tutte le macchine virtuali siano associate a una rete virtuale e a una subnet specifiche.

  • Valutare se serve il percorso predefinito 0.0.0.0/Internet in base alle indicazioni relative alle Informazioni sul tunneling forzato.

    • Se sì, ad esempio, la subnet front-end mantiene il percorso predefinito.
    • In caso contrario, ad esempio per la subnet del livello intermedio o del back-end, è necessario attivare il tunneling forzato, in modo che il traffico non passi attraverso Internet per raggiungere l'istanza locale (cross-premises).

  • Se si utilizza il peering o ci si connette a sedi locali, è possibile implementare percorsi predefiniti opzionali.

  • Se è necessario inviare tutto il traffico nella rete virtuale a un'appliance virtuale di rete per l'ispezione dei pacchetti, implementare percorsi definiti dall'utente.

  • Usare gli endpoint servizio di rete virtuale per l'accesso sicuro ai servizi PaaS come Archiviazione di Azure tramite la rete backbone di Azure.

Proteggersi da attacchi Distributed Denial of Service (DDoS):

Gli attacchi Distributed Denial of Service (DDoS) sono tentativi da parte di un utente malintenzionato di inviare un'ondata del traffico di rete al database SQL di Azure con l'obiettivo di sovraccaricare l'infrastruttura di Azure e farle rifiutare accessi e carichi di lavoro validi.

Menzionato in: Pratica OSA #9

Come implementarla

La protezione DDoS viene attivata automaticamente come parte della piattaforma di Azure. Include il monitoraggio del traffico sempre attivo e la mitigazione in tempo reale degli attacchi a livello di rete sugli endpoint pubblici.

Procedure consigliate

  • Seguire le procedure descritte in Ridurre al minimo la superficie di attacco aiuta a ridurre al minimo le minacce di attacco DDoS.

  • L'avviso di attacco di forza bruta alle credenziali SQL di Advanced Threat Protection aiuta a rilevare gli attacchi di forza bruta. In alcuni casi, l'avviso può anche distinguere i carichi di lavoro dei test di penetrazione.

  • Per le macchine virtuali di Azure che ospitano applicazioni che si connettono al database SQL:

    • Seguire il consigliio di limitare l'accesso tramite endpoint con connessione Internet in Microsoft Defender per il cloud.
    • Usare i set di scalabilità di macchine virtuali per eseguire più istanze dell'applicazione su macchine virtuali di Azure.
    • Disattivare RDP e SSH da Internet per evitare attacchi di forza bruta.

Monitoraggio, registrazione e controllo

Questa sezione si riferisce alle funzionalità che aiutano a rilevare attività anomale che indicano tentativi insoliti e potenzialmente dannosi di accedere o sfruttare i database. Descrive anche le procedure consigliate per configurare il controllo del database per rilevare e acquisire gli eventi del database.

Proteggere i database dagli attacchi

Advanced Threat Protection consente di rilevare e rispondere a minacce potenziali non appena si verificano, fornendo avvisi di sicurezza sulle attività anomale.

Come implementarla

  • Usare Advanced Threat Protection per SQL per rilevare tentativi insoliti e potenzialmente dannosi di accesso o sfruttamento dei database, tra cui:
    • Attacco SQL injection.
    • Perdita/furto di credenziali.
    • Abuso dei privilegi
    • Esfiltrazione di dati.

Procedure consigliate

  • Configurare Microsoft Defender per SQL per un server specifico o un'istanza gestita. È anche possibile configurare Microsoft Defender per SQL per tutti i server e le istanze gestite in una sottoscrizione abilitando Microsoft Defender per il cloud.

  • Per un'esperienza di indagine completa, è consigliabile abilitare il controllo del database SQL. Con il controllo, è possibile tenere traccia degli eventi del database e scriverli in un log di controllo nell'account di archiviazione di Azure o nell'area di lavoro Log Analytics.

Controllare gli eventi di sicurezza critici

Il rilevamento degli eventi del database consente di comprendere l'attività del database. È possibile ottenere informazioni su eventuali discrepanze e anomalie che potrebbero indicare problemi aziendali o sospette violazioni della sicurezza. Inoltre, consente e facilita il rispetto degli standard di conformità.

Come implementarla

  • Abilitare il controllo dei database SQL o il controllo delle istanze gestite per rilevare gli eventi dei database e scriverli in un log di controllo nell'account di archiviazione di Azure, nell'area di lavoro Log Analytics (anteprima) o nell'Hub eventi (anteprima).

  • I log di controllo possono essere scritti in un account di archiviazione di Azure, in un'area di lavoro Log Analytics per l'utilizzo tramite log di Monitoraggio di Azure o in un hub eventi per l'utilizzo tramite Hub eventi. È possibile configurare qualsiasi combinazione di queste opzioni e verranno scritti i log di controllo per ognuno.

Procedure consigliate

  • Configurando il controllo del database SQL sul server o il controllo delle istanze gestite per l'audit degli eventi, tutti i database esistenti e quelli appena creati sul server verranno controllati.
  • Per impostazione predefinita, i criteri di controllo includono tutte le azioni (query, stored procedure e account di accesso riusciti e non riusciti) sui database, il che può comportare un volume elevato di log di controllo. È consigliabile che i clienti configurino il controllo per diversi tipi di azioni e gruppi di azioni usando PowerShell. La configurazione permetterà di monitorare il numero di azioni controllate e ridurre al minimo il rischio di perdita di eventi. Le configurazioni di controllo personalizzate permettono ai clienti di acquisire solo i dati di controllo necessari.
  • I log di controllo possono essere utilizzati direttamente nel portale di Azure o dalla posizione di archiviazione configurata.

Nota

L'abilitazione del controllo nell'analisi dei log comporta costi in base alla frequenza di inserimento. Tenere presente il costo associato all'uso di questa opzione o valutare la possibilità di archiviare i log di controllo in un account di archiviazione di Azure.

Ulteriori risorse

Log di controllo sicuro

Limitare l'accesso all'account di archiviazione per supportare la separazione dei compiti e separare l'amministratore di database dai revisori.

Come implementarla

  • Quando si salvano i log di controllo in Archiviazione di Azure, assicurarsi che l'accesso all'account di archiviazione sia limitato ai principi minimi di sicurezza. Controllare chi ha accesso all'account di archiviazione.
  • Per altre informazioni, vedere Autorizzare l'accesso ai dati in Archiviazione di Azure.

Procedure consigliate

  • Il controllo dell'accesso all'obiettivo del controllo è un concetto chiave per separare l'amministratore di database dai revisori.

  • Quando si controlla l'accesso ai dati sensibili, è consigliabile proteggere i dati con la crittografia dei dati per evitare la fuga di informazioni verso il revisore. Per altre informazioni, vedere la sezione Proteggere i dati sensibili in uso da utenti con privilegi elevati e non autorizzati.

Gestione della sicurezza

Questa sezione descrive i diversi aspetti e le procedure consigliate per la gestione della postura di sicurezza dei database. Include le procedure consigliate per garantire che i database siano configurati per soddisfare gli standard di sicurezza e per scoprire, classificare e rilevare l'accesso ai dati potenzialmente sensibili nei database.

Assicurarsi che i database siano configurati in modo da soddisfare le procedure consigliate per la sicurezza

Migliorare in modo proattivo la sicurezza del database individuando e correggendo le potenziali vulnerabilità del database.

Come implementarla

Procedure consigliate

  • Inizialmente, eseguire la valutazione della vulnerabilità nei database ed eseguire l'iterazione correggendo i controlli errati che si oppongono alle procedure consigliate per la sicurezza. Configurare le previsioni per le configurazioni accettabili fino a quando la scansione non risulta negativa o tutti i controlli sono stati superati.

  • Configurare scansioni periodiche ricorrenti da eseguire una volta alla settimana e configurare la persona interessata affinché riceva le email di riepilogo.

  • Esaminare il riepilogo della valutazione della vulnerabilità dopo ogni analisi settimanale. Per qualsiasi vulnerabilità rilevata, valutare la deriva rispetto al risultato della scansione precedente e determinare se il controllo deve essere risolto. Verificare se esiste un motivo legittimo per la modifica della configurazione.

  • Risolvere i controlli e, se pertinente, aggiornare le previsioni. Creare articoli ticket per la risoluzione delle azioni e tenerne traccia fino a quando non vengono risolti.

Ulteriori risorse

Identificare e contrassegnare i dati sensibili

Individuare colonne che potenzialmente contengono dati sensibili. La definizione di dati sensibili dipende in larga misura dal cliente, dalla conformità alle normative, ecc. e deve essere valutata dagli utenti responsabili dei dati. Classificare le colonne per usare scenari di controllo e protezione avanzati basati sulla riservatezza.

Come implementarla

  • Usare le funzionalità di individuazione e classificazione dei dati per scoprire, classificare, etichettare e proteggere i dati sensibili presenti nei database.
    • Visualizzare i consigli di classificazione creati dall'individuazione automatica nel dashboard Individuazione dati e classificazione SQL. Accettare le classificazioni pertinenti, in modo che i dati sensibili vengano contrassegnati in modo permanente con etichette di classificazione.
    • Aggiungere manualmente le classificazioni per eventuali campi dati sensibili aggiuntivi non rilevati dal meccanismo automatizzato.
  • Per altre informazioni, vedere Individuazione dati e classificazione SQL.

Procedure consigliate

  • Monitorare regolarmente il dashboard di classificazione per una valutazione accurata dello stato di classificazione del database. È possibile esportare o stampare un report sullo stato di classificazione del database per scopi di conformità e controllo.

  • Monitorare continuamente lo stato dei dati sensibili consigliati nella valutazione della vulnerabilità SQL. Tenere traccia della regola di individuazione dei dati sensibili e identificare eventuali deviazioni nelle colonne consigliate per la classificazione.

  • Usare la classificazione in modo da che si adatti alle esigenze specifiche dell'organizzazione. Personalizzare i criteri di protezione delle informazioni (etichette di riservatezza, tipi di informazioni, logica di individuazione) nei criteri di protezione delle informazioni SQL in Microsoft Defender per il cloud.

Rilevare l'accesso ai dati sensibili

Monitorare chi accede ai dati sensibili e acquisire le query sui dati sensibili nei log di controllo.

Come implementarla

Procedure consigliate

Visualizzare lo stato di sicurezza e conformità

Usare un sistema di gestione della sicurezza dell'infrastruttura unificato che rafforza la postura di sicurezza dei data center (inclusi i database in database SQL). Visualizzare un elenco di consigli relativi alla sicurezza dei database e allo stato di conformità.

Come implementarla

Minacce comuni per la sicurezza e potenziali mitigazioni

Questa sezione aiuta a individuare le misure di sicurezza per la protezione da determinati vettori di attacco. Si prevede che la maggior parte delle mitigazioni possa essere ottenuta seguendo una o più delle linee guida di sicurezza indicate sopra.

Minaccia di sicurezza: esfiltrazione dei dati

L'esfiltrazione dei dati è la copia, il trasferimento o il recupero non autorizzato di dati da un computer o da un server. Vedere una definizione di l'esfiltrazione di dati su Wikipedia.

La connessione al server tramite un endpoint pubblico presenta un rischio di esfiltrazione di dati, in quanto richiede ai clienti di aprire i propri firewall agli IP pubblici.

Scenario 1: un'applicazione in una macchina virtuale di Azure si connette a un database nel database SQL di Azure. Un attore non autorizzato ottiene l'accesso alla macchina virtuale e la compromette. In questo scenario, esfiltrazione di dati significa che un'entità esterna che utilizza la macchina virtuale senza autorizzazione si connette al database, copia i dati personali e li memorizza in un'archiviazione BLOB o in un altro database SQL in una sottoscrizione diversa.

Scenario 2: un amministratore di database non autorizzato. Questo scenario si presenta spesso per i clienti sensibili alla sicurezza nei settori regolamentati. In questo scenario, un utente con privilegi elevati potrebbe copiare dati dal database SQL di Azure a un'altra sottoscrizione non controllata dal proprietario dei dati.

Potenziali soluzioni

Attualmente, il database SQL di Azure e Istanza gestita di SQL offrono le seguenti tecniche per mitigare le minacce di esfiltrazione di dati:

  • Utilizzare una combinazione di regole di autorizzazione e rifiuto sugli NSG delle macchine virtuali di Azure per controllare quali aree sono accessibili dalla macchina virtuale.
  • Se si usa un server nel database SQL, impostare le seguenti opzioni:
    • Consentire ai servizi Azure di disattivarsi.
    • Consentire solo il traffico dalla subnet contenente la macchina virtuale di Azure configurando una regola del firewall della rete virtuale.
    • Usare Collegamento privato
  • Per Istanza gestita di SQL, l'uso dell'accesso IP privato per impostazione predefinita risolve il primo problema di esfiltrazione di dati da parte di una macchina virtuale non autorizzata. Abilitare la funzionalità di delega della subnet in una subnet per impostare automaticamente i criteri più restrittivi in una subnet di Istanza gestita di SQL.
  • Il problema dell'amministratore di database non autorizzato è più esposto con Istanza gestita di SQL poiché ha una superficie di attacco più ampia e i requisiti di rete sono visibili ai clienti. In questo caso, la migliore mitigazione consiste nell'applicare tutte le procedure descritte in questa guida alla sicurezza per prevenire del tutto lo scenario dell'amministratore di database non autorizzato (non solo per l'esfiltrazione di dati). Always Encrypted è un metodo per proteggere i dati sensibili crittografandoli e mantenendo la chiave inaccessibile per l'amministratore di database.

Aspetti relativi alla sicurezza della continuità aziendale e della disponibilità

La maggior parte degli standard di sicurezza risolve la disponibilità dei dati in termini di continuità operativa, ottenuta implementando funzionalità di ridondanza e failover per evitare singoli punti di guasto. Per gli scenari di emergenza, è pratica comune mantenere i backup dei dati e dei file di resoconto. La seguente sezione offre delle Informazioni generali sulle funzionalità integrate in Azure. Offre anche opzioni aggiuntive che possono essere configurate per soddisfare esigenze specifiche:

Passaggi successivi