優れたエッジセキュリティでも高リスクセッションを見逃してしまう理由

セキュリティチームはこれまで以上に多くのエッジ制御を活用できるようになり、それぞれが重要な役割を果たしています。しかし、リクエスト検査、認証情報の検証、デバイスフィンガープリンティング、自動化シグナルなど最高水準の対策をもってしても、攻撃者は正規のユーザー活動と見分けがつかないトラフィックの中に依然として巧妙に隠れることに成功しています。

その理由の一つは、各セキュリティ制御がユーザーセッションのそれぞれ異なる部分にしか焦点を当てていないことにあります。

一見正規のユーザーに見える攻撃者が住宅用IPや商用VPNを使用している場合、複数の防御層をアラートも発動もされずにすり抜けてしまうことがあります。

これが既存のエッジセキュリティツールが抱える根本的な問題です。すなわち、背後にあるインフラに関するコンテキストの欠如です。

既存の制御が把握できること、見逃してしまうこと

アプリケーションセキュリティは複数の防御層に依存しており、それぞれが受信トラフィックについて異なる問いに答えるよう設計されています。

CDNやWAFは、リクエストの検査やポリシーの適用、既知の脅威のフィルタリング、エッジでのアプリケーション保護に非常に優れています。しかし、リクエスト単体では、一見普通に見える接続が発信元を隠すために設計されたインフラを経由していることまでは判別できません。

ボット管理は自動化を識別し、ボットと人間のユーザーを区別するのに役立ちます。しかし、悪意のあるセッションのすべてが自動化されているわけではなく、攻撃者は自動化と、正規の一般消費者トラフィックに見せかけるよう設計されたインフラを組み合わせるケースが増えています。

IDおよび認証システムは、ユーザーが名乗る本人であることを証明できるかどうかを判定しようとします。しかし、有効な認証情報を提示できたからといって、それを提示している人物が正規のアカウント所有者であるとは限りません。

デバイスおよびブラウザインテリジェンスは、エンドポイントを記述することで一定の信頼レイヤーを提供します。ただし、そのエンドポイントとアプリケーションを結ぶネットワークインフラまでは明らかにしません。

これらのシグナルは個別に見れば、価値ある不可欠な知見をもたらします。しかし攻撃者は、これらの間にある隙間を突く手口を増やしており、個々の制御には正規に見えながらも、接続の背後にあるインフラに関する重要なコンテキストを隠したセッションを作り出しています。

個々のシグナルからセッション信頼度へ

ここに、もう一段階のコンテキストが必要になります。すなわち、稼働中のセッションの背後にあるインフラに関するインテリジェンスです。Spurはこのレイヤーを提供するためにMonocle Session Enrichmentを構築しました。

Monocleは、匿名化ステータス、プロキシサービスの帰属、住宅用インフラ、新興の攻撃者ネットワークなど、リアルタイムの信頼シグナルですべてのユーザーセッションを強化します。これにより既存のエッジセキュリティスタックのインテリジェンスを拡張し、セキュリティ・不正対策チームが認証リスクを低減しつつ正規ユーザーの摩擦を抑えるような、より賢明なエッジ実施判断を下せるようになります。

MonocleはSpurが持つインターネットインフラへの可視性と、ライブのセッションテレメトリを組み合わせることで、リアルタイムの「セッション信頼度評価」を生成します。単にIPを良し悪しでラベル付けするのではなく、実施レイヤーがセッションの取り扱いを判断する際に利用できる属性を提供します。

セッション信頼度評価は次のような形になります。

{
  "allowed": false,
  "reason": "Anonymous connections blocked",
  "assessment": {
    "vpn": true,
    "proxied": false,
    "anon": true,
    "rdp": false,
    "dch": true,
    "cc": "US",
    "ip": "146.70.202.60",
    "ts": "2026-07-07T23:54:48Z",
    "complete": true,
    "id": "35ea59be-539d-4f65-b699-77ddc13c5df2",
    "sid": "test-app",
    "service": "PROTON_VPN",
    "cpd": "test-cpd-value",
    "ai_agentic": false,
    "ai_crawling": false
  },
  "decisionId": "1a08c38d-810e-4a90-8705-dd3d9a76c529"
}

