PCI データ セキュリティ基準の遵守

このガイドでは、ビジネスのために Google Cloud に Payment Card Industry Data Security Standard(PCI DSS)を実装する方法を学びます。このガイドでは、PCI SSC クラウド コンピューティング ガイドライン(PDF)よりも詳しくこの基準の背景を述べ、クラウドベースのコンプライアンスにおけるカード事業者の役割について説明した後、PCI DSS を使用して支払い処理アプリを設計、デプロイ、構成するためのガイドラインを示します。このチュートリアルでは、アプリのモニタリング、ロギング、検証を行う方法についても説明します。

PCI データ セキュリティ基準は、PCI Security Standards Council によって策定された、支払いカード(クレジット カードデビットカードの両方)の情報を処理する企業のための情報セキュリティ基準です。PCI Security Standards Council には多数の主要な支払いカード会社が参加しています。Visa、MasterCard、Discover、American Express、JCB のカード加盟店は PCI DSS に準拠することが求められ、準拠していない場合は罰金やペナルティを課せられることがあります。

PCI DSS には、直接、支払い情報を収集する事業者から、支払い処理を完全に外部委託している事業者に至るまで、いくつかの事業者タイプが分類されています。このガイドでは、SAQ A、SAQ A-EP、および SAQ D の事業者タイプについて説明します。

目標

  • 支払い処理アプリのアーキテクチャを確認する
  • 支払い処理環境を設定する
  • アプリサーバーをデプロイおよび構成する
  • ロギングとモニタリングを設定する
  • 支払い処理環境を検証する

定義

このガイドでは独特な用語を多数使用します。以下に、よく使用する用語をいくつか示します。詳細については、PCI DSS 用語集をご覧ください。

CDE: カード会員データ環境(Cardholder Data Environment)の頭字語。これは、カードの支払い口座番号や個人情報などのカード会員データを保持または転送するアプリの任意の要素を指します。

代替コントロール: 元の要件の目的と厳密さを満たし、同等のレベルの防御を提供する、任意の要件に対する代替ソリューション。正式な定義では、代替コントロールは他の PCI DSS 要件を「上回るもの」であり、元の要件を遵守しないことによって課される追加のリスクに見合うものでなければなりません。

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 3.2.1 を遵守したサービス プロバイダであるため、事業者レベルにかかわらず、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 で定義される事業者のことを指しています。
SAQ 要件のベン図。SAQ A-EP は SAQ A のスーパーセットであり、SAQ D は SAQ A-EP のスーパーセットである。
SAQ 要件のベン図。SAQ A-EP は SAQ A の上位集合であり、SAQ D は SAQ A-EP の上位集合です。

事業者のレベルとタイプはあらゆる組み合わせが可能で、コンプライアンスの要件はその組み合わせによって大きく異なります。

コンプライアンスへの取り組み

Google では、さまざまな技術と処理を使用して、Google サーバーに保存されている情報を保護しています。Google は、Google が管理している Google Cloud テクノロジーとインフラストラクチャに適用される PCI DSS 要件を独自に検証しました。Google は、Google インフラストラクチャ上で実行されるコンピューティング インスタンスの多くの制御機能を事業者に提供しますが、事業者が Google Cloud にデプロイするオペレーティング システム、パッケージ、アプリのセキュリティは制御しません。事業者がデプロイするオペレーティング システム、パッケージ、アプリ(さらには、使用するアーキテクチャで必要な他のカスタマイズ)について PCI DSS 要件を遵守することは、事業者の責任です。

Google Cloud は、レベル 1 のサービス プロバイダと、該当するすべてのサービス プロバイダに対して規定された PCI DSS 要件を遵守しています。Google Cloud 責任分担表では、PCI DSS の遵守義務について概説しています。この責任マトリックスは、PCI DSS の遵守を徹底し、自社で PCI DSS 監査を実施する際の参考になります。

プロダクトのガイダンス

App Engine

App Engine の上り(内向き)ファイアウォール ルールは使用できますが、下り(外向き)ルールは現在利用できません。要件 1.2.1 および 1.3.4 に従って、すべての送信トラフィックが許可されるようにする必要があります。 SAQ A-EP および SAQ D タイプの事業者は、代替コントロールを指定するか、別の Google Cloud プロダクトを使用する必要があります。代替として Compute Engine と GKE をおすすめします。

Cloud Functions

App Engine と同様、Cloud Functions は現在、下り(外向き)ファイアウォール ルールをサポートしていません。SAQ A-EP および SAQ D タイプの事業者は、代替コントロールを指定するか、別の Google Cloud プロダクトを使用する必要があります。代替として Compute EngineGKE をおすすめします。

