Progettare la configurazione collegamento privato di Azure

Prima di configurare l'istanza di collegamento privato di Azure, prendere in considerazione la topologia di rete e la topologia di routing DNS.

Come illustrato in Usare collegamento privato di Azure per connettere le reti a Monitoraggio di Azure, la configurazione di un collegamento privato influisce sul traffico a tutte le risorse di Monitoraggio di Azure. Ciò vale soprattutto per le risorse di Application Insights. Influisce anche sulla rete connessa all'endpoint privato, ma anche su tutte le altre reti che condividono lo stesso DNS.

L'approccio più semplice e sicuro:

1. Creare una singola connessione di collegamento privato, con un singolo endpoint privato e un singolo monitoraggio di Azure collegamento privato Scope (AMPLS). Se le reti sono sottoposte a peering, creare la connessione di collegamento privato nella rete virtuale condivisa (o hub).
2. Aggiungere tutte le risorse di Monitoraggio di Azure, ad esempio i componenti di Application Insights, le aree di lavoro Log Analytics e gli endpoint di raccolta dati ad AMPLS.
3. Bloccare il traffico in uscita di rete il più possibile.

Se non è possibile aggiungere tutte le risorse di Monitoraggio di Azure ad AMPLS, è comunque possibile applicare il collegamento privato ad alcune risorse, come illustrato in Controllare l'applicazione dei collegamenti privati alle reti. Non è consigliabile questo approccio perché non impedisce l'esfiltrazione dei dati.

Pianificare per topologia di rete

Prendere in considerazione la topologia di rete nel processo di pianificazione.

Principio guida: evitare gli override DNS usando un singolo AMPLS

Alcune reti sono composte da più reti virtuali o altre reti connesse. Se queste reti condividono lo stesso DNS, la configurazione di un collegamento privato su uno qualsiasi di essi aggiornerebbe il DNS e influirà sul traffico in tutte le reti.

Nel diagramma seguente la rete virtuale 10.0.1.x si connette ad AMPLS1, che crea voci DNS che eseguono il mapping degli endpoint di Monitoraggio di Azure agli indirizzi IP compresi nell'intervallo 10.0.1.x. Successivamente, la rete virtuale 10.0.2.x si connette ad AMPLS2, che esegue l'override delle stesse voci DNS eseguendo il mapping degli stessi endpoint globali/regionali agli indirizzi IP dall'intervallo 10.0.2.x. Poiché queste reti virtuali non sono sottoposte a peering, la prima rete virtuale ora non riesce a raggiungere questi endpoint.

Per evitare questo conflitto, creare solo un singolo oggetto AMPLS per DNS.

Reti hub-spoke

Le reti hub-spoke devono usare un singolo set di connessioni di collegamento privato nella rete hub (principale) e non in ogni rete virtuale spoke.

Nota

È consigliabile creare collegamenti privati separati per le reti virtuali spoke, ad esempio per consentire a ogni rete virtuale di accedere a un set limitato di risorse di monitoraggio. In questi casi, è possibile creare un endpoint privato dedicato e AMPLS per ogni rete virtuale. È anche necessario verificare che non convidano le stesse zone DNS per evitare override DNS.

Reti con peering

Il peering di rete viene usato in varie topologie, diverse da hub e spoke. Tali reti possono condividere gli indirizzi IP dell'altro e probabilmente condividono lo stesso DNS. In questi casi, creare un singolo collegamento privato in una rete accessibile alle altre reti. Evitare di creare più endpoint privati e oggetti AMPLS perché si applica solo l'ultimo set nel DNS.

Reti isolate

Se le reti non sono sottoposte a peering, è necessario separare anche il DNS per usare i collegamenti privati. Al termine, creare un endpoint privato separato per ogni rete e un oggetto AMPLS separato. Gli oggetti AMPLS possono collegarsi alle stesse aree di lavoro/componenti o a quelli diversi.

Test in locale: modificare il file host del computer invece del DNS

Per testare i collegamenti privati in locale senza influire sugli altri client nella rete, assicurarsi di non aggiornare il DNS quando si crea l'endpoint privato. Modificare invece il file hosts nel computer in modo che invii richieste agli endpoint di collegamento privato:

• Configurare un collegamento privato, ma quando ci si connette a un endpoint privato, scegliere di non eseguire l'integrazione automatica con il DNS (passaggio 5b).
• Configurare gli endpoint pertinenti nei file host dei computer. Per esaminare gli endpoint di Monitoraggio di Azure che richiedono il mapping, vedere Esaminare le impostazioni DNS dell'endpoint.

Non è consigliabile adottare questo approccio per gli ambienti di produzione.

Controllare l'applicazione dei collegamenti privati alle reti

Usando le modalità di accesso ai collegamenti privati, è possibile controllare il modo in cui i collegamenti privati influiscono sul traffico di rete. Queste impostazioni possono essere applicate all'oggetto AMPLS (per influire su tutte le reti connesse) o a reti specifiche connesse.

La scelta della modalità di accesso appropriata è fondamentale per garantire il traffico di rete continuo e ininterrotto. Ognuna di queste modalità può essere impostata per l'inserimento e le query, separatamente:

• Solo privato: consente alla rete virtuale di raggiungere solo le risorse di collegamento privato (risorse nell'AMPLS). Questa è la modalità di lavoro più sicura. Impedisce l'esfiltrazione dei dati bloccando il traffico da AMPLS alle risorse di Monitoraggio di Azure.
• Apri: consente alla rete virtuale di raggiungere sia le risorse di collegamento privato che le risorse non nell'AMPLS (se accettano il traffico dalle reti pubbliche). La modalità Open access non impedisce l'esfiltrazione dei dati, ma offre comunque gli altri vantaggi dei collegamenti privati. Il traffico verso risorse di collegamento privato viene inviato tramite endpoint privati, convalidati e inviati tramite il backbone Microsoft. La modalità Open è utile per una modalità mista di lavoro (accesso ad alcune risorse pubblicamente e altre tramite un collegamento privato) o durante un processo di onboarding graduale. Le modalità di accesso vengono impostate separatamente per l'inserimento e le query. Ad esempio, è possibile impostare la modalità Solo privato per l'inserimento e la modalità Apri per le query.

Prestare attenzione quando si seleziona la modalità di accesso. L'uso della modalità di accesso solo privato bloccherà il traffico verso le risorse non presenti in AMPLS in tutte le reti che condividono lo stesso DNS, indipendentemente dalla sottoscrizione o dal tenant. L'eccezione è costituita dalle richieste di inserimento di Log Analytics, spiegate. Se non è possibile aggiungere tutte le risorse di Monitoraggio di Azure ad AMPLS, iniziare aggiungendo le risorse selezionate e applicando la modalità Apri accesso. Passare alla modalità Solo privato per la massima sicurezza solo dopo aver aggiunto tutte le risorse di Monitoraggio di Azure ad AMPLS.

Per informazioni dettagliate ed esempi di configurazione, vedere Usare le API e la riga di comando.

Nota

L'inserimento di Log Analytics usa endpoint specifici delle risorse. Di conseguenza, non rispetta le modalità di accesso AMPLS. Per garantire che le richieste di inserimento di Log Analytics non possano accedere alle aree di lavoro dall'AMPLS, impostare il firewall di rete per bloccare il traffico verso gli endpoint pubblici, indipendentemente dalle modalità di accesso AMPLS.

Impostare le modalità di accesso per reti specifiche

Le modalità di accesso impostate nella risorsa AMPLS influiscono su tutte le reti, ma è possibile eseguire l'override di queste impostazioni per reti specifiche.

Nel diagramma seguente, VNet1 usa la modalità Open e VNet2 usa la modalità Solo privato. Le richieste da VNet1 possono raggiungere l'area di lavoro 1 e il componente 2 tramite un collegamento privato. Le richieste possono raggiungere il componente 3 solo se accetta il traffico dalle reti pubbliche. Le richieste VNet2 non possono raggiungere il componente 3.

Prendere in considerazione i limiti AMPLS

L'oggetto AMPLS presenta i limiti seguenti:

• Una rete virtuale può connettersi a un solo oggetto AMPLS. Ciò significa che l'oggetto AMPLS deve fornire l'accesso a tutte le risorse di Monitoraggio di Azure a cui deve accedere la rete virtuale.
• Un oggetto AMPLS può connettersi a 300 aree di lavoro Log Analytics e 1.000 componenti di Application Insights al massimo.
• Una risorsa di Monitoraggio di Azure (area di lavoro o un componente o un endpoint di raccolta dati di Application Insights) può connettersi al massimo a cinque AMPLS.
• Un oggetto AMPLS può connettersi a 10 endpoint privati al massimo.

Nota

Le risorse AMPLS create prima del 1° dicembre 2021 supportano solo 50 risorse.

Nel diagramma seguente:

• Ogni rete virtuale si connette a un solo oggetto AMPLS.
• AMPLS A si connette a due aree di lavoro e a un componente di Application Insights usando due delle possibili 300 aree di lavoro Log Analytics e uno dei possibili 1.000 componenti di Application Insights a cui può connettersi.
• L'area di lavoro 2 si connette ad AMPLS A e AMPLS B usando due delle cinque possibili connessioni AMPLS.
• AMPLS B è connesso a endpoint privati di due reti virtuali (VNet2 e VNet3) usando due delle 10 possibili connessioni endpoint private.

Controllare l'accesso alla rete alle risorse

Le aree di lavoro Log Analytics o i componenti di Application Insights possono essere impostati su:

• Accettare o bloccare l'inserimento da reti pubbliche (reti non connesse alla risorsa AMPLS).
• Accettare o bloccare query da reti pubbliche (reti non connesse alla risorsa AMPLS).

Tale granularità consente di impostare l'accesso in base alle esigenze, per area di lavoro. Ad esempio, è possibile accettare l'inserimento solo tramite reti connesse a collegamento privato (ovvero reti virtuali specifiche), ma si sceglie comunque di accettare query da tutte le reti, pubbliche e private.

Il blocco delle query da reti pubbliche significa che i client come computer e SDK all'esterno degli AMPLS connessi non possono eseguire query sui dati nella risorsa. Tali dati includono log, metriche e flusso delle metriche in tempo reale. Il blocco delle query dalle reti pubbliche influisce su tutte le esperienze che eseguono queste query, ad esempio cartelle di lavoro, dashboard, informazioni dettagliate nel portale di Azure e query eseguite dall'esterno del portale di Azure.

Nota

Esistono alcune eccezioni in cui queste impostazioni non si applicano. I dettagli sono disponibili nella sezione seguente.

Gli endpoint di raccolta dati possono essere impostati per accettare o bloccare l'accesso dalle reti pubbliche (reti non connesse alla risorsa AMPLS).

Per informazioni sulla configurazione, vedere Impostare i flag di accesso alle risorse.

Eccezioni

Prendere nota delle eccezioni seguenti.

Log di diagnostica

I log e le metriche caricati in un'area di lavoro tramite le impostazioni di diagnostica passano attraverso un canale Microsoft privato sicuro e non sono controllati da queste impostazioni.

Metriche personalizzate o metriche guest di Monitoraggio di Azure

Le metriche personalizzate (anteprima) raccolte e caricate tramite l'agente di Monitoraggio di Azure non sono controllate dagli endpoint di raccolta dati. Non possono essere configurati tramite collegamenti privati.

Azure Resource Manager

Limitare l'accesso come illustrato in precedenza si applica ai dati nella risorsa. Tuttavia, le modifiche alla configurazione, ad esempio l'attivazione o la disattivazione di queste impostazioni di accesso, vengono gestite da Azure Resource Manager. Per controllare queste impostazioni, limitare l'accesso alle risorse usando i ruoli, le autorizzazioni, i controlli di rete e il controllo appropriati. Per altre informazioni, vedere Ruoli, autorizzazioni e sicurezza di Monitoraggio di Azure.

Nota

Le query inviate tramite l'API di Resource Manager non possono usare i collegamenti privati di Monitoraggio di Azure. Queste query possono essere eseguite solo se la risorsa di destinazione consente query da reti pubbliche (impostate tramite il riquadro Isolamento rete o tramite l'interfaccia della riga di comando).

