はじめに

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?wt.mc_id=MVP_407731

プライベートエンドポイントを利用するには？

プライベートエンドポイントのリソースを作成するだけでは、利用することができません。
必ず、名前解決と組み合わせて利用する必要があります。

下表のとおり、対象のネットワーク （下表の横列）ごとに、必要なリソース （下表の縦列）の組み合わせが存在します。

どの組み合わせでも、名前解決は必要
プライベート 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?wt.mc_id=MVP_407731#grant-access-from-an-internet-ip-range

② 信頼された Azure サービスからのアクセスを許可

図の ② 信頼されたサービスの一覧にある Azure サービスがこのストレージアカウントにアクセスすることを許可します。 のチェック欄を ON にします。

このように構成することで、以下の公開情報に記載されている特定のサービスについて、アクセスが許可されます。

信頼された Azure サービスにアクセスを許可する
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?wt.mc_id=MVP_407731#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（緑下線）を指定します。

記事の内容としては以上です。
プライベートエンドポイントについて、理解を深めていただけたならば幸いです。

参考情報