前言
明天有个会，大家一起商量一下怎么做好数据安全。提前整理一下思路：
什么是数据安全
- 数据安全是指保护数据不被非法获取、篡改、破坏或泄露的一种技术和管理措施。
- 在我这里，数据安全要更具体一点
- 1.存储安全：数据只要写到数据库里了，就不会丢
- 1.1 存储上：多节点存储，防止物理损坏 MySQL高可用组件之ProxySQL
- 1.2 数据按固定的周期进行全备和日志备份 数据库备份管理制度
- 1.3 自动化脚本检查备份成功和验证
- 1.4 保证数据被意外删除后，还能找回来 自动化流程:数据找回(一:MySQL数据闪回) 自动化流程:数据找回(二:Oracle部分)
- 1.5 保证数据和数据库备份是双机房异地存储 数据库备份管理制度
- 1.6 额外做孤岛备份，以防止内网机房的病毒大面积感染 孤岛备份机和勒索病毒
- 2.账号策略：只有指定权限的用户可以访问可控范围内的数据（到库级别）
- 要求研发分业务存储库，不要混用数据库
- 账号自动化管理，权限限制在可控范围内
- 账号密码不分发给研发，由运维人员统一配置（这点很重要，为第三步的访问控制提供前题）
- 3.访问控制：将业务人员和运维人员隔离
- 业务人员指研发，产品，测试，大数据，风控…
- 运维人员：DBA 运维
- 只有运维人员可以接触到线上数据库，研发和其他人员均不可连接到数据库机器和实例
- 将研发等业务人员和数据库的接触限定在两个方式内：1.通过程序代码操作数据库 2.通过DBA的Web平台操作数据库
- 线上查询和线上变更。走DBA提供的平台执行
- 限制DBA等运维人员，了解业务逻辑，杜绝DBA直接查询和修改线上业务数据 我为什么要反对DBA参与业务(出报表/改数据)
- 4.安全审计：线上的数据异常，要有日志可查
- 数据变更日志（binlog，归档日志等） MySQL的7种日志(四):BinLog
- SQL上线日志 （记录变更新镜像和更新后结果，方便快速回滚） 数据库多环境SQL上线
- 异常日志和慢日志收集到es
- 服务器操作日志，数据库账号变更日志
- 个人查询日志，部分线上查询审计日志
- 5.数据加密：数据库里的敏感信息应该加密存储
- 哪些属于敏感信息：手机号.卡号.身份证号.住址…
- 首先需要把敏感信息标识出来。
- 为此我们开发了一个工具，在用户建表或者修改表结构时，会识别出来
- 外加一个兜底脚本，定时扫描SQL查询结果，如果发现有敏感信息未标识的就会提示出来
- 敏感信息标识后，不管底层是否做了加密存储，DBA和大数据平台都可以对这些字段做针对性的掩码，防止信息泄露
- 数据的加密存储，这个单做一节，详细说说
数据加密
- 如上一节最后说的，我们已经将敏感信息识别出来了，现在怎么做数据的加密存储。根据实际情况展开来说
新项目的数据加密
- 如果有开发资源：架构组开发一套通用的加密服务，新项目调用
- 如果没有开发资源： 研发用通用的加密算法对敏感信息进行可逆的加密（例AES)后入库
老项目的数据加密改造
方法一：数据库里存的是加密数据，研发存放和读取都是明文数据
- 应付审计之法。
- 优点是：库里的数据确实是加密的
- 缺点是：研发和业务人员查询时是明文的
- 这个需要借助第三方中间件来实现：（例如SphereEx）
- 我头一次听SphereEx讲他们的中件层加密时，觉得这个思路非常棒
- 这可能是比较节约开发资源的，又可以应付审计的一种加密方式。
- 这是它的优点也导致了一个缺点：研发查出来数据库里的信息还是明文，数据防泄露效果差
- 只防住了DBA和运维人员的泄密，而更关键的业务泄露并没防住
- 加了中间层，稳定性待考证
- 加密收益： 2颗星 ，加密工作量：1颗星
方法二：数据库里存的是明文数据，研发读取到前台展示的时候是密文的
- 防前台泄密之法
- 在SQL层将所有的查询接口都改造一下，需要花费不少的时间（2-3周）
- 优点是，前台用户看到的数据是加密或掩码的。解密记录是可审计的，防止信息泄漏
- 缺点是，数据库明文存储了，治标了但没治本
- 加密收益： 4颗星 ，加密工作量：3颗星
方法三：数据库里存的是密文数据，研发读取到前台展示的时候是密文的
- 这个就是把旧项目彻底改造了，存数据和读数据的地方都要改一下
- 这个改造的工作量非常大，但是效果是最彻底的
- 最完整的方案是分成三个角色
- DBA提供存储，架构组提供加解密服务，研发存储和读取的都是密文
- 其中架构组是核心，提供整套加解密服务
- 研发参与成本最大，需要在写数据和读数据时修改代码
- 加密收益： 5颗星 ，加密工作量：4颗星
