四个措施打造安全的DevOps流程

本文最初发布于Clemens Reijnen的博客，经原作者授权由InfoQ中文站翻译并分享。阅读英文原文：The 4 focus areas of DevSecOps。

\\

DevOps可以让系统更安全。也许很多人并没有这样考虑过：采纳DevOps及其快节奏的发布方式，有助于塑造更坚固的系统，不仅可以更好地符合安全准则要求，同时也可以更好地抵御新兴威胁。

\\

摘要

\\

任何团队在工作过程中都必须遵守和采纳各种安全准则与实践，这种工作方式必须以高度自动化的方式实现，并由机器学习技术以及“角色扮演”加以支持。

\\

首先，各种业务都会对系统提出灵活度、创新、低成本、合规以及安全等共同的需求。过去，这些需求相互之间需要进行权衡。快速、灵活和创新，这几个需求从来不能与合规与安全并存。但在最新的开发实践、工具和平台帮助下，我们已经不再需要这样的权衡了，在工作中，遵照安全DevOps（DevSecOps）方式的团队将能更好地交付并运维安全的系统。

\\

为了获得足够安全的系统，DevOps团队和相关业务需要专注于下列几个领域：

\\

自动化、机器学习、平台以及文化。

\\

自动化技术有助于快速交付和验证可靠、可重用的系统。作为新技术，机器学习有助于我们分析理解系统行为。平台的种类和能力各不相同，其中很多已经具备了必要的安全能力。文化的诞生则以自动化、平台能力以及机器学习技术为土壤，如果整个公司没能形成恰当的心态，那么其他所有应对措施都将一无是处。

\\

正如DevOps Handbook一书在第22章所述：

\\

\\

\

坏人们已经在通过持续交付的方式开发恶意代码。如果遵循DevOps模式，安全响应速度也会变得更快。
\DevOps范式变迁也许能为安全专家提供一个机会，借此真正将安全性融入IT流程中，而非像马后炮那样事后挽救。

\

\\

自动化

\\

当整个团队及业务已经适应了以尽可能高的频率发布后，如果某个功能或补丁已经就绪，哪怕一天发布多次也可以顺利接受，那么系统的安全性也将大幅提升。

\\

自动化是让团队能够按照需要尽可能频繁发布的关键。整个系统由始至终的每个环节，以及每个环节之间的验证过程都应自动进行。借此团队可以在检测到安全问题后尽快发布安全补丁。

\\

自动化配置是一方面，验证工作也必不可少。系统创建和配置过程中执行的每个活动都需要进行验证。

\\

我们的代码需要进行足够全面的单元测试，每次构建过程中都需要测试。不仅手工编写的代码要验证，所使用的软件包同样需要。软件包和框架组件几乎都是开源的，为了了解这些开源组件是否有漏洞，需要在每次进行自动化构建的过程中，使用专门的工具扫描所用到的软件包。Sonatype、Whitesource、Flexera等工具均具备这样的功能。

\\

关于自动化还有一则金科玉律：所用到的每个工件都应进行版本控制，但相关机密不应包含在内。机密信息绝对不能存储在Git代码库中，哪怕仅仅是开发和测试环境所用的机密信息，因为这些信息同样可以很容易被用于追踪生产环境的路径。

\\

目前已经有很多工具和构建步骤可以在每次进行构建时验证代码中是否包含任何类型的机密信息，例如微软免费提供的CredScan。

\\

自动化漏洞扫描是必不可少的一环，同时也是除了自动配置之外，DevOps为系统开发工作提供的另一个重大收益。任何系统的自动化发布管道都必须与OWASP Zed Attack Proxy Project和Micro focus Fortify这样的漏洞扫描程序集成。

\\

\\

通常来说，自动化是DevSecOps所关注的最主要领域。快速交付与自动化验证有助于保护系统安全。此外很多进入DevSecOps市场的工具供应商也开始涉足自动化这一领域，这也有助于让相关技术快速成熟。

\\

机器学习

\\

为了知道系统何时被攻击，系统行为是否有所变化，首先必须明确系统的默认行为。很多时候，很多公司根本不知道自己被攻击了，往往只能在自己的数据被公开后才意识到实际情况。有时候甚至黑客都会忘记自己曾经攻击过哪些系统。

