IPv6 と金融サービス

冨田

IPv6 と金融サービスの目次

  • IPアドレスと金融サービス
  • ケースとリスク
  • IPv4通信の場合
  • IPv6通信の場合
  • クライアントがIPv6シングルスタックでサーバがIPv4のみ対応の場合
  • 対策

こんにちは。CTOの冨田です。 また投稿間隔が開いてしまいました。 普段の業務の中から切り出して皆さんに発信できることは思ったほどありませんね。

以前よりアナウンスされていましたが、ついに2月1日よりNTTドコモによるIPv6シングルスタック方式の提供が開始されました。 ドコモ社は日本有数の移動体通信事業者です。 ドコモ社がIPv6シングルスタックを開始することでkippのサービスを利用されるお客様の端末の接続環境の無視できない割合が影響を受けると予想されます。 またドコモ社の取り組みに倣い、他の移動体通信事業者も同様の取り組みを検討するでしょう。

移動体通信に限らずIPv6活用の取り組みは広く行われています。 多くの固定回線プロバイダがIPv6のオプションを提供しています。 実際にGoogleサービスへのアクセス統計を見ると執筆時点で日本からのアクセスの43%がIPv6で行われていると分かります。

本記事ではIPv6が普及していく、さらにはIPv4を持たない端末が増えてくる状況で金融サービス提供者が何をするべきか考察します。

IPアドレスと金融サービス

IPアドレスはインターネット通信において機器を識別する値です。 ある機器から宛先の機器にパケットを送信し、その返信を受け取るという通信の基本動作はIPアドレスによる発信元、送信先の指定によって実現されます。 なお本稿では金融サービスに限ってお話しするため、ローカルエリアネットワーク内でのIP通信に言及せずインターネット上の通信のみを扱います。

金融サービスをはじめとするインターネットサービスの多くはサービスプロバイダがサーバを提供し、エンドユーザがクライアントになります。 エンドユーザの機器からサーバに送られたIPパケットの送信元IPアドレスはエンドユーザの環境について一定の情報を持ちます。 この情報はサービスの利便性、安全性を向上する役に立つため、多くの事業者が送信元IPアドレスを記録、分析しています。

たとえばIPアドレス帯と国を紐づけるデータベースを利用し、送信元の国を推定できます。 kippは日本国内向けにサービスを提供しており、ほとんどの利用者は日本国内で利用しています。 直前まで日本国内からアクセスしていた利用者が突然国外の遠い地域からアクセスした場合、不正アクセスの被害に遭っている疑いがあります。 あるいは同一送信元IPアドレスから大量のアカウントを操作している場合、利用規約に反して複数アカウントを取得している懸念があります。

こういった推定は不確実です。 IPv4アドレスによる推定にまつわる誤検知のリスクはよく知られています。 たとえば学校や会社から複数の利用者が同時にアクセスすることで複数アカウント検知を発火させる恐れがあります。 IPv4アドレスと国の対応付けデータベースが更新されておらず、日本国内からのアクセスが国外からのアクセスと判定されサービスが利用できなくなった事例もあります。

それでは、IPv6利用が普及した状況でIPアドレスによる推定はどんな影響を受けるのでしょうか。 サービスプロバイダはどう対応するべきでしょうか。

ケースとリスク

具体的にサーバ・クライアントのそれぞれの状況の組み合わせについてリスクを分析していきます。 まずサーバ側にはIPv6とIPv4両方に対応しているケース(IPv6/IPv4デュアルスタック)とIPv4のみに対応しているケースを考えます。 IPv6のみに対応する運用は現在のエンドユーザのIPv6利用可能率を考慮すると実用的ではないため省きます。

次にクライアント側はIPv4のみ利用できるケース、IPv6のみ利用できるケース(IPv6シングルスタック)、IPv6/IPv4両方利用できるケースがあります。 IPv6シングルスタックではドコモの事例のようにインターネットサービスプロバイダによってIPv4アドレス変換されることがほとんどですので、変換機能を仮定します。

