Panoramica del supporto della rete virtuale Microsoft Azure

Note

È disponibile Power Platform Rete virtuale community su Microsoft Viva Engage. Pubblicare eventuali domande o commenti relativi a questa funzionalità. Partecipare compilando una richiesta tramite il modulo seguente: Richiedere l'accesso a Finance and Operations Viva Engage Community.

Usando il supporto di Rete virtuale di Azure (VNet) per Power Platform, è possibile integrare Power Platform con risorse all'interno della rete virtuale senza esporle tramite Internet pubblico. Il supporto di VNet usa la delega della subnet di Azure per gestire il traffico in uscita da Power Platform in fase di esecuzione. Utilizzando la delega della subnet di Azure, le risorse protette non devono essere disponibili su Internet per integrarsi con Power Platform. Usando il supporto della rete virtuale, i componenti di Power Platform possono chiamare le risorse di proprietà dell'azienda all'interno della rete, indipendentemente dal fatto che siano ospitate in Azure o in locale e usare plug-in e connettori per effettuare chiamate in uscita.

Power Platform si integra generalmente con le risorse aziendali su reti pubbliche. Con le reti pubbliche, le risorse aziendali devono essere accessibili da un elenco di intervalli IP o tag di servizio Azure, che descrivono gli indirizzi IP pubblici. Tuttavia, il supporto della rete virtuale per Power Platform consente di usare una rete privata e di integrarsi ancora con servizi o servizi cloud ospitati all'interno della rete aziendale.

I servizi Azure sono protetti all'interno di una rete virtuale da endpoint privati. È possibile usare ExpressRoute per trasferire le risorse locali all'interno della rete virtuale.

Power Platform usa il servizio di rete virtuale e le subnet delegate per effettuare chiamate in uscita alle risorse aziendali tramite la rete privata aziendale. Usando una rete privata, non è necessario instradare il traffico su Internet pubblico, che potrebbe esporre le risorse aziendali.

In una rete virtuale si ha il controllo completo sul traffico in uscita da Power Platform. L'amministratore di rete applica i criteri di rete al traffico. Il diagramma seguente illustra come le risorse all'interno della rete interagiscono con una rete virtuale.

Screenshot del modo in cui le risorse all'interno di una rete aziendale interagiscono con una rete virtuale.

Vantaggi del supporto di Azure VNet

Usando il supporto della rete virtuale, i componenti Power Platform e Dataverse ottengono tutti i vantaggi offerti dalla delega della subnet Azure, ad esempio:

  • Protezione dei dati: il supporto della rete virtuale consente ai servizi Power Platform di connettersi alle risorse private e protette senza esporle a Internet.

  • Nessun accesso non autorizzato: il supporto per VNet consente di connettersi alle risorse senza richiedere intervalli IP o tag di servizio di Power Platform per la connessione.

Stima delle dimensioni della subnet per gli ambienti Power Platform

I dati di telemetria e le osservazioni dell'anno precedente indicano che gli ambienti di produzione richiedono in genere da 25 a 30 indirizzi IP, con la maggior parte dei casi d'uso che rientrano in questo intervallo. In base a queste informazioni, allocare da 25 a 30 indirizzi IP per gli ambienti di produzione e da 6 a 10 indirizzi IP per ambienti non di produzione, ad esempio ambienti sandbox o di sviluppo. I contenitori connessi alla rete virtuale usano principalmente indirizzi IP all'interno della subnet. Quando l'ambiente inizia a essere usato, crea almeno quattro contenitori, che vengono ridimensionati in modo dinamico in base al volume delle chiamate, anche se in genere rimangono entro l'intervallo da 10 a 30 contenitori. Questi contenitori eseguono tutte le richieste per i rispettivi ambienti ed gestiscono in modo efficiente le richieste di connessione parallele.

Pianificazione per più ambienti

Se si usa la stessa subnet delegata per più ambienti Power Platform, potrebbe essere necessario un blocco più ampio di indirizzi IP CIDR (Classless Inter-Domain Routing). Prendere in considerazione il numero consigliato di indirizzi IP per gli ambienti di produzione e non di produzione quando si collegano gli ambienti a un singolo criterio. Ogni subnet riserva cinque indirizzi IP, quindi includere questi indirizzi riservati nella stima.

Note

Per migliorare la visibilità sull'utilizzo delle risorse, il team di prodotto sta lavorando per rendere visibile il consumo di IP delle subnet delegate per le politiche aziendali e delle subnet.

