PCI 準拠ガイド

PCI データセキュリティ基準 (PCI DSS) は、データセキュリティに対する最低基準を定めるものです。ここでは、PCI 準拠を維持するための手順や、Stripe のサポートについてご案内します。

Mike Dahn のアバターの写真
Mike Dahn

Mike Dahn は Stripe でセキュリティポリシーリレーションシップをリードしています。PCI トレーナーや監査役、インプリメンターを過去に兼任していました。

  1. はじめに
  2. PCI データセキュリティ基準 (PCI DSS) の概要
    1. カードデータの処理
    2. データの安全な保存
    3. 1 年ごとの検証
  3. PCI DSS 準拠の手順ガイド
    1. 1. 自社要件の把握
    2. 2. データフローのマッピング
    3. 3. セキュリティの管理とプロトコルの確認
    4. 4. 監視と保守
  4. PCI 準拠のために Stripe ができること
  5. おわりに
    1. PCI 準拠は有用です。しかし、十分ではありません。

PCI DSS バージョン 4.0 は 2024 年 3 月 31 日に発効します。

2005 年以降、8,500 件を超えるデータ侵害により、110 億件以上の顧客の記録が漏洩しました。これは、2005 年にさかのぼって消費者に影響を与えたデータ侵害やセキュリティ侵害について報告している The Privacy Rights Clearinghouse からの最新の数値です。

消費者データの安全性と、決済エコシステムへの信頼を向上させるため、データセキュリティに対する最低基準が設けられました。Visa、MasterCard、アメリカン・エキスプレス、ディスカバー、および JCB は、2006 年、クレジットカードのデータを扱う企業に対するセキュリティ基準を設定・管理するための PCI SSC (Payment Card Industry Security Standards Council) を設立しました。PCI SSC が設立される前は、これらのクレジットカード会社 5 社は、要件と目的はほぼ同じながらそれぞれが独自のセキュリティ基準プログラムを運用していました。各社は協力し、PCI SSC を通じてひとつの標準ポリシー PCI DSS (PCI Data Security Standards) としてまとめあげ、インターネット時代における消費者とカード会社の基本的な保護レベルを目指しました。

PCI DSS を理解するのは複雑で困難

使用しているビジネスモデルでカードデータの処理が必要な場合、PCI DSS が定める 300 を超えるセキュリティ制御要件のそれぞれに準拠する必要があります。PCI Council が発行した PCI DSS に関する公式文書は 1,800 ページを超え、PCI 準拠の認証を受けるために必要なフォームはどれなのかを説明するものだけで 300 ページ以上が割かれています。読むだけで 72 時間以上もかかってしまいます。

こうした負担を減らすため、次の手順ガイドに従って PCI 準拠の認証を受けましょう。

PCI データセキュリティ基準 (PCI DSS) の概要

PCI DSS は、カード保有者のデータや機密認証データを保存、処理、または転送するあらゆる団体に対応したグローバル規模のセキュリティ基準です。PCI DSS は消費者に対する基本レベルの保護を定め、支払いエコシステム全体での不正使用やデータ漏洩の削減に役立ち、ペイメントカードの受け付けや処理を行うあらゆる組織に適用可能です。

PCI DSS 準拠には以下の主な 3 つの要素が関係します。

  1. 顧客からのクレジットカードデータ入力の処理、つまり、カードの詳細な機密情報の収集と安全な転送など
  2. データの安全な保存。PCI 基準の 12 のセキュリティ要件である、暗号化、継続的な監視、クレジットカードデータへのアクセスにおけるセキュリティテストなど
  3. フォーム、自己問診、外部の脆弱性スキャニングサービス、サードパーティーによる監査を含む、必要なセキュリティ制御が適切に行われているかを毎年検証 (4 つの要件については、下記の手順ガイドを参照)

カードデータの処理

