はじめに
Azure の プライベートエンドポイント についてまとめました。
記事は、以下の構成となっています。
- 前半 = 解説
- 後半 = ストレージアカウントをプライベートエンドポイント経由に構成するための構築手順
本記事を読む前に、類似のサービス（サービスエンドポイント）との違いや、その他の Azure ネットワーク（パブリックインターネット、Microsoft グローバルネットワーク や、Azure PaaS、Azure VM の基本的な通信についてなど）をまとめた記事があります。先に そちらを参照いただき、全体像を掴んでいただくことをおススメします。
プライベートエンドポイント とは？
プライベートエンドポイントは、以下のような Azure の PaaS サービス または Private Link サービス へのアクセスを、パブリックインターネット経由ではなく、仮想ネットワーク経由で利用できるようにするものです。
① Azure Storage （ストレージアカウント）
② Azure Cosmos DB
③ Azure SQL データベース
④ Private Link サービスを使用する独自のサービス
上記の４項目は、以下の公開情報から抜粋しています。
公開情報
４項目のうち、①～③ は ストレージ関連です。いずれも、VM や、仮想ネットワークに統合（VNET統合）された App Service、オンプレミス環境 などから プライベート IP を使ってアクセスできるようになります。
④ の「Private Link サービスを使用する独自のサービス」については、自身が作成した Private Link サービスを公開し、利用者の仮想ネットワーク上に作成した プライベートエンドポイント 経由でのアクセスができるように構成できるようです。
つまり、プライベートエンドポイント に対応したサービスを独自に開発することができ、それを 利用者に プライベート IP 経由で 提供できるという事になります。（レアケースかと思うので、この記事では掘り下げません）
これを応用したものとして、Azure が提供するマネージドなサービスのうち、Private Link サービス を使って提供されているサービスも存在します。
Private Link に対応した Azure の サービス
私が検証済みの Private Link に対応した Azure の サービスは、以下の２つあります。
AVD は、以下に記事化してあります。
AVD を プライベートエンドポイント経由で 閉域接続する
https://qiita.com/carol0226/items/a405fcd075d0d459a672
Azure Monitor Private Link Scope は、２年前に検証したきりですが、ログのインジェストを プライベートエンドポイント経由で LogAnalytics へ送信できるサービスのため、よりセキュアにログを送信できるメリットがあります。これもいずれ、記事化したいと思っています。
Azure Private Link を使用して、ネットワークを Azure Monitor に接続する
https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/private-link-security
プライベートエンドポイントを利用するには？
プライベートエンドポイント のリソースを作成するだけでは、利用することができません。
必ず、名前解決と組み合わせて利用する必要があります。
下表のとおり、対象のネットワーク （下表の横列）ごとに、必要なリソース （下表の縦列）の組み合わせが存在します。
どの組み合わせでも、名前解決 は必要
プライベート DNS ゾーンを使うか、Hosts を使って名前解決を行う必要があります。
プライベート DNS ゾーンは、外部ネットワークから 直接参照することができないため、さらに 追加構成が必要です。
| ネットワークの範囲 ▶ ▼ 必要なリソース |
仮想ネットワーク内 | 外部ネットワーク |
|---|---|---|
| プライベートエンドポイント | 必須 | 必須 |
| プライベート DNS ゾーン を使った名前解決 |
可（推奨） | ※1 要追加構成 |
| Hosts を使った名前解決 | 可（オプション） | 可（オプション） |
| 対外接続ネットワーク (VPN or ExpressRoute) |
－ | 必須 |
公開情報
※1：要追加構成について
外部ネットワークから、プライベート DNS ゾーン を直接参照することはできません。
そのため、以下のいずれかを 別途 準備する必要があります。
- プライベートリゾルバー
- Windows または Linux の VM による DNS サーバー
- ドメインコントローラー（AD 統合ゾーン）
上記の追加構成の DNS サーバーは、Azure DNS（プライべート DNS ゾーン）へ フォワードする設定が必要です。
外部ネットワークのホストは、上記で追加構成した DNS サーバーを参照するように構成して、間接的に プライべート DNS ゾーン の名前解決ができるようにする必要があります。
公開情報
Support Blog
ステップごとの説明
プライベートエンドポイントと、名前解決の関係性を、図を使って 段階的に説明していきます。
Before
ストレージアカウントは、Azure PaaS のサービスです。
PaaS のサービスへのアクセスは、既定では パブリック IP アドレスが使われる仕組みとなっています。
オンプレミス環境 および、Azure VM が、ストレージアカウント を参照する場合には、下図のように アクセスされています。
図を見てもらうと判りますが、いずれも まず 名前解決 が行われて、ストレージアカウント のパブリック IP アドレスを取得してから、パブリック IP アドレスに向かって通信が行われています。
ここで、Azure VM からアクセスする際に 送信接続 SNAT を経由している点に注意してください。
送信接続 SNAT を経由する場合は、プライベート IP から、パブリック IP への SNAT 変換が行われます。
そのため、大規模環境で VM の台数が多かったり、AVD の複数セッションの利用によって、ユーザープロファイルなどが利用されていると、非常に多くの ファイル共有アクセスが発生して、SNAT のポート枯渇が発生するリスクが高まります。
加えて、社内のプライベートな通信なのに、パブリック経由で通信のやり取りが行われているのは、気持ち悪い・・・と感じる場合が多くあります（実際には、暗号化されていて、簡単には傍受できませんが・・・）
これらの課題を プライベート エンドポイント を活用すると、解決することができます。
Step 1
プライベート エンドポイント を構成すると、VM からのアクセスが 以下の通信に変わります。
Azure VM の場合の名前解決は、プライベート DNS ゾーン によって行われ、このとき プライベート エンドポイント の IP アドレスが応答されます。そのため、Azure VM は プライベートエンドポイント経由で ストレージアカウントへアクセスするようになり、送信接続 SNAT を経由しなくなります。
※このとき、パブリック経由 の通信 には変化はなく、引き続き アクセスが可能です。
この場合は、Azure VM が 送信接続 SNAT を経由しない・・・という効果しかなく、外部からのアクセスが可能なため、セキュリティ面での効果は限定的です。
Azure DNS から 外部 DNS へのフォワードは、プライベートエンドポイント の名前解決の際には使われなくなります。
引き続き、その他の インターネットサイトの名前解決の際には、フォワードが利用されます。
Step 2
続いて、ストレージアカウント の ネットワーク構成で パブリック IP からのアクセスをブロックします。
図は 赤い ✖ の箇所しか変化がありませんが、このように パブリック経由 の通信がブロックされるため、結果として プライベート経由のアクセスしか出来なくなり、セキュリティが高まります。
Step 3
プライベートエンドポイントは、外部からのアクセスにも対応しています。
S2S や P2S の VPN を構成して、外部から プライベートエンドポイントのある サブネット までのルーティングが確保されていれば、通信が可能になります。
なお、このとき 対外環境に対して、プライベート DNS ゾーン での名前解決が必要になりますが、Azure DNS は 外部から参照することができないため、間に プライベートリゾルバ（または 自前で DNS サーバー）の手配が必要になります。この点が、慣れていないと難しく感じるかもしれない点ですが、段階的に 理解していくと 納得いただけると思います。
ストレージアカウント を プライベートエンドポイント経由のみに構成する手順
本章では、ストレージアカウントへのアクセスを プライベートエンドポイント だけに絞って、セキュリティを向上させる手順を紹介します。
※ SQL Database / Cosmos DB を構成する場合も、設定の考え方は 同一です。
1. パブリック インターネットからのアクセスをブロックする
この設定を行う事で、ストレージアカウントへの パブリック IP アドレス からのアクセスをブロックします。
この後に構成する プライベートエンドポイント 経由のアクセスのみを許可することで、ストレージへのアクセスに対する セキュリティを高めることができます。
以下の２パターンの構成についての違いを説明します。
(a). 無効
(b). 選択した仮想ネットワークと IP アドレスから有効
注意
以下の私の記事を参照して、Azure Virtual Desktop を構成した場合は、(b) を選択してください。
(a) を選択してしまうと、VM のデプロイ時に カスタムスクリプト を実行できません。
Azure Virtual Desktop (AVD) マスターへの道
https://qiita.com/carol0226/items/7318fdd7aff780f5177c
手順
Azure Portal で 目的の ストレージアカウント のリソースを開きます。
左ペインから セキュリティとネットワーク 配下の ネットワーク を開き ファイアウォールと仮想ネットワーク のタブ を開きます。
(a). 無効
下図のように構成することで、例外なく すべての パブリック IP アドレスからのアクセスをブロックします。
メリット
一切の例外が認められないため、セキュリティは万全です。
注意点
Azure Portal の 「ストレージブラウザー」からのアクセスもブロックされます。
Azure Backup でのバックアップ実施や、Azure Monitor（診断設定）によって、ストレージにログを保存することなどもブロックされます。
(b). 選択した仮想ネットワークと IP アドレスから有効
「(a) 無効」の設定に加えて、以下のような 例外を設けることができます。
① 特定の パブリック IP アドレスからのアクセスを許可
② 信頼された Azure サービスからのアクセスを許可
※仮想ネットワーク という設定項目は サービスエンドポイント を許可するための項目です。プライベートエンドポイントとは関係ありません。
① 特定の パブリック IP アドレスからのアクセスを許可
図の ① クライアント IP アドレス ('xxxxx') の追加 のチェック欄を ON にすることで、Azure Portal のストレージブラウザ を使って、ストレージ上のデータにアクセスが可能になります。
アドレス範囲 欄に、ネットワークアドレス を指定します。
このように構成することで、指定した パブリック IP アドレス からの アクセスも許可されます。
インターネットの IP 範囲からのアクセスを許可する
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?tabs=azure-portal#grant-access-from-an-internet-ip-range
② 信頼された Azure サービスからのアクセスを許可
図の ② 信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します。 のチェック欄を ON にします。
このように構成することで、以下の公開情報に記載されている 特定のサービスについて、アクセスが許可されます。
信頼された Azure サービスにアクセスを許可する
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?tabs=azure-portal#grant-access-to-trusted-azure-services
メリット
ある程度のセキュリティを確保しつつ、例外を認めることで 柔軟な運用が可能になります。
注意
例外を許可した分だけ、セキュリティ が低下します。
2. プライベート エンドポイント を構成する
前章までの対応で、パブリック IP アドレス からのアクセスは抑制されています。
引き続き、プライベート IP アドレス 経由のアクセスを 許可するための構成を行います。
プライベート エンドポイント の特長として、このサブネットにアクセス可能な、すべてのネットワーク から利用することができます（同一仮想ネットワーク、ピアリング、VPN、ExpressRoute などで接続された場所からの プライべートアクセスが可能です）
サービスエンドポイント との違い
サービスエンドポイント の場合は、各サブネット ごとに エンドポイント を作成する必要があるので、その点で 違いがあります。
本章では、以下の公開情報に記載された手順を キャプチャ 付きで紹介しています。
公開情報
- Azure Portal で 目的の ストレージアカウント のリソースを開きます。
- 左ペインから セキュリティとネットワーク を開き、ネットワーク を選択します。上部のタブから プライベート エンドポイント接続 を選び、＋プライベート エンドポイント を押します。
-
基本 タブでは、任意の名前（下図では ストレージアカウント名 に "-PE" を付与）を設定します。
ネットワークインタフェース名 は、上記の名前に "-nic" で 自動命名されます。
リソースグループ名 と 地域 は、ストレージアカウント と合わせた値で構成します。
-
リソース タブでは、対象サブリソース で、ストレージの種類 を指定します。
file = ファイル共有、blob = BLOB、queue = キュー、table = テーブル
※複数のリソースを許可した場合は、それぞれに プライベート エンドポイント を作成してください。
-
仮想ネットワーク タブでは、プライベート エンドポイント を作成する サブネット を指定します。
このサブネット上に、プライベート エンドポイントが生成され、プライベート IP アドレス が構成されます。
以下の例では、Subnet2 というサブネット上に プライベート エンドポイント を構成しています。ご自身のサブネットに読み替えてください。
-
DNS タブでは、必ず プライベート DNS ゾーンと統合する で はい を選択してください。
基本的に、プライベート エンドポイント と、プライベート DNS ゾーンは、セットで利用します。
ここで、プライベート DNS ゾーン を構成することで、ストレージアカウント にアクセスするための DNS レコードが自動的に構成されます。
-
タグ タブ では、特に指定するものはないため 次：確認および作成 を押して 先に進みます。
-
確認および作成 タブでは、設定した項目をチェックして 作成 を押します。
- デプロイが完了すると、以下の通知が表示されます。
- デプロイが完了した際の画面です。リソースに移動 を押します。
- 作成された プライベート エンドポイント が 以下のように表示されます。
- 以下の画面で 作成された プライベート エンドポイント の プライベート IP を確認できます。
- プライベート DNS ゾーン は、以下のように自動構成されています。
これによって carol0226storage.privatelink.file.core.windows.net が 10.10.20.5 に名前解決されるようになります。
3. 動作確認
プライベート経由のアクセス許可の確認
プライベート エンドポイント を構成した 仮想ネットワーク 上の VM へ RDP 接続して、以下のコマンドを実行してください。
nslookup [ストレージアカウント名].[対象サブリソース].core.windows.net
以下のように、プライベート IP アドレス が応答されれば OK です。
エクスプローラー を使って、ファイル共有の確認が可能できます。
FQDN を指定して、アクセスを確認します。
\\[ストレージアカウント名].file.core.windows.net
問題無く、ファイル共有 にアクセスできれば OK です。
ストレージエクスプローラー を使用して、アクセスを確認する事も出来ます。
ファイル共有以外（BLOB , キュー , テーブル）の場合は、こちらを使いましょう。
以下から、ダウンロードして PC へインストールして利用できます。
以下のように File Shares へのアクセスが確認できます。
BLOB , キュー , テーブル があれば、同様に確認できます。
パブリック経由のアクセス拒否の確認
インターネットに接続された、外部の PC 上で、以下のコマンドを実行してください。
nslookup [ストレージアカウント名].[対象サブリソース].core.windows.net
以下のように、パブリック IP アドレス が応答されるハズです。
エクスプローラー を使って、ファイル共有の確認が可能できます。
FQDN を指定して、アクセスを確認します。
\\[ストレージアカウント名].file.core.windows.net
以下のように パブリックのポートには到達できずに、エラーが表示されれば OK です。
ストレージエクスプローラー を使用して、アクセスを確認します。
以下のように FIle Shares を選択すると、エラーが表示されてアクセスできません。
4. 外部ネットワークからの プライベート アクセス
4-1. 対外接続の構成
３章までの構成が完了していれば、あとは 該当のサブネット へアクセス可能な対外接続（ピアリング、VPN、ExpressRoute など）を構成すれば、接続先からのプライベートアクセスを実現できます。
ちょっとマニアックですが、以下のように OpenVPN を使って 仮想ネットワーク へ接続し、プライベートエンドポイント を利用することもできます。
このとき、OpenVPN に接続した際に クライアントの DNS が 次章で構成する DNS サーバー（プライベートIP）を参照するように構成してください。
4-2. 名前解決の構成
プライベートエンドポイントは、プライベート IP アドレス を提供する（上図の青色線）だけでなく、PaaS サービスへの URL を、その プライベート IP アドレスに名前解決するための Azure プライベート DNS ゾーン（上図の緑色線）とセットで利用するのが一般的です。
Azure VM が プライベートエンドポイントを参照するだけなら、DNS クエリも ① の参照（既定）のままで良い為、簡単に構成できます。
しかし、オンプレミスからの参照の場合は、S2S や P2S などの VPN を構成して、プライベートエンドポイント までのルーティング に加えて、DNS の参照先を ★ の プライベート IP となるように構成する必要があります。
プライベート DNS ゾーン にゾーンが無い DNS クエリ は、外部の DNS にフォワードされて、インターネット上の名前解決が行われます。プライベートエンドポイントだけを構成しても、DNS が未構成だと、パブリック IP アドレスが応答されてしまい、プライベート経由の通信にならないので、注意が必要です。
プライベートエンドポイントの対外接続時には、以下の ① ～ ③ いずれかの対応が必要です。
① Hosts を使った名前解決
以下の公開情報を使って、プライベート DNS ゾーンから hosts ファイル用の情報をエクスポートできます。
これを、各 PC の hosts ファイルとして保存することで、DNS サーバーを構築せずに 名前解決 させることができます。
② Azure プライベートリゾルバー は、オンプレミスからの名前解決を Azure プライベート DNS ゾーン へ転送するために用意された仕掛けです。そのため、Azure プライベートリゾルバー をデプロイして、オンプレミスの PC は、この プライベートリゾルバーを 参照する DNS サーバーとして構成すれば OK です。
③ Azure VM で DNS を用意する
この方法は、以下のような DNS サーバー を稼働させて、フォワード先として Azure プライベート DNS ゾーン (168.63.129.16) を指定します。このように 自前で DNS サーバー を用意することもできます。
- Windows Server の ドメインコントローラー + AD 統合ゾーン
- Windows Server の 標準プライマリ DNS ゾーン
- Linux の BIND
ドメインコントローラーへのアクセスがある場合
特に、仮想ネットワーク上に ドメインコントローラー（AD 統合ゾーン）を稼働させていて、オンプレミス側のクライアントがドメイン認証を行う場合は、③ のパターンを採用する必要があります。
Azure 上での ドメインコントローラーの構築は、以下の記事で紹介しています。この手順で構築すれば、結果的に DNS の問い合わせを Azure DNS（プライベート DNS ゾーン）にフォワードされるように構成されます。
https://qiita.com/carol0226/items/084fbbb3f31b646025f4
標準プライマリ DNS や、Linux の BIND を使う場合は、ご自身で Azure DNS へのフォワードを構成してください。
4-3. 仮想ネットワーク の DNS サーバーの構成変更
Azure VM や VPN ゲートウェイ を 前章で構築した DNS サーバー 経由にするためには、仮想ネットワーク の DNS サーバー の構成で、構築した DNS サーバー のプライベート IP アドレス を指定してください。
Azure VM は、これを行わなくても プライベート DNS ゾーンを参照できますが、構築した DNS サーバーを参照させるためには、この設定が必要です。
VPN ゲートウェイを使って、P2S 接続 を行う場合は、この設定が必須になります。
5. 高度な制御（オプション）
プライベートエンドポイント に対して、ルーティングテーブルや ネットワークセキュリティグループ (NSG) を適用しても、既定では 無視 されるようになっています。
プライベートエンドポイントへ ルートテーブルや ネットワークセキュリティグループ (NSG) を適用させるようにするには、以下の公開情報の手順を使って、ネットワークポリシー を有効にする必要があります。
公開情報
ユースケース
NSG の場合は、簡単です。プライベートエンドポイント への通信を 許可／ブロック させたい場合に使えます。
ルートテーブルの場合は、理解が難しいです。
単純に ルートを割り当てても うまく行きません。ハマりポイントです。
上記の公開情報から抜粋した 以下の 赤線 の箇所が該当します。
VPN ゲートウェイや ER ゲートウェイ から入ってきたトラフィックを、一旦 ファイアウォールや 仮想アプライアンスを経由させてから、プライベートエンドポイント へ向けたい場合に、本設定が必要です。
既定では、外部から プライベートエンドポイント 向けのルーティングが /32 で自動構成されているため、VPN/ER ゲートウェイ からの通信は、ダイレクトに プライベートエンドポイント へ向かってしまいます。
すると、通信の制御のために用意した ファイアウォール を経由しなくなってしまいます。
ルートテーブルで、ネットワーク単位で 仮想アプライアンス宛の ルートを書いていても、ロンゲストマッチで /32 が優先されてしまうからです。
そこで、ルートテーブルで プライベートエンドポイントへの接続時に、仮想アプライアンス 経由となるルートを /32 で、構成することで、目的を果たせるようになります（プライベートエンドポイントが複数ある場合は、１つずつ構成する必要が出てきます）
手順
下図を参考に、プライベートエンドポイント が存在している サブネット を開きます。
サブネットの編集 画面を 一番下までスクロールすると、設定項目があります。
以下のように 適用させたい機能（NSG or ルートテーブル）にチェックを入れる事で、該当のサブネットのルールが プライベートエンドポイント に適用されるようになります。
ルートテーブルは、以下の通り、プライベートエンドポイント の IP アドレス（赤下線） に対して 必ず /32（緑下線）を指定します。
記事の内容としては以上です。
プライベートエンドポイントについて、理解を深めていただけたならば幸いです。
参考情報