Condividi tramite


Collegamento privato e integrazione DNS su larga scala

Questo articolo descrive come integrare il collegamento privato di Azure per soluzioni PaaS (Platform as a Service) con zone DNS private di Azure nelle architetture di rete hub-spoke.

Introduzione

Molti clienti creano l'infrastruttura di rete in Azure usando l'architettura di rete hub-spoke, dove:

  • Servizi di rete condivisi, come le appliance virtuali di rete, i gateway ExpressRoute/VPN o i server DNS, vengono distribuiti nella rete virtuale hub.
  • Le reti virtuali spoke usano i servizi condivisi tramite il peering di rete virtuale.

Nelle architetture di rete hub-spoke, i proprietari di applicazioni hanno in genere una sottoscrizione di Azure, che include una rete virtuale (spoke) connessa alla rete virtuale hub . In questa architettura possono distribuire le macchine virtuali e avere connettività privata ad altre reti virtuali o alle reti locali tramite ExpressRoute o VPN.

Un'appliance virtuale di rete centrale, ad esempio Firewall di Azure, offre connettività internet in uscita. Inoltre, tale dispositivo, combinato con un altro servizio, come un proxy DNS di Firewall di Azure, che si trova in o vicino all'hub viene in genere usato per personalizzare l'inoltro DNS.

Molti team applicativi creano le proprie soluzioni usando una combinazione di risorse IaaS e PaaS di Azure. Alcuni servizi PaaS di Azure, ad esempio Istanza gestita di SQL di Azure, possono essere distribuiti nelle reti virtuali dei clienti. Di conseguenza, il traffico rimane privato all'interno della rete di Azure ed è completamente instradabile dall'ambiente locale.

Tuttavia, alcuni servizi PaaS di Azure, ad esempio Archiviazione di Azure o Azure Cosmos DB, non possono essere distribuiti nelle reti virtuali di un cliente e sono accessibili tramite l'endpoint pubblico. In alcuni casi, questa configurazione causa una contesa con i criteri di sicurezza di un cliente. Il traffico aziendale potrebbe non consentire la distribuzione o l'accesso alle risorse aziendali, ad esempio un database SQL, su endpoint pubblici.

Il collegamento privato supporta l'accesso a un elenco di servizi di Azure su endpoint privati, ma richiede la registrazione di tali record di endpoint privati in una zona DNS privata corrispondente.

Questo articolo descrive come i team delle applicazioni possono distribuire i servizi PaaS di Azure nelle sottoscrizioni accessibili solo tramite endpoint privati.

Questo articolo descrive anche in che modo i team delle applicazioni possono garantire l'integrazione automatica dei servizi con zone DNS private. Eseguono l'automazione tramite DNS privato di Azure, che elimina la necessità di creare o eliminare manualmente i record in DNS.

Le zone DNS private sono in genere ospitate centralmente nella stessa sottoscrizione di Azure in cui viene distribuita la rete virtuale hub. Questa pratica di hosting centrale è guidata dalla risoluzione dei nomi DNS cross-premise e da altre esigenze per la risoluzione DNS centrale, ad esempio Windows Server Active Directory. Nella maggior parte dei casi, solo gli amministratori di rete e di identità dispongono delle autorizzazioni per gestire i record DNS nelle zone.

I team delle applicazioni hanno le autorizzazioni per creare una risorsa di Azure nella propria sottoscrizione. Non dispongono di autorizzazioni nella sottoscrizione di connettività di rete centrale, che include la gestione dei record DNS nelle zone DNS private. Questa limitazione di accesso significa che non hanno la possibilità di creare i record DNS necessari quando si distribuiscono i servizi PaaS di Azure con endpoint privati.

Il diagramma seguente illustra un'architettura generale tipica per gli ambienti aziendali con risoluzione DNS centrale e risoluzione dei nomi per le risorse di collegamento privato tramite DNS privato di Azure:

Diagramma di un'architettura di alto livello con risoluzione DNS centrale e risoluzione dei nomi per le risorse di collegamento privato.

