PCI-DSS 3.2.1 の AKS 規制クラスターのネットワークを構成する (パート 3/9)

この記事では、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) に準拠して構成された Azure Kubernetes Service (AKS) クラスターのネットワークに関する考慮事項について説明します。

この記事はシリーズの一部です。 概要を参照してください。

PCI-DSS 3.2.1 標準の主なテーマはセキュリティです。 ハブスポーク トポロジは、規制されたネットワーク環境を設定するための自然な選択肢です。 セキュリティで保護された通信を可能にするインフラストラクチャを簡単に作成できます。 ネットワーク制御が両方のハブスポーク ネットワークに配置され、Microsoft ゼロ トラスト モデルに従います。 知る必要性に基づいてアクセス権を付与すると、この制御を最小限の特権で調整してトラフィックをセキュリティで保護できます。 さらに、各ネットワーク ホップとレイヤーに制御を追加することで、複数の多層防御アプローチを適用できます。

Kubernetes でワークロードをホストする場合、ファイアウォール規則などの従来のネットワーク構成要素に依存するだけでは十分ではありません。 クラスター内のトラフィックのフローを制御する、 NetworkPolicy リソースなどの Kubernetes ネイティブのコンストラクトもあります。 Kubernetes のドキュメントを参照して、分離されたポッドに関する主要な概念と、イングレスおよびエグレスのポリシーについて理解することを強くお勧めします。

セキュリティで保護されたネットワークとシステムを構築して維持する

要件1 - カード会員データを保護するためのファイアウォール構成をインストールして維持する

AKS 機能のサポート

AKS では、プライベート仮想ネットワーク内のクラスターをプライベート クラスターとしてデプロイすることがサポートされています。 クラスターと AKS マネージド Kubernetes API サーバーの間の通信は、信頼されたネットワークを経由します。 プライベート クラスターによって、Azure Virtual Network、ネットワーク セキュリティ グループ (NSG)、およびその他の組み込みのネットワーク制御を使用して、カード所有者データ環境 (CDE) 全体をセキュリティで保護することができます。 この構成により、インターネットと環境間の不正なパブリック アクセスが禁止されます。 このようなクラスターをプロビジョニングする方法の詳細については、「プライベート Azure Kubernetes Service クラスターを作成する」を参照してください。

Azure Firewall は AKS と統合でき、CDE の重要なコンポーネントであるクラスターからの送信トラフィックを制限できます。 AKS FQDN タグを使用すると、構成を簡単に行うことができます。 推奨されるプロセスについては、「Azure Firewall を使用して Azure Kubernetes Service (AKS) のデプロイを保護する」に記載されています。

AKS クラスターには、一部のパブリック インターネット アクセスが必要です。 インターネットへの送信トラフィックを制限するには、クラスター サブネットの Azure Firewall と NSG を使用します。 詳細については、「Azure Kubernetes Service (AKS) でクラスター ノードに対するエグレス トラフィックを制御する」を参照してください。

AKS では、必要に応じて HTTP プロキシを定義する機能がサポートされています。これは、クラスターに対する追加の送信トラフィックコントロールと監視に利用できます。 クラスター ノードは、指定された HTTP プロキシ構成を送信トラフィックのルーティングに使用します。 また、作成時にポッドにプロキシ情報を挿入する MutatingWebhook が登録されるので、ワークロードが同じプロキシ情報を継承することを推奨します。 ポッドはプロキシ情報をオーバーライドできるため、Azure Firewallに加えて、HTTP プロキシの使用を推奨します。

AKS クラスターは NetworkPolicy プラグインを使用して作成する必要があります。 AKS では、 ネットワーク ポリシー プラグインには Calico、Azure Network Policy Management、Cilium など、いくつかのオプションがあります。 Calico ネットワーク ポリシーでは、Kubenet または Azure CNI のいずれかを使用できます。 Azure ネットワーク ポリシー管理では、Azure CNI (Kubenet ではない) のみを使用できます。 Azure と Calico のネットワーク ポリシー プラグインは、いずれもオープン ソースです。 Project Calico の詳細については、 包括的な PCI ソリューションのホワイトペーパーを参照してください。これは、次に示すファイアウォール要件の多くに対応しています。

お客様の責任

要件	担当
要件 1.1	ファイアウォールおよびルーター構成標準を規定し実装します。
要件 1.2	カード所有者のデータ環境のシステム コンポーネントと、信頼されていないネットワークとの間の接続を制限するファイアウォールとルーターの構成を構築します。
要件 1.3	インターネットとカード所有者データ環境にあるシステム コンポーネントの間の直接のパブリック アクセスを禁止します。
要件 1.4	ネットワーク外でインターネットに接続する (会社または従業員個人所有の) 携帯コンピューティング デバイス (従業員が使用するノート PC など) に個人用ファイアウォール ソフトウェアまたは同等の機能をインストールします。これは、CDE にアクセスする場合にも使用するものです。
要件 1.5	セキュリティ ポリシーとファイアウォールを管理するための運用手順が文書化され、使用され、すべての関係者に通知されていることを確認します。

要件 1.1

以下を含む、ファイアウォールおよびルーターの構成標準を規定し実装します。

要件 1.1.1

すべてのネットワーク接続およびファイアウォールやルーターの構成への変更を承認およびテストするための正式なプロセス。

お客様の責任

Azure portal または Azure CLI を直接使用するなどして、構成を手動で実装しないでください。 コードとしてのインフラストラクチャ (IaC) を使用することをお勧めします。 IaC では、インフラストラクチャはバージョン管理システムを使用する記述型モデルによって管理されます。 IaC モデルが適用されるたびに同じ環境が生成されます。 IaC の一般的な例としては、Bicep、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform などがあります。 IaC を選択できない場合、ファイアウォール規則の変更を追跡、実装、および安全にデプロイするための明確に文書化された手順を作成してください。 詳細については、 要件 11.2の一部として記載します。

Azure Firewall、ネットワーク セキュリティ グループ (NSG)、Kubernetes の NetworkPolicy リソースなど、さまざまなネットワーク制御を組み合わせて使用する必要があります。

