PCI-DSS 3.2.1 の AKS 規制クラスターのアーキテクチャ (パート 2/9)

Azure Kubernetes Service (AKS)

Azure Firewall

Azure Application Gateway

Microsoft Defender for Cloud

Azure Monitor

この記事では、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) に準拠してワークロードを実行する Azure Kubernetes Service (AKS) クラスターのリファレンスアーキテクチャについて説明します。このアーキテクチャは、PCI-DSS 3.2.1 ワークロード "ではなく" インフラストラクチャに重点を置いています。

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

推奨事項と例は、以下のリファレンス実装から抜粋されています。

GitHub logo. GitHub: 規制対象ワークロード向け Azure Kubernetes Service (AKS) ベースラインクラスターは、規制されたインフラストラクチャを表しています。この実装は、マイクロサービスアプリケーションを提供します。これは、このインフラストラクチャを体験し、ネットワークとセキュリティのコントロールを解説するために含まれています。このアプリケーションは、実際の PCI DSS ワークロードを表現したり、実装したりしているわけでは "ありません"。

このアーキテクチャの Visio ファイルをダウンロードします。

このネットワークアーキテクチャはハブスポークトポロジに基づいています。ハブ仮想ネットワークには、エグレストラフィック、オンプレミスのネットワークからのゲートウェイトラフィック、および SRE (サイト信頼性エンジニア) クラスタアクセス用の 3 つ目のネットワークを制御するファイアウォールが含まれています。 2 つのスポーク仮想ネットワークがあります。 1 つのスポークには、カードホルダー環境 (CDE) のコンポーネントである AKS クラスターが含まれており、PCI DSS ワークロードをホストします。もう 1 つのスポークは、環境への制御された SRE アクセスに使用される仮想マシンイメージをビルドします。

重要

アーキテクチャと実装は、AKS ベースラインアーキテクチャに基づいています。この記事を最大限に活用するために、ベースラインコンポーネントを確認しておいてください。このセクションでは、2 つのアーキテクチャの違いについて説明します。

Components

このアーキテクチャで使用される主なコンポーネントを次に示します。これらのサービスについて十分に理解していない場合は、「関連する Azure サービス」にある製品ドキュメントへのリンクを参照してください。

Azure Firewall

そのファイアウォールのインスタンスでは、送信ネットワークトラフィックがセキュリティで保護されます。このセキュリティレイヤーがないと、フローと悪意のあるサードパーティサービスが通信することで、会社の機密データが抜き取られる可能性があります。

Azure Bastion

ベースラインアーキテクチャでは Azure Bastion のサブネットが提供されますが、リソースのプロビジョニングは行われていません。このアーキテクチャでは、サブネットに Azure Bastion が追加され、ジャンプボックスへの安全なアクセスが提供されます。

Azure Image Builder

別の仮想ネットワークにプロビジョニングされ、基本セキュリティと構成を使用して VM イメージが作成されます。このアーキテクチャでは、プレインストールされている Azure CLI、kubectl、Flux CLI などの管理ツールを使用して、セキュリティで保護されたノードイメージをビルドするためにカスタマイズされています。

ジャンプボックスインスタンスの Azure Virtual Machine Scale Sets

スポークネットワークには、ジャンプボックス用の追加のコンピューティングがあります。このスケールセットは、AKS クラスターに対し必要に応じて kubectl などのツールを実行するための管理対象アクセスポイントとなることが想定されています。

Web Application Firewall (WAF) が統合された Azure Application Gateway

Azure Application Gateway はレイヤー 7 で負荷分散を行います。 WAF によって、一般的な Web トラフィック攻撃から着信トラフィックが保護されます。インスタンスには、ユーザー要求を受信するパブリックフロントエンド IP 構成が使用されています。

Azure Kubernetes Service (AKS)

カード所有者データ環境 (CDE) の重要な部分であるホスティングインフラストラクチャ。 AKS クラスターはプライベートクラスターとしてデプロイされます。そのため、Kubernetes API サーバーはパブリックインターネットに公開されず、API サーバーへのトラフィックはプライベートネットワークに制限されます。

ACR タスク

コンテナーイメージのビルドと保守の自動化を提供します。

Azure Key Vault

