GKE における PCI DSS コンプライアンス

このガイドは、お客様が 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)は、コンテナ化されたアプリケーションをデプロイするための、本番環境に対応したマネージド環境です。最新のテクノロジーを利用して、デベロッパーの生産性、リソースの効率性、自動運用、オープンソースの柔軟性の向上を図り、製品化までの時間を短縮します。

クラウドでは、コンプライアンスは共有責任です。GKE を含む 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(DLP)API
  • Identity-Aware Proxy(IAP)
  • Security Command Center

このガイドは、コンテナと GKE に精通している方を対象としています。

範囲

このガイドでは、GKE に関連する PCI DSS 要件について説明し、その要件を満たすためのガイダンスを提供します。以下の内容はバージョン 3.2.1 の規格に準拠しています。このガイドは、PCI DSS のすべての要件を網羅しているわけではありません。

PCI DSS の目標 PCI DSS の要件
カード会員データ環境のセグメント化 要件 0 といわれることもあります。PCI コンプライアンスの必須要件ではありませんが、PCI の範囲を制限するため、この要件を遵守することをおすすめします。
安全なネットワークの構築と維持 1. カード会員データを保護するためにファイアウォールを導入し、最適な構成を維持する

2. システム パスワードと他のセキュリティ パラメータにベンダー提供のデフォルトを使用しない
カード会員データの保護 3. 保存されたカード会員データを安全に保護する

4. 公衆ネットワーク上でカード会員データを送信する場合、データを暗号化する
脆弱性を管理するプログラムの維持 5. アンチウイルス ソフトウェアまたはプログラムを利用し、定期的に更新する

6. 安全性の高いシステムとアプリケーションを開発し、保守する
強固なアクセス制御手法の実装 7. カード会員データへのアクセスを業務上必要な範囲に制限する

8. PC にアクセスする利用者ごとに個別の ID を割り当てる

9. カード会員データへの物理的アクセスを制限する
定期的なネットワークのモニタリングおよびテスト 10. ネットワーク リソースおよびカード会員データに対するすべてのアクセスを追跡し、モニタリングする

11. セキュリティ システムおよび管理手順を定期的にテストする
情報セキュリティ ポリシーの維持 12. 従業員と契約社員のための情報セキュリティに関するポリシーを維持する

用語

ここでは、このガイドで使用する用語について説明します。詳細については、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 を分離するには、いくつかの方法があります。PCI セグメンテーションを実現する一つの方法は、GKE PCI Terraform スターター キットを使う方法です。

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 の上りトラフィックと下りトラフィックも管理します。

図 1. VPC Service Controls によるセグメンテーションの実現。
図 1. VPC Service Controls によるセグメンテーションの実現

安全なネットワークの構築と維持

安全なネットワークの構築と維持には、PCI DSS の要件 1 と 2 が含まれます。

要件 1

ファイアウォール構成をインストールして維持し、CDE との間で送受信されるカード会員データとトラフィックを保護します。

コンテナと GKE のネットワークのコンセプトは、従来の VM のコンセプトとは異なります。ポッドどうしは NAT を使用せずに直接接続可能です。ノード間でも到達できます。これにより、単純なネットワーク トポロジが作成されます。複雑なシステムの管理に慣れている場合は、そのシンプルさに驚くかもしれません。GKE のネットワーク セキュリティの最初のステップは、これらのネットワークのコンセプトを理解することです。

安全な Kubernetes クラスタの論理レイアウト。
図 2. 安全な Kubernetes クラスタの論理レイアウト

