このガイドでは、ビジネスのために Google Cloud に Payment Card Industry Data Security Standard（PCI DSS）を実装する方法を学びます。このガイドでは、この基準の背景について PCI SSC クラウド コンピューティング ガイドライン（PDF）よりも詳しく説明します。クラウドベースのコンプライアンスにおけるカード事業者の役割について説明した後、PCI DSS を使用して支払い処理アプリを設計、デプロイ、構成するためのガイドラインを示します。このチュートリアルでは、アプリのモニタリング、ロギング、検証を行う方法についても説明します。
このドキュメントでは、PCI DSS 4.0 の要件（該当する場合）について言及しています。
PCI Data Security Standard は、PCI Security Standards Council によって策定された、支払いカード（クレジット カードとデビットカードの両方）の情報を処理する企業のための情報セキュリティ基準です。PCI Security Standards Council には多数の主要な支払いカード会社が参加しています。Visa、MasterCard、Discover、American Express、JCB、UnionPay のカード加盟店は PCI DSS を遵守することが求められ、遵守していない場合は罰金やペナルティを課せられることがあります。
PCI DSS には、直接、支払い情報を収集する事業者から、支払い処理を完全に外部委託している事業者に至るまでの複数の事業者タイプについての分類があります。このガイドでは、SAQ A、SAQ A-EP、SAQ D の事業者タイプについて説明します。
目標
- 支払い処理アプリのアーキテクチャを確認する
- 支払い処理環境を設定する
- アプリサーバーをデプロイおよび構成する
- ロギングとモニタリングを設定する
- 支払い処理環境を検証する
定義
このガイドでは独特な用語を多数使用します。以下に、よく使用する用語をいくつか示します。詳細については、PCI DSS 用語集をご覧ください。
CDE: カード会員データ環境（Cardholder Data Environment）の頭字語。これは、カードの支払い口座番号や個人情報などのカード会員データを保持または転送するアプリの任意の要素を指します。
補完的統制: 正当な技術的制約または文書化されたビジネス上の制約のためにある事業体が規定どおり明示的に要件を満たせない場合に検討できる代替ソリューション。事業体は、これらの他の統制を実施する際に、この要件に関連するリスクを十分に軽減する必要があります。補完的統制の適用方法については、PCI DSS の要件とセキュリティ評価手順の付録 B と C の「補完的統制」をご覧ください。
PAN: プライマリ アカウント番号（Primary Account Number）の頭字語で、アカウント番号とも呼ばれます。カード発行会社およびカード所有者のアカウントを識別する一意の支払いカード番号です。
QSA: 認定セキュリティ評価機関（Qualified Security Assessor）の頭字語。QSA は PCI Security Standards Council（SSC）により PCI DSS のオンサイト評価を行う資格を認定されています。 認定セキュリティ評価機関（QSA）の認定要件では、QSA 企業と従業員の要件の詳細を提示しています。
SAQ: 自己問診（Self-Assessment Questionnaire）の頭字語。事業体の PCI DSS 評価において自己診断結果を文書化するために使用するレポートツールです。 これは、自己診断の対象となる事業体にのみ適用されます。
スコープ: PCI DSS 評価の対象となるシステム、手順、人員。
トークン化: プライマリ アカウント番号（PAN）をトークンと呼ばれるサロゲート値に置き換えるプロセス。PAN はその後、セキュア ルックアップに保管されます。トークンによって PAN を参照する逆のプロセスがトークン解除です。トークンはハッシュまたは割り当てられた値のいずれかにできます。
背景
PCI DSS では、カード所有者のセキュリティを強化することを意図した要件のリストが提供されています。これらの要件は、番号が付いた 12 の主要区分に分割され、さらに多くの下位区分に分かれています。このドキュメントでは、情報を補完するためにこれらの区分番号を引用していますが、該当する要件をすべて引用しているわけではありません。
PCI DSS 準拠の要件は、会社での支払いカードのトランザクションの処理方法（タイプ）と、毎年実行するトランザクション件数（レベル）によって異なります。
トランザクション件数が増加すると、PCI DSS の事業者レベルが上がり、PCI DSS の遵守ガイドラインがより厳しくなります。最も高い事業者レベルであるレベル 1 では、PCI DSS から監査を求められます。レベル要件はカードのブランドによって異なります。American Express では年間のトランザクション数が 250 万件、Visa、Mastercard、Discover では年間のトランザクション数が 600 万件に達するとレベル 1 になります。各カードブランドには、このドキュメントでは扱っていない追加のレベル要件があります。自社の支払い処理環境について、それぞれの事業者レベルに即した監査を必ず受けてください。
Google Cloud はレベル 1 の PCI DSS 4.0 を遵守したサービス プロバイダであるため、事業者レベルにかかわらず、PCI DSS を遵守するための要件をサポートできます。コンプライアンスへの取り組みセクションには、Google が扱っている領域が記載されています。
もう 1 つの基本的な変数は SAQ タイプです。SAQ には、自己診断の対象となる場合に PCI DSS を遵守するうえで対処する必要がある基準が記載されています。SAQ タイプは、アプリのアーキテクチャと、支払いカードデータの詳細な処理方法によって決まります。クラウド内のほとんどの事業者は以下のいずれかです。
| SAQ タイプ | 説明 |
|---|---|
| A | 支払いカードの処理を第三者のサイトに完全委託した事業者。お客様は事業者のドメインを離れ（<iframe> ウェブフォームを使用する場合を含む）、支払いを完了してから事業者のアプリに戻ります。つまり、事業者はお客様のカードデータに一切触れることができません。 |
| A-EP | 支払い処理を第三者のプロバイダに委託するが、処理中の任意の時点でお客様のカードデータにアクセスできる事業者。カードデータにアクセスできる事業者には、第三者の支払いページに埋め込まれた JavaScript や CSS などのページ要素を管理する事業者も含まれます。 つまり、事業者の支払い処理アプリがクライアント側の支払い処理業者にカードデータを転送するか、または事業者がホストするコンテンツを支払い処理業者がレンダリングします。 |
| D | オンラインで支払いを受け付けるが、SAQ A または SAQ A-EP の資格を持たない事業者。このタイプには、トークン化の有無にかかわらず、自社のサーバーから支払い処理業者の API を呼び出すすべての事業者が含まれます。 つまり、SAQ A でも SAQ A-EP でもない事業者が SAQ D です。 SAQ D では、事業者とサービス プロバイダが区別されます。このドキュメントではサービス プロバイダには触れておらず、SAQ D について言及するときは常に PCI DSS で定義される事業者のことを指しています。 |
コンプライアンスへの取り組み
Google では、さまざまな技術と処理を使用して、Google サーバーに保存されている情報を保護しています。Google は、Google が管理している Google Cloud テクノロジーとインフラストラクチャに適用される PCI DSS 要件を独自に検証しました。Google の PCI DSS コンプライアンス レポートは、Compliance Reports Manager からダウンロードできます。Google は、Google インフラストラクチャ上で実行されるコンピューティング インスタンスの多くの制御機能を事業者に提供しますが、事業者が Google Cloud にデプロイするオペレーティング システム、パッケージ、アプリのセキュリティは制御しません。事業者がデプロイするオペレーティング システム、パッケージ、アプリ（さらには、使用するアーキテクチャで必要な他のカスタマイズ）について PCI DSS 要件を遵守することは、事業者の責任です。
Google Cloud は、レベル 1 のサービス プロバイダと、該当するすべてのサービス プロバイダに対して規定された PCI DSS 要件を遵守しています。Google Cloud 責任分担表では、PCI DSS の遵守義務について概説しています。この責任マトリックスは、PCI DSS の遵守を徹底し、自社で PCI DSS 監査を実施する際の参考になります。
プロダクトのガイダンス
このセクションでは、PCI DSS 環境用のアーキテクチャでよく使用される Google Cloud サービスのガイダンスについて説明します。
App Engine
App Engine の上り（内向き）ファイアウォール ルールと下り（外向き）トラフィック制御を使用します。
Cloud Run
Cloud Run の上り（内向き）設定、VPC Service Controls、VPC コネクタの下り（外向き）制御を使用します。必要に応じて、アウトバウンドの静的 IP アドレスを構成します。
Cloud Functions
Cloud Functions の上り（内向き）と下り（外向き）のネットワーク設定を使用します。
Cloud Logging
Cloud Logging を使用してインタラクションをロギングします。
Cloud Monitoring
Cloud Monitoring を使用してインタラクションをモニタリングします。
Google Kubernetes Engine
PCI DSS 環境での Google Kubernetes Engine の使用については、GKE での PCI DSS コンプライアンスをご覧ください。
Cloud Storage
要件 3.5 では、メインの口座番号（PAN）が保管されている場所は常に保護されていることが規定されています。Google は保存中の暗号化機能を自動的に提供しますが、ルールがさらに求める一方向ハッシュ、切り捨て、またはトークン化は自動的に実行されません。
アーキテクチャ例
このセクションでは、SAQ A、SAQ A-EP、および SAQ D に準拠する環境を実装する方法について説明します。
アーキテクチャの概要
SAQ A
SAQ A は最も基本的な支払い処理アーキテクチャです。支払いは第三者によって処理され、事業者のアプリまたはページからカードデータにアクセスすることはありません。
支払い処理フローの概要は次のとおりです。
お客様は商品を選択して購入手続きを進めます。
決済用アプリは、お客様を第三者の支払い処理業者にリダイレクトします。
お客様は、第三者の処理業者が所有および管理する支払いフォームに支払いカード情報を入力します。
第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。
トランザクションを処理した後、第三者の支払い処理業者はトランザクションの詳細情報と一緒にお客様を事業者アプリに戻します。
事業者アプリは、トランザクションを確定するために支払い処理業者に確認リクエストを送信します。
決済代行業者はトランザクションの詳細を確認して応答します。
SAQ A-EP
SAQ A-EP 支払い処理アーキテクチャでは、Compute Engine 仮想マシン インスタンスで実行される支払い処理アプリが中核となります。これらのインスタンスは、安全なプライベート ネットワーク内に存在し、安全なチャネルを使用して、このネットワークの外側にあるサービスと通信します。
支払い処理フローの概要は次のとおりです。
お客様は、事業者が所有および管理する支払いフォームに支払いカード情報を入力します。
お客様が自分の情報を送信すると、そのフォーム情報は第三者の支払い処理業者に安全に渡されます。
第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。
支払い処理業者は事業者の支払い処理アプリにレスポンスを送信します。次いで、このアプリが事業者のコアアプリにメッセージを渡します。
こうしたやり取りはすべて Cloud Logging によってロギングされ、Cloud Monitoring によってモニタリングされます。
SAQ D
SAQ D 支払い処理アーキテクチャでは、Compute Engine 仮想マシン インスタンスで実行される支払い処理アプリが中核となります。これらのインスタンスは、安全なプライベート ネットワーク内に存在し、安全なチャネルを使用して、このネットワークの外側にあるサービスと通信します。
支払い処理フローの概要は次のとおりです。
お客様は、事業者が所有および管理する支払いフォームに支払いカード情報を入力します。
お客様が自分の情報を送信すると、事業者の支払い処理アプリがフォーム情報を受け取ります。
事業者の支払い処理アプリは支払い情報を確認し、その情報をバックエンド API を通じて第三者の支払い処理業者に安全に渡します。
第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。
支払い処理業者は事業者の支払い処理アプリにレスポンスを送信します。次いで、このアプリが事業者のコアアプリにメッセージを渡します。
上記のやりとりはすべて Logging によって記録され、Monitoring によってモニタリングされます。
支払い処理のお客様対応フロー
SAQ A
このセクションでは、第三者の支払い処理フローについて、アプリを使用するお客様の観点から説明します。
お客様が支払いフォームにアクセスすると、アプリは支払い処理業者がホストする <iframe> を提示します。クロスオリジン リソース シェアリング制限のため、アプリは <iframe> のコンテンツにアクセスすることも、コンテンツをモニタリングすることもできません。お客様が自分の支払いカード情報を送信すると、支払い処理業者はカードを受け付けるか拒否した後、お客様を事業者のアプリに戻します。その後、アプリは支払い処理業者からのトランザクション レスポンスを確認し、それに応じて動作します。事業者のアプリは支払いカード情報にアクセスせず、処理も行いません。
SAQ A-EP
このセクションでは、前述の内部支払い処理フローについて、アプリを使用するお客様の観点から説明します。
お客様が事業者の支払いフォームの URL にアクセスすると、事業者の支払い処理アプリがホストするフォームがサイトに表示されます。お客様が支払いに使用するカード情報を送信すると、そのフォームは決済代行業者に送られます。支払い処理業者はカードを受け付けるか拒否した後、お客様を事業者のアプリに戻します。その後、アプリは支払い処理業者からのトランザクション レスポンスを確認し、それに応じて動作します。お客様は第三者の決済代行業者を認識することなく、サーバー側の事業者アプリも支払いカード情報にアクセスしません。
SAQ D
このセクションでは、内部支払い処理フローについて、アプリを使用するお客様の観点から説明します。
お客様が事業者の支払いフォームの URL にアクセスすると、HTTPS ロードバランサを通じて安全にフォームにルーティングされます。そして、自分の支払いカード情報を送信すると、事業者の支払い処理アプリがその情報を第三者の支払い処理業者に安全に送信します。第三者の支払い処理業者は、カードを受け付けるか拒否した後、事業者の支払い処理アプリにレスポンスを返します。
支払い処理の内部フロー
SAQ A および SAQ A-EP
このセクションでは、支払い処理フローについて、アプリを実行するサーバーの観点から説明します。
事業者の支払い処理アプリは、第三者の支払い処理業者から返されたレスポンスを受信して解析し、レスポンス データの一部または全部をコアアプリに送信します。この時点で、事業者の支払い処理アプリはトランザクションの処理を終了します。コアアプリがお客様に通知するタスクを処理します。
SAQ D
このセクションでは、内部支払い処理フローについて、アプリを実行するサーバーの観点から説明します。
事業者の支払い処理アプリは、お客様が送信した支払いカード情報を確認し、バックエンド API を通じて支払い処理業者にその情報を送信します。処理業者は請求を試み、トランザクションの詳細情報を付けて応答します。事業者のアプリはレスポンスを受信して処理し、レスポンス データの一部または全部をコアアプリに送信します。この時点で、事業者の支払い処理アプリはトランザクションの処理を終了します。コアアプリがお客様に通知して商品を配送するタスクを処理します。
データのモニタリングとロギングのフロー
モニタリングとロギングのフローは、次のように設計されています。
支払い処理環境の設定
このセクションでは、支払い処理環境を設定する方法について説明します。設定には次の作業が含まれます。
- 支払い処理環境を本番環境から分離するための新しい Google Cloud アカウントを作成する
- 環境へのアクセスを制限する
- 仮想リソースを設定する
- アプリサーバーの設定に使用する Linux のベースイメージを設計する
- 安全なパッケージ管理ソリューションを実装する
新しいアカウントを設定する
アクセス制限とコンプライアンス監査を簡素化するには、標準の本番環境およびあらゆる開発環境と QA 環境から完全に分離された、本番稼働品質の支払い処理環境を作成します（要件 6.5.3）。確実に分離するには、コア本番環境のアカウントとは別の Google Cloud アカウントを作成して使用します。Identity and Access Management（IAM）を構成した経験があるユーザーは、スコープ内作業で別々のプロジェクトを使用することで、同等の分離を実現できます。
環境へのアクセスの制限
支払いシステムコードをデプロイする人、または支払いシステムのパソコンを管理する人にのみ支払い処理環境へのアクセスを許可します（7.2 章および要件 8.2.1）。これを最小権限の原則といいます。Cloud IAM のロールを使用してアクセスを制限します。可能な限りロールを使用すること、想定される作業を実行するために必要な権限のみを許可すること、サービスへの完全なルートアクセス権が正当に必要なプリンシパルにのみオーナーのロールを付与することをおすすめします。詳細については、IAM セキュリティ ガイドをご覧ください。
マネージド サービスへの自動アクセスは、サービス アカウントに基づいて行われる必要があります。サービス アカウントは、アプリの認証と承認を管理する方法を提供することによって、アプリ管理のライフサイクルを簡素化します。これらのアカウントは、共通の ID を持つ、類似したアプリと機能を有する仮想マシン インスタンスを柔軟かつ安全にグループ化する方法を提供します。IAM ロールと VPC ファイアウォール ルールを使用して、サービス アカウント レベルでセキュリティとアクセス制御を実施できます。
フォルダに適用する IAM ルールは、そのフォルダに含まれるすべてのアイテムによって継承されます。デフォルトのアクセス許可は「すべてを拒否（deny-all）」（要件 7.2.3）で、ルールを適用するたびにアクセス許可の追加のみが行われます。
要件 8.3.6 には、ユーザー パスワードについてのいくつかの基本的なルールがあります。アメリカ国立標準技術研究所（NIST）は、NIST SP800-63B の 5.1.1 章で、安全なパスワードのためのさらに安全なルールセットを定義しています。可能な限り、NIST デジタル ID ガイドラインに従うことをおすすめします。
PCI DSS SAQ D の 12.7 章では、環境へのアクセスが許可される前に、スコープ内の環境にアクセスする個人が、現地の法律に従って身元調査に合格することを義務付けています。コンプライアンス違反のリスクを低減するために、コンプライアンスの種類に関係なく、各人に対して犯罪歴の調査と身元照会を行うことを検討してください。
ネットワークを保護する
決済処理アプリ ネットワーク間の受信トラフィックおよび送信トラフィックを保護するには、次のものを作成する必要があります。
- Cloud Next Generation Firewall ポリシーまたは Compute Engine ファイアウォール ルール
- Cloud VPN トンネル
- 外部アプリケーション ロードバランサ
VPC を作成する際には、ネットワーク セキュリティを強化するために Cloud NAT の利用もおすすめします。Compute Engine インスタンスと GKE インスタンスの両方のネットワーク保護に使用できる便利なオプションが多数あります。
ファイアウォール ルールの作成
Cloud Next Generation Firewall ポリシーまたは VPC ファイアウォール ルールを使用すると、各 Compute Engine インスタンスのインバウンド トラフィックを制限できます（要件 1.3 および 1.4）。次の 3 つのソースからのインバウンド トラフィックのみを許可します。
- お客様が支払いのページに到達できるようにするためのパブリック HTTPS。
- 事業者の支払い処理アプリが第三者の支払い処理業者からレスポンスを受け取れるようにするための事業者のアプリ ネットワーク。
- 監査や管理の目的でインスタンスにアクセスできるようにするための事業者内のオフィス ネットワーク。
個々のインスタンスでファイアウォール ルールを使用して、送信トラフィックを制限します。これらのルールは、iptables を使用してローカルで実装することも、VPC ファイアウォール ルールとネットワーク タグを使用してより広範に実装することもできます。支払いフォームから第三者の支払い処理業者への送信トラフィックのみを許可します。この接続を HTTPS のみに限定する必要があります。作業をテストするには、このドキュメントで後述するファイアウォール ルールのロギングに関するセクションをご覧ください。
Cloud DNS には非公開 DNS ゾーンがあるので、CDE 内でホストを安全に指定できます。その際、機密のネットワーク トポロジ データが漏洩する可能性はありません。
次のようにトラフィックを制限します。
| 送信元 | 送信先 | ポート | 方向と理由 |
|---|---|---|---|
| パブリック ロードバランサ | 第三者の支払いフォーム | tcp:443 | 受信 支払い処理アプリへのパブリック アクセス |
| 第三者の支払いフォーム | 第三者の決済代行業者 | tcp:443 | 送信 支払いサービス プロバイダに AUTH リクエストを転送 |
| 第三者の決済代行業者 | 事業者の支払い処理アプリ | tcp:5480 | 受信 支払いシステムから AUTH リクエストを受け入れる（カード所有者のデータは含まれない） |
| 会社のオフィス ネットワーク | vpn-gateway | tcp:8000 | 受信 ログと開発用マシンにアクセスするための支払い処理環境へのアクセス |
さらに、支払い処理アプリの内部ネットワークでは、次の内容の安全なトラフィックが生じます。
| 送信元 | 送信先 | ポート | 理由 |
|---|---|---|---|
| カードフォーム | PCI プロキシ | tcp:5480 | 支払い方法トークンのための暗号化されたカードデータの交換 |
| すべてのホスト | Google NTP サーバー | udp:123 | 時刻の同期 |
| VPN ゲートウェイ | すべてのホスト | tcp:22 | Secure Shell（SSH）接続 |
安全な VPN トンネルの確立
Cloud VPN を使用すると、オンプレミス環境と決済処理環境の間に安全な VPN トンネルを確立できます（セクション 2.2.7 と 4.2）。
外部アプリケーション ロードバランサの作成
外部アプリケーション ロードバランサを作成することで、お客様の受信トラフィックを保護できます（セクション 2.2.7 と 4.2）。外部アプリケーション ロードバランサを作成するには、次のものが必要です。
- 支払い処理フォームに使用されるウェブサイトのサブドメイン（例:
payments.your-domain-name.com）。 - サブドメインに登録されている有効で署名済みの SSL 証明書。
ウェブの登録業者のドメイン構成インターフェースで、ドメインの DNS 設定を見て、そのドメインが有効であることを確認してください。
Linux のベースイメージの作成
PCI DSS には、準拠した支払い処理アーキテクチャの一部であるマシンを設定する方法について記載した要件が含まれています。これらの要件はいくつかの方法で実装できますが、最も簡単な方法は次のとおりです。
支払い処理アプリのスコープに含まれる各サーバーにインストールする必要があるソフトウェアとライブラリのリストを作成します。システムに不要な脆弱性が生じないようにするため（要件 2.2.4）、アプリの実行に必要な最小限のソフトウェアとライブラリのみを含めます。候補としては、Google Cloud CLI、言語固有のランタイムやライブラリ、ウェブサーバーなどがあります。
Compute Engine の事前構成されたオペレーティング システム イメージのいずれか 1 つを使用する Compute Engine インスタンスを作成します。
先ほど作成したリスト内のライブラリとソフトウェアをインストールします。
システム クロックを同期するために
ntpをインストールして構成します。Network Time Protocol を使用してサーバー クロックを管理すると、ログのタイムスタンプの完全性が保証されます（10.6 章）。安全な Compute Engine イメージを作成するためのベスト プラクティスにイメージが従っていることを確認します（2.2 章全体）。
ベースイメージを構成したら、そのイメージから Compute Engine のカスタム ディスク イメージを作成します。このイメージを使用すると、仮想マシン インスタンスを作成するときに Linux のベースイメージを使用できます。
安全なパッケージ管理を使用する
パッケージ管理は、セキュリティが強化されたホスティング環境での重要な要素です。2.2 章に従い、業界で受け入れられている強化基準を実装する必要があります。Google の Container-Optimized OS を使用していなければ、おそらく RPM、Yum、Apt などのパッケージ管理システムがすでにインストールされているはずです。一般に、アプリでは NPM、PyPi、Composer などのプログラミング言語固有の独自のパッケージ管理システムを使用し、最初の実行時に依存関係をダウンロードします。
アプリがインターネットからアップデートを取得できる場合は、アップデート ソースを潜在的なセキュリティ リスクとして扱う必要があります。一般向けにホストされているパッケージに悪意を持って組み込まれたサプライサイド攻撃またはアップストリーム攻撃が最近はよく見られます。悪意のあるコードを含む SSH のアップデートをインストールした場合の影響を想像してみてください。
パッケージの安全受領リストを作成し、パッケージがリストに一致していることを確認することで、サプライサイド攻撃のリスクを軽減できます。使用する各パッケージについて、テスト済みおよび承認済みのバージョン番号のリストを保存しておいてください。バージョン番号と一緒にそのハッシュまたは署名を記録します。アプリをインストールまたは更新する前に、パッケージ管理システムがハッシュまたは署名を検証するようにしてください。
ほとんどのパッケージ管理システムでは非公開ホスティングが可能です。可能であれば、独自の非公開パッケージ管理サーバーを起動し、テストおよび承認済みのソフトウェアのみをホストします。パッケージ管理システムをロックして、更新のために他のサーバーにアクセスできないようにします。
理想としては、アプリのビルドプロセスですべてのパッケージを取得して検証し、コンテナに必要なすべてのものを含むカスタム ディスク イメージのリビジョンを作成します。この方法により、サーバーの起動時およびスケールアップ時にインストーラが遅延することがなく、起動時にランダムなエラーが発生する可能性が少なくなります。また、イメージを起動することで、以前のバージョンのアプリを本番環境で使用していたときとまったく同じ状態に戻すことができます。これは診断やフォレンジックに役立ちます。
デプロイメントと構成
次に、ベースイメージからインスタンスのデプロイメントと構成を設定します。
環境をデプロイする
PCI DSS の要件を満たすには、常に適切なアプリをデプロイすること、アプリを安全にデプロイすること、デプロイ中に他のソフトウェア パッケージをインストールしないことに留意します。デプロイメント プロセスを簡素化するために、Terraform を使用したアプリの自動デプロイメントの作成について検討してください。Terraform を使用すると、ファイアウォール ルール、ゲートウェイ、ロードバランサ、コード内のインスタンスなど、決済処理環境全体を記述できます。
自動デプロイメントでは、サードパーティ ソフトウェアであるか独自のソフトウェアであるかにかかわらず、デプロイされるソフトウェアの完全性を検証する必要があります。パッケージがインストールされる際に、各パッケージに対して自動ハッシュを実行して、ソフトウェアを検証できます。ハッシュが検証されたら、自動テスト フレームワークを使用して、セキュリティ テストやその他のテストを実行し、これらのテストに合格していることを確認できます。
最後に、Compute Engine のインスタンスをデプロイするときには、インスタンスが失敗した場合に備えて、復旧計画を作成してください。許容可能なダウンタイムの時間枠が十分にある場合は手動の復旧計画で十分かもしれませんが、そうでない場合は自動復旧計画を作成する必要があります。障害復旧計画ガイド、堅牢なシステムの設計、スケーラブルで復元力のあるウェブアプリのビルドをご覧ください。
環境の構成
インスタンスをデプロイしたら、それらが正しく構成されていることを確認します。必要に応じて、各インスタンスのベースイメージの上に追加のソフトウェアやライブラリをインストールします。手動構成に伴う複雑さ、オーバーヘッド、全体的なリスクを回避するには、Skaffold、Chef、Puppet、Ansible、Salt などの自動構成管理ツールを使用します。
変更不可能な監査ロギングの実装
Logging は、多数のプロダクトのさまざまなアクティビティに関する監査ログを自動的に生成します。長期的には、Cloud Storage バケットロックを使用して、変更不可能なログを安全に保存できます（10.3 章）。バケットのロックを使用すると、指定した時間（秒から年）にわたって、すべてのオブジェクトの変更と削除を不可能にするポリシーを設定できます。
Virtual Private Cloud のフローログの実装
VPC フローログ サービスは、仮想マシン インスタンスが送受信したネットワーク フローを記録するように設計されています。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析に使用できます（10.2 章）。
Logging エージェントをインストールする
サーバーに iptables を設定すると、各サーバーがすべての活動をサーバーのブロック ストレージに記録します。無料割り当てとデータ転送料金の詳細については、Logging の料金ページをご覧ください。これらのログを保持し、疑わしい活動に基づいてアラートを生成するには、各サーバーに Logging エージェントをインストールして、ログを Logging と Monitoring にストリーミングする必要があります（10.3 章）。
侵入検知システムの統合
11.5 章に記載されているとおり、支払い処理環境のセキュリティを確保するために侵入検知システム（IDS）を使用すると、悪意を持った者がシステムを攻撃しようとしたときに察知できます。支払い処理環境内に IDS を配置するには 2 つの方法があります。エントリ ポイントごとに IDS を配置するか、サーバーごとに IDS をインストールするかです。
環境のアーキテクチャの複雑さを軽減し、11.5 への準拠を簡素化するには、各サーバーに IDS をインストールします。IDS ソフトウェアを調査してどれを使用するかを選択したら、IDS のインストールを各サーバーの起動インストール スクリプトに組み込みます。
Cloud Intrusion Detection System（Cloud IDS）は侵入検知サービスで、ネットワークに対する侵入、マルウェア、スパイウェア、コマンド＆コントロール攻撃の脅威を検出します。Cloud IDS では、North-South トラフィックと East-West トラフィックの両方を含むネットワーク トラフィックを完全に可視化し、VM 間の通信をモニタリングしてラテラル ムーブメントを検出できます。また、Cloud IDS を使用して要件 11.5 への遵守を簡素化することもできます。
IDS のログは、PCI DSS の遵守範囲に含まれるため、報告、アラート、監査の目的で Logging と Monitoring に送信する必要があります。
Security Command Center の実装
Security Command Center を使用すると、データを収集し、脅威を特定して、ビジネス上の損害や損失が生じる前に脅威に対応できます。このサービスにより、アプリとデータのリスクに関する詳しい分析情報が得られるので、クラウド リソースに対する脅威を迅速に軽減し、全体的な健全性を評価できます。Security Command Center を使用ことで、一元化された単一ダッシュボードから、クラウド資産のインベントリの表示とモニタリング、センシティブ データ用のストレージ システムのスキャン、一般的なウェブ脆弱性の検出、重要なリソースへのアクセス権の確認を行うことができます。5 章および 6.4 章などのいくつかの要件を遵守するうえで役立ちます。
アプリのデプロイメントを自動化する
アプリの最新バージョンを安全に取得して起動できるよう、構成管理ツールを構築します。アプリは、その場所が安全である限り、Cloud Storage などの任意の場所から取得できます。
上記の構成管理ツールの多くは、継続的インテグレーションおよび継続的デプロイメント（CI / CD）のワークフローをサポートしています。このワークフローは、自動スキャン（11.3 章）を実行してコードのレビュー（要件 6.2.3）を確実に行うために使用することもできます。
構成マネージャー ログを収集する
構成マネージャーを設定する際は、すべてのインストールの詳細がログに記録されることを確認します。構成プロセスの完了後に、そのログが Logging と Monitoring に提供されることを確認します。
ロギングとモニタリング
PCI DSS の 10 章に確実に準拠するため、支払い処理環境で行われるすべての手順が確実にモニタリングおよび記録されるようにする必要があります。すべてのインスタンス上のすべてのサーバーのアクティビティをログに記録し、すべてのユーザーのアクションを後から調べることができるようにする必要があります。
アクセスの透明性を有効にする
アクセスの透明性により、Logging は Google Cloud 管理者がお客様のコンテンツにアクセスした際に、準リアルタイムのログを提供するようになりました。自社の管理者が行ったアクションは、従来から Cloud Audit Logs のログで可視化されています。ただし、この監査証跡では通常、ご利用のクラウド プロバイダのサポートチームまたはエンジニアリング チームによる操作は除外されます。たとえば、アクセス承認のロギングが導入される前は、Google サポートによるデータアクセスを必要とするチケットを登録しても、それは Cloud Audit Logs で追跡されませんでした。アクセス承認はこのギャップを埋めるものであり、サポートチームやエンジニアリング チームが手動で特定のターゲットにアクセスしたときに、準リアルタイムでそのログを収集します。
アクセス承認を使用すると、Google Cloud のデータまたは構成へのアクセスを、そのアクセスが発生する前に明示的に承認できます。アクセス承認は、Google サポートとエンジニア チームによるアクセスの分析情報も提供します。
ファイアウォール ルール ロギングの有効化
ファイアウォール ルール ロギングを使用すると、個々のルールレベルでロギングを有効にできます。これにより、自分で作成したルールで VPC 内の TCP 接続と UDP 接続を記録できます。これは、ネットワーク アクセスを監査する場合に役立ちます。また、ネットワークが承認されていない方法で使用されていることを早期に警告する場合にも役立ちます。
VPC Service Controls の使用
VPC Service Controls を使用すると、Cloud Storage バケット、Bigtable インスタンス、BigQuery データセットなどの Google Cloud リソースとのセキュリティ境界を設定して、VPC ネットワーク内のデータを制限し、データ漏洩のリスクを軽減できます（要件 1.3.1 および 1.3.2）。VPC Service Controls により、センシティブ データを非公開にしたまま、Google Cloud のフルマネージド ストレージおよびデータ処理機能を利用できます。
VPC フローログの設定
VPC フローログは、VM インスタンスによって送受信されたネットワーク トラフィック フローを記録します。ログは、PCI DSS でのモニタリング、監査、フォレンジック、およびリアルタイム セキュリティ分析に役立ちます。各 VPC ネットワークのサブネットで、フローログを個別に有効または無効にできます。スコープ内の CDE に関するフローログのみを有効にすることで、ログデータの量を最小限に抑えることができます。フローログを下りファイアウォール ルールと組み合わせると、許可されたエンドポイントへの送信トラフィックを、監査可能で回避しにくい方法で制限できます（要件 1.2.1 および 1.3.4）。
次の図は、VPC フローログが VM インスタンスによって送受信されるネットワーク トラフィック フローを記録する方法を示しています。
個別の HTTP リクエスト ロギングなど、フローログが提供できるデータよりも詳細なデータが必要な場合は、アプリ内にコントロールを実装できます。また、送信リクエストをプロキシすることもできます。これを行うには、アクセスログを Logging に転送するように構成された独自のリバース プロキシ サーバーを使用します。Compute Engine での Squid プロキシ サーバーの設定については、ネットワーク プロキシの設定をご覧ください。ボトルネックを回避するには、少なくとも 2 つの冗長プロキシ サーバーを設定します。
内部アクセスデータをログに記録する
外部の脅威をログに記録するだけでなく、支払い処理環境への管理アクセス権を持っている個人の活動をモニタリングしてログに記録します（10.2 章）。これを行うには、シェルコマンドをログに記録します。いくつかのオープンソースのツールを使って、シェルコマンドを監査してロギングに送信できます。このタスクには、OSSEC や Tripwire がよく利用されます。
モニタリング アラートを設定する
支払い処理環境内で何か問題が発生した場合に、アラートを送信するように Monitoring を構成します（10.6 章）。環境、監査、内部アプリの各イベントをアラートがカバーしていることを確認します。支払い処理アプリの各コンポーネントの潜在リスクや攻撃方法に基づいて、アラート戦略を立てます。たとえば、IDS が侵入の試み（成功 / 失敗にかかわらず）を検知したら、Monitoring アラートをトリガーできます。また、ファイアウォール ルールロギングを使用して、特定のネットワーク ポリシーに違反する試みに対応してアラートをトリガーできます。
BigQuery にログをストリームする
後で分析するために Logging ログを BigQuery に転送することもできます。詳細については、ルーティングとストレージの概要: シンクをご覧ください。BigQuery は大規模なデータセットへのクエリ用に最適化されているので、大規模なログ分析に適したツールです。Logging では、ニア リアルタイムの分析が必要なログを BigQuery に直接ロギングすることもできます（要件 10.4.1）。
Sensitive Data Protection を使用したデータのサニタイズ
分析や開発などの目的で、スコープ内アプリに含まれていてもそれ自体はスコープ外であるデータを使用する場合があります。Sensitive Data Protection で PCI データをサニタイズした後で初めて、アプリに PCI データへのアクセスを許可します（要件 6.5.1）。
アプリのセキュリティ
アプリを保護するには、まず管理インターフェースを評価する必要があります。また Cloud Key Management Service を使用することも可能です。
管理インターフェースの評価
ほとんどの e コマースアプリには、カスタマー サービス課金ポータルなどの独自の非コンソール型管理インターフェースがあります。そのようなツールには、堅牢なアクセス制御と、多要素認証を使用する個別アクセスが必要で（8.4 章）、さらに監査ロギングを実装する必要があります（10.2 章）。
作成するログには、誰が何をしたか、どこで行ったか、いつ行ったかという内容を含める必要があります。2.2.7 章に従い、そのようなツールへのすべてのアクセスには、優れた転送暗号化を使用する必要があります。Sensitive Data Protection を使用して、機密情報を管理ツールに表示する前にフィルタリングしてください。
Google Cloud Key Management Service（Cloud KMS）
Cloud KMS は、暗号鍵の管理を行うことができるようにするサービスです。AES-256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の暗号鍵の生成、使用、ローテーション、破棄を行うことができます。Cloud KMS を使用すると、コードまたは構成ファイルに格納されている書式なしテキストのパスワードを削除できます。これにより、2.2.2 章、3.6 章、3.7 章、8.2 章の遵守が簡素化されます。
環境を検証する
環境が実装された後、本番環境トラフィック フローが開始される前に、環境を検証する必要があります。
- レベル 1 の事業者の場合、環境は Qualified Security Assessor（QSA）が検証する必要があります。QSA とは、PCI Security Standards Council が PCI 環境を検証して認証シールを与える資格を認められた法人または個人です。
- レベル 2 以下の事業者の場合、自己問診に記入することで環境を検証できます。
次のステップ
- PCI DSS ドキュメント ライブラリ
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。