第9回 決済アプリのセキュリティ基準、PA-DSSとは
川島 祐樹
NTTデータ・セキュリティ株式会社
コンサルティング本部 PCI推進室
CISSP
2010/2/24
PA-DSS実装ガイド
PA-DSSは、開発を行うベンダと、それを実装するリセラーやインテグレータ、そのアプリケーションを運用する加盟店などがかかわってきます。アプリケーション自体にセキュリティ設定が施されていても、実環境において、その設定を変更したり、想定されていない方法で使われてしまうと、PCI DSS準拠を妨げる結果となってしまう可能性があります。
このため、PA-DSS準拠のアプリケーションにはPA-DSS実装ガイドが必ず付属します。実装ガイドに記載しなければいけない内容は、PA-DSSの14要件の中に散在していますが、それらの内容は付録文書に抽出されてまとめられています。このため、実装ガイドに関しては、付録文書を見て、一覧の項目を網羅する形で作成すればよいでしょう。
PA-DSS要件概説
それでは、実際のPA-DSS要件の内容に入ってみましょう。PA-DSSのセキュリティ評価手順は下記のPCI SSCのWebサイトからダウンロードできます。日本語版もありますので、ぜひ読んでみていただければと思います。
| 【関連記事】 Payment Application Data Security Standard (PA-DSS) V1.2 https://www.pcisecuritystandards.org/security_standards/pci_pa_dss.shtml |
◆要件1：完全な磁気ストライプ、カード検証コードまたは値（CAV2、CID、CVC2、CVV2）、またはPINブロックデータを保存しない
PCI DSS要件3に含まれる内容のうち、センシティブ認証データに関する取り扱い方法を要求しているものです。オーソリゼーション後、センシティブ認証データは保管してはいけません。特に磁気ストライプデータにはカード会員番号なども含まれていますが、ここで求められているのは、磁気ストライプデータすべてをそのまま保管してはならないという意味になりますので、そこの含まれるカード会員番号や有効期限、氏名などが業務上必要である場合は、必要な情報のみを取り出し、保存することが求められます。
この要件で特徴的な部分を引用します。
| ◆要件1.1.1： フォレンジックツールまたはフォレンジック手法（あるいはその両方）（市販ツール、スクリプトなど）を使用して、ペイメントアプリケーションによって作成されるすべての出力を調べ、カード裏面の磁気ストライプからすべての追跡内容が承認後に保存されないことを確認します。 |
フォレンジックツールもしくはフォレンジック手法を使用して、とありますが、その脚注として以下の説明があります。
| ◆フォレンジックツールまたはフォレンジック手法： フォレンジックデータを発見、分析、提示するためのツールまたは手法で、コンピュータエビデンスを迅速かつ徹底的に認証、検索、回復するための確実な方法を提供します。PA-QSA が使用するフォレンジックツールまたは手法の場合は、ペイメントアプリケーションが書き込むセンシティブ認証データを正確に見つける必要があります。これらのツールは、市販、オープンソース、PA-QSA による社内開発のいずれでも構いません。 |
PA-QSAはこれらの要件の調査を行うとき、アプリケーションに対して、フォレンジックツールまたはフォレンジック手法を使用し、本当にカード会員データ（センシティブ認証データ）が残っていないかを確認することになります。
筆者の在籍するNTTデータ・セキュリティでは、これらの確認を行うとき、おもにマイクロソフトが提供するSysinternalsのツールや、EnCase Forensicなどを使用しています。一例を紹介すると、決済アプリケーションもしくは関連するプラットフォームにおけるプロセス、それに関連するAPIやディスクアクセスを調査したり、書き込まれたディスクの内容を低レイヤで調査したり、パケットキャプチャを行って流れている通信に含まれているデータを調査したりします。このため、データを削除する際には確実に削除する必要があります。これらの手法の詳細については、また別の機会に紹介できればと思います。
| 【関連記事】 Windows管理者必携、Sysinternalsでシステムを把握する http://www.atmarkit.co.jp/fsecurity/column/ueno/43.html |
要件1では、以下の場所にセンシティブ認証データが存在しないことを確認します。
- 受信トランザクションデータ
- すべてのログ（トランザクション、履歴、デバッグ、エラーなど）
- 履歴ファイル
- トレースファイル
- 不揮発性キャッシュを含む、不揮発性メモリ
- データベーススキーム
- データベースコンテンツ など
例えばデータベースが存在しない場合、データベーススキームや、データベースコンテンツなどはN/Aとなるなどの例外はありますが、基本的にすべての項目が調査対象になります。決済アプリケーションでは、これらの項目を含む、いかなる場所にもセンシティブ認証データを保存しないことを徹底する必要があります。
◆要件2：保存されるカード会員データの保護
この要件では、まずカード会員データが存在する場所の一覧を明確にする必要があります。表示するときはマスキングする必要があり、保存するときは暗号化など読み取り不能にする必要があります。読み取り不能にする方法については、第8回「データ保護と暗号化はイコールではない？」を参照していただければと思います。
マスキングについては、表示してよいのはカード番号の先頭の6けた、下4けたと、PCI DSSと変わりありません。16けたすべてを閲覧する業務上の理由がある場合はマスキングは不要ですが、利便性のためや、過去のバージョンと表示を合わせたいといった理由は認められません。
暗号化する場合はPCI DSSと同様の鍵管理が求められますが、特に暗号化に使用する要素を削除する方法についても明確にする必要があります。顧客、リセラー、インテグレータ向けにも実装ガイドで削除方法を明確に示す必要があります。
◆要件3：安全な認証機能の提供
要件3はPCI DSSの要件8に該当するもので、主に認証に関する要件になります。一意のユーザーIDを使用すること、決済アプリケーションにデフォルトの管理アカウントを使用させてはならないこと、パスワードは保存するときには暗号化することなどが挙げられます。
PA-DSSとして特徴的なのは“導入した時点で、一意のユーザーIDおよび安全な認証が使われるようになっていること”という要件でしょう。また、それらの設定を変更すると、PCI DSSに準拠しなくなることを実装ガイドに明記することなどが求められます。例えば決済アプリケーションをインストールしたとき、その決済アプリケーションが「sa」アカウントを使い、パスワードはデフォルトではNULLである、というようなアプリケーションはこれらの要件に非対応になります。
このような要件は、実際には決済アプリケーション以外のアプリケーションやアプライアンスにもいえることだと筆者は考えています。はじめて導入する新しい製品やアプライアンスがあり、例えばデフォルトの設定で「admin」というユーザー名と、「admin」というパスワードだったとします。ユーザーはデフォルトのユーザー名とパスワードを変更するでしょうか。おそらく変更することはなく、そのまま運用するパターンが多いでしょう。そして、そのアプリケーションのデフォルトユーザーIDとパスワードが、インターネット上の「デフォルトパスワードリスト」に掲載され、悪意のある行為に活用されるわけです。
一般論として、ネットワーク機器や通常のアプリケーションについても、管理者アカウントは初回ログイン時にパスワードの変更を求める、という機能が必要ではないかと常々思います。
◆要件4：ペイメントアプリケーションの動作のログ
決済アプリケーションでは、監査証跡を取得することが求められています。よって、必ずログを取る必要があります。
取得する証跡の契機や項目については、PCI DSS要件10.2.1から10.2.7、および10.3.1から10.3.6が参照されており、これに応じて取得する必要があります。要件4はPA-DSSには2項目しか記載されていませんが、この参照されている部分に対応する必要があります。また、導入時点で監査証跡の取得が有効になっていること、もしくは有効にする方法が明確になっている必要があります。
◆要件5：安全なペイメントアプリケーションの開発
文書化されたソフトウェア開発プロセスが必要です。要件定義や設計、試験などの各フェイズでのセキュリティ対策が求められます。これはPCI DSSでも同様です。
例えば、OSインストール直後の不要なアプリケーションの無効化や削除、設定の変更、アプリケーションの不要なモジュールの削除や設定変更は設計段階で検討する必要がありますし、コーディング時にはコード作成者以外のコードレビュー、もしくは自動のコードレビューなどが必要となります。Webインターフェイス（HTTPインターフェイス）を持っていればOWASPガイドラインなどに従ってコーディングやテストをしなければならないのも、PCI DSSと同様です。
| 【関連記事】
Security&Trustウォッチ（47） Webアプリケーションを作る前に知るべき10の脆弱性 http://www.atmarkit.co.jp/fsecurity/column/ueno/47.html |
◆要件6：ワイヤレス送信の保護
PCI DSS同様、ワイヤレス関連の要件も求められます。特にアメリカではワイヤレスを使っている決済アプリケーションからカード会員データを盗み出される事件が多く発生しており、日本でも同様のリスクがあると考えられます。なお、ワイヤレスを使用しない決済アプリケーションでは、この要件はN/Aとなります。現実的には、WEPしか使っていない、しかも数十台、数百台設置されているアクセスポイントですべて共通の鍵が使用されている現場がいまだに存在します。
この要件のポイントは、まずWEPを使わないこと、そして強力な暗号化を使用することです。ワイヤレスに関する詳細については、PCI SSCから以下の文書が公開されていますので、ご参照ください。
| 【関連記事】 PCI DSS Wireless Guideline https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.pdf |
◆要件7：脆弱性への対応に関するペイメントアプリケーションのテスト
この要件は日本語訳が分かりにくいのですが、既知の脆弱性、および日々発見される脆弱性に対応するため、新しい脆弱性の識別プロセスを持ち、それに対応して迅速にアプリケーションや周辺環境に適用するパッチをテスト、提供することを求める要件です。
要件7には2つの項目しかないのですが、実際にはそれほど簡単な要件ではないと考えた方がよいでしょう。パッチを実際に適用する際の信頼チェーン、つまり配布の段階から、整合性が保たれた状態でいかにアプリケーションのもとに届けられるか、整合性が合わない場合にはパッチの適用が拒否されるかが求められます。これはPCI DSSにはありませんので、PA-DSS特有の要件と考えてよいでしょう。
7.2.aでは、セキュリティパッチおよびアップグレードの開発と導入のプロセスについて、以下が含まれていることを確認します。
|
パッチなどの配布がプルかプッシュか、またはメディアによる配布かなど、さまざまな手法があるかと思いますが、不正なプログラムがパッチ適用時に混入しないことを徹底する必要があります。デジタル署名などを使うことも考えられるでしょう。また、決済アプリケーションがインターネットを使用するものか、内部ネットワークおよび専用線などプライベートであるか、なども関連する可能性があります。
◆要件8：安全なネットワーク実装の促進
この要件は、ひどくあいまいです。実際には、参照されているPCI DSS要件を見ながら確認することになります。参照されているPCI DSS要件は、1、3、4、5、6.6です。
求められているのは、PCI DSSに準拠した環境で実装できることです。例えば、ウイルス対策ソフトウェアを導入すると動かない、ファイアウォール構成で、デフォルトで「Accept」が必要、などを環境に求める決済アプリケーションは、この要件に非準拠となることになります。
◆要件9：カード会員データをインターネット接続のサーバに保存してはならない
この要件で求められるのは、主に下記の2点です。
- データベースサーバと同一のサーバ上に決済アプリケーションが実装されることを求めてはいけない
- データベースサーバがDMZ上にあることを求めてはいけない
インターネットに面した部分に実装する、もしくはインターネットに面した部分に実装するモジュールがある決済アプリケーションは、カード会員データをそのインターネットに面した部分に保存してはいけません。つまり、データベースと分離し、カード会員データをインターネットに面していない内部ネットワークに保管する必要があります。
ここではWebサーバと記載されていますが、HTTPを使っていなくとも、インターネットに面した部分に実装しうるアプリケーションについては同様の対応が求められることになります。アプリケーション自体、インターネット接続を一切使用しないのであれば、本要件はN/Aになるかもしれません。
◆要件10：安全なリモートソフトウェア更新の促進
決済アプリケーションそのもの、もしくはアップデートなどをリモートから配信することがある場合、安全なリモートアクセスを使用する必要がある、という要件です。PCI DSSと同様に、必要な場合のみリモートアクセスをONにし、完了後すぐにOFFにすることが求められます。
◆要件11：ペイメントアプリケーションへの安全なリモートアクセスの促進
本要件も同様にリモートアクセスに関連するものですが、特に「2要素認証の使用を妨げてはならない」という要件です。これは、決済アプリケーションはすべて2要素認証に対応すべしというものではなく、実装される環境において「決済アプリケーションのせいで2要素認証が使用できない」という状況にしてはいけないという要件になります。実装ガイドにおいても“リモートアクセスを行う際は2要素認証を行う必要がある”ことが記載されている必要があります。
◆要件12：公共ネットワークでのセンシティブトラフィックの暗号化
決済アプリケーションが公共ネットワークを介してカード会員データを送受信する場合、暗号化することが求められます。たとえばWebアプリケーションであれば、SSL/TLS、もしくは、IPsecなどを使用する必要があります。さすがに決済サイトでHTTPSを使わないサイトはもうほとんど見かけませんが、HTTP以外でもカード会員データを送受信することがある場合は、通信路を暗号化する必要があります。また、公共ネットワークとは、ワイヤレスも含まれるため、実装時にワイヤレスを使う決済アプリケーションの場合、どのようにワイヤレスの暗号化を行うべきかも実装ガイドで示す必要があります。
◆要件13：すべてのコンソール以外の管理アクセスの暗号化
例えばWebベースの管理ツールなど、ネットワーク経由のコンソールアクセスを提供する決済アプリケーションは、その管理アクセスは暗号化しなくてはなりません。これは先述の要件と同様、SSL/TLS、SSH、VPNなどを使用する必要があり、実装ガイドでそのように求める必要があります。なお、Telnet、rloginなどは使用してはいけません。
◆要件14：顧客、リセラー、インテグレータ向けの指示文書とトレーニングプログラムの保守
実装ガイドを作成すること、およびアプリケーションの更新に合わせて実装ガイドも更新すること、そのアプリケーションを顧客、リセラー、インテグレータに対してトレーニングを行うことが求められます。また、最後の要件では、リセラーやインテグレータの人にインタビューを行い、トレーニング資料を受領していることを確認することまでが求められます。
 |
3/4 |
 |
| Index | |
| 決済アプリのセキュリティ基準、PA-DSSとは | |
| Page1 PA-DSSの対象 PA-DSS対応は義務か？ |
|
| Page2 PA-DSSの概要 PCI DSSとの違い |
|
 |
Page3 PA-DSS実装ガイド PA-DSS要件概説 |
| Page4 求められる安全策はクレジットカード業界以外でも同じ |
|
 |
オール・ザッツ・PCI DSS 連載インデックス |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
