总结



本次课程讲述安全架构和高可用技术。安全的部分的内容基本是银行安全年度培训的一小部分，除了风控是银行中的独立部门被提及外，其他内容都被前两周的测评所涵盖。而高可用涵盖了从设计，SCM，部署和运维的广泛主题。



安全



系统安全



漏洞



OWASP Top10是web安全方面必须关注的重点。Top10中的漏洞都是广泛存在并容易出现的安全问题，非常容易被恶意用户利用造成损失。Top10中，注入曾多年位居榜首，尤其是SQL注入。



1. 注入漏洞，比如SQL，LDAP等，造成非法数据访问。

2. 认证漏洞，登录认证和会话管理方面的漏洞，造成非法用户访问。

3. 敏感数据泄露，数据保护失效，造成用户敏感数据泄露。

4. XML外部实体引用漏洞，有些老版本的XML解析器没有正确处理外部实体引用，造成非法文件访问，端口扫描，远程代码执行和DoS攻击等。

5. 访问控制漏洞，造成越权访问。

6. 安全配置错误，操作系统，框架，库和应用相关的安全配置错误，如HTTP header，安全补丁等，造成非法访问。

7. XSS，跨站脚本，分客户端XSS和服务器端XSS，是内容中包含未转义的恶意脚本，造成对用户数据和服务器的攻击。

8. 不安全的反序列化，造成远程代码执行，注入攻击和越权访问等安全问题。

9. 使用已知的不安全组件，通过公开的已知不安全组件，可以轻易对系统造成攻击。

10. 日志记录和监控不足，对日志和监控数据包含不足，使其可能被利用而攻击系统。



加密和密钥安全



信息加密



敏感数据要加密，按方法分为三类，单向散列加密，对称加密和非对称加密。



单向散列加密，比如MD5，SHA等。此类算法不能通过逆运算获取原文，所以适用于保护密码等系统不需要保存和使用原明文的场景。使用此类算法的假设是不同的原明文对应不用的散列值，通过比较散列值就可以确定是否是原文。但是，MD5，SHA1已不在是安全的散列算法，因为已经可以在普通机器上，合理的时间内找到碰撞因子，即不同的原文得到相同的散列值。所以，不能使用MD5/SHA1来转换并保存密码，应该使用SHA2，1024位以上的算法。



加密时，输入为原文和密钥，输出密文。解密时，输入时密文和密钥，输出是原文。当加密解密的密钥相同时，就是对称加密，不同则是非对称加密。常用的AES算法族是对称加密，PKI的证书体系使用非对称加密，如RSA。非对称加密中的密钥称为公钥和私钥，分别用于加密和解密。不同的场景下，可以是公钥写，私钥读，如HTTPS；也可以是公钥读，私钥写，如证书签名。



密钥管理



密钥管理方面要考虑安全存储，轮转和分割。第一，密钥要存储在安全的介质上。有硬件级密钥存储，也有软件的安全Vault。保证密钥的安全，不能被外界访问获取。第二，密钥在使用上要有有效期并定期轮转，即使泄露也只能在一段时间里使用。第三，密钥要分割管理，没有人能获取全部密钥，完整密钥只在使用时，瞬时存在于内存中。



信息安全



系统安全是基础技术手段，还要防止通过合法的途径在系统中产生非法数据。



垃圾过滤



垃圾信息对系统是有害的，能引起系统过载和公共关系问题，甚至摧毁一个公司。垃圾邮件，广告是最常见的垃圾信息。初级成熟的过滤算法是朴素贝叶斯分类，然后有SVM分类和K-means聚类等算发，现在有NLP和深度学习的分类算法。



风控



交易系统很重要的一个安全问题是风控管理，即识别非法交易，比如洗钱，盗刷，刷单等。风控也已从基于规则，发展至特征工程下的机器学习算法和基于数据的深度学习算法阶段。



高可用



可用性指标