Google Kubernetes Engine

GKE クラスタ内のノードとポッドは、事業者が管理するすべてのサーバーと同じ方法で利用します。ノードとポッドの両方のレベルで、ロギング、インストゥルメンテーション、パッチ適用を実装します。カード所有者のデータをノードレベルで保持しないでください。ただし、ノードにスコープ内の Pod が含まれる(もしくは含まれている可能性がある)場合は、ノードは引き続きスコープの対象になります。

コントロール プレーン(クラスタ マスター)へのアクセスを制限するには、認可済みネットワークを使用して Google Cloud 外部の信頼できない IP アドレスをブロックします。これらの CIDR ルールは限定公開クラスタと互換性があり、許可リスト(ホワイトリストとも呼ばれます)として機能します。

スコープ内のプロジェクトにさまざまな種類のポッドが含まれている場合は、GKE クラスタ内にネットワーク ポリシーを実装します。ネットワーク ポリシーは、事業者が使い慣れていることの多い Virtual Private Cloud(VPC)ファイアウォールと同様に機能します。IP ルールまたはラベルに基づいてトラフィックを許可または拒否できます。

要件 2.2.1 では、サーバーごとに 1 つの主要機能しか実装できないと規定しています。この要件は、単一の GKE クラスタが複数のポッドタイプをホストするケースを禁止するものではありません。GKE ノードの主な機能は、コンテナの提供と管理です。適切に設計されていれば、個々のポッドも単一クラスタでこの主要機能ルールに準拠することが可能です。

Cloud Storage

要件 3.4 では、PAN はその格納場所を問わず読み取り不能でなければならないことが規定されています。Google は保存中の暗号化機能を自動的に提供しますが、ルールがさらに求める一方向ハッシュ、切り捨て、またはトークン化は自動的に実行されません。

アーキテクチャ例

このセクションでは、SAQ A、SAQ A-EP、および SAQ D に準拠する環境を実装する方法について説明します。

アーキテクチャの概要

SAQ A

SAQ A は最も基本的な支払い処理アーキテクチャです。支払いは第三者によって処理され、事業者のアプリまたはページからカードデータにアクセスすることはありません。

支払い処理フローの概要は次のとおりです。

  1. お客様は商品を選択して購入手続きを進めます。

  2. 決済用アプリは、お客様を第三者の支払い処理業者にリダイレクトします。

  3. お客様は、第三者の処理業者が所有および管理する支払いフォームに支払いカード情報を入力します。

  4. 第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。

  5. トランザクションを処理した後、第三者の支払い処理業者はトランザクションの詳細情報と一緒にお客様を事業者アプリに戻します。

  6. 事業者アプリは、トランザクションを確定するために支払い処理業者に確認リクエストを送信します。

  7. 決済代行業者はトランザクションの詳細を確認して応答します。

お客様のブラウザ、販売者のサイト、決済代行業者、支払いゲートウェイの間の情報処理。
SAQ A の第三者支払い処理環境のアーキテクチャ

SAQ A-EP

SAQ A-EP 支払い処理アーキテクチャでは、Compute Engine 仮想マシン インスタンスで実行される支払い処理アプリが中核となります。これらのインスタンスは、安全なプライベート ネットワーク内に存在し、安全なチャネルを使用して、このネットワークの外側にあるサービスと通信します。

支払い処理フローの概要は次のとおりです。

  1. お客様は、事業者が所有および管理する支払いフォームに支払いカード情報を入力します。

  2. お客様が自分の情報を送信すると、そのフォーム情報は第三者の支払い処理業者に安全に渡されます。

  3. 第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。

  4. 支払い処理業者は事業者の支払い処理アプリにレスポンスを送信します。次いで、このアプリが事業者のコアアプリにメッセージを渡します。

こうしたやり取りはすべて Cloud Logging によってロギングされ、Cloud Monitoring によってモニタリングされます。

SAQ A-EP の支払処理環境のアーキテクチャ
SAQ A-EP の支払い処理環境のアーキテクチャ

SAQ D

SAQ D 支払い処理アーキテクチャでは、Compute Engine 仮想マシン インスタンスで実行される支払い処理アプリが中核となります。これらのインスタンスは、安全なプライベート ネットワーク内に存在し、安全なチャネルを使用して、このネットワークの外側にあるサービスと通信します。

支払い処理フローの概要は次のとおりです。

  1. お客様は、事業者が所有および管理する支払いフォームに支払いカード情報を入力します。

  2. お客様が自分の情報を送信すると、事業者の支払い処理アプリがフォーム情報を受け取ります。

  3. 事業者の支払い処理アプリは支払い情報を確認し、その情報をバックエンド API を通じて第三者の支払い処理業者に安全に渡します。

  4. 第三者の支払い処理業者は支払いカード情報を確認し、カードでの支払いを受け付けるか、拒否します。

  5. 支払い処理業者は事業者の支払い処理アプリにレスポンスを送信します。次いで、このアプリが事業者のコアアプリにメッセージを渡します。

