无视安全的公司，离掉队不远了

题图｜视觉中国

在信息时代，钢铁并不是各公共基础设施的通用组建，单晶硅才是。从交通到金融，几乎所有的基础设施都陈列在私有云、公有云网络上，由全世界最大的几家云运营商负责维护。

除了这些云运营商自己的安全团队，世界上又存在一批大型网络安全公司，专为云上基础设施提供安全方案和保障。

但这些都没有阻止上周席卷全球的蓝屏事件发生——始作俑者恰恰是网络安全公司CrowdStrike，一个总资产超过 66 亿美元，员工接近8000人的巨头，以善于解决最棘手的安全事件而闻名。

这个我们正在迁徙去到的数字世界，其实比想象的更加脆弱，一次失败的更新推送，就导致全球航班大面积停飞，许多航空公司取消当天所有航班；许多医院的非紧急手术也被迫取消，甚至美国多个州的911报警线路也一度陷入瘫痪。

如果考虑到可控性更低的生成式 AI 正大举进入数字世界的生产环节，未来的网络安全形式还将变得更加复杂。

技术解决不了人的问题

人们常把网络安全问题单纯地归结为技术问题，认为“道高一尺，魔高一丈”，但在云基础设施的安全层面，近年来的重大事故多半与技术无关。

以CrowdStrike 引发的重大事故为例，若更新经过测试，问题很容易被发现；若更新是灰度上线的，同样不会造成如此恶劣的后果。

那么是 CrowdStrike 的DevOps 平台不够完善吗？

显然不是。事实上，CrowdStrike 在官方网站长期更新着大量DevOps 技术内容，说其是DevOps 布道者也不为过。

可能的答案只剩下一个：负责本次更新的团队绕过了测试环节，擅自进行了发布。而相关团队对灰度的重要性认知不足，默许了该项更新未经测试，直接进行全网发布。这是目前各家媒体共识度较高的答案，CrowdStrike 自身也并未否定这种推测。

再强大的运维平台，也弥补不了团队自身安全意识的缺失，偏偏CrowdStrike 也并不是第一次犯下此类错误。据纽约时报披露，CrowdStrike 在今年4月，向Linux系统的客户推送过一次更新，导致计算机崩溃。CrowdStrike 随后承诺改进其测试流程。没成想仅仅三个月后，更大的事故就酿成了。

显然流程并不是绝对的，团队的安全意识和文化问题，没那么容易改进。细数过去云安全领域的重大事故会发现，类似的情况比比皆是：犯错误的企业，几乎是在以相当的频度，不断重复自己的错误。

遍数行业各家巨头，亚马逊云科技几乎是唯一一家，把安全文化摆在台面上来谈的公司。

在re:Inforce 2024 美国的开场 Keynote 上，亚马逊云科技CISO（首席信息安全官）就聊了亚马逊云科技的安全文化，可见对其的重视。

据透露，亚马逊云科技的安全团队直接向 CEO 汇报，这种组织架构已经持续了八年。此外，每周五，CEO、CISO以及各服务团队有一个固定例会，讨论各服务的安全话题。亚马逊云科技是一个巨型企业，对于参会的许多人来说，这几乎是全年唯一的与CEO直接讨论产品、业务的机会。

这种越级讨论，不仅停留在例会上，也发生在故障处理上。亚马逊云科技规定，各服务团队 leader 对其服务的安全性负直接责任，但在故障发生时，故障发现人有权升级处理。在典型的巨头企业内，升级处理不仅意味着问题严重性被直线升级，也意味着某种习以为常的“公司内部政治”被打破了。而在亚马逊云科技，这种升级处理是不设级别上限的。

此外，在安全问题上，亚马逊云科技极为强调亚马逊领导力原则16条中的“主人翁精神（Ownership）”，不允许各部门在工单上踢皮球。

所以从客观上看，安全事故牵扯到的一系列“大公司病”，确实很少出现在亚马逊云科技身上。

亚马逊云科技试图用这种方式，在内部塑造一种安全文化——他们信奉长期主义，认为安全意识需要不断加强，长期建设。

没人指望一个良性的文化，就能杜绝所有安全问题，但这是一个良好的基础，甚至也是当下必须被倡导的。因为随着生成式 AI 进入生产环节，安全形式只会越来越严峻。

安全问题，已成为整个AI圈儿的“Job Zero”

一个最显著的问题是，大模型把纯粹的程序逻辑变成了某种黑盒，这是一个自机器学习技术遗留下来的老问题，叫做AI的可解释性——即便是模型的构建和训练者，也无法完全确认，AI 的每一次结果输出是如何一步步产生的。

这导致黑客很容易围绕大模型展开攻击，通过对模型输入进行干扰，影响输出。同时，大模型作为新兴产物，相关插件的安全性还不够完善，也很容易被黑客突破。

开放Web应用程序安全项目编制的LLM应用程序十大漏洞关键列表对此有过详细的介绍，比如：

及时注射：以直接、间接的方式，通过巧妙的输入，导致LLM执行意外操作；

