誰にでも起こりうるリスク～認証後の課題とその解決策（SSF）とは

昨今、セキュリティ侵害に対して完璧に防御することは不可能であり、侵入されることを前提に対策を検討すべきだと言われています。これは主に企業や組織を守る立場の文脈で語られていることだと思いますが、その企業や組織が提供しているサービスの利用者など、個人についても同じような考え方が必要なのではないでしょうか。

つまり、セキュリティ被害は個人のレベルでも、誰にでも起こりうる、ということです。それを前提にしなければならないのではないでしょうか。

誰にでも起こりうるリスク

それを裏付けるようにフィッシングによる被害が急増しています。フィッシングによるものと思われる不正送金が令和5年（2023年）に5,000件以上発生しており、その被害額は87億円を超えています。

またクレジットカードの不正利用額も2023年で540億円を超えています。

※ 不正利用額のすべてが騙された結果であるとは言いませんが、やはり、フィッシングにより騙されてカード番号を盗まれた例も多く含まれています。

不正送金額が1年間に87億円、クレジットカードの不正利用額が1年間に540億円、これは途方もない金額ですよね。

こういった問題は様々な機関・組織から注意喚起が出されている他、テレビの報道番組など一般のメディアでも盛んに取り上げられているにも関わらず、減少するどころか増加する一方です。

やはり、セキュリティ被害は個人のレベルでも、誰にでも起こりうる、ということではないでしょうか。

このような状況のなか、とあるイベントに参加し、考えさせられたことがありましたので紹介します。

それは、2024年5月16日に開催された「OpenID TechNight vol.21 ~ Shared Signal Framework & IIW参加報告」というイベントで取り上げられていたShared Signals Framework（以下、SSF）です。

認証後の課題とは？

わたしはこれまで、認証などに関わるいくつかの記事を執筆しLAC WATCHに投稿させていただきました。それらの記事のなかで、弱い認証方式では心もとないのでMFAを導入しましょう。そして、できればフィッシング耐性の高い方式にしましょう。ということをお勧めしてきました。認証さえ確実に行えばほとんどすべての問題は解決するのではないか、と考えていたためです。

しかし前述のイベントに参加して、それでは不十分であることに気づかされたのです。そして、セキュリティ被害は個人のレベルでも、誰にでも起こりうる、ということに結びついたのでした。

そのイベントの冒頭で語られたのは「認証はログイン時のみ行われ、継続したモニタリングが行われていない。これは解決すべき問題である」ということでした。

認証した後、継続したモニタリングが行われていないとはどういうことでしょうか？何が問題なのでしょうか？

継続したモニタリングが行われていないことによる問題とは？

安直で極端な例で恐縮ですが、例えば認証したアカウントが騙され、乗っ取られていたとしても、その後のアクセスや処理のリクエストを許してしまう、ということです。

現実的な例で説明します。

あるショッピングサイトにログインし、商品をカートに入れて注文します。注文した商品が手元に届き、クレジットカードなどで決済されます。ごく当たり前におこなわれていることですが、これは正規のユーザーが一連の行為を実施していることが大前提となっています。つまり、最初に本人確認した後は、その本人確認をした時点での情報を信じて、一連の処理を最後まで行っているということです。したがって、途中でそのアカウントが乗っ取られていたとしても、そのまま一連の処理を最後まで行うということになります。

※ セッションの継続時間／有効期限の長さに依存するお話ではありますが、ユーザーエクスペリエンスの方を優先して、セッションの継続時間／有効期限は長めになってきたのではないかと思います。そして長ければ長いほど認証した時点からの時間経過が大きくなるわけですから、それだけ乗っ取られるリスクも大きくなる、ということです。

大前提と表現しましたが、わたし自身もそれが当たり前、そういうものだと考えていました。しかし、セキュリティに関する意識が高い人たちは違いました。

認証した、その時点の情報は正しかったのかもしれませんが、その後もずっと正しいと言えるのでしょうか？

この点を課題として捉え、解決策を検討しているのがOpenIDのShared Signals Working Groupであり、そこで検討されているのがSSFなのです。

SSFとは

SSFとは、異なるサービスやアプリケーション間で、ユーザーやセッションの状態に関する「Signal」をリアルタイムで共有することにより、認証とアクセス制御を強化するフレームワークです。

それではもう少し詳しく見ていきます。

SSFの主な特徴

1．リアルタイムのセキュリティイベント共有

SSFは、セキュリティ関連のイベントやユーザーの状態変更をリアルタイムで共有します。例えば、ユーザーのアカウントがセキュリティ上のリスクにさらされた場合、その情報が即座に他の関連サービスに伝達されます。

2．クロスドメイン対応

異なるドメインやシステム間でユーザー情報やセキュリティ情報を共有できるため、複数のサービスが統合されている環境でも一貫したセキュリティ管理が可能です。

次に、SSFのなかで重要な役割を果たしている二つのプロトコルContinuous Access Evaluation Profile（以下、CAEP）、およびRisk Incident Sharing and Coordination（以下、RISC）について説明します。

CAEPとは

SSFの一部として開発されたプロトコルで、リアルタイムでアクセス制御を評価するための仕組みです。ユーザーの認証後も、そのアクセスが適切であるかどうかを継続的に評価しセキュリティリスクが発生した場合には即時に対応することを目的としています。