Nel diagramma precedente è importante evidenziare quanto riportato di seguito:

  • I server DNS locali hanno configurato inoltri condizionali per ogni zona DNS pubblica per l'endpoint privato, puntando al resolver DNS privato ospitato nella rete virtuale hub.

  • Il resolver privato DNS ospitato nella rete virtuale hub usa il DNS fornito da Azure (168.63.129.16) come server d'inoltro.

  • La rete virtuale hub deve essere collegata ai nomi delle zone DNS private per i servizi di Azure, ad esempio privatelink.blob.core.windows.net, come illustrato nel diagramma.

  • Tutte le reti virtuali di Azure usano il resolver privato DNS ospitato nella rete virtuale hub.

  • Il sistema di risoluzione privato DNS non è autorevole per i domini aziendali del cliente, ad esempio i nomi di dominio di Active Directory, perché è solo un server d'inoltro. Il sistema di risoluzione privato DNS deve avere server d'inoltro endpoint in uscita ai domini aziendali del cliente, che puntano ai server DNS locali (172.16.1.10 e 172.16.1.11) o ai server DNS distribuiti in Azure autorevoli per tali zone.

Annotazioni

È possibile distribuire un resolver privato DNS nella rete virtuale hub insieme al gateway ExpressRoute. Tuttavia, è necessario assicurarsi che la risoluzione dei FQDN pubblici sia consentita e che raggiunga il server DNS di destinazione con una risposta valida tramite una regola del set di regole di inoltro DNS. Alcuni servizi di Azure si basano sulla possibilità di risolvere i nomi DNS pubblici per funzionare. Per ulteriori informazioni, vedere Regole di inoltro DNS.

Mentre il diagramma precedente illustra un'architettura hub-spoke singola, i clienti potrebbero dover estendere il footprint di Azure in più aree per soddisfare i requisiti di resilienza, prossimità o residenza dei dati. In diversi scenari, è necessario accedere alla stessa istanza PaaS abilitata per il collegamento privato tramite più endpoint privati.

Il diagramma seguente illustra un'architettura generale tipica per gli ambienti aziendali con risoluzione DNS centrale distribuita nell'hub (una per ogni area) in cui la risoluzione dei nomi per le risorse di collegamento privato viene eseguita tramite DNS privato di Azure.

Diagramma di un'architettura di alto livello con risoluzione DNS centrale e risoluzione dei nomi per le risorse collegamento privato in più aree.

È consigliabile distribuire più endpoint privati a livello di area associati all'istanza PaaS, uno in ogni area in cui sono presenti i client. Abilitare il collegamento privato e le zone DNS private per ogni area. Quando si usano servizi PaaS con funzionalità di ripristino di emergenza predefinite, ad esempio account di archiviazione con ridondanza geografica e gruppi di failover del database SQL, è necessario disporre di endpoint privati in più aree.

Questo scenario richiede la manutenzione manuale e gli aggiornamenti del set di record DNS di collegamento privato in ogni area perché attualmente non è disponibile alcuna gestione automatica del ciclo di vita per questi elementi.

Per altri casi d'uso, è possibile distribuire un singolo endpoint privato globale, rendendolo accessibile a tutti i client aggiungendo il routing dalle aree pertinenti all'endpoint privato singolo in una singola area.

Per abilitare la risoluzione e quindi la connettività, dalle reti in sede alla privatelink zona DNS privata e agli endpoint privati, configurare appropriatamente la configurazione DNS, ad esempio i server d'inoltro condizionale, nell'infrastruttura DNS.

Due condizioni che devono essere vere per i team delle applicazioni per creare le risorse PaaS di Azure necessarie nella sottoscrizione:

  • I team centrali della piattaforma o della rete centrale devono garantire che i team delle applicazioni possano distribuire e accedere ai servizi PaaS di Azure solo tramite endpoint privati.

  • I team centrali della rete o della piattaforma centrale devono assicurarsi che, quando creano endpoint privati, configurano come gestire i record corrispondenti. Configurare i record corrispondenti in modo che vengano creati automaticamente nella zona DNS privata centralizzata corrispondente al servizio creato.

  • I record DNS devono seguire il ciclo di vita dell'endpoint privato in modo che i record vengano rimossi automaticamente quando viene eliminato l'endpoint privato.

