組み込みに関するセキュリティガイド
PCI 準拠を確認し、顧客とサーバーの通信を保護します。
カードデータの処理、送信、保存に関わる全員が、Payment Card Industry Data Security Standard (PCI DSS) に準拠する必要があります。Stripe は独立した PCI Qualified Security Assessor Company (認定審査機関、QSA) による監査を受けて、PCI レベル 1 サービスプロバイダーとして認定されました。これは、決済業界で最も厳しいレベルの認証です。
PCI 準拠は共同責任であり、 Stripe とお客様のビジネスの両方に適用されます。支払いを受け付ける際は、PCI に準拠した方法で行う必要があります。PCI に準拠する最も簡単な方法は、カードデータをまったく見ない (またはアクセスしない) ことです。顧客のカード情報を保護するための厳しい作業を Stripe が行うので、これを容易に行えます。以下の条件を満たしている限り、PCI 準拠を簡素化できます。
- 推奨されている決済システムを使用して支払い情報を収集します。支払い情報は直接 Stripe に転送され、お客様のサーバーを通過することはありません。
- Transport Layer Security (TLS) を使用して支払いページを安全に提供することで、HTTPS を利用できるようにします
- アカウントの PCI 準拠を毎年確認および検証します。
PCI 準拠の検証
すべての Stripe ユーザーは、PCI 準拠を毎年検証する必要があります。大半のユーザーは、PCI Security Standards Council によって提供されている自己問診票 (SAQ) を使用して検証できます。SAQ のタイプは、Stripe をどのように実装したか、および以下のどの方法を使用してカードデータを収集するかによって異なります。特定の方法では、追加の PCI ドキュメントを Stripe にアップロードしていただく必要があります。アップロードが必要な場合には、ダッシュボードで実行できます。以下の方法のうち複数を使用している場合、複数の SAQ をアップロードする必要はありません。
ビジネスが PCI に準拠していることを証明する方法がわからない (サードパーティーによって構築された実装システムなど) 場合は、PCI QSA に連絡し、PCI Council が発行している現在のガイダンスに従って、準拠していることを検証する最良の方法を判断してください。
実装システム別 PCI 準拠要件
実装方法 | 要件 | 推奨事項 |
---|---|---|
Direct API | SAQ D | Stripe の API にカード情報を渡すと、お客様の実装システムがそのデータを直接処理します。お客様は、SAQ のうちで最も要件が厳しい SAQ D を使用して、毎年 PCI 準拠を証明する必要があります。この負担を軽減するには、次のようにします。
また、Stripe の不正防止ツールである Radar には、リスク評価、ルールなどが含まれ、クライアント側でのトークン化メソッドを使用している場合のみ利用可能です。 |
Checkout または Elements | SAQ A | Checkout と Stripe.js および Elements は、すべてのカードデータ収集入力を (お客様のではなく) Stripe のドメインが提供する iframe 内でホストするため、顧客のカード情報がお客様のサーバーに接触することはありません。このため、PCI 準拠の負荷が最も軽くなります。 |
Connect | SAQ A | Connect プラットフォーム (Squarespace など) 経由でのみカードデータを収集する場合、プラットフォームが必要な PCI ドキュメントを提供したかどうかを Stripe が判断できます。 |
ダッシュボード | SAQ C-VT | ダッシュボードからの手動によるカード支払いは、定期的な決済処理ではない例外的な状況でのみ可能です。カード情報を入力する適切な決済フォームやモバイルアプリケーションを顧客に提供してください。 この手動で入力されたカード情報は、Stripe の外部で安全であることを確認できないため、お客様が PCI 準拠要件に従ってカードデータを保護し、毎年 SAQ C-VT を記入して、ビジネスが PCI に準拠していることを証明する必要があります。 |
モバイル SDK | SAQ A | Stripe のモバイル SDK の開発および変更管理は、PCI DSS (要求事項 6.3 から 6.5) に準拠していて、Stripe の PCI 検証済みのシステム経由でデプロイされます。iOS または Android 向けの Stripe 公式 SDK の UI コンポーネントのみを使用しているか、WebView で Elements を使用して決済フォームを作成する場合は、カード番号が顧客から Stripe に直接渡されるため、PCI 準拠の負担が最も軽くなります。 カード情報を処理するコードを自社で作成するなどの他の方法を採用する場合は、追加の PCI DSS 要求条項 (6.3 〜 6.5) に対する責任を負い、SAQ A の適格対象外になる可能性があります。PCI QSA に連絡し、PCI Council が発行している現在のガイダンスに従って、準拠していることを検証する最良の方法を判断してください。 自分のデバイスから情報を入力することをお客様のアプリケーションが顧客に要求する場合、SAQ A の対象になります。アプリケーションが複数の顧客のカード情報をお客様のデバイスで受け付ける (POS アプリなど) 場合は、 PCI 準拠を検証する最良の方法について PCI QSA にご相談ください。 |
Stripe.js v2 | SAQ A-EP | 自社のサイトでホストするフォームに入力されたカードデータを Stripe.js v2 を使用して渡す場合は、毎年 SAQ A-EP に記入して、ビジネスが PCI に準拠していることを証明する必要があります。 別の方法である、Checkout と Elements は両方とも、セルフホスト型のフォームの柔軟性とカスタマイズ可能性を維持しつつ、SAQ A に対する PCI 適格性を満たしています。 |
Terminal | SAQ C | Stripe Terminal でのみカードデータを収集する場合は、SAQ C を使用して検証できます。 この表に掲載されている追加の方法を使用して Stripe を導入している場合は、それらの方法に対して別個に、説明に従って準拠していることを示す必要があります。 |
警告
Visa または MasterCard で処理している取引が年間 600 万件を超える場合、またはアメリカン・エキスプレスで処理している取引が 250 万件を超える場合、またはいずれかのカードネットワークによってレベル 1 プロバイダと見なされている場合は、SAQ を使用して PCI 準拠を証明することはできません。決済ブランドは、PCI 準拠を確認するため毎年 Report on Compliance (RoC) への記入を要求します。
TLS と HTTPS を使用する
TLS とは、クライアント (顧客が使用しているアプリまたはブラウザー) とお客様のサーバーとの間で安全にデータを送信するプロセスを指します。これは当初、Secure Sockets Layer (SSL) プロトコルが実行しましたが、古くなり安全ではなくなりました。TLS が SSL に置き換わりましたが、「SSL」という用語は、 TLS とその送信データを保護する機能を表すときに話し言葉で引き続き使用されています。
決済ページでは、お客様と顧客の両方に対する中間者攻撃のリスクを削減するため、最新バージョン (TLS 1.2 以上) を使用する必要があります。TLS は次の達成を目指しています。
- クライアントとサーバー間のトラフィックを暗号化し、その整合性を検証します。
- クライアントが正しいサーバーと通信していることを確認してください。実際には、これはドメインの所有者とサーバーの所有者が同じエンティティであることの検証を意味し、中間者攻撃の防止に役立ちます。この検証が行われないと、正しい受信者へのトラフィックを暗号化していることが保証されません。
さらに、明確に HTTPS で行われているとわかるページに機密情報を共有するため顧客の安心感が高まり、顧客のコンバージョン率を高めることができます。
必要に応じて、HTTPS を使用せずに実装内容をテストし、本番環境で決済を受け付ける準備ができたときに HTTPS を有効にすることができます。ただし、お客様のサーバーと Stripe 間のやり取り (Stripe のライブラリの使用時など) にはすべて HTTPS を使用する必要があります。
TLS を設定する
TLS を使用するには、認証局 (CA) が発行するファイルである「デジタル証明書」が必要です。この証明書をインストールすると、クライアントが、なりすましではなく通信先として想定されるサーバーと実際に通信していることが保証されます。デジタル証明書は、次のような定評のある証明書プロバイダーから取得します。
証明書のコストは、証明書のタイプとプロバイダーによってさまざまです。「Let’s Encrypt」は、無料で証明書を提供する認証局です。
TLS を設定するには次のようにします。
- 適切なプロバイダーから証明書を購入します。
- その証明書を使用するようにサーバーを設定します。この手順は複雑になる可能性があるため、使用するプロバイダーのインストールガイドに従ってください。
TLS は一連の複雑な暗号化ツールであるため、詳細を見過ごしてしまいがちです。Qualys SSL Labs が提供している SSL Server Test を使用して、すべてが安全に設定されたことを確認することをお勧めします。
セキュリティに関する考慮事項
他のサイトから JavaScript を取り込むと、セキュリティが他のサイトに依存するようになり、セキュリティリスクが生じる可能性があります。そのサイトが侵害された場合、攻撃者がお客様のページで任意のコードを実行する可能性があります。実際には、多くのサイトが Google アナリティクスのようなサービスに JavaScript を使用していて、安全なページもあります。それでもなお、これを最小限に抑えることが重要です。
Webhooks を使用している場合、エンドポイントに TLS を使用して、トラフィックが傍受されたり通知が変更されたりしないようにすることをお勧めします (機密情報が Webhook イベントに含まれることは決してありません)。
データセキュリティ標準に準拠することは重要ですが、セキュリティを常に考慮する必要があります。Web セキュリティを理解するのに役立つリソースを以下に示します。
安全に保存できる対象外のカードデータ
Stripe は、支払いリクエストへのレスポンスで機密情報以外のカード情報を返します。これには、カードのタイプ、カードの末尾 4 桁、有効期限が含まれます。この情報は PCI 準拠の対象ではないため、これらのプロパティはいずれもデータベースに保存できます。さらに、Stripe の API から返される情報はすべて保存できます。
コンテンツセキュリティポリシー
コンテンツセキュリティポリシーをデプロイしている場合、Checkout、Connect の埋め込みコンポーネント、Stripe.js で必要となるすべてのディレクティブは次のとおりです。