こうしたやり取りはすべて Logging によってロギングされ、Monitoring によってモニタリングされます。

SAQ D の支払処理環境のアーキテクチャ
SAQ D の支払い処理環境のアーキテクチャ

支払い処理のお客様対応フロー

SAQ A

このセクションでは、第三者の支払い処理フローについて、アプリを使用するお客様の観点から説明します。

SAQ A の第三者支払い処理のお客様対応フロー
SAQ A の第三者支払い処理のお客様対応フロー

お客様が支払いフォームにアクセスすると、アプリは支払い処理業者がホストする <iframe> を提示します。クロスオリジン リソース シェアリング制限のため、アプリは <iframe> のコンテンツにアクセスすることも、コンテンツをモニタリングすることもできません。お客様が自分の支払いカード情報を送信すると、支払い処理業者はカードを受け付けるか拒否した後、お客様を事業者のアプリに戻します。その後、アプリは支払い処理業者からのトランザクション レスポンスを確認し、それに応じて動作します。事業者のアプリは支払いカード情報にアクセスせず、処理も行いません。

SAQ A-EP

このセクションでは、前述の内部支払い処理フローについて、アプリを使用するお客様の観点から説明します。

SAQ A-EP の第三者支払い処理のお客様対応フロー
SAQ A-EP の第三者支払い処理のお客様対応フロー

お客様が事業者の支払いフォームの URL にアクセスすると、サイトは事業者の支払い処理アプリがホストするフォームを提示します。お客様が自分の支払いカード情報を送信すると、そのフォームは直接支払い処理業者に送られます。支払い処理業者はカードを受け付けるか拒否した後、お客様を事業者のアプリに戻します。その後、アプリは支払い処理業者からのトランザクション レスポンスを確認し、それに応じて動作します。お客様は第三者の決済代行業者を認識することなく、サーバー側の事業者アプリも支払いカード情報にアクセスしません。

SAQ D

このセクションでは、内部支払い処理フローについて、アプリを使用するお客様の観点から説明します。

SAQ D の第三者支払い処理のお客様対応フロー
SAQ D の第三者支払い処理のお客様対応フロー

お客様が事業者の支払いフォームの URL にアクセスすると、HTTPS ロードバランサを通じて安全にフォームにルーティングされます。そして、自分の支払いカード情報を送信すると、事業者の支払い処理アプリがその情報を第三者の支払い処理業者に安全に送信します。第三者の支払い処理業者は、カードを受け付けるか拒否した後、事業者の支払い処理アプリにレスポンスを返します。

支払い処理の内部フロー

SAQ A および SAQ A-EP

このセクションでは、支払い処理フローについて、アプリを実行するサーバーの観点から説明します。

SAQ A および SAQ A-EP の内部フロー
SAQ A および SAQ A-EP の内部フロー

事業者の支払い処理アプリは、第三者の支払い処理業者から返されたレスポンスを受信して解析し、レスポンス データの一部または全部をコアアプリに送信します。この時点で、事業者の支払い処理アプリはトランザクションの処理を終了します。コアアプリがお客様に通知するタスクを処理します。

SAQ D

このセクションでは、内部支払い処理フローについて、アプリを実行するサーバーの観点から説明します。

SAQ D の内部フロー
SAQ D の内部フロー

事業者の支払い処理アプリは、お客様が送信した支払いカード情報を確認し、バックエンド API を通じて支払い処理業者にその情報を送信します。処理業者は請求を試み、トランザクションの詳細情報を付けて応答します。事業者のアプリはレスポンスを受信して処理し、レスポンス データの一部または全部をコアアプリに送信します。この時点で、事業者の支払い処理アプリはトランザクションの処理を終了します。コアアプリがお客様に通知して商品を配送するタスクを処理します。

データのモニタリングとロギングのフロー

モニタリングとロギングのフローは、次のように設計されています。

モニタリングとロギングのフロー
モニタリングとロギングのフロー

支払い処理環境の設定

このセクションでは、支払い処理環境を設定する方法について説明します。設定には次の作業が含まれます。

  • 支払い処理環境を本番環境から分離するための新しい Google Cloud アカウントを作成する
  • 環境へのアクセスを制限する
  • 仮想リソースを設定する
  • アプリサーバーの設定に使用する Linux のベースイメージを設計する
  • 安全なパッケージ管理ソリューションを実装する