サーバ2パターン、クライアント3パターンの掛け算をすると6パターンですが、今回興味があるのはサーバ側の対応です。 サーバの受け取るIPパケットがIPv6パケットかIPv4パケットかでおおまかに場合分けできます。

IPv4通信の場合

伝統的なケースです。 前の節で議論したようにIPv4アドレスの利用は長く行われており、弱点も含めてよく知られています。

IPv6通信の場合

サーバとクライアントがともにIPv6対応している場合、IPv6で通信します。 ともにIPv6/IPv4デュアルスタックの場合、Happy EyeballsによりIPv4が利用されることもあります。 上述の「IPv4通信の場合」に該当するので、取り立てて議論する必要はありません。

サーバがIPv6アドレスを記録、利用する場合、追加で注意すべきことがあります。

  1. IPアドレスの構造が違います。 IPv4アドレスは32ビット値であり、文字列表現としてはピリオド句切りの4つの10進数値の組がよく用いられます。 IPv6アドレスは128ビット値であり、文字列表現も16進数とコロンを使います。 IPアドレスを保存するデータベースカラムを32ビット値のみに対応した整数型や15文字までの文字列型にしているとIPv6アドレスを保存できません。 初歩的なミスなので、検証中にすぐ気がつけるでしょう。
  2. 同一拠点でも別機器のIPv6アドレスは異なります。 小規模なエンドユーザの拠点、すなわち一般的な家庭を想定しています。 一般的な家庭ではグローバルIPv4アドレスを1つだけ利用し、NAT(network address translastion)機能によって複数の端末が1つのグローバルIPv4を共用します。 IPv6環境の場合、拠点にはプロバイダからグローバルルーティングプレフィックスが割り振られます。 それにルータがサブネット識別子を付加し通常64ビットのサブネットプレフィックスを作ります。 さらに各機器が64ビットのインタフェース識別子を持ち、全体で128ビットのIPv6アドレスになります。 IPv6アドレスではグローバルルーティングプレフィックス部を把握する方法がなく、IPv4アドレスに比して同一拠点判定の信頼性が揺らぎます。 グローバルルーティングプレフィックスは64ビットがよく見られますが、48ビットを割り当てるケースもあるようです(フレッツにおけるIPv6接続について(PDF)。古い資料です)。
  3. 同一機器からのIPv6アドレスも経時的に変わります。 前項でも言及したインタフェース識別子が機器に対して固定だとIPv6アドレスが同じなら同一拠点の同一機器と識別できますし、機器を移動しても別拠点の同一機器と識別できます。 これはセキュリティ、プライバシーの観点で懸念があります。 この懸念を解消するため、いくつかのIPv6アドレスの自動設定技術は定期的にインタフェース識別子を変更します。 たとえばRFC8981で定義されるTeporary IPv6アドレスは1日程度でIPv6アドレスを変更します。

クライアントがIPv6シングルスタックでサーバがIPv4のみ対応の場合

「IPv4通信の場合」があえて詳細に分析されずわずか2文で終わったことに違和感を感じた方は鋭いです。

大嘘です。 IPv6アドレスしか持っていない端末がIPv4アドレスしか持っていないサーバに接続したくても、直接はできません。 だれかが間を取り持つ必要があります。 ドコモ社の資料の図にもあるとおり、このケースでは交換局が端末のIPv6アドレスからIPv4アドレスに変換します。 サーバと交換局の間はIPv4通信、交換局と端末の間はIPv6通信になります。 IPv4アドレスを収集しているサーバは、端末のIPアドレスのつもりで交換局のIPアドレスを掴まされています

実際に交換局がどの程度の数のIPv4アドレスを利用するのかわかりませんが、IPv6アドレスと同数ではありえないでしょう。 交換局はNAT的に動作していると仮定するのが自然です。 IPv6シングルスタッククライアントが多数いる状況では多くのネットワーク技術に詳しくないエンドユーザが交換局のIPv4アドレスでアクセスしてくる状況が生まれます。

