火のついたジャグリングを簡単に操るように:SCIMによるプロビジョニング

Mike Kiser、Jen Schreiber

CAEPイベントを通じて通信を管理するというShared Signals Frameworkの直接的な用途のほかにも、長期的なアイデンティティの課題に対処するための有力な道筋を提供します。その一つの課題が、アイデンティティライフサイクル管理、つまりプロビジョニングとデプロビジョニングです。

プロビジョニングの課題

多くの人はプロビジョニングの課題を過小評価しています。プロビジョニングについて考えたことがない人にとっては、外部から見ると比較的シンプルに見えるかもしれません。それは、才能ある大道芸人が、例えばロンドンのような国際的な街でジャグリングをしている姿を見るのに似ています。この例を挙げた理由は特にありませんが、最近その素晴らしい街で行われた相互運用性の実証イベントを念頭に置いています。

大道芸人のジャグリングは、最初は比較的簡単なものに始まります。いくつかのボールが空中に飛んで、パフォーマーの手の間を行き来するだけ。物体が行ったり来たりする様子は簡単でスムーズに見えます。

そして、プロビジョニングも確かにそれに似ています。たとえば、HR（人事システム）がローカルの従業員ディレクトリに同期する場合のように、比較的似たスキーマや利用ケースを持つ2つの独立したシステム間であれば簡単です。

しかし、大道芸人を見続けてください...事態は急速に複雑化します。そのうちに、2つのオブジェクトではなく、6つまたは8つのオブジェクトがあります。ボールは棒と交換され、棒に火がつけられます。そうなると、物事はそれほど単純でも簡単でもありませんよね?

実際のプロビジョニングの世界も、ほぼ同じようにエスカレートします。システムの数が増えるにつれて、維持しなければならない接続関係も増えます。これはすぐに解決困難な問題になります(火をつけなくても)。

ID のライフサイクル管理の課題に対処するために、System for Cross-Domain Identity Management (SCIM) が作成されました。SCIMはIDリポジトリの接続にある程度の成功を収めていますが、イベントベースのアーキテクチャの台頭は、SCIMがトランザクションや一括更新から、相互接続されたシステムがIDコンテキストとデータをほぼリアルタイムで共有できるようにするイベントベースの非同期アプローチに移行する必要性を示しています。

 セキュリティイベントトークンのSCIMプロファイルは、イベントベースのアーキテクチャでSCIMの連携を可能にすることを目指しています。

標準を活用する

SCIM イベントでは、CAEP イベントや Risk Incident Sharing and Coordination (RISC) イベントと同じ形式のセキュリティイベントトークンを使用して、この目標を達成するために既存の標準を使用します。SCIM イベントでは、トランスポート層として Shared Signals Framework を使用する場合がありますが、必須ではないことに注意してください。ジャグラーは、空中や水中で物体を投げているかもしれませんし、クラブ、リング、またはボールを投げているかもしれません。そのすべてが楽しいのです。

SCIM イベントは、HTTP、Kafka や Kinesis などのストリーミングテクノロジ、Webhook、SSFを介したプッシュ/プルを介して転送できます。この仕様は特定の技術や方法に依存していません。とはいえ、Shared Signals Frameworkの人気で、推奨される方法になるかもしれません。

同期と通知:多様なアプローチ

イベントベースのアプローチを採用することで、SCIMは単なる更新情報の流通以上のことを可能にします。一部のシステムはイベントのストリームを処理する必要があり、またそれが可能な場合もありますし、他のシステムは変更の通知だけを受け取ることを好むかもしれません。

実際には、これによりそれぞれが関心のある変更だけをセキュアなバックチャネルを通じてリクエストでき、労力を節約しつつプライバシーを保護することが可能になります。他のシステムは非同期で処理を進め、新しい情報を独自のスケジュールで対応する必要があるかもしれません。この標準では、こうしたカスタマイズ可能なアプローチを可能にしており、多様なアーキテクチャに柔軟に対応できる仕組みとなっています。

リアルタイム SCIM イベントの利点

SCIMがリアルタイムプロビジョニングをサポートする機能は重要です。インテグレーションが行われ、リアルタイムの更新がエンタープライズシステム内で共有できるようになると、ゼロスタンディング特権(およびゼロトラスト)が現実に一歩近づきます。リアルタイムで変更を加えられるようになると、アクセスは永続的ではなくなり、ID で必要なときにプロビジョニングされ、不要になったら削除されます。

