Private Link en DNS-integratie op schaal

Artikel
2025-04-08

In dit artikel wordt beschreven hoe u Azure Private Link integreert voor PaaS-oplossingen (Platform as a Service) met Azure Private DNS-zones in hub-and-spoke-netwerkarchitecturen.

Introductie

Veel klanten bouwen hun netwerkinfrastructuur in Azure met behulp van de hub-and-spoke-netwerkarchitectuur, waarbij:

Gedeelde netwerkservices, zoals virtuele netwerkapparaten (NVA's), ExpressRoute/VPN-gateways of DNS-servers, worden geïmplementeerd in het virtuele hubnetwerk.
Virtuele spoke-netwerken maken gebruik van de gedeelde diensten via virtuele netwerkpeering.

In hub-and-spoke-netwerkarchitecturen hebben toepassingseigenaren doorgaans een Azure-abonnement, waaronder een virtueel netwerk (een spoke) dat is verbonden met het virtuele hubnetwerk . In deze architectuur kunnen ze hun virtuele machines implementeren en privéconnectiviteit hebben met andere virtuele netwerken of naar on-premises netwerken via ExpressRoute of VPN.

Een centrale NVA, zoals Azure Firewall, biedt uitgaande internetconnectiviteit. Daarnaast wordt dat apparaat, gecombineerd met een andere service, zoals een Azure Firewall DNS-proxy, die zich in of in de buurt van de hub bevindt, doorgaans gebruikt om DNS-doorsturen aan te passen.

Veel toepassingsteams bouwen hun oplossingen met behulp van een combinatie van Azure IaaS- en PaaS-resources. Sommige Azure PaaS-services, zoals Azure SQL Managed Instance, kunnen worden geïmplementeerd in virtuele netwerken van klanten. Hierdoor blijft verkeer privé binnen het Azure-netwerk en is het volledig routeerbaar vanaf on-premises.

Sommige Azure PaaS-services, zoals Azure Storage of Azure Cosmos DB, kunnen echter niet worden geïmplementeerd in de virtuele netwerken van een klant en zijn toegankelijk via hun openbare eindpunt. In sommige gevallen veroorzaakt deze configuratie een conflict met het beveiligingsbeleid van een klant. Bedrijfsverkeer staat de implementatie of toegang van bedrijfsbronnen, zoals een SQL-database, mogelijk niet toe via openbare eindpunten.

Private Link ondersteunt toegang tot een lijst met Azure-services via privé-eindpunten, maar hiervoor moet u deze privé-eindpuntrecords registreren in een bijbehorende privé-DNS-zone.

In dit artikel wordt beschreven hoe toepassingsteams Azure PaaS-services kunnen implementeren in hun abonnementen die alleen toegankelijk zijn via privé-eindpunten.

In dit artikel wordt ook beschreven hoe toepassingsteams ervoor kunnen zorgen dat services automatisch worden geïntegreerd met privé-DNS-zones. Ze doen de automatisering via Azure Private DNS, waardoor het niet meer nodig is om records handmatig aan te maken of te verwijderen in DNS.

Private Link- en DNS-integratie in hub-and-spoke-netwerkarchitecturen

Privé-DNS-zones worden doorgaans centraal gehost in hetzelfde Azure-abonnement waar het virtuele hubnetwerk wordt geïmplementeerd. Deze centrale hostingpraktijk wordt aangestuurd door cross-premises DNS-naamomzetting en andere behoeften voor centrale DNS-omzetting, zoals Windows Server Active Directory. In de meeste gevallen hebben alleen netwerk- en identiteitsbeheerders machtigingen voor het beheren van DNS-records in de zones.

Applicatieteams hebben machtigingen om in hun eigen abonnement een Azure-resource te maken. Ze hebben geen machtigingen in het abonnement voor centrale netwerkconnectiviteit, waaronder het beheren van DNS-records in de privé-DNS-zones. Deze toegangsbeperking betekent dat ze niet de mogelijkheid hebben om de DNS-records te maken die zijn vereist bij het implementeren van Azure PaaS-services met privé-eindpunten.

In het volgende diagram ziet u een typische architectuur op hoog niveau voor bedrijfsomgevingen met centrale DNS-omzetting en naamomzetting voor Private Link-resources via Azure Private DNS:

In het vorige diagram is het belangrijk om te benadrukken dat:

Op de on-premises DNS-servers zijn voorwaardelijke doorstuurservers geconfigureerd voor elke privé-eindpunt openbare DNS-zone, die verwijst naar de DNS-privéresolver die gehost wordt in het virtuele hubnetwerk.
De dns-privé-resolver die wordt gehost in het virtuele hubnetwerk maakt gebruik van de door Azure geleverde DNS (168.63.129.16) als doorstuurserver.
Het virtuele hubnetwerk moet worden gekoppeld aan de privé-DNS-zonenamen voor Azure-services, zoals privatelink.blob.core.windows.networdt weergegeven in het diagram.
Alle virtuele Azure-netwerken maken gebruik van de dns-privé-resolver die wordt gehost in het virtuele hubnetwerk.
De dns-privé-resolver is niet gezaghebbend voor de bedrijfsdomeinen van de klant, zoals Active Directory-domeinnamen, omdat het alleen een doorstuurserver is. De privé-DNS-resolver moet uitgaande eindpuntdoorstuurders hebben naar de bedrijfsdomeinen van de klant, die verwijzen naar de on-premises DNS-servers (172.16.1.10 en 172.16.1.11) of naar DNS-servers die in Azure zijn geïmplementeerd en gezaghebbend zijn voor dergelijke zones.

Opmerking

U kunt een privé-DNS-resolver implementeren in uw virtuele hubnetwerk naast uw ExpressRoute-gateway. U moet er echter voor zorgen dat de resolutie van openbare FQDN's is toegestaan en met een geldige respons via een regelsysteem voor DNS-doorsturen naar de doel-DNS-server reageert. Sommige Azure-services zijn afhankelijk van de mogelijkheid om openbare DNS-namen op te lossen om te functioneren. Zie regelsetregels voor dns-doorstuurregelsvoor meer informatie.

Hoewel in het vorige diagram één hub-and-spoke-architectuur wordt weergegeven, moeten klanten mogelijk hun Azure-footprint uitbreiden in meerdere regio's om te voldoen aan vereisten voor tolerantie, nabijheid of gegevenslocatie. In verschillende scenario's moet hetzelfde PaaS-exemplaar met Private Link-functionaliteit worden geopend via meerdere privé-eindpunten.

In het volgende diagram ziet u een typische architectuur op hoog niveau voor bedrijfsomgevingen waarop centrale DNS-omzetting is geïmplementeerd in de hub (één voor elke regio) waar naamomzetting voor Private Link-resources wordt uitgevoerd via Privé-DNS van Azure.

U moet meerdere regionale privé-eindpunten implementeren die zijn gekoppeld aan het PaaS-exemplaar, één in elke regio waar clients bestaan. Schakel Private Link- en Privé-DNS-zones in voor elke regio. Wanneer u werkt met PaaS-services met ingebouwde mogelijkheden voor herstel na noodgevallen, zoals geografisch redundante opslagaccounts en failovergroepen voor SQL-databases, moet u privé-eindpunten in meerdere regio's hebben.

Dit scenario vereist handmatig onderhoud en updates van de Private Link DNS-recordset in elke regio, omdat er momenteel geen geautomatiseerd levenscyclusbeheer voor deze is.

Voor andere gebruiksscenario's kan één globaal privé-eindpunt worden geïmplementeerd, waardoor het toegankelijk is voor alle clients door routering vanuit de relevante regio's toe te voegen aan het individuele privé-eindpunt in één regio.

Als u resolutie wilt inschakelen en daarmee connectiviteit van on-premises netwerken naar de privatelink privé-DNS-zone en privé-eindpunten, configureer dan de juiste DNS-instellingen, zoals voorwaardelijke doorstuurservers, in de DNS-infrastructuur.

Twee voorwaarden die waar moeten zijn voor toepassingsteams om eventuele vereiste Azure PaaS-resources in hun abonnement te maken:

Centrale netwerken of centrale platformteams moeten ervoor zorgen dat toepassingsteams alleen Azure PaaS-services kunnen implementeren en openen via privé-eindpunten.
Centrale netwerken of centrale platformteams moeten ervoor zorgen dat wanneer ze privé-eindpunten maken, ze instellen hoe de bijbehorende records moeten worden verwerkt. Stel de bijbehorende records zo in dat ze automatisch worden gemaakt in de gecentraliseerde privé-DNS-zone die overeenkomt met de service die wordt gemaakt.
DNS-records moeten de levenscyclus van het privé-eindpunt volgen, zodat de records automatisch worden verwijderd wanneer het privé-eindpunt wordt verwijderd.

Opmerking

Op basis van DNS-resolutie, als u FQDN's in netwerkregels nodig hebt voor Azure Firewall en Azure Firewall-beleid, schakelt u de Azure Firewall DNS-proxy in om FQDN's te gebruiken in uw netwerkregels. Vervolgens moeten de virtuele spoke-netwerken hun DNS-instelling wijzigen van de aangepaste DNS-server in de Azure Firewall DNS-proxy. Met FQDN's in netwerkregels kunt u uitgaand verkeer filteren met elk TCP- of UDP-protocol, waaronder NTP, SSH en RDP. Wanneer u de DNS-instellingen van een virtueel spoke-netwerk wijzigt, moet u alle VM's binnen dat virtuele netwerk opnieuw opstarten.

In de volgende secties wordt beschreven hoe toepassingsteams deze voorwaarden inschakelen met behulp van Azure Policy. In het voorbeeld wordt Azure Storage gebruikt als de Azure-service die toepassingsteams moeten implementeren. Maar hetzelfde principe is van toepassing op de meeste Azure-services die Private Link ondersteunen.

Configuratievereisten van het platformteam

De configuratievereisten voor het platformteam omvatten het maken van de privé-DNS-zones, het instellen van beleidsdefinities, het implementeren van beleid en het instellen van de beleidstoewijzingen.

Privé-DNS-zones maken

Maak privé-DNS-zones in het centrale connectiviteitsabonnement voor de ondersteunde Private Link-services. Zie DNS-configuratie voor privé-eindpunten in Azure voor meer informatie.

In dit geval is opslagaccount met blob het voorbeeld. Het vertaalt zich in het maken van een privatelink.blob.core.windows.net privé-DNS-zone in het connectiviteitsabonnement.

Een schermopname van de privé-DNS-zone in het connectiviteitsabonnement.

Beleidsdefinities maken

Naast de privé-DNS-zones moet u ook een set aangepaste Azure Policy-definities maken. Deze definities dwingen het gebruik van privé-eindpunten af en automatiseren het maken van de DNS-record in de DNS-zone die u maakt:

Het Deny openbare eindpunt voor PaaS-servicesbeleid.

Dit beleid voorkomt dat gebruikers Azure PaaS-services maken met openbare eindpunten.

Gebruikers krijgen een foutbericht als ze het privé-eindpunt niet selecteren wanneer ze de resource maken.

De exacte beleidsregel kan verschillen tussen PaaS-services. Voor Azure Storage-accounts bepaalt de eigenschap networkAcls.defaultAction of aanvragen van openbare netwerken zijn toegestaan of niet. In dit geval stelt u een voorwaarde in om het maken van het resourcetype Microsoft.Storage/storageAccounts te weigeren als de eigenschap networkAcls.defaultAction niet Denyis. De volgende beleidsdefinitie toont het gedrag:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny de mogelijkheid om een privé-DNS-zone te maken met het privatelink voorvoegselbeleid.

Gebruik een gecentraliseerde DNS-architectuur met een voorwaardelijke doorstuurserver en privé-DNS-zones die worden gehost in de abonnementen die worden beheerd door het platformteam. Het is noodzakelijk om te voorkomen dat de eigenaren van toepassingsteams hun eigen privé-DNS-zones van Private Link maken en services koppelen aan hun abonnementen.

Zorg ervoor dat wanneer uw toepassingsteam een privé-eindpunt maakt, de optie Integrate with private DNS zone is ingesteld op No in het Azure-portaal.

Als u selecteert Yes, voorkomt Azure Policy dat u het privé-eindpunt maakt. In de beleidsdefinitie wordt de mogelijkheid geweigerd om het resourcetype Microsoft.Network/privateDnsZones te maken als de zone het privatelink voorvoegsel heeft. De volgende beleidsdefinitie toont het privatelink voorvoegsel:
```
{
  "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"
    }
  }
}
```
DeployIfNotExists beleid voor het automatisch maken van de vereiste DNS-record in de centrale privé-DNS-zone.

In de volgende beleidsvoorbeelden ziet u twee benaderingen voor het identificeren van welke privateDNSZoneGroup is gemaakt op een privé-eindpunt.

Het eerste beleid is afhankelijk van de groupId, terwijl het tweede beleid zowel privateLinkServiceId als groupID gebruikt. Gebruik het tweede beleid wanneer groupId er conflicten optreden of botst met een andere resource.

De SQL wordt bijvoorbeeld groupId gebruikt voor zowel Azure Cosmos DB als Azure Synapse Analytics. Als beide resourcetypen worden ingezet en het eerste beleid is toegewezen om de privateDNSZoneGroup vermelding voor het privé-eindpunt te creëren, wordt het gemaakt en gekoppeld aan de verkeerde privé-DNS-zone, ofwel van Azure Cosmos DB of Azure Synapse Analytics. Vervolgens kan het schakelen tussen elk van de zones vanwege het conflict groupId dat het eerste beleid zoekt in de beleidsregel.

Zie de kolom subresources in Wat is een privé-eindpunt? voor een lijst met de groupId voor Private Link-resources.

Hint

Ingebouwde Azure Policy-definities worden voortdurend toegevoegd, verwijderd en bijgewerkt. U moet ingebouwde beleidsregels gebruiken in plaats van uw eigen beleid te beheren, indien beschikbaar. Gebruik azPolicyAdvertizer om bestaande ingebouwde beleidsregels te vinden met de volgende naam 'xxx ... om privé-DNS-zones te gebruiken'. Daarnaast heeft Azure Landing Zones (ALZ) een beleidsinitiatief, Azure PaaS-services configureren voor het gebruik van privé-DNS-zones, die ingebouwde beleidsregels bevatten die periodiek worden bijgewerkt. Als een ingebouwd beleid niet beschikbaar is voor uw situatie, kunt u overwegen om een idee te maken op de Azure Governance-community van de azure-policy feedbacksite door het ingebouwde proces voor beleidsvoorstellen in de GitHub-opslagplaats van Azure Policy te volgen.

DeployIfNotExists-beleid alleen voor groupId

Dit beleid wordt geactiveerd als u een privé-eindpuntresource maakt die een servicespecifiek groupIdheeft. Dit groupId is de id van de groep die is verkregen van de externe resource (service) waarmee dit privé-eindpunt verbinding moet maken. Vervolgens wordt een implementatie van een privateDNSZoneGroup binnen het privé-eindpunt geactiveerd, waarmee het privé-eindpunt wordt gekoppeld aan de privé-DNS-zone. In het voorbeeld is het groupId voor Azure Storage-blobs blob. Zie de Subresource kolom in de DNS-configuratie van het privé-eindpunt van Azure voor meer informatie over de groupId met betrekking tot andere Azure-services. Wanneer het beleid het groupId in het privé-eindpunt vindt, wordt er een privateDNSZoneGroup binnen het privé-eindpunt geïmplementeerd en wordt het gekoppeld aan de resource-id van de privé-DNS-zone die is opgegeven als de parameter. In het voorbeeld is de resource-id van de privé-DNS-zone:

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

In het volgende codevoorbeeld ziet u de beleidsdefinitie:

{
  "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"
      }
    }
  }
}