ネットワーク制御へのアクセスと変更が可能なユーザー数を最小限に抑えてください。 チームのロールと明確な責任を定義します。 たとえば、組織のネットワーク チームが、IT チームによって設定されたガバナンス ポリシーに従って変更を検証するようにします。 あらゆるネットワーク構成の変更を承認するためのゲート承認プロセスを作成し、これには複数の人とプロセスが関与するようにします。 このプロセスには、すべてのネットワーク制御をテストするための手順が含まれている必要があります。 このプロセスについて説明する詳細なドキュメントを作成します。

要件 1.1.2

カード所有者データ環境と他のネットワーク (あらゆるワイヤレス ネットワークを含む) の間のすべての接続を示す最新のネットワーク図

お客様の責任

ドキュメントの一部として、送受信トラフィックとセキュリティ制御を示すネットワーク フロー図を保持します。 これには、他のネットワーク (あらゆるワイヤレス ネットワークを含む) から CDE へのトラフィック フローが含まれます。 この図には、クラスター内のフローも示します。 図には侵入センサーと適用された制御を示す必要があるなど、いくつかの特定の要件があります。

この図は参照実装のネットワーク図を示しています。

この図の Visio ファイル をダウンロードします。

図 1.1.2 - ネットワーク フロー

このフローの説明は後続のセクションにあります。

Azure Network Watcher がある場合は Azure 仮想ネットワークのトポロジを表示 できます。 仮想ネットワーク内のすべてのリソース、仮想ネットワーク内のリソースに関連するリソース、およびリソース間のリレーションシップを表示できます。

要件 1.1.3

システムおよびネットワーク間でのすべてのカード所有者データの流れを示す最新の図。

お客様の責任

ドキュメントの一部として、保存時と転送中のデータがどのように保護されるかを示すデータ フロー図を含める必要があります。

この図では、データがワークロードにどのように出入りするのか、1 つのリソースから別のリソースにどのような情報が渡されるのかを示す必要があります。 この図は最新の状態に保つようにしてください。 変更管理プロセスの一部として、データ フロー図を更新するステップを追加します。

このアーキテクチャはワークロード "ではなく" インフラストラクチャに焦点を当てているため、ここでは図を省略しました。

要件 1.1.4

各インターネット接続と、非武装地帯 (DMZ) と内部ネットワーク ゾーン間のファイアウォールの要件。

お客様の責任

DMZ の境界を規定する要素を明確に定義します。 たとえば、カード所有者データ環境 (CDE) は、ファイアウォール、ネットワーク ポリシー、およびその他の制御によって保護された DMZ 内にある場合があります。 詳しくは、 クラウド DMZに関する記事を参照してください。

PCI DSS インフラストラクチャの場合、ネットワーク制御を使用して CDE を含むネットワークへの不正アクセスとネットワークからの不正アクセスをブロックすることにより、CDE を保護する責任があります。 強力なセキュリティ対策のためにネットワーク制御を適切に構成する必要があり、これを以下に対して適用する必要があります。

• 同じクラスター内に配置されたコンポーネント間の通信。
• 信頼されたネットワーク内のワークロードと他のコンポーネント間の通信。
• ワークロードとパブリック インターネット間の通信。

このアーキテクチャでは、以下に示すさまざまなファイアウォール テクノロジを使用して、CDE をホストするクラスターとの間で流れる両方向のトラフィックを検査します。

• Azure Application Gateway はトラフィック ルーターとして使用され、統合された Web アプリケーション ファイアウォール (WAF) はクラスターへの受信 (イングレス) トラフィックのセキュリティ保護に使用されます。

• Azure Firewall は、ネットワークとそのサブネットからのすべての送信 (エグレス) トラフィックをセキュリティで保護するために使用されます。

  トランザクションまたは管理操作の処理の一環として、クラスターは外部エンドポイントと通信する必要があります。 たとえば、クラスターでは AKS コントロール プレーンとの通信、オペレーティング システムやパッケージ更新システムとの通信が必要になる場合があり、多くのワークロードが外部 API と対話します。 これらの相互作用の一部は HTTP を介して行われる場合があり、攻撃ベクトルと見なされます。 これらのベクトルは、データ流出につながる可能性がある中間者攻撃のターゲットです。 エグレス トラフィックにファイアウォールを追加すると、その脅威が軽減されます。

  ポッド間通信でも TLS で暗号化することをお勧めします。 この実践は、相互 TLS (mTLS) 認証を使用したリファレンス実装で示されています。

• NSG を追加することで、クラスターと、インフラストラクチャ内の他のコンポーネントの間のトラフィックをセキュリティで保護します。 たとえば参照実装では、SSH アクセスの試行をブロックするノード プールを持つサブネット上に NSG があります。 仮想ネットワーク内からのトラフィックのみが許可されます。

  アーキテクチャにコンポーネントを追加する際は、サブネット境界でトラフィックの種類を許可または拒否する NSG を追加することを検討してください。 各ノード プールは専用サブネット内にあるため、実際のワークロードの予想トラフィック パターンに基づいて、より具体的なルールを適用します。

• Kubernetes NetworkPolicy オブジェクトは、クラスター内通信を制御するために使用されます。

  既定では、ポッド間通信に制限はありません。 ゼロトラスト ネットワークから始めて必要に応じてパスを開くことによって、クラスター内通信に NetworkPolicy を適用する必要があります。 参照実装では、 a0005-i と a0005-o の名前空間のゼロトラスト ネットワークを示しています。 すべての名前空間 (kube-system、 gatekeeper-system、およびその他の AKS 提供の名前空間を除く) には、制限的なネットワーク ポリシーが適用されています。 ポリシー定義は、これらの名前空間で実行されているポッドに依存します。 readiness、liveliness、startup の各プローブのパスを開くようにしてください。 また、 oms-agent へのパスを開き、ノード レベルのメトリックを送信できるようにします。 許可されたコンテナー ポートに対して一貫性のある NetworkPolicy および Azure Policy を提供できるようにするために、ワークロード全体でポートを標準化することを検討してください。

要件 1.1.5

