Private Link と DNS の大規模な統合

[アーティクル]
03/12/2024

この記事では、ハブアンドスポークネットワークアーキテクチャで、PaaS サービス用の Azure Private Link を Azure プライベート DNS ゾーンと統合する方法について説明します。

はじめに

多くのお客様は、ハブアンドスポークネットワークアーキテクチャを使用して、Azure でネットワークインフラストラクチャを構築しています。そこでは、

ネットワーク共有サービス (ネットワーク仮想アプライアンス、ExpressRoute/VPN ゲートウェイ、DNS サーバーなど) がハブ仮想ネットワーク (VNet) にデプロイされます。
スポーク VNet では、VNet ピアリング経由で共有サービスが使用されます。

ハブアンドスポークネットワークアーキテクチャでは、通常、アプリケーション所有者に Azure サブスクリプションが提供され、これには、ハブ VNet に接続された VNet (スポーク) が含まれます。このアーキテクチャでは、仮想マシンをデプロイし、ExpressRoute または VPN 経由で他の VNet またはオンプレミスネットワークへのプライベート接続を確立できます。

Azure Firewall などの中央のネットワーク仮想アプライアンス (NVA) は、インターネット送信接続を提供します。さらに、Azure Firewall DNS プロキシなどのデバイス、ハブ内またはハブに隣接する別のサービスは、通常、DNS 転送をカスタマイズするために使用されます。

多くのアプリケーションチームは、Azure IaaS および PaaS リソースの組み合わせを使用してソリューションを構築しています。一部の Azure PaaS サービス (SQL Managed Instance など) は、お客様の VNet にデプロイできます。その結果、トラフィックは Azure ネットワーク内でプライベートのままとなり、オンプレミスから完全にルーティング可能です。

ただし、一部の Azure PaaS サービス (Azure Storage や Azure Cosmos DB など) は、お客様の VNet にデプロイできず、パブリックエンドポイント経由でアクセスできます。場合によっては、この構成により、お客様のセキュリティポリシーとの競合が発生します。企業トラフィックで、パブリックエンドポイント経由の企業リソース (SQL データベースなど) のデプロイやアクセスが許可されない場合があります。

Azure Private Link では、プライベートエンドポイント経由の Azure サービスの一覧へのアクセスがサポートされていますが、それには、それらのプライベートエンドポイントレコードを、対応するプライベート DNS ゾーンに登録する必要があります。

この記事では、プライベートエンドポイント経由でのみアクセスできる Azure PaaS サービスをサブスクリプションにデプロイする方法について説明します。

また、この記事では、アプリケーションチームが確実に各サービスが自動的にプライベート DNS ゾーンと統合されるようにする方法についても説明します。彼らは Azure プライベート DNS を介した自動化を行います。これにより、DNS でレコードを手動で作成または削除する必要がなくなります。

ハブアンドスポークネットワークアーキテクチャでの Private Link と DNS の統合

プライベート DNS ゾーンは通常、ハブ VNet がデプロイされている同じ Azure サブスクリプションで、一元的にホストされます。この中央ホスティングプラクティスは、クロスプレミス DNS 名前解決や、Active Directory などの中央の DNS 解決に対するその他のニーズによって推進されます。ほとんどの場合、ゾーンで DNS レコードを管理するアクセス許可を持つのは、ネットワークと ID の管理者のみです。

アプリケーションチームは、所有するサブスクリプションに Azure リソースを作成するアクセス許可を持っています。彼らには、プライベート DNS ゾーンの DNS レコードの管理を含む、中央ネットワーク接続サブスクリプションでのアクセス許可が与えられていません。このアクセス制限は、プライベートエンドポイントでの Azure PaaS サービスのデプロイ時に、必要な DNS レコードを作成できないことを意味します。

次の図は、中央 DNS 解決によるエンタープライズ環境の一般的なアーキテクチャの概要を示しており、そこでは Private Link リソースの名前解決が、Azure プライベート DNS 経由で行われます。

Private Link リソースの中央 DNS 解決と名前解決を備えた高度なアーキテクチャの図。

前の図では、次の点に注目することが重要です。

