ログイン時のVPN検知：セキュリティとユーザー体験のちょうどよい均衡

セキュリティエンジニアにとって、強固な防御とスムーズなユーザー体験の両立は常に悩ましいテーマです。ログイン時にVPN、proxy、TORの出口ノードを検知したいという要件は、規制対応、不正利用対策、地域制限の運用など、さまざまな理由で生まれます。一方で、判定を厳しくしすぎると、正当なユーザーまでログインしづらくなり、サポート問い合わせの増加にもつながります。

この記事では、ログイン時にこれらのサービスを見極めるための実践的かつ技術的なアプローチを整理します。重視するのは、誤検知を抑えながら、ユーザー体験を損なわない運用です。

Why Detect VPNs at Login?

検知の仕組みに入る前に、まず「なぜ検知するのか」を明確にしておくことが重要です。主な目的は次の通りです。

• Fraud Prevention: 攻撃者は、発信元を隠したり、レート制限を回避したり、アカウント乗っ取り対策をすり抜けたりするために、proxy、VPN、TORを頻繁に利用します。これらを識別できれば、不審な行動を示す強いシグナルになります。
• Compliance & Geo-restrictions: サービスによっては、地域ごとのライセンス契約や規制上の制約に従う必要があります。その場合、ユーザーが実際に特定の地域からアクセスしているかを確認することが求められます。
• Security Posture: VPNの利用そのものが悪いわけではありません。ただし、商用VPNやいわゆるbulletproofホスティングなど、特定のネットワーク経由の通信は、他の不審な兆候と組み合わさることで高リスクと判断すべき場面があります。

Core Principles for Login-Time Detection

実在するユーザーを不必要に困らせないためには、単一の条件で一律に遮断するのではなく、多層的に判断する設計が欠かせません。特に意識したいのは次の4点です。

• Passive Detection: ユーザーに操作を求めず、バックグラウンドでIPインテリジェンスを取得します。
• Contextual Analysis: IPのリスクだけで判断せず、デバイスID、過去の行動履歴、ユーザー名とパスワードの妥当性など、他のログインシグナルと合わせて評価します。
• Tiered Response: いきなりブロックするのではなく、MFA、CAPTCHA、行動分析などを段階的に組み合わせます。境界線上のケースほど、追加確認にとどめる設計が有効です。
• Prioritize High-Confidence Signals: 悪意の可能性が高いシグナルには素早く対応しつつ、曖昧なフラグには慎重に向き合います。

IP Intelligence Signals for VPN/Proxy Detection

現在のIPインテリジェンスAPIは、大量のデータを集約し、IPアドレスの性質を分類します。VPNやproxyの検知で活用したい代表的なシグナルは次の通りです。

1. Hosting Provider / Datacenter IP

• What it is: 一般家庭向けISPではなく、AWS、Azure、Google Cloudなどのクラウド事業者、専用サーバー事業者、コロケーション施設に属するIPアドレスです。
• How it helps: 多くの正当なユーザーは、住宅向け回線やモバイル回線からサービスにアクセスします。特に一般消費者向けサービスでデータセンター由来のIPからログイン試行がある場合、不審なアクセスとして扱う価値があります。無料VPN、商用VPN、proxyは、こうしたIPレンジ上で運用されていることが少なくありません。
• Limitations: 正当な法人ユーザーが、データセンター上に構築された企業VPNを経由して接続することもあります。また、APIクライアントや特定のエンタープライズツールでは、データセンターIPからのアクセスがむしろ通常動作である場合もあります。文脈の理解が不可欠です。

2. TOR Exit Node

• What it is: TOR匿名ネットワークの既知の出口ノードとして特定されているIPアドレスです。
• How it helps: TORは匿名性を目的として利用されます。正当な用途もありますが、攻撃者が追跡を避けたり、アクセス元を隠したりするために使う典型的な手段でもあります。TOR出口ノードの検知は、匿名化利用を示す信頼度の高いシグナルです。
• Limitations: TORを全面的にブロックすると、プライバシーを重視する正当なユーザーにも影響します。サービスの性質や脅威モデルに応じて、即時ブロックにするのか、リスクスコアを引き上げるにとどめるのかを決める必要があります。