要件 1 の個々の要件に進む前に、GKE に関連する次のネットワーク コンセプトを確認しておきましょう。

  • ファイアウォール ルールファイアウォール ルールは、ノードへのトラフィックを制限するために使用されます。GKE ノードは Compute Engine インスタンスとしてプロビジョニングされ、他のインスタンスと同じファイアウォール メカニズムを使用します。ネットワーク内では、タグを使用してこれらのファイアウォール ルールを各インスタンスに適用できます。各ノードプールは、ルールで使用できる独自のタグセットを受け取ります。デフォルトでは、ノードプールに属する各インスタンスは、このノードプールが属する特定の GKE クラスタを識別するタグを受け取ります。このタグは、GKE が自動的に作成するファイアウォール ルールで使用されます。クラスタまたはプールの作成時に gcloud コマンドライン ツールで --tags フラグを使用すると、カスタムタグを追加できます。詳しくは、GKE ノードでのファイアウォール ルールの構成をご覧ください。

  • ネットワーク ポリシーネットワーク ポリシーを使用すると、ポッド間のネットワーク接続を制限できます。これにより、ポッドにセキュリティ上の問題が発生した場合、クラスタ内でのネットワーク ピボットと横方向の移動を制限できます。ネットワーク ポリシーを使用するには、GKE クラスタの作成時に機能を明示的に有効にする必要があります。既存のクラスタで有効にすると、クラスタノードが再起動します。デフォルトでは、すべてのポッド間の通信は常に開いています。したがって、ネットワークをセグメント化する場合、ポッドレベルでネットワーク ポリシーを適用する必要があります。GKE では、Kubernetes Network Policy API または kubectl ツールを使用して、ネットワーク ポリシーを定義できます。この Pod レベルのトラフィック ポリシールールは、クラスタ内でどの Pod とどのサービスが互いにアクセスできるかを決定します。

  • 名前空間名前空間を使用すると、Kubernetes クラスタ内でリソースをセグメント化できます。Kubernetes にはすぐに使えるデフォルトの名前空間が用意されていますが、クラスタ内に複数の名前空間を作成することもできます。名前空間は、互いに論理的に隔離されます。これにより、クラスタ内のポッド、サービス、デプロイメントのスコープが提供されるので、ある名前空間を使用しているユーザーに別の名前空間のコンテンツは表示されません。ただし、同じクラスタ内の名前空間の場合は、空間どうしの通信が可能になります。このため、ネットワーク ポリシーが必要になります。名前空間の構成方法については、ブログ記事の名前空間のベスト プラクティスをご覧ください。

次の図は、上記のコンセプトと、クラスタ、ノード、Pod などの他の GKE コンポーネントとの関係を示しています。

クラスタ内のトラフィックを制御する Kubernetes ネットワーク ポリシー。
図 3. クラスタ内のトラフィックを制御する Kubernetes ネットワーク ポリシー

要件 1.1.1

すべてのネットワーク接続、ファイアウォールとルーター構成に対する変更を承認し、テストするための正式なプロセスを作成します。

ネットワーク構成とインフラストラクチャをコードとして扱うには、変更管理プロセスと変更制御プロセスの一部として、継続的インテグレーション / 継続的デリバリー(CI / CD)のパイプラインを確立する必要があります。

CI / CD パイプラインの一部として Cloud Deployment Manager または Terraform テンプレートを使用して、クラスタにネットワーク ポリシーを作成できます。Deployment Manager または Terraform を使用すると、構成とインフラストラクチャを現在の本番環境または他の環境のコピーを再現できるコードとして扱うことができます。その後、単体テストやその他のテストを記述し、ネットワークの変更が期待どおりに機能することを確認できます。承認を含む変更制御プロセスは、バージョン リポジトリに保存されている構成ファイルを使用して管理できます。

Terraform Config Validator を使用すると、制約を定義し、セキュリティ ポリシーとガバナンス ポリシーを適用できます。Config Validator を CI/CD パイプラインに追加すると、任意のワークフローにステップを追加できます。このステップで、Terraform プランを検証し、違反は見つかった場合は却下します。

要件 1.1.5

ネットワーク コンポーネントを管理するグループ、ロール、責任範囲を文書化します。

まず、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

信頼できないネットワークと CDE のシステム コンポーネント間の接続を制限するようにファイアウォールとルーターを構成します。

まず、GKE ノードを実行する Compute Engine インスタンスでファイアウォール ルールを構成します。ファイアウォール ルールは、これらのクラスタノードを保護します。

次に、フローを制限してクラスタ内の Pod を保護するためのネットワーク ポリシーを構成します。ネットワーク ポリシーには、ポッドのグループに相互の通信と他のネットワーク エンドポイントとの通信を許可する方法を指定します。GKE のネットワーク ポリシーを適用することで、クラスタのポッドとサービス間の通信を制御できます。クラスタをさらにセグメント化するには、クラスタ内に複数の名前空間を作成します。名前空間は、互いに論理的に隔離されます。これにより、クラスタ内のポッド、サービス、Deployment のスコープが提供されるので、ある名前空間を使用しているユーザーに別の名前空間のコンテンツは表示されません。ただし、同じクラスタ内の名前空間どうしの通信は制限されません。このため、ネットワーク ポリシーが必要になります。名前空間を使用すると、Kubernetes クラスタ内でリソースをセグメント化できます。名前空間の構成方法については、ブログ記事の名前空間のベスト プラクティスをご覧ください。

デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間のポッドとの間で送受信されるトラフィックがすべて許可されます。すべてのポッドを選択し、これらのポッドに対する上りトラフィックを許可しないネットワーク ポリシーを作成すると、名前空間にデフォルトの隔離ポリシーを作成できます。

要件 1.2.1

受信および送信トラフィックを CDE で必要なトラフィックに制限し、他のすべてのトラフィックを明示的に拒否します。

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

インターネットと CDE のシステム コンポーネント間の直接の公開アクセスを禁止します。

機密情報を保護するため、VPC Service Controls と限定公開の Google アクセスを使用して、VPC ネットワーク内の GKE クラスタとオンプレミスのハイブリッド環境間でプライベート通信を確立します。

要件 1.3.2

インターネットからの受信トラフィックを DMZ 内の IP アドレスに限定します。

インターネットからの受信トラフィックを特定のクラスタに限定するために、GKE で Cloud NAT を設定することを検討してください。CDE の非公開のクラスタに限定公開クラスタを設定し、ノードには RFC 1918 の内部 IP アドレスのみを割り当てます。これにより、ワークロードが公衆インターネットから隔離されます。

要件 1.3.3

なりすまし対策を実装して、偽装された送信元 IP アドレスを検出し、ネットワークへの侵入を阻止します。

なりすまし対策を実装するには、GKE ボットとクラスタでエイリアスの IP アドレスを使用し、偽装された IP アドレスを検出してネットワークへの侵入を防ぎます。エイリアス IP 範囲を使用するクラスタは、VPC ネイティブ クラスタといいます。

要件 1.3.7

許可されていない相手にプライベート IP アドレスとルーティング情報を開示しないでください。

GKE IP マスカレード エージェントを使用すると、クラスタで多対 1 の IP アドレス変換を行うネットワーク アドレス変換(NAT)を使用できます。複数のソース IP アドレスを単一アドレスの背後に隠します。

要件 2

システム パスワードと他のセキュリティ パラメータにベンダー提供のデフォルトを使用しないでください。要件 2 では、デフォルトの設定とベンダー提供の認証情報を削除し、セキュリティ パラメータを強化する方法を記述しています。クラスタの強化はお客様の責任です。

要件 2.2

すべてのシステム コンポーネントの構成標準を開発します。これらの標準が既知のセキュリティ脆弱性に対処済みで、業界標準のシステム強化基準に準拠していることを確認してください。業界標準の強化基準として次のものがありますが、これに限定されるものではありません。

要件 2.2.2

サービス、プロトコル、デーモンなど、システムの機能に必要なものだけを有効にします。

要件 2.2.4

誤用を防ぐためにシステム セキュリティ パラメータを構成します。

要件 2.2.5

スクリプト、ドライバ、機能、サブシステム、ファイル システム、不要なウェブサーバーなど、不要な機能をすべて削除します。

デプロイ前

コンテナを GKE に移動する前に、次のことをおすすめします。

  • 信頼できるソースによってビルドされて維持され、脆弱性チェックが実行されたコンテナ マネージド ベースイメージから始めます。デベロッパーが使用できるように、正常な状態またはゴールデンのベースイメージのセットを作成することも検討してください。より限定的なオプションとして、Distroless イメージスクラッチ ベースイメージを使用する方法もあります。
  • Container Analysis を使用して、コンテナ イメージの脆弱性をスキャンします。
  • 承認済みの信頼できるライブラリとバイナリのみをコンテナに含めるように、DevOps / SecOps 内部ポリシーを設定します。

設定時

設定時には、次のことをおすすめします。

  • デフォルトの Container-Optimized OS を GKE のノードイメージとして使用します。Container-Optimized OS は Chromium OS をベースにし、ノード セキュリティ用に最適化されています。
  • アプリケーションを実行するクラスタでノードの自動アップグレードを有効にします。この機能は、管理対象のコントロール プレーンで実行されている Kubernetes のバージョンにノードを自動的にアップグレードします。これにより、安定性とセキュリティが向上します。
  • ノードの自動修復を有効にします。この機能を有効にすると、GKE は定期的にノードのヘルス ステータスを確認し、ノードの修復が必要かどうかを判断します。ノードの修復が必要な場合、そのノードはドレインされ、新しいノードが作成されてクラスタに追加されます。
  • セキュリティ イベントやノードのヘルス ステータスなどすべてのイベントを可視化するには、Cloud MonitoringCloud 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 が誤ってメールやカスタマー サービスの通信ログに保存されることもあります。対象環境を決済処理システムに限定できるように、Cloud DLP(DLP)を使用してこのようなデータ ストリームをフィルタすることをおすすめします。

