安全即代码：保护云应用程序和系统的最佳（也许唯一）途径

写在前面:感谢王曙推荐文档。

麦肯锡这么多年来一直在推进业务数字化转型，在这过程中，安全作为业务保障手段，变得特别重要。随着向云迁移，云里面也涌现出很多新的安全问题，技术方案也在不断进化。

基础设施即代码（IaC）推动基础设施自动化，同时也有安全策略自动化的需求。特别是在业务部署到多个云的多云战略背景下，为满足DevOps和云原生计算的动态特性，要求安全也要变得敏捷，自动化安全策略，把安全策略代码化是有效的解决方案。

管理安全即代码，使公司能够在云中安全地创造价值。

随着公司采用公有云平台，现有的网络安全架构和运营模式已经崩溃。为什么？因为云里面几乎所有的泄露都来自于错误配置，而不是来自攻击、入侵底层的云基础设施。

因此，云要求应用程序和系统的安全配置。但传统的网络安全机制，没有设计成保证安全配置、或像商业领袖期望的那样，利用敏捷和速度的优点来运营。如果公司想要得到云的价值，他们必须采用新的安全架构和流程，来保护他们的云负载。相比传统的本地模式，云迁移不仅能增加业务价值的交付，而且能提高系统和应用的安全。

安全即代码（Security as code，SaC）是保护云负载最有效的方法，实现速度和敏捷。在这一点上，大多数云领先者认可基础设施即代码（infrastructure as code，IaC）允许他们在云中自动化构建系统，消除手动配置容易引起的故障。SaC走得更远，以编程的方式定义网络策略和标准，在提供云系统的配置脚本中被自动引用，在云中运行的系统可以和安全策略对比，防止“漂移”（见图1）。例如，如果业务设置了一个策略，所有个人身份信息（personally identifiable information，PII）在存储时必须加密，这个策略被转换成一个过程，当开发人员提交代码时会自动启动，违反PII策略的代码自动被拒绝。

为了获取云里面的价值，要求大多数公司打造一个转换引擎（图2）把云集成到业务和技术中，推动在重要业务领域内优先采用，建立能够安全和经济地扩展云使用的基础能力。SaC是在云安全和风险管理中发展基础能力的机制。

理论上SaC能在公司自己的数据中心内实施，但云服务商（CSP）提供的自动化能力，使它在云中更具有实际意义。

SaC三个最大的好处

第一个好处是速度。为了充分认识到云的业务收益，安全团队必须以他们在本地环境中不习惯的速度移动。人工干预会引入摩擦、拖慢开发、损害了云对业务的整体价值主张。

第二个好处是减少风险。本地的安全控制无法考虑云的细微差别。云安全要求在整个生命周期内，控制随着工作负载移动。实现这种级别的嵌入式安全的唯一方法是通过SaC。

最后，SaC是业务的推动者。安全和合规要求日益变成业务产品和服务的核心。在这方面，SaC不仅仅加快上市时间，还在不降低安全的情况下，扩展创新和产品创意的机会。

实现SaC的方法

实施SaC对所有公司都要求策略、架构和文化的明显改变。出于这个原因，许多人发现根据敏感性和重要性，使用SaC框架去分类工作负载非常有帮助，然后基于工作负载风险和部署类型，应用特定的安全控制。而且提供未来状态架构的蓝图，总结所指定的关键决策。通过各种自动化使用案例来有效和有效率地实例化SaC。最后，这个框架定义了公司的运营模型必须如何改变，才能获取采用云的全部好处（图3）。

风险分类，部署模型，和标准/策略

在对工作负载及数据的敏感性和重要性分类后，下一步是应用策略，最后能通过代码来实例化。为了达到这个水平，在每个控制区域，组织常常会遇到三种选择。

首先，发现和编写新策略，解释本地没有的技术，例如考虑容器安全。一直在本地运营的公司可能不会强制扫描静止、部署、运行时的容器漏洞。同样，应该有使用可信镜像和安全注册表的现成策略。标准中常见差异的另一个例子是API安全，需要认证流量和使用网关控制API。

