こんにちは、 STORES 決済 でバックエンドエンジニアをしている東瀬野です。
STORES 決済 では前身となるコイニー株式会社の時代からクレジットカードのデータを安全に取り扱うことを目的として策定された PCI DSS のセキュリティ基準に準拠をしております。
2022年3月にこの PCI DSS が大幅アップデートされ、 v3.2.1 から v4.0 へと更新されました。
本記事では PCI DSS v4.0 準拠までの道のりや対応などを紹介できればと思います。
STORES 決済 は例年1月中頃に本監査を行っており、そこへの対応に向けたお話をしていきます。
PCI DSS とは
正式名称は Payment Card Industry Data Security Standard で、クレジットカードのデータを安全に扱うことを目的として作成されたクレジットカード業界特有のセキュリティ基準です。
クレジットカードを利用したキャッシュレス決済は便利な一方で、不正利用が世界的に大きな課題となっており、国際的なクレジットカード会社5社(VISA、MasterCard、JCB、AmericanExpress、Discover)が協議団体を設立し、クレジットカード情報保護のための基準を策定しました。
PCI DSSに準拠しないとどうなる？
明確な罰則はありません。
ただし、PCI DSSに準拠していない事業者は、準拠している事業者に比べセキュリティインシデントの発生リスクが高いとみなされる傾向にあります。
これは会社の信用リスクに関わる問題であり、業界内で関係する会社からの取引を解消される可能性があります。準拠できないということは事業リスクに繋がります。
PCI DSS v4.0 準拠を目指すかどうか
PCI DSS v4.0 への移行期間が 2024年3月31日であるため当初は 「2024年1月の監査では v3.2.1 でもいいのでは」という意見もありましたが、2024年4月以降の監査を一発勝負で受けるリスクが高いということで早いタイミングから PCI DSS v4.0 準拠に向けた準備を始めました。
PCI DSS v4.0 準拠に向けた方向性
v3.2.1 から v4.0 というメジャーアップデートということでシステムや運用へ多くの変更がありますが、特に影響の大きい変更に関しては通常の移行期間とは別に猶予措置が設けられています。 future date と呼ばれ 2025年3月末までの対応を求められています。
STORES 決済 では future date 要件は翌年度以降で、まずは文書及び運用整備を行った上で PCI DSS v4.0 を準拠する決断をしました。
PCI DSS における重要な観点としては以下のようなものがあります。
- 要件に定められたルールが文書化できている。
- 文書が管理維持、レビューされて最新化されている。
- 文書の内容を対応メンバーに周知され、内容を理解している。
- 文書化された内容が運用されており証跡がある。
- 運用に対しての申請と承認がなされている。
上記の内容が本監査では重要となっています。
STORES 決済 では文書及び運用整備ができれば PCI DSS v4.0 が準拠できそうという。ということで PCI DSS v4.0 準拠に向けたプロジェクトがスタートしました。
準拠へ向けた段取り
段取りとしては以下のように進めていきました。
- エンジニアチーム内ギャップ分析
- コンサルタントとのギャップ分析
- エンジニアチーム内での要件読み合わせ
- 事前資料提出
- 本監査対応
これは結果ですが、タイムラインは以下のように決着しました。
エンジニアチーム内ギャップ分析
まずはコンサルティングを受ける前に事前にエンジニアチーム内で現状とのギャップ分析を行いました。
初回コンサルティングを受ける段階で STORES 決済 内での対応方針が正しいのかどうかを確認したい、という目的があったため早いタイミングから動き始めました。
実際に行った内容としては
- PCI SSCドキュメントライブラリで公開されている変更点に関する資料の読み合わせ
- PCI SSCはクレジットカード業界における世界的な規制機関です。PCI DSS の運営を行っているのも PCI SSC です。
- www.pcisecuritystandards.org
- セキュリティ関連を扱う各社が公開している主な変更点の対応方法について書かれたブログの読み合わせ
- NRIセキュアさんの対応方法についての解説はかなり役立ちました。 www.nri-secure.co.jp
エンジニアチーム内での見解としては、要件6のスクリプトの管理と要件8の認証周りで特に影響がありそう。という結論になりました。
コンサルタントとのギャップ分析
スケジュールのタイムラインに示した通り、2023年5月頃から始まり4回のコンサルティング、9月プレ監査という流れで行いました。
9月後半にプレ監査というスケジュールでしたので基本的な文書化や運用整備はここまでに終わっている必要があります。
事前に準備をした甲斐もエンジニアチーム内で行ったギャップ分析とそれほど大きな差分はありませんでしたが、修正や作成する文書がかなりあったためそこそこ大変な作業でした。
PCI DSS では文書作成や要件の数といった物量に押される側面があるので、そこで疲労しないための工夫も必要です。
9月後半のプレ監査後にはコンサルタントからもこの感じなら大丈夫でしょう。といったことを言われたこと覚えています。
PCI DSS v4.0 準拠へ向けた対応においてはまずは文書と運用整備を行って、翌年度以降に future date に対応するのが良い。とのことでした。
エンジニアチーム内での要件読み合わせ
エンジニアチームがすべての要件の回答をするわけではありませんが、本監査では多くの要件をエンジニアチームが対応方法を説明しています。
そのためすべての要件の読み合わせと対応方法をエンジニアチームで検討して埋められるものは埋めて理解度を上げる、他チームに対応をお願いするものは定例等で依頼するなどもしました。
この読み合わせでは毎週1時間の時間を確保して行っていきました。PCI DSS は要件の数が多く、一気にやると疲れてしまいます。
また、個人のやる気といった精神的な側面に依存させないためにチームで毎週一定の時間を確保する。という戦略を取っています。
当初は5, 6回ほどで終わる想定でしたが、対応方法や要件の意図がつかめないものもあり最終的には12回と想定よりも2倍ほど時間がかかってしました。
ただ、ここに関してはネガティブな気持ちはなく、昨年度の監査の時はこうしたから。ではなく改めて要件の意図を読み込んで要件の理解度を高めた上で監査に挑めたのはよかったと思います。
事前資料提出
本監査での流れをスムーズにするために例年、12月末頃からネットワーク図や文書、運用証跡といった資料を事前に提出します。
日々の運用漏れ、証跡漏れがないかが試される場でもあります。
この中で地味に大変なのがアプリケーションログの提出です。
STORES 決済 ではアプリケーションログを Amazon CloudWatch Logs に保存しているのですが、昨年度までは Amazon CloudWatch Logs -> Amazon S3エクスポートといった作業をしており、ただ待ち時間が長いだけのつらい作業でした。
そしてエクスポートのデータサイズが大きすぎると失敗します…
今年度対応では Amazon Kinesis Data Firehose と連携させて事前に Amazon S3 上へログを保管していたためかなり楽になりました。
本監査対応
STORES 決済 ではオフィスの会議室で 10:00〜18:00 の予定で1週間かけて監査を行っています。
普段はリモートワークで働いていますが監査となるとその場の温度感や表情など、オンラインだと意図を汲み取りきれないことがあるためオフィスに出社して対応をするようにしています。
チームメンバー全員が出社が必須というわけではなく、Google Meetに繋ぎながら監査を行っているため日によってオフライン、オンラインを選択できる余地を残して監査を進めるようにしています。
今年度の体制としてはエンジニアチームは会議室に2名、1人がオンラインでサポートという体制を基本としました。監査の中で追加の証跡を提出してほしい。といったことがあるため、オンラインのサポート要員の方には裏側で証跡の収集や提出などのサポートを願いしています。
大幅な変更のあった PCI DSS v4.0 対応でしたが、問題なく完全準拠することができました。
事前資料提出をしっかりと行ったこともあり、監査員の方からは「STORES さんは事前に提出してくれるのでスムーズに監査を進められて助かります。」とお褒めの言葉もいただきました。
日々の運用をきちんとやってきた甲斐がありました。
余談
PCI DSS v3.2.1 の監査自体は 2024年3月まで受けられるので、3月は PCI DSS v3.2.1 の駆け込みの監査が多くて監査員の方たちは大忙しなようです。
おわりに
無事 PCI DSS v4.0 の準拠はできましたが、future date の対応がまだ残っています。
future date にはシステム面に関わるものの変更や運用も多く含まれているため今年度は future date 対応で大忙しとなりそうです。
今年度も監査がようやく終わりました。監査が終わったのでまた監査の始まりです。
