Distribuzione con protezione avanzata di rete end-to-end

Questa guida illustra come distribuire uno stack di individuazione completo Microsoft in cui tutto il traffico rimane all'interno della rete virtuale. Alla fine, le API del piano dati dell'area di lavoro, la ricerca nella libreria, i processi nel supercomputer e l'archiviazione BLOB del cliente sono tutti accessibili esclusivamente tramite endpoint privati, senza esposizione pubblica a Internet.

Cosa costruisci

Diagramma che mostra la distribuzione end-to-end di Discovery rinforzata dalla rete con endpoint privati per l'area di lavoro, lo scaffale e il blob storage.

Componente Protezione della rete Percorso di accesso
Piano dati dell'area di lavoro Endpoint privato verso il backbone di Azure {name}.workspace.discovery.azure.com viene risolto in un indirizzo IP privato
Piano dati di librerie Endpoint privato verso il backbone di Azure {name}.bookshelf.discovery.azure.com viene risolto in un indirizzo IP privato
Risorse gestite Perimetro di sicurezza di rete (NSP) applicato + endpoint privati MRG Accessibile solo ai componenti del servizio di individuazione
Supercomputer/Nodepool Rete virtuale inserita Viene eseguito nella subnet della rete virtuale, accede alle risorse gestite tramite endpoint privati
Archiviazione BLOB del cliente Endpoint privato + nessun accesso pubblico + nessuna chiave Accessibile solo tramite PE con controllo degli accessi basato sui ruoli per identità gestite

Prerequisiti

  • Sottoscrizione di Azure con Microsoft.Discovery registrata
  • interfaccia della riga di comando di Azure 2,50+
  • Un'identità gestita assegnata dall'utente (UAMI)
  • Prerequisiti di protezione avanzata della rete completati (vedere Configurare la sicurezza di rete)

Passaggio 1: Pianificare la rete virtuale

Creare una rete virtuale con subnet dedicate per ogni componente:

az network vnet create \
  --resource-group {rg} --name {vnetName} \
  --address-prefixes 10.200.0.0/16 --location {region}

Creare le subnet:

Subnet CIDR Scopo
agent-ws 10.200.1.0/27 Carichi di lavoro dell'agente dell'area di lavoro
workspace-ws 10.200.2.0/24 Servizi dell'area di lavoro
pe-ws 10.200.3.0/27 Endpoint privati (area di lavoro e libreria)
bs-search 10.200.4.0/27 Servizi di ricerca Bookshelf
sc-aks 10.200.6.0/24 Cluster di supercomputer
sc-nodepool 10.200.5.0/24 Pool di nodi del supercomputer
sc-mgmt (facoltativo) 10.200.7.0/28 Supercomputer AKS API server (VNet Integration). È necessario solo se si imposta properties.managementSubnetId sul Supercomputer. /28 è il pavimento. Delega a Microsoft.ContainerService/managedClusters.
pe-storage 10.200.11.0/27 Archiviazione BLOB del cliente PE 
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name agent-ws --address-prefixes 10.200.1.0/27
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name workspace-ws --address-prefixes 10.200.2.0/24
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name pe-ws --address-prefixes 10.200.3.0/27
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name bs-search --address-prefixes 10.200.4.0/27
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name sc-aks --address-prefixes 10.200.6.0/24
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name sc-nodepool --address-prefixes 10.200.5.0/24
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name sc-mgmt --address-prefixes 10.200.7.0/28   # optional — only if using API-Server VNet Integration
az network vnet subnet create --resource-group {rg} --vnet-name {vnetName} --name pe-storage --address-prefixes 10.200.11.0/27

Importante

Tutte le subnet devono trovarsi nella stessa rete virtuale, in modo che le risorse gestite, il supercomputer e l'archiviazione possano comunicare privatamente tramite endpoint inseriti nella rete virtuale e endpoint privati.

Passaggio 2: Creare lo stack di risorse di individuazione

Supercomputer (rete virtuale inserita)

Creare prima il supercomputer in modo che possa essere referenziato nello spazio di lavoro. Il cluster di calcolo viene inserito direttamente nella subnet della rete virtuale. Il traffico del carico di lavoro rimane privato.