SCIMイベントは、プロビジョニングだけでなく、さまざまなソースからデータをリアルタイムで取り込むことで、システムが真のセキュリティの可能性を見つけることができると期待されています。組織が採用するアクセスポリシーには、最新のデータと属性が必要です。SCIMイベントからの入力とCAEPおよびRISCをリアルタイムの情報源として使用することで、ポリシーは可能な限り最新のものになります。

データ最小化によるプライバシーは、SCIMイベントの採用によって大きなメリットが得られます。データ収集を必要なものだけに制限することは、プライバシーアプローチの基本です。最小限の情報: SCIM イベントを使用すると、受信側は、受け入れることができる属性またはリソース ライフサイクルの変更を決定できます。または、送信機が受信ドメインを制限する場合です。取得するデータが少ないほど、組織のリスクは少なくなります。

システム内では、SCIM イベントを CAEP イベントと RISC イベントへの対応のために利用できます。これらのイベントがセッション終了されたことを中継すると、システムは基になる属性データとアカウント自体に反応して、将来の使用を防ぐことができます。

最後に、組織内で行われるすべてのことの監査可能な記録は、企業内のコンプライアンスとリスク検出を証明するために不可欠です。無効なセッションを排除したり、アクセスやエンタイトルメントを調整したりするだけでは不十分で、システム内で行われたすべてのアクションを記録して、システムが「独自のルールに従ってライフタイムマネジメント」を実施し、責任を果たしていることを確認する必要があります。したがって、SCIMイベントは、リアルタイムでのプロビジョニングだけでなく、監査とガバナンスも可能にします。

SCIM イベント: 論理的なステップ

SCIMイベントを採用することで、断片化されたデータストア、独自のインターフェース、アイデンティティへのばらばらなアプローチ(歴史的にジャグリングのような問題)など、プロビジョニングの長期的な問題への対処に近づくことができます。しかし、この新しいパラダイムに移行すると、ポリシーに基づく意思決定を強化するためのリアルタイムのコンテキストが得られるという、それ以上のことを達成できます。データを最小限に抑えるためのプライバシー強化アプローチを強化します。CAEPやRISCのイベントに対して、具体的な対応をします。そして、私たちは、必要なとき以外はアクセスできない世界という目標に近づいていることを証明する監査記録を使用して、それをすべて行っています。

