Accesso privato ai servizi PaaS Azure

Questo articolo illustra come connettersi alle risorse PaaS (Platform as a Service) di Azure tramite connessioni di rete private anziché a Internet pubblico. Si apprenderà le differenze tra endpoint di servizio, endpoint privati e collegamento privato in modo da poter scegliere l'approccio più adatto ai requisiti di sicurezza e connettività.

Informazioni su questo articolo

L'accesso PaaS privato rimuove la rete Internet pubblica dal percorso dati tra la rete virtuale Azure e i servizi PaaS Azure come Archiviazione di Azure, database SQL di Azure e Azure Key Vault. Questo articolo illustra le opzioni di connettività, i compromessi e come decidere quale approccio usare per ogni carico di lavoro.

Note

Gli endpoint privati richiedono l'integrazione DNS per risolvere gli FQDN del servizio in indirizzi IP privati. Questo articolo illustra i requisiti DNS inline, ma per l'architettura DNS completa, tra cui l'inoltro ibrido, DNS di Azure resolver privato e la sicurezza DNS, vedere Sicurezza DNS e risoluzione dei nomi privati.

Chi ha bisogno di questo articolo

Leggere questo articolo se si applicano una o più di queste condizioni:

  • I carichi di lavoro devono raggiungere Azure servizi PaaS tramite percorsi di rete privati anziché endpoint pubblici.
  • È necessario decidere tra endpoint di servizio ed endpoint privati in base a sicurezza, costi e gestibilità.
  • È necessario limitare l'accesso a risorse PaaS specifiche per ridurre il rischio di esfiltrazione dei dati.
  • È necessario pianificare DNS, capacità subnet o raggiungibilità ibrida per la connettività PaaS privata.

Tip

Si segue un percorso di scenario? Selezionare lo scenario nella parte superiore della pagina per indicazioni personalizzate. Le linee guida di base seguenti si applicano a tutti i lettori.

Focus su lift-and-shift: saltare questo articolo a meno che alcune parti dell'app migrata non usino già i servizi PaaS di Azure. La maggior parte dei carichi di lavoro lift-and-shift rimane in IaaS (VM, dischi gestiti, rete standard) e non richiede collegamento privato nella fase di migrazione iniziale. Tornare a questo articolo più avanti quando si inizia ad adottare i servizi PaaS per singoli componenti del carico di lavoro.

Leggere questo articolo se:

  • Sono stati migrati carichi di lavoro che usano già Azure servizi PaaS, ad esempio database SQL di Azure o Archiviazione di Azure.
  • Si vuole capire quando iniziare a usare il collegamento privato come parte di una modernizzazione in più fasi dopo il trasferimento in modalità lift-and-shift.
  • È necessario pianificare la capacità della subnet per l'adozione futura di endpoint privati.

Focus sulla modernizzazione: le subnet di collegamento privato in ogni macchina virtuale spoke sono essenziali. I carichi di lavoro AKS, ambiente del servizio app (ASE) e di database gestiti necessitano di connettività privata ai servizi PaaS per soddisfare i requisiti di conformità e impedire l'esfiltrazione dei dati tramite Internet pubblico.

Leggere questo articolo se:

  • Archiviare dati sensibili o regolamentati nei servizi PaaS Azure e devono limitare l'accesso ai percorsi di rete privata.
  • È necessario creare subnet dedicate per collegamento privato in ogni macchina virtuale spoke per l’utilizzo da parte del team dell’applicazione.
  • Vuoi impedire l'esfiltrazione dei dati assicurandoti che gli ambiti di connettività di PaaS siano limitati a specifiche istanze di risorse.
  • Si progettano carichi di lavoro di produzione in cui i servizi PaaS devono essere raggiungibili dalle reti locali tramite VPN o ExpressRoute.
  • È necessario comprendere i compromessi in termini di costi, DNS e sicurezza tra gli endpoint di servizio e gli endpoint privati.

