Architettura di rete e procedure consigliate di Microsoft Purview

Le soluzioni di governance di Microsoft Purview sono soluzioni PaaS (Platform as a Service) per la governance dei dati. Gli account Microsoft Purview hanno endpoint pubblici accessibili tramite Internet per connettersi al servizio. Tuttavia, tutti gli endpoint sono protetti tramite account di accesso Microsoft Entra e controllo degli accessi in base al ruolo.

Per un ulteriore livello di sicurezza, è possibile creare endpoint privati per l'account Microsoft Purview. Si otterrà un indirizzo IP privato dalla rete virtuale in Azure all'account Microsoft Purview e alle relative risorse gestite. Questo indirizzo limiterà tutto il traffico tra la rete virtuale e l'account Microsoft Purview a un collegamento privato per l'interazione dell'utente con le API e il portale di governance di Microsoft Purview o per l'analisi e l'inserimento.

Attualmente, il firewall Microsoft Purview fornisce il controllo di accesso per l'endpoint pubblico dell'account purview. È possibile usare il firewall per consentire tutto l'accesso o bloccare tutto l'accesso tramite l'endpoint pubblico quando si usano endpoint privati. Per altre informazioni, vedere Opzioni del firewall di Microsoft Purview

In base ai requisiti di rete, connettività e sicurezza, è possibile configurare e gestire gli account Microsoft Purview per accedere ai servizi sottostanti o all'inserimento. Usare questa guida alle procedure consigliate per definire e preparare l'ambiente di rete in modo da poter accedere a Microsoft Purview ed analizzare le origini dati dalla rete o dal cloud.

Questa guida illustra le opzioni di rete seguenti:

• Usare gli endpoint pubblici di Azure.
• Usare endpoint privati.
• Usare gli endpoint privati e consentire l'accesso pubblico nello stesso account Microsoft Purview.
• Usare gli endpoint pubblici di Azure per accedere al portale di governance di Microsoft Purview e agli endpoint privati per l'inserimento.

Questa guida descrive alcuni degli scenari di architettura di rete più comuni per Microsoft Purview. Anche se non si è limitati a questi scenari, tenere presente le limitazioni del servizio quando si pianifica la rete per gli account Microsoft Purview.

Prerequisiti

Per comprendere quale opzione di rete è più adatta all'ambiente in uso, è consigliabile eseguire prima le azioni seguenti:

• Esaminare la topologia di rete e i requisiti di sicurezza prima di registrare ed analizzare le origini dati in Microsoft Purview. Per altre informazioni, vedere Definire una topologia di rete di Azure.

• Definire il modello di connettività di rete per i servizi PaaS.

Opzione 1: Usare endpoint pubblici

Per impostazione predefinita, è possibile usare gli account Microsoft Purview tramite gli endpoint pubblici accessibili tramite Internet. Se si hanno i requisiti seguenti, consentire le reti pubbliche nell'account Microsoft Purview:

• Non è necessaria alcuna connettività privata durante l'analisi o la connessione agli endpoint di Microsoft Purview.
• Tutte le origini dati sono solo applicazioni SaaS (Software-as-a-Service).
• Tutte le origini dati hanno un endpoint pubblico accessibile tramite Internet.
• Gli utenti aziendali richiedono l'accesso a un account Microsoft Purview e al portale di governance di Microsoft Purview tramite Internet.

Opzioni di runtime di integrazione

Per analizzare le origini dati mentre il firewall dell'account Microsoft Purview è impostato per consentire l'accesso pubblico, è possibile usare tutti i tipi di runtime di integrazione, ovvero il runtime di integrazione di Azure, il runtime di integrazione della rete virtuale gestita e un runtime di integrazione self-hosted. Per altre informazioni , vedere Scegliere la configurazione di runtime di integrazione corretta per lo scenario.

Ecco alcune procedure consigliate:

• Se applicabile, è consigliabile usare il runtime di integrazione di Azure o il runtime di integrazione della rete virtuale gestita per analizzare le origini dati, per ridurre i costi e il sovraccarico amministrativo.