Esempio di allocazione IP

Consideriamo un tenant con due criteri aziendali. Il primo criterio è per gli ambienti di produzione e il secondo criterio è per gli ambienti non di produzione.

Criteri aziendali di produzione

Se si dispone di quattro ambienti di produzione associati ai criteri aziendali e ogni ambiente richiede 30 indirizzi IP, l'allocazione ip totale è:

(Quattro ambienti x 30 INDIRIZZI IP) + 5 indirizzi IP riservati = 125 INDIRIZZI IP

Questo scenario richiede un blocco CIDR di /25, con capacità per 128 IP.

Politica aziendale di non produzione

Per i criteri aziendali non di produzione con 20 ambienti di sviluppo e sandbox e ogni ambiente richiede 10 indirizzi IP, l'allocazione IP totale è:

(Venti ambienti x 10 INDIRIZZI IP) + 5 indirizzi IP riservati = 205 INDIRIZZI IP

Questo scenario richiede un blocco CIDR di /24, che ha capacità per 256 INDIRIZZI IP e ha spazio sufficiente per aggiungere altri ambienti ai criteri aziendali.

Scenari supportati

Power Platform supporta la rete virtuale sia per i plug-in dataverse che per i connettori. Usando questo supporto, è possibile creare connettività protetta, privata e in uscita da Power Platform alle risorse all'interno della rete virtuale. I plug-in e i connettori di Dataverse migliorano la sicurezza dell'integrazione dei dati connettendosi a origini dati esterne da Power Apps, Power Automate e app Dynamics 365. Ad esempio, puoi:

  • Usare i plug-in Dataverse per connettersi alle origini dati cloud, ad esempio Azure SQL, Archiviazione di Azure, archiviazione BLOB o Azure Key Vault. Puoi proteggere i tuoi dati dall'esfiltrazione di dati e da altri incidenti.
  • Usare i plug-in Dataverse per connettersi in modo sicuro a risorse private protette da endpoint in Azure, ad esempio l'API Web o qualsiasi risorsa all'interno della rete privata, ad esempio SQL e API Web. Puoi proteggere i tuoi dati da violazioni di dati e altre minacce esterne.
  • Usare connettori supportati dalla rete virtuale, ad esempio SQL Server per connettersi in modo sicuro alle origini dati ospitate nel cloud, ad esempio Azure SQL o SQL Server, senza esponerle a Internet. Allo stesso modo, puoi usare il connettore Azure Queue per stabilire connessioni sicure a code di Azure private abilitate per endpoint.
  • Usare il connettore Azure Key Vault per connettersi in modo sicuro a un Azure Key Vault privato protetto da endpoint.
  • Usare connettori personalizzati per connettersi in modo sicuro ai servizi protetti da endpoint privati in Azure o servizi ospitati all'interno della rete privata.
  • Usare Azure File Storage per connettersi in modo sicuro all'archiviazione file privata di Azure con endpoint abilitati.
  • Usare HTTP con Microsoft Entra ID (pre-autorizzato) per recuperare in modo sicuro le risorse su reti virtuali da vari servizi Web, autenticati da Microsoft Entra ID o da un servizio Web locale.

Limitazioni

  • I plug-in a basso codice di Dataverse che usano connettori non sono supportati fino a quando tali tipi di connettore non vengono aggiornati per usare la delega della subnet.
  • Utilizzi operazioni di copia, backup e ripristino del ciclo di vita dell'ambiente su ambienti Power Platform supportati dalla rete virtuale. È possibile eseguire l'operazione di ripristino all'interno della stessa rete virtuale e in ambienti diversi, purché siano connessi alla stessa rete virtuale. Inoltre, l'operazione di ripristino è consentita dagli ambienti che non supportano le reti virtuali a quelli che le supportano.

Regioni supportate

Prima di creare la rete virtuale e i criteri aziendali, convalidare l'area dell'ambiente Power Platform per assicurarsi che si tratti di un'area supportata. Usare il Get-EnvironmentRegion cmdlet dal modulo PowerShell di diagnostica della subnet per recuperare le informazioni sull'area geografica dell'ambiente.

Dopo aver confermato l'area dell'ambiente, assicurarsi di configurare i criteri aziendali e le risorse Azure nelle aree Azure supportate corrispondenti. Ad esempio, se l'ambiente Power Platform si trova nel Regno Unito, la rete virtuale e le subnet devono trovarsi nelle aree uksouth e ukwest Azure. Se un'area di Power Platform include più di due coppie di aree disponibili, è necessario usare la coppia di aree specifica corrispondente all'area dell'ambiente. Ad esempio, se Get-EnvironmentRegion restituisce westus per l'ambiente, la rete virtuale e le subnet devono trovarsi in eastus e westus.

