与 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 服务可以单独审查约定的支付与权益路径。如果您希望对现有集成端点进行独立检查，应用安全评审可以将其纳入范围。
常见问题
相关文章
立即开始
正在规划或审查业务关键集成？
请告诉我们涉及的平台、在平台之间流转的数据和事件，以及您遇到过的任何问题。我们将提出书面范围说明。
申请书面范围说明