PCI DSS 4.0.1 の AKS 規制クラスターの概要

このシリーズで提供されるガイダンスには、すべての設計の選択肢に適切に設計された原則が組み込まれています。この記事では、それらの選択をまとめています。

この記事で、このシリーズは終了します。概要を参照してください。

リファレンス実装が近日公開予定: PCI DSS 4.0.1 の規制対象ワークロードリファレンス実装用の Azure Kubernetes Service (AKS) ベースラインクラスターは現在更新中であり、近日中に利用可能になります。この実装では、CDE 内のさまざまなネットワークおよびセキュリティ制御の使用を示す規制されたインフラストラクチャを示します。これには、Azure のネイティブなネットワーク制御と、Kubernetes のにネイティブな制御の両方が含まれます。また、環境とサンプルワークロードの間の相互作用を示すアプリケーションも含まれます。この記事ではインフラストラクチャに主眼を置いています。このサンプルは、実際の PCI-DSS 4.0.1 ワークロードを示すものではありません。

Well-Architected フレームワーク

Microsoft Azure Well-Architected Framework は、アーキテクチャの卓越性の品質の柱を通じてソリューションを評価するために使用できる一連の基本原則です。

確実
セキュリティ
コストの最適化
オペレーショナルエクセレンス
パフォーマンス効率

PCI DSS 4.0.1 ワークロードでは、適切に設計されたソリューションであることの厳しさが求められています。インフラストラクチャを PCI 要件に合わせることは重要ですが、コンプライアンスはインフラストラクチャのホストに留まりません。品質の重要な要素、特にセキュリティに対処しないと、コンプライアンスを損なう可能性があります。 Well-Architected ソリューションでは、インフラストラクチャとワークロードの両方の観点を組み合わせることで、結果の準拠を実現するために必要な厳格さを満たすことができます。 PCI DSS 4.0.1 では、継続的なコンプライアンス、リスクベースのスコープ、強化された監視、セキュリティで保護されたソフトウェア開発に関する新しい要件が導入されています。これらはすべてこのガイダンスで説明されています。

クラウドおよびコンテナー環境に関連する PCI DSS 4.0.1 の主な機能強化は次のとおりです。

カスタマイズされたアプローチ: クラウドネイティブアーキテクチャに適した代替コントロールを通じて、セキュリティ目標を満たす柔軟性。
拡張認証: カード所有者データ環境へのすべてのアクセスに対する多要素認証要件が強化されました。
継続的な検証: ポイントインタイム評価ではなく、セキュリティコントロールの継続的な監視と検証。
自動化されたセキュリティ: 脆弱性スキャンとセキュリティテストを自動化した DevSecOps パイプラインへのセキュリティの統合。
コンテナーのセキュリティ: コンテナー化されたワークロードと一時的なインフラストラクチャに関する具体的なガイダンス。
ゼロトラスト原則: 検証優先のアプローチと最小限の特権アクセスに重点を置く。

信頼性

規制対象環境の信頼性は、監査目的で一貫して説明できるように、予測可能である必要があります。信頼性の原則に記載されている基本ガイダンスに従ってください。次のセクションでは、規制対象環境の信頼性に関するベストプラクティスをまとめます。

回復ターゲットとディザスターリカバリー

規制対象ワークロードで処理されるデータの機密性のため、回復ターゲットと回復ポイントの目標 (RPO) を定義することが重要です。 CHD の許容される損失は何ですか? CDE 内の回復作業は、引き続き標準要件の対象となります。障害を予測し、ロール、責任、および正当なデータアクセスに適合するそれらの障害の明確な回復計画を策定します。ライブサイトの問題は、規制から逸脱した理由ではありません。これは、完全なディザスターリカバリーの状況で特に重要です。要件に準拠し、予期しない CDE または CHD アクセスを最小限に抑える明確なディザスターリカバリードキュメントを用意します。回復後に、常に回復プロセス手順を確認して、予期しないアクセスが発生していないことを確認します。それらのインスタンスの業務上の正当な理由をドキュメント化します。

復元

回復力と回復戦略をアーキテクチャに追加すると、CDE へのアドホックアクセスの必要性を回避できます。システムは、人による直接の介入を必要とせずに、定義された RPO で自己回復できる必要があります。このように、緊急アクセスが認可されている個人に対しても、CHD の不要な公開を排除できます。回復プロセスは監査可能である必要があります。

