AuthZENとShared Signals & CAEPの補完関係とは
ほとんどのサイバー攻撃は、IDを利用する。この標準仕様は、このような攻撃に対する最善の防御策である
共著:
SGNL CTO ,Shared Signals Working Group共同議長
OpenID Foundation Corporate Board Member
Atul Tulshibagwale氏
Aserto co-founder & CEO
AuthZEN Working Group共同議長
Omri Gazitt氏
最近では、ほとんどのサイバー攻撃が従業員のIDを侵害し、組織に侵入しています。これらの攻撃から身を守るには、すべてのクラウドサービスが各セッションに関する最新情報を持っていることが重要です。即時情報共有により、正当なユーザーへのアクセスを許可すると同時に、正当なユーザーになりすまそうとする攻撃者をブロックできます。CAEP、SSF、AuthZENは、これを達成するのに役立つ標準仕様です。
ここではその方法について解説します。
先日ロンドンで開催されたGartner IAM Summitで、OpenID Foundationは2つの相互運用性を実証するイベントを開催しました。1つはCAEPとSSF、もう1つはAuthZENです。そのカンファレンスの参加者や、相互運用性のデモを見に来た人々からでた質問に「CAEPとAuthZENは互いに競合しているのか」というものがありました。
簡単な答えはノーです、これらは動的に認可を決定するため、補完的に機能します。
CAEPとAuthZENとは?
Continuous Access Evaluation Protocol / Profile (CAEP)
CAEPは、「Continuous Access Evaluation Protocol」(または、仕様だけを指す場合は「Continuous Access Evaluation Profile」)の略で、ログインしたセッションの状態に影響を与えるイベントを伝達する技術です。
また、Shared Signals Framework (SSF) は、非同期に強力で豊富なイベント情報を転送する機能を持ちます。送信者と受信者はSSFを使用してイベントのストリームを作成、一時停止、削除できる一方、CAEP仕様は「セッション無効化」「トークンクレーム変更」「デバイスコンプライアンス変更」などのイベントを定義しており、セッション状態の変化を伝達します。
SSF と Continuous Access Evaluation Profile は、Continuous Access Evaluation Protocol を形成します。SSFはCAEPに使用されるだけでなく、RISC(Risk Information Sharing and Coordination)を介したアカウントのセキュリティイベント（アカウントの削除や無効化など）の通信にも使用され、アカウントの更新を伝達するSCIMイベントの転送役としても使用できます。Shared Signalsは基本的な標準であり、CAEPやRISCが大規模に採用されているのと同様に、SSFの上にさまざまな特殊な目的のためにより多くのプロファイルが作成されることが予想されます。
次の図は、一般的な CAEP アーキテクチャを示しています。出典：SGNL)
AuthZEN
NIST は、SP 800-162でExternalized authorization model ("P*P" モデルと呼ばれることもあります) というものを定義しています。これを使用すればアプリケーションまたはサービスが決定していた認可を外部化できます。このアーキテクチャについては、次の図で説明します。（出典：Aserto）
上の図では、ユーザーがリソースを要求すると (矢印 1)、Policy Enforcement Point (PEP) として機能するアプリケーションが、アクセス可否の決定 (矢印 2) をPolicy Decision Point (PDP) に委任します。PDP は、Policy Administration Point (PAP) によってオフラインで管理されているポリシー (矢印 3) を参照します。Policy Information Point (PIP) は、PDP がアクセスを決定するために必要なデータを提供します。一部の PDP はステートフルであり、常に PIP に依存するのではなく、PDP 自体にデータを保持できます。PDP は、アクセスを決定するために、それ自体の状態 (内部 PIP と考えることができます) を参照するか、外部 PIP を参照します。
AuthZENワーキンググループ憲章は、これらすべてのさまざまなコンポーネント間の通信を標準化することであり、最初はPEPとPDP間のAPIの標準化に焦点を当てています。
これらは互いにどのように連携しているか
CAEPとAuthZENの関係を理解するために、これを現代のゼロトラストクラウドアーキテクチャに合わせたより広い文脈で考えてみましょう。現代の企業は、インフラストラクチャ、マネージドサービス、セキュリティ、デバイスおよびID管理、エンドユーザーアプリケーションなど、さまざまなサービスを提供する数十(場合によっては数百)のクラウドサービスに依存しています。
ユーザーがクラウドベースのサービス内の特定のリソースにアクセスする場合、サービスはそのアクセスを許可するかどうかを決定する必要があります。"P*P" パターンに従って、サービスは PDP を呼び出してそれを決定します。PDPは、決定を下すために配下の利用可能なデータを参照します。これらの対話はすべて、アプリケーション要求のクリティカルパスにあり、待機時間を最小限に抑える必要があるため、ローカルである必要があります。実際、ユーザーがロードするWebページごとに、何百ものリソースがアクセスされる可能性があり、それぞれが独自のアクセス決定を必要とします。
PDPは即座に決定を下す必要がありますが、ローカルで利用可能な情報が古くなっている可能性があります。これには、ユーザーが管理対象デバイスからサービスにアクセスしているかどうか、ユーザーのセッションがまだ有効かどうか、ユーザーが現在、要求されたリソースにアクセスすることの業務上の必要性があるかどうかなどのセッションの状態が含まれます。これらの情報はそれぞれ異なるクラウドサービスにある可能性があるため、ユーザーが要求されたリソースにアクセスしようとしているときにこれらすべてを取得すると、クラウドサービスのレイテンシーと可用性に深刻な影響が及びます。
PDPは即座に決定を下す必要がありますが、ローカルで利用可能な情報が古くなっている可能性があります。これには、ユーザーが管理対象デバイスからサービスにアクセスしているかどうか、ユーザーのセッションがまだ有効かどうか、ユーザーが現在、要求されたリソースにアクセスするビジネス ニーズがあるかどうかなどのセッションの状態が含まれます。これらの情報はそれぞれ異なるクラウドサービスにある可能性があるため、ユーザーが要求されたリソースにアクセスしようとしているときにこれらすべてを取得すると、クラウドサービスのレイテンシーと可用性に深刻な影響が及びます。
そこで登場するのがCAEPです。CAEP を使用すると、アクセスの決定に必要な情報を考慮に入れる必要がある任意のクラウドサービスに、必要な情報を非同期的に配信できます。アクセス決定自体は、PEP と PDP の間で AuthZEN を使用できます。SSF は、誰がどの情報を購読でき、どの主体について登録できるかを決定するための堅牢なフレームワークを提供します。CAEP は、アクセスの決定に影響を与える可能性のあるセッション状態の情報を提供します。
AuthZENと共有シグナルフレームワーク
ステートフル PDP への非同期イベント配信のパターンは、セッションシグナルに限定されません。たとえば、ユーザーとグループのSource of truthは、通常、ID プロバイダー (IdP) または Active Directory などの企業のディレクトリです。ユーザー属性とグループメンバーシップは、認可の決定を通知するデータとして一般的に使用されます。実際、多くのステートフルPDPはこの情報をキャッシュします。
ユーザーが追加されたり、グループメンバーシップが変更されたりした場合は、PDP に通知し、状態を更新する必要があります。SCIM イベントは、この機能を SSF の上に実装する方法を提供します。
さらに、リソースの所有権と共有に関して、サービスは通常この情報を追跡しますが、ユーザー/グループとリソース間のアクセス制御関係が変更されたことをPDPに通知する方法が必要です。
AuthZENワーキンググループは、2025年後半にこれらのユースケースに取り組む予定であり、SSFを基盤として使用する予定です。
認可アーキテクチャについてもう少し知る
継続的セキュリティパラダイム(CSP)
この同期ローカルな決定と必要な情報の非同期通信の相互作用については、SSWGの共同議長であるAtul Tulshibagwale氏とSean O'Dell氏がIDProブログで公開した記事「Continuous Security Paradigm」でもう少し詳しく説明しています。
トランザクショントークン(TraT)
アプリケーション、またはクラウドサービス自体は、数十または数百のマイクロサービスで構成されている場合があります。ユーザーが特定のトランザクションをリクエストするような外部からの呼び出しがあると、それに応じて複数のマイクロサービスが連鎖的に呼び出されます。各マイクロサービスは、アプリケーションの Virtual Private Cloud (VPC) 内から呼び出すことができる内部 API を提供します。現在、アプリケーションは、ユーザーによる外部呼び出しについてPDPから決定を取得できますが、各マイクロサービスからそれを行うのはPDPにとって圧倒される可能性があります。これは、UI でのエンド ユーザーが行う操作ごとに、アプリケーションへの呼び出しが数百回発生し、各呼び出しが複数のマイクロサービスに触れる可能性があるためです。したがって、各マイクロサービスが PDP を呼び出す場合、PDP はユーザー要求ごとに何千ものクエリに応答する必要がある可能性があります。
一方、攻撃者がアプリケーションのVPC内に潜み、痕跡を残さずに甚大な損害を引き起こしている壊滅的な侵害が発生している可能性を考えると、VPCが改ざんから安全であるとは仮定できません。また、権限を与えられた内部関係者がアクセスを悪用して内部APIを呼び出すことができる内部犯行もあります。また、ソフトウェアのサプライチェーンが侵害され、正当なサービスが内部に損害を与える可能性があります
トランザクショントークンは、IETFで進められる今後の標準仕様であり、これらの懸念事項すべてに対処し、各マイクロサービスがPDPを呼び出す必要はありません。これは、アプリケーションがPDPから受信した決定を暗号で署名されたエフェメラルトークンにバインドするのに役立ち、PDPによって発行された決定をTraTにキャプチャし、コールチェーン内のすべてのマイクロサービスに渡すことができます。これにより、PDPの決定が誤ってまたは悪意を持って内部で変更され、外部ユーザーの意図を誤って伝えることがなくなります。
まとめ
この投稿では、認証のさまざまな側面を取り上げようとしました。これらの各分野でやるべきことはたくさんありますが、幸いなことに、私たちは現在、テクノロジースペースとして成熟しており、CSPで提案され、Shared Signals、CAEP、AuthZEN、TraTsなどの標準を使用して実装されたパターンは、ゼロトラストクラウドアーキテクチャの保護に大いに役立つ可能性があります。