DevOps如何在不牺牲安全性的情况下迁移到云

DevOps意味着开发比以往任何时候都快。如何确保一切都是安全的，尤其是在迁移到云时？伊万·诺维科夫（Ivan Novikov）仔细研究了如何使所有事物保持同步发展，而又不会留下巨大的安全漏洞。

为了使企业在未来几年中蓬勃发展，他们的未来可能会基于云。自2002年推出Amazon Web Services（AWS）以来，云计算的日益普及使云计算成为组织中第一大增长领域。

加特纳说过：“在2022年之前，Gartner预测云服务行业的市场规模和增长将是整体IT服务增长的三倍……云服务无疑正在撼动整个行业。在Gartner，我们不知道今天有任何供应商或服务提供商的业务模型产品和收入增长不受组织中越来越多采用云优先策略的影响。”

这很容易理解。数字化转型引领业务增长。云加速了这种转变，简化了流程并促进了全球团队之间的协作。云还：

用开发和运行应用程序所需的按需计算能力来代替昂贵的硬件以及相关的管理和运营成本；

使应用程序和基础微服务能够快速扩展，而无需锁定任何特定的硬件配置。

简化IT管理选项，同时提高内部IT基础架构的可靠性。

同样，云迁移（就像任何革命性的变革一样）伴随着影响我们安全推进业务的方式的变化。

了解云原生架构的影响和新的安全挑战

第一步是了解云将如何影响您的DevOps和安全格局。云架构如何改变您的业务有两个相互影响的巨大趋势：基于新架构的技术催化剂；以及业务流程挑战将如何在基础架构中产生影响。

云中的技术挑战

云技术可以改变技术。

由于传统的安全性考虑让位于云中诞生的新安全性概念，因此需要进行权衡。从好的方面来说，云的规模及其运营团队的专业知识

解决了CTO / CSO及其内部团队以前必须承担的许多问题。建立，维护和保护计算资源的物理部分不再是开发成功的试金石。例如，一旦迁移到云，就不必担心备份是内部部署还是外部部署。但是，云带来了一些显着的安全性挑战：容器安全性和不断变化的管理员IT专业知识。

新环境要求更多地依赖API。但是，传统的解决方案并非旨在解决API级别的漏洞，并且随着攻击性API不断发展以管理和传递复杂的数据结构，执行应用程序逻辑，并在各个容器之间提供协调工作以运行Web的血液流动，它们变得越来越复杂。应用。此外，API的类型很多：面向用户的API提供了要在浏览器中显示的信息；东西方API将应用程序和微服务连接在一起；服务API允许监视，警报和应用程序管理；移动后端API使iPhone等设备真正智能化。还有一个完整的第三方生态系统，完全通过API提供数据服务。例如，只需支付少量费用，

API对于现代体系结构至关重要，并渗透到处理最敏感数据的应用程序中。但是，API会说不同的“语言”或协议，这使它们难以监视。因此，至关重要的是要有适当的API优化安全性，以确保仔细监视和标记内部API和所有传入数据，并适当地确定优先级并解决问题。

新架构面临的另一个主要挑战是对容器和微服务的依赖。像Kubernetes这样的微服务管理系统可以简化迁移。它们可以用于私有云和公共云，例如Google，Azure或Amazon。但是，这些系统具有自己的一组安全性概念。例如，即使您在入口控制器上安装了解决方案，也需要确保它可以跟上大流量和云自动扩展。没有人愿意为了速度而牺牲安全性。

此外，云的灵活性意味着一方面管理对基础架构的访问可能是一个挑战，而对云管理平面的访问就像获得王国的钥匙一样。确保访问点的安全并限制共享凭据非常重要，这样可以避免它们受到威胁。而不是为您的根帐户创建访问密钥，而是实现可靠的基于角色的访问控制（RBAC）。

最后，专家少于采用者，并且对安全工具和最佳实践的关注不足。涌现出太多的新技术，使得捍卫这一新的计算领域变得复杂。快速采用的问题部分在于，这些新技术，基础架构以及大量工具和第三方不属于既定课程。没有足够的人训练来理解全局或微观细节。

（我们稍后将讨论在新的云环境中谁负责安全性。）

面向云的新DevOps

除了技术革新之外，云还紧跟业务流程的重大变化和挑战。

云的演进与特定的DevOps流程和加速相关。为了真正解决云中的安全问题，我们将必须解决安全性如何与现有DevOps工作流程集成的问题。

