PCI-DSS 3.2.1 の AKS 規制クラスターでデータをセキュリティで保護する (パート 4/9)

この記事では、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) に準拠してワークロードを実行する Azure Kubernetes Service (AKS) クラスターの考慮事項について説明します。

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

このアーキテクチャと実装は、ワークロードではなくインフラストラクチャに重点を置いています。 この記事では、設計上の意思決定に役立つ一般的な考慮事項とベスト プラクティスについて説明します。 公式の PCI-DSS 3.2.1 標準の要件に従い、該当する場合にこの記事を追加情報として使用してください。

カード所有者のデータを保護する

要件 3 — 格納されているカード所有者データを保護する

お客様の責任

要件	担当
要件 3.1	すべてのカード所有者データ (CHD) の保存について少なくとも以下のものを含むデータ保持および廃棄のポリシー、手順、プロセスを実装することで、保存するカード所有者データを最小限に抑える。
要件 3.2	承認後の機密認証データを保存しない (暗号化されている場合でも)。 機密認証データを受け取った場合、認証プロセスが完了し次第、すべてのデータを復元不可能にする。
要件 3.3	表示時に PAN をマスクして (先頭 6 桁と末尾 4 桁が最大表示桁数)、業務上の正当な理由がある関係者だけが完全な PAN を見ることができるようにする。
要件 3.4	次のいずれかの手法を使用して、すべての保存場所 (ポータブル デジタル メディア、バックアップ メディア、ログ内を含む) で PAN を読み取り不可にする。
要件 3.5	カード所有者データを漏洩と悪用から保護するために使用されるキーを保護するための手順をドキュメント化し、実施する。
要件 3.6	カード所有者データの暗号化に使用される暗号化キーの管理プロセスおよび手順をすべてドキュメント化し、実施する。これには、以下が含まれる。
要件 3.7	格納されたカード所有者データを保護するためのセキュリティ ポリシーと操作手順がドキュメント化され、使用され、影響を受ける関係者全員に周知されていることを確実にする。

要件 4 — オープンなパブリック ネットワークを経由するカード所有者のデータ転送を暗号化する。

お客様の責任

要件	担当
要件 4.1	次を含む、強力な暗号化とセキュリティ プロトコル (TLS、IPSEC、SSH など) を使用して、オープンなパブリック ネットワーク上の転送中のカード所有者の機密データを守る。
要件 4.2	決してエンドユーザー メッセージング テクノロジ (たとえば、電子メール、インスタント メッセージング、SMS、チャットなど) を使って保護されていない PAN を送信してはならない。
要件 4.3	転送中のカード所有者データを暗号化するためのセキュリティ ポリシーと運用手順を文書化、使用し、関係者全員に通知する。

要件 3.1

すべてのカード所有者データ (CHD) の保存について少なくとも以下のものを含むデータ保持および廃棄のポリシー、手順、プロセスを実装することで、保存するカード所有者データを最小限に抑える。

• 保存するデータ量とリテンション期間を、法律上、規則上、および業務上の要件のために必要な範囲に限定する
• 必要なくなった場合にデータを安全に削除するためのプロセス
• カード所有者データの特定の保存要件
• 定義されたリテンション期間を超えて保存されたカード所有者データを特定して、安全に破棄する四半期ごとのプロセス

お客様の責任

AKS クラスターに状態を格納しないでください。 CHD を格納することにした場合は、セキュリティで保護されたストレージ オプションを検討してください。 オプションとしては、ファイル ストレージ用の Azure Storage、または Azure SQL Databaseや Azure Cosmos DB などのデータベースがあります。

格納できる CHD の種類に関する標準ガイダンスに正確に従ってください。 ビジネス要件と使用するストレージの種類に基づいてデータ保持ポリシーを定義します。 重要な考慮事項をいくつか次に示します。

• データの格納方法と場所
• 格納されるデータを暗号化するかどうか
• 保持期間
• 保持期間中に許可されるアクション
• 保持期間満了後の格納データの削除方法

これらの選択項目の一部に関するガバナンス ポリシーを用意してください。 組み込みの Azure ポリシーで、それらの選択項目が適用されます。 たとえば、クラスター ポッドのボリュームの種類を制限したり、ルート ファイル システムに対する書き込み操作を拒否したりすることができます。

このポリシー定義の一覧を確認し、適切な場合はこれらをクラスターに適用します。