ネットワーク コンポーネントを管理するグループ、ロール、および責任の説明。

お客様の責任

関連するネットワーク フローとコンポーネントを制御する必要があります。 結果として得られるインフラストラクチャには複数のネットワーク セグメントが含まれ、そのそれぞれに多くの制御があり、それぞれの制御には目的があります。 ドキュメントが、ネットワーク計画から適用されるすべての構成まで、幅広く網羅されていることを確認してください。 また、所有権の詳細、明確な責任の所在、および責任を負っている役割も記載する必要があります。

たとえば、Azure とインターネット間のネットワークのセキュリティ保護のガバナンスの責任者が誰であるかを把握します。 企業では通常、IT チームが Azure Firewall ルール、Web アプリケーション ファイアウォール (WAF) ルール、NSG、その他のネットワーク間トラフィックの構成とメンテナンスを担当します。 さらに、企業全体の仮想ネットワークとサブネットの割り当て、IP アドレスの計画も担当する場合もあります。

ワークロード レベルでは、クラスター オペレーターがネットワーク ポリシーを使用してゼロ トラストの管理を担当します。 また、Azure コントロール プレーン、Kubernetes API、監視テクノロジとの通信が責任に含まれる場合もあります。

常に "すべて拒否" の戦略から始めてください。 ビジネス上の必要性やロールの妥当性がある場合にのみ、アクセス許可を付与します。

要件 1.1.6

業務上の正当な理由、およびすべてのサービス、プロトコル、許容されるポートの使用の承認のドキュメント。これには、セキュリティ上安全でないと考えられるプロトコルに実装されるセキュリティ機能に関するドキュメントが含まれます。

お客様の責任

ネットワーク制御で使用されるサービス、プロトコル、ポートについて説明する詳細なドキュメントを作成します。 明示的に許可されたポート以外、すべて拒否します。 セキュリティで保護されていないプロトコルの使用が避けられない場合は、業務上の正当な理由とセキュリティ機能を文書化します。 次に示すのは、Azure Firewall の参照実装の例です。 ファイアウォール規則の範囲は、それに関連するリソースに限定する必要があります。 つまり、特定のソースからのトラフィックのみが特定の FQDN ターゲットに行くようにします。

トラフィックを許可する可能性がある例をいくつか示します。

ルール	プロトコル:ポート	source	宛先	妥当性
ノードとコントロール プレーンの間のセキュリティで保護された通信を許可する。	HTTPS: 443	クラスター ノード プールに割り当てられた承認済みの IP アドレス範囲	AKS コントロール プレーン内の FQDN ターゲットの一覧。 これは AzureKubernetesService FQDN タグで指定されます。	ノードは、管理ツール、状態と構成情報、およびスケーリングできるノードに関する情報を得るためにコントロール プレーンにアクセスする必要があります。
Flux と GitHub の間のセキュリティで保護された通信を許可する。	HTTPS: 443	AKS ノード プール	github.com, api.github.com	Flux は、ノード上で実行されるサードパーティの統合です。 プライベート GitHub リポジトリとクラスター構成を同期します。

要件 1.1.7

最低でも 6 か月ごとに、ファイアウォールおよびルーターのルール セットをレビューする要件。

お客様の責任

最低でも 6 か月ごとにネットワーク構成とスコープのルールを検討するプロセスを用意します。 これにより、セキュリティ保証が最新で有効な状態に維持されます。 次の構成を確認してください。

• Azure Firewall 規則。
• NSG ルール。
• Azure Application Gateway と WAF のルール。
• ネイティブの Kubernetes ネットワーク ポリシー。
• 該当する Azure リソースに対するファイアウォール制御。 たとえば、このアーキテクチャでは、プライベート エンドポイントからのトラフィックのみを許可するルールを Azure Container Registry で使用します。
• アーキテクチャに追加したその他のネットワーク制御。

前回のレビュー以降にワークロードを廃止したり、クラスターの構成を変更したりした場合は、必要なファイアウォール例外や NSG ルールに関する想定が引き続き有効であることを確認することが重要です。

要件 1.2

カード所有者のデータ環境のシステム コンポーネントと、信頼されていないネットワークとの間の接続を制限するファイアウォールとルーターの構成を構築します。

お客様の責任

このアーキテクチャでは、AKS クラスターはカード所有者データ環境 (CDE) の重要なコンポーネントです。 セキュリティを強化するために、クラスターをプライベート クラスターとしてデプロイすることを強くお勧めします。 プライベート クラスターでは、AKS によって管理される Kubernetes API サーバーとノード プールの間のネットワーク トラフィックがプライベートになります。 API サーバーは、クラスターのネットワーク内のプライベート エンドポイントを介して公開されます。

パブリック クラスターを選択することもできますが、この設計は、規制されたワークロードを含むクラスターには推奨されません。 API サーバーはインターネットに公開されます。 DNS レコードは常に検出可能です。 そのため、クラスター API がパブリック アクセスから保護された状態を維持するための制御が必要です。 パブリック クラスターを使用する必要がある場合は、Kubernetes ロールベースのアクセス制御 (RBAC) を使用して厳密なコントロールを行い、AKS 承認済み IP 範囲フィーチャーと組み合わせて、AKS API Server にアクセスできるユーザーを制限することをお勧めします。 ただし、このソリューションは規制対象のワークロードを含むクラスターには推奨されません。

カードカード所有者データ (CHD) を処理する場合、クラスターが通信する必要があるネットワークは、信頼されていると見なされるものと、そうでないものがあります。 このアーキテクチャでは、PCI-DSS 3.2.1 ワークロードの境界内にある両方のハブスポーク ネットワークが、信頼されたネットワークと見なされています。

信頼されていないネットワークは、その境界外のネットワークです。 信頼できないネットワークには次のものが含まれます。

• 同じインフラストラクチャ上にあるが、ワークロード境界の外側にあるその他のハブとスポーク。
• 公共のインターネット。
• 企業ネットワーク。
• Azure または別のクラウド プラットフォーム内のその他の仮想ネットワーク。