\\

捕获日志数据，监视整个系统及其组件和业务职能，这些仅仅是入门措施。目前有很多实用的日志工具，可以帮助我们监视从传统系统到大型基于服务的系统，以及这其中的一切系统。

\\

日志捕获以及可视化工具可以在机器学习技术的帮助下获得更多功能，这样做的理由也非常充分。数量众多的小规模日志数据中往往蕴含着丰富信息，通过对这些数据运用机器学习技术，可以更好地提升系统安全性。

\\

对很多云提供商来说，类似功能早已成为自己产品的标配。微软就将自己的Azure云定位为一种智能安全云，Azure的很多服务都应用了机器学习技术。例如Azure Active Directory Identity Protection会使用这种技术识别被攻陷的标识：

\\

Azure Security Center会使用机器学习技术理解租户订阅中所运行的应用程序产生的不同行为，借此判断应用程序是否被黑客攻陷。

\\

https://azure.microsoft.com/en-us/blog/how-azure-security-center-uses-machine-learning-to-enable-adaptive-application-control/

\\

创建监视系统，针对监视工作配置整个环境，创建可保护系统安全的机器学习算法，这些都是DevOps团队的主要任务，绝不能事后才加以考虑。

\\

\\

将机器学习技术与自动化技术结合在一起，当系统被黑客攻击后实现自愈（自防御），这样的场景距离我们并不遥远，只不过目前还无法实现。但如果算法针对系统用故障得出错误的结论，那么结果就无法让人满意了，例如自动化的股票交易系统，当股票价格自发下跌时算法给出错误的结论……

\\

平台能力

\\

平台有多种形态。对于云计算，平台可分为IaaS、容器、PaaS、无服务器以及SaaS。每种平台都有独特的特性与能力，能为业务系统带来独有价值。此外每种不同风格的平台也有不同安全特征，需要不同类型的保护。

\\

从安全的角度来看，被传统网络包围的IaaS，其受保护程度可能相当高。关于如何配置此类环境，我们已经有了太多经验。相比云原生系统，例如PaaS和无服务器，默认情况下根本是“没有网络”的。

\\

云原生系统需要通过身份验证、加密以及其他技术措施应用不同类型的保护。例如在连接Azure WebApp和SQL PaaS数据库时，仅仅通过HTTPS连接发送包含用户名和密码的连接字符串是不够的。这种通信最好能通过Azure Active Directory身份验证或使用证书以及Azure密钥保管库服务加以保护。这样做更安全，但也有更多相关工作要做，因为平台需要这些工作。

\\

平台还应提供易于配置的功能，这样才能借助平台提供商提供的不同机制更好地保护整个平台。

\\

\\

AWS WAF规则是一系列默认功能，可用于保护Web应用程序防范黑客利用漏洞发器攻击，获取服务器控制权，或DDoS攻击。

\\

诸如容器技术等其他类型的平台在安全方面也需要进行权衡。容器可以轻松地在流程的不同阶段共享，为此只需共享容器主机的Hypervisor即可。规模越小的容器就越容易分发，但是内存超载可能会导致数据泄露至其他实例。Windows Hyper-V容器通过内核级别的隔离解决了这一安全问题，借此，容器的规模可以大幅增加。

\\

\\

应用各类平台的企业在为自己的本地或云端的基础架构选择平台时，需要考虑这些问题。

\\

合规的平台

\\

为了让所选平台能够符合管控要求，平台必须以特定的方式配置并使用资源。例如微软就基于Azure为不同的合规需求构建了多个参考架构。

\\

Azure Blueprint Automation：适用于受管控工作负载的金融服务蓝图。

\\

云端CoE和服务目录

\\

企业需要在云平台的基础上搭建出此类合规的平台，此外其他功能与配置也需要符合公司的安全规则。为了在保持合规的情况下上云，以最大化用量和速度交付业务价值，业务单位必须具备云卓越中心（CCoE，Cloud Center of Excellence）。

\\

在接受云技术的同时专注于价值的交付和反馈，有助于实现更灵活、低成本、创新、安全的业务。这两者的结合可以看作变革的催化剂。