オンプレミスのDNSサーバーには、プライベートエンドポイントのパブリックDNSゾーンごとに条件付きフォワーダーが構成されており、ハブVNetでホストされているプライベートDNSリゾルバーを指します。
ハブVNetでホストされているプライベートDNSリゾルバーは、Azureが提供するDNS (168.63.129.16) をフォワーダーとして使用します。
ハブ VNet は、Azure サービスのプライベート DNS ゾーン名 (図に示すように privatelink.blob.core.windows.net など) にリンクされる必要があります。
すべてのAzure VNetは、ハブVNetでホストされているプライベートDNSリゾルバーを使用します
プライベートDNSリゾルバーは単なるフォワーダー(たとえば、Active Directoryドメイン名)であるため、顧客の企業ドメインに対して権限がないため、そのようなゾーンに対して権限を持つオンプレミスのDNSサーバー (172.16.1.10および172.16.1.11) またはAzureにデプロイされたDNSサーバーを指す、顧客の企業ドメインへの送信エンドポイントフォワーダーが必要です。

Note

Hub Virtual Network に ExpressRoute ゲートウェイなどと一緒に DNS Private Resolver を配置することができます。ただし、パブリック FQDN の解決が許可され、DNS 転送ルールセットのルールを使用して目標 DNS サーバーに有効な応答を返すことを確認する必要があります。一部の Azure サービスは、パブリック DNS 名を機能させるために解決する機能に依存しています。詳しくは、こちらをご覧ください

前の図は単一のハブアンドスポークアーキテクチャを示していますが、回復性、近接性、またはデータ所在地の要件に対応するために、お客様は場合によっては複数のリージョンにわたって Azure フットプリントを拡張する必要がありますが、同じ Private-Link 対応 PaaS インスタンスに複数のプライベートエンドポイント (PE) を介してアクセスする必要があるシナリオがいくつかあります。

次の図は、ハブ (リージョンごとに 1 つ) にデプロイされた中央 DNS 解決によるエンタープライズ環境の一般的なアーキテクチャの概要を示しており、そこでは Private Link リソースの名前解決が、Azure プライベート DNS 経由で行われます。

PaaS インスタンスに関連付けられている複数のリージョンプライベートエンドポイントを、クライアントが存在するリージョンごとに 1 つずつデプロイし、リージョンごとの Private Link とプライベート DNS ゾーンを有効にすることをお勧めします。組み込みの DR 機能 (geo 冗長ストレージアカウントや SQL DB フェールオーバーグループなど) を使用して PaaS サービスを操作する場合は、複数のリージョンのプライベートエンドポイントが必須です。

このシナリオでは、現在のところ自動ライフサイクル管理がないため、すべてのリージョンで設定された Private Link DNS レコードの手動メンテナンス/更新が必要です。

その他のユースケースでは、1 つのグローバルプライベートエンドポイントをデプロイし、関連するリージョンから 1 つのリージョン内の単一のプライベートエンドポイントへのルーティングを追加することで、すべてのクライアントからアクセスできるようにします。

解決を有効にして、それに従いオンプレミスネットワークから privatelink プライベート DNS ゾーンとプライベートエンドポイントへの接続を有効にするには、DNS インフラストラクチャで適切な DNS 構成 (条件付きフォワーダーなど) をプロビジョニングする必要があります。

アプリケーションチームがサブスクリプションに必要な Azure PaaS リソースを作成するために、次の 2 つの条件が満たされている必要があります。

中央ネットワークまたは中央プラットフォーム (あるいはその両方) のチームは、アプリケーションチームだけがプライベートエンドポイント経由で Azure PaaS サービスをデプロイし、アクセスできるようにする必要があります。
中央ネットワークや中央プラットフォームチームは、プライベートエンドポイントを作成するときに、対応するレコードを処理する方法を確実に設定する必要があります。対応するレコードを設定して、それらが、作成されるサービスに一致する一元化されたプライベート DNS ゾーンに自動的に作成されるようにします。
DNS レコードは、プライベートエンドポイントのライフサイクルに従う必要があるので、プライベートエンドポイントが削除されると、自動的に削除されます。

Note

DNS 解決に基づくネットワーク規則の FQDN を Azure Firewall およびファイアウォールポリシーで使用する必要がある場合 (この機能を使用すると、NTP、SSH、RDP など、任意の TCP/UDP プロトコルを使用して送信トラフィックをフィルター処理できます)。ネットワークルールで FQDN を使用するには、Azure Firewall DNS プロキシを有効にする必要があります。その後、スポーク VNets は、カスタム DNS サーバーから Azure Firewall DNS プロキシに DNS 設定を変更するように強制されます。スポーク VNet の DNS 設定を変更するには、その VNet 内のすべての VM を再起動する必要があります。

以下のセクションでは、アプリケーションチームが Azure Policy を使用して、これらの条件を有効にする方法について説明します。例では、アプリケーションチームがデプロイする必要がある Azure サービスとして Azure Storage を使用します。ただし、同じ原則は Private Link をサポートする Azure サービスのほとんどに適用されます。