このアーキテクチャでは、イメージ ビルダーをホストする仮想ネットワークは、CHD 処理で果たす役割がないため信頼されていません。 CDE とそのようなネットワークの相互作用は、要件に従ってセキュリティで保護する必要があります。 このプライベート クラスターを使用すると、仮想ネットワーク、NSG、その他の組み込み機能を使用して環境全体を保護できます。

プライベート クラスターの詳細については、「プライベート Azure Kubernetes Service クラスターを作成する」を参照してください。

要件 1.2.1

送受信トラフィックをカード所有者データ環境に必要なものだけに限定し、その他のすべてのトラフィックを明示的に拒否します。

お客様の責任

設計上、Azure 仮想ネットワークにはパブリック インターネットから直接アクセスすることはできません。 すべての受信 ("イングレス") トラフィックは、中間トラフィック ルーターを経由する必要があります。 ただし、デフォルトでは、ネットワーク内のすべてのコンポーネントがパブリック エンドポイントにアクセスできます。 この動作を無効にするには、 プライベート サブネットを構成するか、UDR を使用してすべての送信トラフィックをファイアウォール経由で送信します。 送信（または 出力）トラフィックは、安全な暗号と TLS 1.2 以降のみを許可するように明示的に保護する必要があります。

• Azure Application Gateway の統合 WAF は、すべての HTTP(S) イングレス トラフィックをインターセプトし、検査されたトラフィックをクラスターにルーティングします。

  このトラフィックの発生元のネットワークは、信頼されている場合と信頼されていない場合があります。 Application Gateway はスポーク ネットワークのサブネットにプロビジョニングされ、NSG によって保護されます。 トラフィックが流入すると、WAF ルールによって許可または拒否され、Application Gateway によって構成されたバックエンドにトラフィックがルーティングされます。 たとえば、Application Gateway は、こちらの種類のトラフィックを拒否することによって CDE を保護します。

  • TLS で暗号化されていないすべてのトラフィック。
  • Azure インフラストラクチャからのコントロール プレーン通信のためのポート範囲外のトラフィック。
  • クラスター内の内部ロード バランサー以外のエンティティによって送信される正常性プローブ要求。

• Azure Firewall は、信頼されているネットワークとそうでないものからのすべての送信 (エグレス) トラフィックを保護するために使用されます。

  Azure Firewall は、ハブ ネットワークのサブネットにプロビジョニングされます。 Azure Firewall を単一のエグレス ポイントとして強制するために、エグレス　トラフィックを生成できるサブネットでユーザー定義ルート (UDF) が使用されます。 これには、イメージ ビルダー仮想ネットワークなど、信頼されていないネットワーク内のサブネットが含まれます。 トラフィックが Azure Firewall に達すると、特定のソースからのトラフィックが特定のターゲットに到達できるように、いくつかのスコープのルールが適用されます。

  詳細については、「Azure Firewall を使用して Azure Kubernetes Service (AKS) のデプロイを保護する」を参照してください。

• 必要に応じて、HTTP プロキシを使用して、クラスターから外部リソースへの送信 (エグレス) トラフィックの監視とセキュリティ保護を行うことができます。

  ファイアウォールに加えて、HTTP プロキシを使用してエグレスで追加の制御を行う必要がある組織もあります。 ユーザー定義ルートは引き続きファイアウォールを通過させ、エグレス トラフィックは単に HTTP プロキシを通過するように制限することをお勧めします。 この設定では、ポッドがプロキシをオーバーライドしようとすると、ファイアウォールが引き続きエグレス トラフィックをブロックできます。

  詳細については、「Azure Kubernetes Service での HTTP プロキシのサポート」を参照してください。

クラスターは、パブリック インターネット経由で他のサービスにアクセスする必要がある場合があります。 たとえば、サードパーティのマルウェア対策ソフトウェアを使用する場合は、パブリックインターネット経由でサーバーからウイルス定義を取得する必要があります。

他の Azure サービスのエンドポイントとの相互作用はAzure backboneを介して行います。 たとえば、通常の操作の一環として、クラスターはマネージド キー ストアから証明書を取得したり、コンテナー レジストリからイメージをプルしたりすることが必要になります。 Azure Private Linkを使用して、これらの対話がプライベートで安全であることを確認します。

ファイアウォール ルールとプライベート ネットワークに加えて、トラフィック フローも NSG ルールを通じて保護されます。 ここでは、このアーキテクチャの例として、トラフィックを拒否することによって CDE が保護されるものをいくつか示します。

• ノード プールを持つサブネット上の NSG は、ノードへの SSH アクセスをすべて拒否します。 すべてのアクセスを拒否する原則を維持しながら、ジャストインタイムの緊急アクセスのためのプロセスが確立されていることを確認します。
• 管理ツールを実行するためのジャンプ ボックスがあるサブネット上の NSG は、ハブ ネットワーク内の Azure Bastion からのトラフィックを除くすべてのトラフィックを拒否します。
• Azure Key Vault および Azure Container Registry へのプライベート エンドポイントを持つサブネット上の NSG は、内部ロード バランサーからのトラフィックと Azure Private Link 経由のトラフィックを除くすべてのトラフィックを拒否します。

要件 1.2.2

ルーター構成ファイルをセキュリティで保護し、同期します。

お客様の責任

実際にデプロイされた状態と望ましい状態との差異を検出するメカニズムを作成します。 Infrastructure as Code (IaC) は、この目的に適しています。 たとえば、Bicep ファイルまたは Azure Resource Manager テンプレート (ARM テンプレート) は、目的の状態の記録を保持します。

Bicep ファイルなどのデプロイメント アセットは、すべての変更履歴を保持できるようにソース管理されている必要があります。 Azure アクティビティ ログ、デプロイ パイプラインログ、Azure デプロイ ログから情報を収集します。 これらのソースは、デプロイされた資産の記録を維持するのに役立ちます。

クラスターでは、Kubernetes ネットワーク ポリシーなどのネットワーク制御もソース管理フローに従う必要があります。 この実装では、GitOps オペレーターとして Flux が使用されます。 ネットワーク ポリシーなどのクラスター構成を同期する場合、Git 履歴と Flux および API ログを組み合わせて、構成履歴のソースにすることができます。

