IaC 扫描：一个被忽视的绝佳学习机会

您阅读的有关基础架构即代码 (IaC) 的所有内容都集中在它的工作方式或您为什么要确保它确实按照您希望的方式构建。

这些是关键领域。 但是我们是否充分考虑了如何在我们的组织中使用这种方法？

As 梅琳达马克斯 ESG 在一份公司报告中指出，随着他们继续采用该技术，“83% 的组织经历了 IaC 模板错误配置的增加”。

我们从云安全联盟所做的工作中了解到（“云计算的主要威胁：令人震惊的十一“) 和其他人一样，错误配置仍然是云中的首要风险。

IaC 支持 减少
通过将基础设施的创建系统化，增加一定程度的严谨性和流程来确保团队构建他们想要的东西并且只构建他们想要的东西来减少配置错误。 如果约 83% 的团队没有看到这一点，则说明存在更深层次的问题。

在较小的团队中，DevOps 哲学的 Dev 和 Ops 部分在一起，这是有道理的。 IaC 允许这些小团队使用相同的语言——代码——来描述他们所做的一切。

这就是为什么我们看到比 Terraform 或 AWS CloudFormation 等工具更高级别的抽象 AWS CDK 和像这样的项目 cdk8s. 这些高级抽象对开发人员来说更舒服。

云服务的运维/SRE/平台视角与同一服务的开发者视角截然不同。 开发人员将查看队列服务并深入了解其界面——添加一个简单的端点并读取一个端点？ 卖。 这是一个简单的集成。

这种操作视角旨在找到优势。 那么，这个队列什么时候达到它的极限呢？ 性能是恒定的还是在负载下发生根本变化？

是的，存在重叠的问题。 是的，这是一个简化的视图。 但这个想法成立。 IaC 解决了很多问题，但它也可以创建和放大团队之间的脱节。 更重要的是，它可以突出您尝试构建的意图与您已构建的现实之间的差距。

因此，这是安全问题经常升级的地方。

大多数工具（商业或开源）都专注于识别基础设施模板的错误。 本篇
是一个很好的构造。 制作 Free Introduction
会很糟糕。 这些工具旨在生成这些结果作为持续集成/持续交付 (CI/CD) 管道的一部分。

这是一个很好的开始。 但它呼应了同样的语言问题。

谁在说话，谁在听？

当 IaC 工具突出一个问题时，谁来解决它？ 如果是开发团队，它是否有足够的信息知道为什么将其标记为问题？ 如果是运营团队，报告中是否列出了问题的后果？

对于开发者来说，经常发生的情况是，他们会简单地调整配置，使 IaC 测试通过。

对于操作，通常是测试是否通过的问题。 如果是，则继续下一个任务。 这对任何一支球队都没有打击； 相反，它突出了期望与现实之间的差距。

需要的是上下文。 IaC 安全工具提供了对即将（希望）构建的内容的可见性。 目标是阻止问题 before 他们开始生产。

今天的 IaC 安全工具突出了需要解决的实际问题。 获取这些工具的输出并使用特定于负责代码的团队的额外上下文来丰富它，这是进行某些自定义自动化的绝佳机会。

这也将有助于弥合语言鸿沟。 您的工具的输出基本上是第三种语言——只是为了让事情变得更复杂——并且需要以对开发或运营受众有意义的方式进行交流。 经常两者兼而有之。

例如，当扫描标记安全组规则没有描述时，为什么这很重要？ 只是收到一条提示“为上下文添加描述”并不能帮助任何人更好地构建。

这种类型的标志是一个很好的机会来教育在云中构建的团队。 添加安全组规则应尽可能具体的解释可减少恶意攻击的机会。 提供对强规则示例的引用。 在不明意图的情况下调用它，其他团队无法测试安全确认的有效性。

安全是每个人的责任，因此承认开发人员和运营人员之间的语言差距将突出这样的机会，以添加简单的自动化，为您的团队提供洞察力。 这将有助于改进他们正在构建的内容，从而推动更好的安全结果。

关于作者

我是一名法医科学家、演讲者和技术分析师，试图帮助您理解数字世界及其对我们的影响。 对于日常用户，我的工作有助于解释数字世界的挑战。 使用社交媒体对您的隐私有多大影响？ 当面部识别等技术开始在我们的社区中使用时，这意味着什么？ 我帮助回答诸如此类的问题以及更多问题。 对于构建技术的人，我帮助他们将安全和隐私镜头应用到他们的工作中，这样他们就可以让用户对他们的信息和行为做出更清晰的决定。 在隐私和安全方面存在大量混淆。 不应该有。 我让安全和隐私更容易理解。