MENU

Azure Service Endpoint AliasとService Endpoint Policy徹底解説｜データ流出対策と設定手順

Azure

Azure の仮想ネットワークから PaaS へ安全にアクセスしたいとき、「サービス エンドポイント」「プライベート エンドポイント」「サービス エンドポイント ポリシー」が入り乱れて何をどう設計すべきか迷いがちです。本記事では、とくに情報が少ない「Service Endpoint Alias（サービス エンドポイント エイリアス）」に焦点を当て、Azure Storage へのデータ流出対策をどのように設計・実装すればよいかを実務目線で解説します。

目次

Azure Service Endpoint と Service Endpoint Policy を整理する

Azure Virtual Network Service Endpoint のおさらい

まずはベースとなる「サービス エンドポイント」から簡単に整理します。

  • VNet のサブネットから Microsoft.Storage など一部の PaaS サービスに対して、インターネットを経由せず Azure バックボーン経由で直接アクセスさせる機能
  • 有効化すると、そのサブネットの プライベート IP が Azure Storage 側から送信元として見える（VNet ID ベースのアクセス制御が可能）
  • サービス タグ（Storage.<region> など）と組み合わせて NSG でアウトバウンドを制御できるが、同リージョン内のすべてのストレージ アカウントが対象になる点が弱点

つまり、サービス エンドポイント単体では「このリージョンのストレージ全部 OK」という粒度までしか絞れず、特定のストレージ アカウントだけを許可する “細かい絞り込み” はできません。

Service Endpoint Policy（サービス エンドポイント ポリシー）の役割

そこで登場するのが Service Endpoint Policy です。公式ドキュメントでは、サービス エンドポイント経由の仮想ネットワーク トラフィックを特定の Azure Storage アカウントのみに制限する仕組みとして説明されています。

主な特徴は次のとおりです。

  • 対象は Azure Storage（リソース プロバイダー名: Microsoft.Storage）に限定される
  • VNet の サブネット単位で関連付ける
  • サービス エンドポイント経由の アウトバウンド（送信先ストレージ）だけを許可リスト方式で制御する
  • ポリシーに含まれていないストレージ アカウントへのサービス エンドポイント経由のアクセスは拒否される（データ流出対策）

ARM/Bicep テンプレートでは Microsoft.Network/serviceEndpointPolicies リソースとして定義され、その子に serviceEndpointPolicyDefinitions を持ちます。定義の中で service = "Microsoft.Storage" を指定し、serviceResources に許可したいストレージ アカウントなどのリソース ID を列挙します。

Service Endpoint Policy は「Microsoft.Storage 専用」か？

結論から言えば、はい。現時点で Service Endpoint Policy が扱えるのは Azure Storage のみです。

  • 公式の仮想ネットワーク サービス エンドポイント ポリシーの解説は、対象を一貫して Azure Storage に限定しています。
  • Cloud Security Alliance の解説でも、「サービス エンドポイント ポリシーは現時点で Azure Storage のみ対応」とされています。
  • Microsoft Q&A でも MVP によって、「Service Endpoint Policy は Microsoft.Storage 専用であり、Key Vault や Azure SQL Database, Cosmos DB には使えない」と明言されています。

したがって、ストレージ以外の PaaS（Key Vault / Azure SQL Database / Cosmos DB など）のネットワーク制御は、Private Endpoint（プライベート リンク）と各サービスのファイアウォール設定で行うのが基本方針になります。

他のネットワーク機能との比較

機能主な目的制御対象代表的なユースケース
Service EndpointAzure バックボーン経由での PaaS への接続リージョン単位の PaaS サービス（Storage など）VM や PaaS から同リージョンの Storage へ安全にアクセス
Service Endpoint PolicyService Endpoint 経由のストレージ向けアウトバウンドを許可リスト化特定の Storage アカウント / サブスクリプション / リソース グループデータ流出対策、厳格なコンプライアンス要求
Private Endpoint特定リソースへのプライベート IP 経由の接続個々の PaaS リソース（Storage, SQL, Key Vault など）インターネット非公開での PaaS 利用、ゼロトラスト設計
NSG / UDRIP/ポートレベルのトラフィック制御と経路制御任意の IP・サービスNVA 経由ルーティング、インターネット遮断、L4 フィルタリング

