このガイドでは、お客様が Payment Card Industry Data Security Standard（PCI DSS）要件への対応で Google Kubernetes Engine（GKE）アプリケーション固有の課題を解決する際に役立つ情報をご提供します。
免責事項: このガイドは情報提供のみを目的としています。このガイドに記載された情報または推奨事項は、法的および監査上の助言を与えることを意図したものではありません。お客様は、サービスの特定の使用方法を必要に応じて独自に評価し、ご自身の法令遵守義務を果たす責任を負います。
PCI DSS コンプライアンスと GKE について
支払いカードのデータを処理する場合、オンプレミスのデータベースかクラウドかにかかわらず、データを保護する必要があります。PCI DSS は、カード会員データのセキュリティを促進および強化し、一貫したデータ セキュリティ対策をグローバルに展開するために開発された規格です。PCI DSS は、クレジット カード データの保護に必要な技術的および運用上の要件のベースラインとなります。PCI DSS は、販売者、処理者、取得者、発行者、サービス プロバイダなど、支払いカードの処理に関与するすべてのエンティティに適用されます。PCI DSS は、カード会員データ（CHD）または機密認証データ（SAD）、あるいはその両方を保存、処理または送信する他のすべてのエンティティにも適用されます。
最近では、コンテナされた化アプリケーションが普及し、多く従来型ワークロードが仮想マシン（VM）ベースのアーキテクチャからコンテナ化されたアーキテクチャに移行されています。Google Kubernetes Engine は、コンテナ化されたアプリケーションをデプロイするための、本番環境に対応したマネージド型環境です。最新のテクノロジーを利用して、デベロッパーの生産性、リソースの効率性、自動運用、オープンソースの柔軟性の向上を図り、製品化までの時間を短縮します。
クラウドでは、コンプライアンスは共有責任です。GKE（Autopilot と Standard の両方のオペレーション モードを含む）を含む Google Cloud は、PCI DSS 要件を遵守しています。クラウドにおける Google の責任分担については、共有責任マトリックスをご覧ください。
対象読者
- GKE を含む Google Cloud に PCI 準拠のワークロードを導入することを検討している方。
- デベロッパー、セキュリティ責任者、コンプライアンス責任者、IT 管理者、コントロールの実装と PCI DSS 要件への準拠を担当するその他の従業員。
始める前に
推奨事項に従うときに、次のものを使用する可能性があります。
- Google Cloud の組織、フォルダ、プロジェクトのリソース
- Identity and Access Management（IAM）
- Google Kubernetes Engine
- Google Cloud VPC
- Google Cloud Armor
- Cloud Data Loss Prevention API（Sensitive Data Protection の保護の一部）
- Identity-Aware Proxy（IAP）
- Security Command Center
このガイドは、コンテナと GKE に精通している方を対象としています。
範囲
このガイドでは、GKE に関連する以下の PCI DSS 要件について説明し、その要件を満たすためのガイダンスを提供します。以下の内容はバージョン 4.0 の規格に準拠しています。このガイドは、PCI DSS のすべての要件を網羅しているわけではありません。このガイドに記載されている情報は、組織が PCI DSS への準拠に取り組む際に参考にできますが、包括的なアドバイスを提供するものではありません。組織は、PCI の Qualified Security Assessor（QSA: 認定セキュリティ評価機関）に正式な検証を依頼できます。
用語
ここでは、このガイドで使用する用語について説明します。詳細については、PCI DSS 用語集をご覧ください。
- CHD
カード所有者データ。少なくとも、完全なカード会員番号（PAN）で構成されます。カード所有者データには、完全な PAN と一緒に次のいずれか含まれる場合があります。
- カード名義人
- 有効期限またはサービスコード
- 機密認証データ（SAD）
- CDE
カード会員データ環境。カード会員データまたは機密認証データを保存、処理または送信するユーザー、プロセス、技術から構成される環境。
- PAN
カード会員番号。PCI DSS で保護する義務があるカード会員データの重要な部分。PAN は通常、支払いカード（クレジットおよびデビット）に固有の 16 桁の番号で、カード発行会社とカード所有者のアカウントの識別に使用されます。
- PIN
個人識別番号。本人とシステムのみが知っている数字のパスワード。システムに対するユーザー認証で使用されます。
- QSA
認定セキュリティ評価機関。PCI Security Standards Council によって監査およびコンプライアンス分析の実施認定を受けた組織または個人。
- SAD
機密認証データ。PCI コンプライアンスでは、カードの発行者がトランザクションの承認に使用するデータ。カード会員データと同様に、PCI DSS では SAD の保護が必須です。販売者とその決済代行業者は SAD を保存できません。SAD には次のものが含まれます。
- 磁気ストライプに記憶された追跡データ
- チップおよび非接触カードによって生成される同等の追跡データ
- オンラインまたはカードを提示しない取引で使用されるセキュリティ検証コード（たとえば、カードに印字された 3～4 桁の数字）。
- PIN および PIN ブロック
- セグメンテーション
PCI DSS のコンテキストでは、エンティティのネットワークの残りの部分から CDE を隔離する方法。セグメンテーションは PCI DSS 要件ではありません。ただし、以下の要素の軽減につながるので、セグメンテーションの実施を強くおすすめします。
- PCI DSS 評価の範囲と費用
- PCI DSS コントロールの実装と保守にかかる費用と複雑さ
- 組織に対するリスク（カード会員データを管理下にある場所に統合することで軽減）
カード会員データ環境のセグメント化
カード会員データ環境（CDE）は、カード会員データまたは機密の認証データの保存、処理、送信を行うユーザー、プロセス、テクノロジーから構成されます。GKE のコンテキストでは、CDE に次のものも含まれます。
- セキュリティ サービスを提供するシステム（たとえば、IAM）。
- セグメンテーションを可能にするシステム（プロジェクト、フォルダ、ファイアウォール、Virtual Private Cloud（VPC）、サブネットなど）。
- カード会員データの保存、処理、送信を行うアプリケーション ポッドとクラスタ。適切なセグメンテーションを行わないと、クラウド フットプリント全体が PCI DSS の対象になる可能性があります。
PCI DSS の範囲外と見なされるには、システム コンポーネントを CDE から適切に分離する必要があります。また、範囲外のシステム コンポーネントが侵害された場合でも、CDE のセキュリティに影響を与えないようにする必要があります。
CDE の範囲を縮小するには、カード会員データの保存、処理、送信に関連するビジネス要件とプロセスを明確に理解していなければなりません。不要なデータを排除し、必要なデータを統合することで、カード会員データをできるだけ少ない場所に限定するには、長年のビジネス慣行の見直しが必要になることもあります。
Google Cloud では、さまざまな方法で CDE をセグメント化できます。このセクションでは、次の手段について説明します。
- リソース階層を使用した論理セグメンテーション
- VPC とサブネットを使用したネットワーク セグメンテーション
- VPC を使用したサービスレベルのセグメンテーション
- 範囲内のクラスタに関するその他の考慮事項
リソース階層を使用した論理セグメンテーション
Google Cloud のリソース階層を使用して組織構造内で CDE を分離するには、いくつかの方法があります。Google Cloud のリソースは階層的に編成されます。組織リソースは、Google Cloud リソース階層のルートノードになります。フォルダとプロジェクトは組織リソースに分類されます。フォルダ内には、プロジェクトや別のフォルダを格納できます。フォルダは、フォルダレベルの IAM 権限を使用して、フォルダ階層内のリソースへのアクセスを制御するために使用されます。また、類似したプロジェクトのグループ化にも使用されます。プロジェクトは、すべてのリソースの信頼境界であり、IAM の適用ポイントになります。
PCI の範囲に含まれるすべてのプロジェクトを 1 つのフォルダにまとめて、フォルダレベルで隔離できます。また、対象となるすべての PCI クラスタとアプリケーションに 1 つのプロジェクトを使用することも、対象の PCI アプリケーションごとにプロジェクトとクラスタを作成して Google Cloud リソースを整理することもできます。いずれにせよ、範囲内と範囲外のワークロードを異なるプロジェクトに保持することをおすすめします。
VPC ネットワークとサブネットを使用したネットワーク セグメンテーション
Virtual Private Cloud （VPC）とサブネットを使用して、ネットワークをプロビジョニングし、CDE 関連のリソースのグループ化や隔離を行うことができます。VPC は、パブリック クラウドの一部を論理的に分離したものです。VPC ネットワークは、Compute Engine 仮想マシン（VM）インスタンスと、VM インスタンスを利用する GKE などのサービスに対して、スケーラブルで柔軟なネットワークを提供します。詳細については、VPC の概要とベスト プラクティスとリファレンス アーキテクチャをご覧ください。
VPC Service Controls と Google Cloud Armor を使用したサービスレベルのセグメンテーション
VPC とサブネットでセグメント化を行い、CDE を隔離する境界を作成したら、VPC Service Controls を使用してレイヤ 7 でセキュリティ境界を強化します。VPC Service Controls を使用すると、対象の CDE プロジェクトに境界を作成できます。VPC Service Controls では次の制御を行うことができます。
- 上りの制御。承認された ID とクライアントにのみセキュリティ境界内へのアクセスを許可します。
- 下りの制御。セキュリティ境界内の ID とクライアントは、承認された宛先にのみアクセスできます。
Google Cloud Armor を使用すると、Google Cloud ネットワークのエッジにある HTTP(S) ロードバランサへのアクセスを許可または拒否する IP アドレスのリストを作成できます。ユーザーまたは不正なトラフィックに可能な限り近い IP アドレスを調べることにより、不正なトラフィックによるリソースの消費や VPC ネットワークへの侵入を防ぐことができます。
VPC Service Controls を使用して、対象のプロジェクトのサービス境界を定義します。この境界により、VM からサービスへのパスとサービス間のパスを管理します。また、VPC の上り（内向き）トラフィックと下り（外向き）トラフィックも管理します。
安全なネットワークとシステムの構築と維持
安全なネットワークの構築と維持には、PCI DSS の要件 1 と 2 が含まれます。
要件 1
ファイアウォール構成をインストールして維持し、CDE との間で送受信されるカード会員データとトラフィックを保護します。
コンテナと GKE のネットワークのコンセプトは、従来の VM のコンセプトとは異なります。ポッドどうしは NAT を使用せずに直接接続可能です。ノード間でも到達できます。これにより、単純なネットワーク トポロジが作成されます。複雑なシステムの管理に慣れている場合は、そのシンプルさに驚くかもしれません。GKE のネットワーク セキュリティの最初のステップは、これらのネットワークのコンセプトを理解することです。
要件 1 の個々の要件に進む前に、GKE に関連する次のネットワーク コンセプトを確認しておきましょう。
ファイアウォール ルール。 ファイアウォール ルールは、ノードへのトラフィックを制限するために使用されます。GKE ノードは Compute Engine インスタンスとしてプロビジョニングされ、他のインスタンスと同じファイアウォール メカニズムを使用します。ネットワーク内では、タグを使用してこれらのファイアウォール ルールを各インスタンスに適用できます。各ノードプールは、ルールで使用できる独自のタグセットを受け取ります。デフォルトでは、ノードプールに属する各インスタンスは、このノードプールが属する特定の GKE クラスタを識別するタグを受け取ります。このタグは、GKE が自動的に作成するファイアウォール ルールで使用されます。クラスタまたはノードプールの作成時に Google Cloud CLI で
--tagsフラグを使用すると、カスタムタグを追加できます。ネットワーク ポリシー。ネットワーク ポリシーを使用すると、ポッド間のネットワーク接続を制限できます。これにより、ポッドにセキュリティ上の問題が発生した場合、クラスタ内でのネットワーク ピボットと横方向の移動を制限できます。ネットワーク ポリシーを使用するには、GKE クラスタの作成時に機能を明示的に有効にする必要があります。既存のクラスタで有効にすると、クラスタノードが再起動します。デフォルトの動作では、すべてのポッド間の通信は常に開いています。したがって、ネットワークをセグメント化する場合、ポッドレベルでネットワーク ポリシーを適用する必要があります。GKE では、Kubernetes Network Policy API または
kubectlツールを使用して、ネットワーク ポリシーを定義できます。この Pod レベルのトラフィック ポリシールールは、クラスタ内でどの Pod とどのサービスが互いにアクセスできるかを決定します。名前空間。名前空間を使用すると、Kubernetes クラスタ内でリソースをセグメント化できます。Kubernetes にはすぐに使えるデフォルトの名前空間が用意されていますが、クラスタ内に複数の名前空間を作成することもできます。名前空間は、互いに論理的に隔離されます。これにより、クラスタ内のポッド、サービス、デプロイメントのスコープが提供されるので、ある名前空間を使用しているユーザーに別の名前空間のコンテンツは表示されません。ただし、同じクラスタ内の名前空間の場合は、空間どうしの通信が可能になります。このため、ネットワーク ポリシーが必要になります。Namespace の構成方法については、ブログ記事の Namespace のベスト プラクティスをご覧ください。
次の図は、上記のコンセプトと、クラスタ、ノード、Pod などの他の GKE コンポーネントとの関係を示しています。
要件 1.1
ネットワーク セキュリティ管理を導入して維持するためのプロセスとメカニズムが定義され、理解されている。
要件 1.1.2
ネットワーク コンポーネントを管理するグループ、ロール、責任範囲を文書化する。
まず、Google Cloud のほとんどのサービスと同様に、GKE で承認を行うために IAM ロールを構成する必要があります。IAM ロールを設定したら、Kubernetes の承認方法として Kubernetes ロールベースのアクセス制御（RBAC）の構成を追加する必要があります。
基本的に、すべての IAM 構成は、Google Cloud リソースとプロジェクト内のすべてのクラスタに適用されます。Kubernetes RBAC の構成は、各 Kubernetes クラスタのリソースに適用され、名前空間レベルでのきめの細かい承認が可能になります。GKE を使用すると、これらの承認方法を併用できます。IAM と RBAC のロールを組み合わせて割り当てることで、ユーザーに許可する機能を効果的に表現できます。
- GKE のネットワーク コンポーネントの論理管理で、IAM を使用してグループ、ロール、責任を制御できます。
- Kubernetes RBAC を使用して、Kubernetes クラスタ内のネットワーク ポリシーにきめ細かい権限を付与することで、Pod 間のトラフィックを制御し、非 CDE ユーザーからの不正な変更や偶発的な変更を防ぎます。
- すべての IAM および RBAC のユーザーと権限に対して正当な理由を説明できます。通常、QSA が制御のテストを行うときに、IAM と RBAC のサンプルに対して業務上の正当な理由を探します。
要件 1.2
ネットワーク セキュリティ管理（NSC）が構成され、維持されている。
まず、GKE ノードを実行する Compute Engine インスタンスでファイアウォール ルールを構成します。ファイアウォール ルールは、これらのクラスタノードを保護します。
次に、フローを制限してクラスタ内の Pod を保護するためのネットワーク ポリシーを構成します。ネットワーク ポリシーには、ポッドのグループに相互の通信と他のネットワーク エンドポイントとの通信を許可する方法を指定します。GKE のネットワーク ポリシーを適用することで、クラスタのポッドとサービス間の通信を制御できます。クラスタをさらにセグメント化するには、クラスタ内に複数の名前空間を作成します。名前空間は、互いに論理的に隔離されます。これにより、クラスタ内のポッド、サービス、Deployment のスコープが提供されるので、ある名前空間を使用しているユーザーに別の名前空間のコンテンツは表示されません。ただし、同じクラスタ内の名前空間どうしの通信は制限されません。このため、ネットワーク ポリシーが必要になります。名前空間を使用すると、Kubernetes クラスタ内でリソースをセグメント化できます。Namespace の構成方法については、ブログ記事の Namespace のベスト プラクティスをご覧ください。
デフォルトでは、Namespace にポリシーが存在しない場合、その Namespace の Pod との間の上り（内向き）トラフィックと下り（外向き）トラフィックがすべて許可されます。すべての Pod を選択し、これらの Pod に対する上り（内向き）トラフィックを許可しないネットワーク ポリシーを作成すると、Namespace にデフォルトの隔離ポリシーを作成できます。
要件 1.2.2
ネットワーク接続と NSC の構成に関する変更がすべて、要件 6.5.1 で定義されている変更制御プロセスに従って承認され、管理されている。
ネットワーク構成とインフラストラクチャをコードとして扱うには、変更管理プロセスと変更制御プロセスの一部として、継続的インテグレーション / 継続的デリバリー（CI / CD）のパイプラインを確立する必要があります。
CI / CD パイプラインの一部として Cloud Deployment Manager または Terraform テンプレートを使用して、クラスタにネットワーク ポリシーを作成できます。Deployment Manager または Terraform を使用すると、構成とインフラストラクチャを現在の本番環境または他の環境のコピーを再現できるコードとして扱うことができます。その後、単体テストやその他のテストを記述し、ネットワークの変更が期待どおりに機能することを確認できます。承認を含む変更制御プロセスは、バージョン リポジトリに保存されている構成ファイルを使用して管理できます。
Terraform Config Validator を使用すると、制約を定義し、セキュリティ ポリシーとガバナンス ポリシーを適用できます。Config Validator を CI/CD パイプラインに追加すると、任意のワークフローにステップを追加できます。このステップで、Terraform プランを検証し、違反は見つかった場合は却下します。
要件 1.2.5
許可されたすべてのサービス、プロトコル、ポートが識別、承認され、業務上の必要性が明確になっている。
GKE クラスタの上り（内向き）制御を強化するために、承認済みネットワークを使用して、クラスタのコントロール プレーンに到達できる IP 範囲をある程度制限できます。GKE は、TLS（Transport Layer Security）と認証の両方を使用して、公衆インターネットからクラスタ マスター エンドポイントへの安全なアクセスを実現しています。これにより、クラスタをどこからでも柔軟に管理できます。承認済みネットワークを使用することで、特定の IP アドレスセットのアクセスをさらに制限できます。
Google Cloud Armor を使用すると、IP 拒否リストと許可リストを作成し、GKE ホスト アプリケーションのセキュリティ ポリシーを設定できます。GKE クラスタでは、受信トラフィックは Cloud Load Balancing のコンポーネントである HTTP(S) 負荷分散によって処理されます。一般に、HTTP(S) ロードバランサは GKE Ingress コントローラによって構成され、このコントローラは構成情報を Kubernetes Ingress オブジェクトから取得します。詳細については、GKE で Google Cloud Armor ポリシーを構成する方法をご覧ください。
要件 1.3
カード会員データ環境との間のネットワーク アクセスが制限されている。
機密情報を保護するため、VPC Service Controls と限定公開の Google アクセスを使用して、VPC ネットワーク内の GKE クラスタとオンプレミスのハイブリッド環境間でプライベート通信を確立します。
要件 1.3.1
CDE への受信トラフィックが次のように制限されている。
- 必要なトラフィックのみに限定する。
- その他のトラフィックはすべて明示的に拒否される。
インターネットからの受信トラフィックを特定のクラスタに限定するために、GKE で Cloud NAT を設定することを検討してください。CDE の非公開のクラスタに限定公開クラスタを設定し、ノードには RFC 1918 の内部 IP アドレスのみを割り当てます。これにより、ワークロードが公衆インターネットから隔離されます。
要件 1.4
信頼できるネットワークと信頼できないネットワークの間のネットワーク接続が制御されている。
この要件には、要件 1.3 で説明した方法で対応できます。
要件 1.4.3
なりすまし対策を実装して、偽装されたソース IP アドレスを検出し、信頼できるネットワークへの侵入を阻止している。
なりすまし対策を実装するには、GKE Pod とクラスタでエイリアスの IP アドレスを使用し、偽装されたソース IP アドレスを検出してネットワークへの侵入を防ぎます。エイリアス IP 範囲を使用するクラスタは、VPC ネイティブ クラスタといいます。
要件 1.4.5
内部 IP アドレスとルーティング情報の開示が、承認済みのユーザーのみに限定されている。
GKE IP マスカレード エージェントを使用すると、クラスタで多対 1 の IP アドレス変換を行うネットワーク アドレス変換（NAT）を使用できます。複数のソース IP アドレスを単一アドレスの背後に隠します。
要件 2
すべてのシステム コンポーネントに安全な構成を適用する。
要件 2 では、デフォルトの設定とベンダー提供の認証情報を削除し、セキュリティ パラメータを強化する方法を記述しています。クラスタの強化はお客様の責任です。
要件 2.2
システム コンポーネントが安全に構成、管理されている。
これらの標準が既知のセキュリティ脆弱性に対処済みで、業界標準のシステム強化基準に準拠していることを確認してください。業界標準の強化基準として次のものがありますが、これに限定されるものではありません。要件 2.2.4
必要なサービス、プロトコル、デーモン、機能のみが有効になっていて、不要な機能はすべて削除または無効化されている。
要件 2.2.5
- 業務上の正当な理由が文書化されている。
- 安全でないサービス、プロトコル、デーモンを使用するリスクを軽減する追加のセキュリティ機能が文書化され、実装されている。
要件 2.2.6
不正使用を防止するようにシステム セキュリティ パラメータが構成されている。
デプロイ前
コンテナを GKE に移動する前に、次のことをおすすめします。
- 信頼できるソースによってビルドされて維持され、脆弱性チェックが実行されたコンテナ マネージド ベースイメージから始めます。デベロッパーが使用できるように、正常な状態またはゴールデンのベースイメージのセットを作成することも検討してください。より限定的なオプションとして、Distroless イメージやスクラッチ ベースイメージを使用する方法もあります。
- Artifact Analysis を使用して、コンテナ イメージの脆弱性をスキャンします。
- 承認済みの信頼できるライブラリとバイナリのみをコンテナに含めるように、DevOps / SecOps 内部ポリシーを設定します。
設定時
設定時には、次のことをおすすめします。
- デフォルトの Container-Optimized OS を GKE のノードイメージとして使用します。Container-Optimized OS は Chromium OS をベースにし、ノード セキュリティ用に最適化されています。
- アプリケーションを実行するクラスタでノードの自動アップグレードを有効にします。この機能は、管理対象のコントロール プレーンで実行されている Kubernetes のバージョンにノードを自動的にアップグレードします。これにより、安定性とセキュリティが向上します。
- ノードの自動修復を有効にします。この機能を有効にすると、GKE は定期的にノードのヘルス ステータスを確認し、ノードの修復が必要かどうかを判断します。ノードの修復が必要な場合、そのノードはドレインされ、新しいノードが作成されてクラスタに追加されます。
- セキュリティ イベントやノードのヘルス ステータスなどすべてのイベントを可視化するには、Cloud Monitoring と Cloud Logging をオンにします。セキュリティ インシデントの発生時に通知を受けるため、Cloud Monitoring アラート ポリシーを作成します。
- GKE ノードに権限が最小限のサービス アカウントを適用します。
- Google Cloud CIS ベンチマーク ガイドの GKE セクションを確認して適用します（該当する場合）。Kubernetes 監査ロギングはデフォルトで有効になっています。
kubectlと GKE API の両方に対するリクエストのログは Cloud Audit Logs に書き込まれます。 - 監査ロギングを構成します。
アカウント データの保護
カード会員データの保護には、PCI DSS の要件 3 および 4 が含まれます。
要件 3
保存されたアカウント データを保護する。
PCI DSS の要件 3 では、暗号化、切り捨て、マスキング、ハッシュなどの保護手段がカード会員データ保護の重要なコンポーネントであることが規定されています。侵入者が他のセキュリティ対策をかいくぐり、暗号化されたデータにアクセスできたとしても、正しい暗号鍵がなければ、データを読み取ることも、再利用することもできません。
リスク回避の手段として、保存されたデータを保護する別の手段を検討したほうがよい場合もあります。たとえば、リスクを最小限に抑える方法として、絶対に必要な場合を除き、カード会員データを保存しないという選択肢もあります。また、完全な PAN が必要ない場合は、データを途中で切り捨てることも可能です。メールやインスタント メッセージングなど、エンドユーザーが使用しているメッセージング技術で、保護されていない PAN を送信しないことも重要です。
Google Cloud での実行中に、決済処理フローで CHD が存在する可能性がある場所は次のとおりです。
- Cloud Storage バケット
- BigQuery インスタンス
- Datastore
- Cloud SQL
CHD が誤ってメールやカスタマー サービスの通信ログに保存されることもあります。対象範囲内の環境を決済処理システムに限定するように、機密データの保護を使用してこれらのデータ ストリームをフィルタすることをおすすめします。
Google Cloud では、データは保存時にデフォルトで暗号化されます。また、物理的な境界をまたぐ場合は、デフォルトで転送データが暗号化されます。こうした保護を有効にするために、追加の構成は必要ありません。
要件 3.5
カード会員番号（PAN）が、保存場所にかかわらず保護されている。
PAN データを読み取り不能にする方法の一つとしてトークン化があります。詳細については、PCI DSS で重要なカード会員データをトークン化するでソリューション ガイドをご覧ください。
DLP API を使用して、カード所有者データのスキャン、検出、報告を行います。Sensitive Data Protection は、Cloud Storage、BigQuery、Datastore で 12～19 桁の PAN データをスキャンし、分類するためのネイティブ サポートを備えています。追加のデータソース、カスタム ワークロード、アプリケーションのサポートを可能にするストリーミング コンテンツ API もあります。また、DLP API を使用して、データの切り捨て（削除）またはハッシュを行うこともできます。
要件 3.6
保存されているアカウント データを保護するために使用する暗号鍵が保護されている。
Cloud Key Management Service（KMS）は、暗号鍵用のマネージド ストレージ システムです。暗号鍵の生成、使用、ローテーション、破棄を行うことができます。Cloud KMS はカード会員データなどのシークレットを格納しませんが、このようなデータの暗号化に使用されます。
Kubernetes コンテキストのシークレットは Kubernetes Secret オブジェクトであり、パスワード、トークン、鍵などの機密情報の保存と管理に使用できます。
Google Cloud はデフォルトで、保存されているお客様のコンテンツを暗号化します。GKE では、こうした暗号化の処理と管理が自動的に行われるため、ユーザー側での操作は不要です。アプリケーション レイヤでシークレットを暗号化することで、機密データ（Secret など）に対するセキュリティをさらに高めることができます。この機能により、Cloud KMS で管理している鍵を使用して、アプリケーション レイヤでデータを暗号化できます。これにより、攻撃者がクラスタの Kubernetes 構成ストレージ インスタンスのコピーにアクセスした場合でも、データの内容が読み取られることはありません。
要件 4
オープンなパブリック ネットワーク上でカード会員データを転送する場合は、強力な暗号でデータを保護する。
悪意のある個人が簡単にアクセスできるネットワーク（公衆ネットワークなど）を介して送信する場合、対象となるデータを送信前に暗号化する必要があります。
Istio は、既存の分散アプリケーションに透過的に階層化されるオープンソースのサービス メッシュです。Istio は、マイクロサービス間のトラフィックの認証、承認、暗号化をスケーラブルに管理します。このプラットフォームの API を使用すると、任意のロギング プラットフォーム、テレメトリ、ポリシー システムを統合できます。Istio の機能セットを使用すると、分散マイクロサービス アーキテクチャを効率的に実行できます。また、マイクロサービスの保護、接続、監視を一貫した方法で行うことができます。
要件 4.1
オープンなパブリック ネットワークを介した転送中に強力な暗号でカード会員データを保護するためのプロセスとメカニズムが定義され、文書化されている。
Istio を使用すると、デプロイされたサービスのネットワークを構築し、ロード バランシング、サービス間の認証、モニタリングを行うことができます。また、相互 TLS に基づく堅牢な ID ベースの承認と認証を使用し、クラスタ内のサービス間で安全な通信を実現できます。相互 TLS（mTLS）は、2 回実行される TLS handshake で、同じレベルの信頼を双方向で確立します（一方向のクライアント サーバー型の信頼とは対照的です）。
Istio では、アプリケーション内の各 GKE Pod に TLS 証明書をデプロイできます。ポッドで実行されているサービスは、mTLS を使用してピア ID を識別します。サービス間通信は、クライアント側とサーバー側の Envoy プロキシによってトンネリングされます。Envoy は、SPIFFE ID を使用して、サービス間で mTLS 接続を確立します。GKE に Istio をデプロイする方法については、GKE のドキュメントをご覧参ください。また、サポートされている TLS バージョンの詳細については、Istio のトラフィック管理のリファレンスをご覧ください。TLS バージョン 1.2 以降を使用してください。
アプリケーションがインターネットに公開されている場合は、GKE HTTP(S) ロード バランシングを使用し、上り（内向き）ルーティングで HTTP(S) を使用するように設定します。Ingress オブジェクトで構成される HTTP(S) 負荷分散には次のような特徴があります。
- 柔軟なサービスの構成。Ingress オブジェクトでは、トラフィックがどのようにサービスに到達し、そのトラフィックがどのようにアプリケーションにルーティングされるかを定義します。また、クラスタ内の複数のサービスに対して単一の IP アドレスを割り振ることができます。
- Google Cloud ネットワーク サービスとの統合。Ingress オブジェクトは、Google マネージド SSL 証明書（ベータ版）、Google Cloud Armor、Cloud CDN、Identity-Aware Proxy などの Google Cloud 機能を構成できます。
- 複数の TLS 証明書のサポート。Ingress オブジェクトでは、リクエストの終了に際して複数の TLS 証明書を使用するよう指定できます。
Ingress オブジェクトを作成すると、GKE Ingress コントローラによって Cloud HTTP(S) ロードバランサが作成され、Ingress および関連するサービスの情報に従って構成されます。
脆弱性を管理するプログラムの維持
脆弱性を管理するプログラムの維持には、PCI DSS の要件 5 および 6 が含まれます。
要件 5
すべてのシステムとネットワークを不正なソフトウェアから保護する。
PCI DSS の要件 5 では、マルウェアによって一般的に影響を受けるすべてのシステムでウイルス対策ソフトウェアを利用し、不正なソフトウェアによる現在および将来の脅威からシステムを保護する必要があると規定されています。この規定はコンテナにも例外なく適用されます。
要件 5.2
不正なソフトウェア（マルウェア）が防止または検出され、対処されている。
コンテナ イメージの脆弱性管理プログラムを実装する必要があります。
次の対応をおすすめします。
- 最新のセキュリティ パッチを定期的に確認し、コンテナに適用します。
- コンテナ化されたアプリケーションとバイナリ / ライブラリに、脆弱性スキャンを定期的に実施します。
- ビルド パイプラインの一部としてイメージをスキャンします。
- 脆弱性情報サービスに登録して、コンテナで使用されている環境およびライブラリに関連する最新の脆弱性情報を受信します。
Google Cloud では、さまざまなコンテナ セキュリティ ソリューション プロバイダと連携し、お客様の Google Cloud デプロイメントのセキュリティ ポスチャー向上に努めています。検証済みのセキュリティ ソリューションとテクノロジーを活用して、GKE 環境を多層的に防御することをおすすめします。Google Cloud で検証済みのセキュリティ パートナーの最新リストについては、セキュリティ パートナーをご覧ください。
要件 5.2.2
以下のようなマルウェア対策ソリューションが導入されている。
- 既知のあらゆるタイプのマルウェアを検出する。
- 既知のあらゆるタイプのマルウェアを削除、ブロック、または封じ込める。
要件 5.2.3
マルウェアのリスクがないシステム コンポーネントが定期的に評価され、以下の内容が含まれる。
- マルウェアのリスクがないすべてのシステム コンポーネントの文書化されたリスト。
- これらのシステム コンポーネントについて、進化するマルウェアの脅威の識別と評価。
- これらのシステム コンポーネントに引き続きマルウェア対策の保護が必要ないかどうかの確認。
マルウェア スキャンを実行するソリューションは数多く存在しますが、PCI DSS では、システムによって攻撃を受ける可能性が異なることを認識しています。Linux サーバー、メインフレームなどのマシンは一般に不正なソフトウェアの影響を受けにくいと見られているため、5.2.2 から除外されます。その場合、要件 5.2.3 に従って、定期的に脅威を診断するシステムを実装する必要があります。
これらのルールは、GKE クラスタ内のノードと Pod の両方に適用されることに注意してください。
要件 5.3
マルウェア対策のメカニズムおよびプロセスの積極的な運用、維持、モニタリングが行われている。
要件 5.2、5.3 および 11.5 では、対象となるホストにウイルス スキャンおよびファイル整合性モニタリング（FIM）を導入することが規定されています。クラスタ内で信頼できるエージェントがすべてのノードをスキャンできるソリューションか、各ノードに単一の管理エンドポイントをレポートするスキャナが用意されているソリューションの実装をおすすめします。
詳細については、GKE のセキュリティの概要と Container-Optimized OS のセキュリティの概要をご覧ください。
アンチウイルスと FIM の両方の要件を満たすには、特定のフォルダにのみ書き込みアクセスを許可するようにコンテナをロックダウンします。これを実現するには、コンテナを root 以外のユーザーとして実行して、ファイル システムの権限でコンテナ ファイル システム内の作業ディレクトリ以外への書き込みアクセスを禁止します。ファイル システムルールの回避を防ぐため、権限昇格を禁止します。
要件 6
安全なシステムとソフトウェアを開発し、維持する。
PCI DSS の要件 6 では、ソフトウェア開発のすべてのステップにセキュリティが組み込まれた強固なソフトウェア開発ライフサイクルの確立が規定されています。
要件 6.2
オーダーメイドのソフトウェアおよびカスタム ソフトウェアが安全に開発されている。
要件 6.2.1
オーダーメイドのソフトウェアおよびカスタム ソフトウェアが、以下のように安全に開発されている。
- 安全な開発のための業界標準やベスト プラクティスに基づいている。
- PCI DSS に準拠している（安全な認証とロギングなど）。
- ソフトウェア開発ライフサイクルの各ステージで、情報セキュリティの問題が考慮されている。
Binary Authorization を使用すると、信頼できるコンテナのみを GKE にデプロイできます。1 人以上の認証者によって承認されたイメージのみを有効にする場合は、脆弱性スキャン結果に基づく証明書を必要とするルールを含むポリシーを適用するように、Binary Authorization を構成できます。また、1 人以上の信頼できる関係者（「認証者」といいます）がイメージをデプロイ前に承認することを必要とするポリシーを作成することもできます。イメージが開発環境からテスト環境、本番環境クラスタに進むマルチステージ デプロイ パイプラインでは、証明者を使用して、ソフトウェアが次のステージに移行する前にすべての必要なプロセスが完了したことを確認できます。
デプロイ時には、Binary Authorization によってポリシーが適用され、コンテナ イメージが必要なすべての制約に合格していること（必要なすべての認証者がイメージのデプロイ準備の完了を確認したことなど）が確認されます。合格している場合はデプロイが許可されます。それ以外の場合は、デプロイがブロックされます。この状態が解決するまで、イメージのデプロイはできません。
Binary Authorization の詳細については、GKE の設定をご覧ください。
緊急時は、ブレークグラス ワークフローを使用して、Binary Authorization ポリシーを回避できます。ブレークグラス インシデントはすべて Cloud Audit Logs に記録されます。
GKE Sandbox を使用すると、コンテナがホストと直接やり取りする必要性が低減します。これによってホストの不正使用を狙った攻撃対象領域が縮小し、悪意のある行為者の動きが制限されます。
要件 6.3
セキュリティの脆弱性を特定し、対処している。
要件 6.3.1
次のようにセキュリティの脆弱性を特定し、管理している。
- セキュリティの新しい脆弱性は、国際的および国内のコンピュータ緊急対応チーム（CERT）からの警告を含む、業界で認知されたセキュリティ脆弱性情報源を使用して特定される。
- 脆弱性には、業界のベスト プラクティスに基づき、潜在的な影響を考慮してリスク ランキングが割り当てられている。
- リスク ランキングにより、少なくとも、高リスクまたは環境にとって重大であると考えられるすべての脆弱性が特定される。
- オーダーメイドのソフトウェア、カスタム ソフトウェア、サードパーティ ソフトウェア（オペレーティング システムやデータベースなど）に対する脆弱性を対象としている。
クラウドのセキュリティでは、クラウド プロバイダとお客様の間で責任を分担します。
GKE では、Google はコントロール プレーンを管理します。コントロール プレーンには、マスター VM、API サーバー、これらの VM 上で実行される他のコンポーネント、etcd データベースが含まれます。管理にはアップグレードとパッチ適用、スケーリング、修復が含まれ、それぞれにサービスレベル目標（SLO）が設定されています。Container-Optimized OS や Ubuntu などのノード オペレーティング システムの場合、GKE はこれらのイメージに対するパッチを速やかに提供します。自動アップグレードを有効にしている場合、これらのパッチは自動的にデプロイされます。これはコンテナの基本層で、コンテナで実行されているオペレーティング システムとは異なります。
GKE の共有責任モデルの詳細については、コンテナ セキュリティの調査: GKE の共有責任モデルをご覧ください。
Google は、CI / CD パイプラインへのセキュリティの組み込みに有用な複数のセキュリティ サービスを提供しています。たとえば、コンテナ イメージの脆弱性を識別するには、Google Artifact Analysis の脆弱性スキャンを使用できます。コンテナ イメージが Google Container Registry（GCR）に push されると、脆弱性スキャンが自動的に開始し、既知の CVE ソースの脆弱性と露出の有無が確認されます。脆弱性には、CVSS スコアに基づき重大度（重大、高、中、低、最小）が割り当てられます。
要件 6.4
一般公開されているウェブ アプリケーションが攻撃から保護されている。
Web Security Scanner を使用すると、App Engine、Compute Engine、GKE の一般公開されているウェブ アプリケーションをスキャンして、クロスサイト スクリプティング、構成ミス、脆弱なリソースなど、一般的な脆弱性を調べることができます。スキャンは Google Cloud コンソールから実行できます。オンデマンドで実行することも、スケジュールを設定することもできます。Security Scanner API を使用すると、アプリケーション ビルド パイプラインのセキュリティ テスト スイートの一部としてスキャンを自動化できます。
強固なアクセス制御手法の実装
強固なアクセス制御手法の実装強には、PCI DSS の要件 7、8、9 が含まれます。
要件 7
システム コンポーネントとカード会員データへのアクセスを業務上必要な範囲に制限する。
要件 7 では、「最小権限」と「必要な範囲」に焦点を当てています。PCI DSS では、これらを、最小限のデータに対するアクセス権を付与し、業務の遂行に必要な最小限の権限を提供することと定義しています。
要件 7.2
システム コンポーネントとデータへのアクセスが適切に定義され、割り当てられている。
IAM と Kubernetes のロールベース アクセス制御（RBAC）は相互に連携し、GKE 環境できめ細かいアクセス制御を実現しています。IAM は、CDE プロジェクト内の Google Cloud リソースに対するユーザー アクセスと権限を管理するために使用されます。GKE では、IAM を使用して、ユーザーとサービス アカウントがクラスタ内で実行できる権限とアクション（クラスタの作成や削除など）を管理することもできます。
Kubernetes RBAC を使用すると、きめ細かい権限セットを構成して、特定の Google Cloud ユーザー、Google Cloud サービス アカウント、ユーザーのグループ（Google グループ）がクラスタ内またはクラスタの特定の名前空間で Kubernetes オブジェクトをどのように操作できるかを定義できます。RBAC 権限としては、Deployment または ConfigMap の編集、ポッドの削除、ポッドからのログの表示などの権限があります。ユーザーまたはサービスに、Google Kubernetes Engine Cluster 閲覧者やカスタムロールなどの限定的な IAM 権限を付与し、必要に応じて Kubernetes RBAC RoleBinding を適用します。
Cloud Identity Aware Proxy（IAP）を GKE の Ingress に統合すると、従業員によるアクセスをアプリケーション レベルで制御できます。また、PCI アプリケーションを必要とする担当者に対しても、アプリケーション レベルでのアクセスが許可されます。
さらに、組織のポリシーを使用して、プロジェクト内で使用可能な API とサービスを制限できます。
要件 7.2.2
ユーザー（特権ユーザーを含む）に、以下に基づいてアクセス権が割り当てられている。
- 職務分類と機能。
- 職務の遂行に必要な最小権限。
ユーザーとサービス アカウントが最小権限の原則に従うようにすると同時に、コンテナもこの原則に従う必要があります。コンテナを実行する際のベスト プラクティスは、root 以外のユーザーがプロセスを実行することです。このベスト プラクティスを実現して適用するには、PodSecurity アドミッション コントローラを使用します。
PodSecurity は Kubernetes アドミッション コントローラであり、これにより GKE クラスタで実行されている Pod に Pod Security Standards を適用できます。Pod Security Standards は事前定義されたセキュリティ ポリシーであり、Kubernetes における Pod セキュリティの高度なニーズに対応しています。これらのポリシーは、制約の緩やかなものから非常に厳格なものまで多岐にわたります。PodSecurity は、Kubernetes v1.25 で削除された以前の PodSecurityPolicy アドミッション コントローラに代わるものです。PodSecurityPolicy から PodSecurity アドミッション コントローラへの移行手順をご確認ください。
要件 8
ユーザーを識別し、システム コンポーネントへのアクセスを認証する
要件 8 では、各個人に自身が行った操作に対する責任を持たせるために、対象の PCI システムにアクセス可能なユーザーに一意の ID を割り当てることが義務付けられています。
要件 8.2
ユーザーおよび管理者のユーザー ID と関連するアカウントが、アカウントのライフサイクルを通じて厳密に管理されている。
要件 8.2.1
すべてのユーザーに対して、システム コンポーネントまたはカード会員データへのアクセスが許可される前に、一意の ID が割り当てられる。
要件 8.2.5
契約終了したユーザーのアクセス権は直ちに取り消される。
IAM と Kubernetes RBAC は両方とも GKE クラスタへのアクセスを制御するために使用され、どちらの場合もユーザーに権限を付与できます。ユーザー アカウントとポリシーを 1 か所で管理できるように、既存の ID システムにユーザーを関連付けることをおすすめします。
要件 8.3
ユーザーおよび管理者の厳格な認証が確立され、管理されている。
要件 8.3.1
- ユーザーが知っているもの（パスワード、パスフレーズなど）
- ユーザーが持っているもの（トークン デバイスやスマートカードなど）
- ユーザー自身（生体認証など）
ユーザーが kubectl で認証されると、証明書がユーザー ID に割り当てられます。すべての GKE クラスタは、Google Cloud のユーザー ID とサービス アカウント ID を受け入れるように構成されています。認証情報を検証し、ユーザーまたはサービス アカウントの ID に関連付けられているメールアドレスを取得できます。そのため、認証に成功するには、こうしたアカウントの認証情報に userinfo.email OAuth スコープが含まれている必要があります。
要件 9
カード会員データへの物理的なアクセスを制限する。
Google は、Google Cloud の基盤となるすべての Google データセンターの物理的なセキュリティ管理を担っています。
定期的なネットワークのモニタリングおよびテスト
定期的なネットワークのモニタリングおよびテストには、PCI DSS の要件 10 と 11 が含まれます。
要件 10
システム コンポーネントとカード会員データへのすべてのアクセスをログに記録し、モニタリングする。
要件 10.2
異常や不審な操作の検出と、イベントのフォレンジック分析をサポートするために、監査ログが実装されている。
Kubernetes クラスタでは、Kubernetes 監査ロギングがデフォルトで有効になっています。これにより、Kubernetes API サーバーに対して行われた呼び出しの記録が時系列で保持されます。Kubernetes 監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリング アラートの作成に対して有用です。
GKE クラスタでは、GKE 監査ロギングのデフォルトの構成が Cloud Audit Logs および Logging と統合されます。Kubernetes 監査ログのエントリは、Google Cloud プロジェクトで表示できます。
プロジェクトの監査ログには、Kubernetes によって作成されたエントリだけでなく、GKE によって書き込まれたエントリもあります。
CDE ワークロードと CDE 以外のワークロードを区別するため、GKE Pod にラベルを追加することをおすすめします。追加したラベルは、これらのワークロードから提供される指標とログに適用されます。
要件 10.2.2
- ユーザー ID
- イベントのタイプ
- 日時
- 成功または失敗の表示
- イベントの発生源
- 影響を受けるデータ、システム コンポーネント、リソース、またはサービスの ID または名前（名前、プロトコルなど）
Logging では、監査ログエントリはすべて次のフィールドを含む LogEntry タイプのオブジェクトになります。
- ペイロード。
protoPayload型になります。各監査ログエントリのペイロードは、AuditLogタイプのオブジェクトになります。ユーザー ID は、AuditLogオブジェクトのAuthenticationInfoフィールドで確認できます。 - 特定のイベント。
AuditLogのmethodNameフィールドで確認できます。 - タイムスタンプ。
- イベントのステータス。
AuditLogオブジェクトのresponseオブジェクトで確認できます。 - オペレーションのリクエスト。
AuditLogオブジェクトのrequestオブジェクトとrequestMetadataオブジェクトで確認できます。 - 実行されるサービス。
serviceDataのAuditDataオブジェクトで確認できます。
要件 11
システムとネットワークのセキュリティを定期的にテストする。
要件 11.3
外部および内部の脆弱性を定期的に特定し、優先順位を付け、対処している。
要件 11.3.1
- 少なくとも 3 か月に 1 回実施する。
- 高リスクおよび重大な脆弱性（要件 6.3.1 で定義されたエンティティの脆弱性リスク ランキングに基づく）を解決する。
- 再スキャンを実施して、上記の高リスクおよび重大な脆弱性がすべて解決されていることを確認する。
- 最新の脆弱性情報によってスキャンツールを最新の状態に維持している。
- 有資格者がスキャンを実施し、テスト担当者の組織的な独立性が確保されている。
Artifact Analysis の脆弱性スキャンは、Container Registry 内のイメージに対して、次の種類の脆弱性スキャンを実行します。
初期スキャン。Artifact Analysis API を初めて起動すると、Container Registry 内のイメージがスキャンされ、イメージのパッケージ マネージャー、イメージベース、脆弱性のオカレンスが抽出されます。
差分スキャン。Artifact Analysis は、Container Registry にアップロードされた新しいイメージをスキャンします。
継続分析: Artifact Analysis は、新しい脆弱性情報や更新された脆弱性情報を脆弱性ソースから取得すると、コンテナの分析を再実行し、スキャン済みイメージの脆弱性オカレンスのリストを最新の状態にします。
要件 11.5
ネットワークへの侵入および予期しないファイルの変更を検出し、対応を行っている。
要件 11.5.1
- すべてのトラフィックが CDE の境界でモニタリングされる。
- すべてのトラフィックが CDE の重要なポイントでモニタリングされる。
- 侵害の疑いがある場合は、担当者にアラートが送信される。
- すべての侵入検知エンジン、侵入防止エンジン、ベースライン、シグネチャが最新の状態に保たれている。
Google Cloud の Packet Mirroring と Cloud IDS を併用すると、ネットワーク侵入を検出できます。Google Cloud Packet Mirroring によって、Compute Engine VM または Google Cloud クラスタからのすべてのネットワーク トラフィックが、指定されたアドレスに転送されます。Cloud IDS では、このミラーリングされたトラフィックが使用して、攻撃の試み、ポートスキャン、バッファ オーバーフロー、プロトコル フラグメンテーション、コマンド＆コントロール（C2）トラフィック、マルウェアなどの幅広い脅威を検出します。
Security Command Center を使用すると、Google Cloud のサービス（GKE を含む）とアセットのセキュリティ状態を組織全体で一元管理できるため、脅威の防止、検出、対応が容易になります。Security Command Center を使用することで、マルウェア、クリプトマイニング、Google Cloud リソースに対する不正アクセス、DDoS 攻撃、ポートスキャン、ブルート フォース SSH など、高リスクの脅威が Google Cloud の Cloud Logging のログに基づいて検出されていることを確認できます。
情報セキュリティ ポリシーの維持
強固なセキュリティ ポリシーでセキュリティの基準を設定し、利用者に期待されるレベルを伝えます。ここで使用している「利用者」とは、CDE にアクセスできる従業員（フルタイムおよびパートタイム）、臨時従業員、契約社員、コンサルタントを意味します。
要件 12
組織のポリシーとプログラムで情報セキュリティをサポートする。
要件 12 の詳細については、Google Cloud PCI 責任分担表をご覧ください。
クリーンアップ
この記事の閲覧中にリソースを使用していた場合（新しい VM の起動、Terraform スクリプトの使用など）、リソースを使用したプロジェクトを削除することで、Google Cloud アカウントに対する課金を防げます。
- Google Cloud コンソールで、[リソースの管理] ページに移動します。
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
次のステップ
- PCI データ セキュリティ基準の遵守について学習する。
- Terraform スターター キットを試す。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。