Annotazioni

In base alla risoluzione DNS, se sono necessari FQDNs nelle regole di rete per Firewall di Azure e criteri di Firewall di Azure, abilitare il proxy DNS di Firewall di Azure per usare FQDNs nelle regole di rete. Le reti virtuali spoke devono quindi modificare l'impostazione DNS dal server DNS personalizzato al proxy DNS di Firewall di Azure. Gli FQDN nelle regole di rete consentono di filtrare il traffico in uscita con qualsiasi protocollo TCP o UDP, tra cui NTP, SSH e RDP. Quando si modificano le impostazioni DNS di una rete virtuale spoke, è necessario riavviare tutte le macchine virtuali all'interno di tale rete virtuale.

Le sezioni seguenti descrivono come i team delle applicazioni abilitano queste condizioni usando Criteri di Azure. L'esempio usa Azure Storage come servizio di Azure che i team delle applicazioni devono distribuire. Ma lo stesso principio si applica alla maggior parte dei servizi di Azure che supportano il collegamento privato.

Requisiti di configurazione del team della piattaforma

I requisiti di configurazione del team della piattaforma includono la creazione delle zone DNS private, la configurazione delle definizioni dei criteri, la distribuzione dei criteri e la configurazione delle assegnazioni dei criteri.

Creare zone DNS private

Creare zone DNS private nella sottoscrizione di connettività centrale per i servizi di collegamento privato supportati. Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.

In questo caso, l'account di archiviazione con blob è l'esempio. Si traduce nella creazione di una privatelink.blob.core.windows.net zona DNS privata nella sottoscrizione di connettività.

Screenshot che mostra la zona DNS privata nella sottoscrizione di connettività.

Creare definizioni di criteri

Oltre alle zone DNS private, è anche necessario creare un set di definizioni personalizzate di Criteri di Azure. Queste definizioni applicano l'uso di endpoint privati e automatizzano la creazione del record DNS nella zona DNS creata:

  1. Endpoint Deny pubblico per i criteri dei servizi PaaS.

    Questo criterio impedisce agli utenti di creare servizi PaaS di Azure con endpoint pubblici.

    Una schermata che mostra l'opzione endpoint pubblico per tutte le reti selezionata.

    Gli utenti ricevono un messaggio di errore se non selezionano l'endpoint privato quando creano la risorsa.

    Screenshot che mostra il messaggio di errore risultante dalla selezione di un endpoint pubblico.

    Screenshot che mostra i dettagli completi dell'errore dalla selezione di un endpoint pubblico.

    La regola esatta dei criteri potrebbe variare tra i servizi PaaS. Per gli account di archiviazione di Azure, la proprietà networkAcls.defaultAction definisce se le richieste provenienti da reti pubbliche sono consentite o meno. In questo caso, impostare una condizione per negare la creazione del tipo di risorsa Microsoft.Storage/storageAccounts se la proprietà networkAcls.defaultAction non è specificata. La definizione di criteri seguente illustra il comportamento:

    {
      "mode": "All",
      "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Storage/storageAccounts"
            },
            {
              "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
              "notEquals": "Deny"
            }
          ]
        },
        "then": {
          "effect": "Deny"
        }
      }
    }
    
  2. Deny possibilità di creare una zona DNS privata con la politica di prefisso privatelink.

    Usare un'architettura DNS centralizzata con un server d'inoltro condizionale e zone DNS private ospitate nelle sottoscrizioni gestite dal team della piattaforma. È necessario impedire ai proprietari dei team applicativi di creare zone DNS private di Private Link e collegare i servizi alle loro sottoscrizioni.

    Assicurarsi che quando il team dell'applicazione crea un endpoint privato, l'opzione su Integrate with private DNS zone è impostata su No nel portale di Azure.

    Screenshot che mostra l'opzione Integrazione con zona DNS privata impostata su no nel portale di Azure.

    Se si seleziona Yes, il criterio di Azure ti impedisce di creare l'endpoint privato. Nella definizione dei criteri viene negata la possibilità di creare il tipo di risorsa Microsoft.Network/privateDnsZones se la zona ha il privatelink prefisso. La seguente definizione di criterio mostra il prefisso privatelink:

    {
      "description": "This policy restricts creation of private DNS zones with the `privatelink` prefix",
      "displayName": "Deny-PrivateDNSZone-PrivateLink",
      "mode": "All",
      "parameters": null,
      "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Network/privateDnsZones"
            },
            {
              "field": "name",
              "contains": "privatelink."
            }
          ]
        },
        "then": {
          "effect": "Deny"
        }
      }
    }
    
  3. DeployIfNotExists politica per creare automaticamente il record DNS richiesto nella zona DNS privata centrale.

    I seguenti esempi di criteri mostrano due approcci per identificare quale privateDNSZoneGroup viene creato su un endpoint privato.

    Il primo criterio si basa sul groupId mentre il secondo criterio usa sia privateLinkServiceId che groupID. Usare il secondo criterio quando groupId si verifica un conflitto con un'altra risorsa.

    Per un elenco delle risorse di collegamento privato, vedere la colonna delle sottorisorse in groupId.