Google Cloud では、データは保存時にデフォルトで暗号化されます。また、物理的な境界をまたぐ場合は、デフォルトで転送データが暗号化されます。こうした保護を有効にするために、追加の構成は必要ありません。

要件 3.4

次のいずれかの方法で、PAN が保存されている場所(ポータブル デジタル メディア、バックアップ メディア、ログなど)で PAN を読み取り不能にします。
  • 強固な暗号による一方向ハッシュ(ハッシュは PAN 全体のものにする必要があります)。
  • 切り捨て(ハッシュを使用して、PAN の切り捨てられた部分と置き換えることはできません)。
  • インデックス トークンとパッド(パッドは安全に保管する必要があります)。
  • 関連する鍵管理プロセスと手順を備えた強力な暗号。

PAN データを読み取り不能にする方法の 1 つとしてトークン化があります。詳細については、PCI DSS で重要なカード会員データをトークン化するでソリューション ガイドをご覧ください。

DLP API を使用して、カード所有者データのスキャン、検出、報告を行います。Cloud DLP は、Cloud Storage、BigQuery、Datastore で 12~19 桁の PAN データをスキャンし、分類するためのネイティブ サポートを備えています。追加のデータソース、カスタム ワークロード、アプリケーションのサポートを可能にするストリーミング コンテンツ API もあります。また、DLP API を使用して、データの切り捨て(削除)またはハッシュを行うこともできます。

要件 3.5

保存されたカード会員データを漏えいや不正使用から保護するために使用する鍵の保護手順を文書化し、実装します。

Cloud Key Management Service(KMS)は、暗号鍵用のマネージド ストレージ システムです。暗号鍵の生成、使用、ローテーション、破棄を行うことができます。Cloud KMS はカード会員データなどのシークレットを格納しませんが、このようなデータの暗号化に使用されます。

Kubernetes コンテキストのシークレットは Kubernetes Secret オブジェクトであり、パスワード、トークン、鍵などの機密情報の保存と管理に使用できます。

Google Cloud はデフォルトで、保存されているお客様のコンテンツを暗号化します。GKE では、こうした暗号化の処理と管理が自動的に行われるため、ユーザー側での操作は不要です。アプリケーション レイヤでシークレットを暗号化することで、機密データ(Secret など)に対するセキュリティをさらに高めることができます。この機能により、Cloud KMS で管理している鍵を使用して、アプリケーション レイヤでデータを暗号化できます。これにより、攻撃者がクラスタの Kubernetes 構成ストレージ インスタンスのコピーにアクセスした場合でも、データの内容が読み取られることはありません。

GKE でのアプリケーション レイヤのシークレット。
図 4. GKE でのアプリケーション レイヤのシークレット

要件 4

公衆ネットワーク上でカード会員データを送信する場合は、データを暗号化します。

悪意のある個人が簡単にアクセスできるネットワーク(公衆ネットワークなど)を介して送信する場合、対象となるデータを送信前に暗号化する必要があります。

Istio は、既存の分散アプリケーションに透過的に階層化されるオープンソースのサービス メッシュです。Istio は、マイクロサービス間のトラフィックの認証、承認、暗号化をスケーラブルに管理します。このプラットフォームの API を使用すると、任意のロギング プラットフォーム、テレメトリ、ポリシー システムを統合できます。Istio の機能セットを使用すると、分散マイクロサービス アーキテクチャを効率的に実行できます。また、マイクロサービスの保護、接続、監視を一貫した方法で行うことができます。

要件 4.1

次のように堅牢な暗号とセキュリティ プロトコルを使用し、公衆ネットワークで送信するカード会員データを保護します。
  • 信頼できる鍵と証明書のみが受け入れられます。
  • 使用中のプロトコルは、安全なバージョンまたは構成のみをサポートします。
  • 使用中の暗号化方法に適した暗号強度を使用します。

Istio を使用すると、デプロイされたサービスのネットワークを構築し、負荷分散、サービス間の認証、モニタリングを行うことができます。また、相互 TLS に基づく堅牢な ID ベースの承認と認証を使用し、クラスタ内のサービス間で安全な通信を実現できます。相互 TLS(mTLS)は、2 回実行される TLS handshake で、同じレベルの信頼を双方向で確立します(一方向のクライアント サーバー型の信頼とは対照的です)。

Istio と mTLS を使用した安全なサービス間通信。
図 5. Istio と mTLS を使用した安全なサービス間通信

