はじめに
ついに本日(2024年3月31日)を以てPCI DSSがv4.0に完全に移行します。本記事では自身の勉強も兼ねてPCI DSSとAWSについて情報収集したので内容シェアさせていただきます。セキュアなAWS環境を作るうえでの気付きは多いと思いますので、多くの方に参考にしていただけたら嬉しいです。
PCI DSSの概要
PCI DSSとは
PCI DSSという用語はご存知でしょうか。そうです、AWSの試験でやたら出てくるアイツです（笑）
クレジットカード業界のセキュリティ基準で、正式には以下のように説明されています。
PCI DSS（Payment Card Industry Data Security Standard）は、 クレジットカード情報および取り引き情報を保護するために2004年12月、JCB・American Express・Discover・マスターカード・VISAの国際ペイメントブランド5社が共同で策定した、クレジット業界におけるグローバルセキュリティ基準である。※1
PCI DSSはマイナーバージョンアップとメジャーバージョンアップを繰り返しており、最新のバージョンは2022年3月にリリースされたv4.0です。長い間移行過渡期でしたが、冒頭でも触れたとおり2024年3月31日を以て完全にv4.0へ移行します。※2
v3.2.1とv4.0の差異は他の方のブログで詳細に説明されているので、ぜひご参照ください。
※1 https://ja.wikipedia.org/wiki/PCI_DSS
※2 https://blog.pcisecuritystandards.org/countdown-to-pci-dss-v4.0
PCI DSSと責任共有モデル
実際に各要件の詳細に触れる前に、PCI DSSとAWSの責任共有モデルについて説明しておきます。
AWS社は、AWSとユーザの関係を責任共有モデル※3として表現しています。すなわち、物理層や仮想化基盤に対するセキュリティはAWSが責任を持ち、その上で動かす環境に対するセキュリティはユーザが責任を持つというモデルです。Security "of" the Cloud と Security "in" the Cloud と表現されることもあります。
※3 https://aws.amazon.com/jp/compliance/shared-responsibility-model/
EC2でWebアプリケーションをホストしている場合を例に取りましょう。この場合、物理施設のセキュリティ、ハードウェアのセキュリティ、電力供給設備に対する責任はAWSにあります。一方、OSやミドルウェアのパッチアップデート、ネットワークトラフィックの保護、アプリケーション保護に対する責任はユーザにあります。
PCI DSSへの準拠対応を行う際も同様で、AWSの責任範囲とユーザの責任範囲を明確にして各種要件に適合するようサービスの選定、パラメータの設定を行う必要があります。AWSが責任を負うPCI DSS要件はPCI DSSの準拠を証明するAttestation of Compliance(AOC)や、AWS PCI Responsibility Summaryで確認できます。これらはAWS Artifact（AWS のコンプライアンスレポートをオンデマンドで入手するためのセルフサービスポータル）経由で入手できます。
ちなみに、AWSではないのですがGoogle Cloudでは各サービスレベルでユーザの責任範囲を明確にしたマトリックスを提供しています。粒度が細かく、しかも英語なのですが各要件に対してユーザがどのように考えてPCI DSSに準拠させるのかのヒントが詰まっています。(以下画像は一例です。)
PCI DSSの12の要件
PCI DSSの12の要件は以下のとおりです。AWS観点でどのようなことが求められるかを簡単にサマライズして記載しています。
目標①：安全なネットワークとシステムの構築と維持
-
要件1 ネットワークセキュリティコントロールの導入と維持
ファイアウォールの適切な構成、インターネットからの直接アクセスの禁止、通信を最小限に制限することなどが求められます。 -
要件2 すべてのシステムコンポーネントにセキュアな設定を適用する
業界で認知されているシステム強化基準を用いてシステムをセキュアに構成することが求められます。
目標②：アカウントデータの保護
-
要件3 保存されたアカウントデータの保護
暗号化を有効にし、厳格なデータ保持方針と手順を維持することが求められます。また承認完了後に機密性の高い認証データを保存またはロギングしないことも求められます。 -
要件4 オープンな公共ネットワークでの送信時に、強力な暗号化技術でカード会員データを保護する
インターネットなどのオープンネットワーク経由で情報を送る際に、厳格な暗号化およびセキュリティコントロールを構成することが求められます。
目標③：脆弱性管理プログラムの維持
-
要件5 悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する
マルウェアの影響を受けるすべてのシステムに対し、適切なウイルス対策製品の導入を求められます。 -
要件6 安全なシステムおよびソフトウェアの開発と維持
セキュリティ脆弱性の特定・ランク割当て・パッチ適用、セキュアな開発・テスト・変更管理、Webアプリケーションの保護など、システム開発や保守を行う上での様々な対策が求められます。
目標④：強固なアクセス制御の実施
-
要件7：システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲（Need to Know）によって制限する
職種と職務に基づいた業務に必要な最小限のアクセス権の割当てが求められます。 -
要件8 ユーザの識別とシステムコンポーネントへのアクセスの認証
アカウントおよび認証情報の適切な設定と管理が求められます。 -
要件9 カード会員データへの物理アクセスを制限する
物理的なセキュリティ対策に対する要求項目ですが、AWSプラットフォームの物理セキュリティやメディア管理はAWSが責任を担います。
目標⑤：ネットワークの定期的な監視とテスト
-
要件10 システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視すること
AWSサービスやインスタンス内の各種ソフトウェアなどのログの有効化、要件に沿った適切な保存および監視が求められます。 -
要件11 システムおよびネットワークのセキュリティを定期的にテストする
セキュリティ診断（脆弱性スキャンおよびペネトレーションテスト）の実施、IDS/IPSや変更検出メカニズムによる監視などが求められます。
目標⑥：情報セキュリティポリシーの維持
- 要件12 組織の方針とプログラムによって情報セキュリティをサポートする
組織のセキュリティに対する姿勢を設定し、カード会員データ環境を保護する情報セキュリティのポリシーとプログラムを維持することが求められます。
スコーピングとセグメンテーション
PCI DSSスコープ
スコーピングについて説明する前に、PCI DSSスコープについて説明します。
PCI DSSスコープとは、PCIデータセキュリティ基準(DSS)で概説されている 12 の要件を満たす必要がある環境のことを言います。カード所有者データ(CHD)をやりとり、もしくは影響を与える人、プロセスおよびテクノロジーを組み合わせたものです。※1
より具体的には、システムコンポーネントを以下の3種類に分類し、1および2に該当するシステムコンポーネントがPCI DSSスコープと考えるとよいかと思います。
-
CDE※2(カード会員データ環境)システム
カード会員番号のような、PCI DSSで定義されたカード情報データが保存、処理、または送信するシステム(同一セグメントにある他のシステムもCDEとみなされます) -
接続先システム、またはセキュリティに影響するシステム
それ自体はCHDを保存、処理、または送信しないが、CHDを行うシステムに接続されているシステムおよびCDEのセキュリティに影響を与えるシステム -
範囲外のシステム
CDEのセキュリティまたは設定に影響を与えず、適用範囲内に含まれないシステム
※1 https://www.pcidssguide.com/ より抜粋
※2 CDE：カード情報が伝送、処理、保存される領域をCDE(The cardholder data environment)と呼ぶ
PCI DSSにおけるスコーピング
PCI DSSにおけるスコーピングとは、前節で述べたPCI DSSスコープの範囲内のシステムを特定することをいいます。
特定の手順はPCI Security Standards Council(SSC)のスコーピングとネットワークセグメンテーションに関する補足ガイダンス で紹介されています。日本語に翻訳しただけですが、以下のステップで行うことがよいとされているようです。
- カード会員データ(CHD)を取得する方法と場所を特定する
CHDを受領した時点から破棄または譲渡するまで、CHDを受け入れるすべてのチャネルと方法を特定する。- アカウントデータがどこに保存、処理、転送されるかを調べ、メモする
全てのCHD フローを文書化し、CHDの保存、処理、または転送に関わる個人、プロセス、および技術を特定する。CDEには、これらすべての人、プロセス、およびテクノロジが含まれる。- PCIの範囲内で、他のすべてのシステム、プロセス、および従業員を特定する
すべてのプロセス、システム、技術的および商業的、およびCDEと対話または影響を与えることができる人員を特定する。これらの人、プロセス、およびテクノロジは、CDEへの接続を持っているか、CHDのセキュリティに影響を与える可能性があるため、すべてPCIの範囲内とみなす。- PCIスコープを最小限に抑えるための制御を実装する
CDEと他のPCI対象システムとの間の通信を、必要なものに制限する。CDEとやり取りおよび影響を与えたりする必要のない人、プロセス、およびテクノロジからCDEを分離するための制御を実装する。- 該当するすべてのPCI DSS要件に従う
範囲内のシステム、プロセス、および担当者に適用される PCI DSS 要件を特定して実施する。- PCI DSSに準拠していること、および情報が安全であることを定期的に検証する
PCI DSSコントロールが日々有効であることを保証するプロセスを実装する。変更を行う際には、範囲に含まれる人、プロセス、およびテクノロジが正確に定義されていることを確認する。
文章だけだとイメージが難しいですよね。
AWSからは、より具体的にPCI DSS準拠の対応のイメージが湧くようにガイドが提供されています。(v3.2.1なのでご注意ください。)
個人的にはお絵描きのイメージが載ってるところが推しポイントです。
<カード会員データフロー図のサンプル>
PCI DSSにおけるセグメンテーション
PCI DSSにおけるセグメンテーションは、PCI DSS Requirement 0と呼ばれます。すなわち他のPCI DSS要件に対処する前に、スコープ内のシステムをスコープ外のシステムから分離しPCI DSSの対象となるシステムを減らすために使用されるということです。(対象のシステムが減ると労力もコストも低減できるので、適切なセグメンテーションはとても大事ということですね！)
どのような手段でセグメンテーションを実現できるかは以下※3のように説明されています。
セグメンテーションは、適切に構成された内部ネットワークセキュリティコントロール、強力なアクセスコントロールリストを備えたルータ、またはネットワークの特定のセグメントへのアクセスを制限するその他のテクノロジなど、多くの物理的または論理的な方法を使用して実現できます。
余談ですが、PCI DSS v3.2.1→v4.0へのメジャーバージョンアップに伴って、「ネットワークセキュリティコントロール」という表現が追加されたようです。これにはパブリッククラウドのようなソフトウェアで定義されたネットワーク(SDN)における様々なコントロールを包含するような意図があるのでは、と以下のブログで示唆されています。(私もそう思います。)
※3 https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4_0-JA.pdf より引用
AWSにおけるスコーピングとセグメンテーション
概念はここまでにし、本セクションからは本題であるAWSにおけるスコーピングとセグメンテーションについて説明します。
なお、本セクションの記載にあたってAWSのホワイトペーパーを大いに参考にしています。ただし、ホワイトペーパーは表現が堅いので読みやすさを重視してできるだけプレーンな表現に変換しています。
AWSにおけるセグメンテーション設計
AWSにおけるセグメンテーションの設計として、主要なものをピックアップしてご紹介します。
-
AWSアカウントによるセグメンテーション
AWSアカウントはAWS環境のリソース管理単位であり課金の分離単位ですが、セキュリティの境界でもあります。PCI DSSにおいても、PCIワークロード用に隔離したアカウントを使用することが最も重要なベストプラクティスとされています。
実際にAWSのベストプラクティスに沿って構成されたマルチアカウントアーキテクチャは以下のようになると思います。
AWS Control Towerでも取り入れられている、ランディングゾーンという考え方に沿ったアーキテクチャです。図は、CDEシステムと適用範囲外のシステムで共通機能を共有しつつ、直接の接続を持たせないことでスコープを制限していることを表現しています。(VPCピアリングは推移的なルーティング※4が不可なので、このような構成が可能になっています。)
※4 推移的なルーティング：あるVPCから別のVPCをまたいでさらに別のVPCへ行くこと -
セキュリティグループによるセグメンテーション
セキュリティグループは、ホストベースのファイアウォールに相当するAmazon Virtual Private Cloud（VPC）の機能です。ネットワークインターフェースに関連付けられます。必要なポート、送信元および宛先アドレスに基づいてネットワーク通信を制限します。
例えば以下の図では、PCI DSSスコープ内のセキュリティグループとスコープ外のセキュリティグループに分割し、相互通信ができないようにしています。(セキュリティグループは、VPCやサブネットとは独立してネットワークセグメントを構成します。)
-
Amazon API Gatewayによるセグメンテーション
サーバレスなどのAPIベースのサービスでは、API Gatewayを使用していることも多いかと思います。API Gatewayはコネクションを一度終端し、再度API Gatewayから新しいコネクションを張りにいくので、リソースがCHDを処理しない限り接続先システムをPCI DSSのスコープから除外できます。(API Gateway自体のPCI DSS準拠は当然ながらAWSの責任範囲です。)
余談ですが、PCI DSSv4.0ではWAFが必須化されています。API GatewayにWAFをアタッチする方法は以下を参照ください。
トークナイゼーション
トークン化とは
トークンという言葉はNFT(非代替性トークン)などに代表されるように、最近よく出てくるなと感じられる方も多いかと思います。使用される場面によって言葉の意味がよく変わるように思いますが、今回はクレジットカード業界におけるトークンについて説明します。
トークン化とは、機密データを非機密データに置き換えることで保護する仕組みのことです。トークン化によってデータは認識不可能なトークン形式になりますが、元のデータのフォーマットは保持されます。たとえば、1234-5678-1234-5678というクレジットカード番号をトークン化した場合、2754-7529-6654-1987となります。このため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はありません。(これはトークン化の大きな利点ですね！)
ちなみに、トークン化は仮名化と呼ばれたりもします。あだ名ではなく、ニュースなどで田中さんを鈴木(仮名)と呼んでいるようなイメージです。当然鈴木という情報から田中さんという本名を類推することはできませんし、田中さんのプライバシーも守ることができますよね。(トークン化に規則性があることはセキュリティリスクに繋がります。)
これと同じことをカード番号などに適用するのがクレジットカード業界におけるトークン化ということになります。
クレジットカード業界においてトークン化が注目を集めた背景に「クレジット取引セキュリティ対策協議会」が取りまとめた実行計画があり、その中に以下の一文があります。
実行計画で示す加盟店における「非保持化」とは、カード情報を保存する場合、それらの情報は紙レポートやクレジット取引にかかる紙伝票のみであり、電磁的に送受信しないこと
この非保持化を実現する技術の一つが、本稿で解説するトークナイゼーションなのです。
トークンの種類
クレジットカード業界の業界知識として、イシュアとアクワイアラについても簡単に解説しておきます。(私もPCI DSSについて学び始めてから知った知識です。)
イシュアは、その名のとおりカード発行会社です。簡単に言うと、①カードを作って送る、②使った人からお金をもらう、③安全を守る、という3つの仕事をしています。詳細は以下の超わかりやすい記事を参照ください。
一方アクワイアラは、カードを使えるようにする会社です。①カードが使える会社を増やす、②イシュアからお金をもらう、③お店にお金をわたす、という3つの仕事をしています。こちらも詳細は以下の記事を参照ください。
カード会社にはこの2種類があり、トークンもそれぞれ意味合いが違ったものになります。
- イシュアトークン：バーチャルカード番号（Virtual Card Numbers、VCN）とも呼ばれる、イシュアによって作成されるトークン
- アクワイアリングトークン：アクワイアラ、加盟店、または加盟店のサービスプロバイダによって作成されるトークン
さらに、カード会社ではなく、TSPによって作成されるトークンとして以下があります。 - ペイメントトークン：EMVCoに登録されたトークン・サービス・プロバイダ(Token Service Providers、略してTSP)が作成するEMV規格のトークン
3種のトークンの違いの詳細については以下の記事も参照ください。(素晴らしい記事です。)
トークナイゼーションによる非保持化と評価範囲
クレジットカード・セキュリティガイドライン【3.0 版】では、クレジットカード番号としてみなさない条件として以下が挙げられています。
また、以下の処理がなされたものはクレジットカード番号とは見做さない。
・トークナイゼーション（自社システムの外でクレジットカード番号を不可逆的に別の番号等
に置き換え、自社システム内ではクレジットカード番号を特定できないもの）
・トランケーション（自社システムの外でクレジットカード番号を、自社システム内では特定
できない方法で安全に国際的な第三者機関に認められた桁数を切り落としたもの）
・無効処理されたクレジットカード番号
非保持化を実現するためには、PANをすべてアクワイアリングトークンまたはペイメントトークンの形で取りまわす必要があります（イシュアトークンのVCNはPANと同等なので、イシュアトークンへの置き換えは非保持化には適しません）。
本稿で扱っているトークナイゼーションの条件で重要なのは、自社システムの外でクレジットカード番号を不可逆的に別の番号等に置き換えという部分です。すなわち、PANをトークンに置き換えるためのトークン化システムは自社システムの外に存在する必要があるということです。(サービスプロバイダーなど他社のシステムによって提供されなければならないということです。)
上記の条件を守る限り、PCI DSSの評価範囲は以下※1のように変わります。
- トークナイゼーションシステムのすべてのコンポーネントはCDEとみなされ、PCI DSSスコープ内（①）
- トークン化またはデトークン機能を提供するシステムは、PCI DSSスコープ内（②）
- トークナイゼーションシステムまたはトークン化・デトークンの処理にアクセス可能なシステムやプロセスはCDEに接続されているためPCI DSSのスコープ内（③④）
- 他のシステムがトークン化またはデトークンの操作を実行しない場合でも、CDE内に位置する、またはカード会員データ環境に接続されている場合はPCI DSSのスコープ内（⑤）
実際の対応の際は上記に注意し、適切に評価範囲を縮小しましょう。
※1 https://www.intellilink.co.jp/column/pcidss/2018/012900.aspx より引用
AWS上でのトークナイゼーションにおける考慮点
AWSでトークンを利用して監査範囲を縮小する際の考慮点は以下のブログにまとめられています。(英語記事です。)
要点をかいつまんでお伝えすると、
- ビジネスに適したトークン化ソリューションを決定するには、ビジネス要件とユースケースを明確にし、トークン化するデータの種類や用途、トークンの決定性と共有性、有効期間などを検討する必要がある。
- 自己管理のトークン化とサービスとしてのトークン化（TaaS）の選択は重要。
- 可逆性のあるトークン化ソリューションは、セキュリティとコンプライアンスのリスクを考慮して厳重に監視する必要がある。
- 運用上の要素、暗号化とセキュリティ標準の満たし方も考慮する。
- トークン化ソリューションはセキュリティリスクの軽減やコンプライアンスコストの削減などの利点を提供するが、システムの複雑さや追加コストが発生する可能性がある。
個人の主観ですが、自社環境でトークン化ソリューションを実装するのはハードルが高いと考えています。そのため、まずはサードパーティーのトークン化ソリューションを検討することになるだろうと思います。AWS環境でのトークナイゼーションには、マーケットプレイスを利用可能です。
要件上、自組織で実装する必要がある場合は以下のサーバレスソリューションを参考にできそうです。
トークナイゼーションを利用することにより、PCI DSSの評価範囲の縮小が可能です。ただし、システムが複雑化する可能性があったり、正しく分離されていないと評価範囲を意図した通りに縮小させられなかったりするので注意事項はよく理解する必要があります。
まとめ
本記事ではPCI DSSとAWSについて、スコーピング、セグメンテーション、トークナイゼーションという観点でまとめました。理解するだけでも骨が折れますが、今後プロジェクトで対応を行うことがあったら役立てていきたいと思います。余談ですが、AWSから公式にPCI DSSv4.0に関するガイドが出ています(現在は英語版のみ)。こちらもぜひ参考にしてください。