セキュリティリスクは、ワークロードのダウンタイムとデータ損失の原因になる可能性があるため、それらを確認します。セキュリティへの投資は、ワークロードの信頼性にも影響します。

運用プロセス

信頼性は、CDE 内および CDE に隣接するすべての運用プロセスにまで及びます。イメージの構築やジャンプボックス管理などの注意事項の、適切に定義され、自動化された、テスト済みのプロセスを Well-Architected ソリューションに組み込みます。

セキュリティ

「セキュリティ設計原則」に記載されている基本的なガイダンスに従います。次のセクションでは、規制対象環境のセキュリティに関するベストプラクティスの概要を示します。

ガバナンス

ガバナンスの実装は、PCI DSS 4.0.1 のコンプライアンス要件に基づきます。これは、セグメント化の管理、リソースへのアクセス、脆弱性の検出、さらに最も重要である顧客データの保護の技術的な制御に影響します。 PCI DSS 4.0.1 は、クラウド環境とコンテナー環境でのインベントリと構成管理のための責任の共有、継続的な監視、自動化されたツールの使用を強調しています。

継続的なコンプライアンス監視: 以前のバージョンの定期的な評価アプローチとは異なり、PCI DSS 4.0.1 では、セキュリティコントロールの継続的な検証が必要です。これは、Azure Monitor、Microsoft Defender for Cloud、Azure Policy による自動ポリシー適用などのクラウドネイティブの監視機能に適しています。

リスクベースのスコープ: この標準では、実際のデータフローとリスク評価に基づくより動的なスコープが可能になりました。これは、コンポーネントが一時的で動的に調整される可能性があるコンテナー化されたワークロードに特に関連します。

企業のセグメント化戦略

完全な分離を維持するには、スタンドアロンサブスクリプションで規制対象インフラストラクチャをデプロイすることが推奨されます。コンプライアンスに必要なサブスクリプションが複数ある場合は、スコープ内のサブスクリプション全体に関連する Azure ポリシーを均一に適用する管理グループ階層でグループ化することを検討してください。サブスクリプション内で、関連 Azure ポリシーをサブスクリプションレベルで適用して、カード会員データ環境 (CDE) 内のすべてのクラスターに適用する必要がある広範なポリシーをキャプチャします。関連 Azure ポリシーをリソースグループレベルで適用し、特定のクラスターインスタンスに適用するポリシーをキャプチャします。これらのポリシーにより、ランディングゾーンの中核となるガードレールを構築します。

運用と接続に関して、PCI ワークロード (対象) を他の (対象外) ワークロードから分離します。分離を作成するには、個別のクラスターをデプロイするか、セグメント化戦略を使用して分離を維持します。たとえば、クラスターで個別のノードプールを使用して、ワークロードがノード仮想マシン (VM) を共有しないようにします。

ポリシーの適用

Azure ポリシーを有効にして、セキュリティ制御を適用します。たとえば、この規制対象アーキテクチャでは、カード会員データ環境の構成の誤りを防ぐことができます。 VM ノードへのパブリック IP の割り当てを許可しない Azure ポリシーを適用できます。このような割り当ては検出され、報告されるかブロックされます。

AKS に対して有効にできるポリシーの詳細については、 Azure Kubernetes Service (AKS) の Azure Policy 組み込み定義に関するページを参照してください。

Azure には、ほとんどのサービスに対応するいくつかの組み込みのポリシーが用意されています。 Azure Policy の組み込みポリシー定義を確認し、必要に応じて適用します。

コンプライアンスの監視

コンプライアンスは体系的に監視し、維持する必要があります。標準のコンプライアンス構成証明が実行されます。クラウドリソースが準拠しているかどうかを把握することは、構成証明と監査の準備に役立ちます。

Microsoft Defender for Cloud の法令遵守ダッシュボードを活用してください。ダッシュボードを継続的に監視することにより、ワークロードのコンプライアンスの状態を追跡できます。

Azure portal のコンプライアンス監視ダッシュボードの例のスクリーンショット。

ネットワークのセキュリティ

