PCI-DSS 3.2.1 の AKS ベースライン クラスターでのアクセス管理 (パート 6/9)

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

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

Kubernetes には、Kubernetes API へのアクセス許可を管理するネイティブのロールベースのアクセス制御 (RBAC) があります。 Kubernetes リソースに対する特定のアクセス許可またはアクションを持った複数の組み込みロールが存在します。 Azure Kubernetes Service (AKS) では、これらの組み込みロールと、きめ細かな制御のためのカスタム ロールがサポートされています。 Kubernetes RBAC によって、これらのアクションをユーザーに許可 (または拒否) することができます。

このアーキテクチャと実装は、オンプレミスのリソースまたはデータセンターへの物理的なアクセスに対する制御を提供するために設計されたものではありません。 エッジのプラットフォームやデータ センターではなく Azure で CDE をホストする利点の 1 つは、物理アクセス制限のほとんどが Azure データセンターのセキュリティによって既に処理されていることです。 組織には物理ハードウェアの管理責任はありません。

強力なアクセス制御手段を実装する

要件 7 — 業務上の知る必要によってカード所有者データへのアクセスを制限する

AKS 機能のサポート

AKS は、ID プロバイダーとして Microsoft Entra ID と完全に統合されています。

Kubernetes のユーザー ID と資格情報を個別に管理する必要はありません。 Kubernetes RBAC のために Microsoft Entra ユーザーを追加できます。 この統合により、Microsoft Entra ユーザーにロールの割り当てができるようになります。 Microsoft Entra RBAC では、閲覧者、ライター、サービス管理者、クラスター管理者などのロール定義を組み込みロールとしてサポートしています。 さらにきめ細かな制御のためのカスタム ロールを作成することもできます。

既定では、Azure RBAC は "すべて拒否" に設定されているため、アクセス許可を付与しないとリソースにアクセスできません。 AKS では、AKS ワーカー ノードへの SSH アクセスを制限し、AKS ネットワーク ポリシーを使用してポッド内のワークロードへのアクセスを制御します。

詳細については、「Kubernetes 認可に Azure RBAC を使用する」および「Azure Policy でクラスターをセキュリティで保護する」を参照してください。

お客様の責任

要件	担当
要件 7.1	システム コンポーネントとカード所有者データへのアクセスは、職務上そのようなアクセスを必要とする個人のみに制限する。
要件 7.2	システム コンポーネントに対するユーザーのアクセスを、知る必要性に基づいて制限し、明確に許可されない限り、"すべて拒否" に設定したアクセス制御システムを確立する。
要件 7.3	カード所有者データへのアクセスを制限するためのセキュリティ ポリシーと運用手順を文書化し、使用し、すべての関係者に通知する。

要件 7.1

システム コンポーネントとカード所有者データへのアクセスは、職務上そのようなアクセスを必要とする個人のみに制限する。

お客様の責任

次にいくつかの考慮事項を示します。

• 組織の要件と、ID 管理に関するコンプライアンス要件を実装が満たしていることを確認します。
• 重大な影響があるアカウントについては特に、継続的なアクセス許可を最小限にします。
• 最小特権アクセスの原則に従います。 タスクを完了するために必要なアクセス権のみを提供します。

要件 7.1.1

各役割が必要とするアクセス権を定義する。

• 各役割がその職務権限でアクセスする必要があるシステム コンポーネントとデータ リソース
• リソースにアクセスするために必要な特権 (ユーザー、管理者など) のレベル。

お客様の責任

スコープ内のコンポーネントに必要な、また、それらと Azure リソースの相互作用に必要なタスクと責任に基づいてロールを定義します。 次のような広範なカテゴリから始めることができます。

• Azure 管理グループ、サブスクリプション、またはリソース グループごとのスコープ
• ワークロードまたはサブスクリプションの Azure Policy
• コンテナーの操作
• シークレットの管理
• ビルドとデプロイのパイプライン

これらの領域に関するロールと責任の定義は、チームの構造に関連付けられる場合がありますが、ワークロードの要件に集中してください。 たとえば、セキュリティ、分離性、デプロイ、監視のメンテナンスに誰が責任を持つのかなどです。 次に例をいくつか示します。

• アプリケーションのセキュリティ、Kubernetes RBAC、ネットワーク ポリシー、Azure ポリシー、他のサービスとの通信に関する決定。
• Azure Firewall、Web アプリケーション ファイアウォール (WAF)、ネットワーク セキュリティ グループ (NSG)、DNS 構成の構成とメンテナンス。
• サーバー セキュリティ、修正プログラムの適用、構成、およびエンドポイントのセキュリティの監視と修復。
• RBAC、Microsoft Defender for Cloud、管理者保護戦略、および Azure リソースを管理するための Azure Policy の使用についての指針の決定。
• インシデントの監視と対応チーム。 セキュリティ情報イベント管理 (SIEM) コンソールまたは Microsoft Defender for Cloud でのセキュリティ インシデントの調査と修復。

