近年、クラウド環境を利用してシステムを構築する企業が急増しています。中でもパブリッククラウドサービスとしていち早く開始されたAWS（Amazon Web Services）はトップシェアを誇っており、AWSを利用している企業や今後移行を検討している企業も多いかと思います。
クレジットカードに関するセキュリティの国際基準であるPCI DSSもそうした変化の影響を受けており、2022年3月にリリースされた最新バージョンであるv4.0では、クラウド環境に柔軟に対応することを意図した要件が多数見受けられました。
AWS環境でPCI DSSに準拠する場合、AWSの提供する各種サービスをうまく活用することで、要件への対応を効率的に実施することが可能です。一方で、デフォルト設定で運用するだけでは要件を満たせないサービスも多く、その設定値や運用方法についてはユーザ側で正しく理解しておくことが重要です。
そこで本記事では、PCI DSS v4.0からいくつかの要件をピックアップし、AWS環境での対応方法について見落としがちなポイントを交えながら解説していきます。
AWS環境における責任分界点について
「AWS責任共有モデル」を理解する
各要件の解説に入る前に、まずはAWS環境におけるユーザとAWSの責任分界点について見ていきましょう。
図１：AWS公式サイトより引用
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
上記の図は、AWS環境のセキュリティにおける責任分界点を示した「AWS責任共有モデル」です。この図では、階層ごとにユーザとAWSのどちらがセキュリティに関する責任を持って運用を行うかが示されています。例えば、AWS環境の基盤となるリージョンやアベイラビリティゾーンの管理、ハードウェアやストレージのセキュリティについてはAWSの責任であると記載されています。一方で、AWS環境上に保存するデータの暗号化や、アカウントのセキュアな管理・運用、OSやNWの設定等は基本的にユーザ側で責任を持って行う必要があることが分かります。
PCI DSSへの対応を行う際も、どのサービスで・どのパラメータを・どのように設定するべきかという点については、ユーザ責任となる範囲を明確化した上で判断する必要があります。AWSがサービスプロバイダとして準拠の責任を負うPCI DSS要件については、PCI DSSの準拠証明書であるAttestation of Compliance（AOC）や、AWS PCI Responsibility Summaryのドキュメントから確認することができます。AWSのユーザであれば、これらはコンプライアンスレポートのダウンロードサービスであるAWS Artifactからいつでも入手することが可能です。
PCI DSS v4.0について
PCI DSS v4.0要件とクラウドの関係
続いて、本記事のテーマであるPCI DSS v4.0とクラウドの関係性についてです。
冒頭で記載した通り、v4.0ではクラウド環境の増加を踏まえたと思われる変更点が多数盛り込まれています。
例えばv3.2.1の要件1で使用されていた「ファイアウォールとルータ」という表現は、v4.0では「ネットワークセキュリティコントロール」という表現に置き換えられました。この変更は、従来型の「ファイアウォールとルータ」には当てはまらないクラウド環境ならではのセキュリティコントロール―AWS環境の場合は、AWSアカウントの分離による環境のセグメンテーションや、セキュリティグループやネットワークACLを利用したネットワーク層での制御など―を包含するような意図があると考えられます。
v4.0要件の主な変更点については以下の記事で解説していますので、こちらをご参照下さい。
PCI DSS v4.0リリース情報｜その特徴とv3.2.1との差分、対応方針について解説
すでにクラウド環境を利用している企業では、要件の枠組みが柔軟になったことにより、自社環境に当てはめて対応を進めやすくなっているのではないでしょうか。
AWSサービスを活用した要件への対応
では、本題であるAWS環境におけるv4.0要件への対応方法について解説していきたいと思います。
今回は全12要件の中から、特にAWSのサービスを利用して実装されることの多い要件をピックアップし、要件を満たすためのポイントも交えてご紹介します。
要件1 ネットワークセキュリティコントロールの導入と維持
要件１ではそのタイトル通り、ネットワーク周りのセキュリティコントロールに関する要件が定義されています。本要件への対応としては、AWSの仮想ファイアウォール機能として提供されているセキュリティグループを主に利用することとなります。そして、前述の責任共有モデルに基づき、セキュリティグループの設定やトラフィックの管理はユーザ責任となっています。
要件１の中ではカード会員データ環境（CDE）へのトラフィックを必要最小限とすることが要求されているため、それに応じた形でセキュリティグループを設定することが必要です。
- 【要件1.3.1】カード会員データ環境（CDE）への着信トラフィックは、必要なトラフィックのみにする。また、その他のトラフィックを明確に拒否する。
- 【要件1.3.2】 カード会員データ環境（CDE）からの発信トラフィックは、必要なトラフィックのみにする。また、その他のトラフィックを明確に拒否する。
セキュリティグループのデフォルト値は以下のように設定されており、送信元セキュリティグループに関連付けられたネットワークインターフェイスからのトラフィック以外は受信しない形となっています。つまり、追加の設定を行わなければ外部からのトラフィックは一切受け付けないという状態です。一方で、アウトバウンドルールについてはすべてが許可されており、制限は設けられていないことが分かります。
図２：AWS公式サイトより引用
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/default-custom-security-groups.html
セキュリティグループはホワイトリスト方式のため、着信トラフィックについてはCDEに必要なトラフィックのみをインバウンドルールに追加していくことで、要件に沿った構成とすることができます。
一方、発信トラフィックについてはデフォルト設定が残っているとすべての通信が許可されてしまうため、デフォルト値を削除した上で必要なトラフィックのみを追加していく必要があります。なお、セキュリティグループは復路の通信を動的に許可する「ステートフル」と呼ばれる動きをするため、復路の通信要件はアウトバウンドルールに記載する必要がない点がポイントです。
CDEに限らず、他の場所でも同様にセキュリティグループを設定することで、以下の要件で求められている通りに必要最小限のトラフィックに絞った制御を実装することが可能となっています。
- 【要件1.4.2】信頼できないネットワークから信頼できるネットワークへの着信トラフィックを、以下に制限する。
- ・一般に公開されたサービス、プロトコル、ポートを提供することが許可されているシステムコンポーネントとの通信
- ・信頼できるネットワーク内のシステムコンポーネントによって開始された通信に対するステートフルな応答
- ・その他のトラフィックはすべて拒否
要件6 安全なシステムおよびソフトウェアの開発と維持
要件６では、主にアプリケーションの開発プロセスとその保護に関する内容が定義されています。Webアプリケーションの保護については、v3.2.1ではWAFの利用または定期的な脆弱性診断のいずれかが要求されていましたが、v4.0からはWAFもしくはWAFと同等の機能を導入することが必須化されています。
- 【要件6.4.2】一般公開されているWebアプリケーションについては、Webベースの攻撃を継続的に検知・防止する自動化された技術的ソリューションを導入する。また、ソリューションは少なくとも以下の条件を満たす必要がある。
- ・一般公開されているWebアプリケーションの前にインストールされ、Webベースの攻撃を検知・防止する。
- ・アクティブに実行され、最新の状態に更新される。
- ・監査ログを生成する。
- ・Webベースの攻撃をブロックするか、アラートを生成して直ちに調査するように設定されている。
本要件への対応としては、Webベースの攻撃をブロックするAWS WAFのサービスを活用することが考えられますが、ユーザ側ではどういった設定を行うべきでしょうか。
図３：AWS公式サイトより引用
https://aws.amazon.com/jp/waf/
まず、AWS WAFの監視ルールはユーザによるカスタム設定が行えるほか、提携するセキュリティベンダやAWSの提供するマネージドルールを設定することが可能です。WAFの運用について十分な知識があればカスタム設定を行っても良いですが、マネージドルールもOWASP TOP 10をカバーするもの等が提供されており、こちらを利用することで要件を充足できると考えられます。
加えて、マネージドルールの場合はルールの更新も自動で行われるため、ユーザ側の管理の負荷を軽減することが可能です。WAFの運用に慣れていない企業の場合は、マネージドルールを利用するのが良いでしょう。
また、ログの取得についてはユーザによる設定が必要となるため注意が必要です。AWS WAFのダッシュボードからログ機能を有効化し、ログの出力先としてAmazon CloudWatch Logs のロググループや、Amazon Simple Storage Service (S3)のバケットを指定しましょう。この設定によってAWS WAFのログが自動で出力・保管されるようになります。
要件7 システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲によって制限する
要件8 ユーザの識別とシステムコンポーネントへのアクセスの認証
要件7および要件８では、アカウントの管理に関する内容が細かく定義されています。
AWS環境におけるアカウント管理には、主にAWS Identity and Access Management (IAM)サービスが使用されますが、IAMの適切な設定・管理のみでは要件を満たせるとは限らない点に注意が必要です。
例えば最上位の権限を持つAWSアカウント（ルートユーザー）については、IAMで設定できる以上の強力な権限を有しているため、以下の要件に基づき通常の運用では利用しないことが原則となります。
- 【要件7.2.2】特権ユーザを含むユーザには、以下に基づいてアクセスを割り当てる。
- ・職務分類と機能
- ・職責を果たすために必要な最小限の特権
また、責任共有モデルにも示されている通り、IDとアクセス管理については基本的にすべてがユーザ責任となっているため、IAMユーザのパラメータ設定はユーザ側で行う必要があります。さらに、本要件ではAWSレイヤのアカウントのみでなく、OSやアプリケーションのアカウントについても要件を満たす必要がある点に注意してください。
例えば以下のAWS環境がPCI DSSの審査スコープとなっている場合、当該環境で使用されるすべてのIAMユーザに加えて、Windows OSおよびLinux OSのアカウントや、アプリケーションのアカウントについても要件に準拠した設定と管理が求められます。
図４：AWS構成図サンプル
特に要件8では、以下のようなアカウントのパスワードパラメータに関する要求事項が複数設けられており、対応の負荷が大きくなることが予想されます。パラメータの修正は運用に影響が生じることも多いため、まずは対象となるアカウントの洗い出しを正しく行うことが重要です。
- 【要件8.3.6】要件8.3.1を満たすためにパスワード／パスフレーズを認証要素として使用する場合、以下の最小レベルの複雑さを満たすこと。
- ・12文字以上（システムが12文字に対応していない場合は8文字以上）であること
- ・数字とアルファベットの両方が含まれていること
AWS環境においても、オンプレ環境と同様の観点でアカウントの洗い出しと一覧化を行い、その上でパラメータの実装を進めるようにしてください。
要件10 システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視する
最後に、ログの収集とその管理について定めた要件10を取り上げたいと思います。
AWS上のログ収集・管理サービスとしてはAWS CloudTrailが提供されており、この機能自体はAWSアカウントを作成すると自動で有効化されますが、要件を満たすためにはさらに追加の設定が必要です。
まず、一つ目のポイントとしてログの保管期間が挙げられます。CloudTrail のログ保管期間は最大90日となっており、そのままでは以下の要件を満たすことができません。
- 【要件10.5.1】監査ログの履歴を少なくとも12ヶ月間保持し、少なくとも直近の3ヶ月間は分析のために直ちに利用できるようにすること。
CloudTrail単体でログを12ヶ月以上保管することはできないため、他サービスとの連携によって保管を行う必要があります。方法はいくつかありますが、メジャーな手段としてはまずCloudWatch Logsを利用する方法が挙げられます。
CloudWatch Logs の場合ログはデフォルトで無制限に保管されるため、CloudTrailのログをCloudWatch Logsに出力することで12ヶ月以上の保管が可能となります。ログの閲覧もCloudWatch Logsのダッシュボード上でいつでも行うことができ、保管期間を定めることも可能なので非常に便利なサービスです。他にも、CloudTrailのログをS3に出力し、S3側でライフサイクルポリシーを設定して12ヶ月またはそれ以上の保管を行うといった方法も有効です。
二つ目の見落としがちなポイントは、先述したアカウントに関する要件と同様に、ログについてもOSやアプリケーションのレイヤを考慮する必要がある点です。
先ほどの環境を例に挙げると、当該VPCにおけるCloudTrailログの他、Windows OSのイベントログ、Linux OSのsyslog、アプリケーションログについても要件に沿った収集と管理が必要となります。
図４：AWS構成図サンプル
なお、上記の図ではインスタンスにCloudWatch Logsのエージェントを導入し、OSやアプリのログもまとめてCloudWatch Logs に出力させることで、ログの一元管理を行っています。これらはAWS環境外で個別に管理しても問題ありませんが、ログの種類ごとに保管場所が異なっていると日々の運用における見落としや監査の際の証跡提出の手間が生じやすくなるため、1つの場所で管理することをお勧めします。
おわりに
一部抜粋という形ではありますが、PCI DSS v4.0要件について、AWS環境上で対応するためのポイントを解説させて頂きました。
AWSのサービスは日々新しいものが追加されており、また仕様も細かく変わっていくため、最新情報をキャッチアップしながら対応を進めることが重要です。
弊社にはAWS認定資格を持つ社員が複数在籍しており、AWS環境におけるPCI DSS準拠支援の実績も多数ございます。新たな基準へ向けた対応についてお困りごとがある場合は、是非ともご相談下さい。
