Stripe 的安全性

在敏感数据问题上，我们的用户信任 Stripe，并依赖我们充当其客户的良好数据保管人。作为一家支付基础设施公司，我们的安全状况持续满足全球金融行业的严苛标准。

标准与合规

Stripe 使用同类最佳的安全做法来保持高级别的安全性。

PCI 认证

Stripe 已经过具有 PCI 认证的审核员审核，获得支付卡行业 1 级服务提供商认证。这是支付行业中最严格的认证级别。此次审核包括 Stripe 的银行卡数据仓库 (Card Data Vault, CDV) 和我们集成代码的安全软件开发。

我们为用户提供一些用于自动化 PCI 合规性问题的功能。

• 我们会分析用户的集成方法，并动态通知他们使用哪种 PCI 验证表单。
• 如果用户要集成 Stripe Elements、Checkout、Terminal SDK 或我们的移动端库，我们会在管理平台中协助完成他们的 PCI 验证表（自我评估问卷 A）。
• 我们发布了一份 PCI 合规指南，以帮助我们的用户了解 PCI 合规性以及 Stripe 可以提供何种帮助。

系统和组织控制 (SOC) 报告

作为我们的 SOC 1 和 SOC 2 合规计划的一部分，Stripe 的系统、流程和控制定期接受审核。SOC 1 和 SOC 2 类型 II 报告每年编制一次，可根据要求提供。

系统和组织控制 (SOC 3) 报告是依据美国注册会计师协会审计准则委员会 (AICPA) 的信任服务标准 (TSC) 制定的。Stripe 的 SOC 3 是一份关于安全性、可用性和机密性内部控制的公开报告。查看我们最近的系统和组织控制 (SOC 3) 报告。

银行卡终端的 EMVCo 标准

Stripe Terminal 在银行卡和终端安全与互操作性方面已通过 EMVCo 1 级和 2 级 EMV® 规范的标准认证。Terminal 还通过了 PCI 支付应用数据安全标准 (PA-DSS) 的认证，这是一项全球安全标准，旨在防止为第三方开发的支付应用存储被禁止的安全数据。

NIST 网络安全框架

Stripe 的信息安全政策套件及其总体设计符合 NIST 网络安全框架。我们的安全实践符合我们的企业客户的标准，这些客户必须提供安全的产品，如按需云计算和存储平台（例如，DigitalOcean 和 Slack）。

隐私和数据保护

Stripe 的隐私保护做法符合 CBPR 和 PRP 制度，这一点已通过 Stripe 获得的 CBPR 和 PRP 认证得到了证明。要查看我们的认证状态，请点击这里 (CBPR) 和这里 (PRP)。Stripe 还遵守美国商务部设定的欧美数据隐私框架 (EU-U.S. Data Privacy Framework, “DPF”)、欧盟-美国数据隐私框架的英国延伸版 (the UK Extension to the EU-U.S. DPF)，以及瑞士-美国数据隐私框架 (Swiss-U.S. Data Privacy Framework)。要查看我们的认证情况，请查看这里。

我们持续实施不断演变的隐私和数据保护流程和程序，以及所有适用的隐私和数据保护制度下的最佳实践。 有关更多信息，请参见以下资源：

• 隐私政策
• 隐私中心
• 数据处理协议

Stripe 产品安全保障

安全性是 Stripe 所有的产品设计和基础设施决策的指导原则之一。 我们提供一系列功能来帮助用户更好地保护他们的 Stripe 数据。

敏感动作验证

Stripe 管理管理平台支持多种形式的多因素验证 (MFA)，包括：短信、基于时间的一次性密码算法 (TOTP)、硬件安全密钥和通行密钥。 我们还通过安全声明标记语言 (SAML) 2.0 支持单点登录，允许客户规定登录要求、配置访问控制，并通过即时账户分配即时入驻团队成员。

必须对来自用户的支持请求进行身份验证，方法一是从管理平台发送请求（登录后），方法二是验证账户访问后再提供支持响应。通过要求身份验证，我们可将风险降至最低，避免向未授权人员提供任何信息。

访问限制和审查

从管理平台中，用户可以分配不同的详细角色来为其员工启用最低权限访问，并创建受限访问密钥来降低 API 密钥泄露的安全性和可靠性风险。

用户还可以在其安全历史记录中查看重要账户更改和活动的审查日志。这些审查日志包含敏感的账户活动记录，如登录或更改银行账户信息。 我们监控登录活动并注意：

• 如果其来自相同或常用的设备
• 如果其来自一致的 IP 地址
• 失败的尝试

用户可以从日志中导出历史信息。 对于时间敏感的活动，例如从未知 IP 和设备登录，我们会发送自动通知，从而避免手动查看日志。

HTTPS 和 HSTS 的安全连接

我们强制要求所有使用 TLS (SSL) 的服务使用 HTTPS，包括我们的公共网站和管理平台。 我们定期审核实施的细节，包括我们提供的证书、我们使用的证书颁发机构以及我们支持的密码。我们用 HSTS 来确保浏览器仅通过 HTTPS 与 Stripe 交互。Stripe 也被列于 HSTS 所有主流浏览器的预装列表中。