データを一時的にキャッシュする必要が生じる場合があります。 キャッシュされたデータは、ストレージ ソリューションへの移動中に保護することをお勧めします。 AKS でホストベースの暗号化機能を有効にすることを検討してください。 これにより、ノード VM 上の格納データが暗号化されます。 詳細については、「Azure Kubernetes Service (AKS) のホストベースの暗号化」を参照してください。 また、ノード プールの一時ディスクとキャッシュの暗号化を求める組み込みの Azure ポリシーを有効にします。

ストレージ テクノロジを選択する場合は、保持機能を確認してください。 たとえば、Azure Blob Storage には時間ベースの保持ポリシーがあります。 もう 1 つの選択肢は、保持ポリシーに従ってデータを削除するカスタム ソリューションを実装することです。 1 つの例として、データ ライフサイクル アクティビティを管理するデータ ライフサイクル管理 (DLM) があります。 このソリューションは、Azure Data Factory、Microsoft Entra ID、Azure Key Vault などのサービスを使用して設計されています。

詳細については、Azure Data Factory を使用したデータ ライフ サイクルの管理に関する記事を参照してください。

要件 3.2

承認後の機密認証データを保存しない (暗号化されている場合でも)。 機密認証データを受け取った場合、認証プロセスが完了し次第、すべてのデータを復元不可能にする。

お客様の責任

(適用対象: 要件 3.2.1、要件 3.2.2、要件 3.2.3)

データの処理と保護は、このアーキテクチャの対象範囲ではありません。 一般的な考慮事項をいくつか次に示します。

標準によると、機密の認証データは、詳細なトラック データ、カード検証コードまたは値、PIN データで構成されます。 CHD 処理の一環として、次のようなソースで認証データが公開されないことを確認してください。

• ポッドから出力されるログ。
• 例外処理ルーチン。
• ファイル名。
• キャッシュ。

一般的なガイダンスとして、マーチャントがこの情報を格納してはなりません。 必要がある場合は、業務上の正当な理由を文書化してください。

要件 3.3

表示時に PAN をマスクして (先頭 6 桁と末尾 4 桁が最大表示桁数)、業務上の正当な理由がある関係者だけが完全な PAN を見ることができるようにする。

お客様の責任

プライマリ アカウント番号 (PAN) は機密データと見なされていて、このデータが公開されないようする必要があります。 1 つの方法は、マスキングを使用して表示される桁数を減らすことです。

ワークロードにはデータ マスキングを実装しないでください。 代わりに、データベースレベルのコンストラクトを使用します。 Azure Synapse Analytics などの一連の Azure SQL サービスでは動的データ マスキングがサポートされ、これにより、アプリケーション レイヤーでの露出が削減されます。 これはポリシーベースのセキュリティ機能であり、マスクされていないデータを表示できるユーザーと、マスクを通じて公開されるデータの量を定義します。 組み込みのクレジット カード マスキング方法では、指定のフィールドの末尾 4 桁が公開され、クレジット カードの形式でプレフィックスとして定数文字列が追加されます。

詳細については、「動的データ マスク」を参照してください。

マスクされていないデータをクラスターに取り込む必要がある場合は、できるだけ早くマスキングしてください。

要件 3.4

次のいずれかの手法を使用して、すべての保存場所 (ポータブル デジタル メディア、バックアップ メディア、ログ内を含む) で PAN を読み取り不可にする。

• 強力な暗号化をベースにした一方向ハッシュ (PAN 全体をハッシュする必要がある)
• 切り捨て (PAN の切り捨てられたセグメントの置き換えにはハッシュを使用できない)
• インデックス トークンとパッド (パッドは安全に保存する必要がある)
• 関連するキー管理プロセスおよび手順を伴う、強力な暗号化

お客様の責任

この要件では、ワークロードで直接暗号化を使用する必要が生じる可能性があります。 PCI DSS のガイダンスでは、業界でテスト済みのアルゴリズムを使用することで、実際の攻撃に対応できるようにすることが推奨されています。 カスタムの暗号化アルゴリズムの使用は避けてください。

適切なデータ マスキング手法でも、この要件が満たされます。 すべてのプライマリ アカウント番号 (PAN) データのマスキングは、お客様が行う必要があります。 Azure Synapse Analytics などの一連の Azure SQL サービスでは動的データ マスキングがサポートされています。 「要件 3.3」を参照してください。