ハブスポークトポロジでは、エンティティごとに個別の仮想ネットワークを使用することで、ネットワークフットプリントに基本的なセグメント化を提供します。各ネットワークはさらにサブネットにセグメント化されます。

AKS クラスターは、CDE の中核を形成します。パブリック IP アドレスからアクセスできず、接続をセキュリティで保護する必要があります。 CDE を出入りする一般的なフローは、次のように分類できます。

クラスターへの受信トラフィック。
クラスターからの送信トラフィック。
ポッド間のクラスター内トラフィック。

規制対象環境の要件を満たすために、クラスターはプライベートクラスターとしてデプロイされます。このモードでは、パブリックインターネットとの間のトラフィックが制限されます。 AKS によって管理される Kubernetes API サーバーとの通信もプライベートです。セキュリティは、厳密なネットワーク制御と IP ファイアウォール規則によってさらに強化されています。

ネットワーク内のリソース間のセキュリティで保護された通信に役立つネットワークセキュリティグループ (NSG)。
クラウドリソース、インターネット、およびオンプレミス間のすべての送信トラフィックをフィルター処理する Azure Firewall。
Azure Application Gateway がインターセプトするインターネットからのすべての受信トラフィックをフィルター処理するための、Azure Web Application Framework に統合された Azure Application Gateway。
Kubernetes NetworkPolicy 、クラスター内のポッド間の特定のパスのみを許可します。
Azure Private Link を使用して、運用タスクのために、Azure Key Vault や Azure Container Registry などの他のサービスとしての Azure プラットフォーム (PaaS) サービスに接続します。

トラフィックが予期したとおりにフローし、すべての異常が検出され、報告されることを確認するための監視プロセスが用意されています。

ネットワークセキュリティの詳細については、「ネットワークのセグメント化」を参照してください。

データのセキュリティ

PCI DSS 4.0.1 では、転送中でもストレージ内であっても、すべてのカード所有者データ (CHD) が明確でないことを要求します。

このアーキテクチャと実装は、ワークロードではなくインフラストラクチャに重点を置いているため、データ管理は示されていません。次のセクションでは、適切に設計された推奨事項について説明します。

静止データ

データは、業界標準の暗号化アルゴリズムを使用して暗号化する必要があります。

カード会員環境にデータを保存しないでください。
ストレージレイヤーの外部で暗号化します。
暗号化されたデータのみをストレージメディアに書き込みます。
キーをストレージレイヤーに保存しないでください。

Azure Storage 内のすべてのデータは、強力な暗号を使用して暗号化および復号化します。自己管理型暗号化キーが推奨されています。

データを一時的に保存する必要がある場合は、そのデータに同じ考慮事項を適用します。 AKS のホスト暗号化機能を有効にすることが強く推奨されます。組み込みの Azure ポリシーを使用して、一時データの暗号化を適用できます。

ストレージテクノロジを選択する場合は、保持機能を確認してください。構成された時間が経過したら、すべてのデータが安全に削除されることを確認します。

標準では、機密認証データ (SAD) が格納されていないことも必要です。ログ、ファイル名、キャッシュ、およびその他のデータでデータが公開されていないことを確認します。

転送中のデータ

CDE とやりとりするエンティティとのすべての通信が、暗号化されたチャネルを経由する必要があります。 PCI DSS 4.0.1 は、更新された暗号スイートとプロトコル標準を使用して暗号化要件を強化します。

HTTPS トラフィックのみが CDE へのフローが許可される必要があります。このアーキテクチャでは、Azure Application Gateway で、ポート 80 経由のすべてのトラフィックが拒否されます。
可能であれば、CDE の外部でデータを暗号化および復号化しないでください。そうする場合は、そのエンティティを CDE の一部にすることを検討してください。
CDE 内では、mTLS によって、ポッド間のセキュリティで保護された通信を提供します。この目的のためにサービスメッシュを実装することを選択できます。
安全な暗号と TLS 1.2 以降のみを許可します。 PCI DSS 4.0.1 では、受け入れ可能な暗号化プロトコルと暗号スイートに関する更新されたガイダンスが提供されます。
PCI DSS 4.0.1 では、自動化されたキーローテーションやハードウェアセキュリティモジュール (HSM) 統合 (該当する場合) など、より厳密なキーライフサイクル管理が必要です。

アイデンティティ

