[認証・認可] ゼロトラスト：Entra ID連携

クラウドサービスの利用拡大や働く場所の多様化により、社内ネットワークと社外ネットワークの境界だけでセキュリティを確保することは難しくなっています。そこで重要になるのが、接続元を一律に信頼せず、ユーザーやデバイスの状態を確認したうえでアクセスを許可する「ゼロトラスト」の考え方です。

株式会社エヌアイデイでは、認証基盤移行プロジェクトで採用するMicrosoft Entra IDと、一般的なSASEソリューションの一つであるPrisma Access、Cloud Identity Engineを使用し、認証連携とアクセス制御方式の技術検証を実施しました。

本検証の目的は、各サービス間の連携方式を確認するとともに、設定や運用における課題を見つけ、将来のソリューション提案や案件対応に技術的な知見を蓄積することです。検証は2024年9月から12月にかけて、社内の若手メンバー（当時1年目～３年目）が実施しました。

※本記事はスライドの記載内容をもとに、検証の要点を簡潔にまとめています。詳細な検証内容や技術的な説明は埋め込みのスライド本文をご参照ください。

今回の検証では、主に以下の3点を確認する計画としました。

1. Entra ID、Cloud Identity Engine、GlobalProtect間で認証連携設定をおこない、GlobalProtectからEntra IDによるログインができること
2. Microsoft Entra ID P2ライセンスを利用したリスクベース認証の挙動
3. GlobalProtectのアプリケーション設定やトンネル設定、Prisma Accessのセキュリティポリシールールを設定した場合のアクセス時の挙動

単にログインできるかを確認するだけでなく、将来的にはEntra IDで管理する認証・認可情報をPrisma Access側のアクセス制御へどのように活用できるかを把握することも目的としました。

Microsoft Entra IDは、Microsoftが提供するクラウドベースのID管理およびアクセス管理サービスです。AzureやMicrosoft 365に加え、オンプレミス環境やマルチクラウド環境との連携にも対応しています。

今回の検証ではMicrosoft Entra ID P2ライセンスを使用しました。P2ライセンスでは、Microsoft Entra ID Protectionによって疑わしいアクティビティにリスクフラグを設定し、危険なユーザーやサインインなどを可視化できます。また、リスクベースの条件付きアクセスポリシーを利用できます。

Prisma Accessは、Palo Alto Networksが提供するクラウド型セキュリティサービスであり、クラウド上で次世代ファイアウォール機能やセキュアアクセス機能を提供します。複数のセキュリティ機能を単一の統合ソリューションに集約し、ゼロトラストネットワークアクセスセキュリティを実現します。

接続形態にはService Connection、Remote Network、Mobile Userの3種類があります。今回は、リモート端末から接続し、Entra IDなどのサードパーティ製IdPとユーザー認証を連携できるMobile Userを使用しました。

Cloud Identity Engineは、クラウド上のIdPやディレクトリと連携し、Palo Alto Networks製品に対してユーザー・グループ情報および認証機能を提供するクラウドサービスです。各IdPとクラウド上で連携して認証情報やグループ情報を取得し、Prisma Accessを含むPalo Alto Networks製品の認証管理を一元化します。

Prisma AccessとEntra IDを直接連携することも可能ですが、今回の検証では認証管理を一元化するため、両サービスの間にCloud Identity Engineを配置しました。

GlobalProtectは、Mobile User接続をおこなうためにリモート端末へインストールするアプリケーションです。GlobalProtect Portalからアプリケーション設定や接続先ゲートウェイの情報を取得し、GlobalProtect Gatewayを経由して通信します。

今回の検証では、Entra IDをIdP、Cloud Identity EngineをEntra IDに対するSPとして構成しました。また、GlobalProtectとの関係ではCloud Identity EngineがIdP、GlobalProtectがSPとなる構成を採用しました。

認証連携にはSAML 2.0を使用しています。SAML 2.0では、SPとIdPの間に信頼関係を構築するため、それぞれの識別子や認証情報の送信先となるURLなどを事前に登録する必要があります。

具体的には、Entity ID、Single Sign On URL、Assertion Consumer Service URL、X.509証明書、NameIDなどを設定し、Entra IDとCloud Identity Engineの間で相互にメタデータを登録しました。

認証の流れは次のとおりです。

1. GlobalProtectからGlobalProtect Portalへ認証を要求
2. Cloud Identity Engineへリダイレクト
3. Webブラウザを介してEntra IDへリダイレクト
4. Entra IDでユーザー認証
5. GlobalProtect Portalからアプリケーション設定と接続先のGlobalProtect Gatewayを取得
6. GlobalProtect GatewayへVPN接続

環境構築では、Prisma AccessとCloud Identity Engineをアクティベートしたうえで、Strata Cloud ManagerからPrisma AccessおよびGlobalProtectのインフラストラクチャを設定しました。そのあと、Entra ID側でユーザーとエンタープライズアプリケーションを作成し、Cloud Identity EngineとのSAML認証設定をおこないました。