新しいアカウントを設定する

アクセス制限とコンプライアンス監査を簡素化するには、標準の本番環境およびあらゆる開発 / QA 環境から完全に分離された、本番稼働品質の支払い処理環境を作成します(要件 6.4.1)。確実に分離するには、コア本番環境のアカウントとは別の Google Cloud アカウントを作成して使用します。Identity and Access Management(IAM)を構成した経験があるユーザーは、スコープ内作業で別々のプロジェクトを使用することで、同等の分離を実現できます。

環境へのアクセスを制限する

支払いシステムコードをデプロイする人、または支払いシステムのパソコンを管理する人にのみ支払い処理環境へのアクセスを許可します(7.1 章および要件 8.1.1)。これを最小権限の原則といいます。Cloud IAM のロールを使用してアクセスを制限します。可能な限り役割を使用すること、想定される作業を実行するために必要な権限のみを許可すること、サービスへの完全なルートアクセス権が正当に必要なプリンシパルにのみオーナーの役割を付与することをおすすめします。詳細については、IAM セキュリティ ガイドをご覧ください。

マネージド サービスへの自動アクセスは、サービス アカウントに基づいて行われる必要があります。サービス アカウントは、アプリの認証と承認を管理する方法を提供することによって、アプリ管理のライフサイクルを簡素化します。これらのアカウントは、共通の ID を持つ、類似したアプリと機能を有する仮想マシン インスタンスを柔軟かつ安全にグループ化する方法を提供します。IAM ロールと VPC ファイアウォール ルールを使用して、サービス アカウント レベルでセキュリティとアクセス制御を実施できます。

フォルダに適用する IAM ルールは、そのフォルダに含まれるすべてのアイテムによって継承されます。デフォルトのアクセス許可は「すべてを拒否(deny-all)」(要件 7.2.3)で、ルールを適用するたびにアクセス許可の追加のみが行われます。

要件 8.2.3 には、ユーザー パスワードについてのいくつかの基本的なルールがあります。アメリカ国立標準技術研究所(NIST)は、NIST SP800-63B の 5.1.1 章で、安全なパスワードのためのさらに安全なルールセットを定義しています。可能な限り、NIST デジタル ID ガイドラインに従うことをおすすめします。

PCI DSS SAQ D の 12.7 章では、環境へのアクセスが許可される前に、スコープ内の環境にアクセスする個人が、現地の法律に従って身元調査に合格することを義務付けています。コンプライアンス違反のリスクを低減するために、コンプライアンスの種類に関係なく、各人に対して犯罪歴の調査と身元照会を行うことを検討してください。

ネットワークを保護する

支払い処理アプリ ネットワーク間の受信トラフィックおよび送信トラフィックを保護するには、次のものを作成する必要があります。

  • Compute Engine ファイアウォール ルール
  • Compute Engine 仮想プライベート ネットワーク(VPN)トンネル
  • Compute Engine の HTTPS ロードバランサ

VPC を作成する際には、ネットワーク セキュリティを強化するために Cloud NAT の利用をおすすめします。Compute Engine インスタンスと GKE インスタンスの両方のネットワーク保護に使用できる強力なオプションが多数あります。

ファイアウォール ルールの作成

ファイアウォール ルールを使用して、Compute Engine の各インスタンスへの受信トラフィックを制限します(要件 1.2.1 および 1.3.2)。次の 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 トンネルを確立する

Compute Engine では、オンプレミス環境と支払処理環境の間に安全な VPN トンネルを確立するために使用できる VPN サービスが提供されています(2.3 および 4.1 章)。

HTTPS ロードバランサを作成する

Compute Engine の HTTP(S) ロードバランサを作成することで、お客様からの受信トラフィックを確実に保護できます(2.3 章および 4.1 章)。HTTPS ロードバランサを作成するには、次のものが必要です。

  • 支払い処理フォームに使用されるウェブサイトのサブドメイン(例: payments.your-domain-name.com)。
  • サブドメインに登録されている有効で署名済みの SSL 証明書。

ウェブの登録業者のドメイン構成インターフェースで、ドメインの DNS 設定を見て、そのドメインが有効であることを確認してください。

Linux のベースイメージを作成する

