云采用旨在帮助企业加速前行，但传统安全运营模式可能迅速扼杀这种创新能力。原因在于，这些模式依赖人工审批、后期审查甚至全面拒绝，从而制造了摩擦。在AWS环境中，团队可以快速配置基础设施并启动工作负载，若安全团队以阻碍进展闻名，则面临被绕过的风险。

“我们常听到安全团队认为自己的职责就是说‘不’，”Stratascale混合云安全首席顾问Alon Diamant-Cohen在最近的BrightTALK网络研讨会上表示。“如果安全团队因说‘不’而声名狼藉，那么他们并未以2026年应有的方式实践安全，而且很难建立桥梁或开展任何有效工作。”他说。

尽管现实如此，许多安全团队仍秉持“守门人”思维。这并不令人意外，因为他们常常被警报淹没，并需要保护规模远超其应对能力的环境。然而，正如Diamant-Cohen所主张，安全团队应定位为赋能者，帮助人们安全地实现目标。

说“不”的真正风险

“拒绝部门”模式如今风险更高，因为云已成为关键业务推动力，而AI驱动的创新日益依赖云资源访问。在基于安全边界的传统模式中，简单阻止访问可能将工作推向不安全的渠道，例如未经批准的工具、账户或AI服务。

“如果安全说‘不’，总会有人找到绕过的方法。作为安全从业者，我们的首要任务是：‘可以，但我们要这样安全地实现’，”Diamant-Cohen说。

安全团队无法保护自己看不见的东西。如果团队因官方流程摩擦过大而绕过安全，组织将失去可见性、问责性和控制力。这些正是AWS扩展所需的安全要素，尤其是在复杂性增加、风险难以被动管理的背景下。

幸运的是，通过主动方法，许多问题可以预防。例如，错误配置、访问问题和权限蔓延，只要安全团队尽早介入以塑造团队构建、部署和扩展的方式，大多可以避免。毕竟，AWS是一个高速环境，必须从一开始就嵌入护栏，以治理团队如何配置和运营。

治理是安全说“是”的方式

治理听起来可能官僚，但它也是让安全团队能够以更少人工干预批准更多活动的机制。只要策略清晰，并可通过组织可用的技术措施强制执行，安全团队便无需从头审查每个决策。

“企业确实有两种方法：先工具后规则，或先规则后工具，”Diamant-Cohen说。两种方法都有效，但正确选择取决于组织。“你需要的是：一份面向业务编写的高层、与具体技术无关的治理策略，以及将该策略转化为你所选工具的技术翻译，以便执行。”他说。

在许多情况下，最好在采购前制定云安全策略，以确定最佳执行工具。但有时，先采购平台再围绕其制定安全策略更有意义，尤其是当截止日期迫近，需要在新项目启动前准备好某些控制措施时。

无论哪种方式，构建安全基础都能让安全团队从一开始获得可见性，而非事后补救。在扩展AWS采用时，治理必须与策略、架构、运营和成本可见性相连接。通过企业级治理策略，安全控制可重复，这正是组织在不使安全成为障碍的前提下安全扩展的手段。

AI提高了云护栏的赌注

安全团队必须成为赋能者的论点并不新鲜，但代理式AI大大提高了风险。当AI代理能够访问系统、调用API、跨工作流操作或支持自主安全与运营流程时，治理必须在这些行为发生前到位。

这使得安全云基础更加重要。在团队进一步扩展云工作负载之前，他们需要一个预配置的环境，其中身份、日志记录、网络分段、监控和安全策略等核心控制已内置。云团队通常将此基础称为着陆区。这一基础至关重要，因为每个新工作负载（包括自主代理）在生产前都应继承正确的护栏，而非安全团队事后干预。

随着更多系统变得自主，安全不能再仅依赖人工审查。Diamant-Cohen还指出，代理是非确定性的，意味着它们不会总是产生相同答案或采取相同路径。这种不可预测性使得定义系统和代理允许访问的内容、禁止的操作、活动监控方式以及事件发生时的责任归属变得更加重要。

“治理是‘我需要能够看到一切，我需要有允许和禁止操作的清单，并且我需要有人对云中采取的每一个行动负责’的简称，”Diamant-Cohen说。

在代理时代，这一定义是安全自主的基础。着陆区、零信任控制、数据安全策略和持续监控，都为安全领导者提供了对AI驱动创新说“是”的方式，而不会放弃可见性或控制力。

对于在AWS上构建或扩展的组织，通往更好安全的路径始于发现：当前存在什么，已有哪些控制，以及治理需要如何改进。SHI与AWS客户合作，将这一评估转化为安全、可扩展云采用的长期路线图。