さらに、Cloud Identity EngineでAuthentication Profileを作成し、そのプロファイルをGlobalProtectのユーザー認証方式として設定しました。最後にBYOD端末へGlobalProtectをインストールし、Entra IDによるログインとVPN接続を確認しました。

※詳細な検証方法はスライド本文をご参照ください

検証の結果、Entra ID、Cloud Identity Engine、GlobalProtect間の認証連携に成功し、GlobalProtectからEntra IDによるログインができることを確認しました。

GlobalProtectからログインを試行すると、既定のWebブラウザでEntra IDのログイン画面へリダイレクトされます。認証完了後はGlobalProtectによるVPN接続がおこなわれ、端末にはMobile User用に設定したプライベートIPアドレスが割り当てられました。また、最寄りのGlobalProtect GatewayであるJapan Centralに接続されることも確認しました。

一方、Entra ID P2ライセンスを使用したリスクベース認証については、設定画面の確認に留まり、挙動の検証までは実施できませんでした。

また、GlobalProtectのアプリケーション設定やトンネル設定、Prisma Accessのセキュリティポリシールールによるアクセス制御についても、試用ライセンスの期限などにより検証には至りませんでした。今回確認できた範囲は、各サービスを連携し、Entra IDの認証情報を使用してGlobalProtectへログインできることまでとなります。

Entra IDの契約準備を開始してから、実際に環境を使用できる状態になるまでには1ヵ月半を要しました。

AzureアカウントとEntra IDテナントは別の概念であり、Microsoft 365管理センター、Azure Portal、Microsoft Entra管理センターもそれぞれ役割が異なります。加えて、Entra ID P2ライセンスの調達スケジュールとPalo Alto Networks製品の試用期間にずれが生じたため、試用期間を複数回延長する必要がありました。

検証や案件の計画を立てる際は、設定作業だけでなく、契約、ライセンス調達、テナント準備などに要する期間もあらかじめ考慮する必要があります。

Strata Cloud Managerでは、設定を保存しただけでは環境に反映されず、「プッシュ」を実行する必要があります。

また、Admin Scopeが適切でない場合や、複数リージョンに同じMobile User用IPアドレスプールを設定した場合には、プッシュが失敗しました。エラーの詳細を確認し、Admin Scopeを「All Admins」に変更することや、重複するIPアドレス設定を削除することで解決しています。

Entra IDでアプリケーション連携を設定するには、クラウドアプリケーション管理者などの権限が必要です。

今回の検証ではグローバル管理者権限を付与して設定作業をおこないましたが、実際の開発や運用では、作業に必要な管理者権限を調査し、必要最小限の権限を付与する設計が求められます。なお、Azureリソースを管理する場合は、Entra IDの管理者権限とは別にサブスクリプションの管理権限が必要です。

今回の検証では、Azureアカウント作成時のテナントと、Entra ID P2ライセンス契約時のテナントを混同し、サインインテストに失敗する場面がありました。

また、Cloud Identity EngineのAuthentication ProfileがGlobalProtect側に表示されない事象も発生しました。これは評価用のTenant Service Groupとのスコープの違いが原因として想定され、Cloud Identity EngineのScope TypeをCSPからTSGへ変更することで解決しました。

複数のテナントや管理スコープを扱う環境では、現在どのテナントとスコープで作業しているかを明確にすることが重要です。

条件付きアクセスポリシーやリスクベース認証を事前テストなしで有効化すると、管理者アカウントでログインできなくなり、設定変更ができなくなる可能性があります。

実際にポリシーを有効化する前に「レポート専用」を設定し、実設定を変更せずに対象ユーザーやサインインへの影響を確認することが望まれます。

今回の検証では、Microsoft Entra ID、Cloud Identity Engine、GlobalProtectをSAML 2.0で連携し、Entra IDによるユーザー認証からGlobalProtectのVPN接続までを確認できました。

一方で、Entra IDの認可情報をPalo Alto Networks製品へ渡した場合のアクセス制御や、条件付きアクセスポリシー、リスクベース認証、GlobalProtectのトンネル設定、HIP情報を含むセキュリティポリシーについては、今後の検証課題として残っています。

また、技術面だけでなく、ライセンス調達期間、試用期限、管理者権限、テナントや設定スコープの違いを含めて全体計画を策定することの重要性も確認できました。限られた検証期間で成果を得るには、事前調査を一定の段階で区切り、実案件のユーザー要望を想定したシナリオとテスト項目を早期に定める必要があります。

今後は、Prisma AccessおよびGlobalProtectの各種ポリシー設定による挙動を比較するとともに、Entra IDで管理される認証・認可情報を活用し、ユーザーや端末の状態に応じてどのようなアクセス制御を実現できるか、さらに技術検証を進めていきます。

エヌアイデイでは、引き続き技術検証を通じて知見の蓄積をおこない、認証連携とアクセス制御方式における提案力向上につなげていきます。

※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。