トピック(2024/9/2 追記)
Global Secure Access は、2024/7/1 に 一般提供 (GA) が開始されています。
ライセンスについては、2024/10/1 からロールアウトが開始されます。
https://learn.microsoft.com/ja-jp/entra/global-secure-access/overview-what-is-global-secure-access#licensing-overview
一般提供のライセンス
注意
これ以降の記事は、2023/8/3 に記載した内容となっていますので、ご承知おきください。
Microsoft Global Secure Access とは?
Microsoft Entra の新サービスとして、Global Secure Access(セキュリティで保護されたグローバルアクセス)という機能がプレビュー提供されました。
イメージとしては、こんな感じ。
※点線の矢印の箇所は、プライベートプレビュー段階(2023/8/3現在)で、利用のためには以下より申請が必要です。
Microsoft Entra ID とは
今まで、Azure AD というブランドで提供されていた製品が Microsoft Entra ID としてリブランディングされました。
詳細は、以下の記事に纏めてあります。
以降の投稿では、新名称を採用しつつも、判りやすさを考えて、カッコ付で「旧名称」も交えながら記載しています。
Global Secure Access とは、どんな機能なのか?
判りやすく言ってしまうと、Zscaler みたいなサービスだと思います。
ZTNA というジャンルのサービスと同じような機能が実現できます。
クライアントPCを クラウド上のセキュアなネットワークへ接続させ、そのネットワークを経由して、クラウドサービスや自社環境 (オンプレミス) へアクセスできるようになります。
Microsoft Entra Internet Access は、インターネット上のクラウドサービスに対して Microsoftが持つグローバルIPアドレスからのアクセスになるため、端末のIPアドレスを隠蔽し暗号化して通信されます。
Microsoft Entra Private Access は、エージェントから アプリプロキシコネクタ間が暗号化され、社内リソースに対して プライベートIPアドレスを使ってアクセスができます。
今回、この記事では 自社環境(オンプレミス)への接続を実現できる Microsoft Entra Private Access を試してみたいと思います。
旧サービスとの比較
Microsoft としては、類似のサービスとして Azure AD アプリケーションプロキシ が提供されてきましたが、これの進化型と言って良いと思います。
Microsoft Entra Private Accessの方が構成が少し複雑ですが、TCP全般の通信が利用でき 自由度が非常に高くなっている点が最大の利点だと思います。
アプリケーションプロキシとの比較した点は、以下の通りです。
(似ている点)
- オンプレミス環境にある Windows Server へアプリプロキシコネクタと呼ばれるエージェントを導入しておくだけで導入の下準備が完了。
- このサーバーは、インターネットへのアウトバウンド(HTTPS) が許可されていればOK。
- Microsoft Entra 条件付きアクセス(Azure AD 条件付きアクセス)をつかって、アクセス可否の制御をすることもできる。
- 非常に簡単に構築できる
- アプリケーションプロキシのコネクタと、Microsoft Entra Private Access のコネクタは同じエージェントが利用されているらしい(共用可とのこと)
(違う点)
- アプリケーションプロキシ
HTTP/HTTPS の通信のみのため自由度が低い(L7で制御していると思います)
Azure AD Premium P1 ライセンスが必要
エージェントは不要
Azure AD 参加は 必須ではない - Microsoft Entra Private Access
TCPプロトコル全般に対応していて自由度がかなり高い(L4で制御していると思います)
→ UDPも開発中とのことです。
プレビュー利用のために Microsoft Entra ID Premium P1ライセンスが必要
→ GA の際のライセンス要件は未定
エージェントが必要
Microsoft Entra 参加済み(またはハイブリッド)が必須
アプリケーションプロキシ | Microsoft Entra Private Access | |
---|---|---|
制御可能な通信 | △ HTTP/HTTPSのみ | ◎ TCP全般 |
ライセンス | Azure AD Premium P1以上 | Microsoft Entra ID Premium P1以上 (GA後は未定) |
アプリプロキシコネクタ | 必要 | 必要 |
コネクタのアウトバウント通信 | HTTPSのみで利用可 | HTTPSのみで利用可 |
クライアントエージェント | 不要 | 必要 |
条件付きアクセス | 併用可 | 併用可 |
Azure AD 参加済みデバイス | 必須ではない | 必要 |
アプリケーションプロキシを構成したことがある人なら、コネクタは ほぼ同じようなアクションで構成できると思って頂ければ良いと思います。
クライアントPCにエージェントの導入が必要ですが、URLの置き換え制御が無い分楽かも。
初めて構成する人でも、構成はとてもシンプルですので、このサイトを参考に Step by Step で試していただければ体感いただけると思います。
1. 導入に必要な前提条件
1-1. 導入に必要な前提条件(管理側)
-
Microsoft Entra テナント(Azure AD テナント)
-
ライセンス:Microsoft Entra ID Premium P1 (Azure AD Premium P1)
Global Secure Access の機能はプレビューで無料なのですが、条件付きアクセスでの制御が必要なので、そのためのライセンスが必要という考え方です。将来的にライセンスが必要になるかは現時点では未定とのこと。 -
アプリプロキシコネクタ導入用サーバー
Windows Server 2012 R2 以降を導入済みのサーバー
スタンドアロン(ワークグループのサーバー)で構いません。
動作環境は、クラウド/オンプレミス を問いません。
インターネットへ HTTPSアウトバウンド接続が可能になっていれば OK です。
URLフィルタやテナント制限が実施されていると利用が出来ない場合があります。
公開情報:前提条件 (許可すべき URLやポートNo.などの記載もあります)
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-configure-connectors#prerequisites
テナントを入手して ライセンスを手配する方法は、以下の記事を参照ください
1-2. 導入に必要な前提条件(クライアント側)
- Windows 10 または Windows 11 が導入されたクライアントPC
- PCのローカル管理者権限
- Microsoft Entra 参加済みデバイス(Azure AD 参加済み)
※ハイブリッド Microsoft Entra 参加済みデバイスも可(Hybrid Azure AD 参加済み)
Microsoft Entra 参加済みデバイスの構成方法は 以下の記事を参照ください
2. 導入手順
導入手順として、以下の作業が必要です。
2-1. テナントでGlobal Secure Access の有効化を行う(初回のみ)
2-2. サーバーにアプリプロキシコネクタをインストールする(初回のみ)
2-3. テナントでクイックアクセスの構成をする(公開するセグメントや Port No.ごと)
2-4. トラフィック転送プロファイルの設定をする(初回のみ)
2-5. クライアントにエージェントを導入する(各クライアントに対して)
2-1. テナントで Global Secure Access の有効化を行う
- 前提条件に記載した環境は、ご自身で準備ください(ライセンスの適用など)
- Microsoft Entra 管理センターへアクセスします。
https://entra.microsoft.com
- 下図の通り、左ペインから「セキュリティで保護されたグローバルアクセス(プレビュー)」から、「作業の開始」を選択。次に「Activate」を押します。
- 無事に Activate されたら、「Get Started」を押します。
- 準備が完了すると、以下の画面になります。
2-2. サーバーにアプリプロキシコネクタをインストールする
- コネクタを導入するサーバーへサインインし、Microsoft Entra 管理センターへアクセスします。
https://entra.microsoft.com
- 下図の通り、左ペインから「セキュリティで保護されたグローバルアクセス(プレビュー)」から、「接続」を選択。次に「コネクタ」を押します。
- 続けて、「コネクタサービスのダウンロード」を押します。
- ダウンロードが終わったら、インストーラーを起動します。
- 以下の画面で、I Agree にチェックを入れて、[Install] を押します。
※Azure AD アプリケーションプロキシのエージェントが使われている事が判りますね。
- 以下の通り、インストール中に認証を求められるため、管理者(アプリケーション管理者ロール以上)の権限のアカウントで認証します。
※グローバル管理者ロールで問題ありません。
- 認証に成功し、インストールが終わると以下の画面になるため、[Close]を押します。
もしエラーが発生した場合は、イベントログのアプリケーションに詳細が出力されるので確認してください(Webフィルタなどの問題で通信がさえぎられている可能性が高いです)
プロキシを経由しないと外部へアクセス出来ない環境の場合は、[Learn More]のリンク先を参照して対処してください。
(Learn Moreのリンク先)
https://learn.microsoft.com/ja-jp/azure/active-directory/app-proxy/application-proxy-configure-connectors-with-proxy-servers
- 正常に構成されたかどうか、Microsoft Entra管理センターで確認します。
下図の通り、サーバー名が表示され ステータスが [アクティブ] になっていれば OK です。
公開情報:コネクタのインストールと登録
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-configure-connectors#install-and-register-a-connector
2-2-1. コネクタグループを作成する
任意となりますが、可用性を高めるために アプリプロキシコネクタを複数台配置する事が可能です。複数のサーバーにアプリプロキシをインストールした場合は、以下を参考に 同一のコネクタグループに配置してください。
別の拠点などにもコネクタを設置した場合は、別のグループを作成して区別していくことになります。
2-3. テナントでクイックアクセスの構成をする
プライベートへのアクセスを公開するための方法として、2通りが提供されています。
どちらを採用するかは、条件付きアクセスで 何通りのアプリとして公開するのかで判断します。
今回紹介する手順では、クイックアクセスを採用しています。
-
クイックアクセス
→ 条件付きアクセスで1種類のアプリ構成のみを条件化できる -
グローバル Secure Access アプリ
→ 条件付きアクセスで複数のアプリ構成を別々の設定で条件化できる
※条件付きアクセスの制約により、エンタープライズアプリごとにポリシーを構成する必要があるため、このような使い分けになっていると思われます。
2-3-1. クイックアクセスの構成を行う
クイックアクセスを構成することで、オンプレミス環境への接続ルールを作成できます。
アクセスの名称を設定し、コネクタグループ (DefaultでOK) を選択したあと、「クイックアクセスのアプリケーションセグメントを追加」を選択します。
- コネクタサーバーからアクセスが可能なオンプレミス環境のアドレス範囲とポート番号を設定します。IPアドレスや、CIDR値 (IPアドレス範囲)、URL などで指定が可能です。
画面の例では、コネクタサーバーのプライベートなローカルネットワークセグメント全体に リモートデスクトップ接続 (Port:3389) を許可していますが、Webサーバーや SSHなど TCP接続を行う通信であれば なんでも構いません。
※現時点では、TCPポートのみが有効ですが、UDPも提供予定らしいです。
- 設定が一覧に表示されたことを確認して、「保存」を押します。
公開情報:クイック アクセスを構成する
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-configure-quick-access#configure-quick-access
2-3-2. ユーザーの割り当てを行う
クイックアクセスで定義したアプリケーションセグメントに、ユーザーを割り当てます。
- クイックアクセス画面の上部にある「アプリケーション設定を編集する」を押します。
- 以下の画面で、「ユーザーとグループ」を押し そのあと「ユーザーまたはグループの追加」を押します。
- ユーザーの一覧を表示させ、任意のユーザーを選択します。
選択されたら、「割り当て」を押します。
- 選択したユーザーが 以下の通り 一覧に表示されていれば OK です。
公開情報:ユーザーとグループの割り当て
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-configure-quick-access#assign-users-and-groups
2-4. トラフィック転送プロファイルの設定をする
Global Secure Access ネットワークから、オンプレミス環境への接続を許可するための設定です。
- Microsoft Entra 管理センターへアクセスします。
https://entra.microsoft.com
- 下図の通り、左ペインから「セキュリティで保護されたグローバルアクセス(プレビュー)」から、「接続」を選択。次に「トラフィック転送」を押します。
- 続けて、「Private access profile」にチェックを入れます。
公開情報:プライベート アクセス トラフィック転送プロファイルを管理する方法
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-manage-private-access-profile
2-5. クライアントにエージェントを導入する
前章までの作業で、クラウド側やサーバー側の構成は完了です。
あとは、接続するクライアント側にエージェントを導入すれば利用する事が可能になります。
- 前提条件に記載した環境は、ご自身で準備ください(OSバージョン、Microsoft Entra参加済みデバイスなど)
- 任意の環境で Microsoft Entra 管理センターへアクセスします。
https://entra.microsoft.com
- 下図の通り、左ペインから「セキュリティで保護されたグローバルアクセス(プレビュー)」から、「デバイス」を選択。次に「クライアント」を押します。
そのあと、「Download client」を押して、エージェントをダウンロードします。
- ダウンロードしたエージェントのファイルをコピーし、クライアントPC上にペーストします。
- クライアントPC上で、エージェントをインストールします。
- agree にチェックを入れ、「Install」を押します。
- インストール中に、認証ウィンドウが表示されるため、条件付きアクセスで許可した Azure AD ユーザーを使って認証してください。
- 認証が終わったら、このウィンドウは、「Close」で閉じてください。
- インストールされたエージェントは、以下の通り PCの設定アプリで確認できます。
公開情報:Windows 用グローバル セキュア アクセス クライアント
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-install-windows-client
ここまで設定が完了すれば、Microsoft Entra Private Access が利用可能になります。
3. 動作確認
では、動作確認してみましょう。
Microsoft Entra Private Access が構成されていると、アプリプロキシコネクタを導入したサーバーからローカルでアクセス可能なリソースへ プライベートIP アドレスでアクセスが可能です。
今回は、アプリプロキシコネクタサーバーのセグメント上にあるサーバーに対して、3389 を許可しているため、RDP接続を試してみます。
- 下図の通り、クライアントPC上で「リモートデスクトップ接続」を起動し、プライベートIPで「接続」を行うだけです。
- RDP接続が開始されたあとに、認証ウィンドウが開きます。
ここで、クイックアクセスアプリに割り当てた Azure AD アカウントで認証します。
※認証に成功したタイミングで、Global Secure Access に接続されます。
- うまくいけば、以下の通り RDPの認証ウィンドウが表示されます。
- 認証に成功すると、以下の通り RDP接続が成功します。
4. オプション
4-1. 条件付きアクセスを設定する
Global Secure Access は、条件付きアクセスを併用して 多要素認証や Intune準拠済みデバイス などの追加条件を加えることが可能です。
以下の手順では、特定のユーザーに 追加で多要素認証の条件を追加した場合の操作例です。
なお、この例では それ以外のユーザーについては制限が掛かっていないため、多要素認証無しで Global Secure Access でアクセス可能な状況になっていますので、必要に応じて アクセスをブロックするポリシーも併用してください。
運用においては、全利用者がシナリオ通りにアクセス制限されているか確認してください(条件付きアクセスを利用する際の基本的な考え方です)
- クイックアクセスの構成画面で、左ペインから「条件付きアクセス」を選択し、その後「新しいポリシー」を選択します。
- 下図を参考に、プライベートアクセスをさせたいユーザーを選択します。
※先ほど、アプリケーションに割り当てたユーザー(またはグループ)に合わせる(または含まれている)必要があります。
- 次に、下図の通り ターゲットリソースとして、クイックアクセスに登録したアプリケーションが選択されている事を確認します。
※クイックアクセスの場合は ここでアプリを1種類しか指定できませんが、グローバル Secure Access アプリでは複数のアプリを作っておいて、ここで使い分けすることができます。
- 下図の通り、許可の設定では、「アクセス権の付与」を選択し、「多要素認証を要求する」にチェックを入れてください。
■ 多要素認証を要求する
□ デバイスは準拠しているとしてマーク済みである必要があります
□ Hybrid Azure AD Join を使用したデバイスが必要
※「多要素認証を要求する」の場合は、アカウントにデバイスを登録するだけで利用が可能ですが、その他の選択肢は、高度な構成技術が必要です(Intune連携や HAADJの構成など)
そのあと、「選択」を押したあと、「ポリシーの有効化」で「オン」を選択し、「作成」ボタンを押します。
- 下図の通り、一覧にポリシーが表示されれば OK です。
公開情報:Private Access アプリに条件付きアクセス ポリシーを適用する
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-target-resource-private-access-apps
4-2. 動作確認(+多要素認証が構成されていた場合)
条件付きアクセスで多要素認証の条件が追加された場合は、以下のような振る舞いになりました。
4-2-1. デバイスの登録(初回のみ)
- 以下のような画面が出た場合は、多要素認証を行うためのデバイス登録が必要です。「次へ」を押してください。
- 以下の画面で、デバイスの登録を行うことができますが、判らない人は「別の方法を設定します」を押します(認証アプリの設定を ここで説明すると複雑になるので、簡単な電話の設定を行います)
- 以下の通り「電話」を選択して、「確認」を押します。
- 下図の通り、日本の国番号(+81)を選択し、お手持ちの携帯電話番号を入力し、「次へ」を押します。
- 携帯電話のSMSに届いた6ケタのコードを、以下の画面に入力し、「次へ」を押します。
- 以下の画面になれば、アカウントに多要素認証の設定が行われたことになります。
「次へ」を押したあと、「完了」を押してください。
4-2-2. 多要素認証時の動作
- 以下の画面が表示されたら、Azure AD アカウントのパスワードを入力して「サインイン」を押します。
※多要素認証の登録を終えた後は、「タイムアウト」と表示されますが、リトライで問題ありません。
- 以下の画面になるため、赤枠部分を押します。
- 以下の画面で、携帯電話に届いた6ケタのコードを入力し「検証」を押します。
- ここで操作に時間が掛かっていると リモートデスクトップ接続 がタイムアウトしているかもしれません。その場合は、再度 RDP接続をやり直してください。
うまくいけば、以下の通り RDPの認証ウィンドウが表示されます。
- 認証に成功すると、以下の通り RDP接続が成功します。
5. まとめ
検証してみて 想像した以上に柔軟性や拡張性が高いサービスだと感じました。
今回の検証では、Azure VM 上に アプリプロキシコネクタを導入したのですが、これだけでセキュアに仮想ネットワーク上のVMにリモート接続できてしまう事に気が付きました。
しかも、利用しない時は VMを停止できるので、Azure Bastion や、VPN Gateway (P2S接続)、Just in Time VMアクセス を使う必要がなくなるし、その分コストも削減できてしまうと思いました。
別途、時間を取って 他のプロトコル(80/443 , 22 , 445)も試してみたいと思います。
それから、柔軟性が高すぎて悪い事にも使えてしまうと心配にもなりました。
※企業内に構築すると、本機能を通じて内部リソースを外部公開できてしまうため、まるで トロイの木馬のようです。
そのため、企業のセキュリティ担当者は、テナント制御と URLフィルタ等を導入して 意図せず 自社以外のテナントを使って 本機能が有効化されないようにコントロールする必要があると思います。
逆に、自社向けには 積極的に 本機能を採用して 能動的にセキュアに管理していくことで社内リソースをセキュアに守ることができるようになると思います。
オンプレミスのエンタープライズなネットワークは、既に テナント制御やWebフィルタが導入されていて、ある程度安全だと思いますが、クラウド上のネットワークも 同様に 気を付けた方が良いと思います。