セキュリティサービス部 佐竹です。
2024年11月に投稿された AWS 公式ブログをご紹介しながら、PCI DSS のための推奨 OU 構成について学びます。
はじめに
本ブログは AWS Organizations についての基本をご理解されている方（中級者）向けに記載しております。AWS Organizations についての理解をされたい場合は、以下で紹介するブログを（かなり時間を要するとは思いますが）順に読まれてから本ブログを確認されることをお勧めします。
では、まずは過去のブログの振り返りです。
AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成
以前、2021年8月頃に、以下のブログを記載しました。
このブログは、AWS のホワイトペーパー（白書）を紹介しながら、具体的な AWS Organizations の推奨 OU (Organizational Unit) 構成を学ぶものです。
AWS のホワイトペーパーに新しい推奨 OU として Business Continuity OU が追加されました
また、情報更新版として、2024年6月に「Business Continuity OU」について掘り下げました。
「Business Continuity OU」の概要は以下の通りです（上記ブログより抜粋）。
ビジネス継続性 OU は、チームが「クロスアカウントでの災害復旧戦略」の実装を支援することを目的としています。データは可能な限りエアギャップに近いもので、OU にはワークロードリソースが存在しません。これにより、組織を保護し、ランサムウェアなどの深刻な災害からの復旧を可能にする「セキュアデータバンカー」が作成されます。
AWS Organizations における推奨 OU 構成のベストプラクティス2025年度最新版を学ぶ
2025年7月に、最新の推奨 OU 構成と、AWS Organizations に関するここ1年の更新をまとめました。
ということで今回ですが、推奨 OU 構成に関連して、PCI DSS のための推奨 OU 構成について学んでいきたいと思います。
関連する AWS 公式ブログ記事の紹介
2024年11月15日に、以下のブログが投稿されています。
本ブログにおいて、「Architecting for PCI DSS Segmentation and Scoping on AWS」というタイトルのホワイトペーパーが2024年度版として更新されたことが紹介されています。
なお2023年版の日本語版も存在しており、「AWS における PCI DSS スコーピングとセグメンテーションのためのアーキテクチャ」という和訳になっています。
Architecting for PCI DSS Segmentation and Scoping on AWS とは
このホワイトペーパーは、AWS クラウドを用いて「セキュリティ基準である PCI DSS 4.0 に準拠する必要があるお客様の支援」を目的としたものです。ブログ本文では以下の通りの強調が記載されています。
今回のアップデートでは、PCI DSS に対応するためにネットワーク層で実用的かつ実用的な設計パターンを提供することで、大幅な機能強化が図られています。以前のバージョンのホワイトペーパーをご覧になった読者の皆様には、今回のアップデートで以下の重要な機能強化がもたらされていることをお知らせいたします。
- アカウント構造のリファレンスアーキテクチャ: AWS Organizations の組織単位（OU）と AWS アカウントの構成は、ネットワークレイヤーの設計とセグメンテーション（分離）の基盤となります。このホワイトペーパーでは、PCI DSS コンプライアンスに役立つよう設計された、これらの構成に関する推奨事項を提供します。
- 実践的なネットワーク設計パターン: ネットワークレイヤーのアーキテクチャパターンは、お客様がワークロードのトラフィックフローを構造化するのに役立ちます。
- ファイアウォールルールの具体例: 今回の更新で追加されたルール設定例により、PCI DSS 要件に準拠したトラフィック制御をより簡単に実施できるようになります。
- 強化されたセグメンテーションガイダンス: 概念的なアドバイスにとどまらず、より実践的なアプリケーションシナリオに適用できる、ハンズオンでの実装情報を提供します。
さて、今回はこの中から「Reference architectures for account structure/アカウント構造のリファレンスアーキテクチャ」に注目してご紹介していきます。
PCI DSS のための推奨 OU 構成を学ぶ
セキュリティ対策の原則「多層防御」
まず大前提として「多層防御」の原則について触れます。
セキュリティにおいて「これだけで安全だ」という万能薬（銀の弾丸）はありません。
これは技術の進化、脅威の変化、ビジネス要件の変更等に伴い脆弱性も変化するためです。これが、セキュリティにおける「運用」が重要視される理由でもあります。
このために、一つの防御策に依存せず複数の対策を重ねる「多層防御」が不可欠となります。AWS クラウドを利用していたとしてもそれは変わりません。
よって、PCI DSS のための推奨 OU 構成においても「いかに多層防御を実現するか？」が鍵になります。
AWS Well-Architected Framework とマルチアカウント戦略
もう1つの前提として「AWS Well-Architected Framework」についても少し解説を行います。
「AWS Well-Architected Framework」は AWS 上でシステムを構築・運用するためのベストプラクティス集で、6つの柱で構成されています*1。以下がその6つの柱です。
- オペレーショナルエクセレンス
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
このうち「セキュリティの柱」の最初のベストプラクティスが「SEC01-BP01 アカウントを使用してワークロードを分ける」となっています。
上記ドキュメント内に アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。 と記載がある通り、適切な AWS アカウントの使い分け（マルチアカウント戦略）は強力なセキュリティのガードレールとなります。
ここまでをまとめると、まず原則として「多層防御が重要」であること。そして、AWS において多層防御を構成する最も重要なファクターが「マルチアカウント戦略」であり「AWS アカウントの適切な分離」となります。
PCI DSS におけるセグメンテーション
さて、ここからが本題となりますが、まず CDE について記載します。
CDE: カード会員データ環境
CDE（Cardholder Data Environment）とは、決済情報を保護するために設定される、PCI DSS の準拠対象となる IT インフラの範囲であり、システムコンポーネントの集合体です。
この CDE をセグメンテーション（分離）によって最小化することが、コンプライアンスのコストと労力を削減するための重要なポイントとなります。
AWS における多層的なセグメンテーション
ではこのセグメンテーションを AWS で実装する場合には、まずどのようにセグメンテーションをすべきでしょうか？具体的には以下の4つの層に分離することが推奨されています。
- ① アカウント層
最も強力な分離境界です。PCI DSS 用のワークロードを専用 OU または専用アカウントに隔離します。このアカウントレベルの論理的な分離は、意図しないスコープの拡大を防ぎ、セキュリティインシデント発生時の影響を最小限に抑えるのに役立ちます。 - ② ネットワーク層
セキュリティグループが中核的なセグメンテーション境界となります。これはインスタンスに直接アタッチされるステートフルな仮想ファイアウォールとして機能し、「暗黙の拒否」の原則で通信を制御します。これにより、従来のオンプレミス環境よりもリソースに近い位置で、きめ細かなアクセス制御が可能です。 - ③ アプリケーション層
Lambda や S3 等の抽象化されたサービスでは、API を介した通信が主となります 。ここでは IAM ポリシーが論理的なセグメンテーション境界として機能し、「誰が」「どのリソースに」「何をできるか」が厳密に制御されます 。また、Amazon API Gateway を CDE への「玄関口」として設置し、接続を仲介させることでセグメンテーション境界として活用することも有効です。 - ④ データ層
AWS Certificate Manager (ACM) や AWS Key Management Service (KMS) 等の暗号化サービスを用い、「保管中（at-rest）」および「転送中（in-transit）」のデータを保護します。この層は、他の層の制御を突破された場合でもデータそのものの機密性を保護する最後の砦であり、他のセグメンテーションと組み合わせることで、包括的なデータ保護戦略を実現します。
つまり、CDE (カード会員データ環境) を「アカウント」層のセグメンテーションで適切に分離し、それらの AWS アカウントを特定の OU 内に集約することがベストプラクティスとなります。
PCI DSS のための推奨 OU の構成図
ここまで解説した通り、PCI DSS の審査範囲 (スコープ) を AWS アカウントレベルで分離し、適切に OU へと集約することでスコープを狭めることができます。
これを OU 構成で具体的に実装すると、以下の通りになります*2。
「Workloads OU」は、組織におけるビジネス固有のワークロードを収める OU ですが、ここに「①PCI OU (In Scope)」と「②Non-PCI OU (Out-of-Scope)」を用意します。
そして、CDE (Cardholder Data Environment) に該当するものは「PCI OU」へ配置します。反対に、CDE に該当しないもの（カード情報に触れず、接続しないもの）は「Non-PCI OU」へ配置します。
基礎的な OU である「Foundational OU」とその配下の「Security OU」と「Infrastructure OU」を鑑みて、OU の組織での全体像を示すと上図の通りです。ここは一般的な AWS Organizations の 推奨 OU 構成と変わりありません。
本 OU 構成により、以下の3つのカテゴリを適切に分離・配置することが可能となります。
- CDEシステムのアカウント (PCI OU):
カード会員データを直接扱うリソース群 - スコープ外システムのアカウント (Non-PCI OU):
CDEに接続せず、セキュリティに影響を与えないリソース群 - 接続やセキュリティに関連するシステムのアカウント (Security OU, Infrastructure OU):
CDEを支援するログ管理、監視、ID管理などの共有サービス群
まとめ
本ブログは、2024年11月に投稿された AWS 公式ブログを元に、本文で紹介されているアップデートされたホワイトペーパー 「Architecting for PCI DSS Segmentation and Scoping on AWS」を情報源として「PCI DSS のための推奨 OU 構成」について解説しました。
AWS においてもセキュリティの原則である「多層防御」の考え方が重要です。これは PCI DSS に準拠するためにも変わらない原則です。
また、AWS において多層防御を構成する最も重要なファクターが「マルチアカウント戦略」であり「AWS アカウントの適切な分離」という根拠も「AWS Well-Architected Framework」の「セキュリティの柱」を用いてご説明しました。
最後に、CDE (カード会員データ環境) を「アカウント」層のセグメンテーションで適切に分離し、それらの AWS アカウントを特定の OU 内に集約することがベストプラクティスであるとし、ワークロード OU 配下で「①PCI OU (In Scope)」と「②Non-PCI OU (Out-of-Scope)」を用いて分離するという、具体的な推奨 OU 構成を構成図としてまとめました。
本ブログが PCI DSS 対応のための何らかのヒントやきっかけになれば幸いです。
関連する余談
社内のメンバーと会話して、以下の内容も気になる点となりました。
- 1つのログアーカイブ（保管）アカウントに、①PCI OU と②Non-PCI OU のログをまとめて出力する場合はそれらが混在するリスクを避ける必要があります
- アカウント分離は強力なセグメンテーションコントロールですが、「Non-PCI OU」が CDE に影響を与えないことを継続的に証明する責任は残ります
- このため、そもそも AWS Organizations ごと PCI DSS 用途の組織を払い出したほうが「完全な分離」になるのではないだろうか
というような会話もありました
関連事例ページ
PCI DSS に関連した弊社の事例を紹介します。
では、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