プラットフォームチームが必要とする構成

プラットフォームチームの構成要件には、プライベート DNS ゾーンの作成、ポリシー定義の設定、ポリシーの展開、ポリシーの割り当ての設定が含まれます。

プライベート DNS ゾーンを作成する

サポートされている Private Link サービスの中央接続サブスクリプションにプライベート DNS ゾーンを作成します。詳細については、「Azure プライベートエンドポイントの DNS 構成」をご覧ください。

この場合、BLOB を含むストレージアカウントがその例です。つまり、接続サブスクリプションに privatelink.blob.core.windows.net プライベート DNS ゾーンを作成します。

接続サブスクリプションのプライベート DNS ゾーンを示すスクリーンショット。

ポリシーの定義

プライベート DNS ゾーンに加えて、カスタム Azure Policy 定義のセットの作成も必要です。これらの定義によって、プライベートエンドポイントの使用が強制され、作成した DNS ゾーンでの DNS レコードの作成が自動化されます。

PaaS サービスポリシーのパブリックエンドポイントを Deny する。

このポリシーにより、ユーザーがパブリックエンドポイントを使用して Azure PaaS サービスを作成できなくなり、リソースの作成時にプライベートエンドポイントを選ばないと、エラーメッセージが表示されます。

正確なポリシー規則は、PaaS サービス間で異なる場合があります。 Azure Storage アカウントでは、パブリックネットワークからの要求を許可するかしないかを定義する networkAcls.defaultAction プロパティを調べます。この場合、プロパティ networkAcls.defaultAction が でなければ、リソースの種類 Microsoft.Storage/storageAccountsDeny の作成を拒否する条件を設定します。次のポリシー定義は、その動作を示しています。
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny プレフィックスポリシーを指定してプライベート DNS ゾーンを作成する機能を privatelink します。

プラットフォームチームが管理するサブスクリプションでホストされている条件付きフォワーダーとプライベート DNS ゾーンで、一元化された DNS アーキテクチャを使用します。アプリケーションチームの所有者が独自の Private Link プライベート DNS ゾーンの作成と、自分のサブスクリプションへのサービスのリンクを行えないようにする必要があります。

アプリケーションチームがプライベートエンドポイントを作成するときに、Azure portal で [Integrate with private DNS zone] オプションが [No] に設定されていることを確認します。

