AWS環境におけるPCI DSS v4.0 に対応したセキュリティ対策を考える

はじめに

こんにちは。AWS事業本部コンサルティング部に所属している和田響です。

この記事では、AWS環境にてクレジットカード業界のセキュリティ基準であるPCI DSS v4.0に準拠するための対応を、AWSの提供するコンプライアンスガイドをもとに考えていきます。

PCI DSS対応の勘所や、AWSサービス理解の一助になれば幸いです。

ソース

本記事は2023年10月9日にAWSから公開されている、Payment Card Industry Data Security Standard (PCI DSS) v4.0 on AWSをもとに、PCI DSSの各要件に必要なAWSでの対応を簡単にまとめていきます。

前提

PCI DSSの各要件について考える前に、 AWS環境でのPCI DSS準拠を考えるために重要な前提を整理します。

共有責任モデル

AWSはセキュリティの責任範囲をAWSとお客様で明確に定義しています。
PCI DSSの対応をするうえで、「我々はどこからどこまで対応する必要があるのか」を考える必要があります。

例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。

引用：https://aws.amazon.com/jp/blogs/news/rethinksharedresponsibility/

具体的には以下の図のように責任範囲が定義されています。

参考：https://aws.amazon.com/jp/compliance/shared-responsibility-model

AWS側は、クラウドで提供されるすべてのサービスを実行するインフラストラクチャの保護について責任を負います。
お客様側は、EC2などのIaaSの場合はOS管理 (更新やセキュリティパッチなど)、インスタンスにインストールしたアプリケーションソフトウェアまたはユーティリティの管理、セキュリティグループの構成に責任を負います。Amazon S3やAmazon DynamoDBなどの抽象化されたサービスの場合はデータの管理 (暗号化オプションを含む)、アセットの分類、IAM ツールでの適切な権限の適用について責任を負います。

適用範囲の特定

PCI DSS要件は以下の3種類のシステムに対して適用されます

1. アカウントデータを保存、処理、送信するコンポーネント
2. 1のリソースに接続されているコンポーネント
3. カード会員データ環境（CDE）のセキュリティに影響を与えうるコンポーネント

アカウントデータのすべての場所とフロー、およびCDEに接続されているか、CDEのセキュリティに影響を与えるすべてのシステムを特定し、少なくとも年に一度（年次評価前に）その範囲の正確性を確認する必要があります。

またこれらを示すために、データフロー図やネットワーク図を作成・維持することが求められています。

セグメンテーション

PCI DSSにおけるセグメンテーションとは、物理的または論理的な方法でネットワーク内の特定のセグメントへのアクセスを制限することで、PCI DSS評価の範囲を限定し、リスクを減少させることを目的としています。

カード会員データ環境（CDE）を必要最小限の範囲にすることで、セキュリティリスクを軽減させるだけではなく、PCI DSSの適用範囲を絞ることができます。このような背景から、セグメンテーション自体はPCI DSSの要件ではないものの俗にPCI DSS要件0と呼ばれています。

要件1：ネットワークセキュリティコントロールの導入と維持

要件1は、ネットワークセキュリティとCDEへのネットワークアクセスの制限を求めています。
AWSでは、VPC、セキュリティグループ、ネットワークACL、およびIAMを用いてこれらを実装できます。

1.2

この要件では、ネットワークセキュリティコントロール（NSC）の設定および管理について求めています。AWSでは、セキュリティグループとネットワークACLの設定によりこれらを実装できます。

セキュリティ管理サービスの一つであるAWS Firewall Managerを用いることで、VPC全体で許可および禁止されるセキュリティグループを定義するポリシーを作成することができ、アカウントやアプリケーション全体でNSCルールを集中管理および設定するのに役立ちます。

1.3

この要件では、CDEネットワークへのアクセス制限が求められています。セキュリティグループを使って、IPアドレス、ポート、およびプロトコルによってトラフィックを制限することができます。デフォルトではセキュリティグループはすべてのアウトバウンド接続を許可しますが、PCI DSS準拠のためにはアウトバウンドルールも適切に設定する責任があります。

1.4

