こんにちは、開発統括室ペイメントシステム課マネージャーの戸田です。 前回 、決済システムの開発・構築・運用に深く関わるPCI DSSについて紹介いたしましたが、このPCI DSSはバージョンによって要件が多少異なっております。 現在弊社はバージョン3.2.1に準拠しておりますが、PCI DSS自体は2022年3月にバージョン4.0にメジャーバージョンアップされました。
今回はバージョン4.0リリースの影響と我々の取り組みについて少しご紹介したいと思います。
バージョン3.2.1とバージョン4.0について
まずはバージョン4.0リリースの経緯について軽く触れたいと思います。 PCI DSSの歴史そのものはここでは割愛いたしますが、バージョン3.0がリリースされたのは2013年なので、今回は約8年ぶりのメジャーバージョンアップとなります。 バージョン3.0がリリースされた後にマイナーバージョンアップを経て3.2.1となったのですが、その間に世の中のシステム環境やセキュリティ対策は大きく変化しました。
今回リリースされたバージョン4.0はバージョン3.2.1の要件を踏襲しつつも、現在のシステム環境に合わせた内容となっております。
主な変更点
機密認証データの扱い
バージョン3.2.1までは機密認証データはオーソリ処理了後に保存できないとなっておりましたが、バージョン4.0からはオーソリ処理中においても強力な暗号化による対応が必要となりました。 カード情報漏えい事件でセキュリティコードも漏えいしたといったことがたびたびニュースでありましたが、こういった攻撃に対応するため処理中も暗号化が必要となったわけです。
暗号化
ディスク暗号化はリムーバブルメディアのみが対象となり、それ以外はカード情報そのものの暗号化が必要となりました。 ハードディスクを暗号化していても中のデータが平文で保存されていると、そこにアクセスされればカード情報が取得できてしまうので、カード情報を保存する際は暗号化が必要となったというわけです。
フィッシング攻撃への対策
フィッシング攻撃もニュースなどでよく耳にする攻撃手段ですが、このフィッシング攻撃の検知や対策もPCI DSS要件に追加されました。
公開用WebアプリケーションへのWAF導入
バージョン3.2.1まではWAFの導入ではなくアプリケーションの脆弱性評価を実施といった対策でもOKとなっていましたが、バージョン4.0ではWAFの実装が必須となりました。
決済ページスクリプトの管理
消費者のブラウザで実行されるスクリプトに関する要件として追加されました。 SQLインジェクションによる攻撃以外にも、スクリプト改ざんなどによる処理中のデータを盗む攻撃も増えているため、スクリプトへの改ざん対策も求められるようになったようです。
パスワード関連
バージョン3.2.1まではパスワードの桁数が最低7文字となっておりましたが、バージョン4.0からは最低12文字と一気に長くなりました。 また、90日に1回の変更の要件も変更となり、無条件にではなく代替手段との選択となりました。ただ、要件を見る限りでは代替手段の方がハードルが高そうな感じがします。
カード会員データ環境へのアクセスのMFA実装
バージョン3.2.1では非コンソールアクセスやリモートアクセスに限定されていたMFAですが、それ以外のカード会員データ環境へのアクセスに関してもMFA実装が必要となりました。
監査ログレビュー
バージョン3.2.1まではログをレビューしなさいという要件でしたが、バージョン4.0からはログレビューを自動化しなさいとなりました。 確かに大量のログを手動や目視で監視するのは無理があり不正を見逃してしまうリスクがあるので、自動化が求められるのは当然の流れかなと思います。 あと細かいですが、監査証跡→監査ログと表現が変わったのはわかりやすくて個人的にはよいと思います。
内部脆弱性スキャン
バージョン3.2.1までは内部脆弱性スキャンはネットワーク診断が中心でしたが、バージョン4.0からは認証スキャンも追加されました。 内部ネットワークに侵入された際の脆弱性への対策が目的だと思いますが、この認証スキャンの追加は結構重いのではないかと心配しています。
リスク分析
バージョン3.2.1までも要件12においてリスク分析についてありましたが、バージョン4.0からは事業体全体ではなくターゲットリスク分析に置き換わりました。 このターゲットリスク分析に置き換わることにより、関連する要件のリスク分析、リスクに応じた評価の頻度、役割と責任などより細かいリスク分析や対応が必要になりました。
バージョン4.0に向けた取り組み
上記は変更点の一部であり、他にも各所で見直しや検討が必要となります。もちろん自社だけでは対応が難しいものもありますので、QSAや外部のセキュリティベンダーにも協力を仰ぎながら、一日も早くバージョン4.0への対応を進める必要があります。 まずはバージョン4.0とのギャップ分析を行い、優先順を付けながら2025年3月までにペストプラクティスを含めた完全準拠を目指していきたいと思います。
バージョン4.0の対応は簡単ではありませんが、対応することでよりセキュアな環境となり、お客様にも安心して利用していただけるようになるのはとても良いことだと思います。 また、これだけのシステム規模のバージョン4.0対応に関われるのは、純粋にエンジニアとしてのスキルアップにもつながるのでワクワクしています。
また機会があれば、このようにバージョン4.0に対応しましたと紹介したいと思います。
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