アクセスポリシーを設計するときは、次のセキュリティ原則に従ってください。

ゼロトラストポリシーから始めます。必要に応じて、例外を認めます。
最小限の特権を付与します。タスクを完了するのに十分です。
永続的なアクセスを最小限にします。

PCI DSS 4.0.1 は認証要件を大幅に強化し、管理アクセスやコンソール以外のすべてのアクセスを含むカード所有者データ環境へのすべてのアクセスに対する多要素認証 (MFA) を管理します。

Kubernetes ロールベースのアクセス制御 (RBAC) によって、Kubernetes API へのアクセス許可を管理します。 AKS では、それらの Kubernetes ロールがサポートされています。 AKS は Microsoft Entra ID と完全に統合されています。ロールに Microsoft Entra ID を割り当てることができ、その他の機能を利用することもできます。

ゼロトラストアクセス

既定で、Kubernetes RBAC、Azure RBAC、および Azure サービスでは、すべて拒否が実装されます。この設定を慎重にオーバーライドして、アクセスを必要とするエンティティのみにアクセスを許可します。ゼロトラストを実装するためのもう 1 つの領域は、クラスターノードへの SSH アクセスを無効にすることです。

最小限の特権

Azure のリソースとポッドにマネージド ID を使用し、それらを予想されるタスクにスコープ設定できます。たとえば、Azure Application Gateway には、Azure Key Vault からシークレット (TLS 証明書) を取得するためのアクセス許可が必要です。シークレットを変更するためのアクセス許可を付与してはなりません。

永続的なアクセスの最小化

Just-In-Time Microsoft Entra グループメンバーシップを使用して、永続的なアクセスを最小限に抑えます。 Microsoft Entra ID の条件付きアクセスポリシーによって制御を強化します。このオプションでは、多要素認証、Microsoft Entra テナントによって管理されるデバイスに対する認証の制限、通常とは異なるサインイン試行のブロックなどの多くのユースケースがサポートされています。

機密管理

シークレット、証明書、キー、およびパスワードは、CDE の外部に保存します。ネイティブ Kubernetes シークレットオブジェクトまたは Azure Key Vault などのマネージドキーストアを使用できます。マネージドストアを使用すると、キーのローテーションや証明書の更新などのシークレット管理タスクに役立ちます。

キーストアへのアクセスには、ネットワーク制御とアクセス制御が組み合わされていることを確認します。マネージド ID を有効にする場合、クラスターが Key Vault に対して自身を認証し、アクセスできるようにする必要があります。さらに、キーストアへの接続が、パブリックインターネットを経由しないようにする必要があります。プライベートリンクなどのプライベートネットワークを使用します。

コストの最適化

コストの最適化の原則に関するページに記載されている基本ガイダンスに従います。

コンプライアンス要件と厳密なセキュリティ制御のため、明確なトレードオフはコストです。料金計算ツールを使用して初期見積もりを確立することをお勧めします。

次の図は、このアーキテクチャで使用される主なリソースのコストへの影響の概要を示しています。

アーキテクチャのコスト管理の図。

主な推進要因は、ノードプールと Azure Firewall を構成する仮想マシンスケールセットです。もう 1 つの要因は Log Analytics です。また、選択したプランに応じて、Microsoft Defender for Cloud に関連する増分コストもあります。

サービスの価格を構成するものを明確に理解します。 Azure では従量制課金使用量が追跡されます。次の図は、このアーキテクチャの Azure Firewall の内訳を示しています。

Azure Firewall の例のコスト管理を示す図。

Azure Firewall などの一部のリソースに関連するコストは、複数のビジネスユニットまたはアプリケーションに分散される可能性があります。コストを最適化するもう 1 つの方法は、組織内でマルチテナントクラスターをホストし、ワークロードの多様性によって密度を最大化することです。ただし、規制されたワークロードにはこのアプローチは 推奨されません。コスト上の利点よりもコンプライアンスとセグメント化を常に優先します。

予算の制約内で維持するために、コストを制御するいくつかの方法は、Azure Application Gateway インフラストラクチャを調整し、自動スケーリングのインスタンス数を設定し、PCI DSS 4.0.1 で必要な監査証跡を満たしている限りログ出力を減らすことです。常にそれらの選択肢を、SLA を満たすことができる設計の他の側面のトレードオフに対して評価します。たとえば、トラフィックの急増に合わせて適切にスケーリングできますか?

