2021 年云安全建议

2021 年云安全建议（假设 2020 年终会结束）

2020 年。这一切就这样发生了。

在云安全方面，2020 年就像往汽油火堆里浇火箭燃料；原本三年的规划被压缩成三个月的执行。正如一堆温暖的篝火，这既带来了收益和机遇，也带来了一些危险。就我个人而言，疫情取消了我大部分的出差，反而让我在更多元的客户群中完成了更多工作。当我们都开始假装自己有机会放慢脚步享受假期时（事实往往并非如此），我想现在或许是个好时机，把我学到的一些趋势和经验整理出来，供我们共同用于 2021 年的规划。

正如伟大的作家 Terry Pratchett 曾说过的：“为一个人生火，他可以温暖一天。点燃一个人，他可以温暖一生。”2021 年的要义在于驾驭火势以推动增长，同时不烧毁自己的房子。

我整理了一些云安全建议，针对我在项目中看到的许多常见系统性缺陷，同时也便于分阶段逐步推进。2020 年我们的云采用速度大幅加快，这意味着许多组织行动迅速，却没有时间打下扎实的基础。这完全正常，但我们不能长期拖延而不加以夯实。下面的每一条都对应着某些广为人知的失败事件的根本原因。

从修复云治理开始

2020 年，我与数十家组织合作，并与数百家组织进行了交流。治理不善是我在云中看到的最普遍的问题，远超其他问题。它有几种不同的表现形式。我最常看到的是两个极端：要么组织对开发人员不施加任何限制，要么安全团队把一切锁定为不适合云环境的标准模式。我建议折中处理：要求所有新的供应商和服务都必须经过安全审批，并赋予安全团队说“不”的权力，但前提是他们能够说明理由。然后，要求安全团队制定体现云原生实践的云原生策略和流程，而不是把所有令人恼火、缓慢且适得其反的数据中心安全工具搬过来。通过云卓越中心让所有人坐到同一张桌子前。我们看到的公有云安全失败案例中，很大一部分根源在于治理失败，而非技术失败。

说到治理，现在正是采用“安全卫士”这一理念的好时机

安全卫士不是 BISO（业务信息安全官）；他们是项目团队中的本地开发人员或管理员，接受一些额外培训，在委员会会议期间享用免费披萨（在 COVID 隔离结束之前可以外送），并在项目与安全团队之间充当联络人。可以把他们视为联络点和倡导者。

提升云安全可见性

另一个常见的治理问题是，除了部分日志之外，把安全团队挡在云账户之外。请在 2021 年解决这一点：为安全团队提供工具以及对每个云部署（包括开发/测试/沙箱环境）的只读访问权限，并为事件响应准备应急的读写访问权限。作为交换，安全团队制定策略，规定只有在无法联系部署团队进行修复的最坏情况下，他们才会自行实施紧急变更。可见性应涵盖部署的持续配置状态（CSPM）以及实时变更的事件和日志数据流（CDR）。

如果您尚未使用多账户来控制攻击的影响范围，请立即开始

我指的不只是生产和非生产环境，而是每个应用堆栈配备多个账户。为什么？因为身份就是新的边界，您把越多内容堆进少数几个大型环境，就越难实施最小权限控制。那种难度几乎是不可能完成的。2021 年，您可以从“新应用用新账户”的规则开始。这里我确实略去了不少复杂性，主要是在需要互联应用堆栈时的网络层面，但一旦您开始采用云原生模式，这些问题都是可以解决的，而且收益巨大。

升级您的云原生事件响应能力

我看到事件响应在两个方面落后。首先，事实证明云服务商文档中的默认日志模式通常并不理想，从事件发生到通知出现之间存在很长延迟。这一点在 AWS 上最为明显，但所有服务商都存在这一问题。如果您依赖标准的 SIEM 连接，可能会给攻击者留出很大的时间窗口。其次，响应流程本身没有得到妥善定义和工具化。用人工响应去应对自动化攻击注定失败。2021 年，请培训您的事件响应团队，优化基于事件的告警，并通过事件分派和自动化来缩短响应窗口。是的，我是在推荐自家产品，但我们也不是为了好玩才做它的。如果您还没准备好采用商业工具，其实可以借助开源和自行编码完成其中很多工作。

自上而下全面审查您的 IAM/RBAC 实施并加以收紧

尽可能减少不必要的权限并增加资源限制。开启云服务商提供的每一项与身份相关的分析和告警工具。开始使用属性和条件策略。要知道，2020 年每一起重大公有云安全事故都涉及 IAM 方面的失误——凭据丢失、权限过多，或缺少 MFA 和条件限制来管控 IAM 边界。如果说 2021 年有什么值得您彻夜难眠，那就是这件事。

治理。基础性共享服务。若干战术性升级。云计算每年都需要全新项目和工具的阶段已经过去。2021 年的重点是夯实基础，同时在可扩展性、有效性和成本方面加以提升。相比几年前，我们现在对哪些实践最有效了解得多得多，关键在于寻找现代化的机会，并淘汰那些确实效果不佳的遗留部分。