Shared Signals Frameworkが切り開く“動的セキュリティ”の未来

1. はじめに

Shared Signals Framework（SSF）¹は、ログイン後に起きるアカウント／セッション／デバイスの状態変化を、標準化されたイベントとしてサービス間でリアルタイム共有し、各サービスが自動対応できるようにするための仕様群です。

複数クラウド／複数SaaSの利用が常態化する中で、企業のアイデンティティ基盤は「ログイン時に正しい」だけでは十分ではありません。ログイン後にデバイス状態が変わったり、アカウントが侵害されたり、セッションが乗っ取られたりする事象に対して、サービス横断で一貫した継続的な制御が求められます。

本稿では、この点について解決策を提示するSSFおよび主要プロファイルであるContinuous Access Evaluation Profile（CAEP）²とRisk Incident Sharing and Coordination（RISC）³について紹介し、企業にもたらす可能性を整理します。

2. Shared Signals Framework（SSF）の本質—何が“新しい”のか

SSFの本質は、「ログイン・認証情報そのもの」ではなく、「その後のアクセス状態やリスク変化（シグナル）」を標準化してリアルタイムに共有する、という発想にあります。

従来の認証Cookieやフェデレーション型のSingle Sign-On（SSO、シングルサインオン）方式は、ログイン時点での認証を保証するものです。しかしログイン後に、デバイスのコンプライアンス違反、認証情報の変更、異常なセッション状態などが起きた場合には、認証時点ではセキュアと判断できた状態が変化している可能性があります。そこで、従来から、認証システム単独でのリスク計算による認証制御は行われてきました。

しかし管理者としては、この変化をSSOでログインを許した関係システム（複数SaaSを含む）に速やかに共有し、全体的にログイン状態を終了させる、再認証を要求する、といった対処で被害を最小化したいはずです。ゼロトラストの普及以降、このような継続的評価やシグナル共有の考え方自体は広く知られてきましたが、実装はベンダー独自仕様で分断されがちでした。SSFは、この「セキュリティ状態変化の共有」を標準化し、多様なシステム間で相互運用可能にすることを目指したものです。

図表1：SSFを導入した場合のシングルサインオンの変化

SSFはまた、SSOで課題となっていたサインアウト（セッション失効）の扱いにも解決策を与えています。一般に、1つのログアウト操作で複数サービスのログイン状態を連動して終了させる仕組みを持つSSOは、プロプライエタリ実装や普及度の低い方式が多く、どの方式を採用すべきかの判断が難しく、その結果、「あるサービスでサインアウトしても別サービスのセッションが残る」「サービスごとに挙動が異なる」といった問題が残りやすいのが実情です。SSF／CAEPにより、例えば「セッション無効化（session-revoked）」のようなイベントを標準形式で共有できるようになれば、将来的により一貫したセッション連携解除（SSOに近い体験）を実現できる可能性があります。

3. SSF／CAEP／RISC—次世代セッション・アカウント制御の基盤

ここで、図表2を使用し、SSF、CAEP、RISCについて簡単に解説します。

図表2：SSF、CAEP、RISCの動作概要

Transmitterは「誰に起きた・いつ起きた・何が起きた」をイベントとして発行します。SSFで定義された標準APIを通し受信側にイベントストリームとして安全に配信します。イベント内容は後述するCAEP（セッション無効化、認証強度変更など）とRISC（アカウント無効化、資格情報侵害など）で定義されます。Receiverは受信後、ログアウトや再認証などを自動実行でき、複数サービスにまたがる不正アクセスをリアルタイムに止められます。

SSFにおけるTransmitter／Receiverはそのイベントストリームで送る側／受ける側という役割であり、固定的にIdentity Provider（IdP）＝Transmitter、アプリケーション＝Receiverと決まるものではありません。IdP以外（EDR/MDM、ITDR*、SaaS等）がTransmitterとなることも、RP以外（SaaS、業務アプリ、ゼロトラストプロキシ等）がReceiverとなることもあります。

