2010年9月29日16:12
第2回 カード会員データとセンシティブ認証データの保護
NTTデータ・セキュリティ コンサルティング本部 PCI推進室 CISSP 川島祐樹
1．カード会員データとセンシティブ認証データの保護 はじめに
第1回では、PA-DSSを含むPCI DSSフレームワークの全貌と、PA-DSSのスコープについてのポイントを解説した。第2回からは、PA-DSS要件の内容について、各要件で求められている対策の観点、および注意点を解説する。
PA-DSS要件は、PCI DSSの要件と関連した要件が並んでいるものの、PCI DSSの要件とはその順番が異なる。これは、PCI DSSが6つのカテゴリーで分けられ、要件番号が1～12と振られているのに対し、PA-DSSは特にカテゴリー分けされているわけではなく、重要な要件から順番に並んでいる。
では、何をもって‟重要”といえるのだろうか。セキュリティ対策を行う上で‟重要なもの”を優先しようとしたとき、場合によっては時間的な制約や金銭的な問題が最重要事項となりうる。PA-DSSの要件においては、‟対策を行うことによって軽減できるリスクの大きさ”をもって重要としていると考えられる。つまり、要件1の対策を行うことで、かなりのリスクを軽減できる。逆に要件14にすべて対応したとしても、セキュリティリスクは軽減できているとはいえないのである。
とはいえ、PA-DSSでは、PCI DSSで使われる‟代替コントロール”という手段を採ることができない。PCI DSSでは、要件に記載されている通りでなくても、リスク分析を行って十分に対策が施されていると判断できる場合に限り‟代替コントロール”として‟対応済み”とすることができる。しかしPA-DSSでは、代替コントロールの考え方自体が存在しないため、要件に記載されている通りに実装、対応しなければならない。よって、既存の決済アプリケーションを改修してPA-DSS対応を行おうとすると、業務プロセスやシステムの構成などによってはPA-DSSに準拠することがかなり難しくなってしまうケースもあるだろう。PCI DSSのように、暗号化を実装できない時に強固なアクセス制御やセグメンテーションを行うことで代替し、暗号化を避ける、といったことができないのである。それでもなんとか準拠しなければならない、といった際の対応方法については、本連載の最終回で触れたいと考えている。
要件に入る前に、要件1および要件2の対象となるセンシティブ認証データとカード会員データの定義を確認しておこう。
まず、センシティブ認証データとは、以下のデータのことを指す。
・完全な磁気ストライプデータ
・CAV2/CID/CVC2/CVV2
・PIN/PINブロック
また、‟カード会員データ”と表現した際は、以下のデータのことを指していることを覚えておいていただきたい（図1）。
・プライマリアカウント番号（PAN）
・有効期限
・会員氏名
・サービスコード
それでは、最も‟重要”である要件1の内容からみていこう。
要件1. 完全な磁気ストライプ、カード検証コードまたは値（CAV2、CID、CVC2、CVV2）、
または PIN ブロックデータを保存しない
リスク分析の最も基本的な考え方は、リスク分析の対象が保持している情報資産を洗い出し、それらの資産価値、脆弱性、脅威を識別して、過剰投資もしくは対策不足とならないように対策を検討、実施することである。過剰投資や対策不足となっていないことを確認するためには、費用対効果分析を行う。つまり、セキュリティ対策とは、どれだけの費用を使ってどれだけの対策を行うかに尽きるのである。そこで最も効果が高いと考えられるのは、対策を実施する対象、すなわちPCI DSSやPA-DSSにおいてはカード会員データを”持たない”ということが最大のセキュリティ対策となるのである。それを具体的に表しているのが、この要件1である。
=====引用=====
1.1 承認後にセンシティブ認証データを保存しない(暗号化している場合でも):
センシティブ認証データには、以下の要件1.1.1-1.1.3で言及されているデータを含む。
==============
これらのデータについては、決済を取り扱う企業にとってはご理解いただけると考えられるので詳細な説明は割愛するが、承認（オーソリゼーション）時にのみ必要となるデータであるため、承認処理が完了した後は保持してはならない。センシティブ認証データを持つことで、カード偽造やなりすましが非常に容易に行えるようになるため、普段目にすることの多いプライマリアカウント番号（16桁のカード番号）よりも悪意のあるユーザに狙われやすいのである。
本要件について、アプリケーション審査を行うPA-QSAはどのように確認を行うのかは、”テスト手順”で確認することができる。
=====引用=====
1.1 センシティブ認証データ(以下の1.1.1-1.1.3を参照)が承認後に保存された後で削除される場合は、データを削除する方法を入手してレビューし、データが回復不能であることを判断します。
以下のセンシティブ認証データの各アイテムについて、多数のテスト取引を完了した後で、ペイメントアプリケーションのすべての機能をシミュレートする以下の手順を実行して、エラー状況を生成してログエントリを取り込みます。
=============
PA-QSAは、決済アプリケーションを実際に操作し、例えば磁気ストライプデータを読み込む処理から取引処理までを複数回行い、承認処理が完了した後状態で磁気ストライプデータが保管された状態でないかを確認する。どのような場所を、どう確認するかについてはテスト手順1.1.1-1.1.3に記載されている。
=====引用=====
フォレンジックツールもしくはフォレンジック手法（あるいはその両方）を使用して、ペイメントアプリケーションによって作成されるすべての出力を調べ、◯◯◯（センシティブ認証データの各項目）が承認後に保存されないことを確認します。以下の種類のファイル（およびペイメントアプリケーションによって生成されるその他すべての出力）が含まれます。
・受信トランザクションデータ
・すべてのログ（トランザクション、履歴、デバッグ、エラーなど）
・履歴ファイル
・トレースファイル
・不揮発性キャッシュを含む、不揮発性メモリ
・データベーススキーム
・データベースコンテンツ
============
さまざまな種類のデータ保管先が挙げられているが、これら任意の項目を調査するのではなく、すべての項目を調査しなくてはならない。データベースが存在しない等、対象が存在しない場合もあるが、‟あらゆる書き込み先”と考えていただきたい。よって、ここに挙げられていない場所にデータを書き込む、もしくは書き込まれているおそれがあるような場合、ここに挙げられていない場所でも調査対象となる。ではどのように調査を行うかというと、‟フォレンジックツールもしくはフォレンジック手法”を用いた調査となる。これは、単純な検索処理等だけではなく、例えば削除されたはずのファイルが断片的に残ってしまっているようなケースも発見できるような手法やツールを使用するということになる。どのような手法やツールを使用するかはPA-QSAによって異なるが、削除したつもりのデータも、ツールひとつで簡単に復元し、取り出すことができてしまうことを覚えておいていただきたい（図2）。
要件1には、上記でとりあげた1.1以外にも、バージョンアップ時に以前のバージョンで書き込んだ可能性のあるデータの削除や、トラブルシューティング時のデータ収集時の削除など、センシティブ認証データを保存しないようにするための要件がある。アプリケーションで対応することも重要だが、顧客やリセラー、インテグレーター向けに提供する手順書など、プロセスに関する要件もあるのでご注意いただきたい。
⇒⇒第2回 カード会員データとセンシティブ認証データの保護（2）へ
⇒⇒第2回 カード会員データとセンシティブ認証データの保護（3）へ