Azure リソースのグループを作成する際は、コストを追跡できるようにタグを適用します。コストの追跡と分析には、 Azure Advisor や Microsoft Cost Management などのコスト管理ツールを使用します。

Kubernetes 固有のコンストラクトによる詳細なクラスターインフラストラクチャコストの割り当てに対して、AKS コスト分析を有効にすることを検討してください。

オペレーショナルエクセレンス

オペレーショナルエクセレンスの原則に記載されている基本的なガイダンスに従ってください。次のセクションでは、規制対象環境のオペレーショナルエクセレンスのベストプラクティスをまとめます。

役割の分離

規制対象環境には明確な義務の分離を適用することが重要です。ワークロードのニーズと CDE との対話に基づいて、ロールと責任を定義します。たとえば、クラスターおよび依存サービスに関連する操作には、インフラストラクチャオペレーターまたはサイト信頼性エンジニア (SRE) のロールが必要になる可能性があります。このロールは、セキュリティ、分離、デプロイ、および可観測性の維持を担当します。それらの定義を形式化し、それらのロールに必要なアクセス許可を決定します。たとえば、SRE はクラスターアクセスに対して高度な特権を持ちますが、ワークロード名前空間への読み取りアクセス権が必要です。

ワークロードの分離

PCI DSS 4.0.1 では、操作の観点から PCI ワークロードを他のワークロードから分離する必要があります。この実装では、対象ワークロードと対象外ワークロードを、2 つの個別のユーザーノードプールにセグメント化します。対象ワークロードのアプリケーション開発者と、対象外ワークロードの開発者は、異なるアクセス許可のセットを持つことがあります。また、個別の品質ゲートがあります。たとえば、対象コードではコンプライアンスと構成証明を守る必要がありますが、対象外のコードでは必要ありません。また、個別のビルドパイプラインとリリース管理プロセスを使用する必要もあります。

PCI DSS 4.0.1 では、次のようなセキュリティで保護されたソフトウェア開発のための包括的な要件が導入されています。

CI/CD パイプラインに統合された自動セキュリティテスト。
静的および動的なアプリケーションセキュリティテスト (SAST/DAST)。
デプロイ前のコンテナーイメージの脆弱性スキャン。
サードパーティ製コンポーネントの依存関係スキャン。
セキュリティに重点を置いたコードレビュープロセス。
開発チーム向けの安全なコーディングトレーニング。

運用メタデータ

PCI DSS 4.0.1 標準の要件 12 では、ワークロードインベントリと担当者アクセスドキュメントに関する情報を保持する必要があります。環境情報を Azure リソース、リソースグループ、およびサブスクリプションと照合できるため、Azure タグを使用することが強く推奨されます。

インフラストラクチャとワークロードの一部である承認済みソリューションに関する情報を保持します。これには、CDE に取り込む選択した VM イメージ、データベース、およびサードパーティソリューションの一覧が含まれます。サービスカタログを構築して、そのプロセスを自動化することもできます。それにより、特定の構成でそれらの承認済みソリューションを使用して、実行中のプラットフォーム運用に準拠するセルフサービスデプロイを実現します。

可観測性

要件 10 を満たすために、CDE への可観測性はコンプライアンスに不可欠です。アクティビティログは、アカウントとシークレットの管理に関連する操作に関する情報 (診断設定の管理、サーバー管理、その他のリソースアクセス操作) を提供します。すべてのログには、日付、時刻、ID、その他の詳細情報が記録されます。 Azure Monitor Logs でデータの保持ポリシーとアーカイブポリシーを構成して、ログを最大 1 年間保持します。

ログには、それらを必要とするロールだけがアクセスすることを確認します。 Log Analytics と Microsoft Sentinel では、監査証跡アクセスを管理するためのさまざまなロールベースのアクセス制御がサポートされています。

応答と修復

Azure 監視サービスの Azure Monitor と Microsoft Defender for Cloud では、異常なアクティビティを検出したときに通知またはアラートを生成できます。これらのアラートには、重大度、状態、アクティビティの時刻などのコンテキスト情報が含まれます。アラートが生成されたら、修復戦略を設定し、進行状況を確認します。データを統合することで、豊富なアラートコンテキストを提供できるため、セキュリティ情報とイベント管理 (SIEM) ソリューションにデータを一元化することが推奨されます。