DeployIfNotExists-beleid voor groupId en privateLinkServiceId

Dit beleid wordt geactiveerd als u een privé-eindpuntresource maakt met een servicespecifiek groupId en privateLinkServiceId. Dit groupId is de id van de groep die is verkregen van de externe resource (service) waarmee dit privé-eindpunt verbinding moet maken. De privateLinkServiceId is de resource-id van de externe resource (service) waarmee dit privé-eindpunt verbinding moet maken. Activeer vervolgens een implementatie van een privateDNSZoneGroup binnen het privé-eindpunt, dat het privé-eindpunt koppelt aan de privé-DNS-zone.

In het voorbeeld is het groupId voor Azure Cosmos DB (SQL) en de privateLinkServiceId must bevattenMicrosoft.DocumentDb/databaseAccounts.SQL Zie de kolom Subresource in de DNS-configuratie van het privé-eindpunt van Azure voor meer informatie over groupId en privateLinkServiceId voor andere Azure-services. Wanneer het beleid groupId en privateLinkServiceId in het privé-eindpunt vindt, implementeert het een privateDNSZoneGroup binnen het privé-eindpunt. En deze is gekoppeld aan de resource-id van de privé-DNS-zone die is opgegeven als de parameter. De volgende beleidsdefinitie toont de resource-id van de privé-DNS-zone:

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

