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によるプロビジョニングの簡素化を実現」についてお届けします。
それでは次回までお待ちください。