Le esperienze seguenti sono note per l'esecuzione di query tramite l'API di Resource Manager:

• Logica Connettore app
• Soluzione Gestione aggiornamenti
• Soluzione di Rilevamento modifiche
• Informazioni dettagliate macchina virtuale
• Informazioni dettagliate contenitore
• Riquadro Riepilogo area di lavoro Log Analytics (deprecato) (che mostra il dashboard delle soluzioni)

Considerazioni su Application Insights

• È necessario aggiungere risorse che ospitano i carichi di lavoro monitorati a un collegamento privato. Ad esempio, vedere Uso di endpoint privati per l'app Web di Azure.
• Le esperienze di utilizzo non del portale devono essere eseguite anche nella rete virtuale collegata privata che include i carichi di lavoro monitorati.
• Per supportare i collegamenti privati per Profiler e Debugger, è necessario fornire il proprio account di archiviazione.

Nota

Per proteggere completamente Application Insights basato sull'area di lavoro, è necessario bloccare l'accesso alla risorsa di Application Insights e all'area di lavoro Log Analytics sottostante.

Considerazioni su Log Analytics

Tenere presenti le considerazioni seguenti su Log Analytics.

Download dei pacchetti di soluzioni Di Log Analytics

Gli agenti di Log Analytics devono accedere a un account di archiviazione globale per scaricare i pacchetti di soluzioni. Le configurazioni di collegamento privato create al 19 aprile 2021 (o a partire da giugno 2021 nei cloud sovrani di Azure) possono raggiungere lo spazio di archiviazione dei pacchetti di soluzioni degli agenti tramite il collegamento privato. Questa funzionalità è resa possibile tramite una zona DNS creata per blob.core.windows.net.

