與 Stripe、Shopify 與 Salesforce 等平台的整合，往往是業務關鍵資料與資金在系統之間流動的地方。這裡也常出現便宜行事的做法：把 API 金鑰貼進前端程式碼、Webhook 端點接受任何請求，或同步工作無聲無息地失敗。每家服務商都發布了詳細的安全指引，但您的團隊撰寫的整合程式碼仍由您負責。本指南介紹能讓整合更安全、更可靠的實用控制措施。
服務簡介
安全的整合需要保護三樣東西：授予存取權限的憑證、在系統之間流動的資料，以及觸發動作的業務事件之完整性。憑證包括 API 金鑰、OAuth 權杖與用戶端密鑰；它們只應存放在伺服器端，保存在機密管理工具或受保護的環境設定中，並僅授予整合所需的最小權限。傳輸中的資料使用 HTTPS，靜態儲存的資料則僅限於業務確實需要保存的內容。事件完整性取決於能否驗證傳入的 Webhook 確實來自服務商。例如，Stripe 使用簽章密鑰為 Webhook 事件簽章，並提供簽章標頭，您的端點應加以驗證；Shopify 使用 HMAC 標頭為 Webhook 簽章；Salesforce 整合通常透過連線應用程式（connected app）或其較新的替代方案外部用戶端應用程式（external client app）使用 OAuth，並設定限定範圍的權限。可靠性同樣重要。Webhook 可能延遲送達、重複送達或順序錯亂，因此處理程式應具備冪等性，對外呼叫也應在處理速率限制與重試時，避免重複扣款、重複下單或重複建立紀錄。正因如此，Stripe 支援冪等金鑰（idempotency key）。
適用對象
本指南適用於：
- 將付款、訂閱或結帳流程與自有系統串接的團隊
- 在 Shopify 與其他平台之間同步訂單、庫存或客戶資料的電子商務企業
- 將 Salesforce 中的 CRM 資料與內部工具或客戶入口網站整合的企業
- 審查由代理商或自由工作者交付之整合工作的產品負責人
有助釐清的問題
逐項檢視這些控制措施，有助於釐清：
- 憑證存放在哪裡、誰可以存取，以及如何輪替
- Webhook 端點是否驗證簽章，並拒絕未簽章或重送的請求
- 如何在不破壞資料的前提下處理故障、重試與重複事件
- 哪些資料在系統之間複製，以及是否全部都有必要複製
包含內容
- 僅在伺服器端保存私密 API 金鑰；在服務商支援的情況下，用戶端使用可公開金鑰（publishable key）或公開金鑰
- 將機密資訊存放在機密管理工具或受保護的設定中，切勿放入原始碼儲存庫
- 申請最小的權限範圍；為每個環境使用個別的憑證
- 依排程輪替憑證，並在人員或供應商異動後立即輪替
- 依服務商文件中的方法驗證 Webhook 簽章，並拒絕驗證失敗的請求
- 檢查事件時間戳記以降低重送風險，並記錄已處理的事件 ID
- 讓處理程式具備冪等性，避免重複事件引發重複動作
- 在支援的情況下，對外部建立操作使用冪等金鑰或同等保護措施
- 以退避方式處理速率限制，將工作排入佇列，而不是直接丟棄
- 記錄整合事件，但不記錄機密資訊、信用卡資料或不必要的個人資料
- 當同步工作或 Webhook 反覆失敗時，向相關人員發出警示
- 在切換到正式憑證之前，先在服務商的沙盒或測試模式中進行測試
不包含內容
- PCI DSS 合規驗證或支付處理機構的核准
- 詐欺防制作業或退單管理
- 宣稱遵循這些控制措施即可防止所有整合事故
- 第三方平台的營運，這仍由各服務商負責
適用時機
在設計新整合時、上線之前、從其他團隊接手整合程式碼時，以及發生任何涉及重複付款、訂單遺失或非預期資料存取的事件之後，請使用本清單。當整合能觸發扣款、退款或訂閱變更等金融動作，或可能暴露客戶紀錄時，這一點尤其重要。
我們的方法
將每項整合視為一個小型產品，擁有各自的負責人、文件與監控。首先盤點整合、憑證與 Webhook 端點；許多組織會發現一些沒人記得何時建立的金鑰。接著依風險順序套用上述控制措施：先處理機密資訊與簽章驗證，再處理冪等性與故障處理，最後是日誌與警示。我們的 Secure Backend & API Engineering 服務負責設計與交付後端及整合工作，提供 API 合約、測試摘要與維運手冊，且僅在取得明確書面授權的情況下使用正式環境存取權限與客戶資料。如果涉及付款與訂閱邏輯，Subscription & Payment Infrastructure Security 服務可以另行審查約定的付款與權益路徑。如果您希望對現有整合端點進行獨立檢查，應用程式安全審查可以將其納入範圍。
常見問題
相關文章
立即開始
正在規劃或審查業務關鍵整合？
請告訴我們涉及的平台、在平台之間流動的資料與事件，以及您遇過的任何問題。我們將提出書面範圍說明。
申請書面範圍說明