PAN がワークフロー プロセスの一部として公開されていないことを確認します。 次にいくつかの考慮事項を示します。

• PAN は、ワークフロー ログおよび (予期していた、または予期しない) 例外の処理ログの、どちらのログにも保存されないようにします。 また、HTTP ヘッダーなどの診断データ フローで、このデータが公開されないようにすることも必要です。

• PAN は、キャッシュ参照キーとしても、このプロセスによって生成されるファイル名の一部としても使用しないでください。

• 顧客が、求められていない場合に自由形式のテキスト フィールドに PAN を入力する場合があります。 すべての自由形式のテキスト フィールドに対するコンテンツ検証と検出のプロセスを準備して、PAN データに類似するすべてのコンテンツが取り除かれるようにしてください。

要件 3.4.1

(ファイルまたは列レベルのデータベース暗号化ではなく) ディスク暗号化が使用される場合、論理アクセスはネイティブなオペレーティング システムの認証およびアクセス制御メカニズムとは別に管理する必要がある (たとえば、ローカル ユーザー アカウント データベースや一般的なネットワーク ログイン資格情報を使用しないなどの方法で)。 暗号化解除キーをユーザー アカウントと関連付けてはならない。

お客様の責任

一般的な規則として、AKS クラスターに状態を格納しないでください。 ストレージ エンジン レベルの暗号化をサポートする外部データ ストレージを使用します。

Azure Storage に格納されているすべてのデータは、強力な暗号を使用して暗号化および暗号化解除されます。 関連するキーは Microsoft によって管理されます。 自己管理型暗号化キーが推奨されています。 暗号化は常にストレージ レイヤーの外部で行い、暗号化されたデータのみをストレージ メディアに書き込み、キーがストレージ レイヤーに隣接しないようにします。

Azure Storage では、自己管理型キーを使用することもできます。 詳細については、「Azure Storage の暗号化のためのカスタマー マネージド キー」を参照してください。

同様の機能をデータベースでも使用できます。 Azure SQL のオプションについては、「カスタマー マネージド キーを使用した Azure SQL Transparent Data Encryption」を参照してください。

キーは必ずマネージド キー ストア (Azure Key Vault、Azure Key Vault Managed Hardware Security Module (HSM) など) に格納してください。

データを一時的に格納する必要がある場合は、AKS のホスト暗号化機能を有効にして、VM ノード上の格納データが確実に暗号化されるようにします。

要件 3.5

カード所有者データを漏洩と悪用から保護するために使用されるキーを保護するための手順をドキュメント化し、実施する。

お客様の責任

これらのポイントについては、以下のサブセクションで説明します。

• 暗号化キーに関する最小特権アクセスの実践を維持します。
• Azure Key Vault と Microsoft Entra ID は、承認と監査ログの要件をサポートするように設計されています。 詳細については、Azure Key Vault に関する認証の要求に関する記事を参照してください。
• すべてのデータ暗号化キーを、暗号化デバイスに格納されているキー暗号化キーを使用して保護します。
• (Microsoft が管理するキーではなく) 自己管理型キーを使用する場合は、キー管理に関連するタスクを管理するプロセスとドキュメントを用意してください。

要件 3.5.1

サービス プロバイダーのみに対する追加の要件: 以下を含む、暗号化アーキテクチャのドキュメント化された説明を保持する。

• カード所有者データの保護に使用されるすべてのアルゴリズム、プロトコル、およびキーについての詳細 (キーの強度と有効期限を含む)
• 各キーの主要な使用法の説明
• キー管理で使用されるすべての HSM および他の SCD のインベントリ

お客様の責任

機密情報 (キー、接続文字列など) を格納する 1 つの方法として、ネイティブの Kubernetes Secret リソースを使用します。 必ず、保存時の暗号化を明示的に有効にしてください。 または、Azure Key Vault などのマネージド ストアにそれらを格納します。 この 2 つの方法のうち、マネージド ストア サービスを使用する方をお勧めします。 1 つの利点として、キーのローテーションなど、キー管理に関連するタスクのオーバーヘッドが削減されます。

Azure では既定で、暗号化されるすべてのデータに対して Microsoft が管理するキーがお客様ごとに使用されます。 ただし、一部のサービスでは、暗号化用に自己管理型キーもサポートされています。 保存時の暗号化に自己管理型キーを使用する場合は、キー管理タスクを処理するプロセスと戦略を準備してください。