Annotazioni

L'impostazione di properties.managementSubnetId sul Supercomputer su una subnet delegata a Microsoft.ContainerService/managedClusters (ad esempio, sc-mgmt nella sezione precedente) consente l'integrazione della VNet del server API di AKS: il kubelet nei nodi raggiunge il server API tramite un ILB privato in tale subnet, quindi il percorso dei dati tra i nodi e il piano di controllo rimane all'interno della rete virtuale. Per ulteriori informazioni, consulta i requisiti relativi all'ID della subnet di gestione.

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/supercomputers/{scName}?api-version=2026-02-01-preview" \
  --body '{
    "location": "{region}",
    "properties": {
      "subnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/sc-aks",
      "identities": {
        "clusterIdentity": { "id": "{uamiResourceId}" },
        "kubeletIdentity": { "id": "{uamiResourceId}" },
        "workloadIdentities": { "{uamiResourceId}": {} }
      }
    }
  }'

Aggiungere un pool di nodi dopo il provisioning del supercomputer:

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/supercomputers/{scName}/nodepools/{nodepoolName}?api-version=2026-02-01-preview" \
  --body '{
    "location": "{region}",
    "properties": { "vmSize": "Standard_D16s_v5", "minNodeCount": 0, "maxNodeCount": 3, "scaleSetPriority": "Regular" }
  }'

Libreria

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/bookshelves/{bsName}?api-version=2026-02-01-preview" \
  --body '{
    "location": "{region}",
    "properties": {
      "searchSubnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/bs-search",
      "privateEndpointSubnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/pe-ws",
      "workloadIdentities": { "{uamiResourceId}": {} }
    }
  }'

Workspace

Creare l'area di lavoro dopo il supercomputer in modo da poter includere supercomputerIds direttamente:

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/workspaces/{wsName}?api-version=2026-02-01-preview" \
  --body '{
    "location": "{region}",
    "properties": {
      "agentSubnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/agent-ws",
      "privateEndpointSubnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/pe-ws",
      "workspaceSubnetId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/workspace-ws",
      "workspaceIdentity": { "id": "{uamiResourceId}" },
      "supercomputerIds": [
        "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/supercomputers/{scName}"
      ]
    }
  }'

Passaggio 3: Creare endpoint privati e configurare DNS

Creare endpoint privati per l'accesso al piano dati dell'area di lavoro, libreria e archiviazione BLOB, quindi configurare le zone DNS private. Per istruzioni dettagliate, tra cui l'interfaccia della riga di comando, PowerShell e il portale, vedere Creare endpoint privati per l'accesso al piano dati.

Passaggio 4: Aggiungere l'archiviazione BLOB del cliente con protezione avanzata dalla rete

Per i carichi di lavoro che devono accedere ai dati dei clienti (dati di training, documenti), creare un account Archiviazione BLOB di Azure completamente bloccato accessibile solo tramite la rete virtuale:

Creare l'account di archiviazione (nessun accesso pubblico, nessuna chiave)

az storage account create --resource-group {rg} \
  --name {storageAccountName} --location {region} \
  --sku Standard_LRS --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --public-network-access Disabled \
  --allow-shared-key-access false \
  --default-action Deny --https-only true

Assegnare RBAC (identità gestita, nessuna chiave)

az role assignment create \
  --assignee-object-id {uamiPrincipalId} \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}"

Creare PE per l'accesso BLOB dalla rete virtuale

az network private-endpoint create \
  --resource-group {rg} --name pe-blob-storage \
  --vnet-name {vnet} --subnet pe-storage \
  --private-connection-resource-id "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}" \
  --group-id blob --connection-name pe-blob-conn

Se usi un account storage con namespace gerarchici abilitati, devi anche creare un endpoint privato per l'endpoint dfs:

az network private-endpoint create \
  --resource-group {rg} --name pe-dfs-storage \
  --vnet-name {vnet} --subnet pe-storage \
  --private-connection-resource-id "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}" \
  --group-id dfs --connection-name pe-dfs-conn

Registrare l'archiviazione con Discovery