証明書や暗号化キーなど、クラスター操作に必要なシークレットを格納および管理します。

クラスター構成

ベースラインアーキテクチャからの重要な変更点を次に示します。

ノードプールのセグメント化

このアーキテクチャでは、クラスターに 2 つのユーザーノードプールと 1 つのシステムノードプールがあります。ノードプールのコンピューティングの選択は変わりません。各ノードプールは専用サブネットに存在し、コンピューティング層の間にネットワーク分離境界を追加します。

注意

コンピューティング保護のためのもう 1 つのアプローチとして、Azure Confidential Computing があります。 AKS ではコンフィデンシャルコンピューティングノードがサポートされており、これによりハードウェアベースの高信頼実行環境 (TEE: Trusted Execution Environment) 内で機密性の高いワークロードを実行できます。詳細については、「Azure Kubernetes Service 上のコンフィデンシャルコンピューティングノード」を参照してください。

PCI-DSS 3.2.1 では操作と接続の点から、PCI ワークロードを他のワークロードから分離する必要があります。

対象範囲内: PCI ワークロード、それが存在する環境、および操作。
対象範囲外: サービスを共有する可能性があるが、対象範囲内のコンポーネントから分離されているその他のワークロード。

重要な方針として、必要な分離レベルを提供することがあります。推奨される方法は、対象範囲内のコンポーネントと対象範囲外のコンポーネントをそれぞれ別々のクラスターにデプロイすることです。この方法の短所は、インフラストラクチャの追加とメンテナンスオーバーヘッドに伴いコストが増加することです。わかりやすくするために、この実装ではすべてのコンポーネントが共有クラスターに配置されています。このモデルに従う場合は、厳密なクラスター内セグメント化方針を採用してください。分離を維持する方法に関係なく、ソリューションの進化に伴って対象範囲外コンポーネントの一部が対象範囲内になる可能性があることに注意してください。

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

イングレスコントローラー

クラスター内部の Kubernetes イングレスコントローラーが NGINX に変更されました。ベースラインアーキテクチャでは Traefik が使用されていました。この変更は、ワークロードの要件に基づいてこのコンポーネントを変更できることを示しています。

プライベート Kubernetes API サーバー

ベースラインアーキテクチャでは、AKS クラスターがパブリックモードでデプロイされていました。つまり、AKS により管理されている Kubernetes API サーバーとの通信はすべて、パブリックインターネットを経由します。 PCI-DSS 3.2.1 ではシステムコンポーネントの公開が禁止されているため、このアーキテクチャではこれは許容されません。この規制対象アーキテクチャでは、クラスターはプライベートクラスターとしてデプロイされます。 Kubernetes API サーバーへのネットワークトラフィックは、プライベートネットワークに制限されます。 API サーバーは、クラスターのネットワーク内のプライベートエンドポイントを介して公開されます。ネットワークセキュリティグループやその他の組み込み機能を使用すると、セキュリティがさらに強化されます。詳細については、「ネットワーク構成」を参照してください。

ポッドのセキュリティ

ワークロードのセキュリティニーズを説明する際には、コンテナーに関連する securityContext 設定を使用します。これには、fsGroup、runAsUser / runAsGroup などの基本設定と、allowPrivilegeEscalation を false に設定すること (必須の場合を除く) などがあります。 Linux 機能の定義と削除、およびseLinuxOptions での SELinux オプションの定義について明確にします。

配置マニフェストでタグを使ってイメージを参照しないようにします。代わりに、実際のイメージ ID を使用します。このようにすることで、コンテナースキャンの結果を、クラスターで実行されている実際のコンテンツに確実にマップできます。これを実施するために、Azure Policy でイメージ名に、許可される正規表現でイメージ ID パターンを含めることができます。 Dockerfile FROM 命令を使用する場合にもこのガイダンスに従ってください。

ネットワーク構成

ハブスポークはすべて、個別の仮想ネットワークにデプロイされ、それぞれがプライベートアドレス空間に含まれます。既定では、2 つの仮想ネットワーク間のトラフィックは一切許可されていません。ネットワーク内では、サブネットを作成することでセグメント化が適用されます。

さまざまな Azure サービスおよび機能とネイティブ Kubernetes コンストラクトの組み合わせによって、必要なレベルの制御が実現します。このアーキテクチャで使用されているいくつかのオプションを次に示します。

