数据与隐私
流程需要什么，我们就只收集什么。
我们构建的系统以数据最小化为设计原则：每个流程只采集完成任务所需的字段，并且只在需要的期限内保留。在托管方面，我们选择欧盟境内托管——生产环境运行于 AWS eu-central-1（法兰克福）——并按照与 GDPR 实践相一致的方式构建：对所处理的数据具备合法依据，响应访问和删除请求，并且默认不让个人数据进入日志和分析数据。
- 01默认数据最小化
- 02欧盟托管——AWS eu-central-1（法兰克福）
- 03符合 GDPR 实践的处理方式：合法依据、访问、删除
- 04个人数据不进入日志和分析数据
运行方式
最小权限访问，特权操作须说明理由。
我们交付的软件从第一次提交起就接入了可观测能力——日志、指标和链路追踪——生产环境中发生的一切都清晰可见，而非靠推测。访问遵循最小权限原则：无论是人还是服务，每个主体只获得完成工作所需的最小权限。敏感的运维操作在执行前须填写理由，并留下审计记录，说明谁在何时、因何、做了什么。这正是我们的运营控制台 Protocore Center 背后的模型，也是我们融入每个系统的同一套做法。
- 01默认可观测——日志、指标、链路追踪
- 02每个主体都遵循最小权限，无论是人还是服务
- 03特权操作须说明理由
- 04审计记录：谁在何时、因何、做了什么
职责分离
我们构建软件。受监管的边界由牌照承担。
支付产品由两部分融合而成：持有或转移资金的监管许可，以及发出指令、对账并展示资金的软件。Protocore 构建软件。受监管的活动——持有资金、开立账户、转移资金——由运营方自己的牌照或持牌合作伙伴承担，例如银行、EMI 或支付机构。我们会让流程适配您所采用的任何受监管通道；我们不是这种许可的替代品，任何软件也都不是。
- 01Protocore 构建软件，而非牌照
- 02受监管活动由运营方或持牌合作伙伴承担
- 03卡数据的处理方式确保其不会接触您的服务器
- 04强客户认证内置于支付流程
实践
值得信赖的系统背后的习惯。
我们内置的具体实践——以机制来说明，而非徽章。
卡数据不经过您的服务器
卡信息由支付通道处理并做令牌化，原始卡号不会接触运营方自己的基础设施。
强客户认证
SCA 内置于支付和登录流程中——在支付通道或风险要求时启用第二因素，而不是事后补加。
传输加密
流量全程通过 TLS 传输；密钥和凭据存放在托管存储和实例角色中，绝不出现在源代码里。
按租户隔离
当一个系统服务多个运营方时，各租户的数据通过访问控制相互隔离，任何租户都无法读取其他租户的数据。
漏洞披露
发现问题？请告诉我们。
如果您认为在 Protocore 的系统中发现了安全问题，请给我们发送邮件，我们会与您一起处理。我们会尽快确认收到报告，在修复期间向您通报进展，并在问题解决后按您的意愿对您致谢。请在公开披露之前给我们合理的修复时间，并且在测试期间不要访问或更改不属于您的数据。
请将您的发现及复现方法发送至 security@protocore.io。
我们会确认已收到报告并开始调查，通常在几个工作日内。
我们进行修复，并持续向您通报进展，直至问题解决。
经您同意，问题解决后我们会公开致谢。
常见问题
最常被问到的安全问题。
我们将安全视为实践，而非徽章。Protocore 构建软件层；凡适用受监管体系的场景——例如卡数据处理——经认证的边界在支付通道或运营方的持牌合作伙伴一侧，我们的构建方式确保卡数据不会接触您的服务器。如果您的项目需要特定的认证证明，请告诉我们，我们会梳理清楚各方分别负责什么。
在欧盟。生产环境运行于 AWS eu-central-1（法兰克福）。我们按照与 GDPR 实践相一致的方式构建——数据最小化、处理具备合法依据，并响应访问和删除请求。
牌照。Protocore 构建发出指令并对资金流转进行对账的软件；持有或转移资金由您自己的牌照或持牌合作伙伴承担——银行、EMI 或支付机构。任何软件都无法替代这种许可。
每个主体都遵循最小权限，特权操作须说明理由并留下审计记录。一切均可观测，因此谁做了什么有据可查，无需事后还原。
请发送邮件至 security@protocore.io。我们会尽快确认，在修复期间向您通报进展，并在问题解决后按您的意愿对您致谢。