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 ID を使用すると、閲覧者、ライター、サービス管理者、クラスター管理者などのさまざまな組み込みロールを使用できます。 よりきめ細かな制御のためにカスタム ロールを作成することもできます。

デフォルトでは、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 を構成および管理します。
• サーバー セキュリティ、修正プログラムの適用、構成、およびエンドポイントのセキュリティの監視と修復。
• Azure リソースを管理するための RBAC、Microsoft Defender for Cloud、管理者保護戦略、および Azure Policy の使用に関する方向性を設定します。
• インシデントの監視および対応チームを特定します。 Microsoft Sentinel や Microsoft Defender for Cloud などのセキュリティ情報およびイベント管理 (SIEM) システムを使用して、セキュリティ インシデントを調査し、修復します。

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

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 Key Vault や Azure Container Registry を含むすべての Azure サービスは、既定ですべてのアクセス許可を拒否します。

• ジャンプ ボックスなどの管理アクセス ポイントでは、初期構成ですべてのアクセスを拒否する必要があります。 すべての拒否ルールを上書きするには、すべての昇格された権限を明示的に定義する必要があります。

要件 7.3

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

お客様の責任

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

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

AKS 機能のサポート

AKS と Microsoft Entra の統合により、アクセス管理、識別子オブジェクト管理などの 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 の割り当てに拡張します。 Azure リソース間でユーザー管理 ID を共有しないでください。 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 によって直接サポートされていないコンポーネントがある場合は、アクセスを削除するプロセスがあることを確認してください。 たとえば、ユーザーが有効でなくなった場合は、ジャンプ ボックスにアクセスするための SSH 資格情報を明示的に削除する必要がある場合があります。

適用対象: 8.1.5

ベンダーやパートナーなどのサードパーティの企業間取引 (B2B) アカウントをゲスト ユーザーとしてホストするように設計された Microsoft Entra 外部 ID を活用します。 条件付きポリシーを使用して会社のデータを保護することで、適切なレベルのアクセス権を付与します。 これらのアカウントには、最小限の継続的なアクセス許可と、必須の有効期限を設定する必要があります。 詳細については、「従業員向けの外部ゲストとの 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 を要求する
• 条件付きアクセス: 準拠デバイスが必要
• 条件付きアクセス: サインインリスクベースの多要素認証

要件 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 でホストされるソリューションを使用して、バックアップへの物理アクセスを制限します。

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

次のステップ

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