“蓝屏事件”启示:拿什么守护企业安全?

  微软近期的“蓝屏事件”令全球哗然,由于系统宕机波及的范围过大,航空、电信、金融机构、医疗、媒体等各行业无差别地受到影响,所造成的经济损失尚无权威估量。这只“黑天鹅”再次把安全机制拷问推到聚光灯前。

  当下,生成式 AI 不再是一套独立存在的技术系统,而是深度融入生产生活的各个环节,以往“杀毒软件式”的攻防思路还能否适应人工智能时代的安全要求?未来,当人们把个人驾驶、陪护等关乎身体的交互场景交由机器代办后,安全漏洞的危害可能就不止于财产损失或信息泄露。

  从管理机制到产品设计、响应机制,全方位地把安全写入企业的 DNA 中,势在必行。

  生成式 AI 时代,安全不再是“门锁”

  从个人 PC 时代走过来的人都熟悉一个早年装机必备工具——杀毒软件,其本质是一把“门锁”。个人上网要与服务器做数据交换,“门锁”的作用是筛选、挡住黑客软件的数据交换。但令人感到讽刺的是,这次微软蓝屏事件据说是与某款第三方安全软件的更新有关,就好比门锁升级,门却开了。

  后来步入公有云时代,这比本地化部署更具性价比,但对数据安全的担忧曾一度阻碍企业的上云。

  眼下的生成式 AI 阶段对数据安全提出了更复杂多变的考验。比如提示词注入(Prompt Injection),这是利用人工智能模型对输入输出存在的漏洞进行攻击的一种方式,攻击者可以通过精心设计的提示语让模型产生意料之外的输出,造成信息泄露或系统损害;再比如数据污染(Data Poisoning),人工智能模型的训练依赖大量的训练数据,如果训练数据被恶意篡改,就可能导致模型产生错误行为。可见,这些都是在生成式 AI 环境下特有的攻击手段,但本质上没有脱离计算机安全的基本范畴。

  AI 与云密不可分,无论是公有云还是生成式 AI,客户关系本质上都是一种订阅关系,而非消费互联网下的买卖关系。长期合作中建立起的信任感使企业客户的迁移成本变高,彼此间黏性增强。与本地化部署买A产品还是B产品的决策不同,订阅客户相当于把半条身家性命交予云平台,后者的安全性就是前者的业务基石。

  而决定产品设计的安全理念始终践行如一的,除了严谨的技术机制之外,更源于高层的管理机制——安全不是 CTO 工程,而是 CEO 工程。

  亚马逊云科技首席信息安全官 Chris Betz 曾在上个月美国 re: Inforce 主题演讲中介绍,八年前亚马逊云科技决定让安全团队直接向 CEO 汇报,目前每周五领导层都会在首席执行官和亚马逊云科技安全领导的带领下,与各个服务团队开会讨论重要的安全问题,各开发人员、产品经理、总经理参与其中。这种管理机制设计重新定义了如何将安全融入公司文化中。

  在响应流程上,亚马逊云科技内部创建了 Guardians 计划。Guardians 是深入各服务团队的工程师,他们从计划会议到立项会议,从安全评审到整个开发周期的每个步骤都在场。一旦出现安全问题,不会像其他公司那样在各部门间来回传递工单而耽误时间,会立刻“升级处理”,员工可越级汇报,交由安全团队负责,内部鼓励这种快速响应理念。

  亚马逊首席执行官安迪·贾西(Andy Jassy) 曾说过,安全是亚马逊的“Job Zero”。事实上,安全也是整个数智社会的“Job Zero”,即“0 号任务”。把安全植入每个产品技术的所有研发、测试、部署、调用、兼容……亚马逊云科技专注于在所有环节构建“安全机制”,在智能时代正凸显出价值。

  “Job Zero” :安全文化的构建是体系化工程

  2024 年迎来生成式 AI 大爆发,很多企业客户选择在亚马逊云平台上做生成式 AI 技术的开发与创新,很重要的一个因素是看中其安全性。数据显示,全球 96% 的 AI 与机器学习独角兽企业,及 90% 的 2024 福布斯 AI 50 强企业选择了亚马逊云科技。亚马逊云科技在新阶段提出生成式 AI 基础设施安全、技术栈安全和数据安全的全面安全理念,与以往相比做了显著升级。

  在 7 月 25 日的 re:Inforce 大会上,亚马逊云科技为 Amazon GuardDuty 全托管服务增加了新的安全功能——S3 云存储恶意软件防护,可帮用户自动扫描文件,并隔离恶意软件。

  目前,亚马逊云科技针对生成式 AI 的三层技术栈做了系统性的安全部署与升级。其中,底层 Nitro 系统从设计上将客户数据与运营商完全隔离,确保亚马云科技的运维团队无法访问客户在 EC2 实例上运行的工作负载和数据。以往,Nitro Enclave 隔离功能只能运行在 CPU 上,限制了它对更大规模参数模型的支持,未来亚马逊云科技计划拓展这一 Nitro 端到端加密流程,将其与机器学习加速器和 GPU 无缝集成,让后者处理运算效率大大提升。

  值得一提的是,在 2017 年 Amazon Nitro 系统诞生前,亚马逊平台 EC2 实例大概有 70 个种类,这之后的 6 年,EC2 实例增长到 750 种。这个过程中,亚马逊云科技一步步将网络、存储的虚拟化、安全、监控等都卸载到 Nitro 硬件上,将服务器算力 100% 为用户实例所用。这些是在架构设计之初主动设计的,把虚拟化的安全纳入硬件层考虑,而不是产生安全隐患时的被动响应。

  在中间层,模型托管平台 Amazon Bedrock 对数据进行加密,允许客户创建、管理和控制加密密钥,且承诺不会使用客户数据来训练或改进原始的基础模型。当客户微调模型时,亚马逊云科技会创建一个该模型的私有版本,将其放入安全的容器中,意味着数据不会与亚马逊云科技共享。

  对于最上层的代码编写,Amazon Q Developer 可以协助开发人员编码、测试、排查隐患、安全扫描和修复。在一个近乎实时生成代码建议和推荐的开发环境下,从一开始就基于安全性和隐私性出发、编写高质量的代码,显然要比完成测试、甚至交付后再去修改要有效率。

  这样一个体系化的安全工程构筑了亚马逊云科技客户的安全保障,也让一些中国出海企业受益。

  货拉拉的海外品牌 Lalamove 选择亚马逊云科技在新加坡、和巴西圣保罗等地区进行 IT 部署。“千岛之地”东南亚的物流环境十分复杂,对业务系统的安全稳定和可拓展性要求也很高。Lalamove 对亚马逊云科技是多层面的技术合作,它利用 Amazon SageMaker 机器学习服务,在全面考量人、车、货、路等货运元素的基础上构建了智慧货运平台;它使用 Graviton 芯片优化云上工作负载,实现了 20% 的云上成本节约。

  安全:数字产业的“达摩克利斯之剑”

  与技术红利带来快速增长机遇相比,建立体系化的安全文化需要经年累月付出,并非一件易事。放眼更大的产业数字化转型进程,安全因素也往往被放在次要地位考虑。

  在今年 5 月份上海举行的亚马逊云科技中国峰会上,该公司宣布了“行业合作伙伴计划”,组建垂直领域的人工智能技术团队,聚焦包括汽车、制造、金融在内的八大行业,深耕企业数字化转型,并与安全厂商联手推出“亚马逊云科技安全合作伙伴计划”。这说明产业层面利用生成式 AI 做创新将迎来一个新的风口。

  人们随之也看到了硬币的另一面。

  以眼下火热的汽车行业为例,“软件定义汽车”重新梳理了汽车的生产和使用,跳出了机械式代步工具的范畴。那么,谁来定义软件呢?或者说,当软件定义汽车时,也同时“定义”了漏洞。任何 ICT 领域的攻击手段几乎都适用于汽车场景。

  2023 年以来,全球汽车安全态势呈现严峻趋势,据统计有 64% 针对车辆的攻击来自黑客,绝大多数为远程攻击。国内也不容乐观,据工信部统计,2023 年 1 月至 2024 年 1 月,发生与车企相关的数据泄露事件 20 多起,涉及驾驶数据、用户数据和业务数据。

  软件定义汽车更进一步的目标是自动驾驶。近期国内无人驾驶网约车的试点运营已经收集到不同城市的负面反馈,现实阻力重重。自动驾驶本身的安全性已经得到反复验证,地铁、高铁、飞机这些有特定运行轨道的交通工具早已实现自动驾驶,但这些所处的是一个相对封闭的网络环境,而车辆自动驾驶是更开放的网络环境,安全不仅关乎个体司机,也涉及到企业、政府、甚至国家层面。

  “蓝屏事件”已经敲响警钟,行业发展的基础是让安全先行,从源头设计上就要把安全置于最高级考虑。

  结语

  贝索斯在亚马逊一直强调“Day 1”文化,意在时刻保持创业者的初心、创造力和警觉,他还喜欢在财报中强调现金流能力而非净利润。亚马逊的企业文化强调做“称重机”,不做“投票机”,即围绕客户需求完善自身,无需理会华尔街一时的投票。在这种企业文化中,对安全建设的资源投入是一个长期持续过程,虽然难以通过财务数据直观显现,但已经体现在客户的选择倾向上,并刻在企业的文化 DNA 中。

  当传统工业时代的红利衰减殆尽,整个产业数字化转型、拥抱 AI 的脚步就会更快。而如果说数据是生成式 AI 的基础和源头,那安全就是面对这场新技术革命的信心和底气——一切瞬息万变,安全的基本原则却恒久不变。