• I passaggi seguenti mostrano il flusso di comunicazione a un livello elevato quando si usa il runtime di integrazione di Azure per analizzare un'origine dati:

  

  Nota

  Questo grafico si applica solo agli account Microsoft Purview creati dopo il 15 dicembre 2023 (o distribuiti con la versione API 2023-05-01-preview in poi).

  1. Viene avviata un'analisi manuale o automatica dal Microsoft Purview Data Map tramite il runtime di integrazione di Azure.

  2. Il runtime di integrazione di Azure si connette all'origine dati per estrarre i metadati.

  3. I metadati vengono accodati nell'account di archiviazione di inserimento di Microsoft Purview e archiviati temporaneamente in Archiviazione BLOB di Azure.

  4. I metadati vengono inviati al Microsoft Purview Data Map.

• 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. Il primo diagramma mostra uno scenario in cui le risorse si trovano in Azure o in una macchina virtuale in Azure. Il secondo diagramma mostra uno scenario con risorse locali. I passaggi tra i due sono gli stessi dal punto di vista di Microsoft Purview:

  

  

  1. 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.

  2. L'analisi viene avviata dal Microsoft Purview Data Map tramite un runtime di integrazione self-hosted.

  3. Il servizio di runtime di integrazione self-hosted dalla macchina virtuale o dal computer locale si connette all'origine dati per estrarre i metadati.

  4. I metadati vengono elaborati nella memoria del computer per il runtime di integrazione self-hosted. I metadati vengono accodati nell'archiviazione di inserimento di Microsoft Purview e quindi archiviati temporaneamente in Archiviazione BLOB di Azure. I dati effettivi non lasciano mai il limite della rete.

  5. I metadati vengono inviati al Microsoft Purview Data Map.

Opzioni di autenticazione

Quando si esegue l'analisi di un'origine dati in Microsoft Purview, è necessario fornire una credenziale. Microsoft Purview può quindi leggere i metadati degli asset dall'origine dati usando il runtime di integrazione. Per informazioni dettagliate sui tipi di autenticazione supportati e sulle autorizzazioni necessarie, vedere ogni articolo sull'origine dati . Le opzioni e i requisiti di autenticazione variano in base ai fattori seguenti:

• Tipo di origine dati. Ad esempio, se l'origine dati è Azure SQL database, è necessario usare un account di accesso con db_datareader accesso a ogni database. Può trattarsi di un'identità gestita assegnata dall'utente o di un'identità gestita di Microsoft Purview. In alternativa, può essere un'entità servizio in Microsoft Entra ID aggiunta a database SQL come db_datareader.

  Se l'origine dati è Archiviazione BLOB di Azure, è possibile usare un'identità gestita di Microsoft Purview o un'entità servizio in Microsoft Entra ID aggiunta come ruolo lettore dati di archiviazione BLOB nell'account di archiviazione di Azure. In alternativa, usare la chiave dell'account di archiviazione.

• Tipo di autenticazione. È consigliabile usare un'identità gestita di Microsoft Purview per analizzare le origini dati di Azure quando possibile, per ridurre il sovraccarico amministrativo. Per qualsiasi altro tipo di autenticazione, è necessario configurare le credenziali per l'autenticazione di origine all'interno di Microsoft Purview:

  1. Generare un segreto in un insieme di credenziali delle chiavi di Azure.
  2. Registrare l'insieme di credenziali delle chiavi all'interno di Microsoft Purview.
  3. All'interno di Microsoft Purview creare una nuova credenziale usando il segreto salvato nell'insieme di credenziali delle chiavi.

• Tipo di runtime usato nell'analisi. Attualmente, non è possibile usare un'identità gestita di Microsoft Purview con un runtime di integrazione self-hosted.

Altre considerazioni

• Se si sceglie di analizzare le origini dati usando endpoint pubblici, le macchine virtuali del runtime di integrazione self-hosted devono avere accesso in uscita alle origini dati e agli endpoint di Azure.
• Le macchine virtuali del runtime di integrazione self-hosted devono avere connettività in uscita agli endpoint di Azure.

