读数据安全架构设计与实践07可审计

1. 可审计

1.1. 可审计（Auditable）就是记录所有的敏感操作，并可用于事件追溯

1.2. 审计功能主要体现在操作日志方面

• 1.2.1. 记录下来的内容，即通常所说的操作日志

1.3. 确保能够通过操作日志来还原事件的真相（通常称之为“复盘”​）​，找到事件发生的真正原因并改进相关的薄弱环节

1.4. 审计的目的

• 1.4.1. 发现产品自身的安全缺陷，改进产品的安全特性，消除产品自身的安全隐患

• 1.4.2. 为安全防御体系的改进提供支持

• 1.4.3. 为诉讼或其他法律行动提供证据

• 1.4.4. 满足监管或外部认证的合规要求

• 1.4.4.1. 提取安全系统拦截或阻断非法请求的证据，可用于合规性证明

1.5. 基于审计日志构建日常例行的大数据分析与事件挖掘活动，主动发现未告警的安全事件或隐患

2. 操作日志内容

2.1. 时间（When）​、地点（Where）​、人物（Who）​、事件（What）​，称为记叙文的四要素

2.2. 操作日志应当排除敏感信息，记录敏感信息可能导致信息泄露，如业务一定需要记录的话，可采取脱敏措施（用*替换部分敏感信息）​

2.3. 时间

2.4. 用户IP地址

2.5. 用户ID（用户名）​

2.6. 操作（增删改查）和操作对象（数据或资源）​

• 2.6.1. 对数据的新增、删除、修改、查询

• 2.6.2. 对资源的申请、释放、扩容、授权等

• 2.6.3. 对流程的审批通过、驳回、转移

• 2.6.4. 对交易的发起、支付、撤销

• 2.6.5. 对人员的授权、吊销授权

3. 操作日志的保存与清理

3.1. 安全性要求不高的应用，一般在应用自身保存操作日志即可

3.2. 安全性要求较高的应用，应当提交日志或日志副本到独立于应用之外的日志管理系统，且无法从应用自身发起删除

3.3. 日志管理系统是多个应用系统共用，通过应用层接口接收日志，而不是直接开放数据库端口

• 3.3.1. 应用系统不需要持有日志管理系统的数据库账号，也就无法直接从应用自身发起对日志的删除操作

3.4. 日志的保存期限

• 3.4.1. 一般至少需要保留六个月的操作日志，用于追溯

• 3.4.2. 对于超时的日志，为了保障可维护性，应当配置成自动清理过期日志的机制，而不是人工清理。否则会由于人员的遗忘、疏忽，导致磁盘空间被占满的情况，影响应用的可用性

4. 资产保护

4.1. Asset Protection

4.2. 保护资产全生命周期的安全性

4.3. 资产包括数据与资源两大类，其中，对数据的保护是资产保护的重中之重

4.4. 不再局限于数据的安全存储，而是包括数据的生成、使用、流转、传输、存储在内的全生命周期的安全管控，以数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪为目标

5. 数据安全存储

5.1. 加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手段

5.2. BASE64是一种编码技术，可以将二进制数据转换为64个可打印字符，这个转换过程没有密钥参与，因此它不是加密算法

5.3. 字段加密是指在应用层加密后再写入数据库，数据库管理员通过控制台查询，看到的也是密文，因此字段加密的安全性高，可以防DBA（数据库管理员）​

5.4. 静态加密通常是指存储侧自动完成的底层加密，开发人员不用关注底层加密细节，继续按照之前未加密的方式进行读写，应用层看到的是明文，数据库管理员通过控制台查询，看到的也是明文，不能防DBA

5.5. 加密并不是一件只有好处没有坏处的事情

5.6. 敏感个人信息以及涉及个人隐私的数据、UGC（User Generated Content，用户生产内容）数据，需要加密存储

5.7. 口令、加解密密钥、私钥，需要加密存储（其中不需要还原的口令需要使用单向散列算法）​

5.8. 有明确检索、排序、求和等运算需求的业务数据，不需要加密存储

5.9. 同态加密技术

5.10. 添加关键词（Keyword）用于辅助检索，首先根据关键词缩小范围，然后对单个或相关的记录执行解密

5.11. 增加辅助字段，缩小范围

5.12. 应用层字段加密，数据在入库前加密，直接向数据库中写入字段密文

