このドキュメントでは、Payment Card Industry（PCI）Security Standards Council コンプライアンス用にクラウド環境を設計する際のベスト プラクティスについて説明します。ここで説明するベスト プラクティスは、PCI コンプライアンス要件が適用されるシステムをクラウド内に移行または設計している組織に役立ちます。このドキュメントでは、PCI DSS 4.0 の要件（該当する場合）について言及しています。
PCI DSS の評価対象について
組織がインターネット経由で商取引を行っている場合、PCI コンプライアンスに対応し、維持する必要があります。クラウド環境を設計して管理する方法は、システムが PCI Data Security Standard（DSS）評価の対象になっている範囲によって変わります。対象範囲の設定は、IT アセットのセキュリティと PCI コンプライアンスの遵守に重要な影響を及ぼします。PCI 環境の対象範囲の設定を適切に行うには、ビジネス プロセスと設計上の決定が範囲にどのような影響があるのかを理解する必要があります。
対象範囲とは
カード所有者データ（CHD）の保存、処理、送信を行うシステムはすべて PCI DSS 評価対象となります。セキュリティはクラウド環境全体で重要な要素ですが、対象範囲内のシステムが侵害されると、データ侵害や CHD の漏洩を招く可能性があります。
図 1 のカード所有者データ環境（CDE）、接続しているシステム、セキュリティに影響するシステムは評価対象の範囲内で、信頼できないシステムや無関係なシステムは評価対象の範囲外になります。
PCI DSS では、対象範囲内のシステムは信頼されています。対象範囲内のシステムには、CDE、それに接続しているシステム、CDE のセキュリティに影響する（または影響を与える可能性のある）システムが含まれます。
システムが同じネットワーク上にあるか、データベースまたはファイル ストレージを共有するか、CDE 内のシステムまたはプロセスにアクセスあるいは接続できる場合、システムから CHD に直接アクセスできなければ、そのシステムは接続しているシステムになります。
攻撃者が CDE に侵入し、アクセスできる場合、そのシステムはセキュリティに影響するシステムになります。接続しているシステムとセキュリティに影響するシステムは常に対象範囲内のシステムになります。
PCI DSS の定義では、対象範囲外のシステムは信頼できないシステムで、CHD または機密認証データ（SAD）へのアクセスを試みる攻撃者にとって価値のないシステムです。対象範囲内のシステムのセキュリティに影響がなければ、そのシステムは侵害されていても対象範囲外のシステムになります。対象範囲外のシステムは直接評価されませんが、PCI Qualified Security Assessor（QSA）は企業が対象範囲の設定を適切に行い、PCI DSS を遵守して CHD を保護しているかどうか検証します。このため、対象範囲の境界を厳重に保護し、継続的なモニタリングを行い、明確に文書化しておく必要があります。
PCI コンテキスト内の接続
いくつかの PCI DSS 要件で接続に関する言及がありますが、PCI DSS では接続が明示的に定義されていません。このコンテキストで接続の意味を解釈するには、PCI DSS の対象範囲の設定とネットワーク セグメンテーションに関する PCI Council のガイダンス（PDF）に記載されている対象範囲の設定の意思決定ツリーを理解する必要があります。
PCI の対象範囲を評価するため、接続は次のように定義されています。
- 2 台のコンピュータまたはシステムを接続するアクティブな情報転送が存在する
- 2 つのいずれかの当事者が通信を開始する
環境を文書化する場合は、接続の開始を承認された当事者を明確に示すことをおすすめします。ある方向のトラフィックのみを許可するようにファイアウォールを構成すると、一方向の接続に制限できます。たとえば、対象範囲内の決済処理アプリケーションが対象範囲外のデータベース サーバーにクエリを送信する場合、次のすべての条件を満たしていれば、対象範囲外のサーバーにそのままクエリを送信できます。
- 接続と対象範囲外のデータベースで CHD または SAD の保存、処理、送信を行わない。
- データベースが別のネットワーク上にあるか、CDE と別のセグメント上にある。
- データベースが、直接または間接的に CDE との通信を開始できない。
- データベースが CDE にセキュリティ サービスを提供していない。
- データベースが CDE の構成やセキュリティに影響を及ぼさない。
- データベースが PCI DSS 要件をサポートしている。
次の図に、システムの対象範囲を決定する要因を示します。
図 2 では、システムの対象範囲を次のように決定しています。
PCI DSS の対象範囲に含まれるシステム コンポーネント:
- 次のいずれかに該当する CDE 内のシステム:
- システム コンポーネントが CHD または SAD の保存、処理、送信を行う。
- システム コンポーネントが、CHD の保存、処理、送信を行うシステムと同じネットワーク セグメント上（同じサブネットや VLAN など）にある。
- 次のいずれかに該当するシステムに接続しているか、このようなシステムのセキュリティに影響を及ぼすシステム:
- システム コンポーネントが CDE に直接接続する。
- システム コンポーネントが CDE の構成とセキュリティに影響する。
- システム コンポーネントが、CDE システムを対象範囲外のシステムおよびネットワークから隔離している。
- システム コンポーネントが CDE に間接的に接続する。
- システム コンポーネントが CDE にセキュリティ サービスを提供している。
- システム コンポーネントが PCI DSS 要件をサポートしている。
- 次のいずれかに該当する CDE 内のシステム:
次のすべてに該当する場合、システム コンポーネントは信頼できない PCI DSS 対象範囲外のシステムとみなされます。
- システム コンポーネントが CHD または SAD の保存、処理、送信を行っていない。
- システム コンポーネントが、CHD または SAD の保存、処理、送信を行うシステムと同じネットワーク セグメント上（サブネットや VLAN など）に存在しない。
- システム コンポーネントが CDE 内のどのシステムにも接続できない。
- システム コンポーネントが、接続またはセキュリティに影響を及ぼすシステムの基準を満たしていない。
対象範囲外のシステムが対象範囲内のシステムのコンポーネントを使用して CDE にアクセスできないように対策が講じられていれば、接続しているシステムまたはセキュリティに影響を与えるシステム コンポーネントに接続するシステムを対象範囲外のシステムに含めることができます。
わかりやすく言えば、PCI DSS のシステムの対象範囲の定義では、セグメンテーションが適切に実装され、文書化されていれば、ウェブ アプリケーションのセッション ストアと e コマース データベースが対象範囲外とみなされる場合があります。次の図に、対象範囲内のシステムと対象範囲外のシステムとの間で読み取りと書き込みの接続がどのように行われるのかを示します。
図 3 は、次の接続を示しています。
- 読み取りのみ:
- 対象範囲内の決済処理アプリケーションが、対象範囲内のカート データベースからカート ID を読み取り、DNS と NTP からデータを読み取ります。
- 書き込みのみ:
- 対象範囲内の決済処理アプリケーションが、対象範囲外のアプリケーションのメイン データベースと Cloud Logging に書き込みを行います。
- 対象範囲外のメイン ウェブ アプリケーションがロギング サービスにデータを書き込みます。このデータに CHD と SAD は含まれません。
- 読み取りと書き込み:
- 公開ウェブのユーザーが、次のようにリクエスト メタデータの読み取りと書き込みを行います。
- ユーザーが対象範囲内の決済処理アプリケーションに対して読み取りと書き込みを行います。このリクエストのメタデータは、CHD と SAD を含むカート ID とカート認証キーです。
- ユーザーが対象範囲外のメイン ウェブ アプリケーションに対して読み取りと書き込みを行います。このリクエストのメタデータは、CHD または SAD を含まないセッション ID です。
- 対象範囲外のメイン ウェブ アプリケーションが、対象範囲外のカート データベース、セッション ストア、アプリケーションのメイン データベースに対してデータの読み取りと書き込みを行います。このデータに CHD と SAD は含まれません。
- 対象範囲内の決済処理アプリケーションが、対象範囲内のカードトークン化サービスと公開ウェブのクレジット カード プロセッサにデータの読み取りと書き込みを行います。このデータには CHD と SAD が含まれます。
- 公開ウェブのユーザーが、次のようにリクエスト メタデータの読み取りと書き込みを行います。
図 3 のアーキテクチャでは、PCI の対象範囲外であるメイン ウェブ アプリケーション（メイン アプリケーション）と、対象範囲内の決済処理アプリケーション（チェックアウト アプリケーション）の 2 つの独立したウェブ アプリケーションが存在します。このアーキテクチャでは、前述のリストに示した方法でのみ、2 つのエンティティ間の接続を開始できます。呼び出し側から見ると、エンティティ間の接続で読み取りのみ、読み取りと書き込み、または書き込みのみが可能です。明示的に記述されていないパスやリクエスト方向は、セグメンテーションによってブロックされます。たとえば、決済処理アプリケーションはカート データベースから読み取り、ロギング サービスに書き込むことができますが、この中には、これらのエンティティに対する接続の開始も含まれます。
一般に、対象範囲内のシステムは対象範囲外のシステムまたはサービスを呼び出しますが、リモートの呼び出し側（カード所有者以外）が直接または直接的に CDE への接続を開始しないため、このような接続の安全性は確保されています。図 3 は、チェックアウト アプリケーションの内向き方向の唯一のパスがユーザーであることを示しています。
図 3 の決済処理アプリケーションに構成データまたはセキュリティ データが提供されることはありません。これらのデータは、アーキテクチャ内を次のように送信されます。
- メイン アプリケーションは、ユーザーをチェックアウト アプリケーションに転送し、HTTP
POSTを使用してCartIDとCartAuthKeyというバリデータを送信します。CartAuthKeyはCartIDのハッシュで、メイン アプリケーションとチェックアウト アプリケーションでのみ認識される事前共有シークレットです。 - チェックアウト アプリケーションは、
CartIDとシークレットをハッシュ化し、その値をCartAuthKeyと比較することにより、ユーザーの検証を行います。 - ユーザーデータが認証されると、
CartIDを使用してカート データベースからカートの内容を読み取ります。カード所有者データはすべて、ユーザーから直接チェックアウト アプリケーションに送信されます。 - 決済プロファイルを使用する場合、カード所有者のデータはトークン化サービスに保存されます。
- 支払いが処理されると、書き込み専用データベースのサービス アカウントを使用して、メイン アプリケーションのデータベースに結果を挿入します。
対象範囲の設定に関する考慮事項
PCI DSS の対象範囲の設定とネットワーク セグメンテーションのガイドラインでは、PCI Security Standards Council（SSC）は、検証が完了するまですべてを対象範囲内にすることを推奨しています。この SSC の推奨事項は、可能な限り範囲を広くしなければならない意味ではありません。QSA では、CDE に接続していないシステムまたは CDE のセキュリティに影響のないシステムを除いて、すべてのシステムを信頼できるシステムとして評価します。規制の要件を満たし、IT アセットを保護するには、最小権限の原則に従って最小限のシステムを信頼し、環境の対象範囲の設定を行う必要があります。
評価を行う前に、環境を見直して対象範囲内と対象範囲外のシステムの境界を把握し、文書化します。QSA の最初のタスクは、文書化された対象範囲が CDE システムとそれに接続するシステムを合理的に網羅していることを確認することです。全体的な評価の一環として、QSA は、対象範囲外のシステムが対象範囲内のシステムに悪影響を及ぼすかどうか検証します。
次のような、環境に固有の特殊な状況を把握してください。
- 電話または VOIP システムを介してカード所有者のデータを収集する場合は、電話ベースで決済カードデータを保護する（PDF）に記載されている対象範囲の設定の問題を検討してください。
- POS システムを稼働させるためにサービス プロバイダが CDE にアクセスする必要がある（PDF）場合、サービス プロバイダの使用するシステムが接続しているシステムとみなされる可能性があります。これには、対象範囲の設定とデュー デリジェンスの考慮事項が必要になる場合があります。
Google のセキュリティのベスト プラクティスを行うと、対象範囲内のシステムと信頼できないシステムの間に明確で許容可能な境界を確立し、提示できます。最小権限の原則を実践してアクセスとセキュリティを管理すると、カード所有者データの露出ポイントと CDE の攻撃対象領域を最小限に抑え、対象範囲を大幅に小さくすることができます。対象範囲内のシステムのフットプリントを小さくすることで、システムの複雑さを軽減し、PCI DSS の評価を効率的に行うことができます。
対象範囲の設定が適切でない場合のリスク
対象範囲が広すぎると、評価コストが増加し、コンプライアンス リスクが増大する可能性があります。対象範囲を狭めるには、システムの数をできるだけ少なくし、少数の指定されたユーザーにのみアクセス権を付与するようにします。評価と自己評価をこまめに行うことで、PCI DSS の対象とすべきでないシステムを特定できます。また、対象範囲外のシステムのガイドラインを満たしていることを確認し、それに応じて対象範囲を狭めることができます。除外プロセスは、信頼できないシステムを発見し、対象範囲内のシステムに影響を与えないようにする最も安全な方法です。
PCI DSS の要件を満たすために大規模なインフラストラクチャ フットプリントが必要な場合は、不要なシステムが評価対象に含まれている可能性があります。対象範囲に不要なシステムを含めると、コンプライアンス違反のリスクが高まります。また、信頼できる対象範囲内の環境に攻撃対象領域を拡大することで、全体的なセキュリティ ポスチャーを低下させる可能性もあります。
ネットワーク セキュリティと PCI DSS の基本原則は、ネットワークの一部または全体が侵害されていることを前提としています。この原則は、Google のゼロトラスト セキュリティ モデルでも採用されています。このモデルでは、境界専用のセキュリティではなく、それぞれのシステムで自身を保護するモデルを使用することを推奨しています。Google のセキュリティ モデルは PCI DSS と一致しています。CDE とそれに接続しているシステムは、広範囲の IT 環境ではなく、そこから分離された小規模で信頼できる場所にデプロイされます。
対象範囲内の PCI 環境では、広範囲で大規模な信頼できるスペースに CDE を配置しないでください。このような場所に配置すると、セキュリティに対する誤解を招き、包括的な多層防御戦略の抑制につながる可能性があります。境界のセキュリティの突破に成功した攻撃者は、信頼できるプライベート イントラネットに簡単に侵入し、攻撃を実行できます。境界セキュリティのみに依存せず、信頼できるスペースに運用と保護に必要なものだけを含める方法を検討してください。これらの原則を理解して遵守することにより、重要なシステムを保護し、侵害されたシステムからのリスクを軽減できるクラウド環境を設計できます。
大規模な対象範囲内にある信頼できるシステムには、システムのモニタリング、メンテナンス、監査、インベントリの継続的な管理のため、大規模な管理アプリケーションが必要になります。システム アーキテクチャ、チェンジ マネジメント プロセス、アクセス制御ポリシーの複雑さにより、セキュリティ リスクとコンプライアンス リスクが発生する可能性があります。これらのモニタリング プロセスの維持が難しいと、PCI DSS 要件 10 と 11 を満たすことが難しくなる可能性があります。これらのリスクを理解し、評価される環境の対象範囲を限定する戦略を実装することが重要です。詳細については、このドキュメントの継続的なコンプライアンスをサポートするをご覧ください。
PCI DSS の対象となる Google Cloud サービス
PCI 環境の対象範囲を修正する前に、PCI DSS の対象となる Google Cloud サービスを確認しておきましょう。これらのサービスが提供するインフラストラクチャ上で、カード所有者データの保存、処理、送信を行う独自のサービスやアプリケーションを構築できます。
対象範囲を狭める方法
このセクションでは、評価対象を減らす方法として、リソース階層の制御、VPC Service Controls セグメンテーション、トークン化について説明します。できる限り対象範囲を縮小できるように、1 つの方法を選ぶのではなく、これらの方法をすべて行うことを検討してください。
PCI の対象範囲の設定に普遍的な解決策はありません。オンプレミス ネットワークですでにセグメンテーションを行っている場合もあれば、カード決済ソリューションが原因でインフラストラクチャの設計がここで説明しているものとは違う場合もあります。ここで説明する方法はあくまで原則であり、お客様独自の環境に合わせて応用できます。
リソース階層制御を確立する
Google Cloud のリソースは階層的に編成されています。
- 組織リソースは、Google Cloud リソース階層のルートノードになります。組織リソースには、フォルダとプロジェクトのリソースが含まれます。組織リソースに適用されるアクセス制御ポリシー（Identity and Access Management（IAM））は、組織内のすべてのリソースの階層全体に適用されます。
- フォルダには、プロジェクトやその他のフォルダを作成できます。また、フォルダレベルの IAM 権限を使用してリソースへのアクセスを制御できます。フォルダは、類似したプロジェクトをまとめる場合もよく使用されます。
- プロジェクトはすべてのリソースの信頼境界であり、IAM の適用ポイントになります。
評価の対象範囲を縮小するには、Google のベスト プラクティスに沿ってリソース階層を定義します。次の図は、PCI コンプライアンス用のリソース階層の例を示しています。
図 4 では、PCI の対象範囲に含まれるすべてのプロジェクトを 1 つのフォルダにまとめて、フォルダレベルで隔離しています。PCI 対象範囲のフォルダには、CDE のほかに、共有サービスを含む別のプロジェクトが含まれています。同様のリソース階層を実装すると、PCI 対象範囲のフォルダが PCI コンプライアンスの対象範囲の論理ルートになります。指定したユーザーのみがこのフォルダとそのプロジェクトにアクセスできるので、階層内の他のフォルダ、プロジェクト、リソースを評価対象から除外できます。
必要に応じて、ユーザーが必要とするフォルダとプロジェクトにのみアクセスを許可する場合は、対象範囲内のコンポーネントに対するアクセス権を特定のユーザーのみに付与します。これは、PCI DSS 要件 7.2、7.3（PDF）などに対応しています。親組織とフォルダに対する権限を適切に設定するには、ポリシーの継承による影響を理解してください。PCI DSS 要件 8.4.1 に対応するには、指定ユーザーに多要素認証（MFA）を適用します。詳しくは、多要素認証に関する PCI DSS の補足ガイダンス（PDF）をご覧ください。リソース階層でコンプライアンスを維持するには、組織のポリシーの制約の設定方法を理解しておく必要があります。これらの制約は、継続的なコンプライアンスをサポートし、信頼された環境を権限昇格から保護するのに役立ちます。
他の PCI コンプライアンスと同様に、明確な対象範囲の境界を設定するには、環境と対象範囲内のコンポーネントに対して適切なロギングとモニタリングを行う必要があります。リソース階層は Identity and Access Management と密接に結びついています。分離を行い、維持するには、ユーザー アクションのロギング、監査、モニタリングを効果的に行う必要があります。
ネットワーク セグメンテーションを実装する
PCI SSC のネットワーク セグメンテーションに関する補足ガイド（PDF）で説明されているように、ネットワーク セグメンテーションは CDE とその接続システムを保護する重要なアーキテクチャ パターンです。ネットワーク セグメンテーションが適切に実装されると、信頼できないシステムが CDE またはそれに接続しているコンポーネントにアクセスするために利用するネットワーク ルートを排除し、評価対象を狭めることができます。信頼できるコンポーネント間の通信に必要なルートのみを定義します。信頼できないシステムに、信頼できるシステムとパケットの送受信を行うルートがない場合、信頼できないシステムは対象範囲外で、対象範囲内のコンポーネントのセキュリティに影響を及ぼすこともありません。
ネットワーク セグメンテーションを実装するには、VPC Service Controls を有効にして、専用の Virtual Private Cloud（VPC）に CDE を配置します。余分なサブネットまたはルートが作成され、信頼できるネットワークへのデフォルトのアクセスが可能にならないように、この VPC はカスタムモードで作成します。この VPC を他のプロジェクトと共有できず、他の信頼できるネットワークとのみピアリングできるように、組織のポリシーの制約を実装します。
次の図は、ネットワーク セグメンテーション戦略がリソース階層とどのように関係しているかを示しています。上の図では、対象範囲内の PCI 環境用の 1 つのフォルダがあり、そのフォルダに CDE と共有サービス用の 2 つのプロジェクトが存在するリソース階層を想定しています。
図 5 で、共有サービスのプロジェクトは CDE には含まれていませんが、これは接続しているシステムのため、PCI の対象となっています。CDE へのアクセスは、ロードバランサとファイアウォール ルールまたはファイアウォール ポリシーによってネットワーク レベルで制限されています。これにより、ネットワークを保護し、PCI DSS 要件 1.2 および 1.3 の条件を満たしています。トークン化システムと決済処理システムは別のサブネットに配置されています。必要な通信のみが許可されるように、各サブネット間のファイアウォール ルールで通信が制御されています。PCI DSS 要件 10.2、10.4、10.5 を満たすロギング、モニタリング、アラートの各機能は別々のプロジェクト内にあります。IAM アクセス制御の誤構成や不正使用から保護するために、共有サービスと CDE は VPC Service Controls セキュリティ境界内にあります。
Google Kubernetes Engine（GKE）上にデプロイされている場合は、次の方法で CDE をセグメント化し、信頼できないシステムからカード所有者データを保護できます。
- Namespace を使用すると、アクセス制御の分離に新たなレイヤを追加できます。これにより、ユーザーは Kubernetes クラスタ内の特定の Pod、Service、Deployment にのみアクセスが許可されます。これは、指定したユーザーのアクセスをきめ細かく制御する場合に役立ちます。
- ネットワーク ポリシーを使用すると、Pod と Service を相互に分離してデータフローを制限できます。また、クラスタ内でネットワーク セグメンテーションのレイヤを追加することもできます。
- PodSecurity は Kubernetes アドミッション コントローラであり、これにより GKE クラスタで実行されている Pod に Pod セキュリティ基準を適用できます。
これらのレイヤは多層防御セキュリティの重要な部分です。信頼されたコンポーネントを周囲の環境から隔離して保護することで、対象範囲をさらに絞り込むことができます。Kubernetes を使用して CDE の全体または一部をデプロイする場合は、GKE で PCI 遵守の環境を実行するで詳細を確認してください。
トークン化の実装
トークン化は、カード会員番号（PAN）を不可逆的に難読化するプロセスです。トークン化された PAN（トークン）から数学的な手法で PAN を取得できません。PCI SSC は、トークン化ガイドラインの補足（PDF）の第 3 章でトークン化の対象範囲の設定への影響に関するガイダンスを提供します。PCI DSS の対象範囲は、カード所有者データの保存と送信を行う一連のコンポーネントによって影響を受けます。適切にトークン化すると、カード会員番号の出現と送信を最小限に抑え、評価対象を狭めることができます。
トークン化は、トークンのみを使用して処理を実行できるシステムからカード所有者データの保存と送信を行うシステムが分離されるため、データフローによるセグメンテーションの 1 つともいえます。たとえば、ユーザーの不正行為を分析するシステムでは、PAN は必要ないかもしれませんが、トークン化されたデータを分析に使用することは可能です。また、トークン化により、PAN の保存と転送を行うシステムと e コマース ウェブ アプリケーション分離するレイヤが追加されます。ウェブ アプリケーションが、トークンを使用するシステムのみとやり取りを行う場合は、接続しているシステムのセットから、そのウェブ アプリケーションを削除して対象範囲を縮小できます。
次の図は、一般的なトークン化システムで CHD、PAN、トークン化されたデータがどのように処理されるかを示しています。
図 6 では、ユーザーから PAN とその他のカード所有者データが送信され、それらのデータがトークン化サービスに送信されます。トークン化サービスは、PAN を暗号化してトークンを生成し、セキュア トークンの Vault に保存します。決済サービスなどの指定サービスのみがネットワーク上の Vault にアクセスできます。また、これらのシステムには、生成されたトークンを使用して PAN を利用することも許可されます。決済サービスは、決済代行業者に送信する場合にのみ PAN を使用します。この厳密に管理されたデータフロー以外では、PAN やその他のカード所有者データは存在しません。多層防御戦略の一環として、このアーキテクチャでは、PAN やカード所有者データなどの予期しない漏洩を防ぐため、機密データの保護も使用しています。
図 6 では、トークン化システムが、厳重に保護されたシークレット ストアである Hashicorp Vault を使用して、PAN とトークンのマッピングを管理しています。認可されたユーザーとサービスだけがルックアップ プロセスを使用してトークンから PAN を取得します。トークンの Vault へのアクセスが許可されたコンポーネントには、時間制限のあるアクセス権が付与されます。コンポーネントは、その機能の実行に必要な特定の時間枠にのみ PAN を利用できます。ビジネスの要件に応じて、他のデータストアのほうが適切な場合もあります。環境でトークン化を安全に実装する方法については、PCI DSS に準拠した、機密性の高いカード所有者データのトークン化をご覧ください。
アーキテクチャの例
次の図は、Pub/Sub と Dataflow を使用してトークン化されたトランザクションを処理し、トークン化されたトランザクション レコードを Spanner に保存するアーキテクチャの例を示しています。
図 7 で、トランザクション処理プロジェクトは、接続しているシステムであり、PCI の対象です。トランザクション処理プロジェクトのコンポーネントが侵害されても、攻撃者が CHD にアクセスできないため、セキュリティには影響しません。webapp プロジェクトは、CDE に接続せず、サニタイズされたデータのみをやり取りしているので、対象範囲外になります。
トークン化されたデータは CDE から Pub/Sub に送信されます。トークン化されたデータが他のサブスクライバーに公開される前に、Sensitive Data Protection は CHD が含まれていないことを確認します。トークン化されたデータは Dataflow によって処理され、Spanner トランザクション データベースに保存されます。PAN にアクセスせずに、トークンでトランザクションを特定のユーザーに関連付けることができます。Looker などのビジネス インテリジェンス（BI）ツールを使用して、レポートや分析を行う際に Spanner トランザクション データベースを使用することもできます。
継続的なコンプライアンスのサポート
適切なアーキテクチャと優れたエンジニアリングだけでは、十分なセキュリティとコンプライアンスを実現することはできません。正しいアーキテクチャを使用すれば、環境が理論上安全に設計されていることを示すことができます。ご使用の環境が実際に安全を確保できるように、効果的な監査、ロギング、モニタリング、修復のプロセスを実装する必要があります。
PCI DSS 要件の 12 のカテゴリそれぞれに対応するには、その要件の実装を継続的にモニタリングする必要があります。PCI DSS の評価が完了した後は、対象範囲内のコンポーネントの安全が今後も維持されることを証明する必要があります。適切な対策と迅速な対応の実施は継続的コンプライアンスと呼ばれています。継続的コンプライアンスは PCI DSS の要件であり、適切に実装すれば、対象範囲を狭める他の方法の効果を高めることができます。
Google Cloud では、ファイアウォール ルールのロギング、VPC フローログ、VPC Service Controls のログ、Cloud Load Balancing のログを使用して、ネットワーク内で発生するすべてのイベントを記録できます。システムとユーザーのアクティビティは Cloud Audit Logs でモニタリングできます。これらのログを定期的に確認することで、PCI DSS 要件 10.4 に準拠して、潜在的なセキュリティ脅威にすばやく対応し、問題を修正できます。詳細については、毎日の効果的なログ モニタリングに関する PCI DSS の補足（PDF）をご覧ください。
Security Command Center でアセット インベントリ、検出、検索、管理を行い、セキュリティとデータに対する攻撃範囲を把握できます。Security Command Center では、機密データの保護スキャン結果を分析して、漏洩したカード所有者データの特定をしたり、トークン化システムの誤使用で PAN が悪用されていないかどうかを確認したりできます。Event Threat Detection を使用すると、Security Command Center でネットワークと VM に対する脅威や異常なアクティビティを早期に検出できます。これらの兆候は、攻撃者がシステムの防御機能を偵察している可能性を示しています。また、Security Command Center では、環境に固有のカスタム セキュリティ ソースを作成できます。
Google Cloud Armor を使用すると、公開された Google Cloud ウェブ アプリケーションの保護を強化できます。これは PCI DSS 要件 6.4 の遵守に役立ちます。Google Cloud Armor は、受信リクエストを評価し、一般的なウェブ攻撃の有無を確認します。要件 6.4 には、時間のかかる手動によるコードレビューが規定されていますが、このような手間のかかる作業の軽減にも役立ちます。WAF を導入すると、継続的コンプライアンスを行いながら、コンプライアンスの費用とリスクを軽減できます。
次のステップ
- コンプライアンス義務を管理するためのベスト プラクティスを確認する。
- Google Cloud での PCI データ セキュリティ基準の準拠を読む。
- PCI DSS の対象範囲の設定とネットワーク セグメンテーションに関する PCI Council のガイダンス（PDF）を読む。
- GKE ブループリントの PCI を試す。
- PCI DSS 準拠のため Kubernetes ワークロードを保護する。
- PCI DSS 準拠のため、機密性の高いカード所有者データをトークン化する。
- PCI Starter Terraform プロジェクトをデプロイする。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。