快速的开发周期（有些短至几分钟）意味着不再可能提前预测和引入生产需求以及进行测试。操作中的所有内容（从物理服务器部署到基本订购的采购过程）都必须跟上。因此，DevOps是自然合并。

云的灵活性是逻辑上的推动力，用于处理不可预测的服务器负载和体系结构，最终用户以及持续集成和部署（CI / CD）产生的无数变量。没有内部部署和公共云体系结构和服务的必然增长，很难想象CI / CD的发展速度。但是，这些快速的CI / CD流程正在改变业务期望，并加剧了向市场交付产品的竞争。

更快的开发周期对业务的技术影响不容忽视。我们已经看到，保险公司正在提供数据保护网络保险，并寻求答案，以帮助量化违规风险和保护质量。我们看到出现了影响技术采购和选址的法规讨论。即使企业向开源社区交纳了数十亿美元的研发费用，安全责任和影响的问题仍在继续。

就内部而言，内部团队将必须优先考虑安全卫生和公司范围内的最佳实践。DevOps团队可能会抵制这些更改，因为他们必须获得新的技能才能安全有效地管理DevOps和CI / CD流程。但是，您的总体安全状况取决于每个人在安全意识，维护等方面的了解。

为了跟上快速CI / CD工作流中业务和技术转换的协调，安全必须适应云。它不仅必须部署在新技术体系结构的关键领域，而且还必须与新的业务实践集成。安全性必须与云本身一样灵活，响应迅速，功能强大且集成在一起。

谁负责云安全？

向云迁移的最明显转变是外包。您的物理硬件和数据基础架构不再完全由您掌控。当数据通过基础架构即服务（IaaS）或平台即服务（PaaS）传输时，谁负责安全性？

与云提供商合作将安全责任划分给云提供商和内部团队之间。内部团队需要了解他们负责保护总体解决方案的哪些部分以及确保这些解决方案安全的最佳实践。

总体而言，云提供的功能和敏捷性正在加快开发周期，使安全性与新变更分开存在。因此，对于开发周期而言，包括安全性基础结构和最佳实践很重要。

诸如不知道专注于安全性的基础结构层之类的简单操作可能会导致数据泄露。根据Verizon的《 2019年数据泄露调查报告》，内部员工的失误占所有数据泄露的34％。这些违规行为给组织带来了财务和声誉损失，这些损害往往无法挽回，尤其是对于中小型组织。

技术解决方案还可以帮助您了解DevOps工作流程的紧迫性，并将安全测试和解决方案集成到工具链，工作流程和流程中。但是，这些工具和解决方案最终将依赖DevOps内部的安全任命人员，而不是单独的安全团队。

云提供商的安全责任与客户端责任的分担

与公共云提供商合作的主要好处之一是，他们非常重视安全性和合规性。云提供商在保护云环境方面投入了大量资金，以确保它们与本地环境一样安全。公共云提供商对服务器位置，硬件本身，主机操作系统和虚拟化层进行物理访问安全性管理。简而言之，就是提供服务的基础架构。

DevOps团队负责保护公司数据，操作系统，应用程序逻辑和端点。与云提供商共享安全责任可以减轻管理负担，但重要的是使正在进行的维护成为正在进行的CI / CD流程的一部分，而不是仅依靠云提供商来进行处理。还值得一提的是，使用开源组件的开发人员必须维护这些资源，以确保不会引入漏洞。这可以通过运行发现来识别和跟踪所有开源组件来完成。

为了提供适合各种组织特定需求的服务，云提供商提供了几种云计算模型，包括软件即服务（SaaS），平台即服务（PaaS）和基础设施即服务（IaaS）–每个涵盖不同数字解决方案的级别和相应的安全性。

根据云标准客户委员会（CSCC），随着从SaaS到PaaS再到IaaS的用户责任趋于增加。

使用SaaS模型的团队在安全性方面的参与最少，因为他们使用的是预先设计的服务，而云提供商则负责处理所有技术方面的问题。这意味着他们可以依靠提供商来管理基础结构，软件堆栈以及大多数相关的应用程序逻辑。

有关安全性所有权和职责的完整列表，团队应检查其首选的云服务提供商的服务级别协议。一旦团队清楚地了解其安全职责，他们便可以将时间集中在保护自己拥有的组件上，并放心其云提供商将处理其余组件。此类策略的一个很好的例子是AWS的分担责任模型。它清楚地记录了客户对其AWS基础架构中的数据，API和软件堆栈的责任。