不安全的输出处理：当LLM 的输出未经过足够的安全审查时，就会出现漏洞，暴露后端系统，可能会导致 XXS、CSRF、权限升级或远程代码执行等严重后果；

训练数据中毒：篡改LLM训练数据，引入损害安全性的数据；

拒绝服务模型：攻击者对LLM进行资源密集型操作，导致服务降级，或极大提高运营商服务成本，有点类似DDos攻击；

……

如果说，过去的云安全问题更像地雷，好像只要不踩中，就可以得过且过。那么今天的安全问题，一旦被利用，都会导致极大的安全风险，根本无法被忽视。在网络安全领域，生成式 AI 制造问题的速度，几乎和解决问题的速度相当。

虎嗅过往曾有文章阐述，UIUC的实验研究表明，使用自主 LLM 代理攻击网站的总成本约为 9.81 美元，总体成功率为 42.7%，而人工成本据估计可能高达 80 美元。LLM极大地降低了黑客的行动成本，进而导致有LLM加持的网络攻击，频频出现。

近两年的一连串人事变动，也能佐证生成式 AI 正在引发越来越广泛的安全风险：2023年76岁的图灵奖得主Geoffrey Hinton从谷歌离职，专注于人工智能风险预警；今年6月，OpenAI 联合创始人Ilya离职创业，他对媒体表示，这是一家将优先考虑安全性而非“商业压力”的公司。

事实上，应用生成式 AI 技术最为积极的巨头，都已经注意到其潜在的安全问题，这是为什么亚马逊云科技今年的 re:Inforce 2024 如此引人关注——作为业界唯一的由云厂商主办的安全大会，它们足够代表当下行业安全问题的领先认知。

亚马逊云科技提倡将安全维度的考量，融入产品设计之初。举个例子，亚马逊云科技旗下Graviton4芯片全面加密了高速物理硬件接口，包括DRAM、连接Nitro卡的PCle，以及双槽位实例中连接第二个Graviton插槽的芯片间链路。此外，Graviton4同样具备指针身份进行验证，以及对跳转目标进行识别等能力。过往许多针对芯片的攻击，都是围绕这些能力展开的，M1 芯片就曾在此吃过大亏。

但基础设施运营商一定要认识到，在安全层面的投入，不仅仅要提升防护能力，也要提升在安全环境下的性能表现。性能和安全，不是要厂商在期间做取舍，而是在保证安全的前提下，“既要又要”。

典型案例是 Amazon Nitro Enclave ，过往只能在 CPU 中运行，因此可以支持的任务类型有限。很快，亚马逊云科技将官宣对其进行拓展，将其与 ML 加速器和 GPU 无缝集成，以解决兼容性和性能问题。

今天的许多大模型都采用私有化部署的模式，原因是业内厂商对安全的认知并不统一，未能将AI数据与设施运营商彻底隔离。诚如亚马逊云科技 CISO Chris Betz在re:Inforce 2024 美国所说，客户需要一个对安全性有深入投资的合作伙伴，进入一段长期的合作关系。

在接下来的一年内，如果不将安全意识提升到一定高度，相关企业几乎不会有生存下去的可能——再华丽的技术，也抵不过客户因各类云安全事故，不断降低的信任值。

探索：将部分权利让渡给 AI

看看行业正在发生的变化就知道了。

就在7月23日，一家初创公司拒绝了谷歌价值 230 亿美元的收购计划，准备实现 10 亿美元的 ARR 并冲击 IPO。

这家公司叫 Wiz，4位联合创始人全部曾在以色列情报部队“8200”服役，也都曾供职过微软云安全部门。据硅兔君报道，他们注意到了一个巨大的市场空白：随着AI时代的到来，现有的安全解决方案多针对本地网络打造，已经无法满足日益增长的云安全需求，安全团队迫切需要一个统一的工具，来管理和监督所有云服务器。

因此他们从微软离职创业，3年融资近20亿美元，成为如今炽手可热的安全新锐企业。

说到底，Wiz 的成功表明，今天的云安全仍然过度复杂，且正变得越来越复杂。他们仅仅是构建跨多云的统一管理平台，就快速实现了 1 亿美元的年度经常性收入。

那么，日后如何推进跨多个基础大模型的安全工作？如何对使用过多种智能辅助工具的代码，进行审查？

这都是亟待解决的问题。

尝试着将一部分繁杂工作，逐渐让渡给 AI ，是目前正在推进的一个工作方向。亚马逊云科技透露，他们正在推进利用生成式 AI 提升安全性，比如用 Amazon Q for Developer 生成安全代码；用Amazon Inspector 分析代码漏洞并编写代码来替换易受攻击的行；用 Amazon Detective 分析承诺指标，并用清晰的语言描述研究结果。

另外，在企业构建了良好的安全文化和相应的组织架构后，用“铁面无情”的AI做最后的安全审查者，从而避免员工私自绕过测试和部署流程，或许也是一个可行方案。

总之，人们必须认识到，我们正在经历一场从物理世界到数字世界的迁徙，而后者的安全工作还远未做到尽善尽美，这或许是当下唯一的“Job Zero”。