Google系统架构（构建安全可靠的系统）

\hGoogle系统架构解密构建安全可靠的系统目录\h第一部分入门资料\h第1章安全性与可靠性的交集\h1.1从密码和电钻谈起\h1.2可靠性与安全性：设计注意事项\h1.3机密性、完整性、可用性\h1.3.1机密性\h1.3.2完整性\h1.3.3可用性\h1.4可靠性与安全性：共性\h1.4.1隐形\h1.4.2评估\h1.4.3简洁性\h1.4.4演变\h1.4.5弹性\h1.4.6从设计到生产\h1.4.7调查系统和日志\h1.4.8危机响应\h1.4.9恢复\h1.5小结\h第2章了解攻击者\h2.1攻击者动机\h2.2攻击者画像\h2.2.1业余爱好者\h2.2.2漏洞研究人员\h2.2.3黑客活动家\h2.2.4犯罪分子\h2.2.5自动化和人工智能\h2.2.6内部人员\h2.3攻击者方法论\h2.3.1威胁情报\h2.3.2网络杀伤链\h2.3.3TTP\h2.4风险评估注意事项\h2.5小结\h第二部分设计系统\h第3章示例分析：安全代理\h3.1生产环境中的安全代理\h3.2Google工具代理\h3.3小结\h第4章设计中的权衡\h4.1设计目标和要求\h4.1.1特性需求\h4.1.2非功能性需求\h4.1.3功能与涌现特性\h4.1.4案例：Google的设计文档\h4.2需求平衡\h案例：支付系统\h4.3处理紧张局势和统一目标\h4.3.1案例：微服务和GoogleWeb应用程序框架\h4.3.2统一涌现特性的需求\h4.4初始速度和持续速度\h4.5小结\h第5章最小特权设计\h5.1概念和术语\h5.1.1最小特权\h5.1.2零信任网络\h5.1.3零接触\h5.2基于风险的访问分类\h5.3最佳实践\h5.3.1API功能最小化\h5.3.2Breakglass机制\h5.3.3审计\h5.3.4测试和最小特权\h5.3.5诊断被拒绝的访问\h5.3.6优雅失败和Breakglass机制\h5.4工作案例：配置分发\h5.4.1基于OpenSSH实现的POSIXAPI\h5.4.2软件更新API\h5.4.3自定义OpenSSHForceCommand\h5.4.4自定义HTTP接收器（边车）\h5.4.5自定义HTTP接收器（内置）\h5.4.6权衡取舍\h5.5一种用于认证和授权决策的策略框架\h5.5.1使用高级授权控件\h5.5.2投入广泛使用的授权框架\h5.5.3避免潜在的陷阱\h5.6高级控制\h5.6.1MPA\h5.6.23FA\h5.6.3业务依据\h5.6.4临时访问\h5.6.5代理\h5.7权衡和冲突\h5.7.1增加了安全复杂性\h5.7.2对合作商及公司文化的影响\h5.7.3影响安全性的质量数据和系统\h5.7.4对用户工作效率的影响\h5.7.5对开发复杂性的影响\h5.8小结\h第6章面向易理解性的设计\h6.1为什么易理解性很重要\h6.1.1系统不变量\h6.1.2分析不变量\h6.1.3心智模型\h6.2设计易理解的系统\h6.2.1复杂性与易理解性\h6.2.2分解复杂性\h6.2.3集中负责安全性和可靠性需求\h6.3系统架构\h6.3.1易于理解的接口规范\h6.3.2易于理解的身份、认证和访问控制\h6.3.3安全边界\h6.4软件设计\h6.4.1使用应用程序框架满足服务需求\h6.4.2理解复杂的数据流\h6.4.3考虑API的可用性\h6.5小结\h第7章适应变化的设计\h7.1安全变更的类型\h7.2变更中的设计\h7.3让发布更容易的架构决策\h7.3.1让依赖项保持最新并频繁重建\h7.3.2用自动化测试让发布更频繁\h7.3.3使用容器\h7.3.4使用微服务\h7.4不同的变更：不同的速度与不同的时间线\h7.4.1短期变更：零日漏洞\h7.4.2中期变更：改善安全态势\h7.4.3长期变更：外部需求\h7.5难点：计划调整\h7.6不断扩大的范围：心脏滴血漏洞\h7.7小结\h第8章弹性设计\h8.1弹性设计原则\h8.2纵深防御\h8.2.1特洛伊木马\h8.2.2GoogleAppEngine分析\h8.3控制降级\h8.3.1区分故障成本\h8.3.2部署响应机制\h8.3.3负责任的自动化\h8.4控制爆炸半径\h8.4.1角色分离\h8.4.2位置分离\h8.4.3时间分离\h8.5故障域和冗余\h8.5.1故障域\h8.5.2组件类型\h8.5.3控制冗余\h8.6持续验证\h8.6.1验证关键区域\h8.6.2验证实践\h8.7实践建议：着手点\h8.8小结\h第9章面向恢复性的设计\h9.1要恢复什么\h9.1.1随机错误\h9.1.2意外错误\h9.1.3软件错误\h9.1.4恶意行为\h9.2恢复机制的设计原则\h9.2.1面向快速恢复的设计（受政策监督）\h9.2.2限制对外部时间观念的依赖\h9.2.3回滚所代表的安全性和可靠性间的权衡\h9.2.4使用显式吊销机制\h9.2.5了解精确到字节的预期状态\h9.2.6面向测试和持续验证的设计\h9.3紧急访问\h9.3.1访问控制\h9.3.2通信\h9.3.3响应人员的习惯\h9.4预期外的收益\h9.5小结\h第10章缓解拒绝服务攻击\h10.1攻守双方的策略\h10.1.1攻方的策略\h10.1.2守方的策略\h10.2面向防御的设计\h10.2.1具有防御能力的架构\h10.2.2使服务具备防护能力\h10.3缓解攻击\h10.3.1监控与告警\h10.3.2优雅降级\h10.3.3DoS防护系统\h10.3.4有策略的响应\h10.4应对源于服务本身的“攻击”\h10.4.1用户行为\h10.4.2客户端重试行为\h10.5小结\h第三部分实现系统\h第11章案例分析：设计、实现和维护一个受信任的公共CA\h11.1受信任的公共CA的背景\h11.2为什么需要受信任的公共CA\h11.3自建还是购买CA\h11.4设计、开发和维护过程中的考虑\h11.4.1选择编程语言\h11.4.2复杂与简明\h11.4.3保护第三方和开源组件\h11.4.4测试\h11.4.5CA密钥材料的弹性\h11.4.6数据验证\h11.5小结\h第12章编写代码\h12.1框架级安全性和可靠性保证措施\h12.1.1使用框架的好处\h12.1.2案例：用于创建RPC后端的框架\h12.2常见安全漏洞\h12.2.1SQL注入漏洞：TrustedSqlString\h12.2.2预防XSS漏洞：SafeHtml\h12.3评估和构建框架的经验\h12.3.1用于常见任务的简单、安全、可靠的库\h12.3.2部署策略\h12.4简洁性有助于提升代码的安全性和可靠性\h12.4.1避免多层嵌套\h12.4.2消除YAGNI类代码\h12.4.3偿还技术债务\h12.4.4重构\h12.5默认安全性和可靠性\h12.5.1选择合适的工具\h12.5.2使用强类型\h12.5.3检查代码\h12.6小结\h第13章代码测试\h13.1单元测试\h13.1.1编写有效的单元测试\h13.1.2编写单元测试的时机\h13.1.3单元测试对代码的影响\h13.2集成测试\h编写有效的集成测试\h13.3动态程序分析\h13.4模糊测试\h13.4.1模糊引擎的工作原理\h13.4.2编写有效的模糊测试驱动程序\h13.4.3示例fuzzer\h13.4.4持续模糊测试\h13.5静态程序分析\h13.5.1自动代码检查工具\h13.5.2如何将静态分析集成至开发工作流中\h13.5.3抽象解释\h13.5.4形式化方法\h13.6小结\h第14章部署代码\h14.1概念和术语\h14.2威胁建模\h14.3最佳实践\h14.3.1强制做代码审查\h14.3.2依赖自动化\h14.3.3验证工件，而不仅仅是人\h14.3.4将配置视为代码\h14.4基于威胁建模做安全加固\h14.5高级缓解策略\h14.5.1二进制文件来源\h14.5.2基于来源的部署策略\h14.5.3可验证的构建\h14.5.4部署阻塞点\h14.5.5部署后验证\h14.6实用建议\h14.6.1一步步来\h14.6.2提供可操作的错误消息\h14.6.3确保来源信息明确\h14.6.4创建明确的策略\h14.6.5引入Breakglass机制\h14.7重温基于威胁建模部署安全措施\h14.8小结\h第15章调查系统\h15.1从调试到调查\h15.1.1案例：临时文件\h15.1.2调试技巧\h15.1.3当陷入困境时该怎么办\h15.1.4协同调试：一种教学方法\h15.1.5安全调查与系统调试间的差异\h15.2收集恰当、有用的日志\h15.2.1将日志设计为不可变的\h15.2.2考虑隐私要素\h15.2.3确定要保留哪些安全相关的日志\h15.2.4日志记录成本\h15.3可靠、安全的调试访问\h15.3.1可靠性\h15.3.2安全性\h15.4小结\h第四部分维护系统\h第16章防灾规划\h16.1“灾难”的定义\h16.2动态灾难响应策略\h16.3灾难风险分析\h16.4建立事件响应团队\h16.4.1确定团队成员和角色\h16.4.2制订团队章程\h16.4.3建立严重性和优先级模型\h16.4.4确定与IR团队合作的运营参数\h16.4.5制订响应计划\h16.4.6创建详细的行动手册\h16.4.7确保访问和更新机制就位\h16.5在事件发生前预先安排系统和人员\h16.5.1配置系统\h16.5.2培训\h16.5.3流程和程序\h16.6测试系统和响应计划\h16.6.1审计自动化系统\h16.6.2开展非侵入式桌面演练\h16.6.3在生产环境中测试响应\h16.6.4红队测试\h16.6.5评估响应\h16.7Google的案例\h16.7.1具有全球影响的测试\h16.7.2DiRT演习测试紧急访问\h16.7.3行业级漏洞\h16.8小结\h第17章危机管理\h17.1是否存在危机\h17.1.1事件分诊\h17.1.2入侵与缺陷\h17.2指挥事件\h17.2.1第一步：不要惊慌\h17.2.2开展响应\h17.2.3组建自己的事件团队\h17.2.4OpSec\h17.2.5牺牲好的OpSec实践换取更大的利益\h17.2.6调查过程\h17.3控制事件\h17.3.1并行处理事件\h17.3.2移交\h17.3.3士气\h17.4沟通\h17.4.1误解\h17.4.2拐弯抹角\h17.4.3会议\h17.4.4让合适的人了解合适的细节\h17.5整合回顾\h17.5.1分诊\h17.5.2宣布事件\h17.5.3沟通和OpSec\h17.5.4开始处理事件\h17.5.5移交\h17.5.6交还事件调查工作\h17.5.7准备沟通和补救\h17.5.8结束\h17.6小结\h第18章恢复和善后\h18.1恢复调度\h18.2恢复时间线\h18.3恢复计划\h18.3.1确定恢复范围\h18.3.2恢复过程的考虑因素\h18.3.3恢复检查清单\h18.4启动恢复\h18.4.1隔离资产\h18.4.2系统恢复和软件升级\h18.4.3数据过滤\h18.4.4恢复数据\h18.4.5更换凭据和密钥\h18.6恢复之后\h复盘\h18.7示例\h18.7.1被入侵的云实例\h18.7.2大规模钓鱼攻击\h18.7.3需要复杂恢复工作的、有针对性的攻击\h18.8小结\h第五部分组织与文化\h第19章案例研究：Chrome安全团队\h19.1背景和团队发展史\h19.2安全是团队的职责\h19.3帮助用户安全地浏览Web页面\h19.4速度很重要\h19.5设计纵深防御机制\h19.6保持透明，让社区参与进来\h19.7小结\h第20章理解角色和责任\h20.1谁为安全性和可靠性负责\h20.1.1专家的作用\h20.1.2了解安全专业知识\h20.1.3资格认证和学术教育\h20.2将安全性整合到组织中\h20.2.1嵌入安全人员和安全团队\h20.2.2案例：Google的嵌入式安全\h20.2.3特殊的团队：蓝队和红队\h20.2.4外部研究者\h20.3小结\h第21章建立安全可靠的文化\h21.1定义健康的安全性和可靠性文化\h21.1.1默认的安全性和可靠性文化\h21.1.2评审文化\h21.1.3意识文化\h21.1.4说“是”的文化\h21.1.5接受必然性的文化\h21.1.6可持续发展文化\h21.2通过最佳实践改变文化\h21.2.1对齐项目目标和激励参与者\h21.2.2通过风险规避机制减少恐惧\h21.2.3使安全兜底措施成为常态\h21.2.4提高生产力和可用性\h21.2.5多沟通，保持透明\h21.2.6怀抱同理心\h21.3说服领导层\h21.3.1了解决策过程\h21.3.2为变革立案\h21.3.3选择自己的战场\h21.3.4升级和问题解决\h21.4小结\h总结\h附录灾难风险评估矩阵注：原文档电子版（非扫描），需要的请下载本文档后留言谢谢。第一部分入门资料如果你邀请用户写出其最喜爱的产品特性，他们的清单基本不可能以安全性和可靠性开始。这两个特性通常隐藏在他们的预期中，当产品运行良好时，用户就不会注意到它们。我们相信，安全性和可靠性应该是每个组织的头等大事。归根结底，几乎没有用户想使用一个既不可靠又不安全的产品，因此这些方面提供了差异化的业务价值。本书的第一部分重点介绍对于一个系统来说，安全性和可靠性的基础实践中存在的大量重合项，以及在它们之间需要面临的权衡。我们为你提供了应对潜在对手的高级指导：他们可能的行为及其行为对系统生命周期可能产生的影响。第1章安全性与可靠性的交集撰写人：AdamStubblefield、MassimilianoPoletto、PiotrLewandowski、DavidHuska和BetsyBeyer1.1从密码和电钻谈起2012年9月27日，Google发布的一份内部公告导致了一系列的服务故障。最终，一把电钻排除了这些故障。Google有一个内部密码管理系统，用于员工存储密码，以及与不具备更高级身份验证机制的第三方服务进行机密共享。存储密码之一就是连接Google旧金山湾区各园区的公交车上的访客Wi-Fi密码。在9月27日那天，运输团队通过电子邮件向数千名员工发布了Wi-Fi密码已更改的公告，最终导致流量远远超过了密码管理系统（该密码管理系统是几年前为一小部分系统管理员开发的）所能承受的峰值。过载流量导致密码管理系统的主服务无法响应，因此负载均衡器将流量牵引到备份服务，结果备机也立即过载。此时，系统向值班工程师发出告警，而该工程师没有响应服务失败的经验：密码管理系统有良好的运行基础，并且在其存在的5年中从未遭受过停机。该工程师尝试重新启动服务，但不知道重新启动需要硬件安全模块（HSM）智能卡。这些智能卡存储在全球各地的Google办事处的多个保险箱中，但不在值班工程师所在的纽约市。当服务无法重启时，该工程师联系了澳大利亚的一位同事，想取回智能卡。令人沮丧的是，澳大利亚的工程师无法打开保险箱，因为密码存储在离线的密码管理器中。幸运的是，加利福尼亚的另一位同事将该密码记录在了在线保险箱中，并且能够取回智能卡。但是，即使加利福尼亚的工程师将卡插入读卡器，该服务仍然因密码错误而无法重启：“密码无法加载任何保护此密钥的卡。”澳大利亚的工程师认为应该用蛮力解决他们的安全问题，因此用起了电钻。一小时后，保险箱打开了，但即便是刚取回的卡也触发了相同的错误消息。团队花了一个多小时才意识到，智能卡读取器上的绿灯实际上并不表示该卡已正确插入。当工程师将卡翻转过来时，服务重启成功，故障排除了。可靠性和安全性都是一个真正值得信赖的系统的关键组成部分，但要构建既可靠又安全的系统是很困难的。尽管对可靠性和安全性的要求具有许多共性，但设计它们时也有不同的注意事项。忽视可靠性和安全性之间的微妙关系很容易引起意外的结果。密码管理系统的故障是由可靠性问题（失效的负载均衡和过载保护策略）触发的，而提高系统安全性的多种措施使恢复密码管理系统变得复杂。安全与隐私的交集安全与隐私是密切相关的概念。系统为了尊重用户隐私，必须从根本上是安全的，并且在对手面前表现得与预期相同。同样，一个完善的安全系统如果不尊重用户隐私，就不能满足许多用户的需求。虽然本书关注的是安全性，但描述的一些方法通常也用于实现隐私保护。1.2可靠性与安全性：设计注意事项在设计可靠性和安全性时，必须考虑不同的风险。可靠性面对的主要风险往往是非恶意的，例如软件更新失败或物理设备故障，而安全风险来自主动尝试利用系统漏洞的对手。在设计可靠性时，你会假设某些地方在某些时候会出错；在设计安全性时，你必须假设有人随时随地蓄意搞破坏。因此，不同的系统在故障响应的设计上也完全不同。在没有破坏者的情况下，系统通常会在故障发生时默认放过（或默认打开），例如电子锁默认在断电时保持打开状态，允许人们安全进出。在故障发生时默认放过/打开的设计可能导致明显的安全漏洞。为了防御可能利用电源故障的人，可以将门设计为在故障发生时默认保护，并在不通电时保持关闭状态。可靠性与安全性的权衡：冗余在设计可靠性时，通常需要向系统添加冗余。举例来说，许多电子锁在断电时会默认保护，但会允许使用物理钥匙。同样，火灾逃生通道为紧急情况提供了冗余的出口。尽管冗余提高了可靠性，但也增加了攻击面。对抗方只需在一条路径上找到漏洞即可成功。可靠性与安全性的权衡：事件管理攻击者的存在还会影响协作方法以及事件发生时响应者可以使用的信息。可靠性受益于拥有多角度的响应者，它们可以协助快速发现问题的根本原因并解决问题。相比之下，通常在处理安全事件时更希望将解决问题的人员最少化，使对手无法获得相关消息。在安全事件中，以按需共享的原则来分享信息。同样，海量的系统日志有助于为事件响应提供信息支撑，并缩短恢复所需事件的时间，但根据记录的内容不同，日志也可能成为攻击者的重要目标。1.3机密性、完整性、可用性安全性和可靠性都与系统的机密性、完整性和可用性有关，但它们针对这些因素的考虑角度不同。两者之间的关键差异在于是否存在恶意的对手。可靠的系统一定不会出现违背机密性的问题，例如出错的聊天系统可能存在错发、乱码或丢失消息的情况。此外，安全的系统必须防止恶意访问、篡改或破坏机密数据。通过下面的例子来看看可靠性问题是如何导致安全问题的。在传统定义中，机密性、完整性和可用性一直被视为安全系统的基本属性，叫作CIA1三要素。尽管很多模型基于CIA扩展了安全属性，但CIA三要素长期以来仍受欢迎。虽然首字母缩写一样，但这个概念与美国中央情报局没有任何关系。1此处的CIA是指confidentiality（机密性）、integrity（完整性）和availability（可用性）。——编者注1.3.1机密性在航空业中，一个明显的机密性问题是一键通按钮卡在了发声位置。在一些有据可查的案例中，卡住的麦克风按钮广播了飞行员之间的私人对话，这明显违反了机密性。在这种情况下，并不存在恶意攻击者，而是硬件可靠性缺陷导致设备在非飞行员预期的情况下传递了信息。1.3.2完整性同样，数据完整性被破坏也不一定涉及攻击者。2015年，Google网站可靠性工程师注意到，端到端加密的完整性检查在一些数据块上出现了失败的情况。处理数据的某些机器存在无法纠正的内存错误，因此网站可靠性工程师决定改写程序，通过按位取反（0和1互换）操作彻底检查计算每个数据版本的完整性。这样一来，他们才能知道结果是否与原始完整性检查的值相匹配。事实证明，所有错误实际上都是按位取反导致的，后续网站可靠性工程师恢复了所有数据。有趣的是，这是一个在完整性故障中采用安全技术来恢复的实际案例。（Google的存储系统使用的是非加密的端到端完整性检查，但因为一些其他因素，SRE团队没有发现按位取反的故障。）1.3.3可用性最后一点，可用性显然既关乎可靠性，又关乎安全性。攻击者可能会利用系统漏洞，使系统停止运行或阻止已授权用户的使用。或者，攻击者可能会控制分布在世界各地的大量设备来发动经典的分布式拒绝服务（distributeddenial-of-service,DDoS）攻击，利用这些设备向受害者发送大量请求。拒绝服务（denial-of-service,DoS）攻击很有趣，这是因为它横跨可靠性领域和安全性领域。从受害人的视角来看，很难区分恶意攻击流量与设计缺陷或合理上升带来的峰值流量。举个例子，2018年的一次软件更新导致一些GoogleHome设备和Chromecast设备在调整时钟时产生了巨大的网络流量，进而导致Google的中央时间服务出现了非预期的流量峰值。与之类似，重大的突发新闻或事件会使得数百万人发出几乎相同的查询，这看起来很像传统的应用级DDoS攻击。如图1-1所示，2019年10月的一个深夜，旧金山湾区发生了4.5级地震，该地区的Google基础设施服务接收到大量查询流量。图1-1：2019年10月14日，旧金山湾区发生4.5级地震时，该地的Google基础设施服务接收到的Web流量（以每秒HTTP请求量计算）1.4可靠性与安全性：共性与许多系统特性不同，可靠性和安全性是系统设计中的突出属性。这两点都很难在事后再加固，因此理想情况下，在设计的初期阶段就应该将两者都考虑在内。系统变更过程中很容易无意中影响到这两点，因此需要在整个系统生命周期中持续关注和测试它们。在复杂的系统中，很多组件会影响到安全性和可靠性，一个看似不经意的更新可能对整个系统的安全性或可靠性造成影响，而这种影响在事故发生前可能并不明显。让我们通过更多细节来研究这些共同点。1.4.1隐形当系统运行一切正常时，可靠性和安全性几乎是隐形的，但可靠性和安全性团队的目标之一是赢得并保持客户和合作伙伴的信任。无论是出现问题时，还是在进展顺利的情况下，良好的沟通都是这种信任的坚实基础。沟通中应该开诚布公、细致入微，并且避免套话和行话，这非常重要。不幸的是，在没有紧急情况的时候，可靠性和安全性的隐形意味着它们通常被视为可以减少或推迟也不会立即造成严重后果的成本，但它们失效时带来的损失可能很严重。据媒体报道，可能因为数据泄露事件的出现，2017年威瑞森收购雅虎的互联网业务的价格降低了3.5亿美元。同一年，断电事件导致达美航空的核心系统停机，造成近700架航班取消和数千次的航班延误，使达美当天的航班吞吐量减少了将近60％。1.4.2评估因为实现绝对可靠性或安全性的想法是不切实际的，所以可以从实际风险出发来评估负面事件带来的成本，以及预防这些事件的前期成本和机会成本。但是，对于可靠性和安全性，应该以不同的方式衡量负面事件的可能性。我们可以推导出系统组成的可靠性，并根据所需的错误预算2来计划工程工作。其中至少一部分可以这样，因为我们可以假设各个组件之间的故障是无关的。而组合的安全性就更难评估了。通过分析系统的设计和实现，可以提供一定程度的保证。攻防演练（以攻击者的角度开展测试）也可以用于评估系统对特定攻击类型的抵抗力、攻击检测机制的有效性以及受到攻击的潜在后果。2有关错误预算的更多信息，请参阅《SRE：Google运维解密》中的第3章。1.4.3简洁性使系统设计尽可能精简，是提高对系统可靠性和安全性的评估能力的最佳方法之一。较简单的设计缩小了攻击面，减少了系统非预期交互的可能性，并使系统更容易被理解。在紧急情况下，可理解性尤其有用，它可以帮助响应者快速解决问题并减少平均修复时间（MTTR）。第6章将详细阐释该主题，并讨论相关策略，例如将攻击面最小化，以及将安全不变量的权责划分到简单的、独立运行的子系统中，以便于独立地推理。1.4.4演变无论初始设计多么简洁和优雅，系统极少情况下会保持长久不变。添加新功能、改变规模以及底层基础设施的演进都会让系统变得复杂。在安全方面，跟进不断发展的攻击手法和新攻击者的需求也会使系统变得复杂。此外，满足市场需求的压力也会导致系统开发人员和维护人员走捷径，从而积攒技术债务。第7章讨论了其中一些挑战。复杂性通常会在不经意间积累起来，这可能会导致系统到达临界点。在这种情况下，一个看起来无关紧要的微小变更就会对系统的可靠性或安全性产生重大影响。DebianGNU/Linux版本的OpenSSL库就出现过一个因微小变更而导致重大故障的案例：2006年引入的一个错误，在将近两年后才被发现。一位开源研发人员注意到Valgrind（一款调试内存问题的标准工具）报告了一个问题：内存使用前未进行初始化。为了消除警告，研发人员删除了两行代码。不幸的是，这导致OpenSSL的伪随机数生成器只使用进程ID作为随机种子，而在Debian系统中，该ID当时默认在1~32768范围内取值，因此可以很轻易地通过暴力破解获取加密密钥。Google也同样无法幸免。例如，2018年10月，YouTube在全球范围内停机了超过一小时，起因是通用日志库里的一个小变更。该变更的目的是提升事件日志的细粒度，在其作者和指定的代码审阅者看来都没有问题，并且通过了所有测试。然而，其开发者完全没有意识到在YouTube的业务规模下会产生的影响：在生产环境的负载下，这个变更导致YouTube的服务器快速地耗尽内存并崩溃。当用户的流量转移到其他正常的服务器时，级联故障导致整个服务都停止了。1.4.5弹性当然，一个内存利用率问题不应该引起全局的服务中断。系统应在非预期情况下具有弹性。从可靠性角度来看，这种情况通常是因预期外的高负载或者组件故障而导致的。负载是系统请求数量和平均开销组合而成的，因此可以通过减少负载量（减少执行）或者减少每个请求的平均开销（执行成本更低）来实现弹性。为了定位组件故障，系统设计应该包括冗余和不同的故障域，以便通过重新路由请求来限制降低故障的影响。第8章将进一步讨论这些话题，第10章将特别深入探讨DoS缓解措施。无论一个系统的各个组件具有多大的弹性，一旦变得足够复杂，就难以保证整个系统不受伤害，但可以通过纵深防御和故障域来解决这个问题。纵深防御是多种防御机制的集合（有时候是冗余）。独立故障域限制了故障的“爆炸半径”，因此也提高了可靠性。良好的系统设计会限制攻击者利用沦陷的主机或者盗取的凭证进行横向移动或是提权，进而影响系统的其他部分。你可以通过划分权限或者限制凭证的可用范围来实现不同的故障域。举个例子，Google内部基础设施所支持的凭证明确地限定了地理区域。这类特性可以限制攻击者向其他区域服务器横向移动的能力（如果已经掌控了一个区域的服务器）。对敏感数据使用独立的加密层是深度防御的另一种常见机制。举个例子，即使磁盘提供了设备级加密，在应用程序层也加密数据通常是个好主意。这样，假设攻击者获取通过物理方式访问存储设备的方法，即使驱动控制器中的加密算法实现有缺陷，也不足以危及受保护数据的机密性。虽然目前为止引用的例子都来自外部攻击者，但内部恶意人员的潜在威胁也是需要考虑的。尽管内部人员可能比第一次窃取员工凭证的外部攻击者更了解潜在的突破点，但在实践中这两种情况通常没有太大区别。最小特权原则可以缓解内部的威胁。它规定用户只能在指定时间范围内拥有工作所需的最小权限集。举个例子，UNIX的sudo机制支持细粒度的策略，用以指定哪些用户可以作为什么角色来运行哪些命令。在Google，我们还使用多方授权来确保敏感操作由特定的员工组来审批。这种多方机制既能防御内部恶意人员，又能降低人为错误的风险（可靠性故障的常见原因）。最小特权和多方授权不是新鲜事物，它们已经为很多非计算机的场景所应用，大到核导弹发射井，小到银行金库。第5章将深入讨论这些概念。1.4.6从设计到生产将一个可靠设计转化为完整部署的生产系统的过程中，要一直考虑安全性和可靠性。从代码开发开始，就有机会通过代码审阅来发现潜在的安全性和可靠性问题，甚至可以通过使用公共框架和库来防止产生问题。第12章探讨了这方面的技术。在部署系统之前，可以用测试来确保它的功能在正常情况下和边缘情况（通常会影响可靠性和安全性）下都能正常工作。无论是使用负载测试来了解系统在大量查询下的行为，或是使用模糊测试来探索潜在的非预期输入后的表现，抑或使用特定的测试来确认加密库是否会泄露信息，测试都在其中发挥着关键作用，以确保实际构建的系统符合设计意图。第13章深入介绍了这些方法。最后，一些实际部署代码的方法（参见第14章）可以控制安全性和可靠性的风险。例如，金丝雀测试和缓慢部署可以防止系统崩溃并波及所有用户。同样，如果部署系统只接受经过合理审阅的代码，则将有助于降低内部人员将恶意二进制文件发布至生产环境的风险。1.4.7调查系统和日志到目前为止，我们都将重点放在了防止可靠性和安全故障的设计原则和实现方法上。不幸的是，想要达到完美的可靠性和安全性，成本通常很高，因此不切实际。我们必须假设预防机制有失败的可能，因此需要制订计划来检测故障并从故障中恢复。将如第15章所述，完善的日志记录是检测和防备故障的基础。一般来说，日志越完整详细就越好，但这个准则有些注意事项。在足够大的规模下，大量日志会带来很大的成本，并且会给分析日志造成困难。前文中提到的YouTube案例说明日志也会导致可靠性问题。安全日志还带来了额外的挑战：日志通常不应该包含认证凭证或个人身份信息（personallyidentifiableinformation,PII）等敏感信息，以免日志本身成为使攻击者感兴趣的目标。1.4.8危机响应在紧急情况下，团队必须快速而顺利地协作，否则可能立即出现不良后果。在最坏的情况下，一个事件可能在几分钟内毁掉一家企业。例如，2014年，一名攻击者接管了代码托管服务CodeSpaces的管理端工具，然后删除了该服务的所有数据，包括所有备份，导致该服务在几小时内完全不可用。这些情况下都需要及时响应，而精心排练过的协作和良好的事件管理就显得尤为重要了。组织危机响应非常有挑战性，所以最好是在紧急情况发生之前就制订好响应计划。发现事件是需要时间的。在任何情况下，响应人员都是在压力和时间紧迫的情况下操作的，并且（至少在刚开始时）对情况的认知有限。如果组织规模较大，同时事件需要24小时响应或者跨时区协作、跨团队维护和班次间事件管理交接，就会导致操作进一步的复杂化。安全事件通常会存在矛盾：一方面想让各个关键方都参与进来；另一方面，通常法律和监管要求限制信息只能在必要知晓时才能共享。而且，最初的安全事件可能只是冰山一角。调查可能超出公司范围，或者涉及执法机构。在危机期间，至关重要的是一个清晰的指挥链以及一套坚实的检查清单、行动手册和协议。将如第16章和第17章所述，Google已经将危机响应转化成名为“Google事件管理”（IncidentManagementatGoogle,IMAG）的程序，包含处理各类事件的标准化方法（无论是系统中断，还是自然灾害），并组织有效的响应。IMAG是基于美国突发事件指挥系统（IncidentCommandSystem,ICS）模型建立的，这是一种用于指挥、控制和协调多个政府机构的应急人员的标准化方法。当没有面临持续事件的压力时，应急人员通常会有大段的空白时间，没有行动。在这些时间段里，团队需要保持个人技能和行动的敏锐性，并改进流程和基础设施，为下一次的应急做准备。Google的灾难恢复测试系统（DisasterRecoveryTestingprogram,DiRT）会定期模拟各种内部系统故障，迫使团队去应付这些场景。频繁地攻击性安全演习能测试防御能力，并有助于识别新的漏洞。Google甚至在小事件中也使用IMAG，这进一步促使我们定期使用应急工具和流程。1.4.9恢复从安全事故中恢复，通常需要为了修复漏洞而打补丁。直觉上，你希望使用非常可靠、经常运行的机制让该过程尽快流转。然而，快速推送变更的能力是一把双刃剑：虽然此功能可以帮助快速关闭漏洞，但它也可能引入错误或性能问题，从而造成大量破坏。如果漏洞广为人知或风险严重，则快速推送补丁的压力更大。推动修复程序的节奏究竟是快还是慢（缓慢推进时确保无副作用，但漏洞就存在被利用的风险），最终归结为风险评估和业务决策。例如，通过降低某些性能或增加资源使用量来修复严重漏洞或许是可以接受的。这样的选择强调了需要可靠的恢复机制，使我们能够在不影响可靠性的情况下快速推出必要的变更，并且还可以在潜在问题导致大范围故障之前发现这些问题。例如，稳健的舰队恢复系统需要可靠地表示每台机器的当前和所需状态，还需要提供备份，以确保状态永远不会回滚到过时或不安全的版本。第9章将介绍该方法及同类方案，第18章将讨论在事件发生后如何实际恢复系统。1.5小结安全性和可靠性有很多共同之处——它们都是所有信息系统的固有属性，最初很容易成为换取更快速度的代价，而事后则需要高昂的修复成本。本书旨在帮助你在系统增长过程中，尽早解决与安全性和可靠性相关的不可避免的挑战。除了工程方面的努力，每个组织都必须了解有助于构建安全性和可靠性文化（参见第21章）的角色和责任（参见第20章），以便坚持可持续的实践。通过分享我们的经验和教训，我们希望你能够在系统生命周期的早期充分地采用这些原则，从而避免在以后的道路上付出更大的代价。我们写这本书时考虑到了广大读者，目标是无论项目处于什么阶段或范围，读者都会发现它是相关的。阅读本书时，请牢记项目的风险概况，这是因为运营股票交易所或政见交流平台的风险与运营动物保护区网站的风险截然不同。下一章将详细讨论攻击者的类别及其可能的动机。第2章了解攻击者撰写人：HeatherAdkins、DavidHuska和JenBarnason1986年8月，LawrenceLivermore实验室的系统管理员CliffordStoll偶然发现了一个看似无害的账号错误，导致他和同事花了10个月的时间寻找窃取美国政府机密的人。这是目前公认的第一个公开案例1，由Stoll带头进行的一项调查揭露了攻击者用来实现目标的具体策略、技术和程序（tactic,technique,andprocedures，TTP）。通过仔细地研究，调查小组描绘出了攻击者锁定目标并从受保护的系统中抽走数据的路径图。许多系统设计人员通过阅读Stoll团队的开创性文章“StalkingtheWilyHacker”吸取了经验教训。1CliffordStoll发表在CommunicationsofACM上的文章“StalkingtheWilyHacker”及其著作TheCuckoo'sEgg:TrackingaSpyThroughtheMazeofComputerEspionage中记录了这次攻击。这些资源对于每个设计安全、可靠系统的人来说都是极好的，可以发现这些研究在今天依然相关。2012年3月，Google位于比利时的一个数据中心发生了一起不同寻常的停电事件，最终导致本地数据损坏。调查显示，一只猫损坏了附近的外部电源，因而引发了大楼电力系统的一系列连锁故障。通过研究复杂系统过去出现类似故障的方式，Google已经能够在世界各地采用弹性设计实践，以应对电缆被中断、掩埋或淹没的情况。了解攻击者，对于培养抵御各种灾难的能力和生存能力尤为重要。在可靠性方面，所谓的“攻击”通常并非恶意，且并非出自具体的某一攻击方。这既可能是常规的硬件故障或过量的用户关注（所谓的“成功灾难”），也可能是更改配置导致系统异常，甚至是渔船意外切断了海底光缆。相比之下，安全性方面的攻击者是人，他们的行为通常以非预期的方式影响目标系统。尽管意图和方法是相反的，但研究破坏可靠性和安全性的攻击者对于理解如何设计和实现弹性系统很重要。如果没有这些知识，那么预测“狡猾黑客”或“好奇猫”的行为将极具挑战性。本章将深入研究破坏安全性的恶意攻击者，以帮助各个领域的专家培养对抗的思维方式。你可能会从流行的刻板印象角度来想象恶意攻击者：在黑暗的地下室中，拥有聪明绰号的攻击者在暗中搞破坏。尽管确实存在如此个性鲜明的角色，但是任何有时间、有知识或有钱的人都可能破坏系统的安全性。只需支付少量费用，任何人都可以购买软件，接管他们可以接触的计算机或手机。黑客通常会购买或构建软件，以破坏其目标系统。研究人员经常探查系统的安全机制，以了解其工作原理。因此，我们鼓励对系统攻击者保持客观的看法。没有相同的两次攻击，也没有相同的两个攻击者。我们建议先看看第21章，以了解与攻击者打交道的文化。即使是对知识丰富的安全专家来说，预测未来的安全事故在大多数时候也只是猜谜游戏。下面几节介绍了多年来我们发现的有助于理解攻击者的三个框架：探索攻击者的潜在动机、常见攻击者的画像，以及如何思考攻击者的方法。我们还分别提供了三个框架的演示性案例，希望你能感受到其中的趣味。2.1攻击者动机破坏安全性的首要攻击者是人（至少目前是）。因此，我们可以通过攻击者的视角来考虑其目的。这样做能让我们更好地了解如何采取主动的（系统设计时）和被动的（应急响应时）措施。请考虑以下攻击动机。好玩破坏系统安全纯粹是为了好玩，知道系统可以被攻破。声望为了炫技而得恶名。激进主义为了发表观点或传播信息，通常是政治观点。获得金钱为了赚钱。胁迫故意让受害者做他们不想做的事。操纵为了达到预期目的或者改变他人的行为，例如发布造假的数据或信息。间谍活动包括商业间谍在内的间谍活动，用以获取可能有价值的信息。这些攻击者一般受雇于情报机构。毁坏破坏系统、销毁数据，或者只是让系统离线。攻击者可能是想赚钱的漏洞研究人员、间谍，或者犯罪分子——他们也可能同时出现！在设计系统时，重要的是牢记多样化的动机。假设有一个组织正在代表其客户处理转账事宜，如果我们了解攻击者可能关注该系统的原因，就可以更安全地设计该系统。2.2攻击者画像通过考虑攻击者的样子，可以更好地理解攻击者的动机：他们是谁，他们实施攻击是为自己还是为他人，他们的全局利益是什么。在本节中，我们将勾勒出一些攻击者的画像，指出他们与系统设计者的关系，并给出一些保护系统免受这几类攻击者破坏的提示。为简洁起见，我们粗略地进行了归纳，但请记住：既没有相同的两次攻击，也没有相同的两个攻击者。以下信息旨在说明，而非定义。早期的黑客麻省理工学院（MIT）被认为是“黑客”（hacking）一词的发源地，其起源可追溯至20世纪50年代，当时这一活动源于无知的恶作剧。良性的起源让一些人将“黑客”和“攻击”（attacking）分别独立地对应为非恶意行为和恶意行为。在本书中，我们将继续遵循这一传统。如今，MIT的黑客社区仍以“MITMindandHandBook”中记录的一套宽松的道德规范运作。2.2.1业余爱好者第一批计算机黑客就是业余爱好者，他们是技术专家，好奇心强，想了解系统是如何工作的。在拆解计算机或调试程序的过程中，这些“黑客”发现了原系统设计者没有注意到的缺陷。一般来说，业余爱好者的动机是他们对知识的渴求：他们成为黑客是受兴趣驱动的。对于希望将弹性构筑到系统中的开发人员来说，业余爱好者可以成为盟友。通常情况下，业余爱好者遵守个人道德，不会损害系统，也不会越界从事犯罪行为。通过深入了解这些黑客是如何思考问题的，可以使系统更加安全。2.2.2漏洞研究人员漏洞研究人员会专业地运用安全知识，而且乐于寻找安全缺陷。他们可以是全职员工、兼职的自由职业者，甚至是偶然发现漏洞的普通用户。许多研究人员会参与漏洞奖励计划［vulnerabilityrewardprogram，也称为漏洞赏金计划（bugbountyprogram），参见第20章］。通常，漏洞研究人员的动机是使系统更好，并且可以成为系统保护者的重要盟友。他们往往会遵守一套预期的披露规范，这些规范在系统所有者和研究人员之间形成了关于如何发现、报告、修复和讨论漏洞的约定。在这些规范下操作的研究人员会避免不适当地访问数据、造成系统损坏或是违法。通常，在这些规范之外操作不仅可能无法获得奖励，而且还可能被视为犯罪。与之相关的是，红队（RedTeam）和渗透测试人员在系统所有者的许可下对目标进行攻击，并可能明确受雇参加演习。跟研究人员一样，他们寻找攻破系统安全的方法，专注于提高安全性，并在一套道德准则下操作。有关红队的更多讨论，参见第20章。2.2.3黑客活动家黑客激进主义（hacktivism）是指利用技术来呼吁社会变革的行为。这个词不精确地涵盖了各种各样的网络政治活动，从表达政治诉求到恶意破坏系统。2出于研究如何设计系统的目的，我们在这里考虑后一种情况。2该词的创造者和含义存在争论。不过在1996年，这个词被著名的黑客组织采用，之后便被广泛使用。与其他类型的攻击者不同，黑客活动家通常会直言不讳地谈论他们的行动，并经常公开赞扬自己的行为。这有很多种表现形式，包括在社交媒体上发帖或是破坏系统。发起这类攻击的活动分子甚至可能不是精通技术的人员。这就会使得预测或防御黑客激进主义变得比较困难。防御黑客激进主义我们建议你考虑一下你的业务或项目是否涉及可能引起黑客活动家注意的、有争议的话题。比如，你的网站是否允许用户托管他们自己的内容，如博客或视频？你的项目是否涉及政治导向的问题，比如动物权利？活动家是否使用你的任何产品，例如消息服务？如果上述任何一个问题的答案为“是”，那么你可能需要考虑非常稳健的、分层的安全管控机制，确保系统打好漏洞补丁，同时对DoS攻击具有恢复能力，并且有备份机制，可以快速恢复系统及其数据。2.2.4犯罪分子利用攻击技术实施犯罪通常与现实中的犯罪相似，比如实施身份欺诈、盗窃金钱和勒索。犯罪分子具备的技术能力范围很广，有些人可能很老练，会自己编写工具，而其他人可能只会购买或借用他人编写的工具，较依赖于“一键攻击”的界面。事实上，尽管社会工程（欺骗受害者使其协助攻击的手段）难度较低，但它仍是非常有效的手法。对于大多数犯罪分子来说，唯一的门槛就是一点时间、一台计算机和一点现金。在过去的10年里，攻击者意识到，受害者会在敏感数据受到威胁时交出钱财。勒索软件是一种将系统或其信息作为“人质”（通常是将数据加密）的软件，直到受害者向攻击者付款才恢复。勒索软件一般会被打包成工具包出售给攻击者，而攻击者通常会通过利用漏洞、将勒索软件与合法软件打包，或者直接诱导用户自己安装勒索软件等手法来感染受害者的计算机。犯罪行为也不全都表现为勒索钱财。举例来说，跟踪软件的目的是在另一个人不知情的情况下收集信息。将恶意软件植入受害者的计算机或手机可以通过诱导受害者安装，也可以通过有权访问设备的攻击者直接安装。一旦安装到位，该软件就可以录制视频和音频。由于跟踪软件经常被受害者身边的人使用，比如配偶，因此这种信任利用可能造成毁灭性的后果。并不是所有的犯罪分子都为自己而工作。公司、律师事务所、政治运动、企业联盟、帮派和其他组织会出于自己的目的雇用恶意攻击者。防御犯罪分子在为应对犯罪分子而设计弹性系统时，需要牢记的是，这些人员往往倾向于采用最简单的方式，以最少的前期成本和精力实现其目标。如果你能让系统具有足够的弹性，那么攻击者可能会将焦点从你的系统转移至他处。因此，需要考虑他们会针对哪些系统，以及如何大幅增加他们的攻击成本。全自动区分计算机和人类的图灵测试系统（CAPTCHA系统）的发展就是一个很好的例子，它阐述了随着时间的推移，攻击成本会不断增长。CAPTCHA（也就是验证码）通常用于识别与网站交互的是人类还是机器人，常见的案例就是登录场景。机器人通常是恶意活动的标志，因此确定用户是否为人类是一个重要的信号。早期的验证码系统要求人类验证机器人难以识别的轻微扭曲的字母或数字。随着机器人变得越来越复杂，验证码的实施者开始使用失真图片和物体识别，这些策略的目的是随着时间的推移大幅增加攻击验证码的成本。33提高验证码技术有效性的对抗仍在继续，新的进展是使用用户与验证码交互时的行为分析。reCAPTCHA是一项免费服务，你可以在自己的网站上使用它。关于研究文献的一个相对较新的概述，可以参考2019年ChowYang-Wei、WillySusilo和PairatThorncharoensri在AdvancesinCyberSecurity:Principles,Techniques,andApplications一书中标题为“CAPTCHADesignandSecurityIssues”的内容，编者为Kuan-ChingLi、XiaofengChen和WillySusilo。2.2.5自动化和人工智能2015年，美国国防部高级研究计划局（USDefenseAdvancedResearchProjectsAgency,DARPA）宣布举行网络挑战赛，旨在设计一种网络推理系统。该系统可以在没有人工干预的情况下自学习和运作，以发现软件中的漏洞，挖掘利用这些漏洞的方法，然后修补这些漏洞。七支队伍参加了现场“决赛”，在一个舒适的大舞厅里直播他们完全独立的推理系统互相攻击。第一名的团队成功开发了这样一个自学习系统。网络挑战赛的成功表明，未来可能至少有一些攻击可以在没有人类直接控制的情况下执行。科学家和伦理学家在思考全感官机器是否有足够的能力学习如何互相攻击。自主攻击平台的概念也促使了对日益自动化防御的需求，我们预测这将是未来系统设计师的一个重要研究领域。防御自动化攻击为了抵御自动化攻击的冲击，开发人员需要考虑“默认弹性”的系统设计，并能够自动迭代其系统的安全态势。本书涵盖了其中的许多主题，例如，第5章的自动配置分发和访问证明，第14章的代码自动构建、测试和部署，以及第8章的DoS攻击处理。2.2.6内部人员每个组织都有内部人员，即被信任的拥有系统内部访问权限或专有知识的现任或前任员工，内部风险就是由这些人构成的威胁。当一个人能够执行可能对组织造成损害的各种恶意、疏忽或意外情况的操作时，他就会成为内部威胁。内部风险是一个很大的话题，可以用几本书的篇幅讨论。为了帮助系统设计人员，我们考虑分三类来简要介绍这个主题，如表2-1所示。表2-1：常见的内部人员和案例列表己方内部人员第三方内部人员相关知情人雇员第三方手机软件开发者朋友实习生开源代码贡献者家庭高管可信赖的内容贡献者室友董事商业伙伴——承办商——供应商——审计人员—安全性与可靠性的交集：内部人员的影响当谈到防御攻击者，出于抵御内部人员目的来设计系统时，可靠性和安全性往往是相辅相成的。这种交集在很大程度上是由于内部人员对系统拥有特别的访问权限。大多数可靠性事件源于内部人员采取的行动，他们通常没有意识到自己是如何影响系统的，例如通过引入错误的代码或错误的配置更改。在安全方面，如果可以控制员工的账户，那么攻击者就可以恶意攻击系统，就好像他们就是那个内部人员一样。分配给内部人员的任何权限或特权都可能为攻击者所用。在设计既可靠又安全的系统时，最佳实践是既考虑可能出错的善意的内部人员，也考虑可能接管员工账户的攻击者。假设有一个数据库，其中包含对业务来说至关重要的敏感客户信息，你可能希望防止员工在执行维护工作时意外删除该数据库，同时还希望保护数据库信息，以避开劫持员工账户的攻击者。第5章概述的最小特权技术可同时防范可靠性和安全性风险。己方内部人员己方内部人员通常是以特定目的加入团队的人——直接参与实现业务目标，包括直接为公司工作的员工、高管和做出关键公司决策的董事会成员，你可能也会想到其他属于这一类的人。能够以主人视角访问敏感数据或系统的内部人员促成了大多数有关内部风险的新闻报道。对于有偷窥倾向的内部人员，或是那些觉得拥有特权会让自己显得很重要的人，甚至想出售此类信息的人，获取个人数据也是很有诱惑力的。随着越来越多的消费者注册社交网络、消息传递和银行服务，保护其数据免受员工不当访问比以往任何时候都更加重要。一些最激进的内部风险故事涉及心怀不满的内部人员，比如因表现不佳而被解雇的人删除前雇主的虚拟服务器，使得公司失去了关键合同和可观的收入。绝大多数成立了一段时间的公司有类似的故事。由于劳务关系的动态性，这种风险是不可避免的。然而，如前所述，己方内部人员也会影响系统的可靠性。例如，上一章讨论的密码存储系统的设计、操作和维护中一系列不幸的内部行为，阻止了网站可靠性工程师在紧急情况下访问凭据。正如我们将看到的，预见到内部人员可能引入的错误对于保证系统完整性至关重要。第三方内部人员随着开源软件和开放平台的兴起，内部威胁有可能是组织中很少有人（甚至没有人）遇见过的人。考虑以下场景：你的公司开发了一个有助于图像处理的新库，现在决定开源该库并接受来自公众的代码变更列表。除了公司员工，你现在还必须将开源贡献者视为内部人员。然而，如果你从未见过的地球另一端的开源贡献者提交了恶意的变更列表，则他们可能会伤害使用该库的人。同样，开源开发人员很少能在所有可能部署代码的环境中测试代码。添加到代码库可能会带来不可预测的可靠性问题，例如意外的性能降级或硬件兼容性问题。在这种场景下，你可能希望实现管控，以确保所有提交的代码都经过彻底审阅和测试。有关该领域最佳实践的更多详细信息，参见第13章和第14章。你还应该仔细考虑如何通过应用程序接口（applicationprogramminginterface,API）扩展产品的功能。假设你的组织开发了一个带有第三方开发者API的人力资源平台，能让公司轻松地扩展软件功能。如果第三方开发者拥有数据的特权或特殊访问权限，那么他们就会变成内部威胁。请仔细考虑通过API提供的访问权限，以及第三方获得访问权限后可执行的操作。你能否限制扩展型内部人员对系统可靠性和安全性的影响？相关知情人信任与我们一起生活的人是人之常情，但在设计安全系统时，系统设计人员往往会忽略其中的风险4。考虑一名员工周末将笔记本计算机带回家的情况，当设备在饭桌上被解锁时，谁可以接触到它，这会有什么影响——无论接触它的人是恶意的还是无意的。对于技术工作者来说，远程办公、在家工作和深夜值班越来越普遍。在考虑内部风险威胁模型时，请确保使用包括家庭在内的“工作场所”的宽泛定义。键盘背后的人可能并不总是“典型”的内部人员。确定内部人员意图如果系统因为内部人员的行为而出现异常，而他们声称自己的行为是意外，你会相信他们吗？这个问题的答案可能很难确定，在极端疏忽的情况下，可能无法最终确认或排除。这类案件通常需要与调查专家合作，例如法务部门、人力资源部门，甚至执法部门。重要的是，在设计、运行和维护系统时要考虑恶意操作和意外操作的情况，并且假设无法知道两者的区别。内部风险威胁模型有许多框架可用于对内部风险进行建模，范围从简单的框架到深度定制主题的、复杂的、详细的框架。如果你需要从一个简单的模型开始，可以参考表2-2中的框架。这种模式也适用于快速的头脑风暴会议或有趣的纸牌游戏。表2-2：内部风险威胁模型的框架参与者/角色动机行为目标工程师意外数据访问用户数据运维人员过失泄露（窃取）源代码销售人员妥协删除文档律师金钱篡改日志营销人员主导意识注入基础设施主管领导报复消息外泄服务—虚荣心—资金首先，建立一个组织中的参与者/角色列表，然后尝试列举出所有可能的潜在目标（数据、系统等），以及对目标可能造成伤害（包括事故）的行为。可以将每个类别中的项目组合成多个场景。这里有一些示例可以协助你开始。有权访问源代码的工程师对工作表现评估结果不满意，并通过向生产系统中注入恶意后门来进行报复，窃取用户数据。陌生人与拥有访问网站SSL加密密钥的网站可靠性工程师联系，并“强制鼓励”（例如，通过威胁其家人）交出敏感材料。准备公司财务报表的财务分析师加班加点，不小心将最终年度收入数据后多加了一个0。网站可靠性工程师的孩子在家里使用父母的笔记本计算机，安装了一个与恶意软件捆绑在一起的游戏，可以锁定计算机，妨碍了网站可靠性工程师对严重故障做出响应。威胁建模错误犯错是人之常情。2009年1月31日那天有大约40分钟，Google搜索向每一个用户、在每一次搜索时都显示了一个不祥的警告，“Thissitemayharmyourcomputer”（这个网站可能会伤害你的计算机）。此警告通常用于链接到已被破坏或托管恶意软件的网站的搜索结果。问题根源很简单，“/”符号被无意间添加到系统里的恶意网站列表（已知会在后台安装恶意软件的网站）中，匹配到了地球上的所有网站。如果有足够的时间使用系统，每个人可能都会遇上类似的恐怖故事。这些错误可能是由于熬夜工作，或是打错字，又或者是遇到了系统上无法预见的功能。在设计安全可靠的系统时，请记住是人就会犯错，并且要考虑如何避免这些错误。自动检查配置中是否添加了“/”就能防止上述案例。针对内部风险的设计本书提出了许多适用于防范内部风险和恶意“外部”攻击者的安全设计策略。在设计系统时必须考虑到，任何有权访问系统及其数据的人都可能是本章概述的任何一类攻击者。因此，检测和降低这两类风险的策略是相似的。我们发现，在考虑内部风险时，以下几个概念特别有效。最小特权原则无论是访问范围还是访问持续时间，仅授予履行工作职责所需的最小特权，参见第5章。零信任设计自动化机制或代理机制来管理系统，这样一来，内部人员就不会有过高的访问权限，从而避免造成危害，参见第3章。多方授权使用技术控制要求多人授权敏感操作，参见第5章。业务缘由要求员工正式记录其访问敏感数据或系统的原因，参见第5章。审计和检测审阅所有访问日志和理由，以确保它们是合理行为，参见第15章。可恢复性在破坏性操作（如心怀不满的员工删除关键文件或系统）后恢复系统的能力，参见第9章。4有关考虑家庭伴侣滥用权限如何影响安全和隐私功能的示例，请参见Matthews、Tara等人2017年发表的论文“StoriesfromSurvivors:Privacy&SecurityPracticesWhenCopingwithIntimatePartnerAbuse”，该论文选自2017年CHI计算系统人为因素会议论文集，第2189~2201页。2.3攻击者方法论我们所描述的攻击者是如何实施攻击的呢？了解此问题的答案对于了解如何对系统产生危害以及如何保护系统至关重要。理解攻击者是如何操作的，就像是推测复杂的魔术。由于可用的攻击方法多种多样，因此尝试预测任何特定攻击者在给定日期可能会做什么是不可行的。我们不可能在这里介绍所有可能的方法，但值得庆幸的是，开发人员和系统设计人员可以利用越来越多的案例和框架知识库来解决这个问题。在本节中，我们将讨论几个研究攻击者方法的框架：威胁情报、网络杀伤链和TTP。2.3.1威胁情报许多安全公司对其看到的攻击做了详细描述。这种威胁情报可以帮助系统防御者了解真正的攻击者每天是如何工作的，以及如何击退这些攻击者。威胁情报有多种形式，每种形式都有其不同的用途。书面报告描述了攻击是如何发生的，对于了解攻击者的过程和意图特别有用。这类报告通常是实际应急响应的结果，其质量可能因研究人员的专业知识而异。失陷指标（indicatorofcompromise,IOC）是攻击的有限属性集，例如攻击者托管钓鱼网站的IP地址或恶意二进制文件的SHA256校验值。IOC通常使用通用格式5构建，可自动获得反馈，因此可用于以编程方式来配置检测系统。恶意软件报告可让你深入了解攻击者所用工具的功能，并可能成为IOC的来源。这些报告由逆向工程专家生成，通常使用行业标准工具，如IDAPro或Ghidra。恶意软件研究人员还利用这些研究，根据它们的共同软件属性来交叉关联分析原本无关的攻击。5例如，很多工具采用了结构化威胁信息表达（StructuredThreatInformationeXpression,STIX）语言来标准化IOC文档，因而可以在系统间使用指标信息的可信自动化交换（TrustedAutomatedeXchangeofIndicatorInformation,TAXII）进行交换。从信誉良好的安全公司（最好是有客户推荐人的公司）获取威胁情报，可以帮助你更好地了解观察到的攻击者活动，包括影响同行的攻击。了解与你类似的组织所面临的攻击类型，可以为你未来将面临的攻击提供早期预警。许多威胁情报公司还免费公开发表年度总结和趋势报告6。6值得关注的包括VerizonDataBreach年度调查报告和CrowdStrike年度全球威胁报告。2.3.2网络杀伤链攻击准备的一种方法是列出攻击者为实现其目标必须采取的所有步骤。一些安全研究人员使用像网络杀伤链（CyberKillChain7）这样的形式化框架来分析这种攻击。这些类型的框架可以帮助你在考虑防御控制的同时绘制攻击的正式过程。表2-3展现了假想的攻击阶段相对应的防御层。7LockheedMartin构思（并注册商标）的网络杀伤链是对传统军事攻击结构的改编。它定义了网络攻击的七大阶段，但我们发现它是可变的。包括本书作者在内的一些研究人员将这七个阶段简化为四五个阶段。表2-3：假想攻击的网络杀伤链攻击阶段攻击案例防御措施侦察：对目标受害者进行监视以了解他们的弱点攻击者使用搜索引擎找到目标组织雇员的电子邮箱地址教育雇员关注线上安全侵入：获得进行攻击所需的网络、系统或账户的访问权限攻击者向员工发送网络钓鱼电子邮件，从而导致账户凭据被盗。然后攻击者可以利用凭据登入虚拟专用网络（virtualprivatenetwork,VPN）VPN服务采用双因素认证（比如安全密钥）。只允许来自组织管理系统的VPN连接横向移动：在系统或账户之间移动以获得更多访问权限攻击者利用窃得的凭据登录其他系统只允许雇员登录他们自己的系统。在登录多用户系统时需要双因素认证持久性：确保持续访问受侵害资产攻击者在新沦陷的系统中安装后门，进而提供远程访问采用应用程序白名单，仅允许授权的软件可运行目标：对攻击目标采取行动攻击者通过网络偷得文档，并通过远程后门取出它们落实访问敏感数据的最小权限，并监控雇员账号2.3.3TTP对攻击者的TTP进行系统性分类，是列举攻击手段的一种越来越常见的方法。最近，MITRE开发了ATT&CK框架来更彻底地实现这一想法。简而言之，该框架将网络杀伤链的每个阶段扩展为详细的步骤，并描述了攻击者如何实施攻击的每个阶段。例如，在凭据访问阶段，ATT&CK描述用户的.bash_History文件里可能包含攻击者只要读到文件即可获得的意外键入的密码。ATT&CK框架列出了攻击者可以操作的数百种（也可能是数千种）方式，以便防御者可以针对每种攻击方法建立防御机制。2.4风险评估注意事项了解潜在的攻击者是谁及其可能使用的方法是复杂又微妙的。在评估各种攻击者造成的风险时，我们发现以下因素非常重要。你可能没有意识到你是目标你的公司、组织或项目是否为攻击者的潜在目标，这可能不会立即显现出来。许多组织，尽管规模较小或没有参与处理敏感信息，也可能被利用来实施攻击。2012年9月，Adobe（一家以支持内容创建者的软件而闻名的公司）披露了有攻击者侵入其网络，使用该公司的官方软件签名证书对其恶意软件进行数字签名，其意图很明确——这使得攻击者能够部署对防病毒软件和其他安全保护软件来说是合法的恶意软件。考虑你的组织是否有攻击者感兴趣的资产，无论是为了直接获利还是作为针对其他人的更大型攻击的一部分。攻击的复杂程度并不能真的帮你成功预测攻击即使攻击者拥有大量的资源和技能，也不要认为他们总会选择最困难、最昂贵或最深奥的方法来实现他们的目标。一般而言，攻击者会选择最简单、最具成本效益的方法来危害符合其目标的系统。例如，一些最突出、最具影响力的情报收集行动依赖于基本的网络钓鱼手段——欺骗用户交出密码。因此在设计系统时，与其担心稀奇古怪的攻击路数（如固件后门），不如先覆盖最基础的安全措施（如使用双因素身份验证）。不要低估攻击者不要假设攻击者不能获得资源来实施昂贵或困难的攻击。仔细考虑一下针对你的攻击者愿意花多少钱。但是，请记住这类情况在很大程度上是例外，而非常态。归因是很难的有动机的攻击者可以用创造性的方式隐藏他们的动机和身份，例如，他们可以将自己伪装成看似无害的角色。由于攻击者的身份和意图可能并不总被很好地理解，因此我们建议你在担心攻击者的具体身份之前，先关注攻击者是如何工作的（TTP）。攻击者并不总是害怕被抓捕即使你设法追踪到攻击者的位置和身份，刑罚制度（特别是国际