Focus sul multi-cloud: Questo articolo diventa rilevante dopo avere configurato il transito e la connettività multi-cloud, a meno che l'architettura di destinazione non includa già Azure PaaS con endpoint privati. Tornare a questo articolo durante l'ottimizzazione quando si è pronti per proteggere i percorsi di accesso PaaS.

Leggere questo articolo se:

  • Si utilizza Azure Migrate con il supporto per Endpoint privato durante il processo di migrazione.
  • Pianificare l'adozione di servizi PaaS di Azure come parte dell'architettura di destinazione post-migrazione.
  • È necessario comprendere il funzionamento degli endpoint privati prima di integrarli con la progettazione tra cloud.

Azure servizi e funzionalità

La tabella seguente descrive i servizi e le funzionalità disponibili per la connettività PaaS privata in Azure.

Servizio o funzionalità Elementi forniti Quando usarlo
Endpoint pubblico (impostazione predefinita) Accedere ai servizi PaaS di Azure via Internet tramite il relativo nome di dominio completo pubblico (FQDN). Non sono necessarie configurazioni aggiuntive. Solo ambienti di sviluppo/test. Non consigliato per i carichi di lavoro di produzione con dati sensibili.
Endpoint di servizio Estende l'identità della rete virtuale ai servizi PaaS Azure. Il traffico rimane sul backbone Microsoft. Il servizio PaaS vede la rete virtuale come origine del traffico. Non crea un indirizzo IP privato. Basso rischio di esfiltrazione. Configurazione più semplice di collegamento privato. Utile quando collegamento privato non è disponibile per un servizio specifico. Gratuito.
Collegamento/Endpoint privato di Azure Crea un'interfaccia di rete con un indirizzo IP privato all'interno della rete virtuale che esegue il mapping a un'istanza di risorsa PaaS specifica. Il traffico rimane sul backbone Microsoft e non attraversa mai la rete Internet pubblica. Richiede l'integrazione DNS. Carichi di lavoro di produzione. Dati sensibili. Conformità alle normative. Prevenzione dell'esfiltrazione dei dati. Preferito rispetto agli endpoint di servizio per le nuove progettazioni.
servizio collegamento privato Esponi il tuo servizio in modo privato agli utenti di altre reti virtuali o tenant di Microsoft Entra. I consumer creano un endpoint privato nella propria macchina virtuale per raggiungere il servizio, senza richiedere il peering di rete virtuale. ISV o i team della piattaforma interna che pubblicano servizi per utenti che non dovrebbero avere accesso a livello di rete alla rete virtuale dell'host.
Integrazione rete virtuale (servizio app, funzioni) Consente al Servizio app o ad Funzioni di Azure di instradare il traffico in uscita attraverso una rete virtuale. Solo in uscita: non fornisce connettività privata in ingresso. Quando il servizio app o Funzioni di Azure deve raggiungere risorse private della rete virtuale, ad esempio database o API interne tramite endpoint privati.

Come scegliere

Diagramma che confronta tre metodi di accesso PaaS: endpoint pubblico, endpoint di servizio tramite backbone ed endpoint privato con ip privato.

Usare le tabelle delle decisioni in questa sezione per selezionare l'approccio di connettività appropriato per il carico di lavoro.

Endpoint di servizio rispetto agli endpoint privati

La tabella seguente confronta i due approcci più comuni per limitare l'accesso PaaS ai percorsi di rete privata.