PCI DSS には、準拠した支払い処理アーキテクチャの一部であるマシンを設定する方法について記載した要件が含まれています。これらの要件はいくつかの方法で実装できますが、最も簡単な方法は次のとおりです。

  1. 支払い処理アプリのスコープに含まれる各サーバーにインストールする必要があるソフトウェアとライブラリのリストを作成します。システムに不要な脆弱性が生じないようにするため(要件 2.2.2)、アプリの実行に必要な最小限のソフトウェアとライブラリのみを含めます。候補としては、Cloud SDK、言語固有のランタイムやライブラリ、ウェブサーバーなどがあります。

  2. Compute Engine の事前構成されたオペレーティング システム イメージのいずれか 1 つを使用する Compute Engine インスタンスを作成します。

  3. 先ほど作成したリスト内のライブラリとソフトウェアをインストールします。

  4. システム クロックを同期するために ntp をインストールして構成します。Network Time Protocol を使用してサーバー クロックを管理すると、ログのタイムスタンプの整合性が保証されます(10.4 章)。

  5. 安全な Compute Engine イメージを作成するためのベスト プラクティスにイメージが従っていることを確認します(2.2 章全体)。

  6. ベースイメージを構成した後、そのイメージから Compute Engine のカスタム ディスク イメージを作成します。このイメージを使用すると、仮想マシン インスタンスを作成する際に Linux のベースイメージを使用できます。

安全なパッケージ管理を使用する

パッケージ管理は、セキュリティが強化されたホスティング環境での重要な要素です。2.2 章に従い、業界で受け入れられている強化基準を実装する必要があります。Google の Container-Optimized OS を使用していなければ、おそらく RPM、Yum、Apt などのパッケージ マネージャーがすでにインストールされているはずです。一般に、アプリでは NPM、PyPi、Composer などのプログラミング言語固有の独自のパッケージ マネージャーを使用し、最初の実行時に依存関係をダウンロードします。

アプリがインターネットからアップデートを取得できる場合は、アップデート ソースを潜在的なセキュリティ リスクとして扱う必要があります。一般向けにホストされているパッケージに悪意を持って組み込まれたサプライサイド攻撃またはアップストリーム攻撃が最近はよく見られます。悪意のあるコードを含む SSH のアップデートをインストールした場合の影響を想像してみてください。

パッケージの安全受領リストを作成し、パッケージがリストに一致していることを確認することで、サプライサイド攻撃のリスクを軽減できます。使用する各パッケージについて、テスト済みおよび承認済みのバージョン番号のリストを保存しておいてください。バージョン番号と一緒にそのハッシュまたは署名を記録します。アプリをインストールまたは更新する前に、パッケージ マネージャーがハッシュまたは署名を検証するようにしてください。

ほとんどのパッケージ管理システムでは非公開ホスティングが可能です。可能であれば、独自の非公開パッケージ管理サーバーを起動し、テストおよび承認済みのソフトウェアのみをホストします。パッケージ マネージャーをロックして、更新のために他のサーバーにアクセスできないようにします。

理想としては、アプリのビルドプロセスですべてのパッケージを取得して検証し、コンテナに必要なすべてのものを含むカスタム ディスク イメージのリビジョンを作成します。この方法により、サーバーの起動時および拡張時にインストーラが遅延することがなく、起動時にランダムなエラーが発生する可能性が少なくなります。また、イメージを起動するだけで、以前のバージョンのアプリを本番環境で使用していたときとまったく同じ状態に戻すことができます。これは診断やフォレンジックに役立ちます。

デプロイメントと構成

次に、ベースイメージからインスタンスのデプロイメントと構成を設定します。

環境をデプロイする

PCI DSS の要件を満たすには、常に適切なアプリをデプロイすること、アプリを安全にデプロイすること、デプロイ中に他のソフトウェア パッケージをインストールしないことに留意します。デプロイ プロセスを簡素化するために、Cloud Deployment Manager を使用したアプリの自動デプロイメントの作成について検討してください。

Cloud Deployment Manager を使用して、ファイアウォール ルール、ゲートウェイ、ロードバランサ、インスタンスを含む支払処理環境全体を記述できます。Cloud Deployment Manager は、各アプリ環境がどのように作成されたかを示す監査証跡の作成にも役立ちます。また、環境を改善して変更する際には環境のバージョン管理が可能です。

自動デプロイメントでは、サードパーティ ソフトウェアであるか独自のソフトウェアであるかにかかわらず、デプロイされるソフトウェアの整合性を検証する必要があります。パッケージがインストールされる際に、各パッケージに対して自動ハッシュを実行して、ソフトウェアを検証できます。ハッシュが検証されたら、自動テスト フレームワークを使用して、セキュリティ テストやその他のテストを実行し、これらのテストに合格していることを確認できます。

最後に、Compute Engine のインスタンスをデプロイするときには、インスタンスが失敗した場合に備えて、復旧計画を作成してください。許容可能なダウンタイムの時間枠が十分にある場合は手動の復旧計画で十分かもしれませんが、そうでない場合は自動復旧計画を作成する必要があります。障害復旧計画ガイド堅牢なシステムの設計スケーラブルで復元力のあるウェブアプリのビルドを参照してください。

