加密
哪些地方使用了加密,哪些地方尚未使用。
加密在验证过程中的多个不同环节提供保护:连接、图像、密钥、备份和密码。我们宁愿逐一如实列出,也不愿只说一句“已加密”,让您误以为它涵盖了一切。
传输中
在边缘节点使用 TLS,并在账本数据库上强制启用。
发送到 ShieldID 的每个请求在到达应用程序之前都会被加密。
- 公共边缘节点为每个连接终止 TLS,并启用 HSTS 和一组严格的安全标头,因此请求在到达其后的任何组件之前就已加密。
- 主账本数据库对其接受的每个连接强制使用 TLS。明文连接会被直接拒绝,而不是仅靠配置加以劝阻。
- 应用程序会依据固定的证书颁发机构验证数据库的证书并检查其主机名,而不是信任最先出现的任意证书。
静态存储
证件图像和出生日期已加密。至于其他哪些内容尚未加密,我们也会具体说明。
“静态加密”常被用来一口气概括整个平台。以下是它目前实际涵盖的范围。
- 证件图像和自拍照
- 存储期间使用 AES-256-GCM 加密,直至自动清除任务将其删除。
- 出生日期
- 以加密形式存储,无论验证记录保存在何处,都绝不以明文存放。
- 密钥与机密(API 密钥、数据库凭据、签名密钥)
- 存放在专用密钥保险库中,而不是应用配置或源代码里。
- 数据库的其余部分和通用存储卷
- 目前尚未在磁盘或数据库层面加密。我们直接说明,而不是暗示全面覆盖。
机密信息
一个保险库,令牌访问控制,轮换有据可查。
应用程序凭据不会零散分布在各个配置文件中。
集中管理
API 密钥、数据库凭据和 webhook 密钥存放在专用的机密管理系统中,仅能通过经过身份验证、受令牌控制的 API 进行读写。
轮换经过审计
专用的轮换流程会将每一次凭据变更和每一次被拒绝的尝试记录在防篡改日志中,日志只保存值的指纹,绝不保存值本身。
绝不出现在代码或配置中
机密信息在启动时从保险库读取,不会提交到源代码,也不会留在随部署一同发布的环境文件中。
备份
在离开内存之前即已加密,并提供无需触碰生产环境即可运行的恢复演练。
备份涵盖应用程序、其配置和数据库。
- 使用 AES-256 加密,密钥存放在密钥保险库中。如果无法获取该密钥,备份脚本会拒绝写入未加密的文件,而不是悄悄退而求其次。
- 我们有记录在案的脚本化恢复流程,并支持恢复到临时位置的演练模式,因此无需触碰线上数据即可测试该流程。
- 目前备份保存在同一场所内。我们不提供异地冗余备份或独立的灾难恢复站点,并且不仅在此处,也在数据驻留和合规页面中如实说明。
密码、会话和 API 密钥
任何用于验证您身份的信息,都不会以他人可读取并重复使用的形式存储。
三种不同的机密,三种不同的处理方式,全部为单向处理。
- 密码
- 经过哈希处理,绝不以明文存储或记录日志。
- 会话令牌
- 您浏览器会话 Cookie 中的令牌是一个随机的 32 字节值,并设置为 HttpOnly Cookie。
- API 密钥
- 以 SHA-256 哈希形式存储。仅以明文保留一个较短的前缀,这样您可以在列表中辨认出某个密钥,而完整的值再也无法被取回。
本页面不作的声明
没有 DDoS 防护,没有 WAF,没有异地冗余。
目前我们并未部署在内容分发网络或 Web 应用防火墙之后,也不声称我们存储的每一个字节都经过磁盘或数据库层面的加密。基础的速率限制保护着登录及其他高成本的端点,但它还不是一个经过加固、持久有效的防滥用层。如果某项具体控制措施对贵组织自身的审查很重要,请直接询问我们,而不要假定某个笼统的说法已涵盖它。
常见问题