\\

云CoE是一种服务和实践中心，需要针对云系统涉及的云平台、设计、交付和运营有着深入和广泛的理解。理解的广度以及与开发和运维知识的深度结合将使得云CoE成为业务创新的加速器。

\\

自动化、模板、实践、解决方案以及服务能够对组织上云过程提供支持。云CoE还必须通过这些工件为业务单位提供适合的服务目录。

\\

服务目录、平台以及业务项目的具体实现如下图所示。黄色的区域中，服务目录团队提供的工件可被业务团队（紫色）所使用，而平台团队（蓝色）也可以使用相同的服务目录工件构建并发布合规的平台。

\\

\\

借助服务目录中提供的拆箱即用解决方案和自动化脚本，不同团队可以立即专注于业务职能本身。配置与运维实践可以确保系统时刻准备就绪，可以立即投入运营，并具备直达业务层面的反馈环路。

\\

AWS提供的服务目录服务可以追踪服务目录内不同产品的生命周期，并提供目录访问能力。

\\

平台的持续合规

\\

在整个生命周期内，需要对平台、服务目录以及业务项目进行不断的合规性监视，为此需要用到一些安全框架，例如NIST、CIS/SANS 20或ISO 27001，但这是个很麻烦的任务。

\\

妥善设计和运维的云平台能够与很多框架保持合规，因此可以让业务项目、服务目录和企业的整个平台继承某些合规能力。但持续的监视依然不可或缺。

\\

Azure Security Center可以持续监视整个平台可能存在的威胁和漏洞，此外可配置策略确保满足不同安全框架的合规要求。

\\

\\

在这些安全策略的基础上，很多提供商还会通过额外的功能实现审核与合规性管理能力。这些产品通常会通过不同平台的“应用市场”提供。

\\

Azure Marketplace围绕关安全性与合规提供的产品：

\\

\\

AWS与Allgress的合作

\\

https://aws.amazon.com/config/partners/allgress/

\\

平台和工具可以帮助我们维持与不同安全框架的合规性，借此提供必要的支援并降低合规工作的复杂度。

\\

文化

\\

选择订阅某种云服务，实现自动化交付，配置平台的合规选项，然后从系统行为中不断学习，仅仅这些还不足以打造足够安全的平台。获得真正安全的环境，这需要整个组织、所有人员、全部流程以及整个组织的文化心态均以安全为中心。云技术与DevOps方法的配合可以提供强大的能力，可以更好地保护业务系统的安全。但是为了从中获得最佳效果，还需要具备清晰的结构化安全方法。

\\

如果问“我的组织中最薄弱的环节是什么”，可能会获得各种有趣的答案。从文件共享的管理密码到测试过程中使用的生产数据，这些古老的习惯都会降低整个环境的安全性。

\\

让整个组织全面关注安全性，这是个不小的挑战，并且会面临大量障碍。安全的DevOps实践，例如自动化以及来自运维工作的反馈环路，这些有助于帮助我们消除大部分壁垒，但依然有更多实践等着我们去采纳。

\\

企业需要开始采纳“网络安全战争游戏”这样的实践，让一个团队尝试着攻击系统，并让另一个团队进行防御。

\\

这样的“游戏”可以带来双倍的收益，可以让团队学着面对入侵做出更快速的响应。这一过程中可增加警报、日志信息等内容，并通过优化机器学习算法让团队面对黑客变得更敏捷。另一项收益其实也很明显，可以在坏人发起攻击之前找出内部的薄弱环节。

\\

为了让整个公司提高安全意识，还可以在公司内部进行钓鱼攻击演练，并将令人震惊的结果告诉所有内部人员。

\\

总结

\\

安全工作是公司内部所有人共同的责任。DevSecOps所提倡的自动化、机器学习、平台以及文化等实践应该在公司内部广泛采用。但是依然要注意，黑客攻击的演进速度极快，他们的思路也截然不同。我们应当加快自己的步调，弄清楚自己何时被攻击，并尽快对攻击做出响应，只有这样才能赢得这场安全战争。

\\

感谢张婵对本文的审校。