其次，除了编写新的策略，公司要修改当前本地环境策略，解决云的独特安全环境，例如要考虑网络分段。因此大多数本地组织，仅限于在网络边界使用粗粒度的防火墙规则，强制网络分段策略。在云中，他们可以配置成安全组，提供主机水平的网络保护，甚至在单独子网内，有效提供微隔离。此外他们在子网或虚拟网络边界上使用更粗粒度的控制，这些可以通过代码来配置和维护，而不是人工流程和使用手册。

最后，为了完整实现SaC的承诺，所有当前策略和新策略，必须编写地足够详细，保证他们能够转换成代码。在生成有效的安全策略方面，我们观察到最大的差距之一是缺少了解如何设计有效策略和策略实施的人才。设计槽糕的策略和策略实施同他们想解决的风险一样问题多多和成本很高，也许是和应用安全有关最常见的例子。策略必须要细粒度，足以自动化阻止应用进入生产，直到他们没有明显的、超出预计修复时间帧的漏洞。同样，为了身份和访问管理的目标，策略应该要求集成SaaS应用和联合身份系统，根据应用的风险分类，自动强制使用多因素认证（MFA）。

架构和自动化

一旦组织建立了健壮的风险分类框架，定义了云策略，成功实施SaC取决于做出关键架构设计决策和执行正确的自动化能力。与策略一样，我们推荐把这些决策映射到组织的优先控制区域。

但在公司能回答云安全架构的关键问题之前，必须首先对于整体云架构做出设计决策。这看起来显而易见，但常常是一个被忽略的关键步骤。只有当组织能回答它的多云架构的关键问题，包括（但不限于）选择主要的云服务商，以及如何设计战略边界之后，组织才能开始设计安全架构。

也许实现SaC最重要的决策是，策略目标是否通过联合、原生CSP工具或集中的第三方工具来实例化。这没有标准答案；而是这个问题必须根据组织的风险偏好、工作负载分类、策略目标和整体云战略的关联关系来考虑。集中的、第三方工具的原理是通过单一界面，跨本地和云，实现集成的可视化。

自动化是加强系统开发生命周期（SDLC）不同阶段策略的基础。因此，组织对于他们的多云环境，开发一个安全自动化使用实例的全面清单非常重要。不像映射到控制区域的策略目标和架构功能，这些使用实例应该映射到SDLC的各个阶段：编码、构建、打包、部署和运维。一些使用实例，如系统正式停止和容错测试，是基础设施即服务（IaaS）部署独有的。而其他的如日志传输、导入、代码扫描，在多种部署模型中很常见。一个云治理引擎合规服务（Cloud Governance Engine Compliance Service）用来管理这个流程。这是一个集中的服务，提供云资源之前，负责接受提出的请求，验证基础设施即代码（IaC）是否符合组织合规要求。

运营模型和更广泛的云战略的连接

当采用合适的安全开始云的旅程时，大多数公司采用技术优先的方法。和技术改变同样重要的是，公司需要改进他们的运维模式，实现“左移”，最大化自我服务能力，实现全生命周期的安全自动化。

SaC要求高度自动化服务、开发人员可以通过API来使用。反过来这同样也要求在安全、基础设施、应用开发团队上的行为改变。安全组织必须从响应式的、基于请求的模式，转变到使用高度自动化的安全产品-例如，在身份和访问管理或漏洞管理中。在云里面，许多控制仅仅是核心计算或存储服务的配置选项。因此，基础设施产品工程团队必须和对应安全部门团结得更紧密，解决产品中积压的安全需求。开发团队要求现场可靠工程师（site-reliable engineers，SRE）有足够的经验来有效地提供安全服务和管理应用。

为实现这个目标，公司需要和常见的开发工具链及持续集成/交付管道结合起来。除非这些能力被标准化，否则SaC和云中的安全，都变得不可能。他们必须升级整个组织的技能，现场可靠工程师（SRE）需要成为有经验的安全使用者。基础设施产品管理者和工程师需要理解他们产品的安全影响。相比合规，安全组织需要更多产品管理和工程能力。

公司如何实现SaC