服务器间的所有通信均采用相互传输层安全协议 (mTLS) 进行加密，而且 Stripe 拥有专用的 PGP 密钥供用户加密与 Stripe 的通信，或验证他们从 Stripe 接收的签名消息。Stripe 的系统会自动阻止使用较旧、安全性较低的 TLS 版本发出的请求，要求至少使用 TLS 1.2。

stripe.com 域名，包括管理平台和 API 子域都位于 Chrome 的顶级域名列表中，为防范“同形字攻击 (homoglyph attack)”提供了额外的保护。这样，就更难在 Chrome 中创建看起来像 stripe.com 的虚假页面（例如，strípe.com），其呈现为微代码形式 (xn–strpe-1sa.com)，从而使 Stripe 证书更难被钓鱼攻击。

主动网络监控

我们会主动在互联网上扫描商家的 API 密钥。一旦发现有泄露的密钥，我们会采取适当的措施，建议用户滚动其 API 密钥。当用户的 API 密钥在 GitHub 上泄露时，我们使用 GitHub Token Scanner 来提醒我们。一旦我们发现外部钓鱼页面可能会捕获我们的用户，我们会主动与供应商合作，将这些页面删除并报告给 Google Safe Browsing 团队。

基础设施保障

我们的安全团队通过扫描漏洞、进行渗透测试及“红队演习”来定期测试我们的基础设施。我们聘请行业领先的安全公司对我们的系统进行第三方扫描，一旦发现缺陷，会立即处理。我们的服务器会经常自动更换，以保持其健康度，并丢弃陈旧的连接或资源。服务器操作系统在其安全寿命终止 (EOL) 日期之前就已升级。

专用银行卡技术

Stripe 对传输中和静态的敏感数据进行加密。 Stripe 用于存储、解密和传输主账号 (PAN)（如信用卡号）的基础设施在单独的托管基础设施中运行，不与其他服务共享任何证书。我们有一个专门的团队在一个独立的 Amazon Web Services (AWS) 环境中管理我们的 CDV，该环境与 Stripe 的其余基础设施彼此分离。只有少数经过专门培训的工程师才能进入这一独立环境，并且每季度对其进行一次审查。

所有卡号在静止时都用 AES-256 加密。解密密钥在不同的机器上存储。我们在内部标记 PAN，将原始数字与基础架构的其余部分隔离开来。 Stripe 的内部服务器和守护进程都不能获得明文卡号，但可以请求将卡发送到静态允许列表上的服务提供商。Stripe 用于存储、解密和传输卡号的基础架构在单独的托管环境中运行，不与 Stripe 的主要服务（包括我们的 API、网站等）共享任何证书。 不仅以这种方式标记 PAN；我们还以类似方式对待其他敏感数据，如银行账户信息。

企业技术

Stripe 对员工访问管理采取零信任方法。员工利用单点登录 (SSO)、基于硬件令牌的双重验证 (2FA) 以及 “相互传输层安全协议”(mTLS)，通过 Stripe 发放的机器上的加密证书进行身份验证。连接到网络后，敏感的内部系统和员工标准工作范围之外的系统需要额外的访问权限。

我们会监控审计日志，以检测异常情况，监视入侵和可疑活动，还监控代码库中敏感文件的更改。Stripe 的所有代码都经过了多方评审和自动化测试。代码更改会被记录在一个不变的、防篡改的日志文件中。我们不断收集有关 Stripe 派发的笔记本电脑的信息，以监控恶意程序、欺诈性域连接和入侵活动。我们有一个全面的流程来允许员工笔记本电脑上安装许可软件，防止安装未经批准的应用程序。。

安全态势维护

我们的开发人员在项目生命周期的早期与安全专家合作。作为我们安全审查流程的一部分，安全专家会开发出威胁模型和信任边界，以帮助指导项目的实施。开发人员利用相同的流程对敏感的代码片段进行修改。

专属专家随时待命

我们有许多专门的安全团队，他们专注于不同的安全领域，包括基础设施、运营、隐私、用户和应用程序。安全专家 24/7 全天候待命。我们专注于不断提高最佳实践的标准，以最大限度地降低网络安全风险。

保障安全，是每名 Stripe 员工的责任

我们要求每位 Stripe 员工每年完成安全教育，并且我们为 Stripe 工程师提供安全软件开发培训。我们在内部开展网络钓鱼活动，以测试 Stripe 的每个人在识别网络钓鱼企图并将其标记给相应的安全团队的能力。

管理访问控制

我们拥有授权访问系统和信息的正式流程；我们会定期审查并自动删除非活动访问。对基础设施中最敏感区域进行的操作需要人工审查。为了以最佳方式实施访问控制，我们的安全专家构建了原语来帮助 Stripe 团队实现最小特权原则。为最大限度降低风险，我们制定了数据保留政策，在遵守法规和业务要求的同时，最大限度地减少我们保留的数据。

漏洞披露和奖励计划

我们有一个漏洞披露和奖励计划（“漏洞奖励”），以此对帮助我们保护用户安全的独立安全研究人员进行补偿。 通过 HackerOne 向 Stripe 提交安全漏洞或缺陷，即表示您已阅读并同意计划条款和条件。请参考我们关于 HackerOne 的政策，了解如何参与我们的“漏洞奖励”计划的更多信息。