この要件では、信頼されたネットワークと信頼されていないネットワーク間のアクセス制限が求められています。CloudFrontやAPI Gatewayによって、信頼されていないネットワーク（通常はインターネット）とから、信頼されたネットワーク（内部ネットワーク）への通信を制限し、エンドポイントによってインターネットを経由しないプライベートなアクセスを実装でき、IAMを使って適切な権限管理を行う必要があります。

要件2：すべてのシステムコンポーネントにセキュアな設定を適用する

要件2は、デフォルトパスワードの変更、不要なソフトウェア、機能、アカウントの削除、不要なサービスの無効化または削除といったシステムの構成要素に安全な設定を施すことで、攻撃者がシステムを侵害するために利用できる手段を減らすことを求めています。

2.2

この要件では、具体的なシステムの安全な設定について以下の対応を求めています。

構成基準の定義

AWSリソースのセキュリティ設定基準を定義・維持する責任があり、これらの標準は業界で認められたシステム強化標準に準拠している必要があります。AWSでは以下のセキュリティガイドを公開しており、構成基準策定に役立てることができます。

• AWS Well-Architected Framework: Security Pillar
• Center for Internet Security (CIS) Benchmark for AWS
• Best Practices for Security, Identity, & Compliance
• AWS Trusted Advisor
• Top 10 security items to improve in your AWS account

ベンダーのデフォルト設定の変更

AWS環境に組み込まれたサードパーティソフトウェアやコードのベンダー提供のデフォルトを変更する責任があります。AWSサービスにはデフォルトアカウントやクレデンシャルはなく、顧客はIAM、AWS IAM Identity Center、Amazon Cognito、AWS Directory Serviceなどの認証メカニズムを使用してアクセスを設定する必要があります。

非コンソールの管理

AWSリソースの管理をコンソール（GUI）以外の方法で行うことに対して、SSH、HTTPS、VPNなどの暗号化された接続を使用してリソースにアクセスし、管理操作を実行する必要があります。これには、AWS Management Console、AWS CLI、またはサービスAPIを使用してリソースを管理する場合も含まれます。
非コンソール管理は、管理接続のセキュリティを確保し、クレデンシャルの盗難やデータ漏洩のリスクを軽減することを目的としています。

要件3：保存されたアカウントデータの保護

要件3は、強力な暗号化によってデータを保護することを求めています。
AWSでは、RDS、ElastiCache for Redis、S3といったほとんどのストレージサービスで暗号化機能を提供します。また、Amazon Macieを使用してS3に保存されている機密データを発見、分類、および保護することもできます。

3.2

この要件では、アカウントデータの保存を最小限に抑えることを求めています。
例えば、DynamoDBのTTL機能を使用することで、アイテムごとにTTLを設定し、指定された時間が経過するとDynamoDBがテーブルからアイテムを自動的に削除することが可能です。

3.3

この要件では、機密認証データ（SAD）の保存の禁止を求めています。
オーソリゼーションプロセス（加盟店での取引）が完了した後に、機密認証データ（SAD）の保存を行わないようにシステムを構成する必要があります。

3.5

この要件では、静止データを暗号化することを求めています。
S3を使用する際はS3マネージドキーによる暗号化(SSE-S3)やCMKによる暗号化(SSE-KMS)に加え、バケットポリシーとIAMポリシーの組み合わせによるアクセス制限も可能です。RDSの場合はCMKおよびRDSマネージドキーでの暗号化をサポートしています。
これらのサービスの他にも、ほとんどのストレージサービスで暗号化機能を提供しています。

要件4：オープンな公共ネットワークでの送信時に、強力な暗号化技術でカード会員データを保護する

要件4は、信頼されていないネットワークや公衆ネットワークなど、悪意のある個人が容易にアクセスできるネットワークを介してカード番号（PAN）を送信する際に強力な暗号化を求めています。

4.2

この要件では、カード番号（PAN）が公衆ネットワーク上で送信される際に暗号化することを求めています。
Amazon CloudFront、Amazon API Gateway、およびElastic Load Balancersなどの外部に公開されているAWSサービスは、TLS 1.2以上のトランスポート暗号化レベルをサポートしており、これを強制するポリシーを実装できます。
セキュリティグループを設定することで、不要なプロトコルの使用をブロックできます。
またAWS Certificate Manager（ACM）を使用し、CloudFront、API Gateway、Elastic Load BalancerにSSL/TLS証明書を割り当てることで、AWS内部への通信の暗号化も可能です。