次に、ワークロードとインフラストラクチャに関して、どのようなレベルのアクセスがロールに必要かを決定することによって、定義を形式化します。 ここでは、わかりやすく説明するための簡単な定義を示します。

Role	役割	アクセス レベル
アプリケーションの所有者	ビジネスの成果に合わせて機能を定義し、優先順位を付けます。 機能がワークロードのコンプライアンス スコープにどのように影響するかを理解し、顧客のデータの保護および所有権とビジネスの目標のバランスを取ります。	アプリケーションによって出力されるログとメトリックに対する読み取りアクセス。 ワークロードまたはクラスターにアクセスするためのアクセス許可は必要ありません。
アプリケーション開発者	アプリケーションを開発します。 すべてのアプリケーション コードは、コンプライアンス、構成証明、リリース管理の各プロセスを支えるトレーニングおよび品質ゲートの対象となります。 ビルド パイプラインを管理する場合がありますが、デプロイ パイプラインは通常は管理しません。	ワークロードのスコープ内にある Kubernetes 名前空間と Azure リソースに対する読み取りアクセス。 システムの状態をデプロイまたは変更するための書き込みアクセス権はありません。
アプリケーション オペレーター (または SRE)	コード ベース、監視、運用に関する深い知識。 ライブサイトのトリアージとトラブルシューティングを行います。 アプリケーション開発者と共に、アプリケーションの可用性、スケーラビリティ、パフォーマンスを向上させます。 "ラストマイル" のデプロイ パイプラインを管理し、ビルド パイプラインの管理を支援します。	関連する Kubernetes 名前空間と Azure リソースを含むアプリケーションのスコープ内での高度な特権。 多くの場合、Kubernetes クラスターの一部に対する継続的なアクセス権を持ちます。
インフラストラクチャの所有者	接続性やコンポーネントの機能を含め、コスト効率の高いアーキテクチャを設計します。 スコープには、クラウドのサービスやオンプレミスのサービスを含めることができます。 機能のデータ保持、ビジネス継続性機能などを決定します。	プラットフォームのログやコスト センターのデータへのアクセス。 クラスター内でのアクセスは必要ありません。
インフラストラクチャ オペレーター (または SRE)	クラスターおよび依存サービスに関連する操作。 ワークロードがデプロイされるクラスターのパイプラインのビルド、デプロイ、ブートストラップを行います。 ターゲット ノード プールと、期待されるサイズおよびスケールの要件を設定します。 インフラストラクチャと依存サービスをホストしているコンテナーの正常性を監視します。	ワークロードの名前空間に対する読み取りアクセス。 クラスターに対する高度な特権アクセス。
ポリシーとセキュリティの所有者	セキュリティまたは規制上のコンプライアンスに関する専門知識。 会社の従業員とその資産、および会社の顧客のそれらについて、セキュリティおよび規制上のコンプライアンスを保護するポリシーを定義します。 他のすべてのロールと連携して、すべてのフェーズを通じてポリシーが適用され、監査可能であることを保証します。	ワークロードとクラスターに対する読み取りアクセス。 また、ログと監査データに対するアクセス権。
ネットワーク オペレーター	企業全体の仮想ネットワークとサブネットの割り当て。 Azure Firewall、WAF、NSG、DNS 構成の構成とメンテナンス。	ネットワーク レイヤーでの高度な特権。 クラスター内での書き込みアクセス許可はありません。

要件 7.1.2

特権のあるユーザー ID へのアクセスを、職責を果たすために必要な最小限の特権に制限する。

お客様の責任

職務権限に応じ、業務に支障をきたさない範囲でアクセスを最小限に絞り込むように努めます。 いくつかのベスト プラクティスを次に示します。

• タスクを完了するために必要なアクセス権のみを ID に付与します。
• スコープ内のコンポーネントにアクセスできる、重大な影響がある ID については特に、継続的なアクセス許可を最小限にします。
• 可能な場合、さらに制限を追加します。 1 つの方法は、アクセス基準に基づいて条件付きアクセスを提供することです。
• 読み取りアクセスの場合でも、サブスクリプションにアクセスできるユーザーとグループの定期的なレビューと監査を実施します。 外部 ID の招待を避けます。

要件 7.1.3

個々の職員の職階と職務権限に基づいてアクセス権を割り当てる。