Opzione 2: Usare endpoint privati

Analogamente ad altre soluzioni PaaS, Microsoft Purview non supporta la distribuzione diretta in una rete virtuale. Non è quindi possibile usare determinate funzionalità di rete con le risorse dell'offerta, ad esempio gruppi di sicurezza di rete, tabelle di route o altre appliance dipendenti dalla rete, ad esempio Firewall di Azure. È invece possibile usare endpoint privati che possono essere abilitati nella rete virtuale. È quindi possibile disabilitare l'accesso a Internet pubblico per connettersi in modo sicuro a Microsoft Purview.

Se si dispone di uno dei requisiti seguenti, è necessario usare endpoint privati per l'account Microsoft Purview:

• È necessario avere l'isolamento della rete end-to-end per gli account e le origini dati di Microsoft Purview.

• È necessario bloccare l'accesso pubblico agli account Microsoft Purview.

• Le origini dati PaaS (Platform-as-a-Service) vengono distribuite con endpoint privati ed è stato bloccato tutto l'accesso tramite l'endpoint pubblico.

• Le origini dati locali o IaaS (Infrastructure as a Service) non possono raggiungere endpoint pubblici.

Considerazioni sulla progettazione

• Per connettersi all'account Microsoft Purview in modo privato e sicuro, è necessario distribuire un account e un endpoint privato del portale. Ad esempio, questa distribuzione è necessaria se si intende connettersi a Microsoft Purview tramite l'API o usare il portale di governance di Microsoft Purview.
• Se è necessario connettersi al portale di governance di Microsoft Purview usando endpoint privati, è necessario distribuire gli endpoint privati sia dell'account che del portale.
• Per analizzare le origini dati tramite la connettività privata, è necessario configurare almeno un account e un endpoint privato di inserimento per Microsoft Purview.
• Esaminare i requisiti DNS. Se si usa un server DNS personalizzato nella rete, i client devono essere in grado di risolvere il nome di dominio completo (FQDN) per gli endpoint dell'account Microsoft Purview nell'indirizzo IP dell'endpoint privato.

Opzioni di runtime di integrazione

Per analizzare le origini dati tramite la connettività privata, è possibile usare il runtime di integrazione della rete virtuale gestita o il runtime di integrazione self-hosted. Per altre informazioni , vedere Scegliere la configurazione di runtime di integrazione corretta per lo scenario.

• Se applicabile, è consigliabile usare il runtime di integrazione della rete virtuale gestita per analizzare le origini dati, per ridurre i costi e il sovraccarico amministrativo.

• Se si usa il runtime di integrazione self-hosted, è necessario configurare e usare un runtime di integrazione self-hosted in una macchina virtuale Windows distribuita all'interno della stessa rete virtuale o di una rete virtuale con peering in cui vengono distribuiti gli endpoint privati di inserimento di Microsoft Purview.

• Per analizzare le origini dati locali, è anche possibile installare un runtime di integrazione self-hosted in un computer Windows locale o in una macchina virtuale all'interno di una rete virtuale di Azure.

• Quando si usano endpoint privati con Microsoft Purview, è necessario consentire la connettività di rete dalle origini dati alla macchina virtuale di integrazione self-hosted nella rete virtuale di Azure in cui vengono distribuiti gli endpoint privati di Microsoft Purview.

• È consigliabile consentire l'aggiornamento automatico del runtime di integrazione self-hosted. Assicurarsi di aprire le regole in uscita necessarie nella rete virtuale di Azure o nel firewall aziendale per consentire l'aggiornamento automatico. Per altre informazioni, vedere Requisiti di rete del runtime di integrazione self-hosted.

Opzioni di autenticazione

• Assicurarsi che le credenziali siano archiviate in un insieme di credenziali delle chiavi di Azure e registrate all'interno di Microsoft Purview.

• È necessario creare credenziali in Microsoft Purview in base a ogni segreto creato nell'insieme di credenziali delle chiavi di Azure. È necessario assegnare, almeno, l'accesso get ed list per i segreti per Microsoft Purview nella risorsa Key Vault in Azure. In caso contrario, le credenziali non funzioneranno nell'account Microsoft Purview.