Area geografica di Power Platform Regione Azure
Stati Uniti Stati Uniti orientali, Stati Uniti occidentali
Sudafrica sudafricanord, sudafricasud
Regno Unito Regno Unito meridionale, Regno Unito occidentale
Giappone Giappone Est, Giappone Ovest
India India centrale, India del sud
Francia francecentral, francesouth
Europa Europa occidentale, Europa settentrionale
Germania Germania Nord, Germania Ovest-Centrale
Svizzera svizzera nord, svizzera ovest
Canada Canada centrale, Canada orientale
Brasile Brasile meridionale
Australia Australia sud-orientale, Australia orientale
Asia Asia orientale, Asia sud-orientale
Emirati Arabi Uniti uaenorth
Corea koreasouth, koreacentral
Norvegia Norvegia Ovest, Norvegia Est
Singapore Asia sud-orientale
Svezia swedencentral
Italia italynorth
Governo degli Stati Uniti usgovtexas, usgovvirginia

Note

Il supporto negli ambienti cloud del governo degli Stati Uniti è attualmente disponibile solo per gli ambienti distribuiti in Government Community Cloud – High (GCC High) o Department of Defense (DoD). Il supporto per gli ambienti GCC (Government Community Cloud) non è disponibile.

Servizi supportati

La tabella seguente elenca i servizi che supportano la delega delle subnet di Azure per il supporto VNet di Power Platform.

Area Servizi di Power Platform Disponibilità del supporto per VNet
Dataverse Plug-in di Dataverse Generalmente disponibile
Connettori Generalmente disponibile
Connettori Generalmente disponibile

Ambienti supportati

Il supporto di VNet per Power Platform non è disponibile per tutti gli ambienti Power Platform. Nella tabella seguente sono elencati i tipi di ambiente che supportano la rete virtuale.

Tipo di ambiente Supportato
Produzione Yes
Default Yes
Sandbox Yes
Sviluppatore Yes
Trial No
Microsoft Dataverse per Teams No

Considerazioni sull'abilitazione del supporto della rete virtuale per l'ambiente Power Platform

Quando si usa il supporto della rete virtuale in un ambiente Power Platform, tutti i servizi supportati, ad esempio plug-in e connettori dataverse, eseguono richieste in fase di esecuzione nella subnet delegata e sono soggetti ai criteri di rete. Le richieste di risorse disponibili al pubblico inizierebbero a fallire.

Important

Prima di abilitare il supporto dell'ambiente virtuale per un ambiente Power Platform, controllare il codice dei plug-in e dei connettori. Aggiornare gli URL e le connessioni per lavorare con la connettività privata.

Ad esempio, un plug-in potrebbe provare a connettersi a un servizio disponibile pubblicamente, ma i criteri di rete non consentono l'accesso a Internet pubblico all'interno della rete virtuale. I criteri di rete bloccano la chiamata dal plug-in. Per evitare la chiamata bloccata, è possibile ospitare il servizio disponibile pubblicamente nella rete virtuale. In alternativa, se il servizio è ospitato in Azure, è possibile usare un endpoint privato nel servizio prima di attivare il supporto della rete virtuale nell'ambiente Power Platform.

Domande frequenti

Qual è la differenza tra un gateway dati di rete virtuale e il supporto VNet per Power Platform?

Un gateway dati di rete virtuale è un gateway gestito usato per accedere ai servizi Azure e Power Platform dall'interno della rete virtuale senza dover configurare un gateway dati locale. Ad esempio, il gateway è ottimizzato per carichi di lavoro ETL (estrazione, trasformazione, caricamento) in flussi di dati di Power BI e Power Platform.

Il supporto di Azure VNet per Power Platform usa una delega di subnet di Azure per il tuo ambiente Power Platform. Le subnet vengono utilizzate dai carichi di lavoro all'interno dell'ambiente Power Platform. I carichi di lavoro dell'API Power Platform usano il supporto della rete virtuale perché le richieste sono di breve durata e ottimizzate per un numero elevato di richieste.

Quali sono gli scenari in cui dovrei usare il supporto VNet per Power Platform e il gateway dati della rete virtuale?

