云管理自动化的 4 个阶段

一位安全从业者的云自动化历程

如果您在某次会议上碰到我，很可能会听到我说“云安全始于架构，终于自动化”。紧接着我会强调，采用云原生思维方式有多么重要——哪怕您正深陷于数据中心合同到期、准备关灯走人之前那场难看的直接迁移的现实之中。这句话虽然精辟，却完全没有说明我是如何从一个只会“家常菜”（防火墙与补丁管理）的安全从业者，转变为一名精通架构与自动化的云原生人士的。与其居高临下地布道，我认为更有用的做法是讲述我的个人历程，以及一路走来在技术上的领悟。如果您是安全从业者，或者正试图帮助某位安全从业者提升云技能，那么您很可能会走上一条非常相似的道路。

第一阶段：配置自动化

对我而言，这一切始于大约九年前，当时我受邀为云安全联盟（Cloud Security Alliance）打造第一套培训课程。很早我就意识到，我们需要可重复的实验环境，它必须能在世界任何地方运行，而学员和讲师的技能水平从“开发人员”到“只会填表的审计人员”不等。那时候，Amazon Web Services 尚未真正推出 IAM，VPC 也还只是私有网络。而像基础设施即代码这样的概念才刚刚开始变得可行。

于是我面临的问题是：如何在云中为成千上万名学员搭建一套动手实践的应用堆栈实验环境。要保持一致性，*并且*能够随着 AWS 技术演进而更新。当时自己制作 AMI 仍是一件苦差事，但后来我发现了 `cloud-init` 的妙用。这是一个我可以托管在 S3 存储桶中的简单脚本，学员只需将两小行内容粘贴到实例的 User Data 字段中，实例启动时就会完全按照需要完成配置。当软件更新导致出问题时，我只需更新已发布 URL 上的那个脚本，之后每个新实例都会使用新配置——简直神奇！虽然这对已在运行的系统打补丁毫无帮助，但它让我能够维持良好的首次运行体验，比更新和发布新的 AMI 容易得多。而且，冒着彻底毁掉自己声誉的风险，您至今仍能在 S3 上看到它的一个后期版本。

我的第一步是 `cloud-init`。它已不再是我如今使用的工具，但当时让我大开眼界的是：我竟然可以用脚本定义整台服务器并让它全部自动运行，只需复制粘贴和一个托管文件。

第二阶段：工作流自动化

但下一步的影响要大得多。在开展了几年动手培训并构建了自己的工作负载之后，我开始琢磨“软件定义安全”的想法。摆在我面前的是琳琅满目的云 API，它们都在我耳边低语“调用我吧”。我开始寻找示例，结果……一无所获。当时就连 Security Monkey 都尚未公开发布。

我当时要为 Black Hat 安全大会准备一门课程，便决定以此为契机学习 Ruby 和 AWS API（通过 Ruby SDK）。最终我编写了三个演示程序：

• 一个事件响应应用，可以隔离某个实例、分析其全部元数据、使用 AWS IAM 将其锁定、为所有存储创建镜像，并启动一台取证分析服务器，随时可以分析挂载的快照。以往需要我花 30 分钟完成的工作，它在 3 秒内就能搞定。
• 一个小型应用，可连接 AWS 和 Chef，识别出所有未运行 Chef 的实例（即“未纳管”服务器）。这个过程在传统数据中心里可能需要数周时间。
• 另一个应用可以为 Qualys 扫描器开放安全组、触发扫描，并在扫描结束后关闭安全组。

我此前没写过 Ruby，所以这三个程序花了大约两个月的业余时间才跑起来。它们相当简单，但我从中学到了一些宝贵的经验。

• 凭据管理至关重要，同时也让代码更难共享、更难让其他人正确配置自己的环境。从配置文件中读取参数……很烦人。尤其是诸如“在哪个区域使用哪个安全组作为隔离组”这类内容。
• Ruby 在我本地系统上运行良好，但在 AWS 实例中运行这些代码时，我会突破服务限额，不得不插入延时器。API 服务限额可不是您的朋友。
• 所有这些都非常静态。尽管演示效果不错，但归根结底还是要从桌面或实例上手动运行代码。这种方式并没有经受住时间的考验。

我把这些打包成了“SecuritySquirrel”，您可以找到GitHub 上的 2014 年版本。信不信由您，那些甚至都不是我在发布前已经使用了几年的最初版本。

第三阶段：云本身的自动化

当 AWS 为 CloudWatch 发布 Rules 功能时，我在接下来那个周六早上花了大约 2 小时拼凑出足够的 Python 代码，可以在 10-15 秒内回滚任何安全组变更——包括根据标签、VPC 或变更请求者来限定防护范围的过滤条件。您可以下载代码和说明文档，而且与我的 Ruby 代码不同，作为一段有 3 年历史的云代码，它至今仍运行良好。

自那次演示以来，我构建了一整套在 Lambda 中运行的事件驱动自动化程序库，其中部分内容您可以下载。在那个软件包中，我最喜欢的是 `identify_internet_facing_servers.py`。出于演示目的，我把它关联到一个 IoT 版的 Amazon Dash 按钮上，点击即可触发。没错，我口袋里随身带着一个实体的 Easy 按钮。它会找出所有对互联网开放 22 端口的实例，我双击按钮就能撤销这些规则，等一切安全无虞后，手机上还会收到一条短信。

我在这里学到的关键一课出乎意料。并不是说这些事件驱动的自动化取代了我基于主机的工作流，而是它们服务于不同的目的。我意识到，我已经从构建工作流以更快完成任务，转向了构建护栏以在后台持续保障安全。两者都具有极高的价值。

第四阶段：全面自动化

我最近的工作是利用 Jenkins 和基础设施即代码（主要是 CloudFormation）来增强安全性。这一组合让我能够将安全能力自动化地融入基础设施和应用本身，从而减少对外部工具的依赖。

例如，我发布了一个简易凭据扫描器，它可在 Jenkins 中运行，在构建开始之前就找出任何已存储的访问密钥。何必等到以后再费力排查呢？之后我又编写了一些测试框架，使我基本上可以在 Jenkins 中运行任何我想用的评估工具，并在任何安全测试（例如网络扫描）未通过时让构建失败（专业提示：只要脚本返回 0 以外的任何退出码，Jenkins 就会判定构建失败）。

回到起点，如今我们在培训课程中使用 CloudFormation 模板来搭建应用堆栈的所有组成部分，让学员可以专注于添加安全能力。我们从构建一致的培训服务器，发展到构建一致的培训环境，并配有可在几分钟内更新的自定义 AMI……在全球范围内……几乎不费力气，所有软件都已预装好，只待完成最终配置。

我的云之旅始于大约九年前，自动化之旅几乎同时起步。起初我是先构建，再试着把其中一部分自动化，如今则从一开始就以自动化为前提。我最早的工作围绕运维展开，而如今几乎全部聚焦于安全，聚焦于消除运维负担，让我头脑中负责安全的部分专注于它最擅长的事情。一路走来，我还认识到：并非所有自动化都是等同的；护栏、工作流、跨平台编排、基础设施即代码和流水线自动化各有其用武之地。如今这一切都带来了几乎难以想象的安全收益，但我们仍处在非常早期的阶段——您可能会因为逆向分析一个文档糟糕的 API 而白白耗掉一周时间。

如果您从事安全工作，是时候练好您的代码功夫了。如果您是开发或运维人员，是时候练好您的安全功夫了。因为最重要的一课在于：安全作为一把保护伞的时代已经结束，安全融入肌理的时代已经到来。