介绍
许多公司正在转向DevOps方法，在该方法中，软件部署和生产环境的持续运营都被纳入了软件开发生命周期。 在准备好将软件发布到生产环境中时，DevOps并没有将完整的代码从开发到操作丢到整个墙壁上，而是将发布到生产中的过程整合到整个发布过程中。 这通常依赖于具有可编程基础结构，例如云和软件定义的网络（SDN），因此整个环境都定义为代码。 仅云基础架构平台可满足此要求。
通过使用DevOps，公司可以比以往更快地移动。 凭借云的动态，快速变化的本质，IT，运营和安全性的主要利益相关者很难保证遵守合规性企业策略。 应用以发现为重点，事件驱动的自动化方法，可以为组织提供他们需要的配置控制，以确保在云中的安全。
DevOps快速概述
DevOps是一种在新版本可用时快速部署软件的方法。 DevOps的主要目标之一是帮助组织快速发展。 新版本将尽快向现实世界的用户，客户和使用人员公开，并对其功能和价值进行测试，以增加应用程序的收益。 大多数组织将云基础架构用作其DevOps团队的操作环境。 简化的过程可能包括以下步骤：
- 提交代码。
- 自动打包应用程序以进行部署。
- 运行一组用于代码检查的回归测试，以及用于生产环境就绪性的冒烟测试。 运行其他测试，例如安全/漏洞探测。
- 根据测试结果：
- 测试失败：为开发，运营和安全团队生成警报和日志。 返回编码。
- 通过测试：自动投入生产。
- 在生产中运行，直到下一个版本。
从头到尾的整个过程通常称为DevOps例程或剧本。
但是，并非所有DevOps团队都知道如何正确配置基础架构，以符合组织的安全性和合规性要求。 为了增加复杂性，大多数DevOps方法包括以下针对任何问题的缓解机制：恢复整个环境。 DevOps剧本几乎总是包含回滚机制。
图1. DevOps剧本
由Medrecs（自己的作品）[CC BY-SA 4.0（http://creativecommons.org/licenses/by-sa/4.0）]，通过Wikimedia Commons
DevOps的云
由于许多原因，云在作为DevOps方法的基础结构方面具有独特的地位，其中包括：
- 云是软件定义的； 它是可编程且灵活的。
- 云是软件驱动的，具有许多不同的层。 客户负责每一层，并且必须进行设计，从网络配置到服务帐户和凭据，再到数据保护和加密设置。
- 云基础架构通常按实用程序式按需付费模式计费。 这意味着可以独立确定应用程序的总运行成本，并且公司可以进行准确的ROI测量来确定应用程序的价值。
云采用
大多数组织认为他们可以像使用IT基础架构一样使用云基础架构，即通过一个集中的IT团队。 但是，诸如服务目录，供应模板和有限的控制台访问之类的方法在规模上会失败，因为不同团队的需求过于多样化，并且IT部门很难跟上他们的步伐。 最终，大量采用云技术变得分散，许多团队访问了云基础架构。 这就带来了根本的问题：并非所有这些团队都是基础架构专家。 而且许多人根本不了解或不了解组织的安全要求，或者不知道如何在软件定义的云环境中实现它们。 再加上大型企业，业务部门，分布式团队和各种合规性机制的复杂性，此问题变得越来越难以大规模管理。
DevOps解决问题的方法
许多DevOps团队可以自动化新应用程序和应用程序版本的部署和回滚。 因此，如果他们发现问题，则整个环境将被拆除。
这种彻底的拆除通常意味着环境停机，然后进行详尽的根本原因分析。 尽管这是提高组织长期发展水平的好方法，但它对即时应用程序可用性提出了挑战。
第二个挑战是测试覆盖范围可能不包括做出保留与回滚决策所应考虑的所有条件。 测试通常侧重于应用程序行为，代码正确性，有时还包括安全评估。 开发团队倾向于主导DevOps组，但他们可能缺乏检查基础架构优化或配置的背景。
部署一套安全和配置控件（有时称为护栏 ）可以为主要执行干系人提供保护和安心，使他们需要DevOps团队快速运作，而不会给组织带来风险。
DevOps的安全感知
大型组织对DevOps的主要关注是缺乏安全重点。 这通常是一个有意识的权衡：让DevOps团队Swift行动，因为他们正在为组织开展重要的新业务。 但是，通常会牺牲安全性，以使团队及其环境不受限制。
云安全
DevOps的安全感知如此消极的原因之一是，对于云基础架构，可能难以管理需要编程的安全控制和配置的数量。 在一个简单的云应用程序体系结构设计中，至少有十个独特的控件可以正确实现和配置。 一些例子：
- 是否为所有基础架构资源启用了云审核日志？
- 防火墙规则配置正确吗？
- 是否在正确的时间使用SSL证书？
- SSL证书是否有效且不受已知漏洞的影响？
- 是否正确使用了服务帐户并为服务启动提供了安全保护？
- 服务帐户是否具有适当的权限，策略和密钥轮换？
- 子网的大小是否合适？
- 是否正在使用和正确配置网络访问控制列表（ACL）？
- 是否在需要的地方对静态数据使用加密？
- 是否在使用途中加密并在需要的地方正确配置了加密？
- 应用程序层之间的通信是否通过服务帐户得到适当保护？
- 是否使用适当的权限集对固定资产进行适当的保护？
图2.示例云架构
图片来源 ：DivvyCloud; 经许可使用
需要什么控制？
组织采用云计算时面临的主要挑战之一是定义他们想要为云环境制定的策略和标准。 这些要求可能因应用程序而异，并且通常来自多个利益相关者。 例如：
- 生产环境可以具有最高级别的安全锁定：
- 所有管理员帐户都需要MFA
- 只允许打开防火墙端口443
- 必须启用审核跟踪
- 测试和开发环境可能专注于控制成本，但不允许组织外部进行任何访问：
- 云网络上没有ACL，但没有公共Web访问
- 没有超过8个核心的实例（混合成本控制和强制性重点放在向外扩展而不是向上扩展）
- 任何基于计算的实例，数据库或存储量的最长使用期限为30天
- 后台应用程序可能需要重新连接到公司网络，并且：
- SSH访问必须对公司网络IP范围开放
- 每天备份四次数据库
- 通过VPN路由的所有IP流量
客户可以使用不同的工具来放置这些配置控件，这些工具的范围从每个云提供商的可用工具到开源检查工具或商业软件。 这些工具可以检查发现的问题并采取措施。 除了可以普遍应用的全局策略之外，组织还可以使用标签，命名约定，云区域或帐户位置来确定哪些配置控制集适用于每个应用程序或工作负载。
安全要求也可能来自不同的来源。 例如，在前面的示例中，可能的涉众是：
| 控制 | 利益相关者 |
|---|---|
| 仅端口443流量 | 安全团队，CISO，SecOps |
| 没有实例超过八个核心 | 财务，首席财务官，首席信息官 |
| SSH访问公司IT范围 | 运营团队，IT，TechOps |
| 数据库备份 | 运营团队，TechOps，CIO，DR团队 |
图3.覆盖业务部门策略以及应用程序，项目或产品特定策略的公司范围策略
图片来自DivvyCloud; 经许可使用
云自动化中通常成功的方法是从可见性开始。 拥有一个持续监视和盘点云环境的工具不仅有用，而且对于确保根据这些控件评估所有云基础架构而言都是必要的。
一些组织依靠从各种部署工具收集此清单，这些工具应在启动新应用程序时“签入”。 另一种方法是使用服务器代理报告回中央清单。 这两种方法都依赖于已安装，正确配置且可访问的代理或部署工具。
一种替代方法是使用云API层对环境执行详尽且重复的查询。 虽然这始终导致完整的基础结构可见性，但它的权衡是无法深入查询操作系统或应用程序层。 因此，许多组织采用组合方法并使用API合并数据。
发现基础结构后，将为每个虚拟机，应用程序，网络，存储资产和工作负载识别并评估适用的配置控制。 当发现问题时，客户有两种选择：接收通知并做出React或设置预定的自动化措施以近乎实时地采取措施。
一个简单的例子是：
- 客户采用了一种控制机制，该机制禁止通过SSH访问生产虚拟机。
- 一个新的应用程序投入生产。 该应用程序定义了一个云网络环境，该环境无意间将端口22开放给世界。
- 云自动化工具会发现新应用程序，并确定它是生产环境。
- 这些工具将新应用程序与适用的生产策略进行比较，并确定存在问题。
- 客户具有预定义的响应，该响应将创建通知，将事件记录到审核跟踪并关闭防火墙端口。
在应用DevOps和更广泛的云采用时，这使关键执行干系人既安全控制又省心。 这两个因素共同可以帮助组织敏捷和快速发展。
图4.云配置控制流程图
图片来源 ：DivvyCloud; 经许可使用
结论
云使组织能够快速移动。 除了潜在的成本节省外，真正的价值是云所允许的敏捷性。 客户可以前所未有的速度构建，修改和拆除环境。 通过将软件定义的基础架构与应用程序发布管道相结合，公司可以实现真正敏捷的DevOps发布方法。 这极大地缩短了发布之间以及发布和接收实际用户数据之间的时间，从而导致了持续的应用程序改进。
尽管云具有潜在的变革性，但实时性和对基础架构的更广泛访问为安全性，成本控制和策略合规性等关键利益相关者带来了一系列新挑战。 使用以发现为重点的监视工具可以检查和执行控制措施，可以帮助消除有关云采用的关键问题。 组织可以安全地通过云更快地前进。
翻译自: https://www.ibm.com/developerworks/library/d-devops-cloud/index.html
2002
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