Microsoft Defender for Cloud の [セキュリティアラート] ビューから、Microsoft Defender for Cloud がリソースで検出したすべてのアラートにアクセスできます。問題に対処するトリアージプロセスを設定します。セキュリティチームと協力して、ワークロード所有者が関連アラートを利用できるようにする方法を理解します。

パフォーマンス効率

パフォーマンス効率の原則に記載されている基本的なガイダンスに従ってください。次のセクションでは、規制対象環境のパフォーマンス効率のベストプラクティスをまとめます。

Scaling

変化する要求に合わせて環境がどのように調整されるかを観察すると、負荷の高い環境で予想される実行時動作が示されます。ワークロード内のリソースの自動スケールによって、CDE での人による操作が最小限に抑えられます。追加されたセキュリティ上の利点によって、常に攻撃面が減少します。 scale-to-zero (0 へのスケーリング) アプローチをサポートするリソースを利用することで、利点を最大化できます。たとえば、AKS では、ユーザーノードプールの 0 へのスケールダウンをサポートしています。詳細については、「User ノードプールを 0 にスケーリングする」を参照してください。

パーティショニング

パーティション分割は、規制対象ワークロードのパフォーマンス効率の重要な要素です。個別のコンポーネントを使用することで、責任を明確に定義することができ、ネットワークポリシーなどの正確な制御に役立ちます。セグメント化戦略と同様に、パーティション分割によってコンポーネントを分離し、予期しない障害やシステム侵害の爆発半径の影響を制御します。

シェアードナッシングアーキテクチャ

シェアードナッシングアーキテクチャは、併置されたワークロード間の競合を除去するように設計されます。また、これは単一障害点を除去するための戦略でもあります。規制対象環境では、論理または物理境界によってコンポーネントを分離する必要があります。これを、シェアードナッシングアーキテクチャに合わせて調整することで、スケーラビリティに利益をもたらします。これにより、関連するセキュリティ制御と、さまざまなコンポーネントのより厳密な監査機能をターゲットにできます。

軽量なワークロード

ワークロードの複雑さによって、ドキュメント化と監査が困難になります。パフォーマンス上の利点と、規制要件の監査の容易さのために、簡素化を追求してください。必要以上に広範囲にわたる選択肢については、攻撃対象領域が拡大し、誤用や誤った構成の可能性が増すため、再検討してください。

すべてをまとめる

Azure Kubernetes Service に PCI DSS 4.0.1 コンプライアンスを実装するには、標準の特定の要件を満たしながら、適切に設計されたフレームワークのすべての側面に対応する包括的なアプローチが必要です。このシリーズでは、ネットワークセキュリティとデータ保護から ID 管理と継続的監視まで、複数のドメインにわたって詳細なガイダンスが提供されています。

重要なポイント

AKS での PCI DSS 4.0.1 コンプライアンスへの移行には、いくつかの重要な考慮事項が含まれます。

基盤としてのインフラストラクチャ: セキュリティで保護された準拠した AKS インフラストラクチャは不可欠ですが、十分ではありません。このアーキテクチャでは、標準で必要とされるセキュリティ制御、監視機能、運用プロセスをサポートする必要があります。
継続的コンプライアンス: PCI DSS 4.0.1 は、以前のバージョンとは異なり、ポイントインタイム評価ではなく、継続的な検証と監視を重視しています。これには、自動化されたツール、リアルタイムアラート、プロアクティブなセキュリティ対策が必要です。
共同責任: Azure はセキュリティで保護されたプラットフォームを提供しますが、組織はセキュリティ制御の適切な構成と維持、適切なアクセスポリシーの実装、継続的なコンプライアンスの確保に責任を持ちます。
適切に設計された原則: 持続可能で準拠したソリューションを作成するには、セキュリティ、信頼性、コストの最適化、オペレーショナルエクセレンス、パフォーマンス効率をすべて考慮する必要があります。

統合ポイント

このシリーズ全体で説明されているさまざまなコンポーネントが連携して、包括的なコンプライアンスフレームワークを作成します。

