本記事ではPCI DSS 4.0.1をベースに、AWSでは要件1を満たすためにどのような方針を検討したかをまとめています。
※準拠のためには必ず本家本元の資料を確認してください。
要件1概要
ネットワークの境界において、信頼できないネットワークからのアクセスを制限する。
- ネットワークセキュリティコントロールを導入・維持するためのプロセスや仕組みが定義され、理解されている。
- ネットワークセキュリティコントロール（NSC）が設定され、維持されている。 カード会員データ環境への、およびカード会員データ環境からのネットワークアクセスが制限され ている。
- 信頼できるネットワークと信頼できないネットワーク間の接続が制御されている。
- 信頼されないネットワークとカード会員データ環境（CDE）の両方に接続できるコンピューティングデバイスによるカード会員データ環境（CDE）へのリスクは軽減される。
※信頼できないネットワークとは、インターネットや他組織のネットワーク、自組織内でもCDE環境外のネットワークを主に意味する。
■準拠に必須なAWSサービス
・セキュリティグループ
・AWS Shield Standard
■任意に選択するAWSサービス
・ネットワークACL
・AWS Network Firewall
・AWS Network Manager
・AWS CloudFormation
・AWS Config
■任意に利用するサードパーティーサービス
・FW/IDSアプライアンス
・Teraform
要件1.1
AWSへの依存がないため、本記事の対象外
要件1.2
「ネットワークセキュリティコントロール(NSC)が最新化され、適切に運用されていること。」
NSCを明確に定義すること、必要性に基づきかつ資料化されること、NSCが最新化され不正にシステム適用されないことが求められます。
「データフロー図」「ネットワーク構成図」の整備が求められており、業務上必要な通信だけを許可するよう示されています。
また、これらの資料に基づき必要な通信のみを適用することが求められ、設定に必要な構成ファイルが不正アクセスされず、更新されないことが必要です。
■方針
- ネットワーク通信の必要性(根拠)に応じてネットワーク設計を行う
- 不要なサービスは起動させず、インバウンド／アウトバウンド問わず、必要な通信許可のみをセキュリティグループで許可する
- AWSおよびセキュリティアプライアンスへのアクセスを制限する
- (オプション)CloudFormationやFirewall Managerを用いて、変更の追跡やマルチアカウントのセキュリティ管理を行う
要件1で求められているNSCに関しては、Vセキュリティグループとルートテーブル、VPCによるネットワーク分割にて要件の達成が可能です。セキュリティグループでは不要な通信許可は行わない(特にアウトバウンド)ように設計します。加えてOSレベルでも不要なポートを閉じたいため、EC2利用の場合は、利用予定のないサービスは停止させます。(例:postfix)
要件1.3
カード会員データ環境(CDE)と非CDEの発着信トラフィックを制限する
■方針
- セキュリティグループで必要最低限のトラフィックを許可
- (オプション)AWS Network FirewallでVPCレベルでアクセスコントロール
- (オプション)AWS Firewall Managerによるセキュリティルールの一元管理
基本方針はセキュリティグループを用いたアクセス制限となります。システムが大規模でVPC数が多い場合には、AWS Network Firewallで明確にVPCに出入りする通信を分離することも可能です。ただし、2024年10月よりVPC間のセキュリティグループ共有機能が追加されたことにより、VPCをまたがってのセキュリティグループによる細かなネットワーク制御が可能になったため、AWS Network Firewallを使わないことも十分可能です。
要件1.4
信頼できないネットワークとCDE環境を分離し、許可しないユーザーからのアクセスを許容しない。
■方針
- セキュリティーグループで必要最低限のアクセスを許可する
- カード会員データが保存されているコンポーネント(EC2やFargate、RDS、S3など)はインターネットからアクセス不可とする
- インターネットや信頼できないネットワークとの通信は、NATやプロキシを用いて内部IPを秘匿する
*（オプション）ミドルウェアなどを利用してスプーフィング対策を実施する（レイヤー3以上）
*（オプション）CDE環境の分離を明確化するため、AWSアカウントレベルを分割する。
CDEの分離要件は要件1.2および要件1.3と大きくは変わりませんが、カード会員データ(CHD)が保存されるサーバーへのアクセスを制限することを要求しています。また、新規にローカルIPを用いた不正なアクセスへの対策が求められています。内部IPの漏洩対策やスプーフィング対策が必要です。前者はプロキシおよびNATを利用して双方向でIPの秘匿を行います。後者は、レイヤー2はAWSデフォルトで対策しているため、必要に応じてレイヤー3以上の対策が可能ですが、基本的には追加対策は不要です。
また、要件1では直接の用語は出てきていませんが、カード会員データ環境(CDE)の対象と対象外が明確に混在する場合は、それらをVPCレベルで分割することが推奨されます。(要件XX)また、VPC外のリソースをCDE対象とCDE対象外で利用する場合は、アカウント単位で分割し、AWSマネージドサービスも明確に分離させることも選択肢に入ります。マルチアカウントは設計の煩雑さが増えるので、VPCによるネットワーク分割だけではQSAに説明しにくい際のテクニックとしての選択肢になります。
要件1.5
AWSへの依存がないため、本記事の対象外
まとめ
要件1ではCDE環境の分離が主に求められています。VPCの分離とセキュリティグループによる通信許可設計といった一般的なセキュリティ対策を行います。
基本的な設計思想はPCI DSSだから特別ということはなく、適切なネットワークの分離を行えば問題ありません。
一方で、「信頼できないネットワーク」などのPCI DSSならではの定義があります。
確実にPCI DSSに準拠させるためにも、PCI DSSの準拠範囲を明確化はさせる必要があります。
そのうえでプロキシやNATの活用によるIP秘匿、インターネットからのCHDアクセス制限などの対策を行います。
また、AWS上のシステム設計とは関連がないため記載していませんでしたが、ネットワーク図などのドキュメント作成も行うので、ドキュメントにてネットワークの分離が明確に読み取れるよう作成することで保守性も向上させるのが良さげです。