ドキュメントの一部として、有効期限、場所、メンテナンス プランの詳細など、キー管理に関連する情報を含めます。

要件 3.5.2

暗号化キーへのアクセスを、必要最小限の管理者に制限する。

お客様の責任

キーへのアクセス権を持つユーザーの数を最小限に抑えます。 グループベースのロールの割り当てを使用している場合は、定期的な監査プロセスを設定して、アクセス権を持つロールを確認します。 プロジェクト チームのメンバーが変更された場合は、関連性のなくなったアカウントをアクセス許可から削除する必要があります。 適切なユーザーだけがアクセス権を持つようにします。 永続的なアクセス許可を削除し、Just-In-Time (JIT) ロールの割り当て、時間ベースのロールのアクティブ化、承認に基づくロールのアクティブ化を使用するようにします。

要件 3.5.3

カード所有者データの暗号化と暗号化解除に使用されるシークレット キーおよび秘密キーは、以下のいずれかの形式 (複数可) で常に保存する。

• 少なくともデータ暗号化キーと同じ強度を持ち、データ暗号化キーとは別の場所に保存されているキー暗号化キーで暗号化された状態で
• 安全な暗号化デバイス (ハードウェア (ホスト) セキュリティ モジュール (HSM) や PTS 承認の加盟店デバイスなど) 内で
• 業界承認の方式に従う、少なくとも 2 つの全長キー コンポーネントまたはキー共有として

お客様の責任

PCI-DSS 3.2.1 ワークロードでは、保存データの保護戦略の一環として複数の暗号化キーを使用する必要があります。 データ暗号化キー (DEK) は CHD の暗号化と暗号化解除に使用されますが、その DEK を保護する追加のキー暗号化キー (KEK) を用意することが必要です。 さらに、その KEK が暗号化デバイスに格納されるようにすることも必要です。

DEK の格納には Azure Key Vault を使用でき、KEK の格納には Azure Dedicated HSM を使用できます。 HSM のキー管理の詳細については、「Azure Dedicated HSM とは何か」を参照してください。

要件 3.6

カード所有者データの暗号化に使用される暗号化キーの管理プロセスおよび手順をすべてドキュメント化し、実施する。これには、以下が含まれる。

お客様の責任

(適用対象: 要件 3.6.1、要件 3.6.2、要件 3.6.3、要件 3.2.4)

Azure Key Vault を使用してキー、証明書、接続文字列などのシークレットを格納する場合は、それを不正なアクセスから保護してください。 Microsoft Defender for Key Vault では、疑わしいアクセス試行が検出され、アラートが生成されます。 これらのアラートは、Microsoft Defender for Cloud で表示できます。 詳細については、「Microsoft Defender for Key Vault」を参照してください。

キー管理に関する NIST のガイダンスに従ってください。 詳細については、次の情報を参照してください。

• 暗号化キー管理。
• SP 800-133 Rev. 2、暗号化キー生成に関する推奨事項
• SP 800-57 Part 1 Rev. 5、キー管理に関する推奨事項

「Microsoft Defender for Key Vault 」も参照してください。

要件 3.6.7

暗号化キーの不正置換の防止。

お客様の責任

• すべてのキー ストアの診断を有効にします。 Azure Monitor for Key Vault を使用してください。 これは、ログとメトリックを収集して Azure Monitor に送信します。 詳細については、Azure Monitor for Key Vault によるキー コンテナー サービスの監視に関する記事を参照してください。
• すべてのコンシューマーに読み取り専用アクセス許可を付与します。
• どの管理サービス プリンシパルに対しても永続的なアクセス許可を設定しないでください。 代わりに、Just-In-Time (JIT) ロールの割り当て、時間ベースのロールのアクティブ化、承認に基づくロールのアクティブ化を使用します。
• ログとアラートを Microsoft Sentinel などのセキュリティ情報およびイベント管理 (SIEM) ソリューションに統合して、一元化されたビューを作成します。
• 特に、予期しない変更時に、アラートと通知に対してアクションを実行します。

要件 3.6.8

暗号化キーの管理者は、自身のキー管理責任を理解し受諾していることを公式に認める必要がある。

お客様の責任

キー管理の運営担当者の責務を説明するドキュメントを保持します。

要件 3.7