Il supporto della rete virtuale per Power Platform è l'unica opzione supportata per tutti gli scenari per la connettività in uscita da Power Platform, ad eccezione dei flussi di dati di Power BI e Power Platform.

Power BI e i flussi di dati di Power Platform continuano a usare il gateway dati della rete virtuale (VNet).

Come è possibile garantire che una subnet di rete virtuale o un gateway dati di un cliente non venga utilizzato da un altro cliente in Power Platform?

  • Il supporto di VNet per Power Platform utilizza la delega di subnet di Azure.

  • Ogni ambiente Power Platform è collegato a una subnet della rete virtuale. Solo le chiamate provenienti da tale ambiente possono accedere alla rete virtuale.

  • La delega consente di designare una subnet specifica per qualsiasi piattaforma distribuita come servizio (PaaS) di Azure che deve essere inserita nella rete virtuale.

Il supporto di VNet per il failover di Power Platform è disponibile?

Sì, è necessario delegare le reti virtuali per entrambe le aree Azure associate all'area di Power Platform. Ad esempio, se l'ambiente Power Platform si trova in Canada, è necessario creare, delegare e configurare reti virtuali in CanadaCentral e CanadaEast.

Come può un ambiente Power Platform in un'area geografica connettersi alle risorse ospitate in un'altra area geografica?

Una rete virtuale collegata a un ambiente Power Platform deve risiedere nell'area dell'ambiente Power Platform. Se la rete virtuale si trova in una regione diversa, creare una rete virtuale nella regione dell'ambiente Power Platform e usare il peering tra reti virtuali in entrambe le reti virtuali con subnet delegata delle rispettive aree di Azure per collegarla alla rete virtuale nella regione distinta.

Posso monitorare il traffico in uscita dalle subnet delegate?

Sì. È possibile usare un gruppo di sicurezza di rete e firewall per monitorare il traffico in uscita da subnet delegate. Per altre informazioni, vedere Monitor Rete virtuale di Azure.

È possibile effettuare chiamate verso Internet da plug-in o connettori dopo che al mio ambiente è stata delegata una subnet?

Sì. Per impostazione predefinita, l'accesso a Internet è disponibile per plug-in e connettori in un ambiente con subnet delegata. Collegare un gateway NAT Azure alla subnet delegata in modo che l'organizzazione possa controllare e proteggere l'accesso in uscita. Per altre informazioni, vedere Procedure consigliate per la protezione delle connessioni in uscita dai servizi Power Platform.

È possibile aggiornare l'intervallo di indirizzi IP della subnet dopo che è stato delegato a Microsoft.PowerPlatform/enterprisePolicies?

No, non mentre la funzionalità è in uso nel tuo ambiente. Non è possibile modificare l'intervallo di indirizzi IP della subnet dopo che è stato delegato a "Microsoft. PowerPlatform/enterprisePolicies." Se si modifica l'intervallo di indirizzi IP, la configurazione della delega si interrompe e l'ambiente smette di funzionare. Per modificare l'intervallo di indirizzi IP, usa Disable-SubnetInjection, apporta le modifiche necessarie e attiva quindi la funzionalità per il tuo ambiente.

È possibile aggiornare l'indirizzo DNS della rete virtuale dopo che è stato delegato a Microsoft.PowerPlatform/enterprisePolicies?

No, non mentre la funzionalità è in uso nel tuo ambiente. Non è possibile modificare l'indirizzo DNS della rete virtuale dopo che è stato delegato a Microsoft.PowerPlatform/enterprisePolicies. Se si modifica l'indirizzo DNS, la modifica non viene rilevata nella configurazione e l'ambiente potrebbe smettere di funzionare. Per modificare l'indirizzo DNS, usare Disable-SubnetInjection per scollegare tutti gli ambienti dal criterio, apportare gli aggiornamenti necessari alla VNet, attendere 30 minuti per assicurarsi che le modifiche siano state propagate e quindi riabilitare l'inserimento della subnet tramite Enable-SubnetInjection.

Posso utilizzare gli stessi criteri aziendali per più ambienti Power Platform?

Sì. Posso utilizzare gli stessi criteri aziendali per più ambienti Power Platform. Tuttavia, esiste una limitazione per cui gli ambienti con ciclo di rilascio anticipato non possono essere utilizzati con gli stessi criteri aziendali degli altri ambienti.

La rete virtuale ha un DNS personalizzato configurato. Power Platform usa il mio DNS personalizzato?