従来もエンドユーザがプロキシサーバやVPNを利用していて、サーバの受け取るIPv4アドレスがエンドユーザ自身のIPアドレスでないケースはありました。 しかしその率は無視できるほど低く、エンドユーザ側もなんらかの意図があって利用していたと考えられます。

この状況で従来型のIPv4アドレス分析をすると多数の一般的なエンドユーザに対して偽陽性を発生させるでしょう。 同一拠点判定で利用停止を実施しているならば、実際には全く関係のない多数のユーザが同一拠点からのアクセスとされ、一斉に利用停止されてしまいます。 これが本稿で取り上げる最大のリスクです。

対策

以上のリスクに対する対策を考えましょう。 まず「クライアントがIPv6シングルスタックでサーバがIPv4のみ対応の場合」ですが、サーバがIPv6に対応するか、IPv4アドレスの一致判定を止めるしかありません。 ドコモ社が利用しているIPv4帯を確認してそれだけ無視リストに登録するといった運用も考えられますが、今後IPv6シングルスタック通信を提供する通信事業者が増えることを想定すると無益な努力でしょう。

IPアドレスによる判定を止める、あるいは重要度を落とすのは価値ある判断です。 サービスプロバイダはIPアドレスの扱いにおいてもプライバシーを尊重するべきです。 非技術者のなかにはIPアドレスを住所と同じように本人や所在地を同定できる情報だと信じている人もいます。 この信念はIPv4アドレスのみ取っても大きな間違いであり、IPv6の普及に伴ってますます信頼性が揺いでいます。 IPv6シングルスタックの導入は信頼性が十分でない中でIPアドレスの分析がビジネス的価値を生むのか問い直す良い機会です。

IPアドレスの利用を続けるならば、サーバをIPv6/IPv4デュアルスタックに変更し、かつIPアドレス処理の仕組みをIPv6/IPv4両対応させましょう。 kippでは全てのサービスにALBを利用しています。 ALBは設定変更でデュアルスタックにできます

「IPv6通信の場合」の分析から、IPv6アドレスを取り扱う際に保存と比較に注意する必要があるとわかります。 値の長さだけでなく、比較方法に依存して値の保存方法を考慮すべき点にも注意しましょう。 たとえば先頭64ビットだけ比較すると決めたら、その比較をデータベース上で効率よく実施できる保存方式を採用します。 極端な例ですが、IPv6アドレス全体のハッシュ値を保存していた場合、検索不可能になります。 文字列表現で保存して前方一致検索するのか、数値表現で保存して数値の範囲で検索するのか、保存時に先頭64ビットを切り取って別カラムに保存するのか、データベース製品の特性を調査し決定します。

同一拠点のチェックのためIPv4アドレスが同一であるという推定を使っていたならば概ね先頭64ビットが同一であるという比較に置き換えてよいでしょう。 その上で過去にIPv4アドレスチェックで偽陽性が頻発していたならばIPv6の特性を生かし条件を調整する余地もあります。

すべての対応を実施してもなお、IPアドレスによる所在地や同一性の判定は不確実性のあるものです。 ビジネス設計全体にこの不確実性を織り込むべきです。 たとえばIPアドレスだけを根拠にアカウントを停止するのは悪手です。 決済行動やアクセスタイミングなど複数の情報ソースを参照し、重み付けして判断しましょう。

不正判定はどうしても偽陽性を生むことがあります。 ユーザの行動を制限する前にサービス運営者が判定結果をチェックしたり、ユーザに確認のメッセージを送るのも重要です。 ユーザからの異議があった場合はユーザの虚偽を警戒しつつ、システムの誤判定や実装ミスも考慮して誠実に対応すべきです。

kippでは業界や世間の動向に素早く反応してサービスを改善するため、開発者の採用を強化しています。 また不正利用判定のような多くのログ、属性情報を組み合わせて信頼性の高い判断を下すデータ分析も改善を計画しています。 このような業務に興味をお持ちの方はお気軽にpeople@kipp-corp.comまでご連絡ください。