Se la configurazione del collegamento privato è stata creata prima del 19 aprile 2021, non raggiungerà lo spazio di archiviazione dei pacchetti di soluzioni tramite un collegamento privato. Per gestirlo, è possibile:

• Ricreare l'AMPLS e l'endpoint privato connesso.

• Consentire agli agenti di raggiungere l'account di archiviazione tramite l'endpoint pubblico aggiungendo le regole seguenti all'elenco di indirizzi consentiti del firewall:

  Ambiente cloud	Risorsa dell'agente	Porte	Direzione
  Pubblico di Azure	scadvisorcontent.blob.core.windows.net	443	In uscita
  Azure per enti pubblici	usbn1oicore.blob.core.usgovcloudapi.net	443	In uscita
  Microsoft Azure gestito da 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	In uscita

Raccogliere log personalizzati e log IIS tramite un collegamento privato

Gli account di archiviazione vengono usati nel processo di inserimento dei log personalizzati. Per impostazione predefinita, vengono usati gli account di archiviazione gestiti dal servizio. Per inserire log personalizzati in collegamenti privati, è necessario usare i propri account di archiviazione e associarli alle aree di lavoro Log Analytics.

Per altre informazioni su come connettere il proprio account di archiviazione, vedere Account di archiviazione di proprietà del cliente per l'inserimento dei log e usare in particolare collegamenti privati e Collegare account di archiviazione all'area di lavoro Log Analytics.

Automazione

Se si usano soluzioni di Log Analytics che richiedono un account di Automazione di Azure (ad esempio Gestione aggiornamenti, Rilevamento modifiche o Inventario), è necessario creare anche un collegamento privato per l'account di Automazione. Per altre informazioni, vedere Usare collegamento privato di Azure per connettere in modo sicuro le reti a Automazione di Azure.

Nota

Alcuni prodotti ed esperienze portale di Azure eseguono query sui dati tramite Resource Manager. In questo caso, non potranno eseguire query sui dati tramite un collegamento privato, a meno che le impostazioni di collegamento privato non vengano applicate anche a Resource Manager. Per superare questa restrizione, è possibile configurare le risorse in modo da accettare query dalle reti pubbliche, come illustrato in Controllo dell'accesso di rete alle risorse. L'inserimento può rimanere limitato alle reti di collegamento privato. Sono stati identificati i prodotti e le aree di lavoro per le query sulle esperienze seguenti tramite Resource Manager:

• Logica Connettore app
• Soluzione Gestione aggiornamenti
• Soluzione di Rilevamento modifiche
• Riquadro Riepilogo area di lavoro (deprecato) nel portale (che mostra il dashboard delle soluzioni)
• Informazioni dettagliate macchina virtuale
• Informazioni dettagliate contenitore

Considerazioni su Prometheus gestito