要件5：悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する

要件5はウイルス、トロイの木馬、ワーム、スパイウェア、ランサムウェア、キーロガー、ルートキット、悪意のあるコード、スクリプト、リンクなどのマルウェア対策を求めています。

5.2

この要件ではマルウェアの検出および対策を求めています。
RDSやFargateなどのAWSマネージドサービスの基盤リソースに対するアンチウイルスおよびアンチマルウェア保護はAWSの責任範囲です。AWSマネージドサービスではないEC2インスタンスやコンテナ上のシステムに対してのマルウェア対策はお客様側の責任範囲です。

Amazon GuardDutyのマルウェア保護機能を有効にすると、疑わしい動作が検出されたEC2インスタンスおよびコンテナワークロードで自動スキャンが実行され、疑いのあるアクティビティを検出はできますが、検出されたマルウェアの対策まではサポートしていません。
AWS Marketplaceには、顧客が利用できる多くのマルウェア対策製品が提供されているため、必要に応じてこれらを活用する必要があります。

要件6:安全なシステムおよびソフトウェアの開発と維持

要件6は、悪意のある個人や悪意のあるソフトウェアによるアカウントデータの搾取や侵害から保護することを求めています。

6.2

この要件ではセキュアなソフトウェア開発が求められています。
AWSでは、AWS CodeCommit、AWS CodePipeline、AWS CodeBuild、AWS CodeDeployなどのサービスを使用して、継続的インテグレーション（CI）と継続的デプロイ（CD）パイプラインに組み込むことができます。ソフトウェア開発のライフサイクルにおける各段階で適切なテスト、検証、承認が行われるようにすることが顧客の責任です。

6.3

この要件ではセキュリティの脆弱性を特定およびパッチ適用を求めています。
AWSでは、EC2インスタンスやECSコンテナにおける脆弱性は、Amazon Inspectorを用いて検出できます。Amazon Elastic Container Registry（ECR）のイメージスキャン機能は、コンテナイメージのソフトウェア脆弱性を特定が可能です。

セキュリティパッチの適用については、Systems Manager Patch Managerを使用してEC2インスタンスへのパッチのアップデート、メンテナンス、デプロイを自動化できます。

6.4

この要件では一般公開されているウェブアプリケーションを攻撃から守ることを求めています。
AWSでは、AWS WAFを使用して、ウェブベースの悪意あるアクティビティの検出および防止を自動化するソリューションを実装できます。

6.5

この要件ではシステムコンポーネントの変更が安全に管理されていることを求めています。
AWSでは本番環境とそれ以外の環境の、AWSアカウントもしくはVPCを分離した上で、IAMを使用して役割に応じたアクセスコントロールを実装することができます。

要件7：システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲（Need to Know）によって制限する

要件7は、システムコンポーネントとカード会員データへのアクセスを必要最低限にすることを求めています。

7.2

この要件では、アクセスを制限のために以下のプロセスおよびメカニズムを求めています。

アクセス権のレビュー

少なくとも半年に一度、アクセス権限を見直す必要があります。
AWSではアカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。これによって誰が環境へのアクセスを許可されているかを確認できます。

最小特権の原則

システムにアクセス可能なユーザは最小特権の原則に従って運用される必要があります。
AWSではIAMポリシーで権限を定義し、それをIAMグループにアタッチすることで、役割に応じたユーザ管理を実装できます。また、IAMユーザーを個別の作業者に割り当てMFAデバイスの設定を行うことで、権限を持たない作業者のAWS Management Consoleへのアクセスを防ぐことができます。

カード会員データへのアクセス制御

カード会員データへのアクセスはユーザの役割と最小特権に基づくアクセスおよび許可されたアクションを行う必要があります。特にデータの移動、コピー、削除などの権限を不用意に与えないように権限範囲を定義する必要があります。