Limitazioni correnti

• L'analisi di più origini di Azure usando l'intero gruppo di risorse o sottoscrizione tramite endpoint privati di inserimento e un runtime di integrazione self-hosted o managed VNet integration runtime non è supportato quando si usano endpoint privati per l'inserimento. È invece possibile registrare ed analizzare le origini dati singolarmente.

• Per limitazioni relative agli endpoint privati di Microsoft Purview, vedere Limitazioni note.

• Per le limitazioni correlate al servizio collegamento privato, vedere limiti di collegamento privato di Azure.

Scenari di endpoint privati

Singola rete virtuale, singola area

In questo scenario, tutte le origini dati di Azure, le macchine virtuali di runtime di integrazione self-hosted e gli endpoint privati di Microsoft Purview vengono distribuiti nella stessa rete virtuale in una sottoscrizione di Azure.

Se esistono origini dati locali, la connettività viene fornita tramite una VPN da sito a sito o la connettività di Azure ExpressRoute a una rete virtuale di Azure in cui vengono distribuiti gli endpoint privati di Microsoft Purview.

Questa architettura è adatta principalmente per organizzazioni di piccole dimensioni o per scenari di sviluppo, test e proof-of-concept.

Area singola, più reti virtuali

Per connettere due o più reti virtuali in Azure, è possibile usare il peering di rete virtuale. Il traffico di rete tra reti virtuali con peering è privato e viene mantenuto nella rete backbone di Azure.

Molti clienti creano l'infrastruttura di rete in Azure usando l'architettura di rete hub-spoke, in cui:

• I servizi condivisi di rete (ad esempio appliance virtuali di rete, gateway ExpressRoute/VPN o server DNS) vengono distribuiti nella rete virtuale dell'hub.
• Le reti virtuali spoke utilizzano tali servizi condivisi tramite peering di rete virtuale.

Nelle architetture di rete hub-spoke, il team di governance dei dati dell'organizzazione può essere fornito con una sottoscrizione di Azure che include una rete virtuale (hub). Tutti i servizi dati possono trovarsi in alcune altre sottoscrizioni connesse alla rete virtuale dell'hub tramite un peering di rete virtuale o una connessione VPN da sito a sito.

In un'architettura hub-spoke è possibile distribuire Microsoft Purview e una o più macchine virtuali di runtime di integrazione self-hosted nella sottoscrizione dell'hub e nella rete virtuale. È possibile registrare ed analizzare origini dati da altre reti virtuali da più sottoscrizioni nella stessa area.

Le macchine virtuali del runtime di integrazione self-hosted possono essere distribuite all'interno della stessa rete virtuale di Azure o di una rete virtuale con peering in cui vengono distribuiti l'account e gli endpoint privati di inserimento.

Facoltativamente, è possibile distribuire un altro runtime di integrazione self-hosted nelle reti virtuali spoke.

Più aree, più reti virtuali

Se le origini dati vengono distribuite in più aree di Azure in una o più sottoscrizioni di Azure, è possibile usare questo scenario.

Per l'ottimizzazione delle prestazioni e dei costi, è consigliabile distribuire una o più macchine virtuali del runtime di integrazione self-hosted in ogni area in cui si trovano le origini dati.

Eseguire l'analisi usando il runtime di rete virtuale gestita

È possibile usare Managed VNet Runtime per analizzare le origini dati in una rete privata. Per altre informazioni, vedere Usare una rete virtuale gestita con l'account Microsoft Purview.

L'uso del runtime della rete virtuale gestita consente di ridurre al minimo il sovraccarico amministrativo della gestione del runtime e di ridurre la durata complessiva dell'analisi.

Per analizzare le origini dati di Azure tramite una rete privata usando Managed VNet Runtime, è necessario distribuire un endpoint privato gestito all'interno di Microsoft Purview Managed Rete virtuale, anche se l'origine dati ha già una rete privata nella sottoscrizione di Azure.