Fattore Endpoint servizio Endpoint privati
Percorso del traffico Backbone Microsoft. La destinazione usa comunque l'indirizzo IP pubblico. Backbone Microsoft. La destinazione usa un indirizzo IP privato nella rete virtuale.
IP privato nella rete virtuale No. L'indirizzo IP di origine diventa privato (indirizzo di rete virtuale), ma il servizio viene risolto nell'indirizzo IP pubblico. Yes. Un'interfaccia di rete con un indirizzo IP privato della subnet viene associata alla risorsa specificata.
Modifiche DNS necessarie No. La risoluzione DNS rimane invariata. Yes. È necessaria una zona DNS privata affinché l'FQDN del servizio si risolva nell'indirizzo IP privato.
Prevenzione dell'esfiltrazione dei dati Limitato. Si applica a livello di rete virtuale a tutte le istanze di un tipo di servizio, ad esempio tutti gli account Archiviazione di Azure. Forte. L'accesso è limitato a un'istanza di risorsa specifica. Solo la risorsa mappata è raggiungibile tramite tale endpoint.
Accesso locale Non raggiungibile dalle reti locali. Soluzione alternativa: aggiungere gli indirizzi IP pubblici o NAT alle regole del firewall IP del servizio Azure. Raggiungibile dall'ambiente locale tramite VPN o ExpressRoute perché l'endpoint ha un indirizzo IP privato instradabile.
Cost Gratuito. Nessun addebito aggiuntivo. Addebito orario per endpoint e tariffa per l'elaborazione dati.

Quando usare l'approccio

Scenario Approccio consigliato Perché
Sviluppo/test, bassa sensibilità ai dati Endpoint pubblico con firewall del servizio Configurazione più semplice. Limitare l'accesso in base all'elenco di indirizzi IP consentiti. Nessun costo aggiuntivo o modifiche dns.
Restrizione semplice della rete virtuale, basso rischio di esfiltrazione Endpoint servizio Gratuito. Rapido da abilitare. Adatto quando non è necessaria la definizione dell'ambito dell'accesso a livello di risorsa.
Carichi di lavoro di produzione, dati sensibili, conformità Endpoint privati Massima protezione contro l'esfiltrazione. Funziona in locale. Supporta la risoluzione basata su DNS da qualsiasi rete connessa.
Pubblicare privatamente il proprio servizio ad altri tenant Servizio Collegamento privato I consumer creano un endpoint privato nella rete virtuale. Non è necessario alcun peering di VNet. Supporta i flussi di lavoro di approvazione e i controlli di visibilità.
App Service o Functions deve accedere alle risorse della VNet Integrazione rete virtuale Connettività solo in uscita. Richiede la delega della sottorete a Microsoft.Web/serverFarms. Combinare con endpoint privati per proteggere l'accesso ai dati ai servizi PaaS.

Frontdoor di Azure Premium supporta collegamento privato origini, usate per connettere Frontdoor ai servizi back-end (servizio app, archiviazione o servizi di bilanciamento del carico interno) tramite una connessione privata. Il traffico tra Frontdoor e l'origine rimane sul backbone Microsoft ed è possibile disattivare completamente l'accesso pubblico all'origine. Questo modello è l'integrazione più ampiamente documentata per collegamento privato tra i servizi di rete Azure.

Usare Frontdoor Premium con origini collegamento privato quando necessario:

  • Bilanciamento del carico globale con protezione firewall per applicazioni web (WAF).
  • Connettività privata verso i server di origine senza esporli a Internet pubblico.
  • Terminazione TLS centralizzata con traffico backend tramite percorsi privati.

Integrazione rete virtuale per l'accesso in uscita

L'integrazione rete virtuale non fornisce connettività privata in ingresso. Consente al servizio app o Funzioni di Azure di instradare le chiamate in uscita attraverso la rete virtuale. Ciò significa che la tua app può raggiungere le risorse dietro i Private Endpoints o accedere ai servizi privati della VNet. L'integrazione VNet richiede una subnet dedicata delegata a Microsoft.Web/serverFarms.

Combinare l'integrazione della rete virtuale con gli endpoint privati quando l'applicazione deve:

  • Chiamare database SQL di Azure o Archiviazione di Azure tramite un indirizzo IP privato.
  • Accedere alle API interne o ai servizi distribuiti nelle reti virtuali spoke.
  • Instradare il traffico in uscita tramite un'appliance virtuale di rete (NVA) per l'ispezione.