お客様の責任

個人の明確に割り当てられた職務に基づいてアクセス許可を決定します。 システムや、従業員の在籍期間のようなパラメーターは避けます。 1 人のユーザーまたは 1 つのグループにアクセス権を付与します。

例をいくつか紹介します。

ジョブ分類	Role
製品の所有者は、ワークロードのスコープを定義し、機能に優先順位を付けます。 顧客のデータの保護および所有権と、ビジネスの目標のバランスを取ります。 レポート、コスト センター、または Azure ダッシュボードに対するアクセス権が必要です。 クラスター内またはクラスターレベルのアクセス許可に対するアクセス権は必要ありません。	アプリケーションの所有者
ソフトウェア エンジニアは、アプリケーション コードを設計し、開発し、コンテナー化します。 Azure 内の (Application Insights のような) 定義されたスコープ内で、またワークロードの名前空間内で継続的な読み取りアクセス許可を持つグループです。 これらのスコープとアクセス許可は、運用前環境と運用環境で異なる場合があります。	アプリケーション開発者
サイト信頼性エンジニアは、ライブサイトのトリアージを行い、パイプラインを管理し、アプリケーション インフラストラクチャをセットアップします。 グループ A は、割り当てられた名前空間内でフル コントロールを持ちます。 継続的なアクセス許可は必要ありません。 グループ B は、ワークロードに対する日常的な操作のためのものです。 割り当てられた名前空間内で継続的なアクセス許可を持つことはできますが、高度な特権は付与されません。	アプリケーション オペレーター
クラスター オペレーターは、信頼性の高い安全な AKS クラスターを設計し、プラットフォームにデプロイします。 クラスターのアップタイム維持の責任を負います。 グループ A は、割り当てられた名前空間内でフル コントロールを持ちます。 継続的なアクセス許可は必要ありません。 グループ B は、ワークロードに対する日常的な操作のためのものです。 割り当てられた名前空間内で継続的なアクセス許可を持つことはできますが、高度な特権は付与されません。	インフラストラクチャ オペレーター
ネットワーク エンジニアは、企業全体の仮想ネットワークとサブネットの割り当て、オンプレミスからクラウドへの接続、ネットワークのセキュリティを担当します。	インフラストラクチャ オペレーター

要件 7.1.4

必要な特権を指定している、認定された関係者による文書化された承認が必要。

お客様の責任

特権の初期割り当てなど、ロールとアクセス許可の変更を承認するためのゲート プロセスを用意します。 必ず、それらの承認を文書化して、検査に利用できるようにします。

要件 7.2

システム コンポーネントに対するユーザーのアクセスを、知る必要性に基づいて制限し、明確に許可されない限り、"すべて拒否" に設定したアクセス制御システムを確立する。

お客様の責任

要件 7.1 に従っていれば、組織とワークロードに当てはまるロールと責任の評価は済んでいるはずです。 アーキテクチャ内のコンポーネントで、スコープ内にあるものすべてに、制限付きのアクセスが付与されている必要があります。 これには、ワークロードを実行する AKS ノード、データ ストレージ、ネットワーク アクセス、および、カード所有者データ (CHD) の処理に関係するその他のすべてのサービスが含まれます。

ロールと責任に基づいて、インフラストラクチャのロールベースのアクセス制御 (RBAC) にロールを割り当てます。 使用できるメカニズムは次のとおりです。

• Kubernetes RBAC は、Kubernetes API サーバーを通じて公開される Kubernetes コントロール プレーンへのアクセスを制御する、ネイティブの Kubernetes 認可モデルです。 この一連のアクセス許可によって、API サーバーで実行できる操作が定義されます。 たとえば、ユーザーに対し、ポッドを作成または一覧表示するためのアクセス許可を拒否することができます。
• Azure RBAC は、Azure コントロール プレーンへのアクセスを制御する Microsoft Entra ID ベースの認可モデルです。 これは、Microsoft Entra テナントと Azure サブスクリプションの関連付けです。 Azure RBAC を使用して、ネットワーク、AKS クラスター、マネージド ID などの Azure リソースを作成するためのアクセス許可を付与することができます。

(インフラストラクチャ オペレーターのロールにマップされる) クラスター オペレーターにアクセス許可を付与する必要があるとします。 インフラストラクチャ オペレーターの責任を割り当てられたすべてのユーザーは Microsoft Entra グループに属します。 7\.1.1 で規定されているように、このロールにはクラスターにおける最も高度な特権が必要です。 Kubernetes には、これらの要件を満たす cluster-admin などの組み込み RBAC ロールがあります。 ロール バインドを作成して、インフラストラクチャ オペレーター用の Microsoft Entra グループを cluster-admin にバインドする必要があります。 処理方法は 2 つあります。 組み込みロールを選択できます。 または、(制限が緩すぎるなどの理由で) 組み込みロールが要件を満たさない場合、バインド用のカスタム ロールを作成します。