Se è necessario analizzare origini dati locali o origini dati aggiuntive in Azure che non sono supportate da Managed VNet Runtime, è possibile distribuire sia Managed VNet Runtime che Self-hosted integration runtime.

Se Microsoft Purview non è disponibile nell'area primaria

Microsoft Purview è una soluzione di piattaforma come servizio di Azure. È possibile distribuire un account Microsoft Purview all'interno della sottoscrizione di Azure in qualsiasi area di Azure supportata.

Se Microsoft Purview non è disponibile nell'area di Azure primaria, considerare i fattori seguenti quando si sceglie un'area secondaria per distribuire l'account Microsoft Purview:

• Esaminare la latenza tra l'area di Azure primaria in cui vengono distribuite le origini dati e l'area secondaria di Azure, in cui verrà distribuito l'account Microsoft Purview. Per altre informazioni, vedere Statistiche di latenza round trip della rete di Azure.
• Esaminare i requisiti di residenza dei dati. Quando si analizzano le origini dati nel Microsoft Purview Data Map, le informazioni correlate ai metadati vengono inserite e archiviate all'interno della mappa dati nell'area di Azure in cui viene distribuito l'account Microsoft Purview. Per altre informazioni, vedere Dove sono archiviati i metadati.
• Esaminare i requisiti di rete e sicurezza se è necessaria la connettività di rete privata per l'accesso utente o l'inserimento di metadati. Per altre informazioni, vedere Se Microsoft Purview non è disponibile nell'area primaria.

Opzione 1: distribuire l'account Microsoft Purview in un'area secondaria e distribuire tutti gli endpoint privati nell'area primaria, in cui si trovano le origini dati di Azure. Per questo scenario:

• Questa è l'opzione consigliata, se l'Australia sud-orientale è l'area primaria per tutte le origini dati e tutte le risorse di rete sono distribuite nell'area primaria.
• Distribuire un account Microsoft Purview nell'area secondaria, ad esempio Australia orientale.
• Distribuire tutti gli endpoint privati di Microsoft Purview, inclusi account, portale e inserimento nell'area primaria, ad esempio Australia sud-orientale.
• Distribuire tutto [Microsoft Purview self-hosted integration runtime](.. /manage-integration-runtimes.md) VM nell'area primaria (ad esempio, Australia sud-orientale). Ciò consente di ridurre il traffico tra aree perché le analisi della mappa dati verranno eseguite nell'area locale in cui si trovano le origini dati e vengono inseriti solo i metadati nell'area secondaria in cui viene distribuito l'account Microsoft Purview.
• Se si usano reti virtuali gestite di Microsoft Purview per l'inserimento di metadati, il runtime della rete virtuale gestita e tutti gli endpoint privati gestiti verranno distribuiti automaticamente nell'area in cui viene distribuito Microsoft Purview, ad esempio Australia orientale.

Opzione 2: distribuire l'account Microsoft Purview in un'area secondaria e distribuire endpoint privati nelle aree primaria e secondaria. Per questo scenario:

• Questa opzione è consigliata se si dispone di origini dati in aree primarie e secondarie e gli utenti sono connessi tramite l'area primaria.
• Distribuire un account Microsoft Purview nell'area secondaria, ad esempio Australia orientale.
• Distribuire l'endpoint privato del portale di governance di Microsoft Purview nell'area primaria (ad esempio, Australia sud-orientale) per l'accesso degli utenti al portale di governance di Microsoft Purview.
• Distribuire gli endpoint privati dell'account Microsoft Purview e dell'inserimento nell'area primaria (ad esempio, l'Australia sud-orientale) per analizzare le origini dati in locale nell'area primaria.
• Distribuire gli endpoint privati dell'account Microsoft Purview e dell'inserimento nell'area secondaria , ad esempio Australia orientale, per analizzare le origini dati in locale nell'area secondaria.
• Distribuire [Microsoft Purview self-hosted integration runtime](.. /manage-integration-runtimes.md) macchine virtuali sia nelle aree primarie che in aree secondarie. Ciò consentirà di mantenere il traffico di analisi della mappa dati nell'area locale e di inviare solo metadati a Microsoft Purview Data Map in cui è configurato nell'area secondaria, ad esempio Australia orientale.
• Se si usano reti virtuali gestite di Microsoft Purview per l'inserimento di metadati, il runtime della rete virtuale gestita e tutti gli endpoint privati gestiti verranno distribuiti automaticamente nell'area in cui viene distribuito Microsoft Purview, ad esempio Australia orientale.