Creare una risorsa di container di archiviazione Discovery che faccia riferimento all'archiviazione BLOB:

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Discovery/storageContainers/{scName}?api-version=2026-02-01-preview" \
  --body '{
    "location": "{region}",
    "properties": {
      "storageStore": {
        "kind": "AzureStorageBlob",
        "storageAccountId": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}"
      }
    }
  }'

Suggerimento

Lo stesso UAMI usato per l'area di lavoro può accedere all'archiviazione blob tramite RBAC — non sono necessarie chiavi di archiviazione. Tutti gli accessi passano attraverso l'endpoint privato all'interno della rete virtuale.

Passaggio 5: Verificare la protezione avanzata della rete end-to-end

Dopo avere distribuito tutte le risorse e creato endpoint privati, verificare che il DNS risolva in indirizzi IP privati e che la connettività funzioni dall'interno della rete virtuale. Per i passaggi di verifica dettagliati, vedere Verificare la connettività.

Come fluisce il traffico end-to-end

La tabella seguente illustra come ogni percorso del traffico rimanga all'interno della rete virtuale:

Percorso del traffico origine Meccanismo di rete Internet pubblico?
La tua app per l'API di Workspace App nella rete virtuale o connessa tramite VPN/ExpressRoute/peering VNet Endpoint privato verso il backbone di Azure No
L'app nell'API Bookshelf App nella rete virtuale o connessa tramite VPN/ExpressRoute/peering VNet Endpoint privato verso il backbone di Azure No
L'app su archiviazione Blob App nella rete virtuale o connessa tramite VPN/ExpressRoute/peering VNet Endpoint privato No
Servizio di individuazione per le risorse MRG dell'area di lavoro Servizio di individuazione NSP + endpoint privati nel gruppo di risorse gestite No
Servizio di Discovery per libreria di risorse MRG Servizio di individuazione NSP + endpoint privati nel gruppo di risorse gestite No
Servizio di individuazione per le risorse MRG del supercomputer Servizio di individuazione NSP + endpoint privati nel gruppo di risorse gestite No
Da area di lavoro al BLOB del cliente Carico di lavoro dell'area di lavoro UAMI + RBAC tramite endpoint privato No
Da libreria a BLOB del cliente Carico di lavoro libreria UAMI + RBAC tramite endpoint privato No
Da supercomputer al BLOB del cliente Calcolo inserito nella rete virtuale UAMI + RBAC tramite endpoint privato No

Come le risorse di individuazione accedono ai dati gestiti e ai dati dei clienti

Tutte le risorse di individuazione (area di lavoro, libreria, supercomputer) accedono interamente alle risorse gestite e ai dati dei clienti tramite la rete virtuale:

  1. Il carico di lavoro risolve il FQDN di destinazione tramite DNS privato a un indirizzo IP privato.
  2. Il traffico passa attraverso endpoint privati all'interno della rete virtuale, mai tramite Internet pubblico.
  3. L'autenticazione usa l'identità gestita (UAMI) con il controllo degli accessi in base al ruolo per le risorse del cliente, senza chiavi di archiviazione o segreti condivisi.

Suggerimento

Usando lo stesso UAMI nell'area di lavoro, nella libreria e nel supercomputer, e assegnandolo Storage Blob Data Contributor nell'account di archiviazione, tutti e tre i componenti possono accedere ai dati dei clienti tramite lo stesso percorso dell'endpoint privato con zero chiavi e zero accesso pubblico.

Importante

Dopo aver verificato la connettività, valutare la possibilità di disabilitare l'accesso alla rete pubblica nell'area di lavoro e nella libreria per assicurarsi che venga accettato solo il traffico dell'endpoint privato.

Riepilogo sicurezza

Una volta completata questa distribuzione, avrai a disposizione:

  • Zero endpoint pubblici - tutte le risorse gestite hanno publicNetworkAccess: Disabled oppure SecuredByPerimeter
  • Attraversamento Internetzero: tutto il traffico del piano dati rimane su Azure backbone attraverso collegamento privato
  • Difesa in profondità - NSP (perimetro di rete) + PE (connettività privata) + inserimento di rete virtuale (isolamento delle risorse computazionali) + controllo accessi basato sui ruoli (accesso basato sull'identità)

Passaggi successivi

  • Ultimo aggiornamento: