信息安全政策

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

• 安全联系人：security@didit.me
• 数据保护官：dpo@didit.me
• 状态页面（实时）：status.didit.me
• 信任包（需签署NDA）：发送电子邮件至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 Key Management Service (KMS) 负责密钥的持有和轮换。应用程序代码绝不接触原始密钥材料。沙盒和生产密钥完全分离。
• 哈希： 客户凭据使用行业标准自适应函数（bcrypt或等效函数）进行哈希处理。API密钥以单向哈希形式存储；原始值仅在创建时向操作员显示。

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

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

6. 数据驻留和隔离

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

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
• 信任包请求（需签署NDA）：security@didit.me