Service Endpoint Alias（サービス エンドポイント エイリアス）とは

公式ドキュメントが薄い理由と正体

Service Endpoint Alias は、公式ドキュメント上ではあまり前面に出ていませんが、2025 年現在の Microsoft Q&A では以下のように説明されています。

  • 一部の Azure サービスが公開している 「Microsoft 管理のストレージ エンドポイント集合」を表すあらかじめ定義済みの ID
  • Service Endpoint Policy に追加することで、そのサービスが内部的に利用するストレージ（バックアップ、ログ、イメージ、テンポラリ データ等）へのアクセスを まとめて許可できる
  • 自分で所有しているストレージ アカウントを列挙する Resources（serviceResources）とは補完関係であり、置き換えではない

ARM/Bicep テンプレート上では、Microsoft.Network/serviceEndpointPolicies リソースの properties.serviceAlias として表現されるプロパティで、「このポリシーはどのサービス用か」を示す識別子として定義されています。

代表的な Service Endpoint Alias の例

現在、Azure 公式ドキュメント上で Alias が確認できる代表例は次の通りです。

サービスService Endpoint Alias 例主な意味 / 用途
Azure SQL Managed Instance/Services/Azure/ManagedInstanceSQL MI が内部で利用する Microsoft 管理ストレージ（バックアップ、データ/ログ ファイル等）へのアクセスを許可するために必須。SQL MI サブネット上のポリシーにはこの Alias を含める必要がある。
Azure Machine Learning/services/Azure/MachineLearningAML のコンピュート インスタンス/クラスターがプロビジョニングやジョブ実行で使用する Microsoft 管理ストレージ群へのアクセスを許可。データ流出対策構成で推奨。
Azure Databricks（クラシック コンピュート）/services/Azure/Databricksワークスペースが内部で利用する管理ストレージ（DBFS など）のアクセスを許可。Databricks のベスト プラクティスで、独自ストレージと併せてポリシーに追加することが推奨。

これらの Alias は、Azure ポータル上で Service Endpoint Policy の「＋ エイリアスの追加」から選択できるようになっています。

Alias と Resources（serviceResources）の役割分担

Service Endpoint Policy の中では、次の 2 種類の要素を組み合わせて許可リストを構成します。

項目設定場所意味典型的な指定例
Resources（serviceResources）serviceEndpointPolicyDefinitions[].properties.serviceResources自テナント側が所有するストレージ アカウント（または RG/サブスクリプション）を列挙する許可リスト/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account> など
Service Endpoint Alias（serviceAlias）Microsoft.Network/serviceEndpointPolicies.properties.serviceAliasサービス（SQL MI / AML / Databricks 等）が内部的に利用する Microsoft 管理ストレージ群をまとめて表す識別子/Services/Azure/ManagedInstance / /services/Azure/MachineLearning / /services/Azure/Databricks など

重要なのは「置き換えではなく補完」だという点です。自分で管理しているストレージ アカウントは Resources 側に ID を列挙し、サービス内部で勝手に使われる Microsoft 管理ストレージは Alias 側で丸ごと許可します。

Microsoft Q&A の MVP 回答でも、この点は明確に「Resources で自分のストレージを許可し、Alias でサービス必須の Microsoft 管理ストレージを許可する“二段構え”で使う」と説明されています。

Alias が必要になる典型シナリオ

では、実際にどんなときに Service Endpoint Alias が効いてくるのか、代表的な 3 つのシナリオで見てみます。

シナリオ 1: Azure SQL Managed Instance + 独自バックアップ ストレージ

SQL Managed Instance（以下 SQL MI）は、サービスとしての運用のために多数の Microsoft 管理ストレージを利用しています。バックアップ、トランザクション ログ、データ ファイルなどが Azure Storage 上で管理されているため、SQL MI サブネットでは 内部ストレージへのアクセスが必須です。

一方で、組織としては次のような要件を満たしたいことが多くあります。

  • 業務データのバックアップ先として、自分たちが管理する特定のストレージ アカウントだけを許可したい
  • 開発者や攻撃者が、自分のサブスクリプションのストレージに勝手にバックアップを書き出すことを防ぎたい