可用性指标通常用几个9表示，意思是可用时间占一年中的比例包含多少个9。两个9就是99%的时间可用，也就是一年中宕机时间少于88个小时，算是基本可用。三个9就是99.9%可用，是高可用系统，一年中的宕机时间小于9小时。以此类推，四个9是自恢复的高可用，宕机时间小于53分钟，五个9是极高可用，宕机时间小于5分钟。



高可用系统工程



保证系统的高可用是一个系统工程，不是某个环节能完全保证的。组织，流程，技术相互配合才能实现高可用系统，任何环节的差错，都能降低可用性。



故障处理流程



1. 报告故障

2. 召集故障处理会议

3. 各部门开始处理，在线沟通

4. 故障处理完毕

5. 事后分析，报告归档



故障原因



• 硬件故障：各种硬件故障，比如常见的磁盘故障，还有cpu，内存，风扇，电源和网络设备故障等。SRE要做好设备更换和扩容计划，电力，通信线路的备份保障。

• 软件bug：bug常在！从BIOS到OS，到系统软件，再到编译器，平台，库和应用，都可能包含bug，并被触发。除了经常更新软件，打补丁，多备份，采用hot-cold，hot-warm，hot-hot等部署方式，对应用开发更是要重视全流程QA，减少bug。

• 系统发布：发布要减少人工操作，使用可靠性高的发布工具。发布可以频繁，但是发布的变更要小，必须经过测试再发布！对不可回滚的变更要单独发布，不要一次做大量变更。发布过程要采用灰度发布，减少变更对系统的压力。

• 并发压力：系统过载而失去响应。高并发，高负载容易造成系统过载。系统个模块对资源的需求不同，有的需要CPU，有的需要内存，有的需要磁盘和网络访问，当系统内划分不合理，大量瓶颈就会降低整个系统性能，容易达到过载阈值。

• 网络攻击：OWASP TOP10中的每个漏洞都可能造成宕机或数据损坏。

• 外部灾害：火灾，恐袭，地震，洪水，市政施工，停电，雷击等各种外部灾害。



高可用设计



• 解耦：目标是构建高内聚，低耦合的组件。应用面向对象设计和领域驱动设计建模达成合理划分，使得错误不会扩散，造成全系统不可用

• 隔离：解耦后就要隔离组件。从业务隔离，到微服务，到生产者于消费者的隔离，再到虚拟机与容器的隔离

• 异步：异步可以达成生产者与消费者的隔离，任何一方的失效都不影响系统的整体可用性

• 冗余与失效转移：数据/组件冗余是高可用的主要手段，组件失效时，要可以平滑迁移

• 重试与幂等：重试是自恢复的有效手段，但是需要有操作的幂等支持

• 限流/熔断/降级：面向恢复的设计。限流可以保护系统不受高并发的冲击。熔断可以主动一定时间内拒绝服务，为系统提供恢复窗口。降级可以关停非核心功能，为核心功能分配更多资源。次三项简单说就是开源节流策略。从资源的角度，限流和熔断是节流，降级是开源。

• 异地多活：机房级的冗余。造价高，但是甚至可以不关心组件的冗余设计。除多活外，还有hot-cold和hot-warm，但是对大规模服务器集群，考虑成本效益，还是最好是hot-hot。



高可用运维



1. 代码分支管理：release branch的创建时机可以是一个版本的开始，也可以是版本code froze时cut off。高可用需要干净，可追溯的release branch。最好做到branch和commit的修改原子性。

2. 测试：单元测试和自动化回归测试

3. CICD：持续集成和持续部署。每个commit都要可以同CI的构建和UT。master/develop上每个commit都可以形成一个能通过测试的版本

4. 自动化测试：减少手工一次性测试，在CICD pipeline中运行自动化测试

5. 灰度发布：蓝绿发布或是金丝雀发布，避免一次性大规模变更。变更后要持续监控一段时间再关闭发布窗口。

6. 运行监控：收集服务器性能数据，应用业务数据，用户行为数据以便及早发现异常，做出告警并采取行动，避免用户可感知的不可用或减少不可用时间。



作业



作业1



详见高可用系统工程一节