ビジネスモデルによっては、決済を受け付ける時点でクレジットカードの機密データを直接処理する必要があるものと、ないものがあります。カードデータを処理する必要がある企業 (支払いページで トークン分解されていない PAN を許可するなど) は、300 件を超える PCI DSS の各セキュリティ制御要件を満たさなければなりません。カードデータがサーバーを短時間通過するだけであっても、その企業はセキュリティ用のソフトウェアとハードウェアを購入および導入し、維持する必要があります。

クレジットカードの機密データを処理する必要がない企業は、処理しないことをおすすめします。サードパーティーによるソリューション (Stripe Elements など) がデータを安全に受け付け、保存するため、企業は複雑さやコスト、リスクの重荷から解放されます。サーバーがカードデータに接することがないため、企業に必要なのは、推測されにくいパスワードを使用するなどの簡単なセキュリティ制御要件をいくつか確認するだけです。

データの安全な保存

組織がクレジットカードデータを処理または保存する場合、カード保有者のデータ環境 (CDE) の範囲を定義する必要があります。PCI DSS は CDE のことを、カードデータを保存、処理、送信する人、および、プロセス、技術、データに接続するあらゆるシステムとして定義しています。CDE には PCI DSS に定められた 300 件を超えるすべてのセキュリティ要件が適用されるため、支払い環境と他の手続きを適切に切り分け、PCI の検証範囲を限定することが重要です。組織が詳細な区分に CDE スコープを収めることができない場合、PCI セキュリティ制御はそのネットワークに繋がれたすべてのシステム、ノートパソコン、およびデバイスに適用されてしまいます。そうなると厄介です。

1 年ごとの検証

カードデータの受け付け方法にかかわらず、組織は毎年 PCI 検証フォームを提出する必要があります。PCI 準拠の検証方法は、下記に挙げた要素の数に応じて異なります。次に挙げるのは、PCI 準拠を示すため組織に求められる 3 つのシナリオです。

  • 決済代行業者が、ペイメントカードブランドへの必須申告事項の一部として要求する場合。
  • ビジネスパートナーが、商取引の合意に入る前提条件として要求する場合。
  • プラットフォームビジネスにおいて (自社技術によって複数の異なるユーザー間でのオンライン取引を促進している)、顧客が、その先の顧客に対してデータ処理の安全性を示すために要求する場合。

PCI DSS セキュリティ基準には、12 の主要要件と 300 以上の副要件があり、セキュリティのリーディングプラクティスを正確に表しています。

安全なネットワークとシステムの構築と維持

  • 1. ネットワーク・セキュリティ・コントロールをインストールして維持。
  • 2. 安全な構築をすべてのシステムコンポーネントに適用。

アカウントデータの保護

  • 3. 保存されているカード保有者データを保護。
  • 4. オープンネットワークまたはパブリックネットワークを介したカード保有者データの送信を強力な暗号化で保護。

脆弱性管理プログラムの保守

  • 5. 悪意のあるソフトウェアからすべてのシステムとネットワークを保護。
  • 6. 安全なシステムとアプリケーションの開発と保守。

強固なアクセス管理方法の導入

  • 7. システムコンポーネントとカード保有者データへのアクセスは業務上最小限に制限。
  • 8. ユーザーを特定し、システムコンポーネントへのアクセスを認証。
  • 9. カード保有者データへの物理的アクセスを制限。

ネットワークの定期的な監視とテスト

  • 10. システムコンポーネントとカード保有者データへの全アクセスを追跡、監視。
  • 11. システムとネットワークの安全性を定期的にテスト。

情報セキュリティポリシーの維持

  • 12. 組織のポリシーと手順で情報セキュリティをサポート。

新規ビジネスに対して PCI 準拠への検証を容易にするため、PCI Council は、PCI DSS 要件全体のサブセットである 9 通りの異なるフォームとして、SAQ (自己問診) を作成しました。これにより、どの項目が適用されるか、またはPCI DSS セキュリティの各要件を満たしているかを検証するのに PCI Council の認定を受けた監査人を採用する必要があるかどうかを判断することができます。また、PCI Council は、3 年ごとに規則を改定し、年間を通して複数の更新を行っているため、より複雑さが増しています。

