数据安全主要从数据防丢失、防篡改、防泄密 三个角度考虑。

下文主要围绕数据保密评估数据安全相关措施，不涉及数据丢失、高可用等话题

数据的流向

访客访问网站请求数据，通常途径前端网页 -> 应用服务器 -> 数据库服务器，而后在数据库服务器硬盘中取出数据原路返回。

针对数据存储加密的场景，可忽略前端环节，仅考虑 应用、数据库、硬盘 三个关键节点；在未进行任何加密的情况下，研发或运维人员一般可以通过：

  1. [数据库访问] 通过数据库地址、账号密码等信息直连数据库进而获取数据
  2. [应用层] 控制应用中访问数据库的相关逻辑，进而获取到所需数据
  3. [数据库服务器] 控制数据库服务器，重置数据库密码以达到访问数据的目的
  4. [数据库硬盘] 访问数据库服务器，将相关数据文件复制到己方机器并设法访问

结合实际业务场景，通过必要的流程、访问限制、数据加密使上述行为受到约束，即可兼顾数据安全与研发效率

数据库访问

数据库的访问需要受到特定的限制：

  1. 只允许白名单内的 IP 进行访问，一般来说只允许应用服务器访问
  2. 需要开启审计功能（general_log），使管理员能够追溯到一定时间范围内的连接和执行信息
  3. 不同业务拥有专有账号，不能混用
  4. 一般情况下，不允许自然人直接访问数据库，表结构的变更需要通过审计平台/审计人确认
  5. 最小权限原则。只为每个账号赋予其实际所需的访问权

应用层/程序研发

应用通过访问数据库最终获取到未加密数据，是正常的业务逻辑需要；围绕应用服务器的合规操作可以有：

  1. 必须通过有审计功能的堡垒机访问应用服务器
  2. 禁止堡垒机之外的登录行为
  3. 程序需要遵循发布流程，敏感服务功能变更时，代码需要有审核环节
  4. 程序代码中不能包含生产环境的任何敏感配置信息，做到即使代码泄露，也不影响数据安全
  5. 一般情况下，研发人员不应持有生产环境的任何敏感配置信息；相关配置信息由持续集成平台在构建或程序启动时注入
  6. 若程序构建为 Docker 镜像，镜像中不应包含生产环境的任何敏感配置信息；做到即使镜像泄露，也不影响数据安全

数据库服务器 / 硬盘

运维或研发人员可能具备访问数据库服务器的权限，如何控制此风险？

  1. 敏感信息加密。做到即使被拖库，也不会泄露敏感内容
  2. 数据库连接信息、敏感密钥信息分离存管。实现方案另开一篇叙述

数据传输

  • 网站、API 需要做到全站 HTTPS
  • HTTP 请求 301 重定向到对应 HTTPS 地址

Checklist

事项 完成
[数据库] IP 白名单
[数据库] 开启审计功能
[数据库] 每个业务账号独立
[数据库] 账号权限满足最小原则
[应用服务器] 通过有审计功能的堡垒机访问
[应用服务器] 禁止堡垒机以外的登录行为
[应用服务器] 异常行为即时通知
[应用服务器] 敏感功能需要两步验证
[研发] 敏感服务功能变更时代码审核
[研发] 代码无任何敏感配置信息
[研发] 研发人员不持有敏感配置信息
[数据加密] 敏感字段内容存储加密
[数据加密] 加密密钥与连接信息分离存管
[数据加密] 加密密钥定时变更
[传输] 全站 HTTPS
[前端] 支持水印