Considerazioni relative alla progettazione

La maggior parte dei progetti lift-and-shift rinvia l'adozione di collegamento privato a una fase successiva. La priorità immediata consiste nella migrazione delle macchine virtuali e nella definizione della connettività di base. Considera collegamento privato quando:

  • I singoli componenti del carico di lavoro usano già PaaS: Se un'applicazione lifted si connette a database SQL di Azure o Archiviazione di Azure, aggiungere un endpoint privato per tale servizio specifico. Non è necessario convertire tutti gli accessi PaaS contemporaneamente.
  • La conformità impone la connettività privata: Alcuni carichi di lavoro regolamentati richiedono percorsi di dati privati dal primo giorno. In questo caso, creare endpoint privati durante la migrazione, non dopo.
  • Pianificare ora la capacità della subnet: anche se si rinvia il collegamento privato, riservare una subnet /27 o /28 in ogni spoke per gli endpoint privati futuri. L'adeguamento dello spazio subnet in un secondo momento è più difficile rispetto alla prenotazione iniziale.

Per la maggior parte delle migrazioni in modalità lift-and-shift, ignorare l'implementazione dettagliata collegamento privato e tornare a questo articolo all'inizio dell'adozione di PaaS.

Creare una subnet di collegamento privato dedicata in ogni rete virtuale spoke. I team delle app usano questa subnet per creare endpoint privati per i servizi PaaS usati dalle applicazioni:

  • Subnet collegamento privato dedicata per ogni spoke: Dimensionare ogni subnet in base al numero di servizi PaaS di cui i carichi di lavoro dello spoke necessitano (un IP per ogni endpoint privato). Un /27 (32 indirizzi) supporta fino a 27 endpoint privati dopo che Azure riserva 5 indirizzi.
  • Gli amministratori delle app decidono le connessioni PaaS: Il team IT fornisce la subnet e l'infrastruttura DNS. I team dell'app creano endpoint privati per le risorse PaaS specifiche (Azure SQL, Key Vault, archiviazione) in base ai requisiti dell'applicazione.
  • Centralizzare le zone DNS nell'hub: Le zone DNS private (ad esempio, privatelink.database.windows.net) si trovano nella sottoscrizione di connettività e sono collegate a tutte le reti virtuali spoke. Questo approccio garantisce una risoluzione dei nomi coerente ed evita il DNS split-brain.
  • Disattivare l'accesso pubblico nelle risorse PaaS: Dopo aver creato un endpoint privato, disattivare l'accesso alla rete pubblica nella risorsa PaaS di destinazione. In caso contrario, il traffico può comunque raggiungere il servizio tramite Internet, sconfiggendo lo scopo della connettività privata.
  • Combinazione con l'integrazione della macchina virtuale: il servizio app e Funzioni di Azure usano l'integrazione con la macchina virtuale per instradare le chiamate in uscita attraverso la macchina virtuale spoke, raggiungendo i servizi PaaS tramite endpoint privati nella stessa macchina virtuale o in una macchina virtuale con peering.

Azure Migrate appliance supporta la connettività dell'endpoint privato, che protegge il traffico del piano di controllo della migrazione. Oltre a questo, rinvia la pianificazione di collegamento privato alla fase di ottimizzazione post-migrazione:

  • Azure Migrate con endpoint privato: durante il processo di migrazione, l'appliance Azure Migrate può usare un endpoint privato per comunicare con il progetto Azure Migrate. Questo approccio consente di mantenere il traffico di controllo della migrazione fuori dalla rete Internet pubblica.
  • Posticipare l'adozione su larga scala di collegamento privato: concentrarsi prima sulla connettività di transito inter-cloud. Dopo la migrazione e la stabilizzazione dei carichi di lavoro in Azure, pianificare endpoint privati per i servizi PaaS come passaggio di ottimizzazione separato.
  • Riservare spazio per la subnet: anche se per ora si salta il collegamento privato, riservare una subnet in ogni spoke per futuri endpoint privati. I carichi di lavoro tra cloud che successivamente adottano Azure servizi PaaS richiedono questa capacità.