In het volgende codevoorbeeld ziet u de beleidsdefinitie:

{
  "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"
     }
  }
}

Beleidstoewijzingen

Nadat beleidsdefinities zijn geïmplementeerd, wijst u het beleid toe aan het gewenste bereik in uw beheergroephiërarchie. Zorg ervoor dat de beleidstoewijzingen zijn gericht op de Azure-abonnementen die de toepassingsteams gebruiken om PaaS-services te implementeren met uitsluitend toegang tot privé-eindpunten.

Belangrijk

Naast het toewijzen van de roldefinitie die is gedefinieerd in het beleid, wijst u de Privé-DNS-zone Inzender rol toe aan de beheerde identiteit die is gemaakt door de toewijzing van het beleid. Deze rol moet worden toegewezen in het abonnement en de resourcegroep waar de privé-DNS-zones worden gehost. De beheerde identiteit maakt en beheert de DNS-record van het privé-eindpunt in de privé-DNS-zone. Deze configuratie is nodig omdat het privé-eindpunt zich bevindt in het Azure-abonnement van de toepassingseigenaar, terwijl de privé-DNS-zone zich in een ander abonnement bevindt, zoals een centraal connectiviteitsabonnement.

Nadat het platformteam de configuratie heeft voltooid:

De Azure-abonnementen van de toepassingenteams zijn klaar voor het team om Azure PaaS-services te maken die exclusieve toegang tot privé-eindpunten hebben.
Het team moet ervoor zorgen dat de DNS-records voor privé-eindpunten automatisch worden geregistreerd bij de bijbehorende privé-DNS-zones en dat de DNS-records worden verwijderd nadat een privé-eindpunt is verwijderd.