5.13. 存储系统透明加密，或称为静态加密（Encryption at Rest）​，加密仅在存储系统内部自动完成，应用系统还是继续使用明文

5.14. 自管理密钥

5.15. 配合KMS（Key Management System，密钥管理系统）​

5.16. 安全上首选应用层字段加密，并配合KMS来实现

5.17. DEK（Data Encryption Key，数据加密密钥）​，即对数据进行加密的密钥

5.18. KEK（Key Encryption Key，密钥加密密钥）​，即对DEK进行加密的密钥

6. 数据安全传输

6.1. 安全传输，目的就是保障传输过程中的安全性，既要达到保密的效果，也要确定传输的内容完整无误，即没有被篡改

6.2. 使用HTTP但尚未切换到HTTPS的网站，经常会面临网络劫持的问题

6.3. 目前主流的浏览器Chrome已将未启用HTTPS的网站标记为“不安全”​，用户可以直接看到“不安全”字样

6.4. “全站HTTPS”应该成为对外Web应用部署时的标配

6.5. 应用层数据不加密，通道加密：建立一个安全的隧道，然后通过这个隧道传输明文内容

• 6.5.1. HTTPS

6.6. 应用层数据加密，通道不加密：直接在不安全的网络上，传输加密的内容

• 6.6.1. AES-GCM

6.7. HTTPS证书

• 6.7.1. DV证书

• 6.7.1.1. 域名验证型（Domain Vali-dation）证书

• 6.7.1.2. 最便宜甚至可以免费的证书类型，只证明域名有效，证书中不包含组织名称（O字段）​，适用于个人及创业公司

• 6.7.2. OV证书

• 6.7.2.1. 组织验证型（Organization Validation）证书

• 6.7.2.2. 企业型证书，证书中包含组织名称，适用于企业一般场景下使用

• 6.7.3. EV证书

• 6.7.3.1. 扩展验证型（Extended Vali-dation）证书

• 6.7.3.2. 最高信任级证书*，证书中包含组织名称且在访问对应的网站时会在浏览器地址栏出现公司名称

• 6.7.3.3. 审核最严格，当然也就最贵了，适用于在线交易、支付、金融等场景

• 6.7.4. 单域名证书，通过证书的“使用者”字段指定域名

• 6.7.4.1. 单域名证书就是只能用于一个域名

• 6.7.5. 多域名证书，通过证书的“使用者可选名称”列出所有适用的域名

• 6.7.5.1. 单域名证书就是只能用于一个域名

• 6.7.6. 通配型证书

• 6.7.6.1. 通配型证书可用于匹配的全部域名

6.8. TLS质量与合规

• 6.8.1. 禁止使用SSL的全部版本（SSLv1～SSLv3）以及TLS 1.0版本，建议使用TLS 1.2或以上版本

• 6.8.2. 密码算法应只使用前向安全算法（Forward Secrecy, FS）​，这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性

• 6.8.3. 启用HSTS（HTTP Strict Transport Security）​，强制浏览器跳转到HTTPS（通过在https的响应头添加一个字段Strict-Transport-Security: max-age=31536000;includeSub Domains来实现，31536000表示一年的秒数，该数据可变，通常最低设置为6个月的秒数）​

6.9. 前向安全

• 6.9.1. 在长期密钥（或称为主密钥）泄露之后，以后的通信安全无法保证，但不会导致过去的会话密钥（由长期密钥产生的用于加密数据的临时密钥，随时间更新）泄露，或者说能够保护过去的通信不受长期密钥在将来泄露的影响，从而保障了历史通信的安全（被监听到的历史加密数据无法被解密）​

7. 数据展示与脱敏

7.1. 数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护

7.2. 脱敏的标准

• 7.2.1. 在一个组织里面，最好是大家共同约定使用同一套脱敏标准，*避免脱敏标准不一而被恶意利用，拼凑出完整的信息

7.3. 脱敏应尽可能地采用源头脱敏的方式

7.4. 受控，就是让风险在可以接受的范围之内，允许被授权的员工查询，但是在正常业务场景下，需要查询的次数是有限的，且系统会记录查询日志

8. 数据完整性校验

8.1. 单向散列（hash）​，多用于文件下载，用户通过把下载文件的散列值跟网站上公布的散列值进行比对来判断文件是否被篡改