つまり、SCIM Events は、プロビジョニングを単純に見えるタスクから、実際には単純なタスクに移行します。(著者たちは、もう1つの難解な問題、つまり5本の燃え盛るボウリングのピンを同時に空中に浮かせておくことについて、まだ取り組んでいます。

OpenID Foundation、Financial Data Exchange Summitでのプレゼンテーション

OpenID FoundationのGail Hodges氏とJoseph Heenan氏は、4月22日(火)にGaylord National Harborで開催されたFinancial Data ExchangeのSpring Global Summitで、北米の参加者のために「If, when, and why to implement the FDX 'blue' security profile with FAPI 2.0」と題した講演を行いました。この講演は、OpenID Foundationがリードしているオープンバンキングとオープンデータのための主要な通信プロトコルFAPI 2.0を含む「blue」プロファイルを含んでおり、今月提案されたどのRFCを承認するかを決定するメンバーにとって特にタイムリーでした。RFCが発効すると仮定すると、北米の実装者は、オープンバンキングの展開と米国とカナダの現地規制への準拠のために、この新しいFDXプロファイルの取り込みを検討することになります。

FDXが推奨するFAPI仕様

FAPI は長い間「FDX が推奨」してきましたが、この春、FDX Security and Authorization Work Groupが新しいRFC提案の一部として「blue」プロファイルにFAPI 2.0を全会一致で推奨したことは重要なマイルストーンとなりました。OpenID Foundationは、Financial Data Exchangeの新しいメンバーとして、この勇気付けられる進展を称賛し、このRFCが今月発効し、FDXとOpenID Foundationの共通のメンバーと貢献者の利益のために行われることを望んでいます。

OpenID Foundationは、FAPI 2.0が米国とカナダの実装者が規制遵守の義務を果たすのを支援し、デフォルトでセキュリティ、相互運用性、運用効率を提供する方法でそれを行う大きな可能性を見出しています。そしてどんなエンティティ(大小を問わず)も取り残しません。

ブラジル、アラブ首長国連邦、サウジアラビア、ノルウェー、オーストラリアなど、世界の他の地域の他のエコシステムはすでにFAPIの恩恵を受けており、北米の実装者がFDXとの関係を通じてFAPI 2.0を大規模に実装する見通しは有望に見えます。

エグゼクティブ・ディレクターのGail Hodges氏は、「データ仕様に関するFDXの専門知識は、安全性が高く相互運用可能な通信プロファイルに関するOpenID Foundationの専門知識を完全に補完するものであり、Financial Data Exchangeとの継続的な協力関係を高く評価しています」と述べています。

FDXメンバーとステークホルダーと共有されたキーメッセージ

Hodges氏とHeenan氏は火曜日の講演で一連の重要なポイントを発表しました。聴衆には北米の銀行、フィンテック企業、アグリゲーターのほか、市民社会や政府の代表者も含まれていました。最初のポイントはFAPI 2.0の主な利点の要約でした。

1. 接続性、セキュリティ、認可がデフォルトで提供されている
2. 実証済みの技術であるということが、多くの複雑なオープンデータエコシステムにおいて、関係者間の安全かつ相互運用可能なデータの移動を可能にする
3. 安全性が、シュトゥットガルト大学による正式な数学的セキュリティ分析によって証明されている
4. 6年の間、仕様開発に数十人が関わった最終版である
5. 実際の実装に対して何千もの「目」による監視され維持されており、OIDF（OpenID Foundation）コミュニティによる仕様とテストの継続的なメンテナンスが行われている

2つ目は、セキュリティ、認可、認証、相互運用性、および適合性に完全に対処し、規定するFAPIの包括的な性質を説明することでした。これは、カスタム環境および統合で OAuth2.0 を使用している米国およびカナダの実装とは異なるアプローチです。

3つ目のポイントは、実施者がこの実証済みの一連の基準に対して、自分たちの事業が他の管轄区域と国境を越えるかどうかに関係なく、自信を持つことができるということでした。これらの管轄区域では、何千人もの実装者が FAPI に自己認定しており、OpenID Foundation は、民間部門主導の管轄区域と政府主導の管轄区域の両方で、これらの管轄区域の多くと提携できることを誇りに思っています。FAPIの採用に動く国・地域の数は、オープンバンキングやオープンデータの規制とベストプラクティスの世界的な採用に伴い、増加すると予想しています。

最後に、Hodges氏とHeenan氏は、銀行、フィンテック、アグリゲーターなど、北米でFAPIを導入することで恩恵を受けることができるすべての企業にとっての理論的根拠を強調しました。

北米のFDX実装者が考慮すべき重要な決定ポイント

北米の人々が米国またはカナダの規制に準拠するために何をする必要があるかについてデューデリジェンスを積極的に実施している人々に対して、HodgesとHeenanは、分析に役立つ一般的なディシジョンツリーを提供しました。

OAuth 2.0からFAPI 2.0を有効にする方法

Heenan氏は、OAuth2.0を有効にし、FAPI 2.0を有効にしたい場合の簡単なプレイブックを実装者に提供した。

1. セキュアなクライアント認証private_key_jwtまたはMTLSの実装
2. 送信者の制約付きトークン DPoP または MTLS を実装する
3. プッシュされた承認要求の実装 (IETF RFC9126)
4. PKCE の実装 (IETF RFC7636)

実装者は誰でも、OpenID Foundationで自由に利用できるオープンソースのテストをビルドすることから始めることができます。彼らは、メンバー($ 1k)または非メンバー($ 5k)として自己認定することもできます。完全なリソース情報は、OpenID FoundationのWebサイトで公開されているように、参加者に提供されました。

・FAPI 2.0最終仕様:https://openid.net/fapi-2-security-profile-attacker-model-final-specifications-approved/

・ソースコードのgitlab:https://gitlab.com/openid/conformance-suite

・テスト/認証の手順:https://openid.net/certification/instructions/

・運用環境へのデプロイ: https://www.certification.openid.net/

　　-google/gitlab/openidのアカウントでログイン

手をたずさえて前進する

OpenID Foundationは、FAPI 2.0を含む新しいFDXプロファイルに関するFDXのセキュリティおよび認証WG/FAPI WGのコラボレーションを歓迎し、相互のメンバーが戦略的関係の継続と深化から利益を得ることを願っています。

相互に関心のある領域の 1 つは、FAPI 2.0 を含む「blue」プロファイルの初期の北米実装者間で相互運用性イベントを実行することを検討することです。相互運用機能への参加に関心のある方は、director@oidf.org 社にお問い合わせください。

より広い意味では、OpenID Foundationは、Financial Data Exchangeの技術ロードマップをサポートすることを楽しみにしています。また、RARとGrant Managementがオーストラリアや英国などの他の市場で果たし始めている役割や、このような罰金の付与された承認が北米市場でもどのように価値があるかについての洞察を共有することを楽しみにしています。私たちは一緒に、北米の適正な手続きと複数の利害関係者の議論に情報を提供するのに役立つ有用な事実を提供したいと考えています。

Shared Signals Framework: モダンなIAM（アイデンティティおよびアクセス管理）のブループリント - 第1部（全4部）

執筆: Sean O'Dell

2024年12月にダラスで開催されたGartner IAM CAEP Interopイベントは、大成功を収め、多くの企業がShared Signals Frameworkの適用、継続投資に関心を示しました。それを踏まえ、本シリーズでは、Shared Signalsとより広いアイデンティティおよびアクセス管理（IAM）コンテキストへの適用性についてさらに深く掘り下げて説明していきます。

Gartner IAM Londonで3回目のShared Signals相互運用イベントを完了した今、その内容を詳しく述べたいと思います。

 

このブログシリーズは全4回で構成されます。

• 第一回
  Shared Signalsのセキュリティ側面や利点を、実際のユースケースで使用される2つのイベントタイプを通じた紹介
• 第二回
  プロビジョニングとSystem for Cross-domain Identity Managementイベントとの重なりに触れた現実の使用例の紹介
• 第三回
  Shared Signalsが継続的アイデンティティやモダンIAMに適用される事例の横断的な紹介と、Shared Signalsが業界に与える未来の展望
• 第四回
  Shared Signalsをアイデンティティとオープンデータシステムの中枢神経系としての戦略的な議論

はじめに

毎週のように、データ漏洩、ハッカーによるシステムへの侵入、国家ぐるみの攻撃、内部脅威、多要素認証（MFA）の欠如などに関するセキュリティのニュースが報じられています。現在、セキュリティは重要な課題であり、企業は達成困難な「ゼロトラスト」の実現を追い求めています。

そして、企業は複雑性の多さや、ベンダー依存のソリューション固有のAPI、セキュリティベンダーや製品間の連携不足によって多くの課題や障害に直面しています。

「MFA（多要素認証）」のような予防的措置が欠如している場合、これが内部脅威と組み合わさると問題は複雑化します。

そして、これらの脅威が実際に悪用された際、その情報を共有・連携するための「コミュニケーション基盤」がないと、事態はさらに深刻化させます。

だからこそ、「話し合う手段が必要だ」ということになるのですが、そこで登場するのがShared Signals Framework（SSF）です。

Shared Signalsとは

抽象的な表現をすると、Shared Signalsとは、脅威やイベントに関する情報をスムーズかつ安全に共有できるサービスやセキュリティプラットフォームを指し、よりプラットフォーム全体で調整済み且つ積極的な対応を可能にします。

Shared Signalsは、現実でも広く使用されています。

例えばアンバーアラート（アメリカで行われている児童誘拐に関する緊急警報システム）や無線緊急アラート、近隣住民が不審な活動のスクリーンショットや動画を共有すること、市や自治体の緊急対応システム（警察、消防、その他のシステム）などが挙げられます。

重要な示唆としては、適切な種類のリアルタイムアラートを適切な対象者に届けることで、それらの人々やシステムが即座に是正措置を講じることができるという点です。

デジタルの領域では、これらのアラートはアカウントやセッションに関連するリスクシグナルから始まります。

ベストプラクティス

「With great power comes great responsibility（大いなる力には大いなる責任が伴う）」。これは、Shared Signalsを十分に活用するためのベストプラクティスというテーマに合う素晴らしい言葉です。

我々は普段、ビジネス、契約、プライバシー、法的、コンプライアンス、運用、技術的な観点など、さまざまな視点で物事を考える必要があります。

Shared Signalsの利活用する場合も同様で、どのような場面で使えるのかを考える際に視野を広く捉えることは、見逃してはならない重要な点です。

以下に、上記の観点の例をいくつか挙げます。

コンプライアンス

Shared Signalsは、あなたの大いなる味方として、多くのコンプライアンスを実現するための手助けとなります。以下のような質も質問に対応することができます。

• 設定がいつ更新され、誰によって行われたのか？
• ユーザーや従業員が退職または離職した際に、アカウント、アクセス、セッションがタイムリーに無効化または取り消されたこと
• 機密性の高い、または特権を有するアプリケーションにアクセスされた際に、適切な認証（例：MFA（多要素認証）やWebAuthN、Passkeysのようなフィッシング不可能な認証）がポリシー通り行われたこと

 これらの質問に対処するには、オープンかつ相互運用可能な標準を使用することがベストプラクティスであり、コンプライアンスの複雑性を解消する方法でもあります。

最後に、Shared signalsに関連するコンプライアンスの別の側面として、適切なデータと契約に基づいて適切なイベントが適切なシステムや受信者に送信されたことを確認するという点があります。

これを確実に行うことは、データ漏洩や過剰なデータ配布を防ぐうえで重要です。

法令順守およびプライバシー

ここで網羅的に記述されているわけではありませんが、Shared signalsの利活用には、社内インフラでの利用や企業間（B2B）も考えられます。Shared signalsは、データやイベント共有におけるトラストフレームワークとして見ることができます。ただし、データの最小化の原則に従うことが重要です。

例えば、イベントの中で対象の情報が、受信者やシステムが意思決定や行動を起こすために必要な最低限のものであることを確認します。

優れたデータの最小化の例であり、ベストプラクティスとも言えるのは、グローバルに一意な識別子（GUID）のような識別不可能な識別子を使用することです。これによって、メールアドレス、ユーザー名、その他個人を特定できる情報（PII）を避けることができます。これは、ユーザーがイベントの主体である場合に特に有益です。一方で、特定可能な属性を含める必要がある場合もあります。そうした場合に法務部門へ相談するのが良いでしょう。 

外部企業と統合する際、特にB2Bのケースでは、両方の企業の法務およびプライバシーチームに相談することがベストプラクティスです。企業間でデータを交換する際には、識別子を難読化し、企業Aと企業Bの関係に限定する範囲でデータを管理することが推奨されます。一つの優れた例として、ユーザーがイベントの主体である場合、イベント交換中に仮名（PPIDS）を使用することが挙げられます。

ユースケース例

では、Continuous Access Evaluation（継続的アクセス評価）の「CAEPabilities」から始めましょう。CAEPは「Continuous Access Evaluation Profile（継続的アクセス評価プロファイル）」の略であり、ユーザーのコンディションや行動が進化するにつれて、それに応じたコンテキストを認識によるユーザーアクセスとセッション管理のリアルタイム評価を含みます。CAEPイベントの例には、「セッションの取り消し」、「認証情報の変更」、「保証レベルの変更」または「デバイスのコンプライアンス変更」が含まれます。CAEPの詳細についてはこちらをクリックしてください。

もし80年代の映画「Risky Business（日本語タイトル：卒業白書）」が「RISCy Business」と名付けられていたら...ダジャレにもなったのに。。

RISCは「Risk Incident Sharing and Coordination（リスクインシデント共有と調整）」の略で、特にセキュリティインシデントに関連する形で侵害されたアカウントを対象としています。RISCイベントの例として、「アカウントの有効化（account enabled）」、「アカウントの無効化（account disabled）」、「識別子の変更（identifier changed）」が挙げられます。RISCについてさらに詳しく知りたい場合はこちらをクリックしてください。

社員が会社を退職する場合

セッション管理は現在も業界および企業で根強い課題となっています。

しかし、Shared Signalsの採用によって、この問題を軽減することができます。典型的な状況としては、社員が退職する際に、通常の人事イベント通知以外の対応が必要になる場合です。一見すると、これは平易で明確なプロセスのように思われますが、IAM（Identity and Access Management）システムやコラボレーションアプリ、さらには複数のアイデンティティプロバイダーが関与する場合、セッション管理は複雑になります。

このような場合、CAEP（Continuous Access Evaluation Profile）とRISC（Risk Incident Sharing and Coordination）イベントの両方を使用することで、標準に基づいた方法で問題に対処し、全社規模で社員の退職に対応するための調整されたプロセスを実現できます。例としては、「セッションの取り消し（session revoked）イベント」（CAEP）と「アカウント無効化（account disabled）イベント」（RISC）を組み合わせることで対応できます。

さらに、企業が1つ以上の「フェデレーション」（複数の会社間の信頼関係構造）に参加している場合、RISCイベントをShared Signals Frameworkを使用して通信プロトコルのメカニズムとして利用することで、協力関係にある各社間でセキュリティに関する協調を強化できます。この例では、社員が退職した際、同じ「アカウント無効化（RISC）」イベントが自社および他社に送信され、関係するすべての当事者が「フェデレーションアカウントの無効化」、「リンクされたアカウントの無効化」、「アクセスの削除」といった適切なセキュリティ対応をリアルタイムで実行できるようになります。

以下の図に示されているように、これらのイベントは、参加しているすべての関係者のために、セキュリティ情報およびイベント管理（SIEM）に記録されるべきであることも重要です。これは、緑色の円とチェックボックスで示されています。

ユーザーの不審な行動

このユースケースは非常に興味深いものであり、コンテキストに強く依存し、場合によっては主観的な要素も含まれます。不審な行動に対してShared Signalsをどのように活用できるかを明確にするために、これを2つの潜在的な選択肢に分解して説明します。

その前に、Shared Signalsにおける「主体」について触れておくことが重要です。「主体（Subjects）」とは、Shared Signals Framework内でセキュリティイベントの主な焦点となるものであり、ユーザー、デバイス、またはユーザーのグループなどが含まれます。

主体についてさらに詳しく知るには、こちらをクリックしてください。

進歩的アプローチ

Shared Signalsに入る前に、いくつかの前提条件を設定する必要があります。

前提条件1: SIEM（セキュリティ情報およびイベント管理）またはIdentity Threat Detection and Response（ITDR）プラットフォームが、デバイス単位での挙動を分類し、それをユーザーに関連付けることができる。

前提条件2: セッションはアイデンティティプロバイダーまたは組織内の重要な影響を持つ、または機密性の高いシステムによって追跡および管理される。

以上の前提条件を考えると、Shared Signals Frameworkを使用することで、エンドユーザーの体験に影響を与えることなく、組織のセキュリティ体制を強化できます。信じられないですか？どうしてそんなことができるのでしょう？ここに状況を説明します。

いま、不審な活動が、ユーザーにとって通常とは見なされない、または以前に使用されたことのない不正なIPアドレスや新しいデバイスから発生しているようです。この場合、セッション取り消し（Session Revoke）イベント（CAEP）は、Shared Signalsの送信側から異なる「主体」を持つ形で選択された受信側に送信されます。セッション取り消しイベントの1つでは、サブジェクトがIPアドレスまたはCIDR範囲になり、別のものでは、不正デバイスの識別子になります。これにより、エンドユーザーの体験に影響を与えることなく、IPアドレスや不正デバイスを対象とすることが可能になります。

これらのセッション取り消しイベントは、送信側とイベント送受信できる関係をつアイデンティティプロバイダーや多くの影響を受けるシステムに送信されます。これが「進歩的アプローチ」と呼ばれるものの一部であり、時間が経つにつれて、Shared signalsからさらに多くのコンテキスト情報を引き出すことが可能になります。

そして、時間が経ち、それらのIPアドレスまたは不正デバイスが再び出現する場合を考えます。この属性を対象とできることがわかったため、さらに別の「進歩的」アクションを取り、資格変更イベント（CAEP）を発行することができます。これは、アカウント乗っ取り（ATO）が発生していることが推測できるためです。

処方的アプローチ

進歩的アプローチで設定された前提は変更されず、異なるのはセキュリティ対応の方法のみです。

状況は以下と同じです：「以前にユーザーが使用したことがない、または通常とは見なされない不正IPアドレスや新しいデバイスから不審な活動が発生しているように見える」。

この前提に基づくと、エンドユーザーへの影響がより大きく、抜本的な対応が必要になるかもしれません。組織のセキュリティポリシーによってはそういった要求される場合があります。このシナリオでは、セッション取り消しイベント（CAEP）、アカウント無効化イベント（RISC）、さらには資格情報変更イベント（RISC）がアイデンティティプロバイダーや多くの影響を受けるシステムに発行され、ユーザーの行動やパターンに基づいて適切にセキュリティ制御することを保証します。

「どのようにして送信側が、受信システムによってアクションが実行され、成功したことを認識するのか？」と思われるかもしれません。これは、「共有は思いやり（sharing is caring）」という方法論に従うことで、調整（Reconciliation）や複式簿記法（double entry bookkeeping）を通じて達成が可能です。基盤として、受信側は送信側でもあるべきです。これが次のセクションで取り上げる内容です。

セキュリティイベントの連鎖

前述の例、すなわち従業員が会社を退職する場合やユーザーアカウントで不審な活動が検出された場合を基に、ここではセキュリティイベントにおけるアクションの検証、調整（リコンシリエーション）、および複式簿記について議論を進めます。この分野で際立って力を発揮するのがShared Signalsです！ゼロトラストを実現するためには、共通の通信手段を見つけることが必要です。以下の図は、Shared Signalsの調整や連鎖の側面を視覚化するための良い参考資料であり、リアルタイムで組織内および組織間のスケールを可能にする非常に強力で有用なものです。

セキュリティイベント#1:

Acme Corpは、子会社であるWonka Industriesにアカウント無効化イベント（RISC）を発行しました。Wonka IndustriesがAcme Corpから送信されたアカウント無効化イベント（RISC）を受け取って承認した後、社内ポリシーに基づいてそのイベントに対するアクションが実行されます。そのアクションが無事に完了すると、別のアカウント無効化イベント（RISC）という形でAcme Corpに送信するアウトバウンドのセキュリティイベントが発行されます。

 ここで重要になるのが、監査、簿記、そして調整です。最初のアカウント無効化イベント（RISC）において、Acme Corpから送信された「txnクレーム」（取引識別子）にはたとえば「a1b2c3d4e5」という値が含まれていたとします。そして、Wonka IndustriesがAcme Corpに返信する際、この同じ値「a1b2c3d4e5」を含めて返信します。このシンプルさによって、関与するすべての関係者が実施したセキュリティイベントを検証でき、監査目的で複式簿記（Double Entry Bookkeeping）が可能になります。

セキュリティイベント#2:

 Acme Corpは、異なる企業であるInitechにもアカウント無効化イベント（RISC）を発行しました。この場合、Acme CorpとWonka Industriesのイベントが一致していることに気づくかもしれません。しかし、調整のためにイベントが常に一致している必要はあるのでしょうか？答えは「いいえ」です。このケースでも、シナリオ1と同じ概念や原則が適用されますが、1つ違いがあります。InitechがAcme Corpからアカウント無効化イベント（RISC）を受け取った場合、代わりにセッション取り消しイベント（CAEP）で応答しました。なぜそうしたのでしょうか？それはポリシー、CAEPのマッピング、またはInitechがAcme Corpからオンデマンドでプロビジョニングされたフェデレーションアイデンティティのセッションを単に取り消したためかもしれません。それでも、Acme Corpが使用した同じtxnクレーム「a1b2c3d4e5」がInitechから返信され、「連鎖を閉じる」形になります。接続された2つのエンティティ間、または相互接続されたエンティティのフェデレーション間でどのポリシーが選択されているかに関わらず、すべての参加者はアカウント無効化イベントやセッション取り消しイベントを交換するという同じプラクティスを順守し、正確なデータを維持します。

将来は、Shared Signals Framework（SSF）やContinuous Access Evaluation Profile（CAEP）、Risk Incident Sharing and Coordination（RISC）、そして将来的にはSCIMイベントのような標準化が協力と「共有は思いやり（sharing is caring）」という意識を促進する時代になります。多くのRP実装者は、RISCやCAEPイベントの受信から始めることに最も安心感を抱くかもしれませんが、本当に重要なのはイベントの双方向交換に必要な信頼を確立することです。このシグナルの双方向交換こそが、公共部門と民間部門の相互接続されたエコシステムを長期的に実現する鍵となるでしょう。このテーマについては、シリーズの第3部と第4部で詳しく取り上げます。

次回は、第2部「Shared Signalsによるプロビジョニングの簡素化を実現」についてお届けします。

それでは次回までお待ちください。

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などの標準を使用して実装されたパターンは、ゼロトラストクラウドアーキテクチャの保護に大いに役立つ可能性があります。