读数据安全架构设计与实践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 Protection4.2. 保护资产全生命周期的安全性4.3. 资产包括数据与资源两大类其中对数据的保护是资产保护的重中之重4.4. 不再局限于数据的安全存储而是包括数据的生成、使用、流转、传输、存储在内的全生命周期的安全管控以数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪为目标5. 数据安全存储5.1. 加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手段5.2. BASE64是一种编码技术可以将二进制数据转换为64个可打印字符这个转换过程没有密钥参与因此它不是加密算法5.3. 字段加密是指在应用层加密后再写入数据库数据库管理员通过控制台查询看到的也是密文因此字段加密的安全性高可以防DBA数据库管理员5.4. 静态加密通常是指存储侧自动完成的底层加密开发人员不用关注底层加密细节继续按照之前未加密的方式进行读写应用层看到的是明文数据库管理员通过控制台查询看到的也是明文不能防DBA5.5. 加密并不是一件只有好处没有坏处的事情5.6. 敏感个人信息以及涉及个人隐私的数据、UGCUser Generated Content用户生产内容数据需要加密存储5.7. 口令、加解密密钥、私钥需要加密存储其中不需要还原的口令需要使用单向散列算法5.8. 有明确检索、排序、求和等运算需求的业务数据不需要加密存储5.9. 同态加密技术5.10. 添加关键词Keyword用于辅助检索首先根据关键词缩小范围然后对单个或相关的记录执行解密5.11. 增加辅助字段缩小范围5.12. 应用层字段加密数据在入库前加密直接向数据库中写入字段密文5.13. 存储系统透明加密或称为静态加密Encryption at Rest加密仅在存储系统内部自动完成应用系统还是继续使用明文5.14. 自管理密钥5.15. 配合KMSKey Management System密钥管理系统5.16. 安全上首选应用层字段加密并配合KMS来实现5.17. DEKData Encryption Key数据加密密钥即对数据进行加密的密钥5.18. KEKKey Encryption Key密钥加密密钥即对DEK进行加密的密钥6. 数据安全传输6.1. 安全传输目的就是保障传输过程中的安全性既要达到保密的效果也要确定传输的内容完整无误即没有被篡改6.2. 使用HTTP但尚未切换到HTTPS的网站经常会面临网络劫持的问题6.3. 目前主流的浏览器Chrome已将未启用HTTPS的网站标记为“不安全”用户可以直接看到“不安全”字样6.4. “全站HTTPS”应该成为对外Web应用部署时的标配6.5. 应用层数据不加密通道加密建立一个安全的隧道然后通过这个隧道传输明文内容6.5.1. HTTPS6.6. 应用层数据加密通道不加密直接在不安全的网络上传输加密的内容6.6.1. AES-GCM6.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的全部版本SSLv1SSLv3以及TLS 1.0版本建议使用TLS 1.2或以上版本6.8.2. 密码算法应只使用前向安全算法Forward Secrecy, FS这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性6.8.3. 启用HSTSHTTP Strict Transport Security强制浏览器跳转到HTTPS通过在https的响应头添加一个字段Strict-Transport-Security: max-age31536000;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. CCChallenge Collapsar挑战黑洞攻击是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式该攻击模拟大并发用户量访问那些需要消耗较多资源的动态页面或数据接口以达到耗尽目标主机资源的目的12.2. CC攻击也是DDoS分布式拒绝服务的一种12.3. 降低产品自身对资源的占用提高服务器性能12.4. 如果单机性能已达极限应考虑横向扩展12.5. 网页静态化与缓存机制12.5.1. 网页尽可能使用静态的网页文件html、js、css、图片等文件由于静态内容只占用很少的系统资源这部分内部不会引入攻击含CC攻击12.5.2. 采用SPASingle 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. 在部署时如果业务能够平行扩展可在不同的地域部署多台服务器或使用CDNContent Delivery Network内容分发网络进行负载均衡12.7.2. 当Web业务面向全球提供业务时部署前置Web服务器并让前置Web服务器经过企业内网访问业务逻辑也可提升用户体验更快地响应用户请求