PCI DSS 準拠の手順ガイド

1. 自社要件の把握

PCI 準拠の最初のステップは、貴社の組織に適用する要件を理解することです。PCI 準拠には 4 つの異なるレベルがあり、通常は、12 カ月間にビジネスが処理するクレジットカード取引の量に応じてレベルが決まります。

コンプライアンスレベル
対象
要件
レベル 1
  1. 年間の取引件数が Visa または MasterCard で 600 万件以上、またはアメリカン・エキスプレスで 250 万件以上の組織、または
  2. 過去にデータ漏洩を経験した組織、または
  3. カードブランド (Visa、MasterCard など) が「レベル 1」と判定した組織
  1. 認定監査会社 (QSA) による年次報告書 (ROC) — レベル 1 オンサイト評価とも呼ばれる — もしくは内部監査役による現場監査報告
  2. 四半期ごとの認定スキャンベンダー (ASV) によるネットワークのスキャン
  3. オンサイト評価の準拠証明書 (AOC) – 加盟店およびサービスプロバイダ専用フォームあり
レベル 2
年間取引件数が 100 ~ 600 万件の組織
  1. 年 1 回の PCI DSS 自己問診 (SAQ) — 9 通りの SAQ タイプの概要については下記の表を参照
  2. 四半期ごとの認定スキャンベンダー (ASV) によるネットワークのスキャン
  3. 準拠証明書 (AOC) — 9 通りの SAQ それぞれに異なる AOC フォームあり
レベル 3
  1. 年間オンライン取引件数が 2 万 ~ 100 万件の組織
  2. 年間総取引件数が 100 万件より少ない組織
同上
レベル 4
  1. 年間オンライン取引件数が 2 万件未満の組織、または
  2. 年間総取引件数が 100 万件までの組織
同上

レベル 2 ~ 4 では、決済機能の実装方法に応じて SAQ タイプが異なります。概要は次のとおりです。

SAQ
説明
A
アカウントデータに関するすべての機能を PCI DSS での確認を行い、コンプライアンスが確保されたサードパーティに全面的に委託している非対面カード支払いの加盟店 (E コマース、通信販売/電話販売)。自社のシステムや施設でアカウントのデータの電子形式での保管、処理、または転送を行わない。

対面式の加盟店には適用されません。 サービスプロバイダーには適用されません。
A-EP
PCI DSS での確認を行い、コンプライアンスが確保されたサードパーティに支払い処理の一部を委託し、自社のウェブサイトでは支払い取引のセキュリティや顧客のアカウントデータが入力されるページの保全性に影響するアカウントデータを受信しない E コマース加盟店。加盟店のシステムや施設でアカウントのデータの電子形式での保管、処理、または転送を行わない。

E-コマース加盟店にのみ適用されます。 サービスプロバイダーには適用されません。
B
下記の方法のみを使用する加盟店:
  • 電子形式でのアカウントデータの保管を行わないインプリント装置、および / または
  • 電子形式でのアカウントデータの保管を行わないスタンドアロン型ダイアルアップ端末
E-コマース加盟店には適用されません。 サービスプロバイダーには適用されません。
B-IP
決済代行業者への IP 接続にスタンドアロンの PTS 認定支払い端末のみを使用し、カード会員データを電子形式で保存しない加盟店。

E-コマース加盟店には適用されません。
C-VT
分離型のコンピューティングデバイスとセキュリティが保護された接続のウェブブラウザーを使用して、PCI DSS での確認を行い、コンプライアンスが確保されたサードパーティのバーチャル決済端末ソリューションへのキーボード入力を介して、取引ごとに支払いアカウントのデータを手入力する加盟店。電子形式のアカウントデータのストレージはない。

E-コマース加盟店には適用されません。 サービスプロバイダーには適用されません。
C
インターネットに接続された決済アプリケーションシステムを使用し、電子形式でのアカウントデータの保管を行わない加盟店。E-コマースチャネルには適用されません。