要件 1.2.3

すべてのワイヤレス ネットワークとカード所有者データ環境の間に境界ファイアウォールをインストールし、ワイヤレス環境とカード所有者データ環境の間で、業務目的にトラフィックが必要な場合は認証されたトラフィックのみを許可し、それ以外は拒否するようファイアウォールを構成します。

お客様の責任

ワイヤレス ネットワークから AKS ノードとノード プールに到達できないようにする必要があります。 また、Kubernetes API サーバーへの要求を拒否する必要があります。 これらのコンポーネントへのアクセスは、承認済みかつセキュリティで保護されたサブネットに制限されます。

一般に、オンプレミスのトラフィックからスポーク ネットワークへのアクセスを制限します。

要件 1.3

インターネットとカード所有者データ環境にあるシステム コンポーネントの間の直接のパブリック アクセスを禁止します。

お客様の責任

AKS クラスター ノード プールは仮想ネットワーク内で動作し、インターネットなどのパブリック ネットワークから分離されています。 分離を維持するには、パブリック IP がクラスター ノードに関連付けされないようにし、インターネット トラフィックがブロックされるようにする NSG ルールをクラスター サブネットに適用します。 アクセス制御の詳細については、 DMZ のセクションを参照してください。

AKS クラスターには、重要なシステム ポッドをホストするシステム ノード プールがあります。 ユーザー ノード プールにも、クラスター操作に参加する他のサービスを実行するポッドがあります。 たとえば、ポッドは、クラスター構成を GitHub リポジトリに同期するために Flux を、またはワークロード ポッドにトラフィックをルーティングするためにイングレス コントローラーを実行することがあります。 ノード プールの種類に関係なく、すべてのノードを保護する必要があります。

もう 1 つの重要なシステム コンポーネントは API サーバーで、これはクラスターと構成の状態の維持など、ネイティブの Kubernetes タスクを実行するために使用されます。 プライベート クラスターを使用する利点は、既定で API サーバー エンドポイントが公開されないことです。 プライベート クラスターの詳細については、「プライベート Azure Kubernetes Service クラスターを作成する」を参照してください。

他のエンドポイントとのやりとりもセキュリティで保護する必要があります。 1 つの方法は、通信をプライベート ネットワーク経由に制限する方法です。 たとえば、プライベート リンク経由でクラスターが Azure Container Registry からイメージをプルするようにします。

要件 1.3.1

パブリックにアクセスできる承認されたサービス、プロトコル、およびポートを提供するシステム コンポーネントのみに受信トラフィックを制限するよう DMZ を実装します。

お客様の責任

いくつかのベスト プラクティスを次に示します。

• ノード プール ノードでパブリック IP アドレスを構成しないでください。
• Azure Policyを使用して、Kubernetes がパブリック ロード バランサーを公開しないようにします。 クラスター内のトラフィックは、内部ロード バランサーを介してルーティングされる必要があります。
• 内部ロードバランサーは、WAF が統合された Azure Application Gateway にのみ公開します。
• すべてのネットワーク制御で、ソース、宛先、ポート、およびプロトコルの制限を指定します (該当する場合)。
• API サーバーをインターネットに公開しないでください。 クラスターをプライベート モードで実行すると、エンドポイントが公開されず、ノード プールと API サーバーの間の通信がプライベート ネットワーク経由で行われます。

ユーザーは、境界ネットワークを実装して AKS クラスターを保護できます。 詳しくは、 クラウド DMZに関する記事を参照してください。

要件 1.3.2

受信インターネット トラフィックが DMZ 内の IP アドレスに制限されている必要があります。

お客様の責任

クラスター ネットワーク内で、内部ロードバランサーを持つサブネット上に NSG を設定します。 WAF が統合された Azure Application Gateway があるサブネットからのトラフィックのみを受け入れるように規則を構成します。 AKS クラスター内で、Kubernetes NetworkPolicies を使用して、ポッドへのイングレス トラフィックを制限します。

要件 1.3.3

スプーフィング対策を実装して、ネットワークに入ってから偽造されたソース IP アドレスを検知してブロックする必要があります。

Azure の責任

さらに、なりすましトラフィックを防止し、送受信トラフィックを信頼できるプラットフォーム コンポーネントだけに限定するため、ネットワーク フィルター処理が実装されていています。

要件 1.3.4

カード所有者データ環境からインターネットへの、承認されていない送信トラフィックをブロックする必要があります。

お客様の責任

承認されていない送信トラフィックをブロックする方法をこちらに示します。

• すべてのクラスター サブネットでユーザー定義ルート (UDR) を使用して、AKS クラスターからのすべての送信 (エグレス) トラフィックをAzure Firewall経由するように強制します。 これにはシステムおよびユーザーのノード プールを持つサブネットが含まれます。
• ノード プールを持つサブネットに NSG を追加して、送信トラフィックを制限します。
• Kubernetes NetworkPolicies を使用して、ポッドからのエグレス トラフィックを制限します。
• 追加のポリシーを処理するためのサービス メッシュを使用します。 たとえば、TLS で暗号化されたトラフィックのみをポッド間で許可する場合、サービス メッシュ プロキシによって TLS 検証を処理できます。 この例は、この実装で示しています。 プロキシとして Envoy がデプロイされています。
• ファイアウォール サブネットなど、明示的に承認されているサブネットによる場合を除き、CDE 内のネットワークにパブリック IP アドレスを追加できないようにします。
• Azure Firewall に加えて HTTP プロキシを使用して、AKS クラスターからインターネットへの送信 (エグレス) トラフィックを制限します。
• Azure Monitor Private Link Service (AMPLS) を使用して、コンテナー分析情報のログから Azure Monitor へのセキュリティで保護されたプライベート接続経由で送信します。 AMPLS を有効にした場合の影響について理解します。

詳細については、「Azure Kubernetes Service (AKS) でクラスター ノードに対するエグレス トラフィックを制御する」を参照してください。

要件 1.3.5

ネットワークへの "確立された" 接続のみを許可します。

Azure の責任