Suggerimento

Le definizioni incorporate di Azure Policy vengono aggiunte, eliminate e aggiornate costantemente. È consigliabile usare criteri predefiniti anziché gestire i propri criteri, se disponibili. Usare AzPolicyAdvertizer per trovare i criteri predefiniti esistenti con il nome seguente di 'xxx ... per usare zone DNS private'. Inoltre, Le zone di destinazione di Azure (ALZ) hanno un'iniziativa di criteri, Configurare i servizi PaaS di Azure per l'uso delle zone DNS private, che contiene criteri predefiniti che vengono aggiornati periodicamente. Se un criterio integrato non è disponibile per la tua situazione, considera di creare un'idea sul sito di feedback azure-policyAzure Governance Community seguendo il processo delle proposte di criteri integrati sul repository GitHub di Azure Policy.

Criterio "DeployIfNotExists" soltanto per il "groupId"

Questo criterio viene attivato se si crea una risorsa endpoint privato che ha un groupId specifico per il servizio. groupId è l'ID del gruppo ottenuto dalla risorsa remota (servizio) a cui deve connettersi questo endpoint privato. Attiva quindi una distribuzione di privateDNSZoneGroup all'interno dell'endpoint privato, che associa l'endpoint privato alla zona DNS privata. Nell'esempio, il groupId per i BLOB di Archiviazione di Azure è blob. Per altre informazioni su groupId per altri servizi di Azure, vedere la colonna Subresource nella configurazione DNS dell'endpoint privato di Azure. Quando il criterio trova il groupId nell'endpoint privato, distribuisce un privateDNSZoneGroup all'interno dell'endpoint privato e lo collega all'ID risorsa della zona DNS privata specificato come parametro. Nell'esempio l'ID risorsa della zona DNS privata è:

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net

L'esempio di codice seguente illustra la definizione dei criteri:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/privateEndpoints"
        },
        {
          "count": {
            "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
            "where": {
              "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
              "equals": "blob"
            }
          },
          "greaterOrEquals": 1
        }
      ]
    },
    "then": {
      "effect": "deployIfNotExists",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "storageBlob-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
    "privateDnsZoneId": {
      "type": "String",
      "metadata": {
        "displayName": "privateDnsZoneId",
        "strongType": "Microsoft.Network/privateDnsZones"
      }
    }
  }
}

Criteri DeployIfNotExists per _groupId_ e _privateLinkServiceId_

Questo criterio viene attivato se si crea una risorsa di endpoint privato specifica del servizio con groupId e privateLinkServiceId. groupId è l'ID del gruppo ottenuto dalla risorsa remota (servizio) a cui deve connettersi questo endpoint privato. privateLinkServiceId è l'ID risorsa della risorsa remota (servizio) a cui deve connettersi questo endpoint privato. Quindi, attiva una distribuzione di privateDNSZoneGroup all'interno dell'endpoint privato, che associa l'endpoint privato alla zona DNS privata.

