序一

多年来，我一直希望有人能写出这样的一本书。自 Google“网站可靠性工程”（Site Reliability Engineering, SRE）的书出版以来，我时常赞赏和推荐它们。因此在来到 Google 时，发现一本专注于安全性和可靠性的书正在编写中，我非常兴奋，也非常高兴能为它做出小小的贡献。自从涉足科技领域以来，我曾在不同规模的组织中见过人们为如何保障安全性而苦恼。集中管理还是联合管理？独立型还是嵌入型？参与运营还是咨询为主？技术型还是管理型？问题不胜枚举。

当 SRE 模型和类似 SRE 的 DevOps 版本流行起来时，我发现 SRE 领域出现的问题与安全性问题很相近。一些团队已将这两项工作合二为一，称为 DevSecOps。

SRE 和安全性都非常依赖于传统的软件工程团队，但又跟传统软件工程团队有质的不同：

◆ 网站可靠性工程师与安全工程师倾向于认为破坏、修复与构建一样重要；

◆ 他们的工作除了开发，还有运维；

◆ 与传统软件工程师不同，网站可靠性工程师和安全工程师都是专家；

◆ 他们通常被视为障碍，而不是推动者；

◆ 他们通常是独立的，并不整合在产品团队中。

与安全工程师类似，SRE 带来了一项专门的工种及一系列工作职责，需要从业者具备特定的技能。SRE 还创造了连接不同团队的实现模型，这似乎是安全社区下一步将要采纳的。多年来，我和我的同事一直在争辩，安全性是否是嵌入软件质量的首要事项。我相信，采纳基于 SRE 的方法是顺应趋势的选择。

自从来到 Google，我了解了 SRE 模型的建立方式、SRE 实现 DevOps 理念的方式，以及 SRE 和 DevOps 的发展方式。除此之外，我还将金融服务领域的 IT 安全经验转化为 Google 的技术和程序化安全能力。这两个领域并非毫不相关，但各自都有值得了解的历史。与此同时，企业正处于关键时期，云计算、各式各样的机器学习方法和复杂的网络安全形势，共同决定着日益数字化的世界的发展方向、发展速度以及发展中涉及的风险。

随着我对安全性和 SRE 之间关系的了解逐步加深，我更加确定，将安全实践集成到软件和数据服务的全生命周期中是非常重要的。现代混合云（其中大部分是基于提供数据互联和微服务的开源软件框架）的本质使紧密集成的安全性和弹性功能变得更加重要。

在过去的二十年中，大型企业在安全性方面的运作和组织形式发生了巨大的变化。最突出的案例包括完全集中式的首席信息安全官和核心基础架构运维团队，其中涉及防火墙、目录服务和代理等，这些团队的规模已发展到包含成百上千名员工。另外，业务与信息安全联合团队已具有所需的业务线或者技术专家，专门负责支持或治理一系列的功能或业务运营问题。其中，委员会、指标和规范要求可能会负责治理安全策略，而嵌入的安全性支持者要么在所谓的组织单元中扮演关系管理的角色，要么跟踪议题的进展。最近，我看到有的团队将嵌入式角色演变成网站安全工程师或专家级安全团队里负责敏捷软件开发（scrum）的角色，而这样做不过是在重复 SRE 模型。

我们有充分的理由相信，企业安全团队对机密性有很强的关注度。但是，团队通常也意识到数据完整性和可用性同等重要，并将这两个领域分配给不同的团队，使其以不同的控制方法来解决问题。SRE 是解决可靠性问题的一流方案，并且在实时检测和响应技术问题（包括特权访问和敏感数据的安全攻击）上也发挥了作用。说到底，虽然工程师团队通常根据专业技能来区分角色，但他们有一个共同的目标：确保系统或应用程序的质量和安全性。

在这个越来越依赖技术的世界中，一本从 Google 和整个行业的经验中汲取有关安全性和可靠性方法论的书，可能会对软件开发、系统管理和数据保护的发展做出重要贡献。随着信息安全所面临的威胁层出不穷，动态和综合的防御方法已经成为基本需求。在我之前的工作经历中，我希望对这些问题有更加正式的探索。我希望内部团队和外部安全团队都能看到，随着方法和工具的发展，这种讨论是大有用处的。这本书强化了我的信念，它涵盖的主题值得在行业中讨论和推广，尤其是考虑到越来越多的团队采用 DevOps、DevSecOps、SRE、混合云架构以及相关的运维模型。至少，在日渐数字化的世界中，这本书在系统和数据安全性的发展和增强方面迈出了重要一步。

——Royal Hansen
Google 公司安全工程副总裁