[Yes] を選んだ場合、Azure Policy により、プライベートエンドポイントの作成が阻止されます。このポリシー定義では、ゾーンに プレフィックスがある場合、Microsoft.Network/privateDnsZonesprivatelink リソースの種類を作成する機能が拒否されます。次のポリシー定義は、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"
    }
  }
}
```
中央のプライベート DNS ゾーンに必要な DNS レコードを自動的に作成する DeployIfNotExists ポリシー。

次のポリシー例は、どの privateDNSZoneGroup がプライベートエンドポイントで作成されたかを識別するための 2 つの方法を示しています。

最初のポリシーは groupId に依存していますが、2 つ目のポリシーでは privateLinkServiceId と groupID の両方が使用されています。が別のリソースと衝突 (競合) することになる場合は、2 つ目のポリシーgroupIdを使用します。

たとえば、 groupId SQL は Cosmos DB と Synapse Analytics の両方に使用されます。両方のリソースの種類がデプロイされ、最初のポリシーがプライベートエンドポイントエントリに privateDNSZoneGroup を作成するために割り当てられている場合は、それが作成され、Cosmos DB または Synapse Analytics の不正確なプライベート DNS ゾーンにマップされます。これは、その後、最初のポリシーによりポリシー規則内で検索された競合する groupId が原因で、各ゾーン間で切り替わる場合があります。

プライベートリンクリソースの groupId の一覧については、「プライベートエンドポイントとは」の「サブリソース」列を参照してください。

ヒント

Azure Policy 組み込み定義は、絶えず追加、削除、更新されます。独自のポリシー (使用できる場合) を管理することと対比して、組み込みのポリシーを使用することを強くお勧めします。 AzPolicyAdvertizer を使用して、'xxx ... to use private DNS zones' (プライベート DNS ゾーンを使用するように xxx ...) という名前を持つ既存の組み込みポリシーを見つけます。さらに、Azure ランディングゾーン (ALZ) にはポリシーイニシアチブ「プライベート DNS ゾーンを使用するように Azure PaaS サービスを構成する」があります。これには、組み込みのポリシーも含まれ、定期的に更新されます。ご自身の状況には組み込みのポリシーを使用できない場合は、azure-policyAzure Policy GitHub リポジトリの新しい組み込みポリシー提案のプロセスに従って、フィードバックサイトの「Azure Governance」 · コミュニティでイシューを作成することを検討してください。

1 つ目の `DeployIfNotExists` ポリシー - `groupId` のみで照合

このポリシーは、サービス固有の groupId を使用してプライベートエンドポイントリソースを作成する場合にトリガーされます。 groupId は、このプライベートエンドポイントの接続先となるリモートリソース (サービス) から取得したグループの ID です。次に、プライベートエンドポイント内の privateDNSZoneGroup のデプロイをトリガーします。これにより、プライベートエンドポイントがプライベート DNS ゾーンに関連付けられます。この例では、Azure Storage BLOB の groupId は blob です。他の Azure サービスの groupId の詳細については、「Azure プライベートエンドポイントの DNS 構成」のサブリソースの列を参照してください。ポリシーによってプライベートエンドポイント内で groupId が検出されると、プライベートエンドポイント内に privateDNSZoneGroup がデプロイされ、パラメーターとして指定されたプライベート DNS ゾーンリソース ID にリンクされます。この例では、プライベート DNS ゾーンリソース ID は次のようになります。

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

次のコードサンプルは、ポリシー定義を示しています。

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

2 つ目の `DeployIfNotExists` ポリシー - `groupId` と `privateLinkServiceId` で照合

このポリシーは、サービス固有の groupId と privateLinkServiceId を使用してプライベートエンドポイントリソースを作成する場合にトリガーされます。 groupId は、このプライベートエンドポイントの接続先となるリモートリソース (サービス) から取得したグループの ID です。 privateLinkServiceId は、このプライベートエンドポイントの接続先となるリモートリソース (サービス) のリソース ID です。次に、プライベートエンドポイント内の privateDNSZoneGroup のデプロイをトリガーします。これにより、プライベートエンドポイントがプライベート DNS ゾーンに関連付けられます。

この例では、Azure Cosmos DB (SQL) の groupId は SQL です。そして、privateLinkServiceId には Microsoft.DocumentDb/databaseAccounts が含まれている必要があります。他の Azure サービスの groupId と privateLinkServiceId の詳細については、「Azure プライベートエンドポイントの DNS 構成」のサブリソースの列を参照してください。ポリシーによってプライベートエンドポイント内で groupId と privateLinkServiceId が検出されると、そのプライベートエンドポイント内に privateDNSZoneGroup がデプロイされます。そして、これは、パラメーターとして指定されたプライベート DNS ゾーンリソース ID にリンクされます。次のポリシー定義は、プライベート DNS ゾーンリソース ID を示しています。

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

次のコードサンプルは、ポリシー定義を示しています。

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

ポリシーの割り当て

ポリシー定義がデプロイされたら、管理グループ階層内の目的のスコープでポリシーを割り当てます。ポリシー割り当てのターゲットは必ず、アプリケーションチームがプライベートエンドポイントアクセスによって排他的に PaaS サービスをデプロイするために使用する Azure サブスクリプションにしてください。

重要

ポリシーで定義された roleDefinition を割り当てることに加えて、プライベート DNS ゾーンにプライベートエンドポイント DNS レコードを作成して管理する責任がある、DeployIfNotExists ポリシー割り当てによって作成されたマネージド IDに対して、プライベート DNS ゾーンがホストされているサブスクリプションとリソースグループのプライベート DNS ゾーン共同作成者ロールを必ず割り当ててください。これは、プライベートエンドポイントがアプリケーション所有者の Azure サブスクリプションにあり、プライベート DNS ゾーンが別のサブスクリプション (中央の接続サブスクリプションなど) にあるためです。

プラットフォームチームが構成を完了した後:

アプリケーションチームの Azure サブスクリプションは、チームが後にプライベートエンドポイントアクセスによって排他的に Azure PaaS サービスを作成する準備ができています。
チームは、プライベートエンドポイントの DNS レコードが、対応するプライベート DNS ゾーンから自動的に登録される (また、プライベートエンドポイントが削除されたら、削除される) ようにする必要があります。

アプリケーション所有者のエクスペリエンス

プラットフォームチームがプラットフォームインフラストラクチャコンポーネント (プライベート DNS ゾーンとポリシー) をデプロイした後、アプリケーション所有者は、Azure サブスクリプションへの Azure PaaS サービスのデプロイを試すときに、次の操作を行います。 Azure ポリシーによってサブスクリプションが管理されるため、このエクスペリエンスは Azure portal または PowerShell や CLI などの他のクライアントのいずれを使用してアクティビティを実行しても同じです。

Azure Portal を使用してストレージアカウントを作成します。 [基本] タブで、目的の設定を選び、ストレージアカウントの名前を指定して、[次へ] を選びます。
[ネットワーク] タブで [プライベートエンドポイント] を選びます。 [プライベートエンドポイント] 以外のオプションを選んだ場合、Azure portal では、デプロイウィザードの [確認と作成] セクションでストレージアカウントを作成できなくなります。パブリックエンドポイントが有効になっている場合、ポリシーにより、このサービスの作成は阻止されます。
プライベートエンドポイントを今、またはストレージアカウントの作成後に、作成できます。この例では、ストレージアカウントの作成後にプライベートエンドポイントの作成を示します。 [確認と作成] を選んで、手順を完了します。
ストレージアカウントを作成したら、Azure portal を使用してプライベートエンドポイントを作成します。
[リソース] セクションで、前の手順で作成したストレージアカウントを見つけます。 [対象サブリソース] で [BLOB] を選んで、[次へ] を選びます。
[構成] セクションで、VNet とサブネットを選んだら、[プライベート DNS ゾーンと統合する] が [いいえ] に設定されていることを確認します。それ以外の場合、Azure portal でプライベートエンドポイントの作成はできません。 Azure Policy では、privatelink プレフィックスを使用してプライベート DNS ゾーンを作成できません。
[確認と作成] を選択し、 [作成] を選択して、プライベートエンドポイントをデプロイします。
数分後に、DeployIfNotExists ポリシーがトリガーされます。それ以降の dnsZoneGroup デプロイでは、中央管理された DNS ゾーンに、プライベートエンドポイントの必要な DNS レコードが追加されます。
プライベートエンドポイントを作成したら、それを選び、その FQDN とプライベート IP を確認します。
プライベートエンドポイントが作成されたリソースグループのアクティビティログを確認します。または、プライベートエンドポイント自体のアクティビティログを確認することもできます。数分後に DeployIfNotExist ポリシーアクションが実行され、それによりプライベートエンドポイントに DNS ゾーングループが構成されることがわかります。
中央ネットワークチームが privatelink.blob.core.windows.net プライベート DNS ゾーンに移動すると、作成したプライベートエンドポイントに対して DNS レコードがそこにあることと、名前と IP アドレスの両方がプライベートエンドポイント内の値と一致していることを確認できます。

この時点で、アプリケーションチームは、ハブおよびスポークネットワーク環境の任意の VNet から、およびオンプレミスから、プライベートエンドポイント経由でストレージアカウントを使用できます。 DNS レコードは、プライベート DNS ゾーンに自動的に記録されています。

アプリケーション所有者がプライベートエンドポイントを削除すると、プライベート DNS ゾーン内の対応するレコードは自動的に削除されます。

次のステップ

「オンプレミスおよび Azure リソース用の DNS」を確認します。「仮想マシンへのリモートアクセスのプラン」を確認します。

重要

この記事では、管理グループに割り当てられた DINE (DeployIfNotExists) ポリシーを使用して、DNS とプライベートリンクの大規模な統合について概説しています。つまり、この方法でプライベートエンドポイントを作成するときに、コードで DNS 統合を処理する必要はありません。これは、ポリシーによって処理されるためです。また、アプリケーションチームが一元化されたプライベート DNS ゾーンへの RBAC アクセス権を持つこともまずありません。

以下は、Bicep と HashiCorp Terraform を使用してプライベートエンドポイントを作成するときに確認すると役立つリンクです。

コードとしてのインフラストラクチャを使用してプライベートエンドポイントを作成する場合:

クイックスタート: Bicep を使用してプライベートエンドポイントを作成する。

Terrafrom Registry で HashiCorp Terraform azurerm_private_endpoint を使用してプライベートエンドポイントを作成する。

コードとしてのインフラストラクチャツールでプライベートエンドポイントを作成することはできますが、この記事で説明されているように DINE ポリシー手法を使用する場合は、DNS 統合側をコードから除外し、プライベート DNS ゾーンに対して必要な RBAC を備えた DINE ポリシーで代わりにこれを処理させるする必要があります。

次の方法で共有

Private Link と DNS の大規模な統合

はじめに

ハブアンドスポークネットワークアーキテクチャでの Private Link と DNS の統合