さらに、なりすましトラフィックを防止し、送受信トラフィックを信頼できるプラットフォーム コンポーネントだけに限定するため、ネットワーク フィルター処理が実装されていています。 Azure ネットワークは、管理トラフィックとお客様のトラフィックを隔離するよう分離されています。

要件 1.3.6

DMZ やその他の信頼されていないネットワークから分離された内部ネットワーク ゾーンに、カード会員データを格納するシステム コンポーネント (データベースなど) を配置します。

お客様の責任

たとえば Private Link を使用して、プライベート ネットワーク経由でのみストレージ システムを公開します。 また、それが必要なノード プール サブネットからのアクセスを制限します。 クラスター外で独自の専用のセキュリティ ゾーン内という状態を維持します。

要件 1.3.7

プライベート IP アドレスおよびルーティング情報を、承認されていないユーザーに公開してはなりません。

お客様の責任

この要件を満たすには、パブリック AKS クラスターという選択肢はありません。 プライベート クラスターは、プライベート DNS ゾーンを使用することによって DNS レコードをパブリック インターネットから隔離します。 ただし、 パブリック DNS アドレスを持つプライベート AKS クラスターを作成することは引き続き可能です。 そのため、コントロール プレーンのプライベートIP アドレスの漏えいを防ぐために、 enablePrivateClusterPublicFQDN を false に設定して、この機能を "明示的" に無効にすることをお勧めします。 パブリック DNS レコードのないプライベート クラスターの使用が強制されるように、Azure Policy を使用することを検討してください。

また、WAF が統合された Azure Application Gateway を持つサブネットと、内部ロード バランサーを持つサブネットの間のルーティングにも、プライベート DNS ゾーンを使用します。 ヘッダーまたは本文にプライベート IP 情報が含まれている HTTP 応答がないことを確認します。 IP および DNS レコードを含む可能性のあるログが、運用上のニーズ以外で公開されていないことを確認します。

Private Link 経由で接続された Azure サービスには、プライベート IP アドレスを公開するパブリック DNS レコードがありません。 ご使用のインフラストラクチャで Private Link を最大利用する必要があります。

要件 1.4

ネットワーク外でインターネットに接続する携帯コンピューティング デバイスに個人用ファイアウォール ソフトウェアまたは同等の機能をインストールします。これは、CDE にアクセスする場合にも使用するものです。

お客様の責任

プライベート クラスターは、AKS コントロール プレーンによって管理されています。 ノードに直接アクセスすることはできません。 管理タスクを実行するには、別のコンピューティング リソースから kubectl などの管理ツールを使用する必要があります。 コマンドを実行できるエアギャップ ジャンプ ボックスを使用するという選択肢があります。 また、ジャンプ ボックスからの送受信トラフィックは、制限され、セキュリティで保護されている必要があります。 アクセスに VPN が使用されている場合は、クライアント コンピューターが企業ポリシーによって管理され、すべての条件付きアクセス ポリシーが設定されていることを確認してください。

このアーキテクチャでは、そのジャンプ ボックスはスポーク ネットワークの別のサブネットにあります。 ジャンプ ボックスへの受信アクセスを制限するには、、SSH 経由で Azure Bastion を使用したアクセスのみを許可する NSG を使用します。

ジャンプ ボックスで特定のコマンドを実行するには、パブリック エンドポイントに接続する必要があります。 たとえば、Azure 管理プレーンによって管理されるエンドポイントなどです。 送信トラフィックはセキュリティで保護されている必要があります。 スポーク ネットワーク内の他のコンポーネントと同様に、ジャンプ ボックスからの送信トラフィックは、HTTPS トラフィックが Azure Firewall を通過するように強制する UDR を使用して制限されます。

要件 1.5

セキュリティ ポリシーとファイアウォールを管理するための運用手順が文書化され、使用され、すべての関係者に通知されていることを確認します。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが極めて重要です。 これは、AKS クラスターをセグメント化する Azure Firewall ルールを管理する場合に特に当てはまります。 規制の対象となる環境の運用担当者に対し、セキュリティの保証をサポートするための教育を施し、情報を提供し、インセンティブを与える必要があります。 これは、広範な管理特権を付与されているアカウントを持つ人たちについては特に重要です。

要件2 - システムパスワードやその他のセキュリティパラメータにベンダー提供のデフォルトを使用しない

お客様の責任

要件	担当
要件 2.1	ネットワークにシステムをインストールする前に必ず、ベンダーから提供された既定値を変更し、不要な既定のアカウントを無効にするか削除します。
要件 2.2	すべてのシステム コンポーネントの構成標準を作成します。 これらの標準がすべての既知のセキュリティ脆弱性に対処し、業界で受け入れられているセキュリティ強化標準に準拠していることを確認します。
要件 2.3	強力な暗号を使用して、コンソール以外からのすべての管理アクセスを暗号化します。
要件 2.4	PCI DSS のスコープ内のシステム コンポーネントのインベントリを管理します。
要件 2.5	ベンダーの既定値およびその他のセキュリティ パラメーターを管理するためのセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に通知されていることを確認します。
要件 2.6	共有ホスティング プロバイダーは、各事業体のホスト環境およびカード所有者データを保護する必要があります。

システムのパスワードとその他のセキュリティ パラメーターで、ベンダーが指定した既定値を使用しない

要件 2.1

ネットワークにシステムをインストールする前に必ず、ベンダーから提供された既定値を変更し、不要な既定のアカウントを無効にするか削除します。

お客様の責任

ベンダーによって提供される既定の設定を変更する必要があります。 既定の設定は一般的な攻撃ベクトルであり、システムが攻撃を受けやすくなります。 次にいくつかの考慮事項を示します。

• コンテナー レジストリの管理者アクセスを無効にします。
• ジャンプ ボックスとビルド エージェントがユーザー管理手順に従って、不要なシステム ユーザーを削除していることを確認します。
• 管理者ユーザーにノードへの SSH キー アクセスを生成したり提供したりしないでください。 緊急アクセスが必要な場合は、Azure 復旧プロセスを使用して、Just-In-Time アクセスを取得します。

Azure の責任