ネットワークセキュリティグループ (NSG) によるサブネットのセキュリティ

クラスター内外のフローを制御する NSG がいくつかあります。次に例をいくつか示します。

クラスターノードプールは専用サブネットに配置されます。各サブネットには、ノード VM への SSH アクセスをブロックし、仮想ネットワークからのトラフィックを許可する NSG があります。ノードプールからのトラフィックは、仮想ネットワークに制限されます。
インターネットからのすべての受信トラフィックは Azure Application Gateway によって傍受されます。たとえば NSG ルールでは次のように規定されています。
- HTTPS トラフィックのみが許可されます。
- Azure コントロールプレーンからのトラフィックは許可されます。詳細については、「いくつかのソース IP へのアクセスを許可する」を参照してください。
Azure Container Registry エージェントが存在するサブネットでは、NSG により必要な送信トラフィックのみが許可されます。たとえば、Azure Key Vault、Microsoft Entra ID、Azure Monitor、およびコンテナーレジストリが通信する必要があるその他のサービスに対してトラフィックが許可されます。
ジャンプボックスがあるサブネットは管理操作用です。 NSG ルールでは、ハブ内の Azure Bastion からの SSH アクセスと、限られた発信接続のみが許可されます。ジャンプボックスにはユニバーサルインターネットアクセスがなく、サブネット NSG と Azure Firewall の両方で制御されます。

ワークロード、システムセキュリティエージェント、およびその他のコンポーネントをデプロイするときに、許可する必要があるトラフィックの種類を定義するのに役立つ NSG ルールをさらに追加します。トラフィックは、これらのサブネットの境界を通過してはなりません。各ノードプールは専用のサブネット内に存在するため、トラフィックパターンを観察し、さらに具体的なルールを適用してください。

ネットワークポリシーによるポッド間セキュリティ

このアーキテクチャでは、Microsoft の "ゼロトラスト" の原則の実装を可能な限り試みています。

概念としてのゼロトラストネットワークの例は、ユーザー指定の名前空間 a0005-i と a0005-o における実装に示されています。すべてのワークロード名前空間には制限的な NetworkPolicy が適用されている必要があります。ポリシー定義は、これらの名前空間で実行されているポッドによって異なります。 readiness、liveliness、startup の各プローブと、Log Analytics エージェントにより収集されるメトリックの許可を必ず考慮してください。許可されているコンテナーポートに一貫性のある NetworkPolicy と Azure Policy を提供できるように、ワークロード全体でポートを標準化することを検討してください。

場合によっては、これはクラスター内の通信には現実的ではありません。ユーザー指定の名前空間の中には、ゼロトラストネットワークを使用できないものがあります (たとえば cluster-baseline-settings では使用できません)。

TLS 暗号化

ベースラインアーキテクチャでは、クラスター内のイングレスコントローラーまでのトラフィックは TLS で暗号化されますが、ポッド間通信は暗号化されません。このアーキテクチャでは、証明機関 (CA) の検証を使用して TLS がポッド間トラフィックまで拡張されます。その TLS はサービスメッシュによって提供され、通信を許可する前に mTLS 接続と検証が強制的に実施されます。

Diagram of the network configuration.

この実装では mTLS が使用されています。 mTLS のサポートは、サービスメッシュの有無に関係なく実装できます。メッシュを使用する場合は、選択した証明書の発行者と互換性があることを確認します。この実装では Open Service Mesh が使用されています。

この実装のイングレスコントローラーは、イングレスリソースに特定の証明書が含まれていない場合に、ワイルドカード証明書を使用して既定のトラフィックを処理します。これは許容される可能性がありますが、組織方針でワイルドカード証明書の使用が許可されていない場合は、ワイルドカード証明書を使用しないようにイングレスコントローラーを調整する必要が生じる可能性があります。

重要

カード所有者データを復号化するすべてのコンポーネントは、PCI DSS 3.2.1 の対象範囲内であると見なされ、カード所有者データ環境のその他のコンポーネントと同じレベルの審査が適用されます。このアーキテクチャでは、Azure Application Gateway は WAF 機能の一部としてペイロードを検査するため、対象範囲内です。代替アーキテクチャオプションとして、WAF ではなく Azure Firewall Premium をイングレスコンポーネントとして使用し、Azure Firewall の署名ベースの IDPS 機能を利用する方法があります。これにより、最初の TLS 終端をクラスターに含めることができます。ただし、専用の WAF を使用しない場合は、追加の補正コントロールを使用して要件 6.6 を満たす必要があります。