ネットワークセキュリティ は、カード所有者データ環境を分離するための基盤を提供します。
データ保護 により、CHD はライフサイクル全体を通じて適切に暗号化され、管理されます。
暗号化とキー管理 により、機密データの安全な保存と転送が可能になります。
アイデンティティとアクセス管理 により強化された MFA コントロールが CDE へのアクセス権を持つ人を制限します。
マルウェア保護 は、環境を侵害する可能性のある脅威から保護します。
監視とログ記録 により、CDE 内のすべてのアクティビティが可視化されます。
継続的なセキュリティ監視 により、リアルタイムの脅威検出と対応が可能になります。
セキュリティポリシーは、 継続的なコンプライアンスのためのガバナンスフレームワークを確立します。

次のステップ

AKS での PCI DSS 4.0.1 コンプライアンスの実装を開始するには、次の推奨手順に従います。

フェーズ 1: 基礎と計画 (週 1 から 4)

現在の状態を評価する: PCI DSS 4.0.1 要件に対して既存の AKS インフラストラクチャを評価します。
スコープの定義: PCI DSS コンプライアンスのスコープ内にあるコンポーネントを明確に識別します。
実装ガイドを確認する: このシリーズの各記事で提供されている詳細なガイダンスを調べます。
アーキテクチャを計画する: ハブスポークネットワークトポロジとセキュリティ制御を設計します。
ガバナンスの確立: ロール、責任、承認プロセスを定義します。

フェーズ 2: インフラストラクチャの実装 (週 5 から 12)

参照アーキテクチャのデプロイ: AKS ベースラインアーキテクチャから開始し、PCI DSS の機能強化を適用します。
ネットワークセキュリティを実装する: プライベートクラスター、ファイアウォール、およびネットワークポリシーを構成します。
ID 管理を設定する: Azure AD の統合と MFA の要件を構成します。
監視インフラストラクチャのデプロイ: Azure Monitor、Log Analytics、Microsoft Defender for Cloud を設定します。
データ保護を実装する: 保存時と転送中の暗号化を構成します。

フェーズ 3: セキュリティとコンプライアンス (週 13 から 20)

セキュリティポリシーの構成: コンプライアンスのために Azure Policy と Kubernetes ポリシーを適用します。
キー管理を実装する: Azure Key Vault と暗号化コントロールを設定します。
マルウェア対策の展開: セキュリティスキャンと脅威検出を構成します。
監視を確立する: 継続的なセキュリティ監視とアラートを実装します。
セキュリティ制御のテスト: すべてのセキュリティ対策が正しく機能していることを検証します。

フェーズ 4: 検証とメンテナンス (週 21~ 24)

セキュリティテストの実施: 侵入テストと脆弱性評価を実行します。
コンプライアンスを検証する: PCI DSS 4.0.1 のすべての要件が満たされていることを確認します。
すべてを文書化する: 監査目的で包括的なドキュメントを作成します。
スタッフをトレーニングする: すべての担当者が自分の役割と責任を理解していることを確認します。
継続的なプロセスの確立: 継続的な監視とメンテナンスの手順を実装します。

進行中の操作

最初の実装後は、次の方法でコンプライアンスを維持します。

定期的なセキュリティ評価: 四半期ごとのセキュリティレビューと年間コンプライアンス評価を実施します。
継続的な監視: すべてのセキュリティ制御を監視し、アラートに迅速に対応します。
更新管理: すべてのシステムとセキュリティコントロールを最新の状態に保ちます。
インシデント対応: インシデント対応手順を維持およびテストします。
ドキュメントのメンテナンス: すべてのドキュメントを最新の状態に保ち、アクセスできるようにします。

ヘルプを取得する

AKS での PCI DSS 4.0.1 コンプライアンスの実装に関する追加サポート:

Microsoft FastTrack: 実装ガイダンスについては、Microsoft FastTrack for Azure と連携します。
Microsoft パートナー: コンプライアンスを専門とする認定 Microsoft パートナーと連携します。
プロフェッショナルサービス: 複雑な実装にプロフェッショナルサービスを関与することを検討してください。
コミュニティリソース: ベストプラクティスのために Azure と Kubernetes コミュニティを活用します。

フィードバック

このページはお役に立ちましたか?

最終更新: 2025-08-07