リファレンス実装では、ネイティブの Kubernetes RBAC を使用した前者の例を示しています。 Azure RBAC でも同じ関連付けを実現できます。 詳細については、Azure Kubernetes Service で Kubernetes のロールベースのアクセス制御と Microsoft Entra ID を使用してクラスター リソースへのアクセスを制限するに関する記事を参照してください。

アクセス許可のスコープは、クラスターレベルまたは名前空間レベルで選択できます。 アプリケーション オペレーターのように、スコープ付きの責任を持つロールの場合、アクセス許可はワークロードの名前空間レベルで割り当てられます。

さらに、ロールには、各自のタスクを実行できるようにするための Azure RBAC アクセス許可も必要です。 たとえば、クラスター オペレーターは、ポータルから Azure Monitor にアクセスする必要があります。 そのため、インフラストラクチャ オペレーターのロールには適切な RBAC 割り当てが必要です。

ユーザーとそのロールとは別に、Azure のリソースや、クラスター内のポッドにもマネージド ID があります。 これらの ID には、Azure RBAC を通じた一連のアクセス許可が必要であり、想定されるタスクに基づいて厳密にスコープを設定する必要があります。 たとえば、Azure Application Gateway には、Azure Key Vault からシークレット (TLS 証明書) を取得するためのアクセス許可が必要です。 シークレットを変更するためのアクセス許可を付与してはなりません。

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

• 個々のロールと、割り当てられたアクセス許可に関する詳細なドキュメントをメンテナンスします。 どのアクセス許可が JIT であり、どれが継続的であるかについての明確な区別を維持します。

• 割り当ての変更やロールの定義などの変更について、ロールを監視します。 変更の背景となる意図が自明であると予想される場合でも、変更に関するアラートを作成します。

要件 7.2.1

すべてのシステム コンポーネントが対象

お客様の責任

以下、アクセス制御の手段を維持するためのベスト プラクティスをいくつか示します。

• 持続的なアクセス権を排除します。 Just-In-Time AD グループ メンバーシップの使用を検討してください。 この機能には、Microsoft Entra Privileged Identity Management が必要です。

• クラスターの Microsoft Entra ID で条件付きアクセス ポリシーを設定します。 これにより、Kubernetes コントロール プレーンへのアクセスがさらに制限されます。 条件付きアクセス ポリシーを使用して、多要素認証を必須にしたり、Microsoft Entra テナントによって管理されているデバイスに認証を限定したり、異常なサインイン試行をブロックしたりできます。 これらのポリシーを、高度な特権を持つ Kubernetes ロールにマップされた Microsoft Entra グループに適用します。

  Note

  JIT と条件付きアクセスのどちらのテクノロジを選ぶ場合でも、Microsoft Entra ID P1 または P2 が必要です。

• クラスター ノードへの SSH アクセスを無効にするのが理想的です。 その目的のために、このリファレンス実装では SSH 接続の詳細を生成しません。

• ジャンプ ボックスなどの追加のコンピューティングには、許可されているユーザーがアクセスする必要があります。 チーム全体で利用できる汎用ログインを作成しないでください。

要件 7.2.2

職階と職務権限に基づく個人に対する特権の割り当て。

お客様の責任

7\.1.3 で規定されているように、クラスターの運用には多くのロールが関係します。 標準的な Azure リソースのロールに加えて、アクセスの範囲とプロセスを定義する必要があります。

たとえば、クラスター オペレーターのロールを考えます。 このロールには、クラスターのトリアージ アクティビティのための明確に定義されたプレイブックが必要です。 ワークロード チームからのアクセスにはどのような違いがあるでしょうか。 組織によっては、これらが同じである場合もあります。 考慮すべき点をいくつか以下に示します。

• どのような方法でクラスターにアクセスするべきか
• どのソースがアクセスを許可されているか
• クラスターに対するどのようなアクセス許可を付与すべきか
• これらのアクセス許可をいつ割り当てるのか

これらの定義が、ワークロード オペレーターとクラスター オペレーターに関するガバナンス ドキュメント、ポリシー、トレーニング資料に記載されていることを確認します。

要件 7.2.3

"すべて拒否" という既定の設定。

お客様の責任

構成を始めるときは、ゼロトラスト ポリシーを出発点にします。 必要に応じて例外を設け、詳細に文書化します。

