Private Link와 DNS의 대규모 통합
이 문서에서는 허브 및 스포크 네트워크 아키텍처의 Azure 프라이빗 DNS 영역과 PaaS용 Azure Private Link 서비스를 통합하는 방법을 설명합니다.
소개
많은 고객이 허브 및 스포크 네트워크 아키텍처를 사용하여 Azure에서 네트워크 인프라를 빌드합니다. 이 아키텍처에서
- 네트워킹 공유 서비스(예: 네트워크 가상 어플라이언스, ExpressRoute/VPN 게이트웨이 또는 DNS 서버)는 허브 VNet(가상 네트워크)에 배포됩니다.
- 스포크 VNet은 VNet 피어링을 통해 공유 서비스를 사용합니다.
허브 및 스포크 네트워크 아키텍처에서 애플리케이션 소유자는 일반적으로 허브 VNet에 연결된 VNet(스포크)을 포함하는 Azure 구독을 제공합니다. 이 아키텍처에서는 가상 머신을 배포하고 ExpressRoute 또는 VPN을 통해 다른 VNet 또는 온-프레미스 네트워크에 프라이빗 연결을 가질 수 있습니다.
Azure Firewall과 같은 NVA(중앙 네트워크 가상 어플라이언스)는 인터넷 아웃바운드 연결을 제공합니다.
많은 애플리케이션 팀은 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 확인의 기타 요구 사항을 기반으로 합니다. 대부분의 경우 네트워킹 및 ID 관리자만 영역에서 DNS 레코드를 관리할 수 있는 권한이 있습니다.
애플리케이션 팀에는 자체 구독에서 Azure 리소스를 만들 수 있는 권한이 있습니다. 프라이빗 DNS 영역에서 DNS 레코드 관리를 포함하는 중앙 네트워킹 연결 구독에는 권한이 없습니다. 이 액세스 제한은 프라이빗 엔드포인트를 사용하여 Azure PaaS 서비스를 배포할 때 필요한 DNS 레코드를 만들 수 없다는 것을 의미합니다.
다음 다이어그램은 중앙 DNS 확인이 있고, Private Link 리소스의 이름 확인이 Azure 프라이빗 DNS 통해 수행되는 엔터프라이즈 환경에 대한 일반적인 상위 수준 아키텍처를 보여 줍니다.
이전 다이어그램에서 다음을 강조 표시해야 합니다.
- 온-프레미스 DNS 서버에는 각 프라이빗 엔드포인트 공용 DNS 영역에 대해 구성된 조건부 전달자가 있으며 허브 VNet에서 호스트되는 프라이빗 DNS Resolver를 가리킵니다.
- 허브 VNet에서 호스트되는 프라이빗 DNS 확인자는 Azure 제공 DNS(168.63.129.16)를 전달자로 사용합니다.
- 허브 VNet은 Azure 서비스의 프라이빗 DNS 영역 이름(예:
privatelink.blob.core.windows.net다이어그램에 표시됨)에 연결되어야 합니다. - 모든 Azure VNet은 허브 VNet에서 호스트되는 프라이빗 DNS Resolver를 사용합니다.
- 프라이빗 DNS 해결자는 고객의 회사 기본 권한이 없기 때문에 단순히 전달자일 뿐이므로(예: Active Directory do기본 이름) 온-프레미스 DNS 서버(172.16.10 및 172.16.1.11) 또는 Azure에 배포된 DNS 서버를 가리키는 고객의 회사 기본 아웃바운드 엔드포인트 전달자가 있어야 합니다.
이전 다이어그램에서는 단일 허브 및 스포크 아키텍처를 보여 주지만, 고객은 복원력, 근접성 또는 데이터 상주 요구 사항을 해결하기 위해 여러 지역에 걸쳐 Azure 공간을 확장해야 할 수 있지만, 여러 PE(프라이빗 엔드포인트)를 통해 동일한 Private Link 지원 PaaS 인스턴스에 액세스해야 하는 몇 가지 시나리오가 등장했습니다.
다음 다이어그램은 Azure 프라이빗 DNS 통해 Private Link 리소스에 대한 이름 확인이 수행되는 허브(지역당 하나)에 배포된 중앙 DNS 확인이 있는 엔터프라이즈 환경에 대한 일반적인 고급 아키텍처를 보여 줍니다.
클라이언트가 있는 각 지역에 하나씩 PaaS 인스턴스에 연결된 여러 지역 프라이빗 엔드포인트를 배포하고 지역별 Private Link 및 프라이빗 DNS 영역을 사용하도록 설정하는 것이 좋습니다. 기본 제공 DR 기능(지역 중복 스토리지 계정, SQL DB 장애 조치(failover) 그룹 등)을 사용하여 PaaS 서비스를 사용하는 경우 여러 지역 프라이빗 엔드포인트가 필수입니다.
이 시나리오에는 현재 자동화된 수명 주기 관리가 없기 때문에 모든 지역에서 설정된 Private Link DNS 레코드의 수동 기본 테넌트/업데이트가 필요합니다.
다른 사용 사례의 경우 단일 전역 프라이빗 엔드포인트를 배포하여 관련 지역의 라우팅을 단일 지역의 단일 프라이빗 엔드포인트에 추가하여 모든 클라이언트가 액세스할 수 있도록 할 수 있습니다.
온-프레미스 네트워크에서 프라이빗 DNS 영역 및 프라이빗 엔드포인트로 privatelink 의 연결을 활성화하려면 DNS 인프라에 적절한 DNS 구성(조건부 전달자 등)을 프로비전해야 합니다.
애플리케이션 팀이 구독에 필요한 Azure PaaS 리소스를 만들려면 다음 두 가지 조건을 충족해야 합니다.
- 중앙 네트워킹 및/또는 중앙 플랫폼 팀은 애플리케이션 팀이 프라이빗 엔드포인트를 통해서만 Azure PaaS 서비스를 배포하고 액세스할 수 있도록 해야 합니다.
- 중앙 네트워킹 및/또는 중앙 플랫폼 팀은 프라이빗 엔드포인트를 만들 때 해당 레코드를 처리하는 방법을 설정해야 합니다. 생성되는 서비스와 일치하는 중앙 집중식 프라이빗 DNS 영역에서 자동으로 만들어지도록 해당 레코드를 설정합니다.
- DNS 레코드는 프라이빗 엔드포인트의 수명 주기를 따라야 합니다. 즉, 프라이빗 엔드포인트가 삭제되면 자동으로 제거됩니다.
참고 항목
DNS 확인을 기반으로 하는 네트워크 규칙의 FQDN을 Azure Firewall 및 방화벽 정책에서 사용해야 하는 경우(이 기능을 사용하면 NTP, SSH, RDP 등 TCP/UDP 프로토콜을 사용하여 아웃바운드 트래픽을 필터링할 수 있습니다). 네트워크 규칙에서 FQDN을 사용하려면 Azure Firewall DNS 프록시를 사용하도록 설정해야 합니다. 그런 다음 해당 스포크 VNet은 사용자 지정 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이 있는 Storage 계정이 예제입니다. 연결 구독에서 프라이빗 DNS 영역을 만드는 privatelink.blob.core.windows.net 것으로 변환됩니다.
정책 정의
프라이빗 DNS 영역 외에도 사용자 지정 Azure Policy 정의 집합을 만들어야 합니다. 이러한 정의는 프라이빗 엔드포인트의 사용을 적용하고 사용자가 만든 DNS 영역에서 DNS 레코드를 자동으로 만듭니다.
PaaS 서비스 정책에 대한 퍼블릭 엔드포인트를
Deny(거부)합니다.이 정책은 사용자가 퍼블릭 엔드포인트를 사용하여 Azure PaaS 서비스를 만들 수 없도록 하고 리소스를 만들 때 프라이빗 엔드포인트를 선택하지 않으면 오류 메시지를 제공합니다.
정확한 정책 규칙은 PaaS 서비스 간에 다를 수 있습니다. Azure Storage 계정의 경우 공용 네트워크의 요청이 허용되는지 여부를 정의하는 networkAcls.defaultAction 속성을 확인합니다. 이 경우 networkAcls.defaultAction 속성이 아닌
Deny경우 Microsoft.Storage/storageAccounts 리소스 종류 만들기를 거부하는 조건을 설정합니다. 다음 정책 정의는 동작을 보여줍니다.{ "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 영역을 만들고 서비스를 구독에 연결하는 것을 방지해야 합니다.
애플리케이션 팀이 프라이빗 엔드포인트를 만들 때 옵션이
Integrate with private DNS zoneAzure Portal에서 설정No되었는지 확인합니다.
선택하는
Yes경우 Azure Policy를 사용하면 프라이빗 엔드포인트를 만들 수 없습니다. 정책 정의에서 영역에privatelink접두사가 있는 경우 Microsoft.Network/privateDnsZones 리소스 유형을 만드는 기능을 거부합니다. 다음 정책 정의는 접두사를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방법을 식별하기 위한 두 가지 방법을 보여 줍니다.첫 번째 정책은 두 번째 정책이 둘 다
privateLinkServiceId사용하는 동안에groupId의존합니다groupID. 다른 리소스와 충돌(충돌)할 때groupId두 번째 정책을 사용합니다.예를 들어
groupIdSQL 은 Cosmos DB 및 Synapse Analytics 모두에 사용됩니다. 리소스 유형이 배포되고 프라이빗 엔드포인트 항목을 만들기privateDNSZoneGroup위해 첫 번째 정책이 할당된 경우 Cosmos DB 또는 Synapse Analytics의 잘못된 프라이빗 DNS 영역에 만들어지고 매핑됩니다. 그런 다음 첫 번째 정책이 정책 규칙에서 찾는 충돌groupId로 인해 각 영역 간에 전환될 수 있습니다.프라이빗 링크 리소스
groupId목록은 프라이빗 엔드포인트란?의 하위 리소스 열을 참조하세요.
팁
Azure Policy 기본 제공 정의는 지속적으로 추가, 삭제 및 업데이트됩니다. 기본 제공 정책을 사용하는 것과 고유한 정책(사용 가능한 경우)을 관리하는 것이 좋습니다. AzPolicyAdvertizer를 사용하여 'xxx... 프라이빗 DNS 영역을 사용하려면 '. 또한 ALZ(Azure 랜딩 존)에는 기본 제공 정책과 주기적으로 업데이트되는 프라이빗 DNS 영역을 사용하도록 Azure PaaS 서비스를 구성하는 정책 이니셔티브가 있습니다. 상황에 기본 제공 정책을 사용할 수 없는 경우 피드백 사이트 Azure 거버넌스에 문제를 azure-policy 만드는 것이 좋습니다. · Azure Policy GitHub 리포지토리의 새 기본 제공 정책 제안 프로세스에 따른 커뮤니티입니다.
첫 번째 DeployIfNotExists 정책 - 일치만 groupId
이 정책은 서비스별 프라이빗 엔드포인트 리소스를 만드는 경우 트리거됩니다 groupId. groupId는 이 프라이빗 엔드포인트가 연결해야 하는 원격 리소스(서비스)에서 가져온 그룹 ID입니다. 그런 다음 프라이빗 엔드포인트 내의 배포를 privateDNSZoneGroup 트리거하여 프라이빗 엔드포인트를 프라이빗 DNS 영역과 연결합니다. 이 예제 groupId 에서 Azure Storage Blob의 경우는 다음과 같습니다 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"
}
}
}
}
두 번째 DeployIfNotExists 정책 - 일치 groupIdprivateLinkServiceId
이 정책은 서비스별 groupId 및 를 사용하여 프라이빗 엔드포인트 리소스를 만드는 경우 트리거됩니다 privateLinkServiceId. groupId는 이 프라이빗 엔드포인트가 연결해야 하는 원격 리소스(서비스)에서 가져온 그룹 ID입니다. 이 privateLinkServiceId 프라이빗 엔드포인트가 연결해야 하는 원격 리소스(서비스)의 리소스 ID입니다. 그런 다음 프라이빗 엔드포인트를 프라이빗 DNS 영역과 연결하는 프라이빗 엔드포인트 내의 privateDNSZoneGroup 배포를 트리거합니다.
이 예제 groupId 에서 Azure Cosmos DB(SQL)의 경우는 SQLprivateLinkServiceId 반드시 포함되어 Microsoft.DocumentDb/databaseAccounts야 합니다. 다른 Azure 서비스에 대한 자세한 내용은 하위 리소스 열 아래의 groupIdprivateLinkServiceId 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 구독을 대상으로 지정하는지 확인합니다.
Important
정책에 정의된 roleDefinition을 할당하는 것 외에도 프라이빗 DNS 영역이 프라이빗 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에서는 접두사를 사용하여 프라이빗 DNS 영역을
privatelink만들 수 없습니다.
검토 + 만들기를 선택한 다음, 만들기를 선택하여 프라이빗 엔드포인트를 배포합니다.
몇 분
DeployIfNotExists후에 정책이 트리거됩니다. 그런 다음, 후속dnsZoneGroup배포는 중앙에서 관리되는 DNS 영역의 프라이빗 엔드포인트에 필요한 DNS 레코드를 추가합니다.프라이빗 엔드포인트를 만든 후 해당 엔드포인트를 선택하고 해당 FQDN 및 개인 IP를 검토합니다.
프라이빗 엔드포인트가 만들어진 리소스 그룹에 대한 활동 로그를 확인합니다. 또는 프라이빗 엔드포인트 자체의 활동 로그를 검사 수 있습니다. 몇 분
DeployIfNotExist후에 정책 작업이 실행되고 프라이빗 엔드포인트에서 DNS 영역 그룹을 구성하는 것을 알 수 있습니다.
중앙 네트워킹 팀이 프라이빗 DNS 영역으로 가는
privatelink.blob.core.windows.net경우 사용자가 만든 프라이빗 엔드포인트에 대한 DNS 레코드가 있는지 확인하고 이름 및 IP 주소가 프라이빗 엔드포인트 내의 값과 일치하는지 확인합니다.
이 시점에서 애플리케이션 팀은 허브 및 스포크 네트워크 환경 및 온-프레미스의 모든 VNet에서 프라이빗 엔드포인트를 통해 스토리지 계정을 사용할 수 있습니다. DNS 레코드는 프라이빗 DNS 영역에 자동으로 기록됩니다.
애플리케이션 소유자가 프라이빗 엔드포인트를 삭제하면 프라이빗 DNS 영역의 해당 레코드가 자동으로 제거됩니다.
다음 단계
온-프레미스 및 Azure 리소스에 대한 DNS를 검토 합니다. 가상 머신 원격 액세스에 대한 계획을 검토합니다.
Important
이 문서에서는 관리 그룹에 할당된 DINE(DeployIfNotExists) 정책을 사용하여 대규모로 DNS 및 프라이빗 링크 통합을 간략하게 설명합니다. 즉, 정책에 의해 처리되므로 이 방법을 사용하여 프라이빗 엔드포인트를 만들 때 코드에서 DNS 통합을 처리할 필요가 없습니다. 또한 애플리케이션 팀이 중앙 집중식 프라이빗 DNS 영역에 대한 RBAC 액세스 권한을 가질 가능성은 거의 없습니다.
다음은 Bicep 및 HashiCorp Terraform을 사용하여 프라이빗 엔드포인트를 만들 때 검토할 수 있는 유용한 링크입니다.
코드로 인프라를 사용하여 프라이빗 엔드포인트를 만드는 경우:
빠른 시작 Bicep을 사용하여 프라이빗 엔드포인트를 만듭니다.
Terrafrom Registry에서 HashiCorp Terraform azurerm_private_endpoint 사용하여 프라이빗 엔드포인트를 만듭니다.
그러나 이 문서에 설명된 대로 DINE 정책 접근 방식을 사용하는 경우 코드에서 DNS 통합 쪽을 그대로 두고 프라이빗 DNS 영역에 필요한 RBAC가 있는 DINE 정책이 이를 대신 처리하도록 해야 합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기