Microsoft Entra ID には、ユーザーが指定した新しいパスワードに適用されるパスワード ポリシーがあります。 パスワードを変更する場合は、古いパスワードの検証が必要になります。 管理者によってリセットされたパスワードは、ユーザーが次にサインインするときに変更する必要があります。

要件 2.1.1

カード所有者データ環境に接続している、またはカード所有者データを伝送しているワイヤレス環境の場合、インストール時に、ワイヤレス ベンダーの既定値をすべて変更してください。これには、既定のワイヤレス暗号化キー、パスワード、SNMP コミュニティ文字列が含まれます (ただし、これらに限定されません)。

お客様の責任

このアーキテクチャと実装は、ワイヤレス接続を介してオンプレミスまたは企業のネットワークからクラウドへのトランザクションを実行するように設計されていません。 考慮事項については、公式の PCI DSS 3.2.1 標準のガイダンスを参照してください。

要件 2.2

すべてのシステム コンポーネントの構成標準を作成します。

お客様の責任

Microsoft クラウド セキュリティ ベンチマークのレコメンデーションを実装します。 これによって、CIS、NIST、PCI-DSS 3.2.1 などの業界フレームワークを対象とする Azure のセキュリティに関する推奨事項が一元的にまとめて示されます。 Microsoft Defender for Cloud の機能と Azure Policy を使用して、標準を追跡できます。 Azure セキュリティ ベンチマークが Microsoft Defender for Cloud の既定のイニシアティブです。 Azure Policy と Azure テナント セキュリティ ソリューション (AzTS) で、追加の自動チェックを作成することを検討してください。

CDE 内のすべてのコンポーネントの望ましい構成状態を文書化します。特に、AKS ノード、ジャンプ ボックス、ビルド エージェント、およびクラスターと対話するその他のコンポーネントについて行います。

詳細については、「Microsoft クラウド セキュリティ ベンチマーク」を参照してください。

Azure の責任

Azure では、業界で受け入れられているセキュリティ強化標準に準拠したセキュリティ構成標準が提供されています。 この標準は、少なくとも年 1 回レビューされます。

要件 2.2.1

同じサーバーに共存する機能ごとに異なるセキュリティ レベルが必要にならないよう、サーバーの主要な機能は各サーバーに 1 つのみ実装します。 (たとえば、Web サーバー、データベース サーバー、および DNS を別々のサーバーに実装します。)

お客様の責任

必要なセグメント化レベルを提供することが重要な戦略となります。 1 つの方法は、対象範囲内のコンポーネントと対象範囲外のコンポーネントをそれぞれ別々のクラスターにデプロイすることです。 これにより、追加されたインフラストラクチャとメンテナンスのオーバーヘッドのコストが増加することを理解してください。 別の方法として、同じ共有クラスター内にすべてのコンポーネントを配置する方法もあります。 セグメント化戦略を使用して、分離を維持します。 たとえば、クラスター内に別々のノード プールを作成します。

リファレンス実装では、2 番目の方法は、1 つのクラスターへのマイクロサービス アプリケーションのデプロイで示されています。 このアプリケーションには 2 つのサービス セットがあり、1 つのセットには対象範囲内のポッドがあり、もう 1 つは対象範囲外です。 両方のセットは 2 つのユーザー ノード プールにわたって分散されています。 Kubernetes テイントを使用することで、対象範囲内のポッドと対象範囲外のポッドは個別のノード プールにデプロイされ、ノード VM を共有することはありません。

コンテナー テクノロジの場合、このセグメント化は既定で提供されますが、これはコンテナーの 1 つのインスタンスだけがシステム内の 1 つの関数の処理を行うためです。

各ワークロード ポッドは独自の ID を使用する必要があります。 クラスター レベルまたはノード レベルの ID を継承することはできません。

可能な場合は、オンノード (クラスター内) ストレージではなく、外部ストレージを使用します。 クラスター ポッドは、カード所有者データ処理の操作の一部として実行する必要がある作業専用に予約しておきます。 対象範囲外の操作はクラスター外に移動します。 このガイダンスは、ビルド エージェント、関連のないワークロード、またはクラスター内にジャンプ ボックスがあるアクティビティなどに適用されます。

要件 2.2.2

必須のサービス、プロトコル、デーモンなど、システムの機能に必要なもののみを有効にします。

お客様の責任

機能とその影響を確認してから有効にしてください。 既定の設定には、必要のない機能が含まれる場合があり、これらの機能によってワークロードの可視性が必要になることがあります。 この例として、Azure Application Gateway の既定の SSL ポリシーの暗号が挙げられます。 ポリシーが過度に寛大でないか確認してください。 必要な暗号のみを選択してカスタム ポリシーを作成することをお勧めします。

完全に制御できるコンポーネントについては、イメージから不要なシステム サービスをすべて削除します。 たとえば、ジャンプ ボックスとビルド エージェントのイメージを確認し、不要なコンポーネントを削除します。

AKS ノードなど、表示のみ可能なコンポーネントの場合は、Azure によってノードにインストールされる内容を文書化します。 DaemonSets を使用して、これらのクラウド制御コンポーネントに必要な追加の監査を提供することを検討してください。

要件 2.2.3

必要なサービス、プロトコル、またはデーモンがセキュリティで保護されていないと考えられる場合は、追加のセキュリティ機能を実装します。

お客様の責任

Application Gateway には統合された WAF があり、パブリック エンドポイントに送信される要求に対して TLS ハンドシェイクをネゴシエートし、セキュリティで保護された暗号のみを許可します。 参照実装では、TLS 1.2 と承認された暗号のみがサポートされます。

Azure Application Gateway を介して CDE と対話する必要があるレガシ デバイスがあるとします。 この要件を満たすには、Application Gateway で安全でないプロトコルを有効にする必要があります。 その例外を文書に記録し、そのプロトコルがそのレガシ デバイス以外で使用されているかどうかを監視します。 そのレガシのやりとりが停止されたらすぐに、そのプロトコルを無効にしてください。

Application Gateway はポート 80 上の要求に応答してはなりません。 アプリケーション レベルでリダイレクトを実行しないでください。 この参照実装には、ポート 80 のトラフィックをブロックする NSG ルールがあります。 このルールは、Application Gateway があるサブネットに関するものです。