この評価は3種類のコンテキストを提供します。Monocleがセッションについて観測した内容を示すシグナル、組織が設定したポリシーに基づく判定結果、そして評価の追跡を可能にするガバナンスデータです。

シグナル

「vpn」「proxied」「anon」「rdp」「dch」といった属性は、Monocleが観測したインフラおよび接続の特性を示すもので、「service」は関与する具体的なサービスを特定します。

さらに「ai_agentic」や「ai_crawling」といったシグナルは、新興のAI駆動型トラフィックに関するコンテキストを提供します。

判定

アプリケーション側にシグナルの解釈を任せるのではなく、「allowed」がその結果としてのポリシー推奨を示し、「reason」がその判断の理由を説明します。この例では、設定されたポリシーが匿名接続をブロックしているため、セッションは許可されていません。

ガバナンスと追跡可能性

「decisionId」「id」「sid」「ts」などのフィールドは識別子と時刻情報を提供し、チームが判断を特定の評価およびアプリケーションのコンテキストにまで遡って追跡する際に役立ちます。

セッションエンリッチメントの目的は、背後にあるインフラの属性を明らかにすることで、組織が自らのユーザー、アプリケーション、リスク許容度というコンテキストの中でそれらのシグナルが何を意味するかを判断し、適切なポリシーを実施できるようにすることにあります。

セッションエンリッチメントの活用: コンテキストが既存の制御をより有用にする

ある金融機関が、米国のIPアドレスからのログインに成功したとします。それ単体では特に目を引くものではありません。

しかし、セッションエンリッチメントによって、その接続が匿名であり、データセンターインフラを発信元とし、商用VPNサービスに帰属することが明らかになる場合があります。これにより実施レイヤーは重要なコンテキストを得て、より的確な認証判断を下せるようになります。

実際の運用では、既知の顧客が普段使っているデバイスからVPN経由でアクセスした場合はそのまま継続を許可する一方、新しい認証情報、見慣れないデバイス、匿名化インフラを使ったログインではMFAを発動させるといった対応が可能です。同じセッションからの高額な取引には、追加の本人確認を求めることもできます。

この原則は、アカウント乗っ取りが疑われるケース以外のユースケースにも当てはまります。

• アカウント作成時: インフラコンテキストにより、ネットワーク上の識別情報を隠蔽したり繰り返し変更したりしようとするユーザーの特定に役立つ
• 自動化された不正利用の場合: セッションエンリッチメントは、活動の分散に使われているインフラを示すことでボット検知を補完できる
• 地理的な制御の場合: 組織はIPの見かけ上の位置情報と、発信元を隠すためにVPNやプロキシインフラを使用しているセッションとを区別できる
• AI生成トラフィックの場合: 組織は、人間および自動化トラフィックに対してすでに用いているポリシーに、新興のエージェント型・クローリング型シグナルを追加できる

判断が重要になる場所で実施する

セッションエンリッチメントは、そのシグナルをすでにトラフィックが制御されている場所、つまりエッジで評価できるときに最も効果を発揮します。

Monocleは既存のエッジインフラを置き換えるのではなく、補完するように設計されています。Cloudflareなどのプラットフォームを利用している組織は、セッションエンリッチメントを既存の実施ワークフローに組み込み、シグナルの組み合わせごとにどう対応すべきかを決定できます。

その対応とは、セッションを許可すること、チャレンジを課すこと、より強固な認証を要求すること、機微な操作を制限すること、追加の分析に回すこと、あるいは完全にブロックすることなどが考えられます。

エッジセキュリティにはより良いコンテキストが必要

セッションエンリッチメントは、セッションの背後にあるインフラに関する、これまで欠けていたインテリジェンスの層を提供し、既存のエッジセキュリティ制御を補完することで、より強固な判断を可能にします。

VPN、プロキシ、その他の匿名化インフラの背後に隠れる脅威をSpurがどのように暴き出すか、ぜひご覧ください。無料で始める。