環境を構成する

インスタンスをデプロイしたら、それらが正しく構成されていることを確認します。必要に応じて、各インスタンスのベースイメージの上に追加のソフトウェアやライブラリをインストールします。手動構成に伴う複雑さ、オーバーヘッド、全体的なリスクを回避するには、SkaffoldChefPuppetAnsibleSalt などの自動構成管理ツールを使用します。

アップストリーム ソースへのサプライ チェーン攻撃が大きな懸念事項になりつつあるので、Linux のベースイメージの使用に加えて、Grafeas API のようなツールを使用してアップストリーム コードを監査することも検討してください。

Forseti Security を実装する

Forseti Security は、Google Cloud 環境のセキュリティ強化に役立つ、コミュニティ主導の一連のオープンソース ツールです。モジュール式のアーキテクチャにより、個々のコンポーネントを有効にできます。このようなコンポーネントの多くは、PCI DSS の特定の要件に対応できます。

Inventory によって Google Cloud リソースのインベントリ スナップショットが作成されるので、アーキテクチャの履歴レコードを維持できます。

Scanner は Forseti Inventory によって収集された情報を使用して、Google Cloud リソースに関するロールベースのアクセス ポリシーを定期的に比較します。Scanner は Google Cloud リソースを監査するための次のようなルールを適用します。

  • 組織、フォルダ、プロジェクトに関する Identity and Access Management(IAM)ポリシー
  • バケット ACL
  • BigQuery データセット ACL
  • Cloud SQL 承認済みネットワーク

Scanner を使用すると、許可されるユーザー、グループ、およびドメイン、必須のユーザー、グループ、およびドメイン、またはリソースから除外されるユーザー、グループ、およびドメインを指定でき、これらのアクセス ポリシーの整合性を維持できます。Scanner ルールに一致しないアクセス ポリシーが検出された場合、これらのルール違反に関する情報を Cloud SQL または Cloud Storage に保存できます。これにより、安全ではない変更や意図しない変更からユーザーを保護できます。

Enforcer は、ユーザーが作成したポリシーを使用して、Compute Engine ファイアウォールの現在の状態を指定の状態と比較します。Enforcer は、すべてのマネージド プロジェクトまたは一部のプロジェクトに関して、バッチモードでポリシーを比較するオンデマンドのコマンドライン ツールです。Enforcer はポリシーの差異を検出すると、Google Cloud APIs を使って変更を行い、結果出力を表示します。

Explain アドオン モジュールは、IAM ポリシーを可視化します。Explain により以下の情報を把握できます。

  • だれがどのリソースにアクセスでき、そのユーザーがそのリソースをどのように操作できるか。
  • プリンシパルがリソースに対する権限を持っている理由、またはプリンシパルにリソースに対する権限がない理由とその修正方法。
  • どの役割が権限を付与するか、どの役割が最近の変更と同期していないか。

構成が完了すると、メール通知により Inventory と Scanner にそのことを知らせることができます。

変更不可能な監査ロギングを実装する

Logging は、多数のプロダクトのさまざまなアクティビティに関する監査ログを自動的に生成します。長期的には、Cloud Storage バケットのロックを使用して、変更不可能なログを安全に保存できます(10.5 章)。バケットのロックを使用すると、指定した時間(秒から年)にわたって、すべてのオブジェクトの変更と削除を不可能にするポリシーを設定できます。早期アクセス プログラムの利用が必要な場合は、Google Cloud の担当者にお問い合わせください。

Virtual Private Cloud のフローログを実装する

VPC フローログ サービスは、仮想マシン インスタンスが送受信したネットワーク フローを記録するように設計されています。これらのログを、ネットワーク モニタリング(10.2 章)、フォレンジック(要件 10.6.3)、およびリアルタイム セキュリティ分析に使用できます。

ロギング エージェントをインストールする

サーバーに iptables を設定すると、各サーバーがすべての活動をサーバーのブロック ストレージに記録します。無料割り当てとデータ転送料金の詳細については、Logging の料金ページをご覧ください。これらのログを保持し、異常な活動に基づいてアラートを生成するには、各サーバーに Logging エージェントをインストールして、ログを Logging と Monitoring にストリーミングする必要があります(要件 10.5.3)。

侵入検知システムの統合

11.4 章に記載されている支払処理環境のセキュリティを確保するために、侵入検知システム(IDS)を使用すると、悪意のある人物がシステムを攻撃しようとしたときにそれを把握できます。支払い処理環境内に IDS を配置するには 2 つの方法があります。エントリ ポイントごとに IDS を配置するか、サーバーごとに IDS をインストールするかです。

