AI時代のフィッシング|第3回:MFA後のトークン・セッションを守る認証セキュリティ 

1. はじめに 

本シリーズの第1回・第2回では、AIによって変化するフィッシング攻撃と、認証後のアクセス権が悪用される仕組みについて見てきました。 これまでの内容から分かるのは、「正しくログインできたから安全」とは限らない時代になっているということです。 

では、MFA(多要素認証)による認証を通過した後、私たちは何を守る必要があるのでしょうか。 

今回は、認証後のトークン(token)やセッション(session)、そして利用状況まで含めて、これからの認証セキュリティについて考えていきます。 

2.「ログイン成功=安全」という前提の変化 

多くのシステムは今でも、「ログイン成功 = 信頼できるユーザー」という前提で動いています。長い間、この考え方でも十分に機能していました。 しかし現在では、認証後に発行されたトークン(アクセス権)やセッション(ログイン状態)を悪用したり、認証フロー(authentication flow)そのものを利用したりする攻撃も行われています。

つまり、認証に成功したからといって、その後のアクセスまで無条件に信頼できるとは限りません。 認証は「ゴール」ではなく、スタート地点になりつつあります。 

3. 認証後のアクセス権と利用状況をどう守るか 

これまでの認証では、パスワードが最も重要と考えられてきました。 しかし現在では、それだけでは十分ではありません。 

認証後に発行される、 

  • トークン
  • セッション
  • Authentication context(認証コンテキスト) 

も重要になっています。 

特に重要なのが、「誰がログインしたのか」だけではなく、「どのような状況でログインし、その後どのようにサービスを利用しているのか」まで確認することです。 

そのために重要になるのが、Authentication Context(認証コンテキスト)という考え方です。 

Authentication Contextとは何か 

Authentication Context(認証コンテキスト)とは、「そのログインやアクセスが自然なものかどうか」を判断するための周辺情報のことです。 

例えば、 

  • どこからアクセスしているか  
  • どの端末を使用しているか  
  • 普段と違う行動をしていないか  

などがあります。 

例えば、いつも日本からアクセスしているユーザーが、突然別の国からログインした場合、不自然なアクセスかもしれません。 

このように、ログイン時の認証結果だけではなく、その周辺の状況も含めてアクセスのリスクを判断することが重要になってきています。 

4. MFAだけでは十分ではない理由 

ここまで読むと、「では、MFA(多要素認証)はもう意味がないのか?」と思うかもしれません。 

もちろん、そんなことはありません。 

MFAは今でも非常に重要なセキュリティ対策です。 ただし、MFAだけですべてを守れる時代ではなくなってきています。 

Device Code Phishing(デバイスコードを悪用したフィッシング攻撃)では、 

  • MFAは正常に動作する  
  • ユーザーも正しく認証する  

それでも、その後で攻撃者がトークン(アクセス権)を利用できる状態になることがあります。 

つまり、認証に成功した」という事実だけでは、その後のアクセスまで安全だとは言い切れないということです。 

では、認証後のアクセスをどのように守ればよいのでしょうか。 

5. 認証後のアクセスを守るためのセキュリティ対策 

認証後も安全な状態を維持するためには、ユーザー側とシステム側の両方から対策を考える必要があります。 

ユーザー側 

ユーザー側では、以下のような状況に注意が必要です。 

  • 突然の認証要求  
  • 業務の文脈に合わない確認  
  • 不自然なログイン誘導  

特に、身に覚えのないデバイスコード(Device Code)の入力を求められた場合などは、注意が必要です。 

システム側 

システム側では、ログイン後の利用状況を継続的に確認することが重要になります。 

具体的には、 

  • 異常なアクセスを検知する「異常検知」(Anomaly Detection) 
  • アクセスの危険度を判断する「リスク分析」(Risk Analysis) 
  • 必要に応じてセッションを制御する仕組み(Session Control) 

例えば、 

  • トークンの有効期間短縮(Token Lifetime) 
  • 利用端末の検証(Device Validation) 
  • リスクに応じた認証(Risk-based Authentication) 

などが考えられます。 

多くのWebアプリケーションでは、一度トークンが発行されると、有効期限が切れるまでトークンを使ったアクセスを許可しているケースがあります。 しかし、トークンが盗まれてしまうと、攻撃者も正規ユーザーと同じ権限で操作できてしまいます。 

そのため今後は、 

  • 使用している端末が変わっていないか 
  • IPアドレスが急激に変化していないか  
  • 普段とは異なる操作が行われていないか 
  •  利用状況に不自然な点がないか 

といった情報も継続的に評価することが重要になります。 

異常が検知された場合には、必要に応じて再認証を求めたり、トークンを無効化したりするなど、状況に応じてアクセスを制御する設計が求められます。 

6.システム設計から考える認証後のセキュリティ 

多くのアプリケーションでは、認証後に発行されたトークンを前提として、その後のアクセスを制御しています。しかし、トークンが盗まれた場合、攻撃者も正規ユーザーと同じ権限を持つ可能性があります。 

そのため今後は、トークンそのものを信頼するだけではなく、 

  • どの端末からアクセスしているのか  
  • どのような操作を行っているのか  
  • 普段と異なる利用状況ではないか  

といった情報も含めて、継続的にアクセスのリスクを評価することが重要になっていくと考えられます。 

つまり、「一度認証したから、その後はずっと信頼する」という設計から、「利用中も状況に応じて信頼度を判断する」設計への変化です。 

7. 継続的認証(Continuous Authentication) 

このように、ログイン時の認証だけで信頼を確定するのではなく、ログイン後も利用状況を継続的に確認するという考え方があります。これが、継続的認証(Continuous Authentication)です。 

つまり、ログイン後も継続して、「本当に本人が利用しているのか」を確認する考え方です。 一度認証に成功したユーザーであっても、その後の利用端末、アクセス元、操作内容などに大きな変化があれば、再度リスクを評価します。 こうすることで、認証後にトークンやセッションが悪用された場合でも、その異常を検知し、必要に応じてアクセスを制限することができます。 

8. まとめ 

以前のフィッシングでは、攻撃者は主にパスワードなどの認証情報を狙っていました。しかし現在では、AIや自動化によって攻撃手法が高度化し、認証後に発行されるトークンやセッションなどの「正規のアクセス権」も攻撃の対象となっています。

特に注目すべき点は、攻撃者が必ずしも「システムを破壊する」ことを目的としているわけではないことです。むしろ、正規のログインやMFAなど、安全性を支えるために導入された仕組みそのものが悪用されるケースが増えています。

このような背景から、これからの認証セキュリティでは、「ログインした時点で終わり」ではなく、「ログイン後も継続的に守る」という考え方が、より重要になると考えられます。

MFAは今後も重要なセキュリティ対策であり続けます。一方で、MFAだけに依存するのではなく、トークン、セッション、利用端末、アクセス元、利用状況などを継続的に評価し、必要に応じてアクセスを制御することが求められます。

技術の進化に伴い、攻撃手法も変化し続けています。

「認証する」だけではなく、「認証後のアクセスも継続的に保護する」。

これからの認証セキュリティにおいては、このような考え方がより重要になっていくのではないでしょうか。