• Kubernetes RBAC では、既定で "すべて拒否" を実装します。 "すべて拒否" 設定の逆を行く、許容度の高いクラスター ロール バインドを追加してこれを覆さないでください。

• Azure RBAC でも、既定で "すべて拒否" を実装します。 "すべて拒否" 設定の逆を行く RBAC 割り当てを追加してこれを覆さないでください。

• すべての Azure サービス、Azure Key Vault、および Azure Container Registry では、"すべて拒否" のアクセス許可のセットが既定になっています。

• ジャンプ ボックスなどの管理アクセス ポイントでは、初期構成ですべてのアクセスを拒否する必要があります。 昇格したすべてのアクセス許可は、"すべて拒否" ルールになるよう明示的に定義する必要があります。

要件 7.3

カード所有者データへのアクセスを制限するためのセキュリティ ポリシーと運用手順を文書化し、使用し、すべての関係者に通知する。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 これには、Azure および Kubernetes の RBAC ポリシーや、組織のガバナンス ポリシーが含まれます。 規制の対象となる環境の運用担当者に対し、セキュリティの保証をサポートするための教育を施し、情報を提供し、インセンティブを与える必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって特に重要です。

要件 8 — システム コンポーネントへのアクセスを識別して認証する

AKS 機能のサポート

AKS と Microsoft Entra の統合により、アクセス管理、ID オブジェクト管理などの ID 管理および認可機能を活用できます。 詳細については、AKS マネージド Microsoft Entra 統合に関する記事を参照してください。

お客様の責任

要件	担当
要件 8.1	すべてのシステム コンポーネントのコンシューマー以外のユーザーと管理者の適切なユーザー ID 管理を保証するためのポリシーと手順を次のように定義して実装する。
要件 8.2	一意の ID の割り当てに加え、少なくとも次の方法のいずれかを使用してすべてのユーザーを認証することで、すべてのシステム コンポーネントでのコンシューマー以外のユーザーと管理者のユーザー認証が適切に管理されることを保証する。
要件 8.3	CDE へのすべてのコンソール以外の管理アクセスとすべてのリモート アクセスを多要素認証を使用して保護する。
要件 8.4	以下を含む認証手順とポリシーを文書化し、すべてのユーザーに通知する。
要件 8.5	次のようにグループ ID、共有 ID、汎用 ID、パスワード、または他の認証方法を使用しない。
要件 8.6	他の認証メカニズム (物理的または論理的なセキュリティ トークン、スマート カード、証明書など) が使用されるところでは、これらのメカニズムの使用は次のように割り当てる必要がある。
要件 8.7	カード所有者データが格納されているデータベースへの (アプリケーション、管理者、およびその他すべてのユーザーによるアクセスを含む) すべてのアクセスは、次のように制限する。
要件 8.8	ID と認証に関するセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に通知されていることを保証する。

要件 8.1

すべてのシステム コンポーネントのコンシューマー以外のユーザーと管理者の適切なユーザー ID 管理を保証するためのポリシーと手順を次のように定義して実装する。

• 8.1.1 システム コンポーネントまたはカード所有者データへのアクセスを許可する前に、すべてのユーザーに一意の ID を割り当てる。
• 8.1.2 ユーザー ID、資格情報、およびその他の ID オブジェクトの追加、削除、および変更を制御する。
• 8.1.3 退職したユーザーのアクセス権をただちに取り消す。
• 8.1.4 非アクティブなユーザー アカウントは 90 日以内に削除するか無効にする。
• 8.1.5 サード パーティがリモート アクセス経由でシステムコンポーネントに対するアクセス、サポート、またはメンテナンスを行うために使用する ID を、次のように管理する。
  • 必要な期間中のみ有効にし、使用されていないときは無効にする。
  • 使用中は監視する。
• 8.1.6 6 回以下のアクセス試行でユーザー ID をロックアウトすることで、アクセス試行の繰り返しを制限する。
• 8.1.7 ロックアウト期間を最小値である 30 分、または管理者がユーザー ID を有効にするまでに設定する。
• 8.1.8 セッションが 15 分を越えてアイドル状態になった場合は、再認証を行って端末またはセッションを再アクティブ化するようにユーザーに要求する。

お客様の責任

この要件に関する全体的な考慮事項を次に示します。

適用対象: 8.1.1、8.1.2、8.1.3

機能的に異なる CDE の部分に対して ID を共有または再利用しないでください。 たとえば、チームのアカウントを使用してデータまたはクラスターのリソースにアクセスしないでください。 共有アカウントを使用しないことを ID に関するドキュメントに明記してください。