在云迁移的安全解决方案中寻找什么？

依靠云提供商以他们从未申请过的方式进行监视和保护，这对组织安全是一个巨大的挑战。让我们以AWS为例。作为最古老的IaaS提供商，AWS奠定了基础，并花费大量资源来培训客户。亚马逊严格遵守服务规定。他们采取了令人难以置信的措施来确保其提供的物理设施和技术。因此，公司通常不必担心网络安全性，服务器或路由器之类的问题。但是，亚马逊也非常清楚，应用程序所有者对其他组件负责。

正如亚马逊对云安全负有共同责任的立场所解释的那样，他们负责该系统。但是，应用程序中的数据，与用户相关的安全性以及人们与应用程序的连接方式不在他们的管辖范围之内。甚至有一个论点是，试图确保这一点将等于公司超支或阻碍了进展。

仅仅相信应用程序和微服务将由开发人员和提供者保护是不够的。您必须确定自己的软件解决方案在发生最多更改和数据的逻辑级别（API级别（第7层））上是安全的。寻找：

• 在应用程序级别部署的工具

• 在您的CI / CD中起作用的解决方案

• 集成工具集和流程不会增加资源需求

• 自动化，可灵活应对

这是安全管理云并将您的业务迁移到功能强大且灵巧的解决方案中的一部分。

启用安全性的API和微服务为公司提供了必要的灵活性，以随着云进行扩展和增长。无论您是决定补充现有技术堆栈，还是完全迁移到新一代的容器和微服务，我们都将重点放在如何管理新动态基础架构的方式，位置和方式上。这是需要新的治理流程和自动化策略的地方。展望未来，云是业务中功能最强大且不断发展的单一变压器。

安全必须适合于业务功能的特定条件和特定的环境才能有效。这并不总是意味着乏味的自定义，而是意味着您需要可以适应您自己的基础架构，业务逻辑和流量并从中理想地学习的解决方案。在更深层次上安装的机器学习可以使您的业务与众不同，这可以确保这一点。

鼓励DevOps与安全团队之间的合作

在技术影响之外，云将需要在组织上进行新的重组。例如，如果您的职责是管理云，那么组织结构图是什么样的？谁应对风险形势负责？CISO和CTO的角色如何变化？它还将改变安全专家如何适应您的组织结构。

传统上，开发，运营和安全团队都是孤岛工作。随着开发和运营合并到统一的DevOps实践中，问题是DevOps是否会从根本上削弱安全性。在DevOps中，开发的速度是决策制定的重中之重，特别是在使用外部软件和平台时，而安全性通常是事后才想到的。随着新威胁和漏洞的引入，威胁形势正在迅速变化，这一挑战进一步加剧。

期望开发人员成为一夜之间的安全专家是不现实的。但是，随着应用程序开发速度的提高，以适应当今企业所需的速度和敏捷性，许多组织并未在其产品中构建安全性。

为了解决此问题，DevOps和安全团队将需要合作，以便在开发生命周期的开始阶段就纳入安全性。

为了最好地整合角色，应考虑一些关键的最佳实践：

• 考虑质量检查。最重要的是要建立一种文化，将安全视为优质产品，共同责任和重中之重。与应用程序性能和用户体验一起，它应被视为关键的应用程序指标之一。

• 将安全性集成到DevOps中。让安全团队参与或在DevOps流程的所有部分中指定安全角色，以确保从一开始就保持透明和协作；安全团队可以检测特定于应用程序的漏洞，并提供可行的DevOps建议，这些建议将为安全的编码实践提供依据。

• 启用开发人员。由于大多数开发人员对要寻找的内容的了解有限，因此在团队中任命安全支持者非常好。他们可能不具备与白帽黑客相同的深入知识，但是他们将在安全方面有足够的参与和了解，以了解概念并知道在哪里寻找正确的工具和资源。

• 获取正确的工具和工具链。部署可以管理安全任务的自动化工具，以使小型安全团队能够将更多精力集中在关键优先事项上，例如定义框架和将精力更多地放在开发流程上；在云中以及CI / CD流程中自动生成并运行安全测试的工具将有助于实现这一点。

• 加强编码。最后，许多安全问题来自最明显的错误。组织需要投资培训培训开发人员以在云中安全地进行编码，并将安全测试纳入流程的一部分。通过机器学习监视代码的高级安全解决方案可以发现代码中的漏洞模式，从而帮助开发人员增强代码健康度。