Toepassingseigenaar implementeert een Azure PaaS-service

Nadat het platformteam de onderdelen van de platforminfrastructuur (privé-DNS-zones en -beleid) heeft geïmplementeerd, voert de eigenaar van de toepassing de volgende stappen uit wanneer ze proberen een Azure PaaS-service in het Azure-abonnement te implementeren. Deze stappen zijn hetzelfde, ongeacht of ze hun activiteiten uitvoeren via Azure Portal of andere clients, zoals PowerShell of CLI, omdat Het Azure-beleid van toepassing is op hun abonnementen.

Maak een opslagaccount via Azure Portal. Kies op het tabblad Basisbeginselen de gewenste instellingen, geef een naam op voor uw opslagaccount en selecteer Volgende.
Selecteer Privé-eindpunt op het tabblad Netwerken. Als u een andere optie dan een privé-eindpunt selecteert, kunt u in Azure Portal het opslagaccount niet maken in de sectie Beoordelen en maken van de implementatiewizard. Het beleid voorkomt dat u deze service maakt als het openbare eindpunt is ingeschakeld.
Het is mogelijk om het privé-eindpunt nu te maken of nadat u het opslagaccount heeft aangemaakt. In dit voorbeeld ziet u hoe u het privé-eindpunt maakt nadat het opslagaccount is gemaakt. Selecteer Beoordelen en maken om de stap te voltooien.
Nadat u het opslagaccount hebt gemaakt, maakt u een privé-eindpunt via Azure Portal.
Zoek in de sectie Resource het opslagaccount dat u in de vorige stap hebt gemaakt. Onder de doel-subresource selecteer je Blob en klik je vervolgens op Volgende.
Controleer in de sectie Configuratie , nadat u uw virtuele netwerk en subnet hebt geselecteerd, of Integreren met privé-DNS-zone is ingesteld op Nee. Anders voorkomt Azure Portal dat u het privé-eindpunt maakt. Met Azure Policy kunt u geen privé-DNS-zone maken met het privatelink voorvoegsel.
Selecteer Beoordelen en maken en selecteer vervolgens Maken om het privé-eindpunt te implementeren.
Na enkele minuten wordt het DeployIfNotExists beleid geactiveerd. De volgende dnsZoneGroup implementatie voegt vervolgens de vereiste DNS-records voor het privé-eindpunt toe in de centraal beheerde DNS-zone.
Nadat u het privé-eindpunt hebt gemaakt, selecteert u het en controleert u de FQDN en het privé-IP-adres:
Controleer het activiteitenlogboek voor de resourcegroep waar het privé-eindpunt is gemaakt. U kunt ook het activiteitenlogboek van het privé-eindpunt zelf controleren. Na een paar minuten wordt een DeployIfNotExist beleidsactie uitgevoerd, waarmee de DNS-zonegroep op het privé-eindpunt wordt geconfigureerd:
Als het centrale netwerkteam naar de privatelink.blob.core.windows.net privé-DNS-zone gaat, bevestigen ze dat de DNS-record er is voor het privé-eindpunt dat u hebt gemaakt en dat zowel de naam als het IP-adres overeenkomen met de waarden binnen het privé-eindpunt.

Op dit moment kunnen toepassingsteams het opslagaccount gebruiken via een privé-eindpunt vanuit elk virtueel netwerk in de hub-and-spoke-netwerkomgeving en vanuit on-premises. De DNS-record is automatisch vastgelegd in de privé-DNS-zone.

Als een eigenaar van een toepassing het privé-eindpunt verwijdert, worden de bijbehorende records in de privé-DNS-zone automatisch verwijderd.