我们常会看到关于数据泄露或系统故障的新闻故事,这些事件是由人为错误或外部实体的某种类型的攻击引起的?如果您在受影响公司的 IT 部门工作,直接和间接的影响可能是显著的,而这种影响在整个 IT 行业中都是显而易见的。让我们考虑一些数据点:Splunk 在其 2023 年的安全状态报告中指出,攻击的复杂性是 38% 受访者面临的最大挑战,28% 的人由于工作负荷过重而陷入反应模式。IBM 的 2023 年安全漏洞成本报告发现,数据泄露的平均成本为 445 万美元,比三年前增加了 15%。这样的统计数据显示,攻击的复杂性和数量以及报告的漏洞正在不断增加。随之而来的是数据泄露和财务影响的风险增加。这里的答案不是放慢脚步,而是更智能地工作。
大多数公司在过去十年中一直在现代化并将业务应用和服务迁移到混合云,以便能够更快地行动并变得更加灵活,因为今天的需求比以往任何时候都要大。更有甚者,我与几乎每位客户交谈时,他们都在努力应对其环境的复杂性,随着边缘计算、人工智能等技术的增加,这种局面还看不到尽头。
这对您整个企业的 AI 工作负载意味着什么?现在,您正在处理大量数据,还在运行或希望运行对技术基础设施要求极高的基于 AI 的应用。如果您没有自动化解决方案的管理,这将是一个非常具有挑战性的场景,因为手动流程可能会使 AI 解决方案和创新的进展变得缓慢。
满足合规需求并推动关键工作负载的操作一致性
在这个现在包含人工智能的复杂环境中,您仍然需要遵循内部和外部政策来控制成本、降低风险并保持一致性,以便在尽力保持灵活的同时。需要进行内部和外部的治理、风险和合规(GRC)管理——但自动化是更智能的方式,这也将帮助您保持灵活性。
通常,您的关键任务系统要么为您的组织创造收入,要么提高生产力,或者帮助您控制流程,它们往往是受到内部和外部合规指令影响最大的系统。它们必须保持安全、高效且可审计,违规情况要少,且补救流程要良好。所有这些都需要时间和额外的工作周期,以确保每项强制性要求都得到解决。审计员和评估师也需要信息,这会进一步占用构建和运行关键应用程序的时间。最终结果是团队中每个角色的挫败感,以及从开发到测试再到生产的速度和效率缺失。
在内部和外部 GRC 过程中,如果您能够:
- 用自动化和无缝的检查替代繁琐且缓慢的手动验证流程,这些检查在采取行动之前就会发生。
- 通过快速、高效的自动化流程来扩展合规性。
- 为您的整个团队提供简化的体验,帮助团队专注于关键责任,并提高对流程的整体满意度。
通过将政策作为代码进行自动化,是帮助您在管理复杂性、降低风险的同时保持合规的最佳实践,并能够快速灵活地部署要求高的人工智能及其他应用程序,商业利益相关者对您团队的期望就是如此。通过自动化的政策作为代码,您能够更好地保持在混合云计算中取得的进展,同时改善整体 GRC 状态。
当您能够以可预测和无缝的能力应用政策时,您将对自己的技术栈更有信心,因为您的操作更加一致。技能差距对您的运营的影响将减小,您可以帮助减少人为错误,而人为错误往往是导致数据泄露和问题的源头。自动化政策作为代码可以帮助您解决团队面临的生产力消耗。
在整个生命周期内实现策略即代码自动化
通过自动化政策即代码,您可以以更好的方式进行设计,使验证和合规政策检查变得无缝。红帽 Ansible 自动化平台是客户用来在 IT 过程中进行自动化以实现速度、效率、灵活性和当然还有投资回报率的常见自动化平台。它是一个高度灵活的解决方案,可以自动化几乎任何您能想到的 IT 过程——这也包括自动化政策即代码。您的团队可以使用自动化的政策作为代码进行:
- 创建:在开发周期中自动检查政策执行,使开发人员能够无缝创建合规的开发和测试平台,并在生产环境和代码中从一开始就建立合规性。确保您的团队能够在不耗时的会议和手动双重检查的情况下应用所有适用的政策。
- 管理:根据需要集成政策执行,例如在自动化作业运行之前或之后包含的自愿或强制政策检查。当您的技术栈中的技术不合规时接收警报,或根据需要自动响应。确保云和其他技术实例符合您的配置规范,以便您能够控制成本并确保一致、可信的操作环境。轻松识别可能受到政策变更影响的库存,然后自动应用更改。
- 扩展:自动化报告和输出到审计相关系统,减轻与报告相关的整体团队负担。
您可以通过在 Ansible Playbook 中包含政策来立即自动化政策作为代码。这些可以手动执行或通过自动化控制器执行。当您添加事件驱动的 Ansible(Ansible 自动化平台的一部分)时,您可以自动化端到端响应,例如当政策偏离时,您的可观察性或监控工具标记此偏离并/或在您的自由裁量权下进行修复。
为完全自动化的政策即代码做好准备
这一切听起来不错,但您如何在大规模和跨组织中实现这一目标?以下是一些准备的方法:
- 扩展您的自动化使用。您的团队(网络、云、基础设施、安全、应用开发、SRE 等)中有多少正在使用单一一致的自动化平台?当您扩展企业级自动化使用时,您可以在各个领域内进行自动化,以便政策能够在整个技术栈中保持一致。这个想法是,您已经扩展了自动化,可以在关键任务工作负载或应用程序中实施自动化政策作为代码。
- 模块化并集中自动化在“即代码”模型中。您的政策能否以供应商无关的方式编写,以便可以集中并应用于特定供应商解决方案或包含在 Ansible Playbook 或 Ansible Rulebook 中?识别一个中央存储库,用于存储您希望一致使用的标准配置文件、剧本和其他自动化资产。这是一种基础设施即代码和/或配置即代码模型,它为您提供了更多的组织,从而添加政策作为代码的自动化。
- 评估您的自动化合规需求并调整您的团队。识别您必须满足的关键合规和安全要求,然后制定包括关键里程碑和目标的路线图。召集您的团队,创建对目标、收益、角色和责任的共同理解。为运营做好准备,例如,所有政策在用于部署工作流之前都已实施和测试。
- 提前思考监控和执行。一旦您的关键应用程序和工作负载上线,确定如何监控和响应政策违规行为。一个选项是使用事件驱动的自动化立即响应,而无需手动干预,以应对安全风险或导致风险的配置更改。
- 委任一个自动化实践社区的领导者。红帽多年来一直推荐这种方法,以促进和扩展自动化的使用。该领导者可以解决自动化问题,并帮助您启动自动化政策即代码。《自动化架构师手册》将为您提供一些想法,帮助您组织内部社区。
开始使用政策即代码:从小事做起,从大处着眼
无论您在旅程的哪个阶段,自动化政策即代码都可以帮助您实现 GRC。由于合规要求您覆盖支持应用的整个技术栈,因此考虑扩展自动化,并达到从单一真实来源进行自动化的程度。如果您还没有达到这一点,您仍然可以自动化政策,但它们可能更具内部性质(例如,特定版本的 Linux 必须应用特定的安全政策才能在您的环境中运行)。
红帽的整体方法是从简单的用例开始,然后逐步扩展范围和复杂性。政策即代码可以以这种方式实施。例如,您的用例可能是:
- 收集不符合特定政策的系统的库存报告。
- 应用运行时策略,例如“防火墙只能在特定端口上打开”。
- 创建云实例,大小不得超过特定限制,以控制云成本。
- 自动化对给定服务器的更改,除非该服务器在维护窗口内。
一旦您能够围绕政策即代码实施简单的用例,您就可以扩展到更高数量和更复杂的用例。
现在您已经了解了红帽对自动化政策即代码的观点,希望您能考虑这一领域,以及如何利用它来简化繁琐且耗时的流程。我最后要提醒您,Ansible 自动化平台具有高度灵活性。一旦您知道自己想要实施的内容,该平台在执行您所期望的操作时表现出色,包括在政策即代码方面。最好的还在后面,政策即代码将成为贯穿整个生命周期更简单、更聪明的工作方式。
关于作者
Richard is responsible for the Ansible Automation Platform strategy. With more than 16 years of experience in Financial Services IT across a range or operational, design and Architecture roles. As well as being an Ansible customer before joining the Red Hat team, he brings a customer focused viewpoint to compliment the strong engineering capabilities of one of the most popular open source projects.
产品
工具
试用购买与出售
沟通
关于红帽
我们是世界领先的企业开源解决方案供应商,提供包括 Linux、云、容器和 Kubernetes。我们致力于提供经过安全强化的解决方案,从核心数据中心到网络边缘,让企业能够更轻松地跨平台和环境运营。