環境のアーキテクチャの複雑さを軽減し、11.5 への準拠を簡素化するには、各サーバーに IDS をインストールします。IDS ソフトウェアを調査してどれを使用するかを選択したら、IDS のインストールを各サーバーの起動インストール スクリプトに組み込みます。

IDS のログは、PCI DSS の遵守範囲に含まれるため、報告、アラート、監査の目的で Logging と Monitoring に送信する必要があります。

Security Command Center の実装

Security Command Center(ベータ版)サービスを使用すれば、データを収集し、脅威を特定して、ビジネス上の損害や損失が生じる前に脅威に対応できます。このサービスにより、アプリとデータのリスクに関する詳しい分析情報が得られるので、クラウド リソースに対する脅威を迅速に軽減し、全体的な健全性を評価できます。セキュリティ コマンド センターにより、一元化された単一ダッシュボードから、クラウド資産のインベントリの表示とモニタリング、機密データ用のストレージ システムのスキャン、一般的なウェブ脆弱性の検出、重要なリソースへのアクセス権の確認を行うことができ、5 章および 6.6 章などのいくつかの要件を遵守するうえで役立ちます。

アプリのデプロイを自動化する

アプリの最新バージョンを安全に取得して起動できるよう、構成管理ツールを構築します。アプリは、その場所が安全である限り、Cloud Storage などの任意の場所から取得できます。

上記の構成管理ツールの多くは、継続的インテグレーションとデプロイ(CI/CD)ワークフローをサポートしています。このワークフローは、自動スキャン(要件 11.2.3)を実行してコードのレビュー(要件 6.3.2)を確実に行うために使用することもできます。

構成マネージャー ログを収集する

構成マネージャーを設定する際は、すべてのインストールの詳細がログに記録されることを確認します。構成プロセスの完了後に、そのログが Logging と Monitoring に提供されることを確認します。

ロギングとモニタリング

PCI DSS の 10 章に確実に準拠するため、支払い処理環境で行われるすべての手順が確実にモニタリングおよび記録されるようにする必要があります。すべてのインスタンス上のすべてのサーバーのアクティビティをログに記録し、すべてのユーザーのアクションを後から調べることができるようにする必要があります。

アクセスの透明性を有効にする

アクセスの透明性と呼ばれる機能を使用すると、Google Cloud 管理者がコンテンツにアクセスした際に、Logging によってほぼリアルタイムでログが提供されます。自社の管理者が行ったアクションは、従来から Cloud Audit Logs のログで可視化されています。ただし、この監査証跡では通常、ご利用のクラウド プロバイダのサポートチームまたはエンジニアリング チームによる操作は除外されます。たとえば、アクセスの透明性ロギングが導入される前は、Google サポートによるデータアクセスを必要とするチケットを登録しても、それは Cloud Audit Logging で追跡されませんでした。アクセスの透明性はこのギャップを埋めるものであり、サポートチームやエンジニアリング チームが手動で特定のターゲットにアクセスしたときに、ほぼリアルタイムでそのログを収集します。

Google は最近、アクセス承認をリリースしました。(アクセス承認は、早期アクセス、リリース ステージにあります)。アクセスの透明性は、Google サポートやエンジニア チームによるアクセスの分析情報を示す機能ですが、アクセス承認は、Google Cloud のデータや構成へのアクセスを、その前に明示的に承認する機能です。この機能の詳細および早期アクセスのリクエストについては、リンク先のページをご覧ください。

ファイアウォール ルール ロギングを有効にする

ファイアウォール ルールロギングを使用すると、個々のルールレベルでロギングを有効にできます。これにより、自分で作成したルールで VPC 内の TCP 接続と UDP 接続を記録できます。これは、ネットワーク アクセスを監査する場合に役立ちます。また、ネットワークが承認されていない方法で使用されていることを早期に警告する場合にも役立ちます。

VPC Service Controls を使用する

VPC Service Controls(ベータ版)は、Cloud Storage バケット、Cloud Bigtable インスタンス、BigQuery データセットなどの Google Cloud リソースの周囲にセキュリティ境界を定義して、VPC 内にデータをとどめ、データ引き出しのリスクを軽減します(要件 1.2.1 と 1.3.4)。VPC Service Controls により、機密データを非公開にしたまま、Google Cloud のフルマネージド ストレージおよびデータ処理機能を利用できます。詳細については、早期アクセスをリクエストしてください。

VPC フローログの設定

VPC フローログを有効にしたときのカード所有者のデータ環境
VPC フローログを有効にしたときの CDE

