Playbook per affrontare i 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 risolvere i requisiti di sicurezza comuni. Non tutti i requisiti sono applicabili a tutti gli ambienti ed è necessario consultare il team di database e sicurezza su quali funzionalità implementare.

Nota

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

Risolvere i requisiti di sicurezza comuni

Questo documento fornisce indicazioni su come risolvere i requisiti di sicurezza comuni per le applicazioni nuove o esistenti usando 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 alla sicurezza e potenziali mitigazioni . Anche se alcune delle raccomandazioni presentate sono applicabili durante la migrazione di applicazioni da locale ad Azure, gli scenari di migrazione non sono incentrati su questo documento.

database SQL di Azure offerte di distribuzione descritte in questa guida

Offerte di distribuzione non illustrate in questa guida

  • Azure Synapse Analytics
  • Macchine virtuali SQL di Azure (IaaS)
  • SQL Server

Destinatari

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

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

Come utilizzare questa guida

Questo documento è destinato a essere complementare alla documentazione di sicurezza database SQL di Azure esistente.

Se non diversamente specificato, è consigliabile seguire tutte le procedure consigliate elencate in ogni sezione per raggiungere il rispettivo obiettivo o requisito. Per soddisfare specifici standard di conformità alla sicurezza o procedure consigliate, i controlli di conformità alle normative importanti sono elencati nella sezione Requisiti o Obiettivi, se applicabile. Questi sono gli standard e le normative di sicurezza a cui si fa riferimento in questo documento:

Microsoft prevede di continuare ad aggiornare le raccomandazioni e le procedure consigliate elencate qui. Fornire input o eventuali correzioni per questo documento usando il collegamento Commenti e suggerimenti nella parte inferiore di questo articolo.

Autenticazione

L'autenticazione è il processo atto a dimostrare che l'utente sia effettivamente chi dichiara di essere. 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 centrale per le identità

La gestione centrale delle identità offre i vantaggi seguenti:

  • Gestire gli account di gruppo e controllare le 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 centralizzata delle identità.

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 i diritti di accesso alle risorse alle entità di accesso a Microsoft Entra tramite l'assegnazione di gruppo: creare gruppi di Microsoft Entra, concedere l'accesso ai gruppi e aggiungere singoli membri ai gruppi. Nel database creare utenti di database indipendenti che eseguono il mapping 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 loro direttamente le autorizzazioni.

    Nota

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

  • L'uso dei gruppi di Microsoft Entra semplifica la gestione delle autorizzazioni e il proprietario del gruppo e il proprietario della risorsa può aggiungere/rimuovere membri da/verso il 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 un'istanza gestita, è necessario un passaggio separato per creare un amministratore di Microsoft Entra.

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 di Azure concesse in Azure non si applicano alle autorizzazioni di database SQL di Azure o Istanza gestita di SQL. Tali autorizzazioni devono essere create/mappate manualmente usando le autorizzazioni SQL esistenti.
  • Sul lato client, l'autenticazione di Microsoft Entra deve accedere a Internet o tramite route definita dall'utente (UDR) a una rete virtuale.
  • 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 Durata dei token configurabili in Microsoft Entra ID
  • Per indicazioni sulla risoluzione dei problemi di autenticazione di Microsoft Entra, vedere il blog seguente: Risoluzione dei problemi relativi all'ID Microsoft Entra.

L'autenticazione a più fattori di Microsoft Entra

Menzionato in: OSA Practice #2, ISO Controllo di accesso (AC)

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 di Active Directory.