クラスター内のあるワークロードが、セキュリティ コンプライアンス プロファイルまたはその他の制御 (制限やクォータなど) に関する組織のポリシーに準拠できない場合、この例外が文書化されていることを確認します。 想定される機能だけが実行されるように監視する必要があります。

要件 2.2.4

誤用や悪用が起きないよう、システムのセキュリティ パラメーターを構成します。

お客様の責任

アーキテクチャで使用されるすべての Azure サービスは、 Microsoft クラウド セキュリティ ベンチマークによって提供されるレコメンデーションに従う必要があります。 これらの推奨事項は、特定のセキュリティ構成設定を選択するための開始点となります。 また、実際の構成をそのサービスのベースライン実装と比較します。 セキュリティ ベースラインの詳細については、「Azure のセキュリティ ベースライン」を参照してください。

Open Policy Agent アドミッション コントローラーは、Azure Policy と連携して動作し、クラスターの誤った設定を検出して防止します。 ノードでパブリック IP の割り当てを許可しないという組織ポリシーがあるとします。 このような割り当てが検出されると、ポリシー定義で指定されたアクションに基づいて、監査または拒否のマークが付けられます。

インフラストラクチャ レベルでは、Azure リソースの種類と構成に制限を適用できます。 誤った構成を防ぐには、Azure Policy を使用します。 この参照実装には、プライベートではない AKS クラスターの作成を拒否するポリシーがあります。

すべての例外が文書化され、定期的にレビューされることを確認します。

Azure の責任

Azure では、承認されているユーザーのみが、多要素アクセス制御と文書化されたビジネス ニーズを使用して、Azure プラットフォームのセキュリティ コントロールを構成できます。

要件 2.2.5

スクリプト、ドライバー、機能、サブシステム、ファイル システム、および不要な Web サーバーなど、不要な機能をすべて削除します。

お客様の責任

トランザクションの処理に関与しない、またはセキュリティ エージェントなどのコンプライアンス要件の監視を行わないジャンプ ボックスまたはビルド エージェントに、ソフトウェアをインストールしないでください。 この推奨事項は、クラスターエンティティ (DaemonSet やポッドなど) にも適用されます。 すべてのインストールが検出され、ログに記録されていることを確認します。

要件 2.3

強力な暗号を使用して、コンソール以外からのすべての管理アクセスを暗号化します。

お客様の責任

クラスターに対するすべての管理アクセスは、コンソールを使用して実行する必要があります。 クラスターのコントロール プレーンを公開しないでください。

Azure の責任

Azure では、ハイパーバイザー インフラストラクチャへのアクセスに強力な暗号化が適用されます。 これにより、Azure ポータルを使用する顧客は、強力な暗号化を使用してサービスおよびホスト コンソールにアクセスできるようになります。

要件 2.4

PCI DSS のスコープ内のシステム コンポーネントのインベントリを管理します。

お客様の責任

アーキテクチャで使用されるすべての Azure リソースには、適切なタグを付ける必要があります。 タグはデータの分類に役立ち、サービスが対象範囲内であるか対象範囲外であるかを示します。 細かなタグ付けにより、リソースのクエリ、在庫の保持、コストの追跡、およびアラートの設定を行うことができます。 また、そのドキュメントのスナップショットを定期的に管理します。

詳細なレベルで、対象範囲内または対象範囲外のリソースにタグを付けないようにしてください。 ソリューションの進化に伴い、対象範囲外のリソースは、間接的にやりとりしたり、カード所有者データに隣接したりした場合でも、対象範囲内になる可能性があります。 これらのリソースは監査の対象であり、監査中の代表的なサンプルの一部となる可能性があります。 より高いレベルで、サブスクリプションおよびクラスターのレベルでタグ付けを検討してください。

タグ付けの詳細については、「リソースの名前付けとタグ付けの意思決定ガイド」を参照してください。

Kubernetes ラベルを適用して、クラスター内のオブジェクトにタグ付けします。 この方法では、オブジェクトの整理、オブジェクトのコレクションの選択、およびインベントリのレポート作成を行うことができます。

要件 2.5

ベンダーの既定値およびその他のセキュリティ パラメーターを管理するためのセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に通知されていることを確認します。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 担当者は、各 Azure リソースのセキュリティ機能と構成設定についてトレーニングを受ける必要があります。 規制の対象となる環境の運用担当者に対し、セキュリティの保証をサポートするための教育を施し、情報を提供し、インセンティブを与える必要があります。 これらの手順は、広範な管理権限が付与されている人にとって特に重要です。

要件 2.6

共有ホスティング プロバイダーは、各事業体のホスト環境およびカード所有者データを保護する必要があります。

お客様の責任

Azure では、共有されるホスト環境コンポーネントのセキュリティ保証が提供されます。 AKS ノードをこのワークロードの専用ホストとして扱うことを強くお勧めします。 つまり、すべてのコンピューティングを 1 つのテナント モデルに含めて、運用する他のワークロードと共有しないようにする必要があります。

Azure インフラストラクチャ レベルで完全なコンピューティング分離が必要な場合は、 Azure Kubernetes Service (AKS) クラスターに Azure Dedicated Host を追加できます。 このオファリングは、ワークロードに専用の "物理" サーバーを提供し、これらのプロビジョニングされたホストに AKS ノードを直接配置できるようにします。 このアーキテクチャの選択はコストに大きな影響を与えるため、慎重な容量計画が必要です。 ほとんどのシナリオでは一般的ではありません。

次のステップ

保存されたカード所有者のデータを保護する。 オープンなパブリック ネットワークを経由するカード所有者のデータ転送を暗号化する。

関連リソース

• Azure Kubernetes Service (AKS) アーキテクチャの設計
• PCI-DSS 3.2.1 の AKS 規制クラスターの概要 (パート 1/9)
• PCI-DSS 3.2.1 の AKS 規制クラスターのアーキテクチャ (パート 2/9)
• Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ
• マルチリージョン クラスターの AKS ベースライン