この ID プリンシパルを Azure におけるマネージド ID の割り当てに拡張します。 ユーザーが管理する ID を Azure リソース間で共有しないでください。 Azure リソースごとに、個別のマネージド ID を割り当ててください。 同様に、AKS クラスターで Microsoft Entra ワークロード ID を使用する場合は、スコープが広い ID を使用するのではなく、ワークロード内の各コンポーネントが独自の ID を付与されるようにしてください。 運用前と運用環境で同じマネージド ID を決して使い回さないでください。

Azure Kubernetes Service (AKS) でのアクセスと ID オプション

適用対象: 8.1.2、8.1.3、8.1.4

ID ストアとして Microsoft Entra ID を使用します。 クラスターとすべての Azure リソースは Microsoft Entra ID を使用するため、Microsoft Entra ID アクセスの無効化または取り消しは、すべてのリソースに自動的に適用されます。 Microsoft Entra ID によって直接サポートされていないコンポーネントがある場合は、アクセス権を削除するプロセスがあることを確認してください。 たとえば、ジャンプ ボックスにアクセスするための SSH 資格情報は、ユーザーが無効になったら明示的に削除することが必要な場合があります。

適用対象: 8.1.5

ベンダー、パートナーなどのサードパーティ アカウントをゲスト ユーザーとしてホストするように設計されている Microsoft Entra 企業間 (B2B) を利用します。 条件付きポリシーを使用して会社のデータを保護することで、適切なレベルのアクセス権を付与します。 これらのアカウントには、最小限の継続的なアクセス許可と、必須の有効期限を設定する必要があります。 詳細については、「Microsoft Entra B2B のゲスト ユーザー アクセスとは」を参照してください。

ベンダーによるアクセスやそれに類するアクセスのパターンを組織で明確化し、文書化する必要があります。

適用対象: 8.1.6、8.1.7、8.1.8

お客様の責任

Microsoft Entra ID では、サインイン試行が失敗した後にユーザーをロックアウトするためのスマート ロックアウト機能が用意されています。 ロックアウトを実装するための推奨方法は、Microsoft Entra 条件付きアクセス ポリシーを使用することです。

同様の機能をサポートしているが Microsoft Entra ID でサポートされていないコンポーネント (たとえば、ジャンプ ボックスなどの SSH 対応マシン) のロックアウトを実装します。 これにより、アクセス試行の悪用を阻止または足止めするためのロックアウトが有効であることが保証されます。

AKS ノードは、定期的にアクセスされるように設計されていません。 クラスター ノードへの直接 SSH またはリモート デスクトップをブロックします。 SSH アクセスは、高度なトラブルシューティング作業の一部としてのみ検討されるべきです。 アクセスを注意深く監視し、特定のイベントの完了後すぐに元に戻す必要があります。 これを行う場合、ノードレベルの変更によってクラスターがサポート対象外になる可能性があることに注意してください。

要件 8.2

一意の ID の割り当てに加え、少なくとも次の方法のいずれかを使用してすべてのユーザーを認証することで、すべてのシステム コンポーネントでのコンシューマー以外のユーザーと管理者のユーザー認証が適切に管理されることを保証する: パスワードやパスフレーズなどの既知の情報、トークン デバイスやスマート カードなどの所持品、生体認証などの本人確認手段。

• 8.2.1 強力な暗号化を使用して、転送中とすべてのシステム コンポーネントでの格納中にすべての認証資格情報 (パスワードやパスフレーズなど) を読み取り不可にする。
• 8.2.2 パスワードのリセットの実行、新しいトークンのプロビジョニング、新しいキーの生成などの認証資格情報の変更を行う前にユーザー ID を確認する。
• 8.2.3 パスワード/フレーズは、次の要件を満たしている必要がある。
  • 少なくとも 7 文字の長さがある。
  • 数字と英文字の両方が含まれている。
• 8.2.4 少なくとも 90 日ごとに 1 回はユーザーのパスワード/パスフレーズを変更する。
• 8.2.5 最近使用した 4 つのパスワード/フレーズのいずれかと同じ新しいパスワード/フレーズの送信を個人に許可しない。
• 8.2.6 各ユーザーの初回の使用時と一意の値へのリセット時に使用されるパスワード/フレーズを設定し、初回の使用直後に変更する。

お客様の責任

クラスターの Microsoft Entra ID で条件付きアクセス ポリシーを設定します。 これにより、Kubernetes コントロール プレーンへのアクセスがさらに制限されます。

前出の一連の要件のいくつかは、Microsoft Entra ID によって自動的に処理されます。 次に例をいくつか示します。