サービスプロバイダーには適用されません。
P2PE
検証済みの PCI 登録済みの POS 暗号化 (P2PE) ソリューションを使用する加盟店。平文のアカウントデータへのアクセスはなく、電子形式によるアカウントデータの保管も行わない。

E-コマース加盟店には適用されません。 サービスプロバイダーには適用されません。
SPoC*
PCI SSC の確認済み SPoC ソリューションの一覧に登録されている安全なカードリーダーを使用して市販の既製モバイルデバイス (スマホ、タブレットなど) を利用している加盟店。平文のアカウントデータへのアクセスはなく、電子形式によるアカウントデータの保管も行わない。

無人のカード提示払い、通信販売/電話販売 (MOTO)、E コマースのチャネルには適用されません。 サービスプロバイダーには適用されません。
D
加盟店向け SAQ D: 上記の SAQ タイプの説明に含まれないすべての加盟店。

サービスプロバイダー向け SAQ D: ペイメントブランドにより SAQ を記入する資格があると定義されたすべてのサービスプロバイダー。
* PCI DSS v4.0 の新しい SAQ

2. データフローのマッピング

クレジットカードの機密データを保護する前に、それがどこに存在し、どうやってそこに入ったかを知る必要があります。組織内でクレジットカードデータをやり取りするシステム、ネットワーク接続、およびアプリケーションの包括的なマップを作成してください。自身の役割によっては、IT チームやセキュリティチームと協力する必要があるかもしれません。

  • 最初に、支払い取引に関係する業務のうち、消費者と接するすべての領域を特定します。たとえば、決済の受け付けは、オンラインのショッピングカートや実店舗内の端末からの場合や、電話注文も考えられます。
  • 次に、組織内でカード保有者データを処理する方法を特定します。データの保管場所とアクセスできる人を正確に把握することは重要です。
  • さらに、支払い取引に関わる内部システムまたは基盤技術を特定します。これには、使用するネットワークシステム、データセンター、およびクラウド環境が含まれます。

3. セキュリティの管理とプロトコルの確認

組織内でクレジットカードデータに関わるすべての潜在的なタッチポイントを精密にマッピングしたら、IT チームおよびセキュリティチームと協力して、適切なセキュリティ設定とプロトコルが正常に実施されているかどうかを確認します (前述の PCI DSS の 12 のセキュリティ要件リストを参照)。これらのプロトコルは、トランスポート層セキュリティ (TLS) プロトコルのように、データ転送を安全に行うことを目的としています。

PCI DSS でのこれら 12 のセキュリティ要件は、あらゆる業務に対して機密データを保護するためのリーディングプラクティスから生じたものです。GDPR、HIPAA、およびその他のプライバシー要件を満たすために必要な事項には重複する部分があるため、一部はすでに組織内で適用されている場合もあります。

4. 監視と保守

PCI 準拠は 1 回限りの出来事ではないことに注意してください。これは、データフローや顧客とのタッチポイントが変化しても、ビジネスが準拠し続けなければならない継続的なプロセスです。年間 600 万件を超える取引を処理している組織は特に、一部のクレジットカードブランドから四半期ごとまたは 1 年ごとにレポートの提出を求められる場合や、準拠継続を検証するオンサイト評価を毎年実行しなければならない場合もあります。

年間を通じて (および対前年比) PCI 準拠を管理するには、他部署からのサポートと協力が必要になります。こういった体制がまだできていない場合は、準拠を適切に維持するための専任チームを内部に発足させるとよいでしょう。対応は各企業で千差万別ですが、「PCI チーム」には、次のような部門の代表者を含めると良いスタートが切れるでしょう。

  • セキュリティ: セキュリティ最高責任者 (CSO)、情報セキュリティ最高責任者 (CISO)、およびそのチームによって、組織が必要なデータセキュリティと、プライバシーに関するリソースおよびポリシーに、常に適切な投資がされているか確認します。
  • テクノロジー / 決済: 最高技術責任者 (CTO)、決済部門の VP、およびそのチームによって、コアツール、システム構築、およびインフラストラクチャーが、組織のシステムが変化しても引き続き準拠していることを確認します。
  • 財務: 最高財務責任者 (CFO) と財務チームは、支払いシステムおよびパートナーによる、すべての支払いデータフローの明細を把握します。
  • 法務: このチームは、PCI DSS 準拠に関する多くの法的な意味合いの理解をサポートします。

