2015年7月30日7:00
トークナイゼーションについて
日本セーフネット株式会社 チーフエバンジェリスト 亀田 治伸
本稿では最近脚光を浴びているトークナイゼーションについて、日本セーフネット チーフエバンジェリスト 亀田 治伸氏に概要を説明してもらった。トークナイゼーションはトークン化と呼称されることもあるが、大事な機密データ（PAN等）を乱数に置き換える技術を差す。
暗号化との違い
個人情報保護法、マイナンバー法、PCI-DSSでも一貫して暗号化されたデータは引き続き機密データとしての取り扱いが要求されます。これは、暗号前データと暗号後データが1対1で紐付き、なおかつ数学的に関連性があり、元に戻る可能性があるためです（実装面として、現存するPCリソースでは、鍵へのアクセスなしにデータをもとに戻すことは、最新の暗号アルゴリズムでは物理的に不可能ですが、あくまで数学的な可能性の話となります）。
一方乱数で置き換えられたデータというのは、トークン化前データとトークン後データで数学的な関連性がなく、元に戻すことが不可能であるため、トークン処理がなされたデータは非機密データとしての取り扱いが可能となります。PANであれば、トークン後データによるシステムの運用の場合は、PCI-DSSの範囲外としてよいと定義されています。
クレジット業界におけるトークン化の歴史
2010年7月4日にVisaが「Best Practices for Tokenization Version 1.0」というドキュメントをリリースし、その中でトークン処理がされたPANは非機密データとして取り扱い可能と定義したのが最初といわれています。
その後、それを受け2011年8月にPCI DSSの管理組織であるPCI SSCが「PCI DSS Tokenization Guidelines」としてトークン処理がされたPANで運用されるシステムは、PCI DSSの範囲外とすることが可能、として正式にPCI DSSの一部に組み込まれています。
これらの流れは、クレジットにおける各プレイヤー（イシュア、アクワイアラ、決済スイッチ、加盟店）がそれぞれ、自分たちのセキュリティ確保のために行うべきものでしたが、その後EMVCoが2014年3月にイシュアがすべてのトークン化処理を、PAN流通前にあらかじめ処理することで、下流プレイヤーのセキュリティ負担を軽減するコンセプトが提案されており、「Apple Pay」をはじめとする、モバイルペイメント関連がこれらをサポートしたことで話題となっています。
余談ですが、PCI DSSを中心としたトークナイゼーションは「Tokenization」、EMVCoにて定義されたトークナイゼーションは「Tokenisation」とスペルが異なっておりますが、これはアメリカ英語とイギリス英語の違いとなります。英語原文を読む際は、これらの違いに注目いただくとよりわかりやすく区別できますが、日本語では一緒となっています。
乱数処理の許容範囲
通常16ケタのクレジットカードを乱数処理する際に、16ケタすべてを乱数に置き換える必要があるのでしょうか。実はこれもすでに先ほどご紹介したドキュメントの中で定義されています。
運用を考えると、一部の生データが残っている方が、ユーザーとのやり取りなどの面から利便性が高いため、上記の中6という方式が良く実装では採用されます。特にコールセンターなど、ユーザーサポートは先頭6ケタとした4ケタおよびユーザー氏名でほぼ100%ユーザーの特定が可能となります。
トークン化システム導入時の注意点
トークン処理を行うときの実装時における注意点を以下にいくつか実例として挙げさせていただきます。トークナイゼーションは暗号化と比べるとまだ歴史も浅く、QSA側の解釈もゆらぎがあるため、事前にいくつかの摺合せがQSAと必要になります。
１．Luhnチェックと銀聯カード
PANを乱数に置き換えた場合、たまたま利用可能なクレジットカード番号になる可能性はあるのでしょうか。クレジットカード番号は実はどの会社もすべて同じロジックで生成されています。このロジックがLuhnチェックというものですが、10％の確率で、再度使用可能なクレジットカード番号になります。トークナイゼーション処理を行う製品をご採用いただく際には、有効なクレジットカード番号をはじく機能が備わっていることをあらかじめご確認いただく必要があります。
1点ご注意点としては、広く流通しているカードの中で、銀聯カードだけはLuhnチェックアルゴリズムを採用しておらず、トークン処理後も有効なクレジットカード番号となる可能性があります。この取り扱いについては事前にQSAとの摺合せが必須となります。
２．CVVと有効期限
CVVと有効期限データはPCI DSSではそれぞれセンシティブ認証データ、カード会員データとなり、PCI DSSにおいてもその取り扱いは定義されています。ただしそれはあくまでPAN（暗号の有無にかかわらず）とセットで取り扱われる場合に限定されており、単独でCVVや有効期限が存在している場合の取り扱いには、その解釈にかなりゆらぎが生じます。
上記に申し上げた通りトークン化されたPANは非機密データですから、仮にトークン化されたPAN、CVV、有効期限がセットで漏洩したとしても事故は論理上おきません。
たとえば、私が普段利用しているカードのCVVは375,有効期限は2017/06ですが、これらのデータを機密とすべきかどうかについても、事前にQSAとの摺合せが必要となります。
３．DataVault（データ金庫）
DataVaultとは、上記のドキュメントの中で定義されている概念です。
PANをトークン処理した後に、PANとトークン化されたPANをペアで保存し暗号化されているデータベースのことを差します。米国では原則そのデータベースは代替コントロールが許容されず、必ず暗号化されなければならないとされていますが、日本ではまだこのあたりの解釈に対するコンセンサスがありませんので注意が必要です。
また、DataVaultは必ずネットワークがVLANなどでセグメント化されそのアクセスが厳しく制限される必要があります。たとえば、トークナイゼーションシステムが導入されたECサイトがあったとします。サポート目的でコールセンターは【先頭6ケタ】【後ろ4ケタ】【有効期限】【氏名】だけの情報を持っていることとなります。この時に万が一に備えて、コールセンターのスーパーバイザーだけは16ケタのPANを入手できるようにした場合、スーパーバイザーのPCが接続されるネットワークはPCI DSS対象となり、最悪コールセンター全体がPCI DSS準拠となる必要があるため、トークナイゼーションの意味がなくなってしまいますので、注意が必要です。
トークナイゼーションはうまく利用すると、セキュリティ向上とコスト削減を同時に実現可能な強力なコンセプトを秘めていますので、是非そのご利用をご検討いただければと思います。
