Azure のテナント間のプライベート エンドポイント接続を制限する
ますます多くのお客様が、Azure のサービスとしてのプラットフォーム (PaaS) サービスにプライベートかつ安全に接続するために、自分のテナントでプライベート エンドポイントを使用しています。 プライベート エンドポイントは、Microsoft Entra テナント全体のサービスに接続できます。 セキュリティとコンプライアンスを確保するために、プライベート エンドポイントでの Microsoft Entra テナントをまたいだ接続をブロックすることが必要になる場合もあります。 このガイダンスでは、クロステナントのプライベート エンドポイント接続を制限または防止するための推奨構成オプションを示します。 これらのオプションは、Azure 環境内でデータ漏えい防止 (DLP) コントロールを構築するのに役立ちます。
プライベート エンドポイントの概要
プライベート エンドポイントを使用することで、Azure 環境内のトラフィックを既存のネットワーク境界を使用して制御できます。 ただし、プライベート エンドポイント接続が企業の Microsoft Entra テナント内部でのみ保持されるようにする必要がある場合もあります。 次の例は、セキュリティ上のリスクが生じる可能性がある接続を示しています。
- 接続 A: 悪意のある管理者が、顧客の仮想ネットワーク上にプライベート エンドポイントを作成します。 これらのエンドポイントは、別の Microsoft Entra テナントなど、顧客環境の外部でホストされているサービスにリンクしています。
- 接続 B: 悪意のある管理者が、顧客の Microsoft Entra テナントでホストされているサービスにリンクした他の Microsoft Entra テナントにプライベート エンドポイントを作成します。
"図 1: プライベート エンドポイントのクロステナント シナリオの図"
どちらのシナリオでも、サービスのリソース ID を指定し、プライベート エンドポイント接続を手動で承認します。 これらのアクションを実行するために、ユーザーにはロールベースのアクセス制御 (RBAC) アクセスも必要です。
図 1 の接続 C と D は、顧客が一般的に許可するシナリオを示しています。 プライベート エンドポイント接続は、企業の Microsoft Entra テナント内に保持されます。 これらはセキュリティ リスクにならないため、この 2 つのシナリオについては、この記事では扱いません。
次の情報は、Microsoft Entra テナント間でプライベート エンドポイントをプロビジョニングできないようにするためのオプションを示します。
他のテナントのサービスにリンクされているプライベート エンドポイントを拒否する
シナリオ 1: 悪意のある管理者が、顧客の Microsoft Entra テナントのサブスクリプションで次の権限を要求しています。
- privateEndpointNetworkPolicies が Disabled に設定されているサブネットでの Microsoft.Network/virtualNetworks/join/action 権限。
- 顧客環境のリソース グループへの Microsoft.Network/privateEndpoints/write アクセス権。
これらの権限があれば、悪意のある管理者は、顧客の Microsoft Entra テナントにプライベート エンドポイントを作成できます。 このプライベート エンドポイントは、別のサブスクリプションと Microsoft Entra テナントのサービスにリンクしています。 図 1 では、このシナリオが接続 A として示されています。
このシナリオでは、ユーザーは外部の Microsoft Entra テナントと Azure サブスクリプションを設定します。 次に、サービスのリソース ID を手動で指定することで、プライベート エンドポイントを顧客環境に作成します。 最後に、悪意のある管理者が、外部の Microsoft Entra テナントでホストされているリンクされたサービスのプライベート エンドポイントを承認し、接続を介したトラフィックを許可します。
悪意のある管理者がプライベート エンドポイント接続を承認すると、企業のデータが企業の仮想ネットワークから外部の Microsoft Entra テナントの Azure サービスにコピーされる可能性があります。 このセキュリティ リスクは、Azure RBAC を使用してアクセス権が付与された場合にのみ発生します。
シナリオ 1 の軽減策
次の Azure Policy を使用して、外部の Azure サービスにリンクされている企業の Microsoft Entra テナントにプライベート エンドポイントが作成されることを自動的にブロックします。
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/privateEndpoints"
},
{
"anyOf": [
{
"count": {
"field": "Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*]",
"where": {
"allOf": [
{
"field": "Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*].privateLinkServiceId",
"notEquals": ""
},
{
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
},
"greaterOrEquals": 1
},
{
"count": {
"field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
"where": {
"allOf": [
{
"field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
"notEquals": ""
},
{
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
},
"greaterOrEquals": 1
}
]
}
]
},
"then": {
"effect": "Deny"
}
このポリシーでは、接続 A と D のように、リンクされたサービスのサブスクリプションの外部で作成されたすべてのプライベート エンドポイントが拒否されます。このポリシーでは、manualPrivateLinkServiceConnections
と privateLinkServiceConnections
を柔軟に使用することもできます。
このポリシーを更新して、プライベート エンドポイントを特定のサブスクリプション セットでのみ作成できるようにすることができます。 この変更を行うには、list
パラメーターを追加し、"notIn": "[parameters('allowedSubscriptions')]"
コンストラクトを使用します。 ただし、この方法は推奨されません。このポリシーのサブスクリプションの一覧を常に維持する必要があるためです。 テナント内に新しいサブスクリプションが作成されるたびに、サブスクリプション ID をパラメーターに追加する必要があります。
代わりに、最上位の管理グループにポリシーを割り当て、必要に応じて適用除外を使用してください。
シナリオ 1 に関する考慮事項
このポリシーでは、サービス自体とは異なるサブスクリプションにあるプライベート エンドポイントの作成がブロックされます。 特定のユース ケースでこれらのエンドポイントが必要な場合は、ポリシーの適用除外を使用します。 マネージド仮想ネットワークでホストされているマネージド プライベート エンドポイントが、Microsoft Entra テナント内でホストされているサービスにのみ接続できるように、Data Factory と Azure Synapse の追加のポリシーを作成します。
他のテナントに作成されたプライベート エンドポイントからの接続を拒否する
シナリオ 2: 悪意のある管理者が、プライベート エンドポイントを作成する必要がある顧客環境のサービスに対する書き込みアクセスを要求しています。
この権限があれば、悪意のある管理者は、外部の Microsoft Entra テナントとサブスクリプションにプライベート エンドポイントを作成できます。 このエンドポイントは、顧客の Microsoft Entra テナント内のサービスにリンクします。 図 1 では、このシナリオが接続 B として示されています。
このシナリオでは、悪意のある管理者は最初に外部のプライベート Microsoft Entra テナントと Azure サブスクリプションを構成する必要があります。 次に、企業の Microsoft Entra テナント内のサービスのリソース ID とグループ ID を手動で指定することによって、自分の環境内にプライベート エンドポイントを作成します。 最後に、リンクされたサービスのプライベート エンドポイントを承認して、Microsoft Entra テナント間の接続を経由したトラフィックを許可します。
悪意のある管理者またはサービス所有者によってプライベート エンドポイントが承認されると、外部の仮想ネットワークからデータにアクセスすることができます。
シナリオ 2 の軽減策
サービス固有のポリシーを使用して、顧客テナント全体でこのシナリオを回避します。 プライベート エンドポイント接続はそれぞれのサービスのサブリソースであり、それらの [プロパティ] セクションに表示されます。 準拠していない接続は、次のポリシー定義を使用して拒否します。
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts/privateEndpointConnections"
},
{
"field": "Microsoft.Storage/storageAccounts/privateEndpointConnections/privateLinkServiceConnectionState.status",
"equals": "Approved"
},
{
"anyOf": [
{
"field": "Microsoft.Storage/storageAccounts/privateEndpointConnections/privateEndpoint.id",
"exists": false
},
{
"value": "[split(concat(field('Microsoft.Storage/storageAccounts/privateEndpointConnections/privateEndpoint.id'), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
]
},
"then": {
"effect": "Deny"
}
このポリシーは、Azure Storage の例を示しています。 同じポリシー定義を、Key Vault、Azure AI サービス、SQL Server などの他のサービスに対してレプリケートします。
管理性を向上させるために、サービス固有のポリシーをイニシアチブにバンドルします。 このポリシーは、それぞれのサービスのサブスクリプションの外部でホストされているプライベート エンドポイントへのプライベート エンドポイント接続の承認を拒否します。 プライベート エンドポイント接続の拒否または削除を拒否することはなく、これはまさに顧客が求める動作です。 接続 C などの自動承認ワークフローは、このポリシーの影響を受けません。
ただし、この方法では、ポータル内の準拠したプライベート エンドポイント接続の承認はブロックされます。 このブロックが発生するのは、ポータル UI で、接続されたプライベート エンドポイントのリソース ID がペイロードで送信されないためです。 プライベート エンドポイント接続を承認するために、Azure Resource Manager、Azure PowerShell、またはAzure CLI を使用することをお勧めします。
また、最上位の管理グループにポリシーを割り当て、必要に応じて適用除外を使用してください。
シナリオ 2 に関する考慮事項
Azure Synapse Analytics と Azure Data Factory ではマネージド仮想ネットワークとマネージド プライベート エンドポイントが提供されます。 これらの新機能により、ポリシーでは、これらのサービスのセキュリティ保護されたプライベートな使用がブロックされます。
シナリオ 2 の軽減策で使用されているポリシー定義の拒否の効果の代わりに、監査効果を使用することをお勧めします。 この変更は、別々のサブスクリプションとテナントに作成されるプライベート エンドポイントを追跡するのに役立ちます。 また、それぞれのデータ プラットフォーム スコープに対してポリシーの適用除外を使用することもできます。
Azure Data Factory
Azure Data Factory のマネージド仮想ネットワークでのシナリオ 1 の問題を解決するには、次のポリシー定義を使用します。
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints"
},
{
"anyOf": [
{
"field": "Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints/privateLinkResourceId",
"exists": false
},
{
"value": "[split(field('Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints/privateLinkResourceId'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
このポリシーでは、Data Factory のサブスクリプションの外部でホストされているサービスにリンクされているマネージド プライベート エンドポイントが拒否されます。 このポリシーを変更して、list
パラメーターを追加し、"notIn": "[parameters('allowedSubscriptions')]"
コンストラクトを使用することによって、一連のサブスクリプションでホストされているサービスへの接続を許可できます。 マネージド仮想ネットワークとマネージド プライベート エンドポイントを使用するサービスが広範囲に使用されるテナントまたは環境内のデータ プラットフォーム スコープでは、この変更をお勧めします。
最上位の管理グループにポリシーを割り当て、必要に応じて適用除外を使用することをお勧めします。 データ プラットフォームの場合は、これらの変更を行って、一連のデータ プラットフォーム サブスクリプションにこのポリシーを割り当てます。
Azure Synapse
Azure Synapse でもマネージド仮想ネットワークが使用されます。 シナリオ 1 の Data Factory ポリシーと同様のポリシーを適用することをお勧めします。 Azure Synapse では、マネージド プライベート エンドポイント用のポリシー エイリアスが提供されていません。 ただし、データ流出防止機能があり、次のポリシーを使用してワークスペースに適用できます。
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Synapse/workspaces"
},
{
"anyOf": [
{
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.preventDataExfiltration",
"exists": false
},
{
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.preventDataExfiltration",
"notEquals": true
},
{
"count": {
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.allowedAadTenantIdsForLinking[*]",
"where": {
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.allowedAadTenantIdsForLinking[*]",
"notEquals": "[subscription().tenantId]"
}
},
"greaterOrEquals": 1
}
]
}
]
},
"then": {
"effect": "Deny"
}
このポリシーでは、Azure Synapse のデータ流出機能の使用を強制します。 Azure Synapse を使用すると、顧客のテナントの外部でホストされているサービスに由来するすべてのプライベート エンドポイントを拒否できます。 また、指定したテナント ID のセット以外でホストされているプライベート エンドポイントを拒否することもできます。 このポリシーでは、顧客のテナントでホストされているサービスにリンクされているマネージド プライベート エンドポイントのみを作成できます。
これらのポリシーは、組み込みとして使用できるようになりました。
Azure Synapse ワークスペースでは、承認済みのターゲットへの送信データ トラフィックのみを許可する必要がある。
定義 ID:
/providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218
Azure Synapse マネージド プライベート エンドポイントは、承認された Microsoft Entra テナント内のリソースにのみ接続する必要がある。
定義 ID:
/providers/Microsoft.Authorization/policyDefinitions/3a003702-13d2-4679-941b-937e58c443f0
最上位の管理グループにポリシーを割り当て、必要に応じて適用除外を使用することをお勧めします。
次のステップ
パブリック インターネットとの間の受信接続と送信接続に対して推奨される接続モデルを理解することは重要です。 次の記事では、設計上の考慮事項、設計に関する推奨事項、および推奨されるコンテンツについて詳しく説明します。