Prerequisiti

Prima di implementare l'accesso PaaS privato, verificare di disporre delle risorse e delle conoscenze seguenti:

  • Una rete virtuale distribuita con almeno una subnet. Gli endpoint privati richiedono una subnet con indirizzi IP disponibili. Per la progettazione della rete virtuale, vedere Reti virtuali e subnet.
  • Un servizio PaaS Azure per connettersi privatamente. Il servizio deve supportare endpoint di servizio o collegamento privato. Consultare la documentazione sulla disponibilità di collegamento privato di Azure per il servizio.
  • Informazioni sull'infrastruttura DNS. Gli endpoint privati richiedono una zona DNS privata. Se si usano server DNS personalizzati, sono necessari server d'inoltro condizionale che puntano a DNS di Azure (168.63.129.16). Per i modelli di progettazione DNS, vedere l'articolo Integrazione DNS per endpoint privati in Risorse correlate.
  • Pianificazione degli indirizzi IP. Ogni endpoint privato usa un indirizzo IP privato dalla subnet. Pianifica di conseguenza le dimensioni delle subnet. Per indicazioni, vedere Pianificazione degli indirizzi IP .

Considerazioni relative alla sicurezza

La connettività PaaS privata influisce direttamente sul comportamento di esfiltrazione dei dati, sull'affidabilità DNS e sull'imposizione dei criteri di rete. Quando si progetta l'implementazione, prendere in considerazione le indicazioni seguenti.

Prevenzione dell'esfiltrazione dei dati

Gli endpoint privati offrono la protezione dell'esfiltrazione più avanzata perché ogni endpoint viene mappato a una singola istanza di risorsa. Un utente o un'applicazione nella rete virtuale può raggiungere solo l'account di archiviazione o il database specifico per cui è configurato l'endpoint privato. Non possono reindirizzare i dati a un'istanza diversa dello stesso tipo di servizio.

Gli endpoint di servizio, al contrario, limitano l'accesso a livello di rete virtuale, ma si applicano a tutte le istanze di un tipo di servizio. Ad esempio, un endpoint di servizio per Archiviazione di Azure significa che la rete virtuale può raggiungere qualsiasi account Archiviazione di Azure che concede l'accesso, non solo l'account previsto. Questo divario rende gli endpoint di servizio insufficienti per gli ambienti in cui l'esfiltrazione dei dati è un problema di conformità.

Configurazione della zona DNS

Diagramma che mostra il flusso di risoluzione DNS dell'endpoint privato dal client attraverso DNS di Azure e la zona DNS privata all'account di archiviazione.

Gli endpoint privati dipendono dalla risoluzione DNS corretta per funzionare. Quando si crea un endpoint privato, si configura una zona DNS privata (ad esempio, privatelink.blob.core.windows.net per Archiviazione BLOB di Azure) in modo che l'FQDN del servizio si risolva nell'indirizzo IP privato anziché nell'indirizzo IP pubblico.

La configurazione errata delle zone DNS può causare:

  • Applicazioni che vengono risolte all'indirizzo IP pubblico, aggirando completamente l'endpoint privato.
  • I client locali non sono in grado di raggiungere l'INDIRIZZO IP privato perché i server d'inoltro condizionale non sono configurati.
  • Problemi di DNS split-brain per cui alcuni client risolvono privatamente e altri tramite DNS pubblico.

Centralizzare le zone DNS private in una sottoscrizione di servizi condivisi o di connettività e collegarle a tutte le reti virtuali che richiedono la risoluzione. Usare Criteri di Azure per applicare l'integrazione della zona DNS privata quando vengono creati endpoint privati.