• collegamento privato impostazioni di inserimento vengono eseguite usando AMPLS e le impostazioni negli endpoint di raccolta dati (DCEs) che fanno riferimento all'area di lavoro di Monitoraggio di Azure usata per archiviare le metriche di Prometheus.
• collegamento privato le impostazioni di query vengono eseguite direttamente nell'area di lavoro di Monitoraggio di Azure usata per archiviare le metriche di Prometheus e non vengono gestite tramite AMPLS.

Requisiti

Si notino i requisiti seguenti.

Dimensioni subnet di rete

La subnet IPv4 più piccola supportata è /27 (usando le definizioni di subnet CIDR). Anche se le reti virtuali di Azure possono essere pari a /29, Azure riserva cinque indirizzi IP. L'installazione del collegamento privato di Monitoraggio di Azure richiede almeno 11 indirizzi IP, anche se ci si connette a una singola area di lavoro. Esaminare le impostazioni DNS dell'endpoint per l'elenco degli endpoint di collegamento privato di Monitoraggio di Azure.

Agenti

Le versioni più recenti degli agenti Windows e Linux devono essere usate per supportare l'inserimento sicuro nelle aree di lavoro Log Analytics. Le versioni precedenti non possono caricare i dati di monitoraggio in una rete privata.

Agenti Windows di Monitoraggio di Azure

Agente windows di Monitoraggio di Azure versione 1.1.1.0 o successiva (usando endpoint di raccolta dati).

Agenti Linux di Monitoraggio di Azure

Agente windows di Monitoraggio di Azure versione 1.10.5.0 o successiva (usando gli endpoint di raccolta dati).

Agente windows di Log Analytics (nel percorso di deprecazione)

Usare l'agente di Log Analytics versione 10.20.18038.0 o successiva.

Agente Linux di Log Analytics (nel percorso di deprecazione)

Usare la versione dell'agente 1.12.25 o successiva. In caso contrario, eseguire i comandi seguenti nella macchina virtuale:

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Azure portal

Per usare le esperienze del portale di Monitoraggio di Azure, ad esempio Application Insights, Log Analytics ed endpoint di raccolta dati, è necessario consentire l'accessibilità delle estensioni portale di Azure e Monitoraggio di Azure nelle reti private. Aggiungere i tag del servizio AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty e AzureFrontdoor.Frontendal gruppo di sicurezza di rete.

Accesso programmatico

Per usare l'API REST, l'interfaccia della riga di comando di Azure o PowerShell con Monitoraggio di Azure nelle reti private, aggiungere i tagdel servizio AzureActiveDirectory e AzureResourceManager al firewall.

Download di SDK di Application Insights da una rete per la distribuzione di contenuti

Aggregare il codice JavaScript nello script in modo che il browser non tenti di scaricare il codice da un rete CDN. In GitHub viene fornito un esempio.

Impostazioni DNS del browser

Se ci si connette alle risorse di Monitoraggio di Azure tramite un collegamento privato, il traffico verso queste risorse deve attraversare l'endpoint privato configurato nella rete. Per abilitare l'endpoint privato, aggiornare le impostazioni DNS come illustrato in Connessione a un endpoint privato. Alcuni browser usano le proprie impostazioni DNS anziché quelle impostate. Il browser potrebbe tentare di connettersi agli endpoint pubblici di Monitoraggio di Azure e ignorare completamente il collegamento privato. Verificare che le impostazioni del browser non eseseguono l'override o memorizzano nella cache le impostazioni DNS precedenti.

Limitazione delle query: operatore externaldata

• L'operatore externaldata non è supportato tramite un collegamento privato perché legge i dati dagli account di archiviazione, ma non garantisce che l'archiviazione sia accessibile privatamente.
• Il proxy di Azure Esplora dati (proxy ADX) consente alle query di log di eseguire query su Azure Esplora dati. Il proxy ADX non è supportato tramite un collegamento privato perché non garantisce che la risorsa di destinazione sia accessibile privatamente.

Passaggi successivi

• Informazioni su come configurare il collegamento privato.
• Informazioni sull'archiviazione privata per i log personalizzati e le chiavi gestite dal cliente.
• Informazioni sui collegamento privato per l'automazione.