Istio では、アプリケーション内の各 GKE Pod に TLS 証明書をデプロイできます。ポッドで実行されているサービスは、mTLS を使用してピア ID を識別します。サービス間通信は、クライアント側とサーバー側の Envoy プロキシによってトンネリングされます。Envoy は、SPIFFE ID を使用して、サービス間で mTLS 接続を確立します。GKE に Istio をデプロイする方法については、GKE のドキュメントをご覧参ください。また、サポートされている TLS バージョンの詳細については、トラフィック管理のリファレンスをご覧ください。少なくとも TLS バージョン 1.1、可能であれば TLS 1.2 以降を使用してください。

アプリケーションがインターネットに公開されている場合は、GKE HTTP(S) 負荷分散を使用し、上り(内向き)ルーティングで HTTP(S) を使用するように設定します。Ingress オブジェクトで構成される HTTP(S) 負荷分散には次のような特徴があります。

  • 柔軟なサービスの構成。Ingress オブジェクトでは、トラフィックがどのようにサービスに到達し、そのトラフィックがどのようにアプリケーションにルーティングされるかを定義します。また、クラスタ内の複数のサービスに対して単一の IP アドレスを割り振ることができます。
  • Google Cloud ネットワーク サービスとの統合。Ingress オブジェクトは、Google マネージド SSL 証明書(ベータ版)Google Cloud ArmorCloud CDNIdentity-Aware Proxy などの Google Cloud 機能を構成できます。
  • 複数の TLS 証明書のサポート。Ingress オブジェクトでは、リクエストの終了に際して複数の TLS 証明書を使用するよう指定できます。

Ingress オブジェクトを作成すると、GKE Ingress コントローラによって Cloud HTTP(S) ロードバランサが作成され、Ingress および関連するサービスの情報に従って構成されます。

脆弱性を管理するプログラムの維持

脆弱性を管理するプログラムの維持には、PCI DSS の要件 5 および 6 が含まれます。

要件 5

アンチウィルス ソフトウェアまたはプログラムを利用し、定期的に更新します。

PCI DSS の要件 5 では、マルウェアによって一般的に影響を受けるすべてのシステムでアンチウィルス ソフトウェアを利用し、不正なソフトウェアによる現在および将来の脅威からシステムを保護する必要があると規定されています。

要件 5.1

不正なソフトウェアによって一般的に影響を受けるすべてのシステム(特にパソコンとサーバー)にアンチウィルス ソフトウェアをデプロイします。

コンテナ イメージの脆弱性管理プログラムを実装する必要があります。

次の対応をおすすめします。

  • 最新のセキュリティ パッチを定期的に確認し、コンテナに適用します。
  • コンテナ化されたアプリケーションとバイナリ / ライブラリに、脆弱性スキャンを定期的に実施します。
  • ビルド パイプラインの一部としてイメージをスキャンします。
  • 脆弱性情報サービスに登録して、コンテナで使用されている環境およびライブラリに関連する最新の脆弱性情報を受信します。

Google Cloud では、さまざまなコンテナ セキュリティ ソリューション プロバイダと連携し、お客様の Google Cloud 環境のセキュリティ向上に努めています。検証済みのセキュリティ ソリューションとテクノロジーを活用して、GKE 環境を多層的に防御することをおすすめします。Google Cloud で検証済みのセキュリティ パートナーの最新リストについては、Google Cloud: セキュリティ パートナー エコシステムの「コンテナ セキュリティ」をご覧ください。

要件 5.1.1

アンチウィルス プログラムが既知の不正なソフトウェアを検知および削除し、脅威を阻止できることを確認します。

要件 5.1.2

5.1.1 で除外されたシステムの場合は、進化するマルウェアの脅威を識別し、評価できることを定期的に確認します。

アンチウィルス スキャンを実行するソリューションは数多く存在しますが、PCI DSS では、システムによって攻撃を受ける可能性が異なることを認識しています。Linux サーバー、メインフレームなどのマシンは一般に悪質なソフトウェアの影響を受けにくいと見られているため、5.1.1 から除外されます。その場合、要件 5.1.2 に従って、定期的に脅威を診断するシステムを実装する必要があります。

これらのルールは、GKE クラスタ内のノードとポッドの両方に適用されることに注意してください。

要件 5.2

すべてのアンチウィルス メカニズムで次の状態が維持されていることを確認します。
  • 最新の状態に保たれている。
  • 定期的にスキャンを実施している。
  • PCI DSS 要件 10.7 に従い、関連する監査ログを生成している。

要件 5.3

アンチウィルス メカニズムがアクティブに実行されていることを確認します。また、管理者によって期間限定で明示的に許可された場合を除き、ユーザーによってアンチウィルス メカニズムの無効化や変更ができないようにします。

