PCI DSS on AWS(概要)

0 はじめに

本記事はPCI DSS4.0に、AWSプラットフォーム上のシステムが準拠する際の勘所や手法を整理する記事である。
多くの記事がPCI DSS 3.2.1からの差分の説明にとどまっているため、本記事では新規導入に焦点を当てる。
記事構成は全体像(本記事)と各要件(逐次公開ｙ)をまったりまとめていく予定だ。
なお、実際にPCI DSSを考慮する場合にはPCI DSSのドキュメントやAWSホワイト北オアーなどを参考にして欲しい。

1 PCI DSSとは

PCI DSS(Payment Card Industry Data Security Standard)とは、クレジットカードを取り扱うシステムにおける国際的なセキュリティ基準である。
かつてはカードブランド(VISAなど)が独自で定めていたセキュリティ基準がもともと存在していた。しかし、クレジットカード情報の流出問題や、インターネット決済の普及、複数のクレジットカードが利用可能な決済システムが標準となったことを受け、国際的カードブランド5社(American Express、Discover、JCB、MasterCard、VISA)によって、2004年12月に最初のバージョン(1.0)が定められた。
PCI DSSは不定期にバージョンアップされ、2025年3月現在では4.0.1が最新版である。
バージョン4.0では12の主要な要件に対してセキュリティ対策方針が記載されているため、それをシステム及び運用に落とし込む必要がある。
PCI DSSへの準拠が必要なシステムの範囲は広く、エンドユーザーがカードで決済する加盟店からカード発行会社(イシュア)までの範囲が含まれる。
下記は登場人物の関係図(イメージ)

また、インターネット経由のオンライン決済に限らず、POSを利用したオフライン決済についても準拠の対象となることに気をつけたい。
準拠にあたっては、要件を満たしたシステムの構築〜運用だけではなく、下記に示すいずれか方法での審査を受ける必要がある。
・訪問審査+スキャン
・自己問診+スキャン
訪問審査:認定審査機関(QSA=Qualified Security Assessor)が事業者を訪問してシステムやドキュメントを確認する。
自己問診:自己評価アンケート(SAQ=Self-Assessment Questionnaire)に対して役員名でもって回答する。すべてYesであれは準拠。
スキャン:以下に記述
※訪問審査と自己問診は規模によっていずれかが求められる。

スキャンでは下記に示す6つの診断が必要となる。(詳細は各章にて説明)
・外部脆弱性診断
・外部ペネトレーションテスト
・内部脆弱性診断
・内部ペネトレーションテスト
・セグメンテーションの有効性チェック
・ワイヤレスチェック
認定ベンダによるスキャンが必須なASVスキャン(外部)と内製化も可能な内部スキャンが存在する。

2 基本方針

AWS上に構築するシステムについて、PCI DSSへの準拠には下記に注意を払う。

2.1 AWS機能の制限

AWSサービスについて、一部そのままではPCI DSSの要件を満たせない場合がある。その際には3つの方針がある。
1:MWや外部サービスを利用する
2:カスタムアプローチを採用する
3:スクラッチで作り込む

いずれも一長一短ではあるため、運用体制とも相談して決めるべきである。

2.2 運用負荷軽減

PCI DSSは定期的にスキャンや監査が必要となる。また、システムの準拠状態を維持するには、PCI DSSのバージョンの変更がなくとも、常にシステム情報の最新化や脆弱性対応が必要となる。
それ故に可能な限りAWSマネージドな管理サービスやサーバーレスを利用することで、AWSの責任範囲を広げ、対象システムの責任範囲を狭めることが重要となる。
この際に重要なのがAWS責任共有モデルだ。
責任共有モデルを理解して、サービスごとにどこの範囲を準拠させる必要があるかを意識する。
例えばEC2とFargateのいずれかを選択する場合、多少AWSからの請求が増えても、Fargateを利用した方がOSレベルでのPCI DSS準拠(ロギングなど)を責任範囲外にできる分、トータルコストを削ることができる。
(SIerとしてはお客様に請求できる運用費をAWSに取られることを意味するのだが。)

2.3 デフォルト設定はベスプラではない

AWSのデフォルト設定には、セキュリティ要件の低い設定がされている場合がある。後の要件でも扱うが、デフォルト設定から大きく変えることを考慮する。
例えばセキュリティグループのアウトバウンド全許可はNGである。

2.4 サードパーティの力を借りる

PCI DSSではWAF要件が追加されている。クレジットカードシステムはトランザクションの誤検知によるブロックの影響が極めて大きい一方で、PCI DSS 4.0からはWAFの運用も求められている。
AWS WAFの運用にはサードパーティのサービスを利用することも考慮する。
その他のサービスも場合によっては、外部サービスの利用を考慮するとよい。

3 注意点

PCI DSS 3.4から4.0に対する変更点は多くのWebページに掲載されているが、一からな説明は少ない。(本記事の執筆動機でもある。)
実際のドキュメントにて、確認することが極めて重要である。

クラウド利用は基本の12要件以外にも、考慮が必要なドキュメントがある。(PCI DSS付録)また、PCI SSC Cliud Guidanceなる参考資料も存在する。
準拠にあたってはこれら資料を読み込むことをおすすめする。

また、AWSのエンタープライズプランに加入している場合は、AWSアカウントチームを巻き込み、AWSの知見を借りることをおすすめする。AWS内部には準拠のための知見が豊富だと思われるためだ。これは外部ベンダーにシステム構築を発注している場合も同様で、PCI DSSのベスト／グッドプラクティスに準拠できない場合は特にそうである。