AWSでは、セキュリティグループ、ネットワークACL、およびIAMロールを使用して、データベースへのアクセスを必要なアプリケーションとサーバーに限定し、外部からのアクセスやまたは不正なアクセスの可能性を防ぐことができます。また、AWS Secrets Managerを使用して、データベースのクレデンシャルを安全に保存することができます。

7.3

この要件では、システムおよびデータへのアクセス制限するために、デフォルトの許可設定を「すべて拒否」にすることが求められています。
AWSでは、IAMポリシー、S3バケットポリシー、KMSキーのポリシー内で定義された権限の評価ロジックはデフォルトで「すべて拒否」が含まれています。

要件8：ユーザの識別とシステムコンポーネントへのアクセスの認証

要件8は、システムにアクセスるユーザの識別の確立および認証の証明を求めています。

8.2

この要件では、ユーザ識別について以下のことを求めています。

共通の認証情報の使用制限

必要に応じて例外的な場合を除き、資格情報の共有を許可してはいけません。
AWSでは、Secrets Managerを使用して共有資格情報を安全に保存し、CloudTrail監査証跡にアクティビティを記録することで共有資格情報にアクセスしたユーザおよびリソースを特定することができます。

90日間の非アクティブユーザーアカウントの削除

非アクティブなユーザーアカウントを特定し、90日間の非アクティブ期間内に削除または権限を無効にする必要があります。 AWSではLambdaやCloudWatchを使用して、ユーザの監視およびIAMユーザーの削除（権限の無効化）を自動化を設定することができます。

アイドルセッションタイムアウト

15分のアイドルセッションタイムアウトを実装および強制する必要があります。
AWS Systems Manager Session Managerや、デバイスのスクリーンセーバー機能によってこれらを実装できます。

8.3

この要件では、利用者および管理者の強力な認証のために以下のことを求めています。

パスワードポリシー

最低12文字のパスワード、90日以内の有効期限、過去4つ以上のパスワードの再利用防止を強制するパスワードポリシーを強制する必要があります。
AWSではIAMパスワードポリシーの設定や、AWS Directory Serviceを使用してこれを実装できます。

アカウントロック

無効なログオン試行回数10回以下でユーザアカウントをロックアウトするよう設定する必要があります。
AWSではAWS Managed Microsoft ADを使用するか、AWSCloudTrail、Amazon DynamoDB、AWS Lambda、Amazon CloudWatchを組み合わせることによってこれらを実装できます。

8.5

この要件では、多要素(MFA)認証の確立が求められています。
AWSでは、IAMポリシーによってAWSマネジメントコンソール、AWS CLI、およびAPIアクセスに対するMFA認証の強制を実現できます。

8.6

この要件では、スクリプト、構成ファイル、カスタムソースコードに認証情報がハードコーディングされていないことが求められています。
AWSでは、Systems Manager Parameter StoreまたはSecrets Managerを使用してパスワードや機密情報を保存し、必要に応じてアプリケーションから取得することができます。Parameter StoreとSecrets Managerに保存された機密データは、顧客のKMSキーを使用して暗号化することができます。

要件9:カード会員データへの物理アクセスを制限する

要件9は、システムの物理デバイスの管理について定義されています。
AWSリソースの物理デバイスの管理はAWS側の責任範囲です。

要件10:システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視すること

要件10は、何か問題が発生した場合の追跡、分析のために可能にログを記録することを求めています。

10.2

この要件では監査ログの実装を求めています。
AWSでは、Cloud Trailを用いてAWS環境内のイベント履歴を記録しており、これらをS3に保管することが可能です。
EC2インスタンスにCloudWatchエージェントをインストールすることでOSログをCloudWatchLogsに送信することが可能です。
RDSインスタンスにおいては監査ログ取得の設定を有効にすることでCloudWatchLogsに監査ログを送信することが可能です。

10.3

この要件では監査ログの保護を求めています。
AWSではIAMポリシーを使用してCloudTrailおよびS3へのアクセスを制限を実装でき、特定の担当者のみが監査ログにアクセスできるようにします。
S3にはバージョニング、ライフサイクルポリシー、オブジェクトロック機能をサポートしており、監査ログを削除や改ざんから保護できます。

10.4