Sì. Power Platform usa il DNS personalizzato configurato nella rete virtuale che contiene la subnet delegata per risolvere tutti gli endpoint. Dopo aver delegato l'ambiente, è possibile aggiornare i plug-in per usare l'endpoint corretto in modo che il DNS personalizzato possa risolverli.

Il mio ambiente ha plug-in forniti da ISV. Questi plug-in funzionerebbero nella subnet delegata?

Sì. Tutti i plug-in dei clienti e i plug-in ISV possono essere eseguiti usando la subnet. Se i plug-in ISV hanno connettività in uscita, potrebbe essere necessario elencare gli URL nel firewall.

I miei certificati TLS dell'endpoint locale non sono firmati da autorità di certificazione root (CA) note. Sono supportati i certificati sconosciuti?

No. Power Platform richiede che l'endpoint presenti un certificato TLS con la catena completa. Non è possibile aggiungere la CA radice personalizzata all'elenco delle CA note.

Power Platform non consiglia alcuna topologia specifica. Tuttavia, i clienti usano ampiamente la topologia di rete hub-spoke in Azure.

Il collegamento di una sottoscrizione Azure al tenant di Power Platform è necessario per attivare il supporto della rete virtuale?

Sì, per abilitare il supporto della rete virtuale per gli ambienti Power Platform, è necessario associare una sottoscrizione Azure al tenant di Power Platform.

In che modo Power Platform usa la delega di subnet Azure?

Quando si assegna una subnet di Azure delegata a un ambiente Power Platform, l'ambiente utilizza l'iniezione nella VNet per distribuire il contenitore nella subnet delegata in fase di esecuzione. Durante questo processo, la scheda di interfaccia di rete (NIC) del contenitore ottiene un indirizzo IP dalla subnet delegata. L'host (Power Platform) e il contenitore comunicano tramite una porta locale nel contenitore e il traffico passa attraverso Azure Fabric.

È possibile usare una rete virtuale esistente per Power Platform?

Sì, è possibile usare una rete virtuale esistente per Power Platform, se si delega una singola subnet all'interno della rete virtuale specificamente a Power Platform. Devi dedicare la subnet delegata alla delega della subnet e non puoi utilizzarla per altri scopi.

Posso riutilizzare la stessa subnet delegata in più criteri aziendali?

No. Non è possibile riutilizzare la stessa subnet in più criteri aziendali. I criteri aziendali Power Platform devono avere una propria subnet univoca per la delega.

Che cos'è un plug-in Dataverse?

Un plug-in Dataverse è un frammento di codice personalizzato che è possibile distribuire in un ambiente Power Platform. È possibile configurare questo plug-in per l'esecuzione durante gli eventi (ad esempio una modifica dei dati) o attivarli come API personalizzata. Per altre informazioni, vedere Plug-in Dataverse.

Come viene eseguito un plug-in Dataverse?

Un plug-in Dataverse viene eseguito all'interno di un contenitore. Quando si assegna una subnet delegata a un ambiente Power Platform, la scheda di interfaccia di rete del contenitore ottiene un indirizzo IP dallo spazio indirizzi della subnet. L'host (Power Platform) e il contenitore comunicano tramite una porta locale nel contenitore e il traffico passa attraverso Azure Fabric.

È possibile eseguire più plug-in nello stesso contenitore?

Sì. In un determinato ambiente Power Platform o Dataverse, più plug-in possono essere eseguiti nello stesso contenitore. Ogni contenitore usa un indirizzo IP dallo spazio indirizzi della subnet e ogni contenitore può eseguire più richieste.

In che modo l'infrastruttura gestisce un aumento delle esecuzioni simultanee del plug-in?

Man mano che aumenta il numero di esecuzioni simultanee del plug-in, l'infrastruttura si espande o si riduce automaticamente per gestire il carico. La subnet delegata a un ambiente Power Platform deve disporre di spazi di indirizzi sufficienti per gestire il volume di picco delle esecuzioni per i carichi di lavoro in quell'ambiente Power Platform.

Chi controlla la rete virtuale e i criteri di rete associati?

Si ha la proprietà e il controllo sulla rete virtuale e sui criteri di rete associati. D'altra parte, Power Platform usa gli indirizzi IP allocati dalla subnet delegata all'interno di tale rete virtuale.

I plug-in che supportano Azure supportano la rete virtuale?

No, i plug-in che supportano Azure non supportano la rete virtuale.

Passaggi successivi

Configurare il supporto della rete virtuale

Contenuti correlati

Risolvere i problemi relativi alla rete virtuale

  • Last updated on