Configurazione DNS con endpoint privati

Risoluzione dei nomi per più account Microsoft Purview

È consigliabile seguire queste raccomandazioni, se l'organizzazione deve distribuire e gestire più account Microsoft Purview usando endpoint privati:

1. Distribuire almeno un endpoint privato dell'account per ogni account Microsoft Purview.
2. Distribuire almeno un set di endpoint privati di inserimento per ogni account Microsoft Purview.
3. Distribuire un endpoint privato del portale per uno degli account Microsoft Purview negli ambienti di Azure. Creare un record A DNS per l'endpoint privato del portale per risolvere web.purview.azure.com. L'endpoint privato del portale può essere usato da tutti gli account purview nella stessa rete virtuale di Azure o nelle reti virtuali connesse tramite peering reti virtuali.

Questo scenario si applica anche se più account Microsoft Purview vengono distribuiti tra più sottoscrizioni e più reti virtuali connesse tramite peering reti virtuali. L'endpoint privato del portale esegue principalmente il rendering degli asset statici correlati al portale di governance di Microsoft Purview, pertanto è indipendente dall'account Microsoft Purview, pertanto è necessario un solo endpoint privato del portale per visitare tutti gli account Microsoft Purview nell'ambiente Azure se le reti virtuali sono connesse.

Opzione 3: usare endpoint privati e pubblici

È possibile scegliere un'opzione in cui un subset delle origini dati usa endpoint privati e allo stesso tempo è necessario eseguire una delle seguenti analisi:

• Altre origini dati configurate con un endpoint di servizio
• Origini dati con un endpoint pubblico accessibile tramite Internet

Se è necessario analizzare alcune origini dati usando un endpoint privato di inserimento e alcune origini dati usando endpoint pubblici o un endpoint di servizio, è possibile:

1. Usare gli endpoint privati per l'account Microsoft Purview.
2. Impostare Accesso alla rete pubblica su Abilitato da tutte le reti nell'account Microsoft Purview.

Opzioni di runtime di integrazione

• Per analizzare un'origine dati di Azure configurata con un endpoint privato, è necessario configurare e usare un runtime di integrazione self-hosted in una macchina virtuale Windows distribuita all'interno della stessa rete virtuale o con peering in cui vengono distribuiti l'account Microsoft Purview e gli endpoint privati di inserimento.

  Quando si usa un endpoint privato con Microsoft Purview, è necessario consentire la connettività di rete dalle origini dati a una macchina virtuale di integrazione self-hosted nella rete virtuale di Azure in cui vengono distribuiti gli endpoint privati di Microsoft Purview.

• Per analizzare un'origine dati di Azure configurata per consentire un endpoint pubblico, è possibile usare il runtime di integrazione di Azure.

• Per analizzare le origini dati locali, è anche possibile installare un runtime di integrazione self-hosted in un computer Windows locale o in una macchina virtuale all'interno di una rete virtuale di Azure.

• È consigliabile consentire l'aggiornamento automatico per un runtime di integrazione self-hosted. Assicurarsi di aprire le regole in uscita necessarie nella rete virtuale di Azure o nel firewall aziendale per consentire l'aggiornamento automatico. Per altre informazioni, vedere Requisiti di rete del runtime di integrazione self-hosted.

Opzioni di autenticazione

• Per analizzare un'origine dati di Azure configurata per consentire un endpoint pubblico, è possibile usare qualsiasi opzione di autenticazione, in base al tipo di origine dati.