格納されたカード所有者データを保護するためのセキュリティ ポリシーと操作手順がドキュメント化され、使用され、影響を受ける関係者全員に周知されていることを確実にする。

お客様の責任

ドキュメントは、一般的な記述に加え、すべてのペルソナに関する一連の最新ロール ガイドとして作成します。 新規採用者のトレーニングと継続的なトレーニングを実施します。

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 複数のチームが参加して、保存時および転送中のデータが確実に保護されるようにします。 ドキュメントには、すべてのペルソナのロール ガイダンスを記載してください。 ロールには、SRE、カスタマー サポート、営業、ネットワーク操作、セキュリティ操作、ソフトウェア エンジニア、データベース管理者などを含める必要があります。 スキルセットを最新の状態に保つために、NIST のガイダンスと保存データの戦略に沿って担当者をトレーニングしてください。 トレーニング要件は、要件 6.5 および 要件 12.6 で取り上げられています。

要件 4.1

強力な暗号化とセキュリティ プロトコル (TLS、IPSEC、SSH など) を使用して、オープンなパブリック ネットワーク上で転送されているカード所有者の機密データを守る。これには以下が含まれる。

お客様の責任

パブリック インターネット経由で送信されるカード所有者データ (CHD) は暗号化する必要があります。 データは TLS 1.2 (またはそれ以降) を使用して暗号化する必要があります。これにより、すべての転送に対する暗号のサポートが軽減されます。 非 TLS から TLS へのリダイレクトは、どのデータ転送サービスでもサポートしないでください。

設計には、戦略的な TLS 終端ポイント チェーンを含める必要があります。 ネットワーク ホップを経由してデータを転送するときは、パケット検査を必要とするホップで TLS を維持します。 少なくとも、最終の TLS 終端ポイントをクラスターのイングレス リソースに設定します。 クラスター リソース内でそれをさらに進めていくことを検討してください。

Azure Policy を使用してリソースの作成を制御します。

• HTTPS 以外のイングレス リソースの作成を拒否します。
• クラスター内でのパブリック IP またはパブリック ロード バランサーの作成を拒否して、Web トラフィックがゲートウェイを介してトンネリングされるようにします。

詳細については、「Azure の暗号化の概要」を参照してください。

要件 4.1.1

カード所有者データを伝送する、またはカード所有者データ環境に接続しているワイヤレス ネットワークで、業界のベスト プラクティス (IEEE 802.11i など) を使用して、認証と転送に対して強力な暗号化を実装する。

お客様の責任

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

要件 4.2

決してエンドユーザー メッセージング テクノロジ (たとえば、電子メール、インスタント メッセージング、SMS、チャットなど) を使って保護されていない PAN を送信してはならない。

お客様の責任

ワークロードで電子メールを送信する必要がある場合は、電子メール検疫ゲートを構築することを検討してください。 この検証により、すべての送信メッセージをスキャンしてコンプライアンスを確認し、機密データが含まれていないことを確認できます。 できれば、カスタマー サポートのメッセージについても、この方法を検討してください。

検証は、ワークロード レベルおよび変更制御プロセスで行う必要があります。 この要件が承認ゲートで理解されている必要があります。

考慮事項については、公式の PCI DSS 3.2.1 標準のガイダンスを参照してください。

要件 4.3

転送中のカード所有者データを暗号化するためのセキュリティ ポリシーと運用手順を文書化、使用し、関係者全員に通知する。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 これは、トランスポート層セキュリティ (TLS) に関するポリシーを管理している場合に特に当てはまります。 領域をいくつか次に示します。

• パブリック インターネットのイングレス ポイント。 1 つの例として、TLS 暗号に対する Azure Application Gateway のサポートがあります。
• 境界ネットワークとワークロード ポッド間のネットワーク ホップ。
• ポッド間の暗号化 (実装されている場合)。 これには、サービス メッシュの構成に関する詳細が含まれる場合があります。
• ポッドからストレージ (アーキテクチャの一部の場合)。
• ポッドから外部サービス、TLS を使用する Azure PaaS サービス、支払いゲートウェイ、または不正行為検出システム。

確実なセキュリティを実現するために、規制対象の環境の運用担当者に対し、教育を行い、情報を提供し、インセンティブを与える必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって特に重要です。

次の手順

すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新します。 セキュリティで保護されたシステムとアプリケーションを開発して維持します。