8.2. HMAC，多用于后台消息传递时的完整性校验，但对消息本身没有加密保护

8.3. AES-GCM，在保障身份认证、数据加密的同时，提供完整性保障

8.4. 数字签名（即使用私钥加密）​，由于篡改后会导致无法解密，从而也保障了完整性

9. 业务安全

9.1. 业务安全，是指产品自身业务逻辑的安全性，避免出现由于业务逻辑缺陷导致的业务损失

9.2. 交易支付有关：交易、支付、提现等各环节的安全，如重复支付、重复提现等

9.3. 账号安全有关：付费会员账号盗号、账号分享、恶意批量注册、免费会员变付费会员等

9.4. 运营活动有关：奖品、无门槛优惠券、热门的演唱会门票大部分被黄牛刷走了

9.5. 商品排名相关：刷评论

10. 账号安全

10.1. 防撞库

• 10.1.1. 黑客获取了其中某一个网站泄露的口令库，他可能就会用这个口令库尝试登录其他网站，这就是撞库

• 10.1.2. 防撞库的主要手段是前端慢速加盐散列，以及频率限制、总量限制、IP锁定、验证码等技术手段

10.2. 防弱口令

• 10.2.1. 如果能够在注册时让用户提前规避弱口令是最好的，但由于一些非安全的原因（比如避免用户流失）​，有时不得不接受用户使用弱口令的场景，此时就要非常小心黑客的弱口令攻击了

• 10.2.2. 有必要对来自同一设备的登录次数进行限制，来自同一设备的登录尝试，如果出错达到一定次数，弹出验证码（CAPTCHA）或锁定一定时长

10.3. 防账号数据库泄露

• 10.3.1. 如果没有对账号数据库加以特殊的保护，数据库被拖走，就可能导致全部用户账号泄露

10.4. 防垃圾账号

• 10.4.1. 垃圾账号一般是使用工具软件批量注册的，被黑产用来薅羊毛、刷单、刷好评等，获取不当利益

• 10.4.2. 在账号注册过程中，需要将垃圾账号这个场景考虑进去，借助实名认证、邮件认证、手机认证、验证码等手段，防止批量注册

• 10.4.3. 可以借助专业的风控系统，利用其黑产大数据对账号注册进行把关

10.5. 防账号找回逻辑缺陷

11. B2B交易安全

11.1. 最核心的诉求就是交易安全，包括互不信任、证据链完整、抗抵赖、抗重放等

11.2. 要保障交易安全，首先就需要确保双方的身份无误，这一点通过双方的数字证书来实现

11.3. 电子签名可作为法律认可的身份，这就需要用户侧也有数字证书

11.4. B2B交易也是这样，需要双方都拥有数字证书

12. 产品防攻击能力

12.1. CC（Challenge Collapsar，挑战黑洞）攻击，是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式，该攻击模拟大并发用户量，访问那些需要消耗较多资源的动态页面或数据接口，以达到耗尽目标主机资源的目的

12.2. CC攻击也是DDoS（分布式拒绝服务）的一种

12.3. 降低产品自身对资源的占用，提高服务器性能

12.4. 如果单机性能已达极限，应考虑横向扩展

12.5. 网页静态化与缓存机制

• 12.5.1. 网页尽可能使用静态的网页文件（html、js、css、图片等文件）​，由于静态内容只占用很少的系统资源，这部分内部不会引入攻击（含CC攻击）​

• 12.5.2. 采用SPA（Single Page Application，单页应用）技术及框架（Angular 5/6/7、React、Vue.js等）构建的网站前端，除了会与后端动态交互（使用JSON Restful API接口）之外，基本也算是静态页面

12.6. 消息队列与异步机制

• 12.6.1. 针对消耗资源比较多的功能或接口，可采取分布式异步消息队列等处理机制，相比同步处理可以提高并发能力

• 12.6.2. 在高并发业务场景中，消息队列可用于降低业务模块间的耦合，削峰平谷，提高并发能力

12.7. 负载均衡

• 12.7.1. 在部署时，如果业务能够平行扩展，可在不同的地域部署多台服务器，或使用CDN（Content Delivery Network，内容分发网络）​，进行负载均衡

• 12.7.2. 当Web业务面向全球提供业务时，部署前置Web服务器，并让前置Web服务器经过企业内网访问业务逻辑，也可提升用户体验，更快地响应用户请求