• パスワード セキュリティ

  Microsoft Entra ID には、強力なパスワードの使用を強制する機能が用意されています。 たとえば、グローバル禁止パスワードの一覧に含まれる脆弱なパスワードはブロックされます。 これは十分な保護ではありません。 Microsoft Entra パスワード保護機能を追加して、組織固有の禁止リストを作成することを検討してください。 パスワード ポリシーは既定で適用されます。 ポリシーの中には、変更ができず、前出の一連の要件の一部に対応するものがあります。 これには、パスワードの有効期限や、使用できる文字が含まれます。 完全なリストについては、「Microsoft Entra パスワード ポリシー」を参照してください。 条件付きアクセス ポリシーで適用できる高度な機能の使用を検討してください。たとえば、ユーザー リスクに基づいて、漏洩したユーザー名とパスワードのペアを検出する機能などです。 詳細については、「条件付きアクセス: ユーザー リスクベースの条件付きアクセス」を参照してください。

  注意

  パスワードレスのオプションを検討することを強くお勧めします。 詳細情報については、「Microsoft Entra ID でのパスワードレス認証のデプロイを計画する」を参照してください。

• ユーザー本人確認

  サインイン リスクの条件付きアクセス ポリシーを適用して、認証要求が要求元の ID によって発行されたかどうかを検出できます。 脅威インテリジェンスのソースに照らして要求が検証されます。 これには、パスワード スプレーや IP アドレスの異常が含まれます。 詳細については、「条件付きアクセス: サインイン リスクベースの条件付きアクセス」を参照してください。

SSH を使用したジャンプ ボックスへのアクセスなど、Microsoft Entra ID を使用しないコンポーネントが存在する場合があります。 そのような場合は、少なくとも RSA 2048 のキー サイズの公開キー暗号化を使用します。 常にパスフレーズを指定します。 既知の承認済み公開キーを追跡する検証プロセスを用意します。 公開キー アクセスを使用するシステムは、インターネットに公開してはなりません。 代わりに、秘密キーの漏洩の影響を軽減するために、すべての SSH アクセスは Azure Bastion などの中継局を通じて許可する必要があります。 直接パスワード アクセスを無効にし、代替のパスワードレス ソリューションを使用します。

要件 8.3

CDE へのすべてのコンソール以外の管理アクセスとすべてのリモート アクセスを多要素認証を使用して保護する。 注: 多要素認証では、3 つの認証方法のうちの少なくとも 2 つを使用して認証する必要があります (認証方法については、要件 8.2 の説明を参照してください)。 1 つの要素を 2 回使用する (たとえば、異なる 2 つのパスワードを使用する) 方法は 多要素認証とみなされません。

お客様の責任

特に管理者アカウントについて、条件付きアクセス ポリシーを使用して多要素認証を施行します。 これらのポリシーは、いくつかの組み込みロールで推奨されます。 これらのポリシーを、高度な特権を持つ Kubernetes ロールにマップされた Microsoft Entra グループに適用します。

追加のポリシーによって、このポリシーをさらに強化することができます。 次に例をいくつか示します。

• Microsoft Entra テナントによって管理されているデバイスに認証を限定することができます。
• クラスター ネットワークの外部のネットワークからアクセスが発生している場合、多要素認証を施行できます。

詳細については、次を参照してください。

• 条件付きアクセス:管理者に対して MFA を必須にする
• 方法:条件付きアクセスを使用してクラウド アプリへのアクセスにマネージド デバイスを要求する
• 方法:条件付きアクセスを使用して信頼されていないネットワークからのアクセスに対して MFA を必須にする

要件 8.4

以下を含む認証手順とポリシーを文書化し、すべてのユーザーに通知する。

• 強力な認証資格情報の選択に関するガイダンス
• ユーザーが自分の認証資格情報を保護する方法に関するガイダンス
• 前に使用したことがあるパスワードを再利用しないことの指示
• パスワードが漏れた疑いがある場合は、パスワードを変更することの指示。

お客様の責任

適用されるポリシーに関するドキュメントを保守します。 ID オンボード トレーニングの一環として、パスワードのリセット手順や、アセットの保護に関する組織のベスト プラクティスのガイダンスを提供します。

要件 8.5

次のようにグループ ID、共有 ID、汎用 ID、パスワード、または他の認証方法を使用しない。

• 汎用ユーザー ID を無効にするか削除する。
• システム管理およびその他の重要な機能用の共有ユーザー ID が存在しない。
• システム コンポーネントの管理で共有ユーザー ID と汎用ユーザー ID を使用しない。

お客様の責任

機能的に異なるクラスターまたはポッドの部分に対して ID を共有または再利用しないでください。 たとえば、チームのアカウントを使用してデータまたはクラスターのリソースにアクセスしないでください。 共有アカウントを使用しないことを ID に関するドキュメントに明記してください。

