Microsoft Entra Internet Accessのトランスポート層セキュリティ (TLS) 検査を使用すると、サービス エッジの場所で暗号化されたトラフィックを復号化して検査できます。 この機能により、グローバル セキュア アクセス (GSA) は、脅威の検出、より詳細な Web コンテンツ フィルタリング、その他のコンテンツ コントロールなどの高度なセキュリティ制御を適用できます。 TLS 検査を使用すると、GSA は、Web コンテンツのフィルター処理のためにユーザーがブロックされた場合など、ユーザーフレンドリなカスタム エラー メッセージを提供することもできます。
このチュートリアルでは、以下の内容を学習します。
- TLS 検査用の TLS 終了証明書を作成します。
- TLS 検査ポリシーを作成して構成します。
- TLS 検査ポリシーをセキュリティ プロファイルにリンクします。
- Microsoft Entra Conditional Accessを使用してセキュリティ プロファイルを割り当てます。
- クライアントで TLS 検査を確認します。
主な概念
TLS 検査が必要な理由
現在、95% を超える Web トラフィックが HTTPS/TLS で暗号化されています。 TLS 検査を使用しない場合、セキュリティ ツールでは次の情報のみを確認できます。
- 送信先 IP アドレス。
- TLS ハンドシェイクからの完全修飾ドメイン名 (FQDN) であるサーバー名表示 (SNI)。
TLS 検査を有効にすると、セキュリティ ツールで次の情報を確認できます。
- 完全な URL パス (
/imagesや/downloads/malware.exeなど)。 - 要求と応答の内容。
- ファイルのアップロードとダウンロード。
- カテゴリ化のための Web ページコンテンツ。
TLS 検査のしくみ
トラフィックのフローを次に示します。
- クライアントは、セキュリティ サービス エッジ (SSE) への TLS 接続を確立します。
- SSE は、宛先への個別の TLS 接続を確立します。
- SSE はトラフィックの復号化、検査、再暗号化を行います。
- クライアントには、エンタープライズ証明機関 (CA) によって署名された証明書が表示されます。
- ポリシーで許可されている場合、SSE はトラフィックを元の宛先サーバーに転送します。
User → GSA Client → SSE Proxy → Destination Server
│
[TLS Terminated]
[Content Inspected]
[Re-encrypted with Enterprise CA cert]
[Forwarded to destination]
目標
このチュートリアルでは、TLS 検査ポリシーを作成して有効にします。 システム生成のバイパス 規則は既定値のままにします。 次に、TLS 検査が想定どおりに行われていることを確認します。
サンプルチュートリアルビデオ
次のビデオでは、TLS 検査を構成する方法を示します。
次のビデオでは、より多くの TLS 検査構成を示します。
次のビデオでは、TLS 検査を確認する方法を示します。
手順 1: TLS 終了 CA 証明書を作成する
TLS 終了 CA 証明書の作成には、証明書署名要求 (CSR) の生成、署名、署名された証明書のアップロードが含まれます。 TLS 終了 CA 証明書は、アクセスする Web サイトの有効期間が短いリーフ証明書を発行するために使用されます。
手順 1.1: CSR を生成する
CSR を作成し、TLS 終了用の署名付き証明書をアップロードするには:
Microsoft Entra 管理センターに、Global Secure Access 管理者としてサインインします。
グローバル セキュア アクセス>>を参照します。
TLS 検査設定タブに切り替えます。
[ + 証明書の作成] を選択します。 この手順は、CSR の生成から始まります。
[ 証明書の作成 ] ウィンドウで、次のフィールドに入力します。
- 証明書名: 証明書名は、ブラウザーで表示するときに証明書階層に表示されます。 一意で、スペースを含めず、長さは 12 文字以下にする必要があります。 以前の名前を再利用することはできません。
-
共通名: 中間証明書を識別する共通名 (
Contoso TLS ICAなど)。 -
組織名: 組織名 (例:
Contoso IT)。
[ CSR の作成] を選択します。 この手順では、
.csrファイルを作成し、既定のダウンロード フォルダーに保存します。
手順 1.2: CSR に署名する
自己署名証明書または秘密キー基盤 (PKI) サービスを使用して CSR に署名します。
オプション 1:OpenSSL を使用したパブリック ドキュメントの手順
OpenSSL の使用方法に慣れていない場合は、スタックした場合にサンプルのチュートリアル ビデオを参照してください。
Microsoft以外のサイトからOpenSSL for Windowsをダウンロードできます。 使用する前に、ダウンロードしたバイナリの整合性を確認します。
Option 2: Active Directory Certificate Services を使用した PowerShell スクリプトのサンプル
提供されたサンプルを使用せずに独自の証明書を作成する場合は、 サーバー認証 が拡張キー使用法にあり、 certificate authority (CA)=true、 keyCertSign、 cRLSign、および basicConstraints=critical,CA:TRUE が Basic Extension にあることを確認します。 署名された証明書を .pem 形式で保存します。
手順 1.3: TLS 終了用の署名付き証明書をアップロードする
証明書とチェーン .pem ファイルを取得したら、TLS 終了用の署名付き証明書をアップロードします。
[ + 証明書のアップロード] を選択します。
[ 証明書のアップロード ] フォームで、
signedcertificate.pemファイルとrootCAchain.pemファイルをアップロードします。[ 署名付き証明書のアップロード] を選択します。
証明書の横にある [ アクション] 列の下にある省略記号 (3 つのドット) を選択し、[ 有効] を選択します。
証明書を有効にすると、状態が [登録 ] から [アクティブ] に変わります。 この手順には数分かかる場合があります。
手順 2: TLS 検査ポリシーを作成する
TLS 検査ポリシーを作成するには:
Microsoft Entra admin centerで、Secure>TLS 検査ポリシーに移動します。
[ポリシーの作成] を選択します。
名前と説明 (省略可能) を入力し、[検査] に [アクション] を設定します。
次へを選択します。
既定のアクションを [検査] に設定すると、ユーザーまたはシステムによって生成されるバイパス規則と一致しない限り、すべてのトラフィックが TLS 検査されます。 TLS 検査ポリシーを作成すると、システムによって 2 つの規則が自動的に生成されます。 1つ目のルールは、Microsoftが互換性がないことを知っているTLS検査を自動的にバイパスするシステムルールです。 2 番目の規則は、ユーザーが機密性の高い、またはプライベートと見なす可能性がある特定のカテゴリの TLS 検査をバイパスする推奨バイパス リストです。 このルールは後で編集できます。
TLS 検査ポリシーを作成した 後 に、ポリシーで [編集] を選択すると、システムによって生成されたルールを表示できます。
次へを選択します。
送信を選択します。
手順 3: TLS 検査ポリシーをセキュリティ プロファイルにリンクする
- [グローバル セキュア アクセス]>[セキュア]>[セキュリティ プロファイル] に移動します。
- [ プロファイルの作成] を選択します。
- ポリシーの名前と説明を入力し、[ 次へ] を選択します。
- [ ポリシーのリンク] を選択し、[ 既存の TLS 検査ポリシー] を選択します。
- 作成した TLS 検査ポリシーを選択し、[追加] を選択 します。
- 次へを選択します。
- [ プロファイルの作成] を選択します。
手順 4: 条件付きアクセスを使用してセキュリティ プロファイルを割り当てる
- Entra ID>Conditional Access に移動します。
- [新しいポリシーの作成] を選択します。
- 名前を入力し、ユーザーまたはグループを割り当てます。
- [ ターゲット リソース] を選択し、[ グローバル セキュリティで保護されたアクセスを使用するすべてのインターネット リソース] を選択します。
- [ セッション>グローバル セキュア アクセス セキュリティ プロファイルを使用 して、手順 3 で作成したセキュリティ プロファイルを選択します。
- [選択]
- [ ポリシーの有効化] セクションで、[ オン] が選択されていることを確認します。
- を選択してを作成します。
条件付きアクセスによってセキュリティ プロファイルが割り当てられた後、セキュリティ プロファイルが有効になるまでに最大 1 時間かかる場合があります。
手順 5: クライアントで TLS 検査を確認する
TLS 検査が正しく行われていることを確認するには、次の手順を実行します。
ユーザー デバイスに、
rootCAchain.pemフォルダーに ファイルがインストールされていることを確認します。- Windows 11で、Manage ユーザー証明書 を開きます。
- [信頼されたルート証明機関] を選択し、[証明書] を右クリックします。
- [ インポート] を選択します ( [すべてのタスク] の下にある場合があります)。
- インポート ウィザードに従って、
rootCAchain.pemファイルを選択してインポートします。
クライアント デバイスでブラウザーを開き、
www.google.comなど、さまざまな Web サイトをテストします。 証明書情報を検査し、GSA 証明書を確認します。注
Microsoftトラフィックは、インターネット アクセス トンネルをバイパスします。つまり、TLS 検査はほとんどのMicrosoft アプリケーションに適用されません。 TLS 検査が正しく構成されていることを確認する前に、Microsoft以外の Web サイトを参照してください。
Microsoft Edge ブラウザーで証明書を確認するには:
Web URL の横にあるロック アイコンを選択します。
接続は安全です を選択します。
証明書アイコンを選択します。
共通名が Microsoft Global Secure Access Intermediate であることを確認します。
学習した内容
この演習では、次のタスクを実行しました。
- 証明書階層を作成しました。 CSR を生成し、ルート CA で署名し、両方の証明書を GSA にアップロードしました。 TLS 検査に必要な信頼チェーンを確立しました。
- バイパス規則を理解しました。 証明書のピン留めや相互 TLS など、一部の宛先が TLS 検査と互換性がない、または銀行や医療などのプライバシーに敏感であることを学習しました。 既定では、一部の宛先は自動的にバイパスされます。
- 条件付きアクセスを使用してセキュリティ プロファイルを作成しました。 このセキュリティ プロファイルは、ベースライン プロファイル (すべてのユーザーに適用) とは異なり、条件付きアクセスを使用して特定のユーザーをターゲットにして段階的なロールアウトを許可することを学習しました。
- ルート CA 証明書を配布しました。 クライアントが再暗号化されたトラフィックを信頼するには、信頼されたストアにルート CA 証明書が必要であることを学習しました。
徹底分析: 証明書チェーン
┌─────────────────────────────┐
│ Your root CA │ ← Deployed to client trusted store
│ (rootCAchain.pem) │
└─────────────┬───────────────┘
│
▼ Signs
┌─────────────────────────────┐
│ GSA intermediate CA │ ← Uploaded to GSA (signed certificate)
│ (signedcertificate.pem) │
└─────────────┬───────────────┘
│
▼ Signs (dynamically)
┌─────────────────────────────┐
│ Leaf certificates │ ← Generated on-the-fly for each site
│ (www.google.com, etc.) │
└─────────────────────────────┘
セキュリティの考慮事項
- 攻撃者が侵害された場合に証明書を偽造する可能性があるため、ルート CA 秘密キーを保護します。
- 運用 PKI (一般的な業界ガイダンス) ではなく、TLS 検査に専用 CA を使用することを検討してください。
- 機密性の高いサイトが確実に保護されるように、バイパス 規則を定期的に監査します。
次は何ですか
TLS 検査を有効にすると、(完全修飾ドメイン名だけでなく) URL ベースのフィルター規則を作成できるようになりました。 カスタム ブロック メッセージをユーザーに提供することもできます。