安全なStripe・Shopify・Salesforce連携

Stripe、Shopify、Salesforceなどのプラットフォームとの連携は、事業に不可欠なデータや資金がシステム間を移動する場所であることが少なくありません。同時に、手抜きが起こりやすい場所でもあります。フロントエンドのコードに貼り付けられたAPIキー、どのようなリクエストでも受け付けるWebhookのエンドポイント、何も知らせずに失敗する同期ジョブなどです。各事業者は詳細なセキュリティガイダンスを公開していますが、チームが書いた連携コードの責任は依然として自社にあります。本ガイドでは、連携をより安全で信頼性の高いものにする実践的な管理策を取り上げます。

何であるのか

安全な連携は3つのものを守ります。アクセスを許可する認証情報、システム間を流れるデータ、そしてアクションを引き起こすビジネスイベントの完全性です。認証情報にはAPIキー、OAuthトークン、クライアントシークレットが含まれます。これらはサーバー上にのみ置き、シークレットマネージャーや保護された環境設定に保管し、連携に必要な最小限の権限に絞るべきです。転送中のデータにはHTTPSを使い、保存するデータは事業上本当に必要なものに限定します。イベントの完全性は、受信したWebhookが本当にその事業者から送られたものかを検証できるかにかかっています。たとえばStripeは署名シークレットでWebhookイベントに署名し、エンドポイントで検証すべき署名ヘッダーを提供しています。ShopifyはHMACヘッダーでWebhookに署名します。Salesforceとの連携では通常、コネクテッドアプリ、またはその新しい後継である外部クライアントアプリを通じたOAuthを使い、権限の範囲を限定します。信頼性も重要です。Webhookは遅れて届く、複数回届く、順序が入れ替わって届くことがあるため、ハンドラーは冪等であるべきです。また、外部への呼び出しでは、請求、注文、レコードを重複させることなく、レート制限と再試行を処理する必要があります。Stripeが冪等キー（idempotency key）をサポートしているのはこのためです。

誰のために

本ガイドは次のような方を対象としています。

決済、サブスクリプション、チェックアウトのフローを自社システムに接続するチーム
Shopifyと他のプラットフォームの間で注文、在庫、顧客を同期するEコマース事業者
SalesforceのCRMデータを社内ツールや顧客ポータルと連携する企業
制作会社やフリーランスが納品した連携作業をレビューするプロダクトオーナー

明確にするのに役立つこと

管理策を一つずつ確認することで、次の点が明確になります。

認証情報がどこに保管され、誰がアクセスでき、どのようにローテーションされるか
Webhookのエンドポイントが署名を検証し、署名のないリクエストや再送されたリクエストを拒否しているか
障害、再試行、重複が、データを破損させずにどう処理されるか
どのデータがシステム間でコピーされ、そのすべてが本当に必要か

含まれる内容

シークレットAPIキーはサーバー側にのみ置き、事業者が対応している場合はクライアントで公開可能キーを使う
シークレットはシークレットマネージャーや保護された設定に保管し、ソースコードリポジトリには決して置かない
最小限のスコープと権限を要求し、環境ごとに別々の認証情報を使う
認証情報を定期的に、またスタッフやサプライヤーの変更直後にローテーションする
事業者が文書化した方法でWebhookの署名を検証し、検証に失敗したリクエストを拒否する
イベントのタイムスタンプを確認して再送攻撃のリスクを下げ、処理済みのイベントIDを記録する
繰り返し届いたイベントで重複したアクションが生じないよう、ハンドラーを冪等にする
対応している場合は、外部への作成操作に冪等キーまたは同等の安全策を使う
レート制限にはバックオフで対応し、処理を破棄せずにキューに入れる
シークレット、カードデータ、不要な個人データを記録せずに、連携イベントをログに残す
同期ジョブやWebhookが繰り返し失敗した場合に担当者へアラートを送る
本番の認証情報に切り替える前に、事業者のサンドボックスやテストモードでテストする

含まれていないもの

PCI DSS準拠の検証や決済代行事業者の承認
不正対策の運用やチャージバックの管理
これらの管理策に従えばあらゆる連携インシデントを防げるという主張
事業者の責任範囲であるサードパーティプラットフォームの運用

それを選ぶべきとき

新しい連携を設計するとき、本番稼働の前、他チームから連携コードを引き継いだとき、そして二重決済、注文の欠落、想定外のデータアクセスを伴うインシデントの後に、このチェックリストを使ってください。連携が請求、返金、サブスクリプションの変更などの金銭的なアクションを引き起こし得る場合や、顧客の記録を露出させ得る場合には特に重要です。

私たちのアプローチ

各連携を、それぞれ担当者、ドキュメント、監視を持つ小さな製品として扱ってください。まず、連携、認証情報、Webhookのエンドポイントを一覧化します。多くの組織では、誰も作成した覚えのないキーが見つかります。次に、上記の管理策をリスクの高い順に適用します。まずシークレットと署名の検証、次に冪等性と障害時の処理、最後にログ記録とアラートです。当社のSecure Backend & API Engineering サービスは、API仕様、テストの概要、運用手順書を備えたバックエンドと連携の設計・開発を行い、本番環境へのアクセスと顧客データの利用は、明示的な書面による許可がある場合に限ります。決済とサブスクリプションのロジックが関わる場合は、Subscription & Payment Infrastructure Securityにより、合意した決済と利用権の経路を別途レビューできます。既存の連携エンドポイントについて独立した確認が必要な場合は、アプリケーションセキュリティレビューのスコープに含めることができます。

Secure Backend & API Engineering

Secure Backend & API Engineeringのサービスページを見る