要件 5.1、5.2 および 11.5 では、対象となるホストにウイルス スキャンおよびファイル整合性モニタリング(FIM)を導入することが規定されています。クラスタ内で信頼できるエージェントがすべてのノードをスキャンできるソリューションか、各ノードに単一の管理エンドポイントをレポートするスキャナを用意するソリューションの実装をおすすめします。

アンチウイルスと FIM の両方の要件を満たすには、特定のフォルダにのみ書き込みアクセスを許可するようにコンテナをロックダウンします。これを実現するには、コンテナを root 以外のユーザーとして実行して、ファイル システムの権限でコンテナ ファイル システム内の作業ディレクトリ以外への書き込みアクセスを禁止します。ファイル システムルールの回避を防ぐため、権限昇格を禁止します。

要件 6

安全性の高いシステムとアプリケーションを開発し、保守します。

PCI DSS の要件 6 では、ソフトウェア開発のすべてのステップにセキュリティが組み込まれた強固なソフトウェア開発ライフサイクルの確立が規定されています。

要件 6.1

信頼できる外部ソースを使用して、セキュリティの脆弱性を識別するプロセスを確立します。また、新たに発見されたセキュリティの脆弱性に対してリスク評価(高、中、低など)を行います。

クラウドのセキュリティでは、クラウド プロバイダとお客様の間で責任を分担します。

GKE では、Google はコントロール プレーンを管理します。コントロール プレーンには、マスター VM、API サーバー、これらの VM 上で実行される他のコンポーネント、etcd データベースが含まれます。管理にはアップグレードとパッチ適用、スケーリング、修復が含まれ、それぞれにサービスレベル目標(SLO)が設定されています。Container-Optimized OS や Ubuntu などのノード オペレーティング システムの場合、GKE はこれらのイメージに対するパッチを速やかに提供します。自動アップグレードを有効にしている場合、これらのパッチは自動的にデプロイされます。これはコンテナの基本層で、コンテナで実行されているオペレーティング システムとは異なります。

GKE の共有責任モデルの詳細については、コンテナ セキュリティの調査: GKE の共有責任モデルをご覧ください。

Google は、CI / CD パイプラインへのセキュリティの組み込みに有用な複数のセキュリティ サービスを提供しています。たとえば、コンテナ イメージの脆弱性を識別するには、Google Container Analysis の脆弱性スキャンを使用できます。コンテナ イメージが Google Container Registry(GCR)に push されると、脆弱性スキャンが自動的に開始し、既知の CVE ソースの脆弱性と露出の有無が確認されます。脆弱性には、CVSS スコアに基づき重大度(重大、高、中、低、最小)が割り当てられます。

要件 6.3

PCI DSS および業界のベスト プラクティスに従って、内部および外部のソフトウェア アプリケーションを開発します。この中には、アプリケーションに対するウェブベースの管理アクセスも含まれます。ソフトウェアの開発ライフサイクル全体に情報セキュリティ システムを組み込みます。これは、内部で開発したすべてのソフトウェアと、サードパーティが開発した特注またはカスタム ソフトウェアに適用されます。

Binary Authorization を使用すると、信頼されたコンテナのみを GKE にデプロイできます。1 人以上の認証者によって承認されたイメージのみを有効にする場合は、脆弱性スキャン結果に基づく証明書を必要とするルールを含むポリシーを適用するように、Binary Authorization を構成できます。また、1 人以上の信頼できる関係者(「認証者」といいます)がイメージをデプロイ前に承認することを必要とするポリシーを作成することもできます。イメージが開発環境からテスト環境、本番環境クラスタに進むマルチステージ デプロイ パイプラインでは、証明者を使用して、ソフトウェアが次のステージに移行する前にすべての必要なプロセスが完了したことを確認できます。

デプロイ時には、Binary Authorization によってポリシーが適用され、コンテナ イメージが必要なすべての制約に合格していること(必要なすべての認証者がイメージのデプロイ準備の完了を確認したことなど)が確認されます。合格している場合はデプロイが許可されます。それ以外の場合は、デプロイがブロックされます。この状態が解決するまで、イメージのデプロイはできません。

Binary Authorization を使用して、信頼できるイメージのみを GKE クラスタに適用するポリシーを使用。
図 6. Binary Authorization を使用して、信頼できるイメージのみを GKE クラスタに適用するポリシーを使用

Binary Authorization の設定の詳細については、GKE でのソフトウェア サプライ チェーンの保護に関するソリューション ガイドをご覧ください。

緊急時は、ブレークグラス ワークフローを使用して、Binary Authorization ポリシーを回避できます。ブレークグラス インシデントはすべて Cloud Audit Logs に記録されます。

GKE Sandbox は、コンテナがホストと直接やり取りする必要性を減らします。ホストの不正使用を狙った攻撃範囲を縮小し、悪意のある操作者の動きを制限します。

要件 6.6

少なくとも年に一度と変更後にはアプリケーションの脆弱性を評価することにより、公開されているすべてのウェブ アプリケーションが既知の攻撃から保護されていることを確認します。

Web Security Scanner を使用すると、App Engine、Compute Engine、GKE の一般公開されているウェブ アプリケーションをスキャンして、クロスサイト スクリプティング、構成ミス、脆弱なリソースなど、一般的な脆弱性を調べることができます。スキャンは Cloud Console から実行できます。オンデマンドで実行することも、スケジュールを設定することもできます。Security Scanner API を使用すると、アプリケーション ビルド パイプラインのセキュリティ テスト スイートの一部としてスキャンを自動化できます。

強固なアクセス制御手法の実装

強固なアクセス制御手法の実装強には、PCI DSS の要件 7、8、9 が含まれます。

要件 7

カード会員データへのアクセスを業務上必要な範囲に制限します。

要件 7 では、最小限の特権と知る必要性に焦点を当てています。PCI DSS では、最小限のデータに対するアクセス権を付与し、ジョブの実行に最低限必要な特権を提供することとして、この条件を定義しています。

要件 7.1

システム コンポーネントおよびカード会員データに対するアクセスを、このような操作が業務上必要な人物にのみ許可します。

IAM と RBAC の適用により、多層防御を実現。
図 7. IAM と RBAC の適用により、多層防御を実現

IAMKubernetes のロールベースのアクセス制御(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.1.2

特権ユーザー ID に対するアクセスを制限し、ジョブの責任遂行に必要な最小限のアクセス権に制限します。

ユーザーとサービス アカウントが最小限の特権原則を遵守する場合、コンテナも同じ原則を遵守する必要があります。コンテナを実行する際のベスト プラクティスは、root 以外のユーザーがプロセスを実行することです。これを実現するには、PodSecurityPolicy を使用します。

PodSecurityPolicy は、クラスタ上でポッドを作成および更新するリクエストを検証するために作成するアドミッション コントローラ リソースです。PodSecurityPolicy は、クラスタに受け入れられるために Pod が満たす必要がある一連の条件を定義します。Pod の作成または更新のリクエストが PodSecurityPolicy の条件を満たさない場合、そのリクエストは拒否され、エラーが返されます。

この YAML ファイルの例では、PodSecurityPolicy により root 権限を必要とするコンテナの実行が許可されず、ボリューム タイプが制限付きリストで制限されています。

要件 8

PC にアクセスする利用者ごとに個別の ID を割り当てます。

要件 8 では、対象の PCI システムに対してアクセス可能な人物に 一意の ID を割り当てることが義務付けられています。また、各個人は自身が行った操作に対して責任を負わなければなりません。

要件 8.1.1

システム コンポーネントまたはカード会員データへのアクセスを許可する前に、すべてのユーザーに固有の ID を割り当てる必要があります。

要件 8.1.3

利用を停止したユーザーのアクセス権はすぐに取り消します。

IAM と Kubernetes RBAC は両方とも GKE クラスタへのアクセスを制御するために使用され、いずれの場合もユーザーに権限を付与できます。ユーザー アカウントとポリシーを 1 か所で管理できるように、既存の ID システムにアカウントを関連付けることをおすすめします。

要件 8.2

一意の ID を割り当てるだけでなく、少なくとも以下のいずれかの方法でユーザーを認証することにより、すべてのシステム コンポーネントで一般ユーザー以外のユーザーおよび管理者のユーザー認証を適切に管理します。
  • ユーザーが知っているもの(パスワード、パスフレーズなど)
  • ユーザーが持っているもの(トークン デバイスやスマートカードなど)
  • ユーザー自身(生体認証など)

ユーザーが kubectl で認証されると、証明書がユーザー ID に割り当てられます。すべての GKE クラスタは、Google Cloud のユーザー ID とサービス アカウント ID を受け入れるように構成されています。認証情報を検証し、ユーザーまたはサービス アカウントの ID に関連付けられているメールアドレスを取得できます。そのため、認証に成功するには、こうしたアカウントの認証情報に userinfo.email OAuth スコープが含まれている必要があります。

要件 9

カード所有者データへの物理的アクセスを制限します。

Google は、Google Cloud の基盤となるすべての Google データセンターの物理的なセキュリティ管理を担当しています。

定期的なネットワークのモニタリングおよびテスト

定期的なネットワークのモニタリングおよびテストには、PCI DSS の要件 10 と 11 が含まれます。

要件 10

ネットワーク リソースおよびカード会員データに対するすべてのアクセスを追跡し、監視します。

要件 10.1

監査証跡を実装して、システム コンポーネントに対するすべてのアクセスを個々のユーザーに関連付けます。

Kubernetes クラスタでは、Kubernetes 監査ロギングがデフォルトで有効になっています。これにより、Kubernetes API サーバーに対して行われた呼び出しの記録が時系列で保持されます。Kubernetes 監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリング アラートの作成に対して有用です。

GKE クラスタでは、GKE 監査ロギングのデフォルトの構成が Cloud Audit Logs および Logging と統合されます。Kubernetes 監査ログのエントリは、Google Cloud プロジェクトで表示できます。

プロジェクトの監査ログには、Kubernetes によって作成されたエントリだけでなく、GKE によって書き込まれたエントリもあります。

CDE ワークロードと CDE 以外のワークロードを区別するため、GKE ポッドにラベルを追加し、これらのワークロードから提供される指標とログに適用することをおすすめします。

要件 10.3

発生したイベントに対してシステム コンポーネントの監査証跡エントリを記録します。少なくとも、次のエントリは記録する必要があります。
  • 10.3.1: ユーザーの識別
  • 10.3.2: イベントのタイプ
  • 10.3.3: 日時
  • 10.3.4: 成功または失敗の表示
  • 10.3.5: イベントの発生源
  • 10.3.6: 影響を受けるデータ、システム コンポーネント、リソースの ID または名前

Logging では、監査ログエントリはすべて次のフィールドを含む LogEntry タイプのオブジェクトになります。

  • ペイロード。protoPayload 型になります。各監査ログエントリのペイロードは、AuditLog タイプのオブジェクトになります。ユーザー ID は、AuditLog オブジェクトの AuthenticationInfo フィールドで確認できます(10.3.1)。
  • 特定のイベント。AuditLogmethodName フィールドで確認できます(10.3.2)。
  • タイムスタンプ(10.3.3)。
  • イベントのステータス。AuditLog オブジェクトの response オブジェクトで確認できます(10.3.4)。
  • オペレーションのリクエスト。AuditLog オブジェクトの request オブジェクトと requestMetadata オブジェクトで確認できます(10.3.5)。
  • 実行されるサービス。serviceData オブジェクトの AuditData オブジェクトで確認できます(10.3.6)。

要件 11

セキュリティ システムおよび管理手順を定期的にテストします。

要件 11.2.1

四半期ごとに内部で脆弱性スキャンを実行します。脆弱性を解決し、再度スキャンを実行します。エンティティの脆弱性評価に従って、すべての「高リスク」な脆弱性が解決されていることを確認します(要件 6.1)。スキャンは有資格者が実行しなければなりません。

Container Analysis の脆弱性スキャンは、Container Registry 内のイメージに対して、次の種類の脆弱性スキャンを実行します。

  • 初期スキャン。Container Analysis API を初めて起動すると、Container Registry 内のイメージがスキャンされ、イメージのパッケージ マネージャー、イメージベース、脆弱性のオカレンスが抽出されます。

  • 差分スキャン。Container Analysis は、Container Registry にアップロードされた新しいイメージをスキャンします。

  • 継続分析: Container Analysis は、新しい脆弱性情報や更新された脆弱性情報を脆弱性ソースから取得すると、コンテナの分析を再実行し、スキャン済みイメージの脆弱性オカレンスのリストを最新の状態にします。

要件 11.4

侵入検知(IDS)や侵入防止(IPS)技術を使用して、ネットワークへの侵入を検知および防止します。CDE の境界および CDE 内の重要なポイントですべてのトラフィックを監視し、侵害の可能性について担当者に警告します。すべての侵入検知 / 侵入防止エンジン、ベースライン、署名を常に最新の状態にしておきます。

Google Cloud の Packet Mirroring を、Palo Alto Networks などのサードパーティ IDS とともに使用して、ネットワーク侵入を検出できます。Google Cloud Packet Mirroring によって、Compute Engine VM または Google Cloud クラスタからのすべてのネットワーク トラフィックが、指定されたアドレスに転送されます。Palo Alto Networks などの 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 アカウントに対する課金を防げます。

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