Procedure consigliate

  • Attivare l'accesso condizionale in Microsoft Entra ID (richiede una sottoscrizione Premium).

  • Creare gruppi Microsoft Entra e abilitare i criteri di autenticazione a più fattori per i gruppi selezionati usando l'accesso condizionale Microsoft Entra.

  • L'autenticazione a più fattori può essere abilitata per l'intero tenant di Microsoft Entra o per Active Directory federata con Microsoft Entra ID.

  • Usare la modalità di autenticazione interattiva di Microsoft Entra per database SQL di Azure e Istanza gestita di SQL di Azure in cui viene richiesta una password in modo interattivo, seguita dall'autenticazione a più fattori:

  • Implementare le applicazioni per connettersi a database SQL di Azure o Istanza gestita di SQL di Azure usando l'autenticazione interattiva con supporto per l'autenticazione a più fattori.

    Nota

    Questa modalità di autenticazione richiede identità basate sull'utente. Nei casi in cui viene usato un modello di identità attendibile che ignora l'autenticazione utente Microsoft Entra (ad esempio, usando l'identità gestita per le risorse di Azure), l'autenticazione a più fattori non viene applicata.

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

Menzionato in: OSA Practice #4, ISO Controllo di accesso (AC)

I metodi di autenticazione basati su password sono una forma più debole di autenticazione. Le credenziali possono essere compromesse o erroneamente date via.

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. Federate il dominio di Active Directory locale con Microsoft Entra ID e usate autenticazione di Windows integrate (per i computer aggiunti a un dominio con l'ID Microsoft Entra).

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

Menzionato in: OSA Practice #4, ISO Controllo di accesso (AC)

Come implementarla

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

Procedure consigliate

Proteggere password e segreti

Per i casi in cui le password non sono evitabili, assicurarsi che siano protette.

Come implementarla

  • Usare Azure Key Vault per archiviare password e segreti. Quando applicabile, usare l'autenticazione a più fattori per 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 dell'applicazione 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: ASP.NET'app principale.

Usare l'autenticazione SQL per le applicazioni legacy

L'autenticazione SQL fa riferimento all'autenticazione di un utente durante la connessione a database SQL di Azure o Istanza gestita di SQL tramite nome utente e password. È necessario creare un account di accesso in ogni server o istanza gestita e un utente creato 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 database SQL di Azure o Istanza gestita di SQL.

Implementare il principio dei privilegi minimi

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

Il principio dei privilegi minimi indica che gli utenti non devono avere più privilegi di quanto necessario per completare le attività. Per altre informazioni, vedere l'articolo Just enough administration .For more information, see the article Just enough administration.

Come implementarla

Assegnare solo le autorizzazioni necessarie per completare le attività necessarie:

Procedure consigliate

Le procedure consigliate seguenti sono facoltative, ma comportano una migliore gestibilità e supporto della strategia di sicurezza:

  • Se possibile, iniziare con il set minimo possibile di autorizzazioni e iniziare ad aggiungere le autorizzazioni uno per uno, se c'è una vera necessità (e giustificazione), anziché l'approccio opposto: prendere le autorizzazioni passo dopo passo.

  • Evitare di assegnare autorizzazioni a singoli utenti. Usare invece i ruoli (ruoli del database o del server) in modo coerente. I ruoli contribuiscono notevolmente 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 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 utenti a più ruoli.

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

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

    Nota

    Non è consigliabile applicare autorizzazioni a livello di oggetto perché questo livello aggiunge complessità non necessarie all'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 una grant a livello di colonna. Ciò richiede l'attivazione della configurazione del server di conformità dei criteri comuni.

  • Eseguire controlli regolari usando valutazione della vulnerabilità (VA) per testare 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, detta anche separazione dei compiti, descrive il requisito di suddividere le attività sensibili in più attività assegnate a utenti diversi. La separazione dei compiti consente di evitare violazioni dei dati.

Come implementarla

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

    • Tra ambienti di sviluppo/test e produzione
    • Attività sensibili per la sicurezza rispetto alle attività a livello di gestione di Database Amministrazione istrator (DBA) e attività di sviluppo.
      • Esempi: Revisore, creazione di criteri di sicurezza per la sicurezza a livello di ruolo (RLS), 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 di utenti necessari e assegnare le autorizzazioni ai ruoli.

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

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

  • 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 possano comunque eseguire attività DBA, è possibile usare Always Encrypted con la separazione dei ruoli.

  • Nei casi in cui l'uso di Always Encrypted non è fattibile o almeno non senza costi e sforzi importanti che potrebbero persino rendere il sistema quasi inutilizzabile, è possibile apportare compromessi e attenuarli tramite l'uso di controlli di compensazione, ad esempio:

    • Intervento umano nei processi.
    • Audit trail: per altre informazioni sul controllo, vedere Controllare gli eventi di sicurezza critici.

Procedure consigliate

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

  • Evitare di assegnare autorizzazioni a singoli utenti. Usare invece i ruoli (ruoli del database o del server) in modo coerente. La presenza di ruoli consente di creare report e risolvere i problemi relativi alle autorizzazioni.

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

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

  • Le assegnazioni di ruolo possono anche essere eseguite temporaneamente, note anche come separazione dinamica dei compiti (DSD), all'interno dei passaggi del processo di SQL Agent in T-SQL o usando Azure PIM per i ruoli di Azure.

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

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

  • È possibile recuperare la definizione dei ruoli predefiniti di Azure per visualizzare le autorizzazioni usate e creare un ruolo personalizzato in base agli estratti e alle estensioni 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, questa appartenenza deve essere concessa con attenzione. Esistono tuttavia molte attività che richiedono privilegi db_owner. Attività 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 db_owner e quindi impedire a un account amministrativo di visualizzare i dati utente. Se sono presenti dati altamente sensibili in un database, Always Encrypted può essere usato per impedire in modo sicuro db_owners o qualsiasi altro amministratore del database di visualizzarlo.

Nota

Il raggiungimento della separazione dei compiti (SoD) è difficile per le attività correlate alla sicurezza o alla risoluzione dei problemi. Altre aree come lo sviluppo e i ruoli degli utenti finali sono più facili da separare. La maggior parte dei controlli correlati alla conformità consente l'uso di funzioni di controllo alternative, ad esempio il controllo quando altre soluzioni non sono pratiche.

Per i lettori che vogliono approfondire Il soD, è consigliabile usare le risorse seguenti:

Eseguire revisioni regolari del codice

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

La separazione dei compiti non è limitata ai dati in un database, ma include il codice dell'applicazione. Il codice dannoso può potenzialmente aggirare i controlli di sicurezza. Prima di distribuire codice personalizzato nell'ambiente di produzione, è essenziale esaminare gli elementi distribuiti.

Come implementarla

  • Usare uno strumento di database come Azure Data Studio che supporta 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 esaminare il codice per individuare potenziali rischi di elevazione dei privilegi, nonché modifiche ai dati dannosi per proteggersi da frodi e accessi non autorizzati. Questa operazione può essere eseguita usando meccanismi di controllo del codice sorgente.

Procedure consigliate

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

  • Valutazione della vulnerabilità contiene regole che controllano autorizzazioni eccessive, l'uso di algoritmi di crittografia precedenti e altri problemi di sicurezza all'interno di uno schema del database.

  • È possibile eseguire ulteriori controlli in un ambiente di controllo di qualità o test usando Advanced Threat Protection che analizza il codice vulnerabile all'inserimento SQL.

  • 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, a seconda dei 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 esperto nelle revisioni del codice e nella codifica sicura.

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

Protezione dei dati

La protezione dei dati è un set di funzionalità per proteggere informazioni importanti dalla compromissione dalla crittografia o dall'offuscamento.

Nota

Microsoft attesta database SQL di Azure e Istanza gestita di SQL come conforme a FIPS 140-2 Level 1. Questa operazione viene eseguita dopo aver verificato l'uso rigoroso di algoritmi accettabili fips 140-2 livello 1 e istanze convalidate fips 140-2 di livello 1 di tali algoritmi, inclusa la coerenza con le lunghezze di chiave necessarie, la gestione delle chiavi, la generazione di chiavi e l'archiviazione delle chiavi. Questa attestazione è destinata a consentire ai clienti di rispondere alla necessità o al requisito per l'uso di istanze convalidate fips 140-2 di livello 1 nell'elaborazione dei dati o del recapito di sistemi o applicazioni. Definiamo i termini "conformità FIPS 140-2 Level 1" e "conformità FIPS 140-2 Livello 1" usati nell'istruzione precedente per dimostrare la loro applicabilità prevista all'uso degli Stati Uniti e del governo canadese del diverso termine "FIPS 140-2 Level 1 convalidato".

Crittografa i dati in transito

Menzionato in: OSA Practice #6, ISO Control Family: Cryptography

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

Crittografare i dati inattivi

Menzionato in: OSA Practice #6, ISO Control Family: Cryptography

La crittografia dei dati inattivi è la protezione crittografica dei dati quando è persistente nei file di database, log e backup.

Come implementarla

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

Procedure consigliate

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

  • 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 centralmente le protezioni TDE insieme ad altre chiavi o ruotare la protezione TDE in base alla propria pianificazione 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 del cliente, ad esempio nomi di tabella, nomi di oggetti e nomi di indice, possono essere trasmessi nei file di log 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 in memoria del sistema di database durante l'esecuzione di query SQL. Se il database archivia dati sensibili, l'organizzazione potrebbe essere necessaria per garantire che agli utenti con privilegi elevati venga impedito di visualizzare i dati sensibili nel database. Gli utenti con privilegi elevati, ad esempio gli operatori Microsoft o gli amministratori di database nell'organizzazione devono essere in grado di gestire il database, ma non possono visualizzare ed 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 accessibili agli amministratori in testo non crittografato, sono specifici per l'organizzazione e le normative di conformità a cui è necessario 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 in database SQL di Azure o Istanza gestita di SQL, anche in memoria/in uso. Always Encrypted protegge i dati dai database Amministrazione istrators (DBA) e dagli amministratori cloud (o da attori malintenzionati che possono rappresentare utenti con privilegi elevati ma non autorizzati) e offre un maggiore controllo su chi può accedere ai dati.

Procedure consigliate

  • Always Encrypted non è un sostituto per crittografare i dati inattivi (TDE) o in transito (SSL/TLS). Always Encrypted non deve essere usato per i dati non sensibili per ridurre al minimo l'impatto sulle prestazioni e sulle funzionalità. L'uso di Always Encrypted in combinazione con TDE e Transport Layer Security (TLS) è 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, elencate in Always Encrypted - Dettagli funzionalità. Potrebbe pertanto essere necessario riprogettare l'applicazione per riabilitare le funzionalità, una query non supporta, sul lato client o/e effettuare il refactoring dello schema del database, incluse le definizioni di stored procedure, funzioni, viste 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 Microsoft, prodotti e servizi che supportano Always Encrypted è in crescita, molti di essi non funzionano con le colonne crittografate. La crittografia di una colonna può influire anche sulle prestazioni delle query, a seconda delle caratteristiche del carico di lavoro.

  • Gestire le chiavi Always Encrypted con la separazione dei ruoli se si usa Always Encrypted per proteggere i dati da dbA dannosi. Con la separazione dei ruoli, un amministratore della sicurezza crea le chiavi fisiche. L'amministratore di database crea gli oggetti metadati della chiave master della colonna e della chiave di crittografia della colonna che descrivono le chiavi fisiche nel database. Durante questo processo, l'amministratore della sicurezza non deve accedere al database e l'amministratore di database non deve 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 archiviazione delle chiavi distribuite, anziché le soluzioni di gestione delle chiavi centrali) che rendono difficile la gestione delle chiavi.

  • Valutare attentamente i compromessi dell'uso di più chiavi (chiave master della colonna o chiavi di crittografia della colonna). Mantenere ridotto il numero di chiavi per ridurre i costi di gestione delle chiavi. Una chiave master della colonna e una chiave di crittografia della colonna per ogni database sono in genere sufficienti in ambienti a stato stabile (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 delle colonne, è consigliabile usare la crittografia online per ridurre al minimo i tempi di inattività dell'applicazione.

  • Usare la crittografia deterministica se i calcoli (uguaglianza) sui dati devono essere supportati. In caso contrario, usare la crittografia casuale. Evitare di usare la crittografia deterministica per set di dati a bassa entropia o set di dati con distribuzione nota pubblica.

  • Se si è preoccupati per terze parti che accedono ai dati in modo legale senza il consenso, assicurarsi che tutti gli strumenti e le applicazioni che hanno accesso alle chiavi e ai dati in testo non crittografato vengano eseguiti all'esterno di Microsoft Azure Cloud. Senza accesso alle chiavi, la terza parte non potrà decrittografare i dati a meno che non ignorino la crittografia.

  • Always Encrypted non supporta facilmente la concessione dell'accesso temporaneo alle chiavi (e ai dati protetti). Ad esempio, se è necessario condividere le chiavi con un amministratore di database per consentire all'amministratore di database di eseguire alcune operazioni di pulizia sui dati sensibili e crittografati. L'unico modo per revocare in modo affidabile l'accesso ai dati dall'amministratore di database consiste nel ruotare sia le chiavi di crittografia della colonna che le chiavi master della colonna che proteggono i dati, operazione costosa.

  • Per accedere ai valori di testo non crittografato nelle colonne crittografate, un utente deve avere accesso alla chiave master della colonna (CMK) che protegge le colonne, configurate nell'archivio chiavi che contiene la chiave cmk. 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 gli utenti specifici dell'applicazione che hanno accesso alle chiavi crittografiche possano visualizzare o aggiornare i dati.

Come implementarla

Procedure consigliate:

Quando si usa CLE:

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

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

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

  • Prestare 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 è progettato principalmente per proteggere i dati sensibili in uso da utenti con privilegi elevati di database SQL di Azure (operatori cloud, DBA) . Vedere Proteggere i dati sensibili in uso da utenti con privilegi elevati e non autorizzati. Tenere presenti le problematiche seguenti quando si usa Always Encrypted per proteggere i dati dagli utenti dell'applicazione:

  • Per impostazione predefinita, tutti i driver client Microsoft che supportano Always Encrypted mantengono una cache globale (una per applicazione) delle chiavi di crittografia delle colonne. Quando un driver client acquisisce una chiave di crittografia della colonna non crittografata contattando un archivio chiavi che contiene una chiave master della colonna, la chiave di crittografia della colonna non crittografata 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 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 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 l'utente non ha accesso alle chiavi. Per ottenere l'isolamento degli utenti all'interno di un'applicazione multiutente, è possibile disabilitare la memorizzazione nella cache della chiave di crittografia della colonna. La disabilitazione della memorizzazione nella cache causerà un sovraccarico aggiuntivo delle prestazioni, perché il driver dovrà contattare l'archivio chiavi per ogni operazione di crittografia o decrittografia dei dati.

Proteggere i dati da una visualizzazione non autorizzata da parte degli utenti dell'applicazione mantenendo al tempo stesso il formato dei dati

Un'altra tecnica per impedire agli utenti non autorizzati di visualizzare i dati consiste nell'offuscare o mascherare i dati mantenendo i tipi di dati 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, il che implica la necessità di assegnare priorità alla protezione dei dati in uso e mascherare i 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 mascheramento non si applicano agli utenti con accesso amministrativo, ad esempio 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 utente per eseguire aggiornamenti nelle colonne mascherate. La creazione di una maschera in una colonna non impedisce gli aggiornamenti a tale colonna. Gli utenti che ricevono dati mascherati durante l'esecuzione di query sulla colonna mascherata possono aggiornare i dati se dispongono di autorizzazioni di scrittura.

  • Dynamic Data Masking non mantiene le proprietà statistiche dei valori mascherati. Ciò può influire sui risultati delle query, ad esempio query contenenti predicati di filtro 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 transito per database SQL di Azure.

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

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

Come implementarla

Procedure consigliate

  • Applicare una versione minima di TLS a livello di server database SQL o Istanza gestita di SQL usando l'impostazione minima della versione TLS. È consigliabile impostare la versione minima di TLS su 1.2, dopo il test per verificare che le applicazioni lo supportino. 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 non possibile, valutare attentamente i rischi per la sicurezza.

    • Ridurre i vettori di attacco tramite vulnerabilità in SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1 disabilitandoli nei computer client che si connettono alle database SQL di Azure impostazioni del Registro di sistema di Transport Layer Security (TLS).
    • Controllare i pacchetti di crittografia disponibili nel client: Pacchetti di crittografia in TLS/SSL (SSP Schannel).Check cipher suites available on the client: Cipher Suites in TLS/SSL (SCHANNEL SSP). In particolare, disabilitare 3DES per configurazione dell'ordine TLS Cipher Suite.

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 database SQL di Azure.

Menzionato in: OSA Practice #5

Come implementarla

In 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:

  • Seguire le linee guida in Requisiti di rete.

Procedure consigliate

  • Limitazione dell'accesso a database SQL di Azure e Istanza gestita di SQL connettendosi a 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 gruppi di sicurezza di rete (NSG) 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 di 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 database SQL di Azure e Istanza gestita di SQL connettendosi a un endpoint pubblico, ad esempio usando un percorso dati pubblico. È consigliabile considerare le procedure consigliate seguenti:

    • Per un server in database SQL, usare le regole del firewall IP per limitare l'accesso solo agli indirizzi IP autorizzati.
    • Per Istanza gestita di SQL, usare gruppi di sicurezza di rete (NSG) per limitare l'accesso alla porta 3342 solo alle risorse necessarie. Per altre informazioni, vedere Usare un'istanza gestita in modo sicuro con endpoint pubblici.

    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 Criteri di Azure per impedire l'abilitazione degli endpoint pubblici al primo posto.

  • Configurare i componenti di Rete di Azure:

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

Procedure consigliate

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

Procedure consigliate

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

Procedure consigliate

  • Usare una combinazione di regole Consenti e Nega nei gruppi di sicurezza di rete delle macchine virtuali di Azure per controllare le aree a cui è possibile accedere dalla macchina virtuale.

  • Assicurarsi che la macchina virtuale sia configurata in base all'articolo Procedure consigliate per la sicurezza per i 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 è necessaria la route predefinita 0.0.0.0/Internet in base alle indicazioni relative al tunneling forzato.

    • Se sì, ad esempio, la subnet front-end mantiene la route predefinita.
    • Se no, ad esempio, il livello intermedio o la subnet back-end, abilitare il tunneling forzato in modo che nessun traffico passa attraverso Internet per raggiungere l'ambiente locale ,ad esempio cross-premise.

  • Implementare route predefinite facoltative se si usa il peering o ci si connette all'ambiente locale.

  • Implementare route definite dall'utente se è necessario inviare tutto il traffico nella rete virtuale a un'appliance virtuale di rete per l'ispezione dei pacchetti.

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

Protezione 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'inondazione del traffico di rete a database SQL di Azure con l'obiettivo di sovraccaricare l'infrastruttura di Azure e di rifiutare accessi e carichi di lavoro validi.

Menzionato in: OSA Practice #9

Come implementarla

La protezione DDoS viene abilitata automaticamente come parte della piattaforma 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 le minacce agli attacchi DDoS.

  • L'avviso delle credenziali SQL di forza bruta di Advanced Threat Protection consente di rilevare attacchi di forza bruta. In alcuni casi, l'avviso può anche distinguere i carichi di lavoro di test di penetrazione.

  • Per le applicazioni di hosting di macchine virtuali di Azure che si connettono a database SQL:

    • Seguire la raccomandazione Per 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 in macchine virtuali di Azure.
    • Disabilitare RDP e SSH da Internet per evitare attacchi di forza bruta.

Monitoraggio, registrazione e controllo

Questa sezione si riferisce alle funzionalità che consentono di 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 tenere traccia e acquisire gli eventi del database.

Proteggere i database da attacchi

Advanced Threat Protection consente di rilevare e rispondere alle potenziali minacce man mano che 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 accedere o sfruttare i database, tra cui:
    • Attacco SQL injection.
    • Furto/perdita di credenziali.
    • Abuso di 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 database SQL Controllo. Con il controllo è possibile tenere traccia degli eventi del database e scriverli in un log di controllo in un account Archiviazione di Azure o in un'area di lavoro Di Azure Log Analytics.

Controllare gli eventi di sicurezza critici

Il rilevamento degli eventi del database consente di comprendere l'attività del database. È possibile ottenere informazioni dettagliate su discrepanze e anomalie che potrebbero indicare problemi aziendali o sospette violazioni della sicurezza. Consente inoltre e facilita la conformità agli standard di conformità.

Come implementarla

  • Abilitare database SQL Controllo o controllo Istanza gestita per tenere traccia degli eventi del database e scriverli in un log di controllo nell'account Archiviazione di Azure, nell'area di lavoro Log Analytics (anteprima) o in Hub eventi (anteprima).

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

Procedure consigliate

  • Configurando database SQL Controllo sul server o Istanza gestita Controllo per controllare gli eventi, verranno controllati tutti i database esistenti e appena creati in tale server.
  • Per impostazione predefinita, i criteri di controllo includono tutte le azioni (query, stored procedure e account di accesso riusciti e non riusciti) sui database, che possono comportare un volume elevato di log di controllo. È consigliabile per i clienti configurare il controllo per diversi tipi di azioni e gruppi di azioni tramite PowerShell. La configurazione consentirà di controllare il numero di azioni controllate e ridurre al minimo il rischio di perdita di eventi. Le configurazioni di controllo personalizzate consentono ai clienti di acquisire solo i dati di controllo necessari.
  • I log di controllo possono essere utilizzati direttamente nella portale di Azure o dal percorso di archiviazione configurato.

Nota

L'abilitazione del controllo in Log Analytics comporta costi in base alle tariffe 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.

Altre risorse

Proteggere i log di controllo

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

Come implementarla

  • Quando si salvano i log di controllo in Archiviazione di Azure, assicurarsi che l'accesso all'account Archiviazione sia limitato ai principi di sicurezza minimi. Controllare chi può accedere all'account di archiviazione.
  • Per altre informazioni, vedere Autorizzazione dell'accesso alle Archiviazione di Azure.

Procedure consigliate

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

  • Quando si controlla l'accesso ai dati sensibili, è consigliabile proteggere i dati con la crittografia dei dati per evitare perdite di informazioni al 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 del comportamento di sicurezza dei database. Include procedure consigliate per garantire che i database siano configurati per soddisfare gli standard di sicurezza, per l'individuazione e la classificazione e il rilevamento dell'accesso ai dati potenzialmente sensibili nei database.

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

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

Come implementarla

  • Abilitare valutazione della vulnerabilità SQL (VA) per analizzare il database per individuare i problemi di sicurezza e per l'esecuzione automatica nei database.

Procedure consigliate

  • Inizialmente, eseguire l'analisi dell'integrità nei database ed eseguire l'iterazione correggendo i controlli con errori che si oppongono alle procedure consigliate per la sicurezza. Configurare le linee di base per le configurazioni accettabili fino a quando l'analisi non viene rimossa o vengono superati tutti i controlli.

  • Configurare analisi periodiche ricorrenti per l'esecuzione una volta alla settimana e configurare la persona pertinente per ricevere messaggi di posta elettronica di riepilogo.

  • Esaminare il riepilogo va a seguito di ogni analisi settimanale. Per eventuali vulnerabilità rilevate, valutare la deriva dal risultato dell'analisi precedente e determinare se il controllo deve essere risolto. Verificare se esiste un motivo legittimo per la modifica della configurazione.

  • Risolvere i controlli e aggiornare le linee di base dove pertinente. Creare elementi ticket per la risoluzione delle azioni e tenere traccia di questi elementi fino a quando non vengono risolti.

Altre risorse

Identificare e contrassegnare i dati sensibili

Individuare colonne che potenzialmente contengono dati sensibili. Ciò che viene considerato dati sensibili dipende in modo rilevante dal cliente, dalla normativa sulla conformità e così via e deve essere valutato dagli utenti responsabili di tali dati. Classificare le colonne per usare scenari avanzati di controllo e protezione basati sulla riservatezza.

Come implementarla

  • Usare l'individuazione e la classificazione dei dati SQL per individuare, classificare, etichettare e proteggere i dati sensibili nei database.
    • Visualizzare le raccomandazioni di classificazione create 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 classificazioni per eventuali campi dati sensibili aggiuntivi che non sono stati individuati 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à DI 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 adattarsi alle esigenze specifiche dell'organizzazione. Personalizzare i criteri di Information Protection (etichette di riservatezza, tipi di informazioni, logica di individuazione) nei criteri di SQL Information Protection in Microsoft Defender per il cloud.

Tenere traccia dell'accesso ai dati sensibili

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

Come implementarla

  • Usare SQL Audit e Classificazione dati in combinazione.

Procedure consigliate

Visualizzare lo stato di sicurezza e conformità

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

Come implementarla

Minacce comuni per la sicurezza e potenziali mitigazioni

Questa sezione illustra le misure di sicurezza da proteggere da determinati vettori di attacco. È previsto che la maggior parte delle mitigazioni possa essere ottenuta seguendo una o più delle linee guida di sicurezza precedenti.

Minaccia di sicurezza: esfiltrazione dei dati

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

Connessione al server su un endpoint pubblico presenta un rischio di esfiltrazione dei dati perché richiede ai clienti di aprire i firewall agli indirizzi IP pubblici.

Scenario 1: un'applicazione in una macchina virtuale di Azure si connette a un database in database SQL di Azure. Un attore non autorizzato ottiene l'accesso alla macchina virtuale e lo compromette. In questo scenario, l'esfiltrazione dei dati significa che un'entità esterna che usa la macchina virtuale non autorizzata si connette al database, copia i dati personali e la archivia in un archivio BLOB o in un'altra database SQL in una sottoscrizione diversa.

Scenario 2: un amministratore del database non autorizzato. Questo scenario viene spesso generato da clienti sensibili alla sicurezza provenienti da settori regolamentati. In questo scenario, un utente con privilegi elevati potrebbe copiare dati da database SQL di Azure a un'altra sottoscrizione non controllata dal proprietario dei dati.

Possibili mitigazioni

Attualmente, database SQL di Azure e Istanza gestita di SQL offre le tecniche seguenti per mitigare le minacce all'esfiltrazione dei dati:

  • Usare una combinazione di regole Consenti e Nega nei gruppi di sicurezza di rete delle macchine virtuali di Azure per controllare le aree a cui è possibile accedere dalla macchina virtuale.
  • Se si usa un server in database SQL, impostare le opzioni seguenti:
    • Consenti la disattivazione dei servizi di Azure.
    • 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 dei dati di una macchina virtuale non autorizzata. Attivare la funzionalità di delega della subnet in una subnet per impostare automaticamente i criteri più restrittivi in una subnet Istanza gestita di SQL.
  • Il problema del DBA Rogue è più esposto con Istanza gestita di SQL poiché ha una superficie di attacco più ampia e i requisiti di rete sono visibili ai clienti. La mitigazione migliore per questa soluzione consiste nell'applicare tutte le procedure descritte in questa guida alla sicurezza per evitare lo scenario DBA Non autorizzato al primo posto (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 della 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 errore. Per gli scenari di emergenza, è pratica comune mantenere i backup dei file di dati e di log. La sezione seguente offre una panoramica generale delle funzionalità integrate in Azure. Offre anche opzioni aggiuntive che possono essere configurate per soddisfare esigenze specifiche:

Passaggi successivi