一个大规模金融机构准备将80%的工作负载转移到云上。然而人们很快就发现，解决合规问题的传统响应方法，在部署到产品环境之后，无法跟上云负载。因此公司决定使用SaC主动推动管道中的合规。

为了实现这个目标，对关键任务应用分成了400个控制，保证弹性的云基础设施。然后开发和实现了90多个规则支持这些控制，并把他们转换成小段代码，在任何时候，任何基础设施请求都可以引用。这些代码块确保在提供之前满足所有的合规要求。这个方法为当前一半的安全需求提供自动化覆盖。

安全常常被看作是采用云的障碍。本来应该是无摩擦的部署过程，从一开始就嵌入安全。但当他们试图把云部署硬塞入传统的安全机制中，变成在开发人员、基础设施和安全之间几周和几个月时间来回扯皮。从第三方评估到防火墙变更的冗长审批，不仅降低了云的整体价值主张，而且为适应业务要求，增加了风险策略例外情况的需求。

SaC努力扭转这种趋势，把CISO定位为业务的推动者，而不是妨碍者。消除基于ticket的工作流、手动变更流程的需求，相比本地系统，SaC框架把最关键的安全控制实现自动化，提高整体安全，不会降低业务或牺牲合规要求。

CISO 对SaC的看法

来自亚马逊、谷歌和微软的CISO们看到了安全即代码的多种好处。

减少人力错误：

通过代码实现安全关键在于可重复性。为了安全目的，我们实施自动化和使用代码，因为它在整个组织内应用普遍的严谨。解决人工错误问题，这是云泄露中常见的共同点。
—Stephen Schmidt, AWS CISO

随着时间，规模经济会推动高水平的缺省控制。我们越提高控制基线(例如，加密虚拟机、高保证容器工作负载，身份和访问管理，客户管理加密秘钥),更多的客户就能打开所有工作负载分类。很快，当这样的增强安全控制部署到所有客户的所有服务，我们会到达一个顶点Schmidt, AWS CISO
—Phil Venables, Google Cloud CISO

平衡速度和风险：

安全即代码就是给与我们员工工作自由，同时保证我们能看见他们的所作所为，没有隐藏的行为或影子IT。安全团队必须扮演一个审计员角色，详细了解进行的工作，当变更发生时得到提示。
—Stephen Schmidt, AWS CISO

你从清单、服务、配置中获得的自动化能力和洞察，以及大规模修复能力在本地都是不可能的。我们在两年半时间内，通过使用集成的整体云方案，减少48%的供应商。
—Bret Arsenault, Microsoft CISO

安全提高的步伐和我们产品安全特性（我们安全产品的主题，而不仅仅是安全产品）增加的程度正在加快，许多其他云提供商也取得类似成绩，这个大规模、全球范围内的竞争，在保持敏捷和生产力同时持续提高安全，对所有人都有好处。
—Phil Venables, Google Cloud CISO

提升和转移安全：

我们能看见的最大的问题是组织努力把安全从本地转移到云，这样做错失了很多在云里而不是数据中心的机会。
—Stephen Schmidt, AWS CISO

对一些没有熟练安全团队的客户，他们所做的是保证开启云提供的每项新安全功能。最先进的客户要求给所有人带来好处的新功能，而这一点再加上我们作为大规模的云提供商拥有的对威胁的可视化和响应，事实上，对整个客户生成一个数字免疫系统。
—Phil Venables, Google Cloud CISO

我们能和企业客户建立联系，我们的安全基础设施和工具不是天生为云而生。然而，组织不能只采用传统的、本地安全过程和工具，把他们应用到云环境中，他们无法以必要的规模或速度起到作用。他们必须根据他们操作的环境进行过渡。这个投资实现整体成本节省，好处非常明显。
—Bret Arsenault, Microsoft CISO

自动化遏制：

一些组织能自动化修复到已知的良好状态，但大多数组织没有，他们应该专注自动化遏制。应用的所有组件需要有特定的、最新的、测试过的运行手册，遏制事件中不期望的行为。尽早带给业务和应用的所有者。你不会想争论何时拉开在激烈斗争中隔开每件事的那根线。
—Stephen Schmidt, AWS CISO

文章来源：安全行者老霍