これを実現する構成が、公式ブログでも紹介されている次のようなパターンです。

  1. バックアップ先ストレージに Private Endpoint を張り、SQL MI からのバックアップ経路を 1 対 1 で確立
  2. SQL MI サブネットに対して、Azure Storage の Service Endpoint を有効化
  3. Service Endpoint Policy を作成し、
    • Resources にバックアップ先ストレージ（またはリソース グループ / サブスクリプション）を追加
    • Alias として /Services/Azure/ManagedInstance を追加
  4. そのポリシーを SQL MI サブネットに関連付ける

こうすることで、

  • SQL MI が利用する Microsoft 管理ストレージ へのアクセスは Alias によって継続
  • バックアップ先ストレージ は Resources で明示的に許可
  • それ以外のストレージ アカウントは Service Endpoint 経由では到達できない（Private Endpoint 経由のみ許可したいものは別途設計）

さらに、公式ドキュメントでは 「Service Endpoint Policy により SQL MI の通常動作が阻害されることはない」ことも明言されています。

シナリオ 2: Azure Machine Learning のデータ流出対策

Azure Machine Learning（AML）のコンピュート インスタンス / クラスターは、プロビジョニングやジョブ実行の過程で、Microsoft 管理ストレージ アカウントへのアクセスを行います。

AML では、データ流出リスクを抑えるために次のような構成が公式に紹介されています。

  1. AML ワークスペースのデフォルト ストレージ アカウントに対して Service Endpoint Policy を適用
  2. Policy の Resources に、そのストレージ アカウントを追加
  3. Policy に /services/Azure/MachineLearning の Alias を追加
  4. AML コンピュートが存在するサブネットに対して、Microsoft.Storage の Service Endpoint を有効化し、上記ポリシーを関連付け

これにより、

  • AML が内部的に利用する Microsoft 管理ストレージ（プロビジョニング用、ログ用など）へのアクセスは Alias を通じて許可
  • それ以外のストレージ アカウントへの “勝手な” アクセスは、Service Endpoint 経由ではブロック

AML のドキュメントでは、Service Endpoint Policy が 「Storage のアウトバウンドを許可するストレージ アカウントに限定することで、データ流出リスクを低減する」というコンテキストで詳しく説明されています。

シナリオ 3: Azure Databricks クラシック コンピュート

Azure Databricks のクラシック コンピュート平面でも、Service Endpoint Policy と Alias によるストレージ制御が公式にガイドされています。

代表的な構成は次の通りです。

  • ワークスペース用 VNet のサブネットに Microsoft.Storage の Service Endpoint を有効化
  • Service Endpoint Policy を作成し、
    • Alias に /services/Azure/Databricks を追加（Databricks が管理する必須ストレージへのアクセスを許可）
    • Resources に DBFS や Unity Catalog 用のストレージ アカウントを追加
  • そのポリシーを Databricks ワークスペースのパブリック サブネットに関連付け

これによって、Databricks が裏側で使用するストレージには影響を与えずに、ワークスペースからアクセス可能なストレージ アカウントを厳密に制限できます。

設定方法：ポータルと IaC（Bicep/ARM）の具体例

共通の前提：サブネット側の設定

Service Endpoint Alias を含む Service Endpoint Policy を使うときは、必ず次の前提を満たす必要があります。

  1. 対象サブネットで Microsoft.Storage の Service Endpoint を有効化していること
  2. そのサブネットに Service Endpoint Policy を関連付けていること

どちらか一方でも欠けると、ポリシーは一切効きません。「ポリシーを作ったのに効かない」という場合、ほとんどがこの 2 点のどちらかの漏れです。

Azure ポータルを使った設定手順（共通パターン）

SQL MI / AML / Databricks など、Alias を使うサービスでの設定フローは概ね共通しています。ここでは抽象化した手順をまとめます。

  1. Service Endpoint Policy の作成
    • Azure ポータルで「Service Endpoint Policy」を検索し、「作成」を選択
    • サブスクリプション / リソース グループ / 名前 / リージョンを入力
  2. ポリシー定義（Policy definitions）の設定
    • ＋ エイリアスの追加 をクリックし、対象サービスに応じた Alias を選択
      • SQL MI: /Services/Azure/ManagedInstance
      • AML: /services/Azure/MachineLearning
      • Databricks: /services/Azure/Databricks
    • ＋ リソースの追加 をクリックし、自社のストレージ アカウントを追加
      • Service: Microsoft.Storage
      • Scope: 「単一アカウント」または「サブスクリプション内すべて」など要件に応じて選択
  3. ポリシーの作成（確認して「作成」をクリック）
  4. サブネットへの関連付け
    • VNet のサブネット設定に移動し、Service Endpoint で Microsoft.Storage を有効化
    • 同じ画面の Service Endpoint Policies で、作成したポリシーを選択
    • 保存して反映