Azure Key Vault ネットワークの制限

すべてのシークレット、キー、および証明書は Azure Key Vault に格納されます。 Key Vault により、ローテーションなどの証明書管理タスクが処理されます。 Key Vault との通信は、Azure Private Link 経由で行われます。 Key Vault に関連付けられている DNS レコードはプライベート DNS ゾーンにあるため、インターネットからは解決できないようになっています。これによってセキュリティが強化されますが、いくつかの制限があります。

Azure Application Gateway では、Private Link を使用して公開されている Key Vault インスタンスから HTTP リスナー用の TLS 証明書を取得することはサポートされていません。そのため、実装では Key Vault がハイブリッドモデルにデプロイされます。 Private Link をサポートする接続には引き続き Private Link が使用されますが、Application Gateway 統合のパブリックアクセスも許可されます。このハイブリッド方式がデプロイに適していない場合は、証明書管理プロセスを Application Gateway に移動します。これにより管理オーバーヘッドが増加しますが、Key Vault インスタンスは完全に分離されます。詳しくは次の記事をご覧ください:

DDoS 保護

パブリック IP を持つ Application Gateway が含まれているサブネットが属する仮想ネットワークに対して、Azure DDoS ネットワーク保護を有効にします。これにより、大量の不正な要求からインフラストラクチャとワークロードが保護されます。このような要求によって、サービスが中断したり、別の同時攻撃が隠ぺいされたりする可能性があります。 Azure DDoS にはかなりのコストがかかりますが、通常は多数の IP アドレスをまたがる多くのワークロードにわたって償却されます。ネットワークチームと協力して、ワークロードの対象範囲を調整してください。

ID アクセス管理

ロールを定義し、そのロールの要件に従ってアクセスの制御を設定します。可能な限り狭い範囲内の Kubernetes アクションにそのロールをマップします。複数の職務にまたがるロールは避けてください。 1 人のユーザーが複数のロールを担当する場合は、同等の職務に関連するすべてのロールをそのユーザーに割り当ててください。そのため、1 人のユーザーがクラスターとワークロードの両方を直接担当する場合でも、個々のユーザーがいる場合と同様に Kubernetes ClusterRoles を作成してください。その後、1 人のユーザーに関連ロールをすべて割り当てます。

特に、影響の大きいアカウントの継続的なアクセス (SRE/Ops によるクラスターの操作など) を最小限に抑えます。 AKS コントロールプレーンでは、 Microsoft Entra ID Privileged Access Management (PAM) Just-In-Time (JIT) と条件付きアクセスポリシーの両方がサポートされています。これにより、ビルドした規則に基づいて、特権化したアクセスに必要な認証検証の追加レイヤーが提供されます。

PowerShell を使用して条件付きアクセスを構成する方法の詳細については、「New-MgIdentityConditionalAccessPolicy」、「Get-MgIdentityConditionalAccessPolicy」、および「Remove-MgIdentityConditionalAccessPolicy」を参照してください。

ディスクの暗号化

保存データの暗号化を設計するときには、ストレージディスク、AKS エージェントノードの VM、その他の VM、および一時ディスクとオペレーティングシステムディスクを考慮してください。

ストレージディスク

既定では、Azure Storage ディスクは保存時には Microsoft マネージドキーで暗号化されます。エフェメラルではないオペレーティングシステムディスクを使用する場合、またはデータディスクを追加する場合は、暗号化キーの制御にカスタマーマネージドキーを使用することをお勧めします。ストレージレイヤー外部で暗号化し、暗号化されたデータのみをストレージメディアに書き込みます。また、キーがストレージレイヤーに隣接していないようにしてください。

詳細については、Azure ディスクでの Bring Your Own Key (BYOK) の使用に関する記事を参照してください。

