2011年1月5日8:20
決済アプリケーションセキュリティ基準「PA-DSS」入門 第5回（3/3）
決済アプリケーションのPA-DSS準拠と実運用のギャップの扱い方
責任の所在を明らかに
本要件で言及されている内容をふまえると、ベンダの責任は「ペイメントアプリケーションの開発と、PCI DSS準拠環境での運用の支援」にあり、実際に安全に導入、運用する責任は、加盟店やインテグレータにあるといえる。
これは、いわゆる“本音と建前”の世界であり、もちろんPA-DSS準拠のアプリケーションを、実装ガイドに書かれた通りに設定、導入し、運用するのが理想的だが、数百、数千といった数の端末/アプリケーションを、強固なセキュリティのものに一気に入れ替えるのは容易ではない、というのが“本音”といえるだろう。そこで、アプリケーションの実装としては、“建前”を用意してPA-DSS準拠しつつ、現実的な“本音”の運用にも対応し、緩やかに理想的な運用に近づけていく必要があるだろうと筆者は考えている。これがまさに、本連載初回で予告した（以下に引用）、代替コントロールを採ることができないPA-DSS認定取得を目指す際に対応する方法だ。
＝＝＝＝＝抜粋＝＝＝＝＝
PCI DSSでは、要件に記載されている通りでなくても、リスク分析を行って十分に対策が施されていると判断できる場合に限り“代替コントロール”として“対応済み”とすることができる。しかしPA-DSSでは、代替コントロールの考え方自体が存在しないため、要件に記載されている通りに実装、対応しなければならない。
～
PCI DSSのように、暗号化を実装できない時に強固なアクセス制御やセグメンテーションを行うことで代替し、暗号化を避ける、といったことができないのである。それでもなんとか準拠しなければならない、といった際の対応方法については、本連載の最終回で触れたいと考えている。
引用元： https://paymentnavi.com/pcidss/6942.html
＝＝＝＝＝＝＝＝＝＝＝＝
逆にいえば、“現実的に考えて運用が無理だから、PA-DSS準拠対応はしない”という結果に終わる必要はない。選択肢を持たせれば良いのである。簡単に言ってしまうと、“PA-DSS準拠モード”と、“PA-DSS非準拠モード”の2種類を用意し、非準拠モードの説明に「このモードは絶対に使用しないで下さい。いいか、絶対にだぞ！！」という注意書きを追加すれば完璧だ。アプリケーションはPA-DSSに準拠できるし、加盟店やインテグレータへの忠告も十分である。
1つ例を挙げる。読み取った完全な磁気ストライプデータは、オーソリゼーション完了後に保管してはならない。ただし、現状では保管されていることは多いだろう。決済アプリケーションベンダとしては、このようなデータを保管しないアプリケーションに改修することは技術的には難しくはないはずだ。ではなぜ保管しているのだろうか。原因はさまざまだが、外部接続先（プロセッサや、カード会社）とのやりとりの上で必要となるため保管しているケースなどがあるだろう。このような場合に、外部接続先とやり取りするデータの内容やフォーマットのほか、業務フローも修正しなければならないが、それは加盟店の責任である。アプリケーションとしては要求通りにオーソリ後に削除する機能を実装すれば良い。ただし、現場で行われている運用や外部システムがうまくいかないようであれば、この機能を無効化できるようにしておけば良いのである。無効化できてしまうとPA-DSS準拠できないというわけではない。
本連載まとめ
おわりに
本連載では、5回にわたりPA-DSS要件の解説をした。PA-DSSに限らず、このような基準、標準文書は、幅広いシステムやプラットフォームをカバーしなければならないため、記述内容が曖昧であったり、逆に特定の実装に適用しようとすると要求事項がうまく合わなかったりする。PA-DSS要件を満たすべき決済アプリケーションは、Webアプリケーションや一般的なパソコン上で稼働するアプリケーションだけではなく、組込みOSや、最近ではスマートフォン上で稼働するアプリケーションなどもあり、これらをPA-DSSという1つのセキュリティ基準でカバーし、かつ意味のあるものでなければならないのである （スマートフォン上の決済アプリケーションについては、現在PCI SSCで議論されており、認定は取得できない）。ただし、むやみに要件通りに実装することが目的ではなく、安全に決済が行われるようにすることが目的であることを、ベンダや加盟店の方々だけでなく、われわれQSAやPA-QSAも考えていく必要があるだろう。つまり、要求事項に沿ってできていないことを指摘することではなく、できないところをどうやって実現するかを、加盟店、ソフトウェアベンダ、カード会社など含めたステークホルダーと共に考えるのがQSAやPA-QSAの役割なのである。
PCI DSSと同様、PA-DSS も3年のライフサイクルでバージョンアップされる。先述したが、以前は参照先のみであったPCI DSSの内容が、バージョン2.0ではPA-DSSの中に盛り込まれており、読みやすくなっている。本格的に準拠を目指して対応していくのであれば、プログラムガイドなど、アプリケーション要件以外にも、バージョニング方法の定義や各種契約など、さまざまな手続きがあり準拠は容易なものとはいえないが、要件には“今すぐできるセキュリティ対策”も多く含まれている。バージョン2.0の日本語版もすでに公開されているので、本連載でご興味を持っていただけたら、要件書もご一読いただければ幸いである。
⇒⇒決済アプリケーションセキュリティ基準「PA-DSS」入門 第5回（1/3）へ戻る