CDE でルート ユーザーを無効にします。 ユーザーが CDE 内のクラスターへの組み込み --admin アクセスを使用できないように、Kubernetes ローカル アカウントの使用を無効にします。

要件 8.6

他の認証メカニズム (物理的または論理的なセキュリティ トークン、スマート カード、証明書など) が使用されるところでは、これらのメカニズムの使用は次のように割り当てる必要がある。

• 認証メカニズムは、個人アカウントに割り当る必要があり、複数のアカウント間で共有してはならない。
• 物理/論理コントロールを配置して、目的のアカウントのみがそのメカニズムを使用してアクセスできることを保証する必要ある。

お客様の責任

CDE へのすべてのアクセスがユーザーごとの ID で提供されていることを確認します。これは、すべての物理または仮想トークンに拡張されます。 これには、CDE ネットワークへのすべての VPN アクセスが含まれ、エンタープライズ ポイントツーサイト アクセス (存在する場合) で、その認証フローの一部としてユーザーごとの証明書を使用することを保証します。

要件 8.7

カード所有者データが格納されているデータベースへの (アプリケーション、管理者、およびその他すべてのユーザーによるアクセスを含む) すべてのアクセスは、次のように制限する。

• データベースに対するすべてのユーザー のアクセス、クエリ、アクションは、プログラム的な方法で実行される。
• データベースに対する直接的なアクセスやクエリは、データベース管理者だけが実行できる。
• データベース アプリケーションのアプリケーション ID は、アプリケーションのみが使用できる (個人ユーザーやその他のアプリケーション以外のプロセスは使用できません)。

お客様の責任

ロールと責任に基づいてアクセスを提供します。 ユーザーは自分の ID を使用できますが、アクセスには "知る必要性" に基づいて制限を設け、継続的なアクセス許可は最小限にする必要があります。 ユーザーがアプリケーション ID を使用してはなりません。また、データベース アクセス ID を共有してはなりません。

可能であれば、マネージド ID を使用してアプリケーションからデータベースにアクセスします。 不可能な場合は、接続文字列と資格情報の露出を制限します。 機密情報は、ポッド定義のような見つかりやすい場所に保存する代わりに、Kubernetes シークレットを使用して保存します。 もう 1 つの方法は、Azure Key Vault などのマネージド ストアにシークレットを格納し、そこから読み込むことです。 AKS クラスターでマネージド ID が有効な場合、この ID がアクセス権を得るためには、Key Vault と照合して自身を認証する必要があります。

要件 8.8

ID と認証に関するセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に通知されていることを保証する。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 適用されるポリシーに関するドキュメントを保守します。 ID オンボード トレーニングの一環として、パスワードのリセット手順や、アセットの保護に関する組織のベスト プラクティスのガイダンスを提供します。 規制の対象となる環境の運用担当者に対し、セキュリティの保証をサポートするための教育を施し、情報を提供し、インセンティブを与える必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって特に重要です。

要件 9 — カード所有者データへの物理的なアクセスを制限する

AKS 機能のサポート

この要件に該当する AKS 機能はありません。

お客様の責任

このアーキテクチャと実装は、オンプレミスのリソースまたはデータセンターへの物理的なアクセスに対する制御を提供するために設計されたものではありません。 考慮事項については、公式の PCI DSS 3.2.1 標準のガイダンスを参照してください。

以下、技術的な制御を適用するための提案事項をいくつか示します。

• CDE のジャンプ ボックスなど、管理コンソールへのアクセスでは、アクセスを最小限にするためにセッション タイムアウトを調整します。

• Azure portal などのアクセス ポイントからの Azure アクセス トークンで TTL が最小になるように条件付きアクセス ポリシーを調整します。 詳細については、以下の記事を参照してください。

  • 条件付きアクセスを使用して認証セッション管理を構成する
  • 構成可能なトークンの有効期間 - Microsoft ID プラットフォーム

• クラウドでホストされる CDE の場合、物理アクセスとハードウェアの管理責任はありません。 企業ネットワークの物理的および論理的な制御に依存します。

• オンプレミスの送信先への CHD バックアップのエクスポートを最小限にします。 Azure でホストされるソリューションを使用して、バックアップへの物理アクセスを制限します。

• オンプレミスへのバックアップを最小限にします。 これが必要な場合、オンプレミスの送信先が監査の対象になることに注意してください。

次のステップ

ネットワーク リソースとカード所有者のデータへのすべてのアクセスを追跡して監視します。 セキュリティ システムとプロセスを定期的にテストします。