Criteri di rete nelle subnet degli endpoint privati

I gruppi di sicurezza di rete (NSG) e le route definite dall'utente sono ora supportati nelle subnet degli endpoint privati. Questo supporto è disabilitato per impostazione predefinita e deve essere abilitato in modo esplicito per ogni subnet. Dopo aver abilitato i criteri di rete:

  • È possibile applicare le regole del gruppo di sicurezza di rete per controllare quali origini possono raggiungere l'endpoint privato.
  • È possibile usare le UDR per instradare il traffico degli Endpoint privati attraverso un'appliance virtuale di rete ai fini dell'ispezione.
  • È possibile fare riferimento agli endpoint privati nelle regole del gruppo di sicurezza delle applicazioni .

Abilitare i criteri di rete nelle subnet degli endpoint privati negli ambienti di produzione per mantenere un comportamento di sicurezza coerente in tutte le subnet della rete virtuale.

Importante

Dopo aver configurato un endpoint privato per un servizio PaaS, disattivare l'accesso alla rete pubblica in tale servizio. Se l'accesso pubblico rimane abilitato, il traffico può comunque raggiungere il servizio tramite Internet, che sconfigge lo scopo della connettività privata.

DNS privato zone per i servizi comuni

Nella tabella seguente sono elencate le zone DNS private necessarie per i servizi PaaS di uso comune Azure.

Servizio di Azure zona DNS privato
Archiviazione BLOB di Azure (Servizio di archiviazione Blob di Azure) privatelink.blob.core.windows.net
Database SQL di Microsoft Azure privatelink.database.windows.net
Azure Key Vault (Archivio chiavi di Azure) privatelink.vaultcore.azure.net
Azure Cosmos DB, un servizio di database distribuito globale di Microsoft privatelink.documents.azure.com
Servizio app di Azure privatelink.azurewebsites.net

Tip

Quando si crea un endpoint privato nel portale di Azure, spesso crea automaticamente una zona DNS privata associata. L'eliminazione dell'endpoint privato non rimuove sempre la zona o i relativi collegamenti di rete virtuale. Controllare periodicamente gli endpoint privati orfani e le zone DNS private. Aumentano i costi e la complessità della configurazione di risoluzione dei nomi.

Perimetro di sicurezza di rete per l'accesso PaaS

collegamento privato controlla il modo in cui il traffico raggiunge un servizio PaaS tramite un indirizzo IP privato. Network Security Perimeter (NSP) controlla quali reti e risorse possono comunicare con tale servizio. NSP aggiunge un limite esplicito per le risorse PaaS, ad esempio Archiviazione di Azure, database SQL di Azure e Azure Key Vault: le risorse all'interno del perimetro comunicano liberamente, mentre l'accesso dall'esterno viene negato per impostazione predefinita, a meno che non lo consenta una regola di accesso. Usare NSP insieme agli endpoint privati quando è necessaria la protezione dell'esfiltrazione dei dati a livello PaaS nelle progettazioni a sicurezza elevata. Per la posizione di NSP in tutti i livelli di sicurezza, vedere la matrice del comportamento di sicurezza nella panoramica.

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Accesso a Internet in uscita: controllare il modo in cui i carichi di lavoro migrati raggiungono Internet tramite un percorso di uscita centralizzato.

Nel prossimo percorso di modernizzazione:

Accesso a Internet in uscita: instradare tutto il traffico in uscita degli spoke attraverso il firewall dell'hub per un controllo uniforme gestito centralmente dall'IT.

Il prossimo passo nel tuo percorso multicloud:

Monitoraggio e diagnostica della rete: ottenere visibilità sul traffico tra cloud e la connettività degli endpoint privati.

Se la tua architettura multicloud include un accesso a Internet in uscita centralizzato, leggi prima Accesso a Internet in uscita.

  • Last updated on