Cloud Identity Engine (CIE) で実現するIDベースの統合セキュリティ【Part2: Azure AD連携】

はじめに

前回の記事「Cloud Identity Engine (CIE) で実現するIDベースの統合セキュリティ 【Part1: Okta連携】」では、IDベースの統合セキュリティの必要性と、それを実現するPalo Alto Networks社のクラウドネイティブサービスであるCloud Identity Engine (CIE) について説明しました。簡単に振り返ると、CIEをOktaやAzure ADなどの主要なIDプロバイダと連携することで、SASEやNext Generation Firewall (NGFW) とのID連携を簡易的に構成することができます。これにより、オンプレミスやリモートで生じるトラフィックを常にID単位で検証するセキュアなシステムを構築できます。Part 1では Oktaに登録されているID情報に基づき、NGFW経由でSingle Sign On (SSO)認証を行えること、またIDベースのアクセス制御が可能であることをご紹介しました。

今回のPart 2では、Oktaと同様、Azure ADでもCIEをブローカーとした認証連携が構成できることを示します。

Cloud Identity Engine (CIE)とは

改めてCloud Identity Engine (CIE) とは、Palo Alto Networks社がホストするクラウドネイティブなID同期・認証中継サービスです。Azure AD、Oktaなど主要なIDプロバイダと、認証装置であるSASEやNext Generation Firewall (NGFW) との間に入って、認証およびディレクトリ情報の受け渡しを行います。CIEにより、数多あるトラフィック制御ポイントとIDプロバイダの連携が簡素化され、ID管理負荷が軽減されます。また近年、データセンターの入口・出口対策による従来型のセキュリティから、SASEによるクラウドマネージド型の統合セキュリティに移行する企業が増えています。後者はZero trust network access (ZTNA) と表現されるなど、信頼を排除し全てのトラフィックを継続的に検証することが理想とされます。ここでゼロトラストに不可欠な要素であるIDをCIE経由で補完することにより、IDベースの統合セキュリティが実現します。詳しくは前回のブログを併せてご参照ください。

NGFW + CIE + Azure ADで動作確認

ここからは具体的なイメージを示すため、NGFW、CIE、Azure ADをそれぞれ連携してみます。その後、NGFWで受けた認証要求をCIEが中継し、Azure ADのSAML認証に受け渡せることを確認します。構成は以下の通りです。

設定手順

これをセットアップする手順は以下の通りです：

・SAML連携　(CIE + Azure AD)
・Authentication Portal設定 （NGFW）
・テスト (NGFW + CIE + Azure AD)

上記の設定イメージを抜粋していきます。

SAML連携　(CIE + Azure AD)

まずはCloud Identity Engine (CIE) のCloud Authentication Service機能を利用し、既存のAzure ADとSAML 2.0ベースでの認証連携を行います。

CIEとAzure ADを連携するためには、CIE側でAzure ADをIdentityプロバイダとして登録します。またAzure AD側ではCIEをSAMLサービスプロバイダに登録します。互いの情報を交換するために必要なメタデータをファイル形式でダウンロードおよびアップロードする機能が備わっており、これを利用すると複雑なURL入力や証明書の登録が一括で行えます。

Azure ADには連携専用のエンタープライズアプリケーションが用意されています。Azureにて認証するユーザが登録されたDirectoryにスイッチし、ADギャラリーよりPalo Alto Networks Cloud Identity Engine - Cloud Authentication Serviceを追加・設定することで、簡単にCIEをAzure ADとリンクするアプリケーションとして構成できます。

Authentication Portal設定 （NGFW）

NGFWでWebトラフィックを認証するためのAuthentication Portalポリシーを作成します。

Authentication Enforcement欄には先ほど作成したAuthentication Profileが紐づけられたオブジェクトを指定します。

上記は事前に認証を要する通信を指定する設定ですが、FW配下のクライアントからのアクセスを許可するポリシーは別途必要です。また、HTTPSサイトが対象に含まれる場合はSSL復号化ポリシーを併せて設定します。

尚、認証時にユーザ端末（プリンシパル）とCAS/IdP間で発生する通信は、Authenticationポリシーから除外する必要があります。今回はCIEのURLである *.apps.paloaltonetworks.com や *.microsoftonline.comなど、除外が必要となるURL/FQDNを含むURLグループを作成し、それを紐づけた認証除外のポリシーを作成しています。

テスト (NGFW + CIE + Azure AD)

ではテストしてみましょう。NGFW配下のクライアントよりOffice 365サイト宛にアクセスを試みます。NGFWのAuthentication Policyに従い、認証要求がCloud Identity Engine経由でAzure ADにリダイレクトされます。ユーザは自身のアカウントでログインし、必要に応じてスマートフォンアプリなどの多要素認証デバイスにて追加の認証を行います。認証が成功すると、目的のサイトへ自動でリダイレクトされます。

尚、今回は認証時にフェデレーションを行い、Authentication Policyで認証を受けたユーザにてOffice 365にログイン済みの状態でアクセスしています。

このように、多要素認証やNGFW検査によりセキュリティを高めつつ、フェデレーションによるSSOでSaaS利用時の利便性を向上させることも可能です。

NGFW上ではAzure ADで認証を受けたユーザの情報がアクセスログに記録されていることが確認できました。IPアドレスではなく、ユーザ単位でアクセス状況が可視化されますので、アクセス元のロケーションに依存しない制御・管理が可能です。

テスト結果

NGFW + CIE + Azure ADの連携設定から認証、ポリシーの適用まで、想定通りの動作が確認できました。前回のOktaと同様、Azure ADにもCIEと連携可能なアプリが用意されており、WebUIベースで直感的にセットアップすることができました。CIEと連携したIdPは、NGFWやPrisma Accessなど複数の制御デバイスで利用でき、単一デバイス上で複数のIdP連携を併用することも可能です。またフェデレーションを活用することで、SaaSアクセスの認証頻度を下げ、かつ全てのアクセス先をユーザ情報が紐づいた形でロギングできますので、可視性が向上します。

おわりに

今回の「Cloud Identity Engine (CIE) で実現するIDベースの統合セキュリティ【Part2: Azure AD連携】」では、Part1のOktaと同様、Azure ADでもCIEを仲介したSAML連携が簡単に設定できることをご覧いただきました。今後、Palo Alto Networks社ではCIEに統合可能なIdPを拡張すると共に、認証連携・ディレクトリ連携機能の更なる向上が予定されています。リモートワークやクラウド利活用において不可欠な認証・ユーザID連携を、セキュアかつ一貫性を持って実装するソリューションの一つとして、ご注目頂ければ幸いです。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。