PCI 準拠についての詳細は PCI Security Standards Council ウェブサイトをご覧ください。このガイドと他のいくつかの PCI ドキュメントしかご覧になっていない場合、次のドキュメントから読まれることをお勧めします。PCI DSS 準拠への優先的なアプローチ、 SAQ の手順とガイドラインオンサイト評価要件の決定のために使用する SAQ 資格基準に関するよくあるご質問、および支払いカードデータを受け付ける消費者デバイス用アプリを開発する加盟店の義務に関するよくあるご質問。

PCI 準拠のために Stripe ができること

Stripe は CheckoutElementsモバイル SDKTerminal SDK を導入している企業の PCI の負担を大幅に軽減します。Stripe Checkout および Stripe Elements では、すべてのカードデータ処理にオンライン支払いフィールドが使用されます。カード保有者が支払いに関する機密情報を入力するのは、Stripe の PCI DSS 認証サーバーから直接作成された支払いフィールドです。Stripe のモバイル SDK と Terminal SDK でも、カード保有者は支払いに関する機密情報を PCI DSS 認証サーバーに直接送信できます。

導入方法に関わらず、すべてのユーザーに対して、Stripe は PCI が推奨する通りに活動し、さまざまな方法でサポートします。

  • 貴社の導入方法を分析し、準拠のための労力を軽減する方法を提案します。
  • 取引のボリュームが増加し、準拠の認証を受ける方法の変更が必要な場合は、お客様に事前に通知します。
  • 大規模加盟店 (レベル 1) で、(クレジットカードデータを保存しているか、より複雑な決済フローを使用しているために) PCI QSA との連携が必要な場合、世界各地に存在する 350 以上の QSA 企業を通して、Stripe のさまざまな導入方法を熟知した複数の監査人を紹介できます。

おわりに

PCI 準拠の評価と認証は通常年に 1 回ですが、PCI 準拠は 1 回限りの出来事ではありません。審査と改善という、継続的な努力が必要となります。企業が成長するにつれ、中核となるビジネスロジックとプロセスも変化します。つまり、コンプライアンス要件も時と共に変化するのです。一例として、オンラインビジネスが実店舗をオープンして新たな市場に乗り出したり、カスタマーサポートセンターを立ち上げたりすることが挙げられます。何か新しいことに支払いカードデータが関わるのであれば、現在の PCI 認証方式に影響はないか積極的にチェックし、必要に応じて PCI 準拠を再検証することをお勧めします。

PCI 準拠は有用です。しかし、十分ではありません。

PCI DSS ガイドラインを遵守することは、お客様のビジネスの保護に不可欠な一手ですが、それだけでは十分ではありません。PCI DSS は、カード保有者データの処理と保存に関する重要な基準を定めていますが、あらゆる支払い環境に十分な保護を提供しているわけではありません。Stripe Checkout、Elements、およびモバイル SDK といった安全なカード受け付け方法に移行することで、より効率的な方法でお客様の組織を保護することができます。このアプローチを採用すれば、変化にすばやく対応するビジネスは、潜在的なデータ漏洩を軽減し、PCI 認証に関する負担が大きく、時間と費用のかかる旧式の方法から脱却する手段を得ることが可能です。導入方法が安全であれば、365 日いつでも信頼することができるのです。

今すぐ始めましょう。アカウントを作成するか、お問い合わせください。

アカウントを作成し、決済の受け付けを開始しましょう。契約や銀行情報は不要です。ビジネスに合わせたカスタムパッケージの設計については、お問い合わせください。