Click here for the English version of this article.
はじめに
Microsoft Entra Global Secure Access の インターネットアクセス を利用していると、本記事の構成を行うことで、TLS インスペクション が実装できます。
TLS インスペクション を郵便に例えたイメージ
TLS インスペクションなし
- 封筒（通信）は厚紙で封がされており「暗号化」されている
- 郵便局（ネットワーク管理者／GSA）は中身を開けられない
- 手紙の中身が詐欺であっても気づけない（＝悪性通信が見抜けない）
→ 中身が見えないため「監査不可」、宛先チェック（URL/ドメインレベルの制御）しかできない
TLS インスペクションあり
- 郵便局（GSA）が封筒を安全に「一度開封」する
- 内容（URL / ファイル / プロンプトなど）を検査できる
- 問題がなければ新しい封筒に入れ直して送る（再暗号化）
- フィッシングやマルウェアなどの危険な内容があればブロックできる
→ 中身を確認できるため、脅威判定・AI プロンプト検査・ファイル解析など高度な機能が使える
GSA の TLS インスペクションは、上記の例で説明した検閲を実現するソリューションです。
※図は、以下の公開情報より抜粋
公開情報：トランスポート層セキュリティ検査とは
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-transport-layer-security?wt.mc_id=MVP_407731
Support Blog：Microsoft Entra Internet Access で TLS インスペクションが利用可能に
https://jpazureid.github.io/blog/azure-active-directory/tls-inspection-now-in-microsoft-entra-internet-access/
なお、TLS インスペクションを構成しただけでは、暗号化トラフィックの可視化（監査）が可能になるだけです。
その後、以下の機能を追加で構成することで、監査結果を基にしたアクション（ブロックなど）が実行可能になります。
| ポリシー種別 | TLS インスペクション必要？ | 理由 |
|---|---|---|
| Web コンテンツ制限ポリシー | 推奨 | HTTPS の URL カテゴリ判定をする場合は TLS 検査が必要 |
| 脅威インテリジェンス ポリシー | 推奨 | 悪性 URL / C2 通信の検知精度向上 |
| ファイル ポリシー | 必須 | ファイルの中身を検査するため |
| プロンプト ポリシー | 推奨 ※実質、必須 |
TLS インスペクションを行わない場合、URL ベースの AI サイトブロックは可能。 TLS インスペクションを行うことで、Prompt Shield で内容を検査可能となる |
| 脅威に対する保護ポリシー | 推奨 | TLS インスペクションを行わない場合は AI サイトへの URL / ドメイン単位制御のみ可。 該当 URL が他のポリシー対象であれば、それらの検査が複合的に適用されるため TLS インスペクションがあると効果が高い |
| Netskope DLP ポリシー | 不要 | Netskope 側で復号するため |
| クラウド ファイアウォール ポリシー | 不要 | L3/L4 制御のため |
※つまり、TLS インスペクションは、表の上から５つの機能を効果的に使うための前提事項になっている訳です。
前提条件
GSA TLS インスペクション を構成するためには、以下の公開情報で示されている前提条件を満たしておく必要があります。
上記の公開情報で示されている前提条件を、以下の ①～③ で示します。
① 証明機関
② Microsoft Entra Internet Access のライセンス
③ グローバルなセキュリティで保護されたアクセスの前提条件
① 証明機関
本機能を実装し検証する上で、この点が一番わかりづらい点です。
公開情報では、あくまでテスト用として OpenSSL を使う例を示してくれていますが、本運用ではどうすれば良いのかが示されていませんでした。
証明書署名要求 (CSR) に署名し、TLS 検査用の中間証明書を生成するための公開キー 基盤 (PKI) サービス。 テスト シナリオでは、OpenSSL で作成された自己署名ルート証明書を使用することもできます。
本記事では 運用も踏まえて Active Directory 証明書サービス (AD CS) を使った方法を紹介します。
任意のサーバーを用意して、以下の記事を参考に AD CS スタンドアロン CA（AD ドメイン環境であれば、エンタープライズ CA を推奨）を作成してください。
※すでに運用中の AD CS があれば、それを利用できます。
Active Directory 証明書サービス (ADCS) の導入
https://qiita.com/carol0226/items/cb38ed3188c520bd9d64
② Microsoft Entra Internet Access のライセンス
以下の記事を参考に GSA インターネットアクセス を構成してください。
[GSA:Internet] Microsoft Entra インターネット アクセス を構成する
https://qiita.com/carol0226/items/ae2bfdb209170fb41bae
③ グローバルなセキュリティで保護されたアクセスの前提条件
以下の記事を参考に DoH 無効化・QUIC 無効化・IPv4 優先 などの必要な前提条件のすべてを満たしてください（結構ボリュームがあります）
[GSA : Internet] 前提条件のすべてを満たす構成
https://qiita.com/carol0226/items/613214a52fdc2aff77cf
証明書の作成と展開
以下の順番で手順を紹介しています。
- 1．CSR の作成
- 2．AD CS による証明書への署名
- 3．署名済み証明書のアップロード
- 4．AD CS ルート証明書を クライアントに配布する
- 5．TLS 検査ポリシーを作成する
- 6．作成した TLS 検査ポリシーを セキュリティプロファイルを割り当てる
- 7．動作テスト
参考
上記の 1～3 について、私の記事では手動で構成する手順をキャプチャと解説付きで説明していますが、以下の公開情報には、PowerShell で すべてを実行する方法が いつの間にか 掲載されていました。
※私は、この公開情報を見つける前に 手動で対応して記事も完成させてしまったので、PowerShell は未検証です。
公開情報：PowerShell を使用して Active Directory 証明書サービスを使用して TLS 証明書を生成して署名する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/scripts/powershell-active-directory-certificate-service?wt.mc_id=MVP_407731
1. CSR の作成
TLS 検査を行うために、GSA が中間の証明機関となって、サイト毎の サーバー証明書を発行します。
この TLS 検査で必要な証明書の発行ができるようにするために、証明書要求 (CSR) を作成しています。
CSR を 上位の証明機関に提示することで、GSA を 中間の証明機関として認めてもらう必要があります。
ポイント
クライアントは、上位の証明機関のルート証明書を持っているため、上位の証明機関に認められた 下位の証明機関（GSA の中間証明機関）が発行するサーバー証明書を信頼することができるようになります。
公開情報：グローバル セキュリティで保護されたアクセス管理者: CSR を作成し、TLS 終了用の署名付き証明書をアップロードする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-transport-layer-security-settings?wt.mc_id=MVP_407731#global-secure-access-admin-create-a-csr-and-upload-the-signed-certificate-for-tls-termination
1．グローバル セキュア アクセス 管理者として Microsoft Entra 管理センターにログインします。
https://entra.microsoft.com
2．以下の画面の通りに操作を進めます。
① 左メインから TLS 検査ポリシー を選択します。
② TLS 検査の設定 タブを選択します。
③ ＋証明書の作成 ボタンを押します。
④ 以下を参考に 各項目の名称を入力します。
証明書名: この名前は、ブラウザーで表示されるときに証明書階層に表示されます。
一意で、スペースを含めず、長さは 12 文字以下にする必要があります。
重要: 削除後でも、以前の証明書名を再利用することはできません。
共通名 (CN): 中間証明書を識別する共通名 (Contoso TLS ICA など)。
組織単位 (OU): Contoso IT などの組織名。
⑤ CSR の作成 ボタンを押します。
3．以下の通知が表示されれば OK です。
同時に 以下のような csr ファイルがダウンロードされています。
以下の通り、作成した証明書が一覧に表示されていれば OK です。
2. AD CS による証明書への署名
1．ブラウザで http://[ADCSサーバーのIP]/certsrv にアクセスします。
2．以下の画面が表示されたら 証明書を要求する を選択します。
3．証明書の要求の詳細設定 を選択します。
4．前章でダウンロードした CSR をメモ帳で開き、下図の範囲を選択して コピー します。
※BEGIN と END ヘッダー箇所は範囲外です。メモ帳は閉じて構いません。
5．コピーした CSR を 以下の緑枠の箇所に貼り付けます。証明書テンプレート は、下位の証明機関 を選択（重要）して、送信 をクリックします。
6．Base 64 エンコード を選択後、証明書のダウンロード と 証明書チェーンのダウンロード をそれぞれ実施します。
3. 署名済み証明書のアップロード
AD CS からダウンロードした証明書は、そのまま GSA にインポートすることができません。
ポイント
前章でダウンロードした証明書は、以下のファイル形式になっていますが、このままでは GSA にアップロードできません。GSA 側では、拡張子 (.pem) 形式である必要があります。
ルート証明書：certnew.cer
証明書チェーン：certnew.p7b
上記の形式を .pem 形式に変換する手順
1．前章でダウンロードしたルート証明書 (certnew.cer) をコピーし、拡張子を .pem にして保存します。
※ルート証明書は、拡張子を変更するだけで GSA にアップロード可能になります。
certnew.cer も後で使うため、取っておいてください。
2．証明書チェーン (certnew.p7b) を 拡張子 .pem に変換する手順です。
p7b ファイルをダブルクリックして、一覧に表示された証明書を2つともエクスポートします。
（１つ目の証明書）
（２つ目の証明書）
※エクスポートする際には、以下の通り、Base 64 を選択してください。
3．以下のように .cer 形式 で保存します。
（１つ目の証明書）＝ルート証明書
（２つ目の証明書）＝中間証明書
4．メモ帳を新規で開き、以下の図のように ２つの証明書の内容を続けて貼り付けます。
これを、Chain.pem として保存してください。これで GSA にアップロードが可能になります。
5．下図のように TLS 検査ポリシーの証明書アップロード欄に、本章で準備した .pem ファイルを指定して 署名された証明書のアップロード をクリックします。
6．以下のように通知が届けば OK です。
7．初めは 状態（緑下線）が 無効 と表示されていますが、アクションを操作し 有効にする を選択してください。
※有効にする を選択すると、登録中 の表示に変わるので、そのまま待ちます。
8． 以下のように有効になれば OK です。
9．このとき AD CS を見ると、以下のように 下位の証明機関 (SubCA) が発行されています。
上記の証明書をダブルクリックして開くと、以下の情報を確認することができます
（全般タブ）
（詳細タブ）
（証明のパスタブ）
以上で 中間証明機関としての構成は完了です。
4. AD CS ルート証明書を クライアントに展開する
① 手動で クライアントに ルート証明書をインポートする
テストのために、１台だけに展開したい場合は 以下の記事を参考にしてください。
AD CS の ルート証明書 をダウンロードして、クライアントPC にインストールする手順
https://qiita.com/carol0226/items/33042c5c639c79832aeb
② AD CS エンタープライズ CA が使われ、ドメイン参加済みの PC の場合
この場合は、何もしなくても ドメイン参加している PC に、ルート証明書が配布された状態になっています。
③ Intune を使って 組織内のクライアントに配布する
本番運用などで、複数台のクライアントに展開する方法です。
以下の記事は、本記事で GSA の証明書を展開したときのキャプチャを使っているので、完全に整合性が取れています。
Intune で信頼されたルート証明書を配布する手順
https://qiita.com/carol0226/items/6b016907fd41001ab305
ポイント
GSA では、中間証明書 を利用しますが、クライアントデバイスには ルート証明書だけが導入されていれば OK です。中間証明書は、このルート証明書に署名（チェーンが構成）されていれば、自動的にチェックされるため 問題ありません。
つまり、すでに組織内に ルート証明書が展開済みであれば、前章の 下位証明機関 として署名するだけで良いことになります。
5. TLS 検査ポリシーを作成する
さて、本題です。
GSA の管理画面で TLS 検査ポリシーを作成します。
ここで 検査 として割り当てられた カテゴリ や URL が TLS 検査の対象となります。
公開情報：手順 1: グローバル セキュリティで保護されたアクセス管理者: TLS 検査ポリシーを作成する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-transport-layer-security?wt.mc_id=MVP_407731#step-1-global-secure-access-admin-create-a-tls-inspection-policy
1．Microsoft Entra 管理センターで、 グローバルセキュアアクセス から 安全 を開き、TLS 検査ポリシー を選択します。TLS 検査ポリシー タブで ＋ポリシーの作成 を押します。
1．基本 タブでは TLS インスペクションであることが分かる名前を付与し、検査 を選んで 次へ を押します。
2．ルール タブでは、ルールが 既定のままで良い場合は、追加せずに そのまま 次へ 進めます。
3．レビュー タブで 内容を確認して 送信 を押します。
4．以下のようにポリシーが追加されれば OK です。
なお、確認のために ・・・ を押して 編集 で開いてください。
すると、以下のように 既定で除外（バイパス）される システムルール と ルール 65000 (教育/Education、ファイナンス/Finance、政府/Government、健康+医療/HealthAndMedicine) があります。
これ以外の通信が TLS 検査されるように構成されました。
以上で、既定の設定で TLS インスペクション を実施するポリシーが作成できました。
このまま 次の章へ進んでしまって OK です。
ポイント
バイパスされているカテゴリーを あえて検査したい場合には、検査 を選んで ルールを追加します。その他のカテゴリは 既定で 自動的に検査 されるため、これを除外したい場合には バイパス を選んで ルールを追加する・・・という考え方になっています。
参考：例外設定を行う方法
既定の設定をカスタマイズしたい場合だけ、以下の例を参考にしてみてください。
＋ルールの追加 を押します。
ファイナンス（既定でバイパス）に含まれる 楽天証券 (*rakuten-sec.co.jp) を検査するためのルール例
既定で 検査されるカテゴリである ホスト決済側ゲートウェイ (Hosted Payment Gateways) をバイパスするためのルール例
カスタマイズを追加すると、以下のような画面になります。
公開情報：グローバル セキュア アクセス Web コンテンツのフィルター処理カテゴリ
https://learn.microsoft.com/ja-jp/entra/global-secure-access/reference-web-content-filtering-categories?wt.mc_id=MVP_407731
6. 作成したポリシーを プロファイル に割り当てる
前章までに作成したポリシーを、プロファイルにリンクする手順は、以下の私の記事で紹介しています。
[GSA : Internet] ポリシーを適用するためのプロファイル設定まとめ
https://qiita.com/carol0226/items/1d9fa23904947c8598fd
注意
ポリシーを作成しただけでは、TLS インスペクションは機能していません。
プロファイルにリンクすることで、初めて機能するようになります。
7. 動作テスト
TLS インスペクションが正しく構成されたら、動作テストを行います。
テストは、GSA インターネットアクセスが 有効 の場合と 無効 の場合を比較することで行います。
有効・無効 を切り替えるたびに、ブラウザのキャッシュをクリアすることを忘れないでください。
公開情報：手順 4: 構成をテストする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-transport-layer-security#step-4-test-the-configuration
Edge でキャッシュクリアを行う手順
Edge で 証明書を確認する方法
鍵のマークをクリック後に、接続がセキュリティで保護されています の右側の赤丸をクリックします。
以下の画面に変わるので、赤丸 の箇所をクリックすることで、証明書の情報を表示できます。
TLS インスペクション無効時
qiita.com の証明書が Amazon から発行されていることが分かります。
詳細タブ を見ると、Amazon ルート証明書からの３階層になっていることも確認できます。
TLS インスペクション有効時
qiita.com の証明書が Microsoft Global Secure Access Intermediate CA2 から発行されていることが分かります。
詳細タブ を見ると、ADCS の ルート証明書からの４階層になっていることが確認できます。
証明書の階層の箇所を、下スクロールした状態です。
ルート証明書が誤っている場合
PC 上の信頼されたルート証明機関に 適切なルート証明書がインポートされていないと、以下の画面になってしまいます。
Web コンテンツフィルタと組みあわせると、動作に変化が生じるため これでも確認が可能です。
TLS インスペクションなしの場合
例：https://www.amazon.co.jp を参照した場合
以下の通り、タイムアウトしたような表示になり、なぜ接続できなかったのかの表示はされません。
TLS インスペクション と組み合わせた場合
例：https://www.amazon.co.jp を参照した場合
TLS インスペクションと組み合わせることで、以下のように エラーページを表示できるようになります。
参考
記事執筆にあたっては、以下の記事を参考にさせていただきました。
TLS Inspection in Microsoft Entra GSA Internet Access – Complete Configuration Guide
https://www.thetechtrails.com/2025/09/entra-gsa-tls-inspection-guide.html
Youtube：TLS Inspection in Microsoft Entra Internet Access Deep Dive
https://www.youtube.com/watch?v=WxxHH_4vKh4
Entra Global Secure Access を利用している際に発生するトラブルあれこれ
https://zenn.dev/syuheiuda/scraps/f6e5d04b460bba
私が本記事の執筆を終えてから、以下の記事を見つけました。Azure KeyVault に自己署名証明書を保存して、GSA中間証明書を署名、Intune で証明書を配るという、スゴイ連携を実現していますが、このスクリプトを維持運用するのは非常に高度なスキルを有する必要がありそうですね。
GitHub: TLS Inspection Automation
https://github.com/nathanmcnulty/nathanmcnulty/blob/main/Entra/global-secure-access/README.md#tls-inspection-automation
まとめ
本記事では、Microsoft Entra Global Secure Access（GSA）における TLS インスペクションの構成手順を、前提条件の整理から証明書の生成・署名・展開、ポリシー作成、プロファイルへの割り当て、そして動作検証に至るまで、順序立てて解説しました。
TLS インスペクションは、単に暗号化トラフィックを可視化するだけでなく、以下のような 高度な保護機能の前提条件 となります。
- Web コンテンツ制限の精度向上
- 脅威インテリジェンスの強化
- ファイルベースの検査
- AI プロンプト検査（Prompt Shield）
特に、中間証明書の発行と PEM 形式への変換は理解が難しいポイントですが、本記事の手順に沿って構成すれば再現性高く実装できるようになっています。
最後に、TLS インスペクションは ポリシーを作成するだけでは有効にならず、必ずプロファイルに割り当てる必要がある点に注意が必要です。
また、動作検証では証明書の階層がどのように変化するかを確認することが重要です。
本記事が、GSA 環境における TLS インスペクションの導入・検証に取り組む方々の参考となれば幸いです。必要に応じて、例外設定や AD CS／Intune での証明書配布手順も併せてご活用ください。