信息安全政策

本信息安全政策描述了 Didit 持有的认证、Didit 运营的技术和组织控制以及可供客户、潜在客户、监管机构和审计师使用的信任凭证。它至少每六个月审查一次。

• 安全联系方式：security@didit.me
• 数据保护官：dpo@didit.me
• 状态页面（实时）：status.didit.me
• 信任包（需签署保密协议）：发送电子邮件至 security@didit.me

1. 认证和证明

如需索取任何基础报告或证书，请发送电子邮件至 security@didit.me。受其颁发机构条款限制的报告（例如 SOC 2 Type 1）将在签署保密协议 (NDA) 后于同一工作日内共享。

2. 范围

本政策涵盖所有 Didit 人员（员工、承包商和授权第三方）、所有 Didit 生产和企业信息系统以及 商业条款和条件 中描述的面向客户的服务。它由支持 Didit ISO/IEC 27001:2022 管理系统的适用性声明支持。

3. 治理

• 信息安全和隐私管理系统与 ISO/IEC 27001:2022 和 ISO/IEC 27701 控制措施对齐，并附有文档化的适用性声明。
• 首席技术官是指定的信息安全执行发起人；数据保护官 (dpo@didit.me) 负责隐私计划治理。
• 年度外部安全审计由独立审计师进行（ISO 27001 监督和 SOC 2 检查）。
• 风险登记册每季度审查和更新。重大风险上报至管理委员会。
• 持续改进，每个事件、审计发现和风险评估都将纳入纠正措施积压和下一次政策更新。

4. 加密和密钥管理

• 静态： 所有生产数据库、对象存储和备份卷均采用 AES-256 加密。
• 传输中： 所有外部 API 调用、Webhook 和商业控制台会话均采用 TLS 1.3。旧版 TLS 版本和弱密码已禁用。HTTP 严格传输安全 (HSTS) 在全站强制执行并预加载。
• 密钥管理： AWS 密钥管理服务 (KMS) 负责密钥的存储和轮换。应用程序代码绝不接触原始密钥材料。沙盒和生产密钥完全分离。
• 哈希： 客户凭据使用行业标准自适应函数（bcrypt 或等效函数）进行哈希处理。API 密钥以单向哈希形式存储；原始值仅在创建时向操作员显示。

5. 身份、访问和零信任架构

• 默认零信任，对每个内部系统的每个请求都进行身份验证和授权。不基于网络位置进行隐式信任。
• 基于角色的访问控制 (RBAC)，遵循最小权限原则。每季度进行访问审查。
• 多因素身份验证 (MFA) 对每个员工、每个生产系统、每个云控制台和每个代码托管账户都是强制性的。
• 单点登录 (SSO) 用于内部应用程序，特权角色使用硬件令牌 MFA。
• 即时访问用于生产：长期特权访问是例外，而非规则。
• 审计日志记录，每个特权操作都记录到防篡改、一次写入的审计管道中，并保留至少 12 个月。

6. 数据驻留和隔离

• 默认欧盟。 生产数据在欧盟的 Amazon Web Services 上处理和存储。对于监管机构有要求的司法管辖区，可根据可用性在企业合同中提供特定区域或国内驻留。
• 环境隔离。 沙盒、暂存和生产在网络、身份和密钥管理层进行隔离。一个环境中的任何人员或服务都无法在没有明确、经过审计的访问路径的情况下读取另一个环境中的数据。
• 租户隔离。 多租户数据通过每个租户的加密密钥进行逻辑隔离（如适用）。跨租户查询在应用程序和数据库层被阻止。

7. 安全开发生命周期 (SDLC)

• 代码审查是每个生产变更的必需环节。任何工程师都不能在未经审查的情况下将代码合并到生产环境。
• 静态应用程序安全测试 (SAST)、依赖项扫描和软件组成分析 (SCA) 在每个拉取请求上自动运行。
• 容器和基础设施扫描在每次构建时以及对已部署镜像的定期计划中进行。
• 高影响变更（身份验证、密钥管理、生物识别管道、支付流程）的预生产安全测试。
• 内部渗透测试持续进行；外部渗透测试每年至少一次由独立专家进行。重大发现将根据 SLA 绑定的时间表进行跟踪直至解决。
• 漏洞赏金/负责任披露渠道，将安全问题报告至 security@didit.me。

8. 漏洞管理

• 按严重性划分的补丁 SLA，关键（供应商披露后 72 小时内），高（7 天内），中（30 天内），低（90 天内）。
• 持续漏洞扫描覆盖生产基础设施、容器和依赖项。
• 威胁建模用于新产品界面、生物识别管道和跨环境集成。

9. 监控、检测和事件响应

• 24x7 监控每个生产系统，并对可用性、错误和安全信号进行警报。
• 安全信息和事件管理 (SIEM) 聚合和关联安全事件；异常模式上报给值班安全工程师。
• 文档化的事件响应计划，包含指定角色、通信树、严重性矩阵和事件后审查流程。该计划至少每年通过桌面演练进行测试。
• 个人数据泄露通知。 Didit 不无故延迟通知受影响的客户，无论如何都会及时通知，以便客户能够履行其在通用数据保护条例 (GDPR) 第 33 条项下的 72 小时通知义务。企业客户将获得一名指定的待命工程师和专用通信渠道。
• 公共状态页面位于 status.didit.me，所有生产事件、所有事后分析，无需登录。

10. 业务连续性和灾难恢复

• 每个生产区域的多可用区主动冗余；无状态服务自动故障转移。
• 备份已加密，在选定的驻留边界内进行地理分离，并按定期计划进行测试。
• 核心验证 API 和商业控制台的恢复点目标 (RPO) ≤ 1 小时和恢复时间目标 (RTO) ≤ 4 小时。
• 灾难恢复 (DR) 测试至少每年进行一次。

11. 人员安全

• 对所有有权访问生产数据或个人数据的员工和承包商进行背景调查，在适用法律允许的情况下。
• 所有员工和承包商在入职时签署保密协议。
• 所有员工在入职时和至少每年更新一次强制性安全和隐私培训。针对需要特定培训的角色（安全编码、生物识别数据处理、反欺诈、反洗钱）进行有针对性的培训。
• 定期进行网络钓鱼模拟。
• 入职/调动/离职流程在角色变更或离职后 24 小时内撤销访问权限。

12. 供应商和子处理方管理

• 每个子处理方在入职前进行风险评估，并至少每年重新审查一次。
• 每个子处理方都签署一份数据处理协议 (DPA)，其中规定了与 Didit 对其客户承担的义务基本相似的数据保护义务。
• 当前的子处理方列表在签署保密协议 (NDA) 后通过电子邮件与客户和潜在客户共享。发送电子邮件至 security@didit.me 请求。订阅子处理方变更通知的客户将收到电子邮件通知，并有足够的提前通知时间提出异议。

13. 数据主体权利和删除

• 访问和可移植性权利，`GET /v3/sessions/:session_id/decision/`。
• 删除权利，`POST /v3/sessions/:session_id/delete/`。删除会话和所有关联的工件，包括所有副本。
• 每个应用程序的保留期限可在商业控制台中配置，范围为 30 天到 10 年；默认情况下是无限期，除非客户配置较短的期限。生物识别数据保留在任何情况下均受适用生物识别隐私法律法规的约束和限制，包括欧盟通用数据保护条例 (GDPR) 第 9 条、伊利诺伊州生物识别信息隐私法 (BIPA)、德克萨斯州生物识别标识符捕获或使用法 (CUBI) 和华盛顿州 H.B. 1493，以及任何其他适用的生物识别隐私法律；如果此类法律规定了较短的保留期限或较早的销毁义务，则该较短或更严格的规则优先于任何默认或客户配置的保留期限。
• 有关完整的数据主体权利流程，请参阅 隐私政策 和 验证隐私声明。

14. 报告安全问题

如果您认为在任何 Didit 产品或服务中发现了安全漏洞，请发送电子邮件至 security@didit.me，并附上描述、重现步骤以及您观察到的影响。Didit 将在 2 个工作日内确认安全报告，并与遵循负责任披露实践的报告者真诚合作。

15. 联系方式

• 安全：security@didit.me
• 数据保护官：dpo@didit.me
• 隐私：privacy@didit.me
• 法律/合同：legal@didit.me
• 信任包请求（需签署保密协议）：security@didit.me