* ITDR：Identity Threat Detection and Response（アイデンティティ領域の脅威を検知し、認証・セッション・権限に対する対応まで行う仕組み）

なお、Transmitter／Receiverを誰として信頼し参加させるか（審査・契約・責任分界・ガバナンス等）のトラストフレームワークは、SSFのスコープ外となります。企業内などの場合問題になりにくいと考えられますが、多数の企業間で使用する場合は別途設計が必要です。

これにより、これまで難しかった、複数クラウド／SaaSをまたぐ統合アクセス管理が、サービスごとの個別実装ではなく、共通のイベント共有基盤で横断運用することが期待できます。

以下では、SSFのプロファイルであるCAEPとRISCを紹介します。これらは、それぞれ異なるタイプの状態変化イベントを扱います。これにより、セッション、アカウント、デバイスなどをまたいだ統一的な通知と制御が可能になります。

3.1 CAEP（Continuous Access Evaluation Profile）

ログイン後のセッション状態やアクセストークンに関わる状態変化を、継続的に共有するためのプロファイルです。

受信側（Receiver）はイベントを受け取ると、アクセス再評価、再認証要求、セッション無効化などのアクションを即時に取れます。

これにより、例えば不正デバイスや異常アクセスの検知後、自動セッション無効化（Session Revoked等）によるリアルタイムな対応が可能となります。

3.2 RISC（Risk Incident Sharing and Coordination）

アカウントのライフサイクル変化やリスクインシデントを共有するためのプロファイルです。

組織間／サービス間でアカウント状態を共有できるため、横断的なアクセス剥奪や統一ポリシーの維持に寄与します。

これにより、例えば退職のアカウント無効化時の即時対応（Account Disabled等）で、すべてのサービスで即時アクセス剥奪などが可能になります。

4. SSFが企業にもたらす“変革可能性”

相互運用性を前提にSSFに対応する製品やアプリケーション導入を増やすことで、企業は次のような変化を実現しやすくなります。

4.1 セキュリティ運用が「即応型」へ—リアルタイムなアクセス制御

従来はログ監視や定期チェック、セッション有効期限など「後追い」の統制が中心でした。SSFにより、不正や異常の検知後、即時共有と即時対処（アクセス停止／再認証要求など）が可能になり、被害の封じ込めまでの時間短縮が期待できます。

例えば、デバイス侵害やコンプライアンス違反が判明した瞬間に、異常セッションを打ち切る／退職や権限変更に伴い全サービス横断で即時アクセス剥奪する、といったことが可能になるでしょう。

4.2 サービス間での“統一された信頼関係”の構築

多くのSaaSを利用する環境では、各サービスが個別にアクセス制御を持つことでポリシーの一貫性が崩れ、運用も複雑化します。SSFにより、複数サービス間で同じフォーマットでイベントをやり取りでき、実装差分を吸収しながら統一的なポリシー運用を設計しやすくなります。結果として、ベンダーロックインを避けつつ拡張しやすい環境の骨格を作ることができます。

4.3 アプリケーション設計と運用の新たなモデル—“イベントドリブンアクセス制御”

SSF／CAEPにより、アクセス制御がイベントドリブンになります。認証後に状態変化があれば再認証や制限を随時適用でき、アプリが個別に複雑な判定ロジックを持つ負担も軽減します。既存のSSO＋IdP＋セキュリティツール群の上に「動的アクセス制御レイヤー」を追加できる点が、大きな進化です。

5. まとめ—SSFが実現する“動的・連携型セキュリティ基盤”

SSF／CAEP／RISCの最終仕様の承認により、実装者は安定した仕様に基づいて相互運用性を前提とした実装・導入検討を進めやすくなりました。

これは、単なる標準策定のマイルストーンを超え、企業のアイデンティティ／アクセス管理のモデルを刷新する契機となり得ます。