3. Commercial VPN / Proxy Service

• What it is: NordVPN、ExpressVPNなどの既知の商用VPN事業者、あるいはオープンproxy／プライベートproxyネットワークに明示的に紐づくIPアドレスです。
• How it helps: ユーザーの位置情報や身元を隠す目的で提供されているサービスを直接識別できます。VPNやproxy利用を示すシグナルとしては非常に強力です。
• Limitations: これらのサービスはIPレンジを頻繁に変更・拡張するため、最新のリストを維持し続けるのは簡単ではありません。この領域では、専門のIPインテリジェンスプロバイダーを活用することが重要です。

4. rDNS Hostname and ASN Information

• What it is:

rDNS (reverse DNS) hostname: IPアドレスに対応するドメイン名です。たとえば `ec2-xx-xx-xx-xx.compute-1.amazonaws.com` のように、プロバイダーの手がかりになることがあります。 ASN (Autonomous System Number): ネットワークに割り当てられるグローバルに一意な識別子です。たとえば Amazon.com, Inc. の場合は ASN 16509 です。

• How it helps: こうした低レイヤーのネットワーク情報は、IPの性質を裏づける材料になります。クラウド事業者やVPNサービスを示すrDNSホスト名に加え、一般的な住宅向けISPではないASNが確認できれば、他のシグナルの確度を高められます。
• Limitations: rDNSレコードは汎用的だったり、そもそも設定されていなかったりします。また、ASNだけでIPの用途を完全に判断することはできません。追加の文脈が必要です。

5. IP Risk Score

• What it is: IPアドレスに関連する総合的なリスクを数値化したものです。多くの場合、0-100の範囲で表されます。上記のシグナルに加え、過去の悪用履歴、ボットネットとの関連、スパム活動などを組み合わせて算出されます。
• How it helps: 個別のフラグをそれぞれ処理する代わりに、統合された指標として扱えます。たとえば、スコア >70 でMFAを要求し、スコア >90 で一時的にブロックするといったしきい値運用が可能です。
• Limitations: リスクスコアの解釈は、アプリケーションの性質やユーザー層に合わせて調整する必要があります。あるサービスで「高リスク」と見なされるスコアが、別のサービスでは「中程度」にすぎないこともあります。

Implementing Detection without Annoying Users

ユーザー体験を損なわずに検知を導入するには、次のような段階的アプローチが現実的です。

• Passive IP Lookup: すべてのログイン試行で、バックグラウンドにてIPインテリジェンスの照会を行います。ユーザーを待たせないよう、処理は高速であるべきです。目安としてはsub-100msに収まる設計が望ましいでしょう。
• Initial Triage (Low Friction):

High Risk (e.g., TOR exit, known malicious IP, very high risk score): ただちにMFAまたはCAPTCHAを求めます。すでにMFAが必須の環境であれば、追加の精査を適用します。 Medium Risk (e.g., generic commercial VPN, datacenter IP for consumer service, moderate risk score): まずはイベントを記録し、将来の分析に使えるようにします。新しいデバイス、不自然な地理的位置、複数回のログイン失敗など、他の不審な行動シグナルと組み合わさった場合に、MFAやCAPTCHAへエスカレーションします。 Low Risk (e.g., residential ISP, low risk score):* 追加の介入なしにログインを進めます。

• Adaptive Responses: 高リスクIPとしてフラグされた場合でも、ユーザーがMFAを正常に完了したなら、それは強いポジティブシグナルになります。そのユーザーとデバイスの組み合わせについては、一定期間、IPチェックの厳しさを一時的に緩和することを検討できます。ただし、他に強いネガティブシグナルが出てきた場合は、改めて厳格な判定に戻すべきです。