Nell'esempio, il groupId per Azure Cosmos DB (SQL) è SQL e il privateLinkServiceId deve contenere Microsoft.DocumentDb/databaseAccounts. Per altre informazioni su groupId e privateLinkServiceId per altri servizi di Azure, vedere la colonna Subresource nella configurazione DNS dell'endpoint privato di Azure. Quando il criterio trova groupId e privateLinkServiceId nell'endpoint privato, distribuisce un privateDNSZoneGroup nell'endpoint privato. Ed è collegato all'ID risorsa della zona DNS privato specificato come parametro. La definizione di criterio seguente mostra l'ID risorsa della zona DNS privata.

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com

L'esempio di codice seguente illustra la definizione dei criteri:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
     "allOf": [
       {
         "field": "type",
         "equals": "Microsoft.Network/privateEndpoints"
       },
       {
         "count": {
           "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
           "where": {
             "allOf": [
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
                 "contains": "Microsoft.DocumentDb/databaseAccounts"
               },
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                 "equals": "[parameters('privateEndpointGroupId')]"
               }
             ]
           }
         },
         "greaterOrEquals": 1
       }
     ]
   },
    "then": {
      "effect": "[parameters('effect')]",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "cosmosDB-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
     "privateDnsZoneId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Dns Zone Id",
         "description": "The private DNS zone to deploy in a new private DNS zone group and link to the private endpoint",
         "strongType": "Microsoft.Network/privateDnsZones"
       }
     },
     "privateEndpointGroupId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Endpoint Group Id",
         "description": "A group Id for the private endpoint"
       }
     },
     "effect": {
       "type": "String",
       "metadata": {
         "displayName": "Effect",
         "description": "Enable or disable the execution of the policy"
       },
       "allowedValues": [
         "DeployIfNotExists",
         "Disabled"
       ],
       "defaultValue": "DeployIfNotExists"
     }
  }
}

Assegnazioni di criteri

Dopo la distribuzione delle definizioni dei criteri, assegnare i criteri nell'ambito desiderato nella gerarchia dei gruppi di gestione. Assicurarsi che le assegnazioni dei criteri siano destinate alle sottoscrizioni di Azure usate dai team dell'applicazione per distribuire i servizi PaaS con accesso esclusivo agli endpoint privati.

Importante

Oltre ad assegnare il roleDefinition definito nei criteri, assegnare il ruolo Collaboratore zona DNS privata all'identità gestita creata dall'assegnazione dei criteriDeployIfNotExists. Questo ruolo deve essere assegnato nella sottoscrizione e nel gruppo di risorse in cui sono ospitate le zone DNS private. L'identità gestita crea e gestisce il record DNS dell'endpoint privato nella zona DNS privata. Questa configurazione è necessaria perché l'endpoint privato si trova nella sottoscrizione di Azure del proprietario dell'applicazione, mentre la zona DNS privata si trova in una sottoscrizione diversa, ad esempio una sottoscrizione di connettività centrale.

Dopo che il team della piattaforma ha completato la configurazione:

  • Le sottoscrizioni di Azure dei team delle applicazioni sono pronte per consentire al team di creare servizi PaaS di Azure con accesso esclusivo agli endpoint privati.

  • Il team deve assicurarsi che i record DNS per gli endpoint privati vengano registrati automaticamente nelle zone DNS private corrispondenti e che i record DNS vengano rimossi dopo l'eliminazione di un endpoint privato.

Il proprietario dell'applicazione distribuisce un servizio PaaS di Azure

