Microsoft Entra Private Access と Hub-spoke を組み合わせてみる
TL;DR
- Microsoft Entra Private Access と Azure の Hub-spoke アーキテクチャーを組み合わせてみ隊
- ID によって、Spoke へのアクセスを制御できた
- これこそゼロトラスト ネットワーク アクセスだね
はじめに
Microsoft Entra Private Access はどうやってパケットを曲げているのか (分からんかった) や Microsoft Entra Private Access の出口 などの調査の結果、なんとなく Microsoft Entra Private Access (MEPA) の動きが分かってきたので、じゃあ実践的にいろんなアーキテクチャを試してみよう、のお時間です。
今回は、Azure の一般的な Hub-spoke アーキテクチャーと MEPA を組み合わせてみます。
Azure の Hub-spoke アーキテクチャー
簡単に Azure の Hub-spoke アーキテクチャーについて振り返っておきます。
Hub-spoke architecture
Azure のハブスポーク ネットワーク トポロジ - Azure Architecture Center などが参考になりますが、オンプレミスとの接続やインターネットへの出入り口、Firewall、NVA などを Hub に集約し、個別のワークロードは Spoke に置くというアーキテクチャーです。
Hub と Spoke の間は VNet Peering で接続することで、相互に通信できるようにしたり、その可否を制御することができる、というものです。
特に、オンプレミスとの接続に利用する ExpressRoute などは、システムごとに用意すると運用が複雑であったりコストの増加につながるため、集約して利用しよう、という意図も含まれています。
MEPA と Hub-spoke アーキテクチャー
前述のとおり Hub-spoke はオンプレミスとの接続を Hub に集約し、そこに個別の PC からの Poinrt-to-Site VPN (P2S VPN) を受け入れることも可能です。
この記事では、そのような従来からの一般的なアーキテクチャーではなく、P2S VPN の代わりに MEPA (の ZTNA) を使うことを考えてみます。
Hub-spoke の考え方に基づき、Microsoft Entra Private Access Connector (MEPA-C) は Hub に置くことにします。
そのうえで、Spoke へのアクセスが MEPA の機能により制御できることを試します。
今回のアーキテクチャー
名前のとおりではありますが、今回は家のような適当なリモート アクセスの通信元となるようなネットワークと、Azure 側に Hub-spoke アーキテクチャーを構築します。
前述のとおり、Hub には MEPA-C をデプロイしてあり、2 つの Spoke それぞれには通信確認用に Azure VM をデプロイしてあります。
remote-network-and-hub-spoke
Microsoft Entra Private Access Connector 周りの設定
今回は MEPA-C は 1 台のみしかデプロイしていませんが、Entra admin center 上では複数台をまとめて Connector group として扱います。
また、ZTNA としての設定は Enterprise application を利用し、その中の property の一つである Network access property を設定することで、その IP アドレス・ポート番号に向かうトラフィックを制御するかを設定します。
ざっくり書くと、MEPA-C の塊として MEPA-C group があり、その MEPA-C group に対して Enterprise application を関連付けし、その Enterprise application の property として Network access property を設定する、という流れです。
Microsoft Entra Private Access configuration model
構成として面白いのが、MEPA-C group と Enterprise application の関連が 1 対 1 ではなく、1 対多、つまり 1 つの MEPA-C group に対して複数の Enterprise application を関連付けることができる、という点です。
なので、MEPA-C (もしくは MEPA-C group) が 1 つしかなかったとしても、そこに Enterprise application を複数関連付けることで、複数の Spoke に対するアクセス制御が可能だろう、と考えました。
つまり、Spoke に対するアクセス制御を ID のレイヤーでやる、ネットワークのアクセス制御を ID でやる、これこそゼロトラスト ネットワークの本来の姿だろうということです。
やってみた
ということで、やってみます。
10.0.0.0/16 をアドレス空間として作成した spoke01 と、10.10.0.0/16 とした spoke02 を用意します。
Enterprise application も 2 つ作成し、spoke01 に対応するものと spoke02 のものを作成します。
それぞれの Enterprise application には spoke01 - user01、spoke02 - user02 というユーザーを割り当てておきます。
意図としては、user01 であれば spoke01 の Azure VM にアクセス可能で、spoke02 の Azure VM にはアクセスできない、という感じです。
まず、Advanced diagnostics の画面を開いてみます。
user01 としてログインしている状態ですが、user02 にしか許可されていない 10.10.0.0/16 についても、この一覧には表示されてしまっています。
GSA - Advanced diagnostics
では、その許可されていないアドレスに mstsc してみます。
mstsc なのに、Microsoft Entra ID の認証画面が出るのがなかなか新鮮です。
その後、Enterprise application で許可されていない場合、Microsoft Entra ID の画面でエラーが出て結果拒否されます。
つまり、LWF 的には一旦その宛先の通信を吸い込んで、トンネルで送ろうと思ったものの、いったん Microsoft Entra ID から拒否され、もう一回認証を試してみるもののやっぱりダメだった、という感じでしょうか。
GSA - access error
ということで、Advanced diagnostics の画面上ではアクセスできない IP アドレス帯についても表示されていますが、実際には認証のレイヤーでアクセスが拒否されているので一応大丈夫、という感じでした。
まとめ
ということで、MEPA と Azure の Hub-spoke アーキテクチャーを組み合わせてみました。
Spoke に対するネットワークアクセスを、ID を用いて制御できるという、まさにこれがゼロトラスト ネットワークだな、というのが実現できました。
ファイアウォール的なものでアクセス制御するのが一般的ではありますが、IP アドレスベースだとその PC が別のネットワークに移動したり、といったケースに対応しづらいです。
結局はそのユーザーが何にアクセスができるのか、の粒度が一番よいと思うので、やや煩雑ではあるかもしれませんが、手段の 1 つとしてはありかもしれません。
参考
- Microsoft Entra Private Access はどうやってパケットを曲げているのか (分からんかった)
- Microsoft Entra Private Access の出口
- Azure のハブスポーク ネットワーク トポロジ - Azure Architecture Center
- Microsoft Entra の Global Secure Access を使ってみる (Private Access 編)
Update log
- 参考リンクの追加 - 2024/07/14
- typo の修正とか - 2024/07/14
Discussion