Azure Bastion で保護されたジャンプボックスなど、クラスターと対話する可能性のあるその他のすべてのディスクには、BYOK を使用することを検討してください。 BYOK を使用する場合、一部の SKU やリージョンではこの機能はサポートされていないため、VM の SKU の選択肢と利用可能なリージョンが制限されます。

VM ホスト

ホストでの暗号化機能を有効にすることをお勧めします。これにより、VM ホストと、VM ホストにキャッシュされているすべての一時オペレーティングシステムまたはデータディスクが暗号化されます。詳細については、ホストベースの暗号化の VM サポートに関する記事を参照してください。

この機能は、ホストベースの暗号化機能を使用して、AKS エージェントノードの VM ホストに格納されているデータまで拡張されます。 BYOK と同様に、この機能により VM の SKU と利用可能なリージョンが制限される可能性があります。

これらの機能は Azure Policy によって適用できます。

クラスターのバックアップ (状態とリソース)

ワークロードにクラスター内ストレージが必要な場合は、堅牢で安全なバックアップと回復のプロセスを用意します。 PersistantVolumeClaim のバックアップと回復には、Azure Backup (Azure Disks および Azure Files の場合) などのサービスを検討してください。バックアップシステムでネイティブ Kubernetes リソースがサポートされている場合にはメリットがあります。重要なシステムの回復手法として、クラスターを既知の状態にするという主要な手法を、バックアップシステムで補完できます。たとえば、Kubernetes リソースレベルでの経時的なシステム状態の変化のカタログ化と、ドリフト検出で役立つ可能性があります。

バックアッププロセスでは、クラスター内外にあるバックアップのデータを分類する必要があります。データが PCI DSS 3.2.1 の対象範囲内である場合は、クラスター外部にあるバックアップのライフサイクルとバックアップ先を含むように、コンプライアンスの境界を拡張します。バックアップは攻撃ベクトルになる可能性があります。バックアップを設計する際には、地理的な制約、保存時の暗号化、アクセスの制御、ロールと責任、監査、有効期限、改ざん防止を考慮してください。

クラスター内バックアップシステムは、稼働時に高い特権で実行される必要があります。クラスターにバックアップエージェントを組み込むリスクと利点を評価します。エージェント機能がクラスター内の別の管理ソリューションと重複していますか? 攻撃対象領域を拡大せずにこのタスクを実行するために必要な最小限のツールセットは何ですか?

Azure Policy に関する考慮事項

通常、適用される Azure ポリシーには、ワークロードにより調整される設定はありません。この実装で適用する Kubernetes cluster pod security restricted standards for Linux-based workloads イニシアチブでは、設定の調整が許可されていません。このイニシアチブをエクスポートして、特定のワークロードに合わせて値をカスタマイズすることを検討してください。すべての Gatekeeper deny Azure ポリシーを 1 つのカスタムイニシアティブに含め、すべての audit Azure ポリシーを別のイニシアティブに含めることができます。これにより、情報のみのポリシーのブロックアクションが分類されます。

可視性を向上するため、kube-system および gatekeeper-system 名前空間を kube-system ポリシーに含めることを検討してください。これらの名前空間を deny ポリシーに含めると、サポートされていない構成が原因でクラスターでエラーが発生することがあります。

いくつかの Azure Policy アラートを設定することで、データ暗号化を適用できます。たとえば、クラスターリソースに diskEncryptionSetID がないクラスターを検出するアラートを使用して、BYOK を適用できます。別のポリシーでは、agentPoolProfiles でホストベースの暗号化が有効になっているかどうかを検出できます。リファレンス実装では、クラスター内のディスクは使用されません。またオペレーティングシステムディスクはエフェメラルです。この例のポリシーはいずれも、セキュリティ機能のリマインダーとして配置されています。ポリシーは block ではなく audit に設定されます。

イメージの管理

ワークロードにはディストリビューションレス基本イメージを使用します。これらのイメージを使用すると、シェルやパッケージマネージャーなどの補助イメージが削除されるため、セキュリティ上の外部からのアクセスが最小限に抑えられます。 CVE ヒット率が減少するというメリットがあります。

Azure Container Registry では、Open Container Initiative (OCI) イメージ形式の仕様に準拠するイメージをサポートしています。これと、署名の検証をサポートするアドミッションコントローラーとの組み合わせにより、秘密キーで署名したイメージのみを実行できるようになります。これらのプロセスを統合するオープンソースソリューション (SSE Connaissier や IBM Portieris など) があります。