• Se si usa un endpoint privato di inserimento per analizzare un'origine dati di Azure configurata con un endpoint privato:

  • Non è possibile usare un'identità gestita di Microsoft Purview. Usare invece un'entità servizio, una chiave dell'account o l'autenticazione SQL in base al tipo di origine dati.

  • Assicurarsi che le credenziali siano archiviate in un insieme di credenziali delle chiavi di Azure e registrate all'interno di Microsoft Purview.

  • È necessario creare credenziali in Microsoft Purview in base a ogni segreto creato in Azure Key Vault. Assegnare almeno l'accesso get ed list per i segreti per Microsoft Purview nella risorsa Key Vault in Azure. In caso contrario, le credenziali non funzioneranno nell'account Microsoft Purview.

Opzione 4: Usare endpoint privati solo per l'inserimento

È possibile scegliere questa opzione se è necessario:

• Analizzare tutte le origini dati usando l'endpoint privato di inserimento.
• Le risorse gestite devono essere configurate per disabilitare la rete pubblica.
• Abilitare l'accesso al portale di governance di Microsoft Purview tramite la rete pubblica.

Per abilitare questa opzione:

1. Configurare l'endpoint privato di inserimento per l'account Microsoft Purview.
2. Impostare Accesso alla rete pubblica su Disabilitato solo per l'inserimento (anteprima)nell'account Microsoft Purview.

Opzioni di runtime di integrazione

Seguire la raccomandazione per l'opzione 2.

Opzioni di autenticazione

Seguire la raccomandazione per l'opzione 2.

Raccomandazioni per la rete e il proxy del runtime di integrazione self-hosted

Per analizzare le origini dati nelle reti locali e di Azure, potrebbe essere necessario distribuire e usare una o più macchine virtuali di runtime di integrazione self-hosted all'interno di una rete virtuale di Azure o di una rete locale, per uno degli scenari indicati in precedenza in questo documento.

• Per semplificare la gestione, quando possibile, usare Il runtime di integrazione di Azure e microsoft Purview Managed VNet IR per analizzare le origini dati.

• Il servizio runtime di integrazione self-hosted può comunicare con Microsoft Purview tramite una rete pubblica o privata sulla porta 443. Per altre informazioni, vedere Requisiti di rete del runtime di integrazione self-hosted.

• Una macchina virtuale di runtime di integrazione self-hosted può essere usata per analizzare una o più origini dati in Microsoft Purview, tuttavia, il runtime di integrazione self-hosted deve essere registrato solo per Microsoft Purview e non può essere usato per Azure Data Factory o Azure Synapse contemporaneamente.

• È possibile registrare e usare uno o più runtime di integrazione self-hosted in un account Microsoft Purview. È consigliabile inserire almeno una macchina virtuale di runtime di integrazione self-hosted in ogni area o rete locale in cui risiedono le origini dati.

• È consigliabile definire una baseline per la capacità necessaria per ogni macchina virtuale del runtime di integrazione self-hosted e ridimensionare la capacità della macchina virtuale in base alla richiesta.

• È consigliabile configurare la connessione di rete tra le macchine virtuali del runtime di integrazione self-hosted e Microsoft Purview e le relative risorse gestite tramite la rete privata, quando possibile.

• Consentire la connettività in uscita a download.microsoft.com, se l'aggiornamento automatico è abilitato.

• Il servizio di runtime di integrazione self-hosted non richiede la connettività Internet in uscita, se le macchine virtuali del runtime di integrazione self-hosted vengono distribuite in una rete virtuale di Azure o nella rete locale connessa ad Azure tramite una connessione VPN da ExpressRoute o da sito a sito. In questo caso, il processo di analisi e inserimento dei metadati può essere eseguito tramite la rete privata.

• Il runtime di integrazione self-hosted può comunicare Microsoft Purview e le relative risorse gestite direttamente o tramite un server proxy. Evitare di usare le impostazioni proxy se la macchina virtuale del runtime di integrazione self-hosted si trova all'interno di una rete virtuale di Azure o è connessa tramite ExpressRoute o la connessione VPN da sito a sito.

• Esaminare gli scenari supportati, se è necessario usare il runtime di integrazione self-hosted con l'impostazione proxy.

Passaggi successivi

• Usare endpoint privati per l'accesso sicuro a Microsoft Purview