AML のドキュメントによれば、2025 年 2 月時点では Azure CLI や PowerShell から Alias を追加する機能は提供されておらず、ポータルでの設定が必要とされています。

Bicep での Service Endpoint Policy + Alias 定義例

IaC で管理したい場合は、Bicep から Microsoft.Network/serviceEndpointPolicies とその子リソースを定義します。サービス Alias は properties.serviceAlias プロパティで指定します。

@description('Service Endpoint Policy for SQL MI subnet')
resource sePolicy 'Microsoft.Network/serviceEndpointPolicies@2025-01-01' = {
  name: 'sep-sqlmi-prod'
  location: resourceGroup().location
  properties: {
    // このポリシーが SQL Managed Instance 用であることを示す
    serviceAlias: '/Services/Azure/ManagedInstance'

    serviceEndpointPolicyDefinitions: [
      {
        name: 'allow-backup-storage'
        properties: {
          description: 'Allow backup storage account'
          service: 'Microsoft.Storage'
          serviceResources: [
            '/subscriptions/xxxxx/resourceGroups/rg-prod-backup/providers/Microsoft.Storage/storageAccounts/stprodbackup01'
          ]
        }
      }
    ]
  }
}

作成したポリシーは、サブネット側の定義で serviceEndpointPolicies として参照します（Bicep の VNet/Subnet 定義における詳細はここでは割愛します）。

設計上のポイントとありがちな落とし穴

Service Endpoint Policy は「アウトバウンド & Storage 限定」

改めて整理すると、Service Endpoint Policy は次のような性質を持ちます。

  • 対象: Microsoft.Storage への Service Endpoint 経由のトラフィックのみ
  • 方向: アウトバウンド（送信先ストレージ側） の制御専用
  • インバウンド制御（外から VNet 内リソースへのアクセス）は NSG や Firewall で行う
  • オンプレミスからの VPN/ExpressRoute 経由のトラフィックには適用されない

そのため、たとえば「オンプレからのバックアップを特定の Storage にだけ許可したい」といった要件には直接は使えず、Storage ファイアウォールや Private Endpoint + NSG の組み合わせで実現する形になります。

Private Endpoint との関係

よく聞かれるのが「Private Endpoint を使っている場合でも Service Endpoint Policy は必要か？」という質問です。

  • Private Endpoint は NIC（プライベート IP）レベルの別経路であり、Service Endpoint / Service Endpoint Policy の対象外
  • Databricks や AML のドキュメントでも、「Private Endpoint を持つストレージ アカウントはポリシーに追加不要」と明記されています。

したがって、設計の基本は次のようになります。

パターン推奨構成Service Endpoint Policy の役割
自社ストレージは Private Endpoint のみ利用Storage 側でパブリック エンドポイントを無効化し、Private Endpoint 経由のみ許可基本的には不要。ただし、サービスが内部で利用する Microsoft 管理ストレージを Service Endpoint 経由で許可する必要がある場合は Alias を使う
一部ストレージは Service Endpoint 経由で利用Service Endpoint + Service Endpoint Policy で許可ストレージを厳格化Service Endpoint 経由で到達できるストレージを絞り込む。Private Endpoint 経由の通信には影響しない

SQL MI のバックアップ例のように、バックアップ先は Private Endpoint で 1 対 1 接続しつつ、Service Endpoint Policy と Alias で「それ以外のストレージへの Service Endpoint 経由アクセスをすべて絞る」という設計は、セキュリティと可用性のバランスがよい実践的なパターンです。

ありがちなミスとトラブルシューティングの視点

実際の運用でよくあるトラブルと、そのチェックポイントをまとめます。

