CGNATとは何か：IPアドレス1つ＝ユーザー1人ではない理由

不正利用対策のルールには、いまも「IPアドレスはユーザーを識別できる」という前提で作られているものが少なくありません。ところが、その前提はすでに何年も前から成り立たなくなっています。大きな理由のひとつが、Carrier-grade NAT（CGNAT）です。

What CGNAT is

IPv4アドレスは枯渇しました。そこで、すべての加入者に希少なIPv4アドレスを割り当てる代わりに、モバイルキャリアや多くの固定回線ISPは、加入者を共有のグローバルIPアドレスプールの背後に置き、外向き通信の際にポートを変換しています。つまり、1つのグローバルIPアドレスの裏側に、数百から数千の世帯や端末が同時に存在することがあります。

サーバー側から見ると、それらの通信はすべて「同じ1人のクライアント」から来ているように見えます。

What it breaks

Blocking. ブルートフォース攻撃を検知してIPアドレスをBANしたつもりが、モバイルネットワーク上の地域一帯の正規ユーザーまで締め出してしまうことがあります。一方、攻撃者は再接続するだけで数秒後には同じプール内の別のIPアドレスを取得し、攻撃を続けます。

Rate limiting. 「1 IPあたり1分間に10リクエスト」という制限は、1人のユーザーに対しては寛容でも、2,000人の加入者が同じ出口IPを共有している場合にはあまりにも厳しすぎます。ピーク時間帯には正規ユーザーを知らないうちに絞り込み、彼らは何も言わずに離脱していきます。

Attribution. 「同じIPから2つのアカウントが使われている」という事実は、キャリアネットワーク上では複数アカウント利用の強い証拠にはなりません。住宅向け光回線なら一定の意味を持つかもしれませんが、CGNAT環境ではほとんど意味を持たないこともあります。

Analytics. IPアドレスを基準にユニークビジター数を数えると、モバイルでは実際より少なく見え、頻繁にアドレスがローテーションされるネットワークでは実際より多く見えます。どちらの誤差も、ダッシュボード上では気づきにくいものです。

How to tell you are looking at CGNAT

次のようなシグナルが見えたら、CGNATの可能性を疑うべきです。

• 接続タイプがmobileと判定されている、またはASNがモバイルキャリアに属している。
• 1つのIPアドレスからのリクエストの多様性が非常に高い。たとえば、多数のユーザーエージェント、アカウント、ロケールが混在している。
• 転送ヘッダー内に、共有アドレス空間（100.64.0.0/10）のアドレスが現れている。

IP intelligenceのルックアップを使えば、最初の2つは直接取得できます。これだけでも、リクエスト時点でポリシーを切り替えるには十分です。

What to do instead

• ネットワーク種別に応じて制限を調整する。 住宅向け回線には厳しめのIP単位制限を適用します。一方、モバイル回線やビジネス向けレンジには、IP単位の制限を大きく緩め、その代わりにアカウント単位やデバイス単位の制限を強めます。
• 識別の軸を一段下げる。 可能な限り、アカウントID、セッション、デバイスシグナルを基準にレート制限を行います。IPは主キーではなく、補助的なキーとして扱うべきです。
• ブロックよりチャレンジを優先する。 チャレンジは共有ネットワークの利用者に多少の手間をかけるだけですが、ブロックはそのネットワーク全体を連帯責任で罰してしまいます。
• 有効期限は短くする。 共有IPをどうしてもブロックする必要がある場合は、日単位ではなく分単位にします。攻撃者は、あなたのBANが残り続けるずっと前に、すでに別のアドレスへ移っています。
• 巻き添えの規模を監視する。 1つのBANによって、数件を超えるアクティブアカウントに影響が出るなら、それはそのIPアドレスが共有されているサインです。そして多くの場合、BANは適切な手段ではありません。

The underlying principle

IPアドレスは「人」の属性ではなく、「通信経路」の属性です。リスクシグナルとしては強力ですが、識別子としては非常に不安定です。この違いを理解して設計されたシステムは、そうでないシステムよりも、誤検知あたりではるかに多くの不正を止められます。IPv6の普及によって加入者単位のアドレス割り当てがある程度戻ってきたとしても、モバイルトラフィックが増え続ける限り、この問題が消えることはありません。