この要件では取得した監査ログをレビュー可能にすることを求めています。
AWSではAthenaとQuickSightを使用することでS3に保管された監査ログを視覚化することができます。
MarketplaceでもSIEMオプションが提供されているため、必要に応じて導入することができます。

また、EventBridgeやCloudWatchアラーム、Lambda、SNSを活用することで、特定のアクティビティや状態に対するアラート機能を実装することができます。

10.5

この要件では監査ログを最低でも1年間分を保持し直近3ヶ月分は直ちに分析できるようにすることを求めています。
AWSでは監査証跡を保持するために専用のS3バケットを使用し、3ヶ月以上経過したデータをS3 Glacierに移行するためのライフサイクルポリシーを設定することで、ログの保管期間を設定することができます。

10.6

この要件では正確で安全な時刻同期を求めています。
AWSではEC2インスタンスとコンテナに設定可能なAmazon Time Sync Serviceを提供し、NTPを使用して協定世界時（UTC）の正確な現在時刻を提供します。また、プライベートサブネット内から安全にアクセスすることが可能です。

10.7

この要件では重要なセキュリティ対策システムの障害が迅速に検知、警告、対処されることを求めています。
前述のCloudWatchアラームやEventBridgeなどを用いた以上検知に加え、Configのカスタムルールを作成して、リソースを監視し、変更が検出された場合にSNSトピックに通知を送信することができます。

要件11:システムおよびネットワークのセキュリティを定期的にテストする

要件11は、システムやネットワークのセキュリティテストの実施を求めています。

11.3

この要件ではシステム内部および外部の脆弱性スキャンを求めています。
AWSではAmazon Inspectorを用いて、EC2インスタンス、コンテナに対してネットワーク到達可能性およびパッケージの脆弱性を検出できます。またこれらに加えLambda関数に対するコードの脆弱性も検出可能です。

11.4

この要件では、ペネトレーションテスト（侵入テスト）の定期的な実行を求めています。
AWSでは許可されたテストと、禁止されているテストを定めているのでこれらを確認し、ペネトレーションテストを定期的に実行する必要があります。
侵入テスト 定義されたセキュリティ標準に対してAWS環境をテストする

11.5

この要件ではネットワークへの侵入や予期せぬファイルの変更を検知し対処することを求めています。

ネットワーク侵入検知

ネットワークへの不正な侵入を検知および防止するために、侵入検知システム（IDS）および侵入防止システム（IPS）の導入を検討する必要があります。
AWSサービスではGuardDutyやWAFなどのサービスを利用して、IDS/IPS機能を実装できます。 また、VPC内へIDS/IPSアプライアンスのデプロイや、EC2インスタンスにホストベースのIDS/IPSをインストールすることも考えられます。MarketplaceではIDS/IPSオプションを提供しており、必要に応じて導入を検討しましょう。

変更検知

対象のリソースおよび重要なシステムファイルの変更検知およびアラートを実装する必要があります。
AWSでは、CloudFormationドリフト検知を使用して、デプロイ時のテンプレートから異なるCloudFormationスタックの変更を検出できます。
Configは、AWSリソースの構成を継続的に監視および記録し、変更を検知することができます。

11.6

この要件では決済ページの不正な変更の検知・対応が求められています。
AWSでは、S3の読み取り専用バケットでホストされた静的ウェブサイトを使用することでページコンテンツの改ざんを防止できます。

要件12:組織の方針とプログラムによって情報セキュリティをサポートする

要件12は、組織全体の情報セキュリティ方針の文書化・周知およびセキュリティインシデント対応を求めています。
AWSではControl Towerでサービスコントロールポリシー（SCP）を使用したアカウント内のリソース利用制限を実装できます。
Detectiveはセキュリティインシデントの原因を特定に役立ちます。
Configは前述の通りAWSリソースの構成を継続的に監視および記録し変更を検知することができます。

また、AWSはAWS セキュリティインシデント対応ガイドを公開しており、AWS環境内でのセキュリティインシデント対応の基本について概要を説明しています。

最後に

今回はAWSの提供するコンプライアンスガイドをもとに、AWS環境におけるPCI DSS v4.0準拠の方法についてまとめていました。
PCI DSSの各要件や、準拠に役立つAWSサービスの理解の一助になれば幸いです。