2011年1月5日8:00
決済アプリケーションセキュリティ基準「PA-DSS」入門 第5回（1/3）
要件13、まとめ
NTTデータ・セキュリティ コンサルティング本部 PCI推進室 CISSP 川島祐樹
はじめに
ここまで、決済アプリケーション向けのセキュリティ基準であるPA-DSSの解説を行ってきたが、今回で最終となる。もし、全体を通してご覧いただいていれば、PA-DSSへの準拠は一筋縄ではいかないのでは、と感じられた方が多いのではないだろうか。その理由は、さまざまである。
■業務運用との乖離
「アプリケーションないし端末を要求通りの仕様にすることは可能だが、現場でそのような使い方は到底できない。」
例えばPCI DSSでは要件5、PA-DSSでは要件8.1では、アンチウィルスソフトウェアの導入に関する要求があるが、実際に導入されているPOS端末でアンチウィルスを稼働させ、定期的なパターンファイルのアップデートやログの生成と管理等を要求通りに行うことができない、などが考えられる。
■プラットフォーム上の制限
「そんなアクセス制御方法／管理方法は、このOSでは実現できない。」
PCI DSSやPA-DSSは、明らかにオープン系システムを想定した内容に偏っており、決済端末で使用されるような組み込み、専用OSや、メインフレームなどではうまく適合しない要件がある。例えばPCI DSS要件8のアカウントやパスワード関連の詳細な要件、PCI DSS要件10のログ管理要件などは、専用OSで、もともとマルチアカウント対応していない、必要最小限のコンポーネントしか持たない、などの性質から、そもそも実現できない、といったことも十分にあり得る。
■外部接続
「最小限のカード会員データを保持、伝送すべきなのはわかる。しかし接続先からすべて伝送するよう指示されているので持たざるをえない」
グローバルな基準とはいえ、米国発祥のPCI DSS/PA-DSSと日本国内の事情が異なることから、よく問題となる。自組織でPCI DSS準拠や、アプリケーションのPA-DSS準拠を目指していても、外部接続先（プロセッサ等）との連携があり、ここでやりとりされる電文フォーマットは当然ながらあらかじめ決められたものである。1対1で決められたものであればまだ調整の余地はありそうだが、複数の接続先を受け入れている事業者が、特定の1社に対してだけフォーマットを変えるということは、あまり考えられない。
このように、原因はさまざまではあるが、決済アプリケーションをPA-DSS準拠させるのはなかなか難しいことがおわかりいただけるだろう。こういった場合には、ビジネス上、契約上、システム上など、さまざまなレイヤーで変化球が必要になると考えていただきたい。時には要件の解釈を「逆手に取る」というようなことも必要かもしれないが、本来の目的は、カード会員データを情報漏えいから守ることであり、PA-DSSに準拠するのが目的ではないということを思い返しながら対応を進めていただければと思う。
PA-DSSに準拠していても期待通りに設定・運用されるとは限らない？
PA-DSS準拠決済アプリケーションの取扱い
要件13の内容に入る前に、少しおさらいしておこう。PA-DSSは、PCI DSSをベースにした決済アプリケーション向けの基準であるが、ステークホルダーに違いがある。大きな違いとしては、PA-DSSはアプリケーション開発を行うベンダが、実際に決済が行われる環境に登場しないことである。つまり、PCI DSSの場合はPCI DSSに準拠すればその環境がそのまま実運用環境であり、準拠していることが確認できるが、PA-DSSの場合はあくまでアプリケーション自体の準拠に過ぎず、実運用環境でのアプリケーションの安全な稼働まで保証されるものではない。PA-DSS準拠のアプリケーションであっても、適切な使用法のもと稼働させなければ、決済環境を安全にすることはできない（図1）。
そこで、PA-DSSでは、「顧客、リセラー、インテグレータ向けの指示文書とトレーニングプログラムの保守」といった要件が含まれている。本要件は、13.1、13.2（v1.2においては14.1、14.2）の2つのサブ要件しか含まれていないが、PA-DSS全体に散りばめられている「PA-DSS実装ガイド」の策定と管理を含む幅広い要件とお考えいただきたい。実装ガイドは各要件に散りばめられているが、13要件（14要件）の後に実装ガイドに関する要件が抜粋された一覧表があるため、実装ガイドの作成時、確認時には活用すべきである。
⇒⇒決済アプリケーションセキュリティ基準「PA-DSS」入門 第5回（2/3）へ
