Isolamento rete virtuale gestita dell'area di lavoro
SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)SDK di Python azure-ai-ml v2 (corrente)
Azure Machine Learning offre supporto per l'isolamento della rete virtuale gestita (rete virtuale gestita). L'isolamento della rete virtuale gestita semplifica e automatizza la configurazione dell'isolamento della rete con una rete virtuale gestita di Azure Machine Learning predefinita a livello di area di lavoro. La rete virtuale gestita protegge le risorse di Azure Machine Learning gestite, ad esempio istanze di calcolo, cluster di calcolo, calcolo serverless ed endpoint online gestiti.
La protezione dell'area di lavoro con una rete gestita offre isolamento di rete per l'accessoin uscita dall'area di lavoro e dagli ambienti di calcoli gestiti. Una rete virtuale di Azure creata e gestita dall'utente viene usata per fornire l'isolamento della rete per l'accesso in ingresso all'area di lavoro. Ad esempio, un endpoint privato per l'area di lavoro viene creato nella Rete virtuale di Azure. Tutti i client che si connettono alla rete virtuale possono accedere all'area di lavoro tramite l'endpoint privato. Quando si eseguono processi in ambienti di calcoli gestiti, la rete gestita limita le risorse a cui l'ambiente di calcolo può accedere.
Architettura di Rete Virtuale gestita
Quando si abilita l'isolamento della rete virtuale gestita, viene creata una rete virtuale gestita per l'area di lavoro. Le risorse di calcolo gestite create per l'area di lavoro usano automaticamente questa rete virtuale gestita. La rete virtuale gestita può usare endpoint privati per le risorse di Azure usate dall'area di lavoro, ad esempio Archiviazione di Azure, Azure Key Vault e Registro Azure Container.
Esistono due diverse modalità di configurazione per il traffico in uscita dalla rete virtuale gestita:
Suggerimento
Indipendentemente dalla modalità in uscita usata, il traffico verso le risorse di Azure può essere configurato per l'uso di un endpoint privato. Ad esempio, è possibile consentire tutto il traffico in uscita verso Internet, ma limitare la comunicazione con le risorse di Azure aggiungendo regole in uscita per le risorse.
Modalità in uscita | Descrizione | Scenari |
---|---|---|
Consenti Internet in uscita | Consentire tutto il traffico Internet in uscita dalla rete virtuale gestita. | Si vuole accedere senza restrizioni alle risorse di Machine Learning su Internet, ad esempio pacchetti Python o modelli con training preliminare.1 |
Consenti solo il traffico in uscita approvato | Il traffico in uscita è consentito specificando i tag del servizio. | * Si vuole ridurre al minimo il rischio di esfiltrazione di dati, ma è necessario preparare tutti gli artefatti di apprendimento automatico necessari nell'ambiente privato. * Si vuole configurare l'accesso in uscita a un elenco approvato di servizi, tag del servizio o FQDN. |
Disabilitata | Il traffico in ingresso e in uscita non è limitato o si usa la propria rete virtuale di Azure per proteggere le risorse. | Si vuole che l'accesso pubblico e il traffico in uscita dall'area di lavoro o si gestisca l'isolamento della rete con la propria rete virtuale di Azure. |
1: È possibile usare le regole in uscita con la modalità Consentire solo connessioni in uscita approvate per ottenere lo stesso risultato dell'uso previsto dalla modalità di Consentire internet in uscita. Le differenze sono le seguenti:
- È necessario aggiungere regole per ogni connessione in uscita che bisogna consentire.
- L'aggiunta di regole in uscita FQDN aumenta i costi perché questo tipo di regola usa il Firewall di Azure. Per altre informazioni, vedere la pagina Prezzi.
- Le regole predefinite per Consenti solo il traffico in uscita approvato sono progettate per ridurre al minimo il rischio di esfiltrazione di dati. Eventuali regole in uscita aggiunte possono aumentare il rischio.
La rete virtuale gestita è preconfigurata con le regole predefinite necessarie. Viene configurato anche per le connessioni endpoint private all'area di lavoro, l'archiviazione predefinita dell'area di lavoro, il registro contenitori e l'insieme di credenziali delle chiavi se sono configurati come privati o la modalità di isolamento dell'area di lavoro è impostata per consentire solo l'approvazione in uscita. Dopo aver scelto la modalità di isolamento, potrebbe essere necessario considerare solo altri requisiti in uscita da aggiungere.
Il diagramma seguente mostra una rete virtuale gestita configurata per consentire Internet in uscita:
Il diagramma seguente mostra una rete virtuale gestita configurata per consentire solo i valori in uscita approvati:
Nota
In questa configurazione, l'archiviazione, l'insieme di credenziali delle chiavi e il registro contenitori usati dall'area di lavoro vengono contrassegnati come privati. Poiché vengono contrassegnati come privati, viene usato un endpoint privato per comunicare con questi.
Nota
Una volta configurata un'area di lavoro della rete virtuale gestita per consentire internet in uscita, l'area di lavoro non può essere riconfigurata in modo che sia disabilitata. Analogamente, dopo che un'area di lavoro di rete virtuale gestita è configurata per consentire solo connessioni in uscita approvate, l'area di lavoro non può essere riconfigurata per consentire internet in uscita. Tenere presente questo aspetto quando si seleziona la modalità di isolamento della rete virtuale gestita nell'area di lavoro.
Studio di Azure Machine Learning
Se si vuole usare il notebook integrato o creare dei set di dati nell'account di archiviazione predefinito da Studio, il client deve accedere all'account di archiviazione predefinito. Creare un endpoint privato o un endpoint di servizio per l'account di archiviazione predefinito nella rete virtuale di Azure usata dai client.
Parte dello studio di Azure Machine Learning viene eseguita in locale nel Web browser del client e comunica direttamente con l'archiviazione predefinita per l'area di lavoro. La creazione di un endpoint privato o di un endpoint di servizio (per l'account di archiviazione predefinito) nella rete virtuale del client garantisce che il client possa comunicare con l'account di archiviazione.
Se l'account di archiviazione di Azure associato all'area di lavoro ha accesso alla rete pubblica disabilitato, verificare che all'identità gestita dell'area di lavoro venga concesso l'endpoint privato creato nella rete virtuale client. Questo vale sia per gli endpoint privati di blog che per l'archiviazione file. Il ruolo non è necessario per l'endpoint privato creato dalla rete virtuale gestita.
Per altre informazioni sulla creazione di un endpoint privato o di un endpoint di servizio, vedere gli articoli Connettersi privatamente a un account di archiviazione ed Endpoint di servizio.
Risorse associate protette
Se si aggiungono i servizi seguenti alla rete virtuale usando un endpoint di servizio o un endpoint privato (disabilitando l'accesso pubblico), consentire ai servizi Microsoft attendibili di accedere a questi servizi:
Service | Informazioni sugli endpoint | Consentire informazioni attendibili |
---|---|---|
Azure Key Vault | Endpoint di servizio Endpoint privato |
Consentire ai servizi Microsoft attendibili di ignorare il firewall |
Account di archiviazione di Azure | Endpoint servizio ed endpoint privato Endpoint privato |
Concedere l'accesso da istanze di risorse di Azure o Concedere l'accesso ai servizi di Azure attendibili |
Registro Azure Container | Endpoint privato | Consenti servizi attendibili |
Prerequisiti
Prima di seguire la procedura descritta in questo articolo, assicurarsi di disporre dei prerequisiti seguenti:
Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare. Provare la versione gratuita o a pagamento di Azure Machine Learning.
Il provider di risorse Microsoft.Network deve essere registrato per la sottoscrizione di Azure. Questo provider di risorse viene usato dall'area di lavoro quando si creano endpoint privati per la rete virtuale gestita.
Per informazioni sulla registrazione dei provider di risorse, vedere Risoluzione degli errori di registrazione del provider di risorse.
L'identità di Azure usata per la distribuzione di una rete gestita richiede le azioni di controllo degli accessi in base al ruolo di Azure seguenti per creare endpoint privati:
Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/read
Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/write
L'interfaccia della riga di comando di Azure e l'estensione
ml
per l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Installare, configurare e usare l'interfaccia della riga di comando (v2).Suggerimento
La rete virtuale gestita di Azure Machine Learning è stata introdotta il 23 maggio 2023. Se si ha una versione precedente dell'estensione ml, potrebbe essere necessario aggiornarla affinché gli esempi riportati in questo articolo funzionino. Per aggiornare l'estensione, usare il comando seguente dell'interfaccia della riga di comando di Azure:
az extension update -n ml
Gli esempi dell'interfaccia della riga di comando in questo articolo presuppongono che si usi la shell Bash (o compatibile). Ad esempio, un sistema Linux o un sottosistema Windows per Linux.
Gli esempi dell'interfaccia della riga di comando di Azure in questo articolo usano
ws
per rappresentare il nome dell'area di lavoro erg
per rappresentare il nome del gruppo di risorse. Modificare questi valori in base alle esigenze quando si usano i comandi con la sottoscrizione di Azure.
Nota
Se si usa l'area di lavoro UAI, assicurarsi di aggiungere il ruolo di responsabile approvazione della connessione della rete aziendale di Azure per intelligenza artificiale all'identità. Per altre informazioni, vedere Identità gestita assegnata dall'utente.
Configurare una rete virtuale gestita per consentire internet in uscita
Suggerimento
La creazione della rete virtuale gestita viene posticipata fino a quando non viene creata una risorsa di calcolo o il provisioning non viene avviato manualmente. Quando si consente la creazione automatica, la creazione automatica può richiedere circa 30 minuti per creare la prima risorsa di calcolo perché esegue anche il provisioning della rete. Per altre informazioni, vedere Effettuare manualmente il provisioning della rete.
Importante
Se si prevede di inviare processi Spark serverless, è necessario avviare manualmente il provisioning. Per altre informazioni, vedere la sezioneconfigurare i processi Spark serverless.
Per configurare una rete virtuale gestita che consenta le comunicazioni in uscita su Internet, è possibile usare il parametro --managed-network allow_internet_outbound
o un file di configurazione YAML contenente le voci seguenti:
managed_network:
isolation_mode: allow_internet_outbound
È anche possibile definire le regole in uscita ad altri servizi di Azure su cui si basa l'area di lavoro. Queste regole definiscono endpoint privati che consentono a una risorsa di Azure di comunicare in modo sicuro con la rete virtuale gestita. La regola seguente illustra l'aggiunta di un endpoint privato a una risorsa BLOB di Azure.
managed_network:
isolation_mode: allow_internet_outbound
outbound_rules:
- name: added-perule
destination:
service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
spark_enabled: true
subresource_target: blob
type: private_endpoint
È possibile configurare una rete virtuale gestita usando i comandi az ml workspace create
o az ml workspace update
:
Creazione di una nuova area di lavoro:
Nell'esempio seguente viene creata una nuova area di lavoro. Il
--managed-network allow_internet_outbound
parametro configura una rete virtuale gestita per l'area di lavoro:az ml workspace create --name ws --resource-group rg --managed-network allow_internet_outbound
Per creare un'area di lavoro usando invece un file YAML, usare il parametro
--file
e specificare il file YAML che contiene le impostazioni di configurazione:az ml workspace create --file workspace.yaml --resource-group rg --name ws
L'esempio YAML seguente definisce un'area di lavoro con una rete virtuale gestita:
name: myworkspace location: EastUS managed_network: isolation_mode: allow_internet_outbound
Aggiornare un'area di lavoro esistente:
Avviso
Prima di aggiornare un'area di lavoro esistente per usare una rete virtuale gestita, è necessario eliminare tutte le risorse di calcolo per l'area di lavoro. Sono inclusi l'istanza di calcolo, il cluster di elaborazione e gli endpoint online gestiti.
Nell'esempio seguente viene aggiornata un'area di lavoro esistente. Il
--managed-network allow_internet_outbound
parametro configura una rete virtuale gestita per l'area di lavoro:az ml workspace update --name ws --resource-group rg --managed-network allow_internet_outbound
Per aggiornare un'area di lavoro esistente usando il file YAML, usare il parametro
--file
e specificare il file YAML che contiene le impostazioni di configurazione:az ml workspace update --file workspace.yaml --name ws --resource-group MyGroup
Nell'esempio YAML seguente viene definita una rete virtuale gestita per l'area di lavoro. Viene inoltre illustrato come aggiungere una connessione di un endpoint privato a una risorsa usata dall'area di lavoro; in questo esempio, un endpoint privato per un archivio BLOB:
name: myworkspace managed_network: isolation_mode: allow_internet_outbound outbound_rules: - name: added-perule destination: service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME> spark_enabled: true subresource_target: blob type: private_endpoint
Configurare una rete virtuale gestita per consentire solo il traffico in uscita approvato
Suggerimento
Il provisioning della rete virtuale gestita viene eseguito automaticamente quando si crea una risorsa di calcolo. Quando si consente la creazione automatica, potrebbero essere necessari circa 30 minuti per creare la prima risorsa di calcolo perché esegue anche il provisioning della rete. Se sono state configurate regole in uscita FQDN, la prima regola FQDN aggiunge circa 10 minuti al tempo di provisioning. Per altre informazioni, vedere Effettuare manualmente il provisioning della rete.
Importante
Se si prevede di inviare processi Spark serverless, è necessario avviare manualmente il provisioning. Per altre informazioni, vedere la sezioneconfigurare i processi Spark serverless.
Per configurare una rete virtuale gestita che consenta solo le comunicazioni in uscita approvate, è possibile usare il parametro --managed-network allow_only_approved_outbound
o un file di configurazione YAML contenente le voci seguenti:
managed_network:
isolation_mode: allow_only_approved_outbound
È anche possibile definire regole in uscita per definire le comunicazioni in uscita approvate. È possibile creare una regola in uscita per un tipo di service_tag
, fqdn
e private_endpoint
. La regola seguente illustra l'aggiunta di un endpoint privato a una risorsa BLOB di Azure, un tag del servizio ad Azure Data Factory e un FQDN a pypi.org
:
Importante
- L'aggiunta di traffico in uscita per un tag del servizio o FQDN è valida solo quando la rete virtuale gestita è configurata su
allow_only_approved_outbound
. - Se si aggiungono regole in uscita, Microsoft non può garantire l'esfiltrazione di dati.
Avviso
Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.
managed_network:
isolation_mode: allow_only_approved_outbound
outbound_rules:
- name: added-servicetagrule
destination:
port_ranges: 80, 8080
protocol: TCP
service_tag: DataFactory
type: service_tag
- name: add-fqdnrule
destination: 'pypi.org'
type: fqdn
- name: added-perule
destination:
service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
spark_enabled: true
subresource_target: blob
type: private_endpoint
È possibile configurare una rete virtuale gestita usando i comandi az ml workspace create
o az ml workspace update
:
Creazione di una nuova area di lavoro:
L'esempio seguente usa il parametro
--managed-network allow_only_approved_outbound
per configurare la rete virtuale gestita:az ml workspace create --name ws --resource-group rg --managed-network allow_only_approved_outbound
Il file YAML seguente definisce un'area di lavoro con una rete virtuale gestita:
name: myworkspace location: EastUS managed_network: isolation_mode: allow_only_approved_outbound
Per creare un'area di lavoro usando il file YAML, usare il parametro
--file
:az ml workspace create --file workspace.yaml --resource-group rg --name ws
Aggiornare un'area di lavoro esistente
Avviso
Prima di aggiornare un'area di lavoro esistente per usare una rete virtuale gestita, è necessario eliminare tutte le risorse di calcolo per l'area di lavoro. Sono inclusi l'istanza di calcolo, il cluster di elaborazione e gli endpoint online gestiti.
Nell'esempio seguente viene usato il
--managed-network allow_only_approved_outbound
parametro per configurare la rete virtuale gestita per un'area di lavoro esistente:az ml workspace update --name ws --resource-group rg --managed-network allow_only_approved_outbound
Il file YAML seguente definisce una rete virtuale gestita per l'area di lavoro. Illustra anche come aggiungere una rete in uscita approvata alla rete virtuale gestita. In questo esempio viene aggiunta una regola in uscita per entrambi i tag del servizio:
Avviso
Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.
name: myworkspace_dep managed_network: isolation_mode: allow_only_approved_outbound outbound_rules: - name: added-servicetagrule destination: port_ranges: 80, 8080 protocol: TCP service_tag: DataFactory type: service_tag - name: add-fqdnrule destination: 'pypi.org' type: fqdn - name: added-perule destination: service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME> spark_enabled: true subresource_target: blob type: private_endpoint
Configurare per i processi Spark serverless
Suggerimento
I passaggi descritti in questa sezione sono necessari solo se si prevede di inviare processi Spark serverless. Se non si intende inviare processi Spark serverless, è possibile ignorare questa sezione.
Per abilitare i processi Spark serverless per la rete virtuale gestita, è necessario eseguire le azioni seguenti:
- Configurare una rete virtuale gestita per l'area di lavoro e aggiungere un endpoint privato in uscita per l'account Archiviazione di Azure.
- Dopo aver configurato la rete virtuale gestita, eseguirne il provisioning e contrassegnarlo per consentire i processi Spark.
Configurare un endpoint privato in uscita.
Usare un file YAML per definire la configurazione della rete virtuale gestita e aggiungere un endpoint privato per l'account Archiviazione di Azure. Impostare anche
spark_enabled: true
:Suggerimento
Questo esempio riguarda una rete virtuale gestita configurata usando
isolation_mode: allow_internet_outbound
per consentire il traffico Internet. Se si vuole consentire solo connessioni in uscita approvate, usareisolation_mode: allow_only_approved_outbound
.name: myworkspace managed_network: isolation_mode: allow_internet_outbound outbound_rules: - name: added-perule destination: service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME> spark_enabled: true subresource_target: blob type: private_endpoint
È possibile usare un file di configurazione YAML con il comando
az ml workspace update
specificando il parametro--file
e il nome del file YAML. Ad esempio, il comando seguente aggiorna un'area di lavoro esistente usando un file YAML denominatoworkspace_pe.yml
:az ml workspace update --file workspace_pe.yml --resource_group rg --name ws
Nota
Quando l'opzione Consentire solo connessioni in uscita approvate è abilitata (
isolation_mode: allow_only_approved_outbound
), le dipendenze del pacchetto conda definite nella configurazione della sessione Spark non riusciranno a essere installate. Per risolvere questo problema, caricare un file wheel del pacchetto Python completo senza dipendenze esterne in un account di archiviazione di Azure e creare un endpoint privato in questo account di archiviazione. Usare il percorso del file wheel del pacchetto Python come parametropy_files
nel processo Spark. L'impostazione di una regola in uscita FQDN non consente di ignorare questo problema perché la propagazione delle regole FQDN non è supportata da Spark.Effettuare il provisioning della rete virtuale gestita.
Nota
Se l'area di lavoro dispone dell'accesso alla rete pubblica abilitata, è necessario disabilitarla prima del provisioning della rete virtuale gestita. Se non si disabilita l'accesso alla rete pubblica durante il provisioning della rete virtuale gestita, gli endpoint privati per l'area di lavoro potrebbero non essere creati automaticamente nella rete virtuale gestita. In caso contrario, è necessario configurare manualmente la regola in uscita dell'endpoint privato per l'area di lavoro dopo il provisioning.
L'esempio seguente illustra come effettuare il provisioning di una rete virtuale gestita per i processi Spark serverless usando il
--include-spark
parametro .az ml workspace provision-network -g my_resource_group -n my_workspace_name --include-spark
Effettuare manualmente il provisioning di una rete virtuale gestita
Il provisioning della rete virtuale gestita viene eseguito automaticamente quando si crea un'istanza di calcolo. Quando si fa affidamento sul provisioning automatico, possono essere necessari circa 30 minuti per creare la prima istanza di calcolo perché viene effettuato anche il provisioning della rete. Se sono state configurate regole in uscita FQDN (disponibili solo con la modalità Consentire solo traffico approvato), la prima regola FQDN aggiunge circa 10 minuti al tempo di provisioning. Se si ha un set di regole in uscita di grandi dimensioni da sottoporre a provisioning nella rete gestita, il completamento del provisioning può richiedere più tempo. Un tempo di provisioning più elevato può causare il timeout della creazione della prima istanza di calcolo.
Per ridurre il tempo di attesa ed evitare potenziali errori di timeout, è consigliabile effettuare manualmente il provisioning della rete gestita. Attendere quindi il completamento del provisioning prima di creare un'istanza di calcolo.
In alternativa, è possibile usare il provision_network_now
flag per effettuare il provisioning della rete gestita come parte della creazione dell'area di lavoro. Questo flag è in anteprima.
Nota
Per creare una distribuzione online, è necessario effettuare manualmente il provisioning della rete gestita o creare prima un'istanza di calcolo che ne effettui automaticamente il provisioning.
Nell'esempio seguente viene illustrato come effettuare il provisioning di una rete virtuale gestita durante la creazione dell'area di lavoro. Il --provision-network-now
flag è in anteprima.
az ml workspace create -n myworkspace -g my_resource_group --managed-network AllowInternetOutbound --provision-network-now
Nell'esempio seguente viene illustrato come effettuare manualmente il provisioning di una rete virtuale gestita.
Suggerimento
Se si prevede di inviare processi Spark serverless, aggiungere il parametro --include-spark
.
az ml workspace provision-network -g my_resource_group -n my_workspace_name
Per verificare che il provisioning sia stato completato, usare il comando seguente:
az ml workspace show -n my_workspace_name -g my_resource_group --query managed_network
Configurare la creazione di immagini
Quando registro Azure Container per l'area di lavoro si trova dietro una rete virtuale, non può essere usato per compilare direttamente immagini Docker. Configurare invece l'area di lavoro per usare un cluster di elaborazione o un'istanza di ambiente calcolo per compilare immagini.
Importante
La risorsa di elaborazione usato per compilare le immagini Docker deve essere in grado di accedere ai repository di pacchetti utilizzati per eseguire il training e la distribuzione dei modelli. Se si usa una rete configurata per consentire solo il traffico approvato in uscita, potrebbe essere necessario aggiungere regole che consentano l'accesso ai repository pubblici o usare pacchetti Python privati.
Per aggiornare un'area di lavoro per usare un cluster di elaborazione o un'istanza di ambiente calcolo per compilare immagini Docker, usare il comando az ml workspace update
con il parametro --image-build-compute
:
az ml workspace update --name ws --resource-group rg --image-build-compute mycompute
Gestire le regole in uscita
Per elencare le regole in uscita della rete virtuale gestita per un'area di lavoro, usare il comando seguente:
az ml workspace outbound-rule list --workspace-name ws --resource-group rg
Per visualizzare i dettagli di una regola in uscita della rete virtuale gestita, usare il comando seguente:
az ml workspace outbound-rule show --rule rule-name --workspace-name ws --resource-group rg
Per rimuovere una regola in uscita dalla rete virtuale gestita, usare il comando seguente:
az ml workspace outbound-rule remove --rule rule-name --workspace-name ws --resource-group rg
Elenco delle regole obbligatorie
Endpoint privati:
- Quando la modalità di isolamento per la rete virtuale gestita è
Allow internet outbound
, le regole in uscita dell'endpoint privato vengono create automaticamente come regole necessarie dalla rete virtuale gestita per l'area di lavoro e le risorse associate con accesso alla rete pubblica disabilitata (Insieme di credenziali delle chiavi, account di archiviazione, Registro Contenitori, area di lavoro di Azure Machine Learning). - Quando la modalità di isolamento per la rete virtuale gestita è
Allow only approved outbound
, le regole in uscita dell'endpoint privato vengono create automaticamente come regole necessarie dalla rete virtuale gestita per l'area di lavoro e le risorse associate indipendentemente dalla modalità di accesso alla rete pubblica per tali risorse (Key Vault, Account di archiviazione, Registro Contenitori, area di lavoro di Azure Machine Learning). - Queste regole vengono aggiunte automaticamente alla rete virtuale gestita.
Per l'esecuzione normale di Azure Machine Learning, è necessario un set di tag di servizio necessari in una rete virtuale gestita o personalizzata. Non esistono alternative alla sostituzione di determinati tag di servizio necessari. Di seguito è riportata una tabella di ogni tag di servizio obbligatorio e il relativo scopo all'interno di Azure Machine Learning.
Regola tag del servizio | In ingresso o in uscita | Scopo |
---|---|---|
AzureMachineLearning |
In entrata | Creare, aggiornare ed eliminare l'istanza di ambiente di calcolo o il cluster di elaborazione di Azure Machine Learning. |
AzureMachineLearning |
In uscita | Uso dei servizi Azure Machine Learning. Nei notebook Python IntelliSense utilizza la porta 18881. La creazione, l'aggiornamento e l'eliminazione di un'istanza di ambiente di calcolo di Azure Machine Learning usa la porta 5831. |
AzureActiveDirectory |
In uscita | Autenticazione usando Microsoft Entra ID. |
BatchNodeManagement.region |
In uscita | Comunicazione con il back-end di Azure Batch per istanze di ambiente di calcolo e cluster di elaborazione di Azure Machine Learning. |
AzureResourceManager |
In uscita | Creazione di risorse di Azure con Azure Machine Learning, l’interfaccia della riga di comando di Azure e Azure Machine Learning SDK. |
AzureFrontDoor.FirstParty |
In uscita | Accedere alle immagini Docker fornite da Microsoft. |
MicrosoftContainerRegistry |
In uscita | Accedere alle immagini Docker fornite da Microsoft. Configurare il router di Azure Machine Learning per il servizio Azure Kubernetes. |
AzureMonitor |
In uscita | Usato per registrare il monitoraggio e le metriche in Monitoraggio di Azure. Necessario solo se Monitoraggio di Azure non è stato protetto per l'area di lavoro. Questo valore in uscita viene usato anche per registrare le informazioni per gli eventi imprevisti di supporto. |
VirtualNetwork |
In uscita | Obbligatorio quando gli endpoint privati sono presenti nella rete virtuale o nelle reti virtuali con peering. |
Nota
I tag di servizio come limite di sicurezza ONLY non sono sufficienti. Per l'isolamento a livello di tenant, usare gli endpoint privati quando possibile.
Elenco di regole in uscita specifiche dello scenario
Scenario: accedere ai pacchetti di apprendimento automatico pubblici
Per consentire l'installazione di pacchetti Python per il training e la distribuzione, aggiungere regole FQDN in uscita per consentire il traffico verso i nomi host seguenti:
Avviso
Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.
Nota
Questo non è un elenco completo degli host necessari per tutte le risorse di Python su Internet, ma solo dei più usati. Ad esempio, se è necessario accedere a un repository GitHub o a un altro host, occorre identificare e aggiungere gli host necessari per tale scenario.
Nome host | Scopo |
---|---|
anaconda.com *.anaconda.com |
Usato per installare i pacchetti predefiniti. |
*.anaconda.org |
Usato per ricevere i dati del repository. |
pypi.org |
Usato per elencare le dipendenze dall'indice predefinito, se presenti e se l'indice non viene sovrascritto dalle impostazioni utente. Se l'indice è sovrascritto, è necessario consentire anche *.pythonhosted.org . |
pytorch.org *.pytorch.org |
Usato da alcuni esempi basati su PyTorch. |
*.tensorflow.org |
Usato da alcuni esempi basati su Tensorflow. |
Scenario: usare il Visual Studio Code per desktop o web con l'istanza di ambiente calcolo
Se si prevede di usare Visual Studio Code con Azure Machine Learning, aggiungere regole FQDN in uscita per consentire il traffico agli host seguenti:
Avviso
Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.
*.vscode.dev
vscode.blob.core.windows.net
*.gallerycdn.vsassets.io
raw.githubusercontent.com
*.vscode-unpkg.net
*.vscode-cdn.net
*.vscodeexperiments.azureedge.net
default.exp-tas.com
code.visualstudio.com
update.code.visualstudio.com
*.vo.msecnd.net
marketplace.visualstudio.com
vscode.download.prss.microsoft.com
Scenario: usare endpoint batch o ParallelRunStep
Se si prevede di usare endpoint batch di Azure Machine Learning per la distribuzione o ParallelRunStep, aggiungere regole di endpoint privato in uscita per consentire il traffico verso le risorse secondarie seguenti per l'account di archiviazione predefinito:
queue
table
Scenario: usare il prompt flow con OpenAI di Azure, la sicurezza dei contenuti e Azure AI Search
- Endpoint privato a Servizi di Azure AI
- Endpoint privato in Azure AI Search
Scenario: usare modelli HuggingFace
Se si prevede di usare modelli HuggingFace con Azure Machine Learning, aggiungere regole di FQDN in uscita per consentire il traffico verso gli host seguenti:
Avviso
Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.
docker.io
*.docker.io
*.docker.com
production.cloudflare.docker.com
cdn.auth0.com
cdn-lfs.huggingface.co
Scenario: abilitare l'accesso da indirizzi IP selezionati
Se si vuole abilitare l'accesso da indirizzi IP specifici, usare le azioni seguenti:
Aggiungere una regola di endpoint privato in uscita per consentire il traffico all'area di lavoro di Azure Machine Learning. Questa regola consente alle istanze di calcolo create nella rete virtuale gestita di accedere all'area di lavoro.
Suggerimento
Non è possibile aggiungere questa regola durante la creazione dell'area di lavoro, perché l'area di lavoro non esiste ancora.
Abilitare l'accesso alla rete pubblica all'area di lavoro. Per altre informazioni, vedere l’accesso alla rete pubblica abilitato.
Aggiungere gli indirizzi IP al firewall per Azure Machine Learning. Per altre informazioni, vedere abilitare l'accesso solo dagli intervalli IP.
Nota
Sono supportati solo gli indirizzi IPv4.
Per altre informazioni, vedere Configurare il collegamento privato.
Endpoint privati
Gli endpoint privati sono attualmente supportati per i servizi di Azure seguenti:
- Azure Machine Learning
- Registri di Azure Machine Learning
- Archiviazione di Azure (tutti i tipi di risorse secondarie)
- Registro Azure Container
- Azure Key Vault
- Servizi di Azure AI
- Azure AI Search (in precedenza Ricerca cognitiva)
- Azure SQL Server
- Azure Data Factory
- Azure Cosmos DB (tutti i tipi di risorse secondarie)
- Hub eventi di Azure
- Cache Redis di Azure
- Azure Databricks
- Database di Azure per MariaDB
- Database di Azure per PostgreSQL - Server singolo
- Database di Azure per PostgreSQL - Server flessibile
- Database di Azure per MySQL
- Gestione API di Azure
Quando si crea un endpoint privato, si specifica il tipo di risorsa e la risorsa secondaria a cui si connette l'endpoint. Alcune risorse hanno più tipi e risorse secondarie. Per altre informazioni, vedere che cos'è un endpoint privato.
Quando si crea un endpoint privato per le risorse di dipendenza di Azure Machine Learning, ad esempio Archiviazione di Azure, Registro Azure Container e Azure Key Vault, la risorsa può trovarsi in una sottoscrizione di Azure diversa. Tuttavia, la risorsa deve trovarsi nello stesso tenant dell'area di lavoro di Azure Machine Learning.
Importante
Quando si configurano endpoint privati per una rete virtuale gestita di Azure Machine Learning, gli endpoint privati vengono creati solo quando viene creato il primo calcolo o quando viene forzato il provisioning della rete virtuale gestita. Per altre informazioni sull'uso forzato del provisioning della rete virtuale gestita, vedere Configurare i processi Spark serverless.
Selezionare una versione Firewall di Azure per l'autorizzazione solo in uscita approvata (anteprima)
Viene distribuita una Firewall di Azure se viene creata una regola in uscita FQDN mentre è consentita solo la modalità in uscita approvata. Gli addebiti per il Firewall di Azure sono inclusi nella fatturazione. Per impostazione predefinita, viene creata una versione Standard di AzureFirewall. Facoltativamente, è possibile selezionare per usare una versione di base . È possibile modificare la versione del firewall usata in base alle esigenze. Per capire quale versione è migliore per te, visita Scegliere la versione Firewall di Azure corretta.
Importante
Il firewall non viene creato fino a quando non si aggiunge una regola FQDN in uscita. Per altre informazioni sui prezzi, vedere Prezzi di Firewall di Azure e visualizzare i prezzi per la versione standard.
Usare le schede seguenti per informazioni su come selezionare la versione del firewall per la rete virtuale gestita.
Per configurare la versione del firewall dall'interfaccia della riga di comando, usare un file YAML e specificare .firewall_sku
L'esempio seguente illustra un file YAML che imposta lo SKU del firewall su basic
:
name: test-ws
resource_group: test-rg
location: eastus2
managed_network:
isolation_mode: allow_only_approved_outbound
outbound_rules:
- category: required
destination: 'contoso.com'
name: contosofqdn
type: fqdn
firewall_sku: basic
tags: {}
Prezzi
La funzionalità di rete virtuale gestita di Azure Machine Learning è gratuita. Tuttavia, vengono addebitati i costi per le seguenti risorse usate dalla rete virtuale gestita:
Collegamento privato di Azure: gli endpoint privati usati per proteggere le comunicazioni tra la rete virtuale gestita e le risorse di Azure si basano sul collegamento privato di Azure. Per altre informazioni sui prezzi, vedere Prezzi di Collegamento privato di Azure.
Regole in uscita FQDN: le regole in uscita FQDN vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per impostazione predefinita, viene usata una versione standard di Firewall di Azure. Per informazioni sulla selezione della versione di base, vedere Selezionare una versione Firewall di Azure.
Importante
Il firewall non viene creato fino a quando non si aggiunge una regola FQDN in uscita. Per altre informazioni sui prezzi, vedere Prezzi di Firewall di Azure e visualizzare i prezzi per la versione standard.
Limiti
- Dopo aver abilitato l'isolamento della rete virtuale gestita dell'area di lavoro (consentire internet in uscita o consentire solo l'uscita approvata), non è possibile disabilitarlo.
- La rete virtuale gestita usa la connessione dell'endpoint privato per accedere alle risorse private. Non è possibile avere un endpoint privato e un endpoint di servizio contemporaneamente per le risorse di Azure, ad esempio un account di archiviazione. È consigliabile usare gli endpoint privati in tutti gli scenari.
- La rete virtuale gestita viene eliminata quando l'area di lavoro viene eliminata. Quando si eliminano le risorse di Azure Machine Learning nella sottoscrizione di Azure, disabilitare eventuali blocchi o blocchi delle risorse che impediscono l'eliminazione delle risorse create o creati da Microsoft per la rete virtuale gestita.
- La protezione dell'esfiltrazione di dati viene abilitata automaticamente per la di solo traffico in uscita approvato. Se si aggiungono altre regole in uscita, ad esempio i nomi di dominio completi, Microsoft non può garantire la protezione dall'esfiltrazione di dati a tali destinazioni in uscita.
- La creazione di un cluster di elaborazione in un'area diversa da quella dell'area di lavoro non è supportata quando si usa una rete virtuale gestita.
- Kubernetes e macchine virtuali collegate non sono supportate in una rete virtuale gestita di Azure Machine Learning.
- L'uso delle regole in uscita FQDN aumenta il costo della rete virtuale gestita perché le regole FQDN usano Firewall di Azure. Per altre informazioni, vedere Prezzi.
- Le regole in uscita FQDN supportano solo le porte 80 e 443.
- Se l'istanza di calcolo si trova in una rete gestita ed è configurata per nessun indirizzo IP pubblico, usare il comando
az ml compute connect-ssh
per connettersi tramite SSH. - Quando si usa la rete virtuale gestita, non è possibile distribuire risorse di calcolo all'interno della rete virtuale personalizzata. Le risorse di calcolo possono essere create solo all'interno della rete virtuale gestita.
- L'isolamento della rete gestita non può stabilire una connessione privata dalla rete virtuale gestita alle risorse locali di un utente. Per l'elenco delle connessioni private supportate, vedere Endpoint privati.
- Se la rete gestita è configurata per consentire solo l'approvazione in uscita, non è possibile usare una regola FQDN per accedere agli account Archiviazione di Azure. È invece necessario usare un endpoint privato.
- Assicurarsi di consentire gli endpoint privati gestiti da Microsoft creati per la rete virtuale gestita nei criteri personalizzati.
Migrazione delle risorse di calcolo
Se si dispone di un'area di lavoro esistente e si vuole abilitare la rete virtuale gestita, non è attualmente disponibile alcun percorso di migrazione supportato per le risorse di calcolo gestite esistenti. È necessario eliminare tutte le risorse di calcolo gestite esistenti e ricrearle dopo aver abilitato la rete virtuale gestita. L'elenco seguente contiene le risorse di calcolo che devono essere eliminate e ricreate:
- Cluster di elaborazione
- Istanza di calcolo
- Endpoint online gestiti