症状よくある原因チェックポイント
特定ストレージへのアクセスだけ失敗するService Endpoint Policy の Resources に対象ストレージの ID を追加し忘れているポリシー定義の serviceResources に正しいリソース ID が入っているか確認
SQL MI / AML / Databricks がエラーを返す必要な Service Endpoint Alias をポリシーに追加していないSQL MI なら /Services/Azure/ManagedInstance、AML なら /services/Azure/MachineLearning など、サービス固有 Alias の設定を確認
ポリシーを作ったのに何も制限されないサブネットで Microsoft.Storage の Service Endpoint が有効化されていない or ポリシー未関連付けVNet サブネット画面で「サービス エンドポイント」「サービス エンドポイント ポリシー」の項目を再確認
Databricks / AML のジョブが Storage 403 で失敗必要な管理ストレージが Alias に含まれている前提だが、別の経路（Firewall / NSG）でブロックされているStorage 側ファイアウォール、NSG、ルート テーブルなどが、サービスからのトラフィックをブロックしていないかを確認

Service Endpoint Alias を使うかどうかの判断基準

Alias を使うべきケース

Service Endpoint Alias を積極的に使った方がよいのは、次のような状況です。

  • サブネットからの Storage 向けアウトバウンドを厳格に許可リスト化したい（コンプライアンス / 金融系など）
  • そのサブネット上で SQL MI / AML / Databricks などの PaaS を利用しており、Microsoft 管理ストレージへのアクセスを維持したい
  • 「自社管理ストレージだけを許可したいが、サービスの裏側のストレージは（安全な範囲で）例外的に許可したい」というニーズがある

このような場合、

  • Resources（serviceResources）で自社ストレージを列挙し、
  • Service Endpoint Alias でサービス必須の Microsoft 管理ストレージを一括許可する

という構成を取ることで、「セキュアだがサービスは壊れない」ラインをうまく狙うことができます。

Alias を使わなくてもよいケース

逆に、次のような場合は Alias をあえて使わない設計も十分考えられます。

  • 当該サブネットでは、そもそも SQL MI / AML / Databricks など Alias を必要とするサービスを動かしていない
  • VNet 内のリソースから Storage へのアクセスはすべて Private Endpoint 経由に統一しており、Service Endpoint を無効化している
  • 許可したい Storage がごく少数であり、Service Endpoint Policy を使うよりも Storage 側のファイアウォールだけで十分に制御できている

Alias はあくまで 「Service Endpoint Policy を使って Storage 向けアウトバウンドを絞り込みつつ、サービス自身が必要とする Microsoft 管理ストレージは壊さずに残す」ための仕組みです。その前提がなければ、無理に使う必要はありません。

まとめ：Service Endpoint Alias と Policy の実務的な使いどころ

最後に、本記事のポイントを実務設計の観点で整理します。

  • Service Endpoint Policy は Microsoft.Storage 専用であり、Key Vault や Azure SQL Database、Cosmos DB などには適用できません。これらは Private Endpoint とサービス側ファイアウォールで制御します。
  • Service Endpoint Alias は、一部の Azure サービスが公開している「Microsoft 管理ストレージの論理セット」を表す識別子で、Service Endpoint Policy に追加することで、そのサービスが必要とするストレージのみを例外的に許可できます。
  • Alias は Resources（serviceResources）を置き換えるものではなく、自社ストレージの許可リストを補完するものです。
  • SQL MI / AML / Databricks など Alias 対応サービスでは、公式ドキュメントで 特定 Alias の追加が必須／推奨と明記されています（例: /Services/Azure/ManagedInstance, /services/Azure/MachineLearning, /services/Azure/Databricks）。
  • Private Endpoint だけで閉じられる経路には Service Endpoint Policy は効きませんが、サービスが内部的に利用するストレージが Service Endpoint 依存である場合、Alias 付きポリシーが強力なデータ流出対策になります。

「とりあえず Storage 向けの Service Endpoint を有効化しただけ」の状態だと、同リージョン内の任意のストレージにデータを逃がせてしまいます。Service Endpoint Policy + Service Endpoint Alias を組み合わせることで、Azure PaaS を壊さずに“どこへデータが出て行けるか”を厳密にコントロールできるようになります。

今後、Alias に対応するサービスは増えていく可能性があります。実装時には必ず最新の公式ドキュメントを確認しつつ、「どのサブネットから、どのストレージにだけ出て行けるのか」という観点でネットワーク設計を見直してみてください。

Azure
セキュリティ Azure 仮想ネットワーク Service Endpoint Policy SQL Managed Instance Machine Learning

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次