その役割は、特に長期間のセッションが許可されている場合やユーザーの行動が変化した場合にアクセスの再評価を行うことであり、セッションハイジャックや不正アクセスを防ぐことができます。

つまりCAEPとは、リアルタイムのアクセス評価に焦点を当てたプロトコルであり、ユーザーがアクティブな状態にあるときに継続的にアクセスの適切性を評価することでセッション中のリスクを最小化するためのもの、という位置づけとなります。

RISCとは

SSFに関連するもう一つの重要なプロトコルで、セキュリティインシデントやリスクに関する情報を共有するためのフレームワークです。RISCを通じて、あるサービスで発生したセキュリティインシデントを他の関連サービスに迅速に共有することで、全体のセキュリティを高めることを目的としています。

その役割は、アカウントの乗っ取りや他の不正行為が発生した場合に、その情報を関連するサービスに共有し早急な対応を促します。これにより、連鎖的な攻撃の防止や被害の拡大を防ぐことができます。

つまりRISCとは、セキュリティインシデントの共有と調整を担当し複数のサービス間でリスク情報を連携させることで、全体のセキュリティ態勢を強化するためのもの、という位置づけとなります。

フィッシングによる被害を防ぐ

難しいことを並べ立ててしまいましたが、ざっくりとまとめると、
セキュリティ被害は個人のレベルでも、誰にでも起こりうるという前提に立ち、複数のサービス/システムでSSFを取り入れれば被害の更なる拡大を防ぐことができる、
ということです。

今度は飛躍しすぎましたね。それでは具体的なイメージ、ユースケースをあげてみたいと思います。

※ 以下のイメージ、ユースケースは、わたしが想像するところの「SSFの導入により実現できそうなこと」であって、実現できることを確約するものではありません。また逆に、既にそういった方向で導入が進みつつある、ということもあるかもしれません。この点についてはあらかじめご了承ください。

フィッシングとは

と、改めて説明するまでもないほど認知されているとは思うのですが、この記事の冒頭で述べたとおり、その被害は減少するどころか急増しているのが現状です。生成AIを使用することにより、従来のフィッシングメールで使われていたような明らかに不自然な言い回しなどが無くなり、もはや文面を見ただけでは正規のメールなのかどうか区別が難しくなっている、という背景もあるようです。

以下の図は、以前、わたしがアップさせていただいた記事『WebAuthnでセキュリティとユーザビリティを向上させよう～WebAuthnがおすすめな理由 #2～』で紹介したAiTM（Adversary in The Middle）という手法のイメージです。

細かい説明は省略しますが、正規サイトとユーザーの間にプロキシーとしてフィッシングサイトを立てることにより、多要素認証も突破してセッションクッキーを窃取し、それを使って正規サイトにアクセスする、ということです。

つまり、正規サイト側ではセッションクッキーがあるため、認証が正しく行われたとの前提で処理を行います。したがって、攻撃者は正規のユーザーになりすまして不正送金などを行うことができてしまいます。正規のユーザーアカウントを乗っ取った、ということですね。

SSFによってどのように防ぐのか

先ほどのシステムに、異常なアクセスを監視するシステムを導入し、それをトランスミッター（Signalを送信する側）とします（下の図の右端）。

このシステムは通常とは異なるパターンのアクセス^※を検出します。そのような異常なアクセスを検出した際にSignalを送信します。レシーバー（Signalを受信する側）は、先ほどの例と同じ正規サイトです。

※ 通常はアクセス元が日本の特定の地域のIPアドレスであるにもかかわらず、ある日突然、アクセス元が海外のIPアドレスになった、など

攻撃者が先ほどの例と同じ手法でセッションクッキーを使って正規サイトにアクセスします。この時、上の図の⑩で異常なアクセスを監視するシステムが異常を検出して⑪でSignalを送信します。次に攻撃者が⑫で送金手続きを試みた際に、正規サイトでは異常を検出したSignalを受信しているので、このアクセスをブロックすることができます。

上記の例にとどまらず、SSFには様々な機能がありますので、興味を持たれた方は当記事の文末に記載したShared Signals Working Groupのページやスペックを参照ください。

さいごに

フィッシング対策や認証の強化など、個別の対策もそれぞれに重要であることは間違いありません。ですが、それでもやはり被害は増加の一途をたどっています。このことを現実として受け入れ、更なる被害を防ぎましょう。

そのための有効な対策としてSSFというフレームワークがある、というのが今回の記事です。SSFはまだそれほど一般的になっていないかもしれませんが、Microsoftや、Google、Appleなどでは既に一部が取り入れられているとのことです。

また、トランスミッターとなる側とレシーバーとなる側が同じ組織とは限りませんので一朝一夕にはいかないかもしれませんが、金融機関や通信キャリアなどの大きな企業グループは、傘下に様々な会社があり、様々なサービスを展開しています。まずはそういった既につながりのあるサービス同士でSSFを取り入れることを検討されてみてはいかがでしょうか。

参考情報

OpenID Foundation

• Shared Signals Working Group - OpenID Foundation
• OpenID Shared Signals Framework Specification 1.0 - draft 03
• OpenID Continuous Access Evaluation Profile 1.0 - draft 03
• OpenID RISC Profile Specification 1.0 - draft 03

Microsoft

• Microsoft 365 の継続的アクセス評価 - Microsoft 365 for Enterprise | Microsoft Learn

Google

• クロスアカウント保護機能でユーザー アカウントを保護する | Authorization | Google for Developers