Dopo che il team della piattaforma distribuisce i componenti dell'infrastruttura della piattaforma (zone e criteri DNS privati), il proprietario dell'applicazione esegue i passaggi seguenti quando tentano di distribuire un servizio PaaS di Azure nella sottoscrizione di Azure. Questi passaggi sono uguali se eseguono le attività tramite il portale di Azure o altri client, ad esempio PowerShell o l'interfaccia della riga di comando, perché i criteri di Azure regolano le sottoscrizioni.

  1. Creare un account di archiviazione tramite il portale di Azure. Nella scheda Informazioni di base scegliere le impostazioni desiderate, specificare un nome per l'account di archiviazione e selezionare Avanti.

    Screenshot che mostra la scheda Informazioni di base e le opzioni per la creazione dell'account di archiviazione nel portale di Azure.

  2. Nella scheda Rete selezionare Endpoint privato. Se si seleziona un'opzione diversa da Endpoint privato, il portale di Azure non consente di creare l'account di archiviazione nella sezione Rivedi e crea della distribuzione guidata. Il criterio impedisce la creazione di questo servizio se l'endpoint pubblico è abilitato.

    Screenshot che mostra la scheda Rete e l'opzione Endpoint privati.

  3. È possibile creare l'endpoint privato ora o dopo aver creato l'account di archiviazione. Questo esempio mostra la creazione dell'endpoint privato dopo la creazione dell'account di archiviazione. Selezionare Rivedi e crea per completare il passaggio.

  4. Dopo aver creato l'account di archiviazione, creare un endpoint privato tramite il portale di Azure.

    Screenshot che mostra le impostazioni degli endpoint privati.

  5. Nella sezione Risorsa individuare l'account di archiviazione creato nel passaggio precedente. In Sottorisorsa di destinazione selezionare BLOB e quindi selezionare Avanti.

    Screenshot che mostra la scheda Risorse per la selezione della sottorisorsa di destinazione.

  6. Nella sezione Configurazione , dopo aver selezionato la rete virtuale e la subnet, assicurarsi che l'integrazione con la zona DNS privata sia impostata su No. In caso contrario, il portale di Azure impedisce di creare l'endpoint privato. I criteri di Azure non consentono di creare una zona DNS privata con il prefisso privatelink.

    Screenshot che mostra la scheda Configurazione per l'impostazione dell'opzione integrazione con zona DNS privata su no.

  7. Selezionare Rivedi e crea e quindi crea per distribuire l'endpoint privato.

  8. Dopo alcuni minuti, la DeployIfNotExists politica viene attivata. La distribuzione successiva dnsZoneGroup aggiunge quindi i record DNS necessari per l'endpoint privato nella zona DNS gestita centralmente.

  9. Dopo aver creato l'endpoint privato, selezionarlo ed esaminarne il nome di dominio completo e l'INDIRIZZO IP privato:

    Screenshot che mostra dove esaminare l'endpoint privato, il nome di dominio completo e l'indirizzo IP privato.

  10. Controllare il log attività per il gruppo di risorse in cui è stato creato l'endpoint privato. In alternativa, è possibile controllare il log attività dell'endpoint privato stesso. Dopo alcuni minuti, viene eseguita un'azione DeployIfNotExist relativa alle politiche che configura il gruppo di zone DNS sul punto finale privato.

    Una screenshot che mostra il log delle attività del gruppo di risorse e dell'endpoint privato.

  11. Se il team di rete centrale passa alla privatelink.blob.core.windows.net zona DNS privata, verifica che il record DNS sia presente per l'endpoint privato creato e che il nome e l'indirizzo IP corrispondano ai valori all'interno dell'endpoint privato.

    Screenshot che mostra la zona DNS privata e la posizione in cui verificare che il record DNS esista.

A questo punto, i team delle applicazioni possono usare l'account di archiviazione tramite un endpoint privato da qualsiasi rete virtuale nell'ambiente di rete hub-and-spoke e da ambienti locali. Il record DNS è stato registrato automaticamente nella zona DNS privata.

Se un proprietario dell'applicazione elimina l'endpoint privato, i record corrispondenti nella zona DNS privata vengono rimossi automaticamente.

Importante

È comunque possibile creare endpoint privati nell'infrastruttura come strumenti di codice. Tuttavia, se si usa l'approccio DeployIfNotExists ai criteri in questo articolo, non dovresti integrare il DNS nel codice. Le DeployIfNotExists politiche che hanno il controllo degli accessi in base al ruolo richiesto per le zone DNS private gestiscono l'integrazione DNS.

Passaggi successivi