コンテナーイメージとその他の OCI 成果物は、組織の知的財産を含んでいるため、保護してください。カスタマーマネージドキーを使用し、レジストリの内容を暗号化します。既定では、データは保存時にはサービスマネージドキーを使用して暗号化されますが、規制コンプライアンス標準を満たすには、カスタマーマネージドキーが必要となる場合があります。 Azure Key Vault などのマネージドキーストアにキーを格納します。キーを作成して所有するため、ローテーションや管理など、キーのライフサイクルに関連する操作の責任を負うことになります。詳細については、「カスタマーマネージドキーを使用してレジストリを暗号化する」を参照してください。

Kubernetes API Server 運用時のアクセス

ジャンプボックス周辺に基づく運用プロセスを必ずしも作成することなく、クラスターに対して実行されるコマンドを制限できます。 IAM ゲート IT オートメーションプラットフォームを使用している場合は、定義済みのアクションを使用して、アクションの種類を制御および監査します。

ビルドエージェント

ビルドプロセスは脅威ベクトルとなることがあるため、パイプラインエージェントは、規制対象クラスターの対象範囲外にする必要があります。 Kubernetes をエラスティックビルドエージェントインフラストラクチャとして使用するのは一般的ですが、規制対象ワークロードランタイムの境界内でそのプロセスを実行しないでください。ビルドエージェントに、クラスターを直接アクセスさせないでください。たとえばビルドエージェントには、コンテナーイメージや Helm chart などをプッシュするために Azure Container Registry へのネットワークアクセス権のみを付与します。次に、GitOps を使用してデプロイします。一般的なプラクティスとして、ビルドとリリースのワークフローは、Kubernetes Cluster API (またはそのノード) に直接アクセスしてはなりません。

操作の監視

クラスター内アクティビティ

kube-system で実行されているクラスター内 omsagent ポッドは、Log Analytics 収集エージェントです。テレメトリの収集、コンテナー stdoutと stderr のログのスクレイピング、Prometheus メトリックの収集を行います。その収集設定を調整するには container-azm-ms-agentconfig.yaml ConfigMap ファイルを更新します。このリファレンス実装では、kube-system 全体とすべてのワークロードでログが有効になっています。既定では、kube-system はログから除外されます。ログ収集プロセスを調整して、コスト目標、ログを確認する際の SRE 効率、およびコンプライアンスニーズの間のバランスを取る必要があります。

セキュリティの監視

Microsoft Defender for Cloud の Defender for Containers を使用して、セキュリティに関する推奨事項を表示および修復し、コンテナーリソースに対するセキュリティアラートを表示します。 Microsoft Defender プランを有効にします。これらのプランは、カード所有者データ環境のさまざまなコンポーネントに適用されます。

データの確認、分析、クエリを効率的に実行できるようにするため、ログを統合します。 Azure には、いくつかのオプションが用意されています。 AKS 診断ログを有効にして、 Azure Monitor の一部である Log Analytics ワークスペースに送信できます。もう 1 つのオプションは、Microsoft Sentinel などのセキュリティ情報とイベント管理 (SIEM) ソリューションにデータを統合することです。

標準で定められているように、すべての Log Analytics ワークスペースには 90 日間の保持期間が設定されます。長期保管用に連続エクスポートを設定することを検討してください。機密情報をログデータに保存しないでください。また、アーカイブされたログデータへのアクセスが、最近のログデータと同じレベルのアクセス制御の対象になっていることを確認してください。

完全な観点については、「Microsoft Defender for Cloud Enterprise オンボードガイド」を参照してください。このガイドでは、登録、SIEM ソリューションへのデータエクスポート、アラートへの応答、ワークフロー自動化の構築について説明しています。

このアーキテクチャの主要コンポーネントの機能に関するドキュメントへのリンクを次に示します。

次の手順

カード所有者データを保護するファイアウォール構成をインストールして管理すること。システムのパスワードとその他のセキュリティパラメーターで、ベンダー提供の既定値を使用しなでください。

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

PCI-DSS 3.2.1 の AKS 規制クラスターのアーキテクチャ (パート 2/9)

Components