Condividi tramite


Proteggere l'origine con collegamento privato in Frontdoor di Azure Premium

Si applica a: ✔️ Frontdoor Premium

Collegamento privato di Azure consente di accedere ai servizi PaaS di Azure e servizi ospitati in Azure tramite un endpoint privato nella rete virtuale. Il traffico tra la rete virtuale e il servizio attraversa la rete backbone Microsoft, impedendone l'esposizione alla rete Internet pubblica.

Frontdoor di Azure Premium può connettersi all'origine tramite collegamento privato. L'origine può essere ospitata in una rete virtuale o ospitata come servizio PaaS, ad esempio App Web di Azure o Archiviazione di Azure. Il collegamento privato elimina la necessità di accedere pubblicamente all'origine.

Diagramma di Frontdoor di Azure con collegamento privato abilitato.

Quando si abilita il collegamento privato all'origine in Frontdoor di Azure Premium, Frontdoor crea un endpoint privato per conto dell'utente da una rete privata a livello di area gestita di Frontdoor di Azure. Si riceve una richiesta di endpoint privato di Frontdoor di Azure all'origine in attesa dell'approvazione.

È necessario approvare la connessione all'endpoint privato prima che il traffico possa passare privatamente all'origine. È possibile approvare le connessioni di endpoint privati usando il portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell. Per altre informazioni, vedere Gestire una connessione endpoint privato.

Dopo aver abilitato un'origine per il collegamento privato e aver approvato la connessione all'endpoint privato, la connessione può richiedere alcuni minuti. Durante questo periodo, le richieste all'origine ricevono un messaggio di errore di Frontdoor di Azure. Il messaggio di errore viene eliminato una volta stabilita la connessione.

Dopo l'approvazione della richiesta, viene assegnato un endpoint privato dedicato per il routing del traffico dalla rete virtuale gestita di Frontdoor di Azure. Il traffico proveniente dai client raggiungerà i POP globali di Frontdoor di Azure e quindi viene instradato sulla rete backbone Microsoft al cluster a livello di area afd che ospita la rete virtuale gestita contenente l'endpoint privato dedicato. Il traffico viene quindi instradato verso l'origine attraverso la piattaforma di collegamento privato sulla rete backbone di Microsoft. Di conseguenza, il traffico in ingresso verso l'origine è protetto al momento in cui arriva ad Azure Front Door.

Nota

  • Questa funzionalità supporta solo la connettività tramite link privato dall'AFD all'origine. La connettività privata da client ad AFD non è supportata.

Origini supportate

Il supporto dell'origine per la connettività diretta degli endpoint privati è attualmente limitato ai tipi di origine seguenti.

Tipo di origine Documentazione
Servizio app (app Web, app per le funzioni) Connetti AFD a un'origine di app Web/app per le funzioni tramite collegamento privato.
Archiviazione BLOB Connettere AFD a un'origine di un account di archiviazione con Collegamento Privato.
Sito Web statico Connettere AFD a un'origine del sito Web statico di archiviazione con collegamento privato.
Servizi di bilanciamento del carico interni o servizi che espongono servizi di bilanciamento del carico interni, ad esempio il servizio Azure Kubernetes o Azure Red Hat OpenShift Collegare AFD a un'origine interna del bilanciamento del carico con Private Link.
Gestione API Connettere AFD a un'origine di Gestione API con collegamento privato.
Gateway delle applicazioni Connettere AFD a un'origine del gateway di applicazione con collegamento privato.
App contenitore di Azure Connettere AFD a un'origine di App Azure Container con collegamento privato.

Nota

  • Questa funzionalità non è supportata per gli Azure App Service Slots e l'applicazione web statica di Azure.

Aree di disponibilità

Il collegamento privato di Frontdoor di Azure è disponibile nelle aree seguenti:

Americhe Europa Africa Asia Pacifico
Brasile meridionale Francia centrale Sudafrica settentrionale Australia orientale
Canada centrale Germania centro-occidentale India centrale
Stati Uniti centrali Europa settentrionale Giappone orientale
Stati Uniti orientali Norvegia orientale Corea centrale
Stati Uniti orientali 2 Regno Unito meridionale Asia orientale
Stati Uniti centro-meridionali Europa occidentale Asia sud-orientale
West US 2 (Regione Ovest degli Stati Uniti 2) Svezia centrale
Stati Uniti occidentali 3
Governo degli Stati Uniti, Arizona
Governo degli Stati Uniti, Texas
Governo degli Stati Uniti, Virginia

La funzionalità Collegamento privato di Frontdoor di Azure è indipendente dall'area, ma per la migliore latenza è consigliabile scegliere sempre un'area di Azure più vicina all'origine quando si sceglie di abilitare l'endpoint collegamento privato di Frontdoor di Azure. Se l'area dell'origine non è supportata nell'elenco delle aree supportate collegamento privato, selezionare l'area più vicina successiva. È possibile usare le statistiche di latenza round trip della rete di Azure per determinare l'area più vicina in termini di latenza.

  • Frontdoor di Azure non consente la combinazione di origini pubbliche e private nello stesso gruppo di origine. In questo modo possono verificarsi errori durante la configurazione o mentre AFD cerca di inviare il traffico alle origini pubbliche/private. Mantenere tutte le origini pubbliche in un singolo gruppo di origine e mantenere tutte le origini private in un gruppo di origine diverso.
  • Miglioramento della ridondanza:
    • Per migliorare la ridondanza a livello di origine, assicurarsi di avere più origini abilitate per il collegamento privato all'interno dello stesso gruppo di origine in modo che AFD possa distribuire il traffico tra più istanze dell'applicazione. Se un'istanza non è disponibile, altre origini possono comunque ricevere traffico.
    • Per instradare il traffico di Private Link, le richieste vengono instradate dai POP AFD alla rete virtuale gestita da AFD ospitata nei cluster regionali di AFD. Per ottenere ridondanza nel caso in cui il cluster regionale non sia raggiungibile, è consigliabile configurare più origini (ciascuna con una regione di collegamento privato diversa) nello stesso gruppo di origine AFD. In questo modo, anche se un cluster a livello di area non è disponibile, altre origini possono comunque ricevere traffico tramite un cluster a livello di area diverso. Di seguito è riportato l'aspetto di un gruppo di origine con ridondanza a livello di origine e a livello di area. Diagramma che mostra un gruppo di origine con ridondanza sia a livello di origine che a livello di area.
  • Durante l'approvazione della connessione all'endpoint privato o dopo l'approvazione della connessione all'endpoint privato, se si fa doppio clic sull'endpoint privato, verrà visualizzato un messaggio di errore che indica che non si ha accesso. Copiare i dettagli dell'errore e inviarli agli amministratori per ottenere l'accesso a questa pagina." Questo è previsto perché l'endpoint privato è ospitato all'interno di una sottoscrizione gestita da Frontdoor di Azure.
  • Per proteggere la piattaforma, ogni cluster regionale AFD ha un limite di 7200 RPS (richieste al secondo) per un profilo AFD. Le richieste superiori a 7200 RPS saranno limitate con "429 Troppe richieste". Se si sta eseguendo l'onboarding o si prevede un traffico superiore a 7200 RPS, è consigliabile distribuire più origini (ognuna con una diversa regione di collegamento privato) in modo che il traffico venga distribuito tra più cluster regionali AFD. È consigliabile che ogni origine sia un'istanza separata dell'applicazione per migliorare la ridondanza a livello di origine. Tuttavia, se non è possibile gestire istanze separate, è comunque possibile configurare più origini a livello di front-end con ogni origine che punta allo stesso nome host, ma le aree vengono mantenute diverse. In questo modo AFD instrada il traffico alla stessa istanza, ma tramite cluster regionali diversi.

Associazione di un endpoint privato con un profilo Frontdoor di Azure

Creazione dell'endpoint privato

All'interno di un singolo profilo frontdoor di Azure, se due o più origini abilitate per il collegamento privato vengono create con lo stesso set di ID risorsa, ID gruppo e area, per tutte queste origini viene creato un solo endpoint privato. Le connessioni al back-end possono essere abilitate usando questo endpoint privato. Questa configurazione significa che è necessario approvare l'endpoint privato una sola volta perché viene creato un solo endpoint privato. Se si creano più origini abilitate per il collegamento privato usando lo stesso set di percorsi di collegamento privato, ID risorsa e ID gruppo, non è necessario approvare altri endpoint privati.

Endpoint privato singolo

Ad esempio, un singolo endpoint privato viene creato per tutte le origini diverse in gruppi di origine diversi, ma nello stesso profilo Frontdoor di Azure, come illustrato nella tabella seguente:

Diagramma che mostra un singolo endpoint privato creato per le origini create nello stesso profilo di Frontdoor di Azure.

Più endpoint privati

Un nuovo endpoint privato viene creato nello scenario seguente:

  • Se l'area, l'ID risorsa o l'ID gruppo cambia, AFD considera che la posizione del collegamento privato e il nome host sia cambiata, comporta la creazione di endpoint privati aggiuntivi e ognuno deve essere approvato.

    Diagramma che mostra un endpoint privato multiplo creato perché cambia nell'area e nell'ID risorsa per l'origine.

  • L'abilitazione del Collegamento privato per le origini in diversi profili Frontdoor creerà endpoint privati aggiuntivi e richiede l'approvazione per ognuno di essi.

    Diagramma che mostra un endpoint privato multiplo creato perché l'origine è associata a più profili Frontdoor di Azure.

Rimozione dell'endpoint privato

Quando un profilo Frontdoor di Azure viene eliminato, vengono eliminati anche gli endpoint privati associati al profilo.

Endpoint privato singolo

Se AFD-Profile-1 viene eliminato, viene eliminato anche l'endpoint privato PE1 in tutte le origini.

Diagramma che mostra che se AFD-Profile-1 viene eliminato, viene eliminato PE1 in tutte le origini.

Più endpoint privati

  • Se AFD-Profile-1 viene eliminato, tutti gli endpoint privati da PE1 a PE4 vengono eliminati.

    Il diagramma mostra che, se AFD-Profile-1 viene eliminato, tutti gli endpoint privati da PE1 a PE4 verranno eliminati.

  • L'eliminazione di un profilo Frontdoor di Azure non influisce sugli endpoint privati creati per un profilo Frontdoor diverso.

    Diagramma che mostra il profilo Frontdoor di Azure che viene eliminato ma non influisce sugli endpoint privati in altri profili Frontdoor.

    Ad esempio:

    • Se AFD-Profile-2 viene eliminato, viene rimosso solo PE5.
    • Se AFD-Profile-3 viene eliminato, viene rimosso solo PE6.
    • Se AFD-Profile-4 viene eliminato, viene rimosso solo PE7.
    • Se AFD-Profile-5 viene eliminato, viene rimosso solo PE8.

Passaggi successivi