VPC フローログは、VM インスタンスによって送受信されたネットワーク トラフィック フローを記録します。ログは、PCI DSS でのモニタリング、監査、フォレンジック、およびリアルタイム セキュリティ分析に役立ちます。各 VPC ネットワークのサブネットで、フローログを個別に有効または無効にできます。スコープ内の CDE に関するフローログのみを有効にすることで、ログデータの量を最小限に抑えることができます。

フローログを下りファイアウォール ルールと組み合わせると、許可されたエンドポイントへの送信トラフィックを、監査可能で回避しにくい方法で制限できます(要件 1.2.1 および 1.3.4)。

個別の HTTP リクエスト ロギングなど、フローログが提供できるデータよりも詳細なデータが必要な場合は、アプリ内にコントロールを実装できます。また、送信リクエストをプロキシすることもできます。これを行うには、アクセスログを Logging に転送するように構成された独自のリバース プロキシ サーバーを使用します。Compute Engine での Squid プロキシ サーバーの設定については、ネットワーク プロキシの設定をご覧ください。ボトルネックを回避するには、少なくとも 2 つの冗長プロキシ サーバーを設定します。

内部アクセスデータをログに記録する

外部の脅威をログに記録するだけでなく、支払い処理環境への管理アクセス権を持っている個人の活動をモニタリングしてログに記録します(10.2 章)。これを行うには、シェルコマンドをログに記録します。いくつかのオープンソースのツールを使って、シェルコマンドを監査してロギングに送信できます。このタスクには、OSSECTripwire がよく利用されます。

モニタリング アラートを設定する

支払い処理環境内で何か問題が発生した場合に、アラートを送信するように Monitoring を構成します(10.6 章)。環境、監査、内部アプリの各イベントをアラートがカバーしていることを確認します。支払い処理アプリの各コンポーネントの潜在リスクや攻撃方法に基づいて、アラート戦略を立てます。たとえば、IDS が侵入の試み(成功 / 失敗にかかわらず)を検知したら、Monitoring アラートをトリガーできます。また、ファイアウォール ルールロギングを使用して、特定のネットワーク ポリシーに違反する試みに対応してアラートをトリガーできます。

BigQuery にログをストリーミングする

Logging から Cloud Storage と BigQuery の両方にログをストリーミング
Logging から Cloud Storage と BigQuery の両方にログをストリーミング

必要に応じて、後で分析するために Logging ログを BigQuery にルーティングできます。詳細については、ルーティングとストレージの概要: シンクをご覧ください。BigQuery は大規模なデータセットへのクエリ用に最適化されているので、大規模なログ分析に適したツールです。Logging では、ほぼリアルタイムの分析が必要なログを BigQuery に直接ロギングすることもできます(要件 10.6.1)。

Cloud Data Loss Prevention を使用してデータをサニタイズする

分析や開発などの目的で、スコープ内アプリに含まれていてもそれ自体はスコープ外であるデータを使用することがあります。Cloud Data Loss Prevention で PCI データをサニタイズした後で初めて、アプリに PCI データへのアクセスを許可します(要件 6.4.3)。

アプリのセキュリティ

アプリを保護するには、まず管理インターフェースを評価する必要があります。また Cloud Key Management Service を使用することも可能です。

管理インターフェースを評価する

ほとんどの e コマースアプリには、カスタマー サービス課金ポータルなどの独自の非コンソール型管理インターフェースがあります。そのようなツールには、堅牢なアクセス制御と、多要素認証を使用する個別アクセスが必要で(8.3 章)、さらに監査ロギングを実装する必要があります(10.2 章)。

作成するログには、誰が何をしたか、どこで行ったか、いつ行ったかという内容を含める必要があります。2.3 章に従い、そのようなツールへのすべてのアクセスには、強力な転送暗号化を使用する必要があります。Cloud Data Loss Prevention を使用して、機密情報を管理ツールに表示する前にフィルタリングしてください。

Google Cloud Key Management Service(Cloud KMS)

Cloud KMS は、暗号鍵の管理を行うことができるようにするサービスです。AES-256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の暗号鍵の生成、使用、ローテーション、破棄を行うことができます。Cloud KMS を使用すると、コードまたは構成ファイルに格納されている書式なしテキストのパスワードを削除できます。これにより、3.5、3.6、6.3.1、および 8.2 の要件の遵守が簡素化されます。

環境を検証する

環境が実装された後、本番環境トラフィック フローが開始される前に、環境を検証する必要があります。

  • レベル 1 の事業者の場合、環境は Qualified Security Assessor(QSA)が検証する必要があります。QSA とは、PCI Security Standards Council が PCI 環境を検証して認証シールを与える資格を認められた法人または個人です。
  • レベル 2 以下の事業者の場合、自己問診に記入することで環境を検証できます。

次のステップ