Procedure consigliate per la sicurezza di Microsoft Purview
Questo articolo fornisce le procedure consigliate per i requisiti di sicurezza comuni per le soluzioni di governance di Microsoft Purview. La strategia di sicurezza descritta segue l'approccio di difesa a più livelli in profondità.
Nota
Queste procedure consigliate riguardano la sicurezza per le soluzioni di governance unificata dei dati di Microsoft Purview. Per altre informazioni sulle soluzioni di rischio e conformità di Microsoft Purview, vedere qui. Per altre informazioni su Microsoft Purview in generale, vedere qui.
Prima di applicare queste raccomandazioni all'ambiente, è consigliabile consultare il team di sicurezza perché alcuni potrebbero non essere applicabili ai requisiti di sicurezza.
Sicurezza di rete
Microsoft Purview è una soluzione PaaS (Platform as a Service) in Azure. È possibile abilitare le funzionalità di sicurezza di rete seguenti per gli account Microsoft Purview:
- Abilitare l'isolamento della rete end-to-end usando il servizio collegamento privato.
- Usare Microsoft Purview Firewall per disabilitare l'accesso pubblico.
- Distribuire regole del gruppo di sicurezza di rete (NSG) per le subnet in cui vengono distribuiti endpoint privati delle origini dati di Azure, endpoint privati di Microsoft Purview e macchine virtuali di runtime self-hosted.
- Implementare Microsoft Purview con endpoint privati gestiti da un'appliance virtuale di rete, ad esempio Firewall di Azure per l'ispezione della rete e il filtro di rete.
Per altre informazioni, vedere Procedure consigliate relative alla connettività ai servizi PaaS di Azure.
Distribuire endpoint privati per gli account Microsoft Purview
Se è necessario usare Microsoft Purview dall'interno della rete privata, è consigliabile usare collegamento privato di Azure Servizio con gli account Microsoft Purview per l'isolamento parziale o end-to-end per connettersi al portale di governance di Microsoft Purview, accedere agli endpoint di Microsoft Purview e analizzare le origini dati.
L'endpoint privato dell'account Microsoft Purview viene usato per aggiungere un altro livello di sicurezza, quindi solo le chiamate client provenienti dall'interno della rete virtuale possono accedere all'account Microsoft Purview. Questo endpoint privato è anche un prerequisito per l'endpoint privato del portale.
L'endpoint privato del portale di Microsoft Purview è necessario per abilitare la connettività al portale di governance di Microsoft Purview usando una rete privata.
Microsoft Purview può analizzare le origini dati in Azure o in un ambiente locale usando endpoint privati di inserimento.
- Per analizzare la piattaforma Azure come origini dati del servizio , vedere Matrice di supporto per l'analisi delle origini dati tramite l'endpoint privato di inserimento.
- Se si distribuisce Microsoft Purview con l'isolamento della rete end-to-end, per analizzare le origini dati di Azure, queste origini dati devono essere configurate anche con endpoint privati.
- Esaminare le limitazioni note.
Per altre informazioni, vedere Architettura di rete e procedure consigliate di Microsoft Purview.
Bloccare l'accesso pubblico usando il firewall Microsoft Purview
È possibile disabilitare l'accesso pubblico di Microsoft Purview per interrompere completamente l'accesso all'account Microsoft Purview da Internet pubblico. In questo caso, è necessario considerare i requisiti seguenti:
- Microsoft Purview deve essere distribuito in base allo scenario di isolamento della rete end-to-end.
- Per accedere al portale di governance di Microsoft Purview e agli endpoint di Microsoft Purview, è necessario usare un computer di gestione connesso alla rete privata per accedere a Microsoft Purview tramite una rete privata.
- Esaminare le limitazioni note.
- Per analizzare la piattaforma Azure come origini dati del servizio, vedere Matrice di supporto per l'analisi delle origini dati tramite l'endpoint privato di inserimento.
- Le origini dati di Azure devono essere configurate anche con endpoint privati.
- Per analizzare le origini dati, è necessario usare un runtime di integrazione self-hosted.
Per altre informazioni, vedere Firewall per limitare l'accesso pubblico.
Usare i gruppi di sicurezza di rete
È possibile usare un gruppo di sicurezza di rete di Azure per filtrare il traffico di rete da e verso le risorse di Azure in una rete virtuale di Azure. Un gruppo di sicurezza di rete contiene regole di sicurezza che consentono o negano il traffico di rete in ingresso o in uscita da diversi tipi di risorse di Azure. Per ogni regola, è possibile specificare origine e destinazione, porta e protocollo.
I gruppi di sicurezza di rete possono essere applicati alle subnet dell'interfaccia di rete o delle reti virtuali di Azure, in cui vengono distribuiti endpoint privati di Microsoft Purview, macchine virtuali di runtime di integrazione self-hosted e origini dati di Azure.
Per altre informazioni, vedere Applicare regole del gruppo di sicurezza di rete per gli endpoint privati.
Le regole del gruppo di sicurezza di rete seguenti sono necessarie nelle origini dati per l'analisi di Microsoft Purview:
| Direzione | Origine | Intervallo di porte di origine | Destinazione | Porta di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|---|
| Inbound | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Origini dati indirizzi IP privati o subnet | 443 | Qualsiasi | Consenti |
Le regole del gruppo di sicurezza di rete seguenti sono necessarie dai computer di gestione per accedere al portale di governance di Microsoft Purview:
| Direzione | Origine | Intervallo di porte di origine | Destinazione | Porta di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|---|
| In uscita | Indirizzi IP privati o subnet dei computer di gestione | * | Subnet o indirizzi IP dell'endpoint privato dell'account e del portale Microsoft Purview | 443 | Qualsiasi | Consenti |
| In uscita | Indirizzi IP privati o subnet dei computer di gestione | * | Tag di servizio: AzureCloud |
443 | Qualsiasi | Consenti |
Le regole del gruppo di sicurezza di rete seguenti sono necessarie nelle macchine virtuali del runtime di integrazione self-hosted per l'analisi e l'inserimento di metadati di Microsoft Purview:
Importante
Valutare la possibilità di aggiungere regole aggiuntive con i tag del servizio pertinenti, in base ai tipi di origine dati.
| Direzione | Origine | Intervallo di porte di origine | Destinazione | Porta di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|---|
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Origini dati indirizzi IP privati o subnet | 443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Subnet o indirizzi IP dell'account Microsoft Purview e dell'endpoint privato di inserimento | 443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Tag di servizio: Servicebus |
443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Tag di servizio: Storage |
443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Tag di servizio: AzureActiveDirectory |
443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Tag di servizio: DataFactory |
443 | Qualsiasi | Consenti |
| In uscita | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Tag di servizio: KeyVault |
443 | Qualsiasi | Consenti |
Per gli endpoint privati dell'account, del portale e dell'inserimento di Microsoft Purview sono necessarie le regole del gruppo di sicurezza di rete seguenti:
| Direzione | Origine | Intervallo di porte di origine | Destinazione | Porta di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|---|
| Inbound | Subnet o indirizzi IP privati delle macchine virtuali di runtime di integrazione self-hosted | * | Subnet o indirizzi IP dell'account Microsoft Purview e dell'endpoint privato di inserimento | 443 | Qualsiasi | Consenti |
| Inbound | Indirizzi IP privati o subnet dei computer di gestione | * | Subnet o indirizzi IP dell'account Microsoft Purview e dell'endpoint privato di inserimento | 443 | Qualsiasi | Consenti |
Per altre informazioni, vedere Requisiti di rete del runtime di integrazione self-hosted.
Gestione degli accessi
Gestione delle identità e degli accessi fornisce la base di un'ampia percentuale di garanzie di sicurezza. Consente l'accesso in base all'autenticazione delle identità e ai controlli di autorizzazione nei servizi cloud. Questi controlli proteggono dati e risorse e decidono quali richieste devono essere consentite.
Per quanto riguarda i ruoli e la gestione degli accessi in Microsoft Purview, è possibile applicare le procedure consigliate di sicurezza seguenti:
- Definire ruoli e responsabilità per gestire Microsoft Purview nel piano di controllo e nel piano dati:
- Definire ruoli e attività necessari per distribuire e gestire Microsoft Purview all'interno di una sottoscrizione di Azure.
- Definire i ruoli e le attività necessari per eseguire la gestione e la governance dei dati usando Microsoft Purview.
- Assegnare ruoli ai gruppi di Azure Active Directory invece di assegnare ruoli ai singoli utenti.
- Usare Gestione diritti di Azure Active Directory per eseguire il mapping dell'accesso utente ai gruppi di Azure AD usando i pacchetti di accesso.
- Applicare l'autenticazione a più fattori per gli utenti di Microsoft Purview, in particolare per gli utenti con ruoli con privilegi, ad esempio amministratori della raccolta, amministratori dell'origine dati o curatori dei dati.
Gestire un account Microsoft Purview nel piano di controllo e nel piano dati
Il piano di controllo si riferisce a tutte le operazioni correlate alla distribuzione e alla gestione di Microsoft Purview in Azure Resource Manager.
Il piano dati si riferisce a tutte le operazioni correlate all'interazione con Microsoft Purview all'interno di Mappa dati e Data Catalog.
È possibile assegnare ruoli del piano di controllo e del piano dati a utenti, gruppi di sicurezza ed entità servizio dal tenant di Azure Active Directory associato alla sottoscrizione di Azure dell'istanza di Microsoft Purview.
Esempi di operazioni del piano di controllo e operazioni del piano dati:
| Attività | Ambito | Ruolo consigliato | Quali ruoli usare? |
|---|---|---|---|
| Distribuire un account Microsoft Purview | Piano di controllo | Proprietario o collaboratore della sottoscrizione di Azure | Ruoli del controllo degli accessi in base al ruolo di Azure |
| Configurare un endpoint privato per Microsoft Purview | Piano di controllo | Collaboratore | Ruoli del controllo degli accessi in base al ruolo di Azure |
| Eliminare un account Microsoft Purview | Piano di controllo | Collaboratore | Ruoli del controllo degli accessi in base al ruolo di Azure |
| Aggiungere o gestire un runtime di integrazione self-hosted (SHIR) | Piano di controllo | Amministratore dell'origine dati | Ruoli di Microsoft Purview |
| Visualizzare le metriche di Microsoft Purview per ottenere le unità di capacità correnti | Piano di controllo | Lettore | Ruoli del controllo degli accessi in base al ruolo di Azure |
| Creare una raccolta | Piano dati | Raccolta Amministrazione | Ruoli di Microsoft Purview |
| Registrare un'origine dati | Piano dati | Raccolta Amministrazione | Ruoli di Microsoft Purview |
| Analizzare un SQL Server | Piano dati | Amministratore dell'origine dati e lettore di dati o curatore dei dati | Ruoli di Microsoft Purview |
| Cerca all'interno di Microsoft Purview Data Catalog | Piano dati | Amministratore dell'origine dati e lettore di dati o curatore dei dati | Ruoli di Microsoft Purview |
I ruoli del piano di Microsoft Purview vengono definiti e gestiti all'interno dell'istanza di Microsoft Purview nelle raccolte di Microsoft Purview. Per altre informazioni, vedere Controllo di accesso in Microsoft Purview.
Seguire le raccomandazioni sull'accesso in base al ruolo di Azure per le attività del piano di controllo di Azure.
Autenticazione e autorizzazione
Per ottenere l'accesso a Microsoft Purview, gli utenti devono essere autenticati e autorizzati. L'autenticazione è il processo per dimostrare all'utente chi dichiara di essere. L'autorizzazione si riferisce al controllo dell'accesso all'interno di Microsoft Purview assegnato alle raccolte.
Azure Active Directory viene usato per fornire meccanismi di autenticazione e autorizzazione per Microsoft Purview all'interno delle raccolte. È possibile assegnare ruoli di Microsoft Purview alle entità di sicurezza seguenti dal tenant di Azure Active Directory associato alla sottoscrizione di Azure in cui è ospitata l'istanza di Microsoft Purview:
- Utenti e utenti guest (se sono già stati aggiunti al tenant di Azure AD)
- Gruppi di sicurezza
- Identità gestite
- Entità servizio
I ruoli con granularità fine di Microsoft Purview possono essere assegnati a una gerarchia di raccolte flessibile all'interno dell'istanza di Microsoft Purview.
Definire il modello con privilegi minimi
Come regola generale, limitare l'accesso in base alla necessità di conoscere e ai principi di sicurezza con privilegi minimi è fondamentale per le organizzazioni che vogliono applicare criteri di sicurezza per l'accesso ai dati.
In Microsoft Purview, le origini dati, gli asset e le analisi possono essere organizzati usando le raccolte di Microsoft Purview. Le raccolte sono un raggruppamento gerarchico di metadati in Microsoft Purview, ma allo stesso tempo forniscono un meccanismo per gestire l'accesso a Microsoft Purview. I ruoli in Microsoft Purview possono essere assegnati a una raccolta in base alla gerarchia della raccolta.
Usare le raccolte di Microsoft Purview per implementare la gerarchia dei metadati dell'organizzazione per la gestione centralizzata o delegata e la gerarchia di governance in base al modello con privilegi minimi.
Seguire il modello di accesso con privilegi minimi quando si assegnano ruoli all'interno delle raccolte di Microsoft Purview separando i compiti all'interno del team e concedendo solo la quantità di accesso agli utenti che devono eseguire i processi.
Per altre informazioni su come assegnare un modello di accesso con privilegi minimi in Microsoft Purview, basato sulla gerarchia della raccolta di Microsoft Purview, vedere Controllo di accesso in Microsoft Purview.
Minore esposizione di account con privilegi
La protezione dell'accesso con privilegi è un primo passaggio fondamentale per proteggere gli asset aziendali. Riducendo al minimo il numero di persone che hanno accesso a informazioni o risorse sicure, si riduce la possibilità che un utente malintenzionato abbia accesso o che un utente autorizzato inavvertitamente influisca su una risorsa sensibile.
Ridurre il numero di utenti con accesso in scrittura all'interno dell'istanza di Microsoft Purview. Mantenere il numero minimo di amministratori della raccolta e ruoli di curatore dati nella raccolta radice.
Usare l'autenticazione a più fattori e l'accesso condizionale
Azure Active Directory Multi-Factor Authentication offre un altro livello di sicurezza e autenticazione. Per una maggiore sicurezza, è consigliabile applicare criteri di accesso condizionale per tutti gli account con privilegi.
Usando i criteri di accesso condizionale di Azure Active Directory, applicare Azure AD Multi-Factor Authentication all'accesso per tutti i singoli utenti assegnati ai ruoli di Microsoft Purview con accesso modificato all'interno delle istanze di Microsoft Purview: raccolta Amministrazione, origine dati Amministrazione, Data Curator.
Abilitare l'autenticazione a più fattori per gli account amministratore e assicurarsi che gli utenti dell'account amministratore si siano registrati per MFA.
È possibile definire i criteri di accesso condizionale selezionando Microsoft Purview come app cloud.
Impedire l'eliminazione accidentale di account Microsoft Purview
In Azure è possibile applicare blocchi di risorse a una sottoscrizione di Azure, a un gruppo di risorse o a una risorsa per impedire l'eliminazione o la modifica accidentale per le risorse critiche.
Abilitare il blocco delle risorse di Azure per gli account Microsoft Purview per impedire l'eliminazione accidentale di istanze di Microsoft Purview nelle sottoscrizioni di Azure.
L'aggiunta di un CanNotDelete blocco o ReadOnly all'account Microsoft Purview non impedisce operazioni di eliminazione o modifica all'interno del piano dati di Microsoft Purview, ma impedisce qualsiasi operazione nel piano di controllo, ad esempio l'eliminazione dell'account Microsoft Purview, la distribuzione di un endpoint privato o la configurazione delle impostazioni di diagnostica.
Per altre informazioni, vedere Informazioni sull'ambito dei blocchi.
I blocchi delle risorse possono essere assegnati a risorse o gruppi di risorse di Microsoft Purview, tuttavia non è possibile assegnare un blocco di risorse di Azure alle risorse gestite o al gruppo di risorse gestite di Microsoft Purview.
Implementare una strategia di break glass
Pianificare una strategia di interruzione per il tenant di Azure Active Directory, la sottoscrizione di Azure e gli account Microsoft Purview per impedire il blocco dell'account a livello di tenant.
Per altre informazioni sulla pianificazione dell'accesso di emergenza di Azure AD e Azure, vedere Gestire gli account di accesso di emergenza in Azure AD.
Per altre informazioni sulla strategia di rottura del vetro di Microsoft Purview, vedere Procedure consigliate per le raccolte di Microsoft Purview e consigli di progettazione.
Protezione dalle minacce e prevenzione dell'esfiltrazione dei dati
Microsoft Purview offre informazioni approfondite sulla sensibilità dei dati, il che rende prezioso per i team di sicurezza che usano Microsoft Defender per il cloud per gestire il comportamento di sicurezza dell'organizzazione e proteggersi dalle minacce ai carichi di lavoro. Le risorse dati rimangono una destinazione comune per gli attori malintenzionati, rendendo fondamentale per i team di sicurezza identificare, assegnare priorità e proteggere le risorse dei dati sensibili nei propri ambienti cloud. Per risolvere questa sfida, viene annunciata l'integrazione tra Microsoft Defender per cloud e Microsoft Purview in anteprima pubblica.
Integrazione con Microsoft 365 e Microsoft Defender per il cloud
Spesso, una delle maggiori sfide per l'organizzazione della sicurezza in un'azienda consiste nell'identificare e proteggere gli asset in base alla loro criticità e sensibilità. Microsoft ha recentemente annunciato l'integrazione tra Microsoft Purview e Microsoft Defender per il cloud in anteprima pubblica per contribuire a superare queste sfide.
Se sono state estese le etichette di riservatezza di Microsoft 365 per asset e colonne di database in Microsoft Purview, è possibile tenere traccia degli asset di grande valore usando Microsoft Defender for Cloud dall'inventario, dagli avvisi e dalle raccomandazioni in base alle etichette di riservatezza rilevate dagli asset.
Per consigli, sono stati forniti controlli di sicurezza che consentono di comprendere l'importanza di ogni raccomandazione per il comportamento di sicurezza complessivo. Microsoft Defender per il cloud include un valore di punteggio sicuro per ogni controllo che consente di assegnare priorità al lavoro di sicurezza. Altre informazioni sono disponibili nei controlli di sicurezza e nelle relative raccomandazioni.
Per gli avvisi, sono state assegnate etichette di gravità a ogni avviso per facilitare la definizione della priorità dell'ordine di partecipazione a ogni avviso. Per altre informazioni, vedere Come vengono classificati gli avvisi?
Per altre informazioni, vedere Integrare Microsoft Purview con i prodotti di sicurezza di Azure.
Azure Information Protection
Proteggere l'estrazione e l'archiviazione dei metadati
Microsoft Purview è una soluzione di governance dei dati nel cloud. È possibile registrare ed analizzare origini dati diverse da vari sistemi dati dagli ambienti locali, Azure o multicloud in Microsoft Purview. Mentre l'origine dati viene registrata e analizzata in Microsoft Purview, i dati e le origini dati effettivi rimangono nelle posizioni originali, solo i metadati vengono estratti dalle origini dati e archiviati in Microsoft Purview Data Map, il che significa che non è necessario spostare i dati dall'area o dalla posizione originale per estrarre i metadati in Microsoft Purview.
Quando viene distribuito un account Microsoft Purview, viene distribuito anche un gruppo di risorse gestito nella sottoscrizione di Azure. Un account di archiviazione di Azure gestito viene distribuito all'interno di questo gruppo di risorse. L'account di archiviazione gestito viene usato per inserire i metadati dalle origini dati durante l'analisi. Poiché queste risorse vengono utilizzate da Microsoft Purview, non è possibile accedervi da altri utenti o entità, ad eccezione dell'account Microsoft Purview. Questo perché un'assegnazione di rifiuto del controllo degli accessi in base al ruolo di Azure viene aggiunta automaticamente per tutte le entità a questo gruppo di risorse al momento della distribuzione dell'account Microsoft Purview, impedendo qualsiasi operazione CRUD su queste risorse se non vengono avviate da Microsoft Purview.
Dove vengono archiviati i metadati?
Microsoft Purview estrae solo i metadati da sistemi di origine dati diversi in Microsoft Purview Data Map durante il processo di analisi.
È possibile distribuire un account Microsoft Purview all'interno della sottoscrizione di Azure in qualsiasi area di Azure supportata.
Tutti i metadati vengono archiviati all'interno di Mappa dati all'interno dell'istanza di Microsoft Purview. Ciò significa che i metadati vengono archiviati nella stessa area dell'istanza di Microsoft Purview.
Come vengono estratti i metadati dalle origini dati?
Microsoft Purview consente di usare una delle opzioni seguenti per estrarre metadati da origini dati:
Runtime di Azure. I dati dei metadati vengono estratti ed elaborati all'interno della stessa area delle origini dati.
Viene avviata un'analisi manuale o automatica dal Microsoft Purview Data Map tramite il runtime di integrazione di Azure.
Il runtime di integrazione di Azure si connette all'origine dati per estrarre i metadati.
I metadati vengono accodati nell'archiviazione gestita di Microsoft Purview e archiviati in Archiviazione BLOB di Azure.
I metadati vengono inviati al Microsoft Purview Data Map.
Runtime di integrazione self-hosted. I metadati vengono estratti ed elaborati dal runtime di integrazione self-hosted all'interno della memoria delle macchine virtuali del runtime di integrazione self-hosted prima che vengano inviati a Microsoft Purview Data Map. In questo caso, i clienti devono distribuire e gestire una o più macchine virtuali basate su Windows self-hosted integration runtime all'interno delle sottoscrizioni di Azure o negli ambienti locali. L'analisi delle origini dati locali e basate su macchine virtuali richiede sempre l'uso di un runtime di integrazione self-hosted. Il runtime di integrazione di Azure non è supportato per queste origini dati. I passaggi seguenti mostrano il flusso di comunicazione a un livello elevato quando si usa un runtime di integrazione self-hosted per analizzare un'origine dati.
Viene attivata un'analisi manuale o automatica. Microsoft Purview si connette ad Azure Key Vault per recuperare le credenziali per accedere a un'origine dati.
L'analisi viene avviata dal Microsoft Purview Data Map tramite un runtime di integrazione self-hosted.
Il servizio runtime di integrazione self-hosted dalla macchina virtuale si connette all'origine dati per estrarre i metadati.
I metadati vengono elaborati nella memoria della macchina virtuale per il runtime di integrazione self-hosted. I metadati vengono accodati nell'archiviazione gestita di Microsoft Purview e quindi archiviati in Archiviazione BLOB di Azure.
I metadati vengono inviati al Microsoft Purview Data Map.
Se è necessario estrarre metadati da origini dati con dati sensibili che non possono lasciare il limite della rete locale, è consigliabile distribuire la macchina virtuale di runtime di integrazione self-hosted all'interno della rete aziendale, in cui si trovano le origini dati, estrarre ed elaborare i metadati in locale e inviare solo metadati a Microsoft Purview.
Viene attivata un'analisi manuale o automatica. Microsoft Purview si connette ad Azure Key Vault per recuperare le credenziali per accedere a un'origine dati.
L'analisi viene avviata tramite il runtime di integrazione self-hosted locale.
Il servizio runtime di integrazione self-hosted dalla macchina virtuale si connette all'origine dati per estrarre i metadati.
I metadati vengono elaborati nella memoria della macchina virtuale per il runtime di integrazione self-hosted. I metadati vengono accodati nell'archiviazione gestita di Microsoft Purview e quindi archiviati in Archiviazione BLOB di Azure. I dati effettivi non lasciano mai il limite della rete.
I metadati vengono inviati al Microsoft Purview Data Map.
Protezione e crittografia delle informazioni
Azure offre molti meccanismi per mantenere i dati privati inattivi e man mano che si sposta da una posizione a un'altra. Per Microsoft Purview, i dati vengono crittografati inattivi usando chiavi gestite da Microsoft e quando i dati sono in transito, usando Transport Layer Security (TLS) v1.2 o versione successiva.
Transport Layer Security (Crittografia in transito)
I dati in transito (noti anche come dati in movimento) vengono crittografati in Microsoft Purview.
Per aggiungere un altro livello di sicurezza oltre ai controlli di accesso, Microsoft Purview protegge i dati dei clienti crittografando i dati in movimento con Transport Layer Security (TLS) e proteggendo i dati in transito da attacchi "fuori banda" (ad esempio l'acquisizione del traffico). Usa la crittografia per assicurarsi che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.
Microsoft Purview supporta la crittografia dei dati in transito con Transport Layer Security (TLS) v1.2 o versione successiva.
Per altre informazioni, vedere Crittografare le informazioni sensibili in transito.
Transparent Data Encryption (Encryption-at-rest)
I dati inattivi includono informazioni che risiedono nell'archiviazione permanente su supporti fisici, in qualsiasi formato digitale. Il supporto può includere file su supporti magnetici o ottici, dati archiviati e backup dei dati all'interno delle aree di Azure.
Per aggiungere un altro livello di sicurezza oltre ai controlli di accesso, Microsoft Purview crittografa i dati inattivi per la protezione da attacchi "fuori banda", ad esempio l'accesso all'archiviazione sottostante. Usa la crittografia con chiavi gestite da Microsoft. Questa procedura consente di assicurarsi che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.
Per altre informazioni, vedere Crittografare i dati sensibili inattivi.
Configurazione facoltativa dello spazio dei nomi di Hub eventi
Ogni account Microsoft Purview può configurare hub eventi accessibili tramite l'endpoint Atlas Kafka. Questa opzione può essere abilitata durante la creazione in Configurazione o dal portale di Azure in Configurazione Kafka. È consigliabile abilitare l'hub eventi gestito facoltativo solo se viene usato per distribuire eventi in o all'esterno di Microsoft Purview Account Data Map. Per rimuovere questo punto di distribuzione delle informazioni, non configurare questi endpoint o rimuoverli.
Per rimuovere gli spazi dei nomi configurati di Hub eventi, è possibile seguire questa procedura:
- Cercare e aprire l'account Microsoft Purview nel portale di Azure.
- Selezionare Configurazione kafka nella pagina impostazioni dell'account Microsoft Purview nel portale di Azure.
- Selezionare gli hub eventi da disabilitare. Gli hub hook inviano messaggi a Microsoft Purview. Gli hub di notifica ricevono notifiche.
- Selezionare Rimuovi per salvare la scelta e avviare il processo di disabilitazione. Il completamento può richiedere alcuni minuti.
Nota
Se si dispone di un endpoint privato di inserimento quando si disabilita questo spazio dei nomi di Hub eventi, dopo aver disabilitato l'endpoint privato di inserimento può essere visualizzato come disconnesso.
Per altre informazioni sulla configurazione di questi spazi dei nomi di Hub eventi, vedere gli argomenti: Configurare hub eventi per Atlas Kafka
Gestione delle credenziali
Per estrarre i metadati da un sistema di origine dati in Microsoft Purview Data Map, è necessario registrare ed analizzare i sistemi di origine dati in Microsoft Purview Data Map. Per automatizzare questo processo, sono stati resi disponibili connettori per diversi sistemi di origine dati in Microsoft Purview per semplificare il processo di registrazione e analisi.
Per connettersi a un'origine dati, Microsoft Purview richiede una credenziale con accesso in sola lettura al sistema dell'origine dati.
È consigliabile assegnare priorità all'uso delle opzioni delle credenziali seguenti per l'analisi, quando possibile:
- Identità gestita di Microsoft Purview
- Identità gestita assegnata dall'utente
- Entità servizio
- Altre opzioni, ad esempio Chiave account, Autenticazione SQL e così via.
Se si usano opzioni anziché identità gestite, tutte le credenziali devono essere archiviate e protette all'interno di un insieme di credenziali delle chiavi di Azure. Microsoft Purview richiede l'accesso get/list al segreto nella risorsa Key Vault di Azure.
Come regola generale, è possibile usare le opzioni seguenti per configurare il runtime di integrazione e le credenziali per analizzare i sistemi di origine dati:
| Scenario | Opzione di runtime | Credenziali supportate |
|---|---|---|
| L'origine dati è una piattaforma come servizio di Azure, ad esempio Azure Data Lake Storage Gen 2 o Azure SQL all'interno della rete pubblica | Opzione 1: Runtime di Azure | Identità gestita di Microsoft Purview, entità servizio o chiave di accesso/autenticazione SQL (a seconda del tipo di origine dati di Azure) |
| L'origine dati è una piattaforma come servizio di Azure, ad esempio Azure Data Lake Storage Gen 2 o Azure SQL all'interno della rete pubblica | Opzione 2: Runtime di integrazione self-hosted | Entità servizio o chiave di accesso/autenticazione SQL (a seconda del tipo di origine dati di Azure) |
| L'origine dati è una piattaforma come servizio di Azure, ad esempio Azure Data Lake Storage Gen 2 o Azure SQL all'interno della rete privata usando collegamento privato di Azure Servizio | Runtime di integrazione self-hosted | Entità servizio o chiave di accesso/autenticazione SQL (a seconda del tipo di origine dati di Azure) |
| L'origine dati si trova all'interno di una macchina virtuale IaaS di Azure, ad esempio SQL Server | Runtime di integrazione self-hosted distribuito in Azure | Autenticazione SQL o autenticazione di base (a seconda del tipo di origine dati di Azure) |
| L'origine dati si trova all'interno di un sistema locale, ad esempio SQL Server o Oracle | Runtime di integrazione self-hosted distribuito in Azure o nella rete locale | Autenticazione SQL o autenticazione di base (a seconda del tipo di origine dati di Azure) |
| Multicloud | Runtime di Azure o runtime di integrazione self-hosted basato sui tipi di origine dati | Le opzioni delle credenziali supportate variano in base ai tipi di origini dati |
| Tenant di Power BI | Azure Runtime | Identità gestita di Microsoft Purview |
Usare questa guida per altre informazioni su ogni origine e sulle relative opzioni di autenticazione supportate.
Altre raccomandazioni
Applicare le procedure consigliate per la sicurezza per le macchine virtuali di runtime self-hosted
Prendere in considerazione la protezione della distribuzione e della gestione delle macchine virtuali di runtime di integrazione self-hosted in Azure o nell'ambiente locale, se il runtime di integrazione self-hosted viene usato per analizzare le origini dati in Microsoft Purview.
Per le macchine virtuali di runtime di integrazione self-hosted distribuite come macchine virtuali in Azure, seguire le indicazioni sulle procedure consigliate per la sicurezza per le macchine virtuali Windows.
- Bloccare il traffico in ingresso verso le macchine virtuali usando i gruppi di sicurezza di rete e l'accesso Just-in-Time di Azure Defender.
- Installare antivirus o antimalware.
- Distribuire Azure Defender per ottenere informazioni dettagliate su qualsiasi potenziale anomalia nelle macchine virtuali.
- Limitare la quantità di software nelle macchine virtuali del runtime di integrazione self-hosted. Anche se non è obbligatorio avere una macchina virtuale dedicata per un runtime self-hosted per Microsoft Purview, è consigliabile usare macchine virtuali dedicate soprattutto per gli ambienti di produzione.
- Monitorare le macchine virtuali usando Monitoraggio di Azure per le macchine virtuali. Usando l'agente di Log Analytics, è possibile acquisire contenuto, ad esempio le metriche delle prestazioni, per modificare la capacità necessaria per le macchine virtuali.
- Integrando le macchine virtuali con Microsoft Defender per il cloud, è possibile prevenire, rilevare e rispondere alle minacce.
- Mantenere aggiornati i computer. È possibile abilitare la Windows Update automatica o usare Gestione aggiornamenti in Automazione di Azure per gestire gli aggiornamenti a livello di sistema operativo per il sistema operativo.
- Usare più computer per una maggiore resilienza e disponibilità. È possibile distribuire e registrare più runtime di integrazione self-hosted per distribuire le analisi in più computer di runtime di integrazione self-hosted o distribuire il runtime di integrazione self-hosted in un set di scalabilità di macchine virtuali per una maggiore ridondanza e scalabilità.
- Facoltativamente, è possibile pianificare l'abilitazione del backup di Azure dalle macchine virtuali del runtime di integrazione self-hosted per aumentare il tempo di ripristino di una macchina virtuale di runtime di integrazione self-hosted in caso di emergenza a livello di macchina virtuale.