应对AI驱动的攻击，保障数据安全：Oracle 如何从源头保护数据库资产

要点

如果问企业，在部署AI Agent时最担心什么，答案往往并不是模型或提示词，而是数据。Omdia的研究发现，企业对AI Agent最关注的三大风险分别是数据隐私（37%）、安全漏洞（34%）以及合规与监管风险（29%）。这三项风险都直接落在数据层面。

这些担忧并非没有依据。每新增一个Agent、一项集成或一条自动化数据管道，都会为企业数据增加一条潜在访问路径。过去相对封闭的应用和终端用户体系，如今正逐渐演变为一张由自动化访问路径构成的复杂网络，连接着企业所持有的最敏感信息。保护这些数据已经不再是众多工作流中的一个环节，而是企业能够真正部署 AI 的前提。

AI重塑攻击方程

不久前，一次严重的网络攻击还需要高度专业的技术人员投入数周时间进行细致、手动的操作。如今，AI已经打破了这一门槛。它可以分析代码变更、生成数十种攻击变体，并以传统防御机制难以跟上的速度同时针对多个系统发起攻击。过去需要稀缺专业技能才能完成的工作，如今变得更加简单、快速、自动化，也更容易被广泛利用。

由此产生了巨大的攻防不对称：攻击面不断扩大，而防御响应窗口却持续缩短。 已知漏洞、权限过高的用户、错误配置、权限漂移以及审计缺口，都可能在防御人员来得及修复之前被攻击者利用。供应商发布安全补丁的频率已经达到前所未有的水平，但更棘手的问题在于，客户能否及时完成补丁部署，同时确保生产环境中的应用不会因此出现故障。

这也是应用层安全控制能力触及上限的地方，而原因并非产品质量，而是其自身的架构位置所决定的。这些控制位于数据之前。每增加一个访问数据库的应用、集成或 Agent，就意味着需要额外部署和维护一道安全边界；而任何绕过应用层的访问路径，也会同时绕过相应的安全控制。此外，这些安全控制通常按照发布周期和季度审计等人工管理节奏进行配置和审查，而攻击却在持续迭代。对于一种必须在各处重复部署、并通过定期更新来维持有效性的安全控制而言，很难抵御一种能够同时出现在各个入口、以机器速度发起并持续自我适应的威胁。

因此，补丁管理、风险评估、防御和恢复已不能再被视为一次性的专项工作。

AI Agent：一种真正全新的风险类别

大多数数据库风险并不陌生，包括SQL注入和控制绕过、敏感数据和测试数据暴露、系统未及时打补丁和备份不安全、安全加固不足、凭据被窃取以及权限过度等。这些都是长期存在的问题，而如今，能够以机器速度运行的 Agentic 攻击者正在让这些风险呈指数级放大。

但AI Agent带来了一些新的风险。AI Agent是能够进行规划并采取行动的软件，其中有两个特性使其与传统软件明显不同。

第一是滥用（abuse）。 AI Agent可能受到其处理内容的操纵，从而执行其操作人员从未授权的行为，包括获取并泄露原本不应被访问或披露的数据。

第二是权限继承（inheritance）。 AI Agent通常代表最终用户执行操作，并继承该用户的访问权限，而这种机制与企业实际的权限分配方式并不匹配。用户通常拥有较为广泛的权限，因为其工作职责多样，并且会根据实际情况判断决定何时使用这些权限。而 AI Agent 虽然拥有相应的访问权限，却没有人的判断能力，可以在几秒钟内调用其全部权限，执行数千项操作，而这些操作可能是最终用户从未主动选择执行的。

这并不意味着企业不应该使用AI Agent。同一项研究显示，87%的企业认同AI Agent将帮助其解决过去被认为无法解决的问题，或实现此前被认为不可能实现的业务应用场景。 AI Agent带来的机遇是真实存在的，而这也正是为什么必须将相关风险控制在一个更加持久、可靠的安全边界之内。

这个边界不能设在应用层：AI Agent通常是一个合法且经过身份认证的调用方，所执行的操作也确实属于其被授予的权限范围。因此，安全边界必须建立在一个AI Agent无法绕过或规避的地方。

AI时代数据安全的三项原则

Oracle 围绕三项核心原则构建了应对策略，分别对应 AI 如何改变当前的威胁模型：

1. 从源头保障安全（Secure at source）：无论AI从何处访问企业数据，都在数据层直接构建安全能力，而不是将安全功能附加在上层应用之上，从而全面保护企业数据。

2. 以攻击速度保障安全（Secure at speed）：通过自动化补丁管理和生命周期管理应对AI驱动的威胁，使防御能力能够跟上攻击的速度。

3. 通过韧性保障安全（Secure through resilience）：假设任何环节都可能出现问题，并确保能够快速、可靠地恢复，从而保障系统正常运行时间、服务级别协议（SLA）以及业务连续性。

这三项原则共同将数据安全重新定义为一项持续覆盖整个数据库环境的系统性工作，而不再是一系列周期性开展的专项项目。这样的转变正是关键所在。当前安全压力最大的企业，并不是缺少安全工具，而是仍然将安全视为阶段性的工作，而面对的威胁却是持续不断的。

从源头保障安全：让防护能力随数据而行

保护数据最可靠、最持久的位置，就是数据层本身。

Oracle Deep Data Security将针对最终用户的隐私规则直接部署在数据库内部，阻止任何 SQL 访问最终用户无权查看的数据。这直接解决了前文所述的权限继承问题：由于安全规则在数据源头执行，并且与最终用户的身份绑定，代表该用户执行操作的 AI Agent 也会继承相应的安全边界，而不是寻找绕过边界的方法；同时，最小权限原则也能够得到实际执行，而非仅仅依赖预设。无论AI Agent如何受到误导，都无法获取最终用户本身无权访问的数据。

归根结底，Deep Data Security在数据库中建立了最终用户安全上下文，使数据库会话受到用户身份、角色和属性的约束，而不是依赖应用程序数据库账户所拥有的更广泛权限。

与此同时，Oracle In-Database SQL Firewall能够在数据库内部透明地应对 SQL 注入攻击。由于该防火墙直接构建于数据库之中，而不是叠加在数据库之上的安全层，因此攻击者无法绕过，同时也不会带来额外的可用性或延迟问题。随着通往数据的访问路径不断增加，数据本身才是最值得防守、也最难绕过的安全控制点。

以速度保障安全：让自动化跟上攻击节奏

要跟上 AI加速的威胁，就必须同时实现补丁管理和生命周期管理的自动化。Oracle Autonomous AI Database提供Oracle Managed自主补丁、自动化威胁检测与修复，以及始终开启的静态数据和传输中数据加密。Exadata Database Cloud Service 等共同管理型服务，则能够在整个数据库资源池中进一步实现高度自动化的补丁管理。

对于规模更大的数据库环境，关键在于将补丁管理从一次性的项目转变为一种快速、可重复执行的安全控制机制：发现补丁缺口，通过自动化更新减少人工操作和运维负担，在不同环境中统一管理和执行补丁流程，并向安全团队和企业管理层证明合规进展。Oracle Database Lifecycle Management Pack、Exadata Management Pack 以及Fleet Patching and Provisioning都支持这一完整流程。

而信心是速度的另一面，因为担心影响生产环境，补丁部署被推迟是主要原因之一。Oracle Real Application Testing 可以捕获生产环境中的工作负载，并进行回放，在部署前验证应用行为。GoldenGate通过数据同步支持以最少甚至零计划停机时间完成补丁部署，随后再通过 GoldenGate Veridata 验证数据一致性。Data Safe 和 Database Security Central 则提供覆盖整个数据库环境的可视化能力，可对敏感数据进行分类、评估用户和配置风险、监控活动、检测配置漂移，并在云端和本地数据库环境中确定修复优先级。

通过韧性保障安全：将恢复能力作为安全控制

问题最终总会发生，这意味着，从AI驱动的攻击或系统中断中快速恢复，应当被视为一种安全能力，而不是事后才考虑的补救措施。

Oracle Zero Data Loss Recovery解决方案能够持续备份生产数据，并提供不可篡改、物理隔离的备份，以抵御勒索软件攻击；同时支持在主流云平台和本地环境中，以比其他方案最高快5倍的速度恢复至最后一笔事务，且实现零数据丢失。

Oracle Globally Distributed AI Database通过将多个物理位置上的本地数据库呈现为一个逻辑数据库，使企业能够在不同地区应对系统故障，同时满足数据主权法规要求。与此同时，Maximum Availability Architecture（MAA）将参考架构和运维实践整合为不同的可用性等级。目前，MAA已增加增强版Platinum等级，并推出面向超关键业务负载的全新Diamond等级，其灾难故障切换通常可在 3 秒以内完成。通过从Silver到Diamond的不同等级，企业可以根据业务负载的重要程度匹配相应的韧性投入。

降低立即行动的门槛

Oracle也在帮助客户降低采取行动的门槛，让企业能够在遭受攻击之前采取措施，而不是等到安全事件发生后才开始应对。对于当前拥有支持服务的客户，部分安全和补丁管理工具可在限定期限内免费使用；同时，部分关键升级和补丁管理工具的一年期许可证也提供大幅折扣。Oracle还鼓励客户在条件允许的情况下迁移至 Autonomous AI Database，以获得Oracle Managed自主威胁检测和补丁管理能力，或者升级至Oracle Database 19c、Oracle AI Database 26ai等长期支持版本，并应用所有版本更新。

评估自身数据库环境的五个问题

企业如果希望根据这一威胁模型评估自身数据库环境，应思考以下五个问题：

1. 数据访问实际上在哪里得到控制？是在数据层，还是由每个应用程序分别负责？

2. 如果AI Agent受到操纵，它能够访问哪些数据？这一边界是最终用户的全部访问权限，还是比用户权限范围更小？

3. 一个补丁需要多长时间才能部署到整个数据库环境中的所有数据库？这一时间能否通过实际数据证明，而不是仅仅估算？

4. 能否在一个统一的位置查看敏感数据、用户风险和配置漂移情况，并同时覆盖云端和本地数据库？

5. 如果明天就需要恢复，备份是否不可篡改、经过验证，并且能够足够快速地恢复，以满足企业已经对外承诺的业务要求？

凡是依赖人工操作，或需要在大量应用中重复部署安全控制的环节，都应该成为企业优先改进的对象。

核心结论

Agentic AI在推动创新和提升生产力方面带来了巨大的机遇，但与此同时，也正在重塑针对企业核心数据的威胁格局。AI驱动的复杂攻击门槛已经降低，数据暴露面不断扩大，留给企业的响应时间持续缩短，而AI Agent所带来的新型风险，则使其能够继承合法访问权限并自主执行操作。传统的应用层安全控制和周期性的安全项目，并不是为应对这种组合型风险而设计的。

能够在这一阶段建立优势的企业，需要从数据源头进行保护，让安全能力随数据而行；通过自动化补丁和生命周期管理，让防御速度跟上威胁演进；同时构建具备韧性的基础设施，确保出现问题时能够快速、可靠地恢复。目前，Oracle AI Database已承载全球97%的《财富》100强企业的关键业务数据库环境，因此，进一步强化其抵御Agentic AI攻击的能力已经不是一个小众或局部问题。

从竞争格局来看，Omdia注意到，多家数据库厂商都提供了部分能够构成Oracle Deep Data Security能力的组件，但目前尚无主要竞争对手能够以单一的、原生于数据库的授权框架，提供与Oracle相同的完整组合，并明确针对 Agentic AI场景进行设计。

Oracle AI Database 26ai中的Deep Data Security并非传统的行级安全机制。其差异化优势在于，数据库能够识别应用程序或AI Agent背后的实际最终用户安全上下文，并在 SQL执行过程中，在行、列乃至单个数据单元格级别实施声明式授权，而无论数据访问来自应用程序、分析工具、RAG工作流、AI Agent还是直接SQL路径，都能够执行一致的安全控制。

这一差异至关重要。如果AI Agent因提示词注入攻击而遭到控制，或者只是生成了不恰当的SQL，就不应该因此继承权限过于宽泛的数据库服务账户所拥有的访问范围。数据库可以独立地将查询结果限制在人类用户主体有权查看的数据范围内。Oracle明确将这一能力定位为：将授权机制从应用程序或Agent代码中移出，并直接在数据源头执行。

最终用户身份传递、数据库原生上下文授权、行级/列级/单元格级安全控制，以及在应用、分析工具和AI Agent等不同访问路径上的一致性执行能力共同构成了Oracle AI Database的差异化优势，使其成为企业部署Agentic AI 的理想平台。

对于任何正在推动AI进入生产环境的企业，Omdia建议：首先根据前文提出的五个问题评估自身数据库环境，并与Oracle AI Database团队进一步沟通，了解“三项原则”如何应用于自身环境。企业能够在安全事件发生之前采取行动的窗口正在迅速缩小。

文章版权和解释权归微信平台Omdia所有

Omdia隶属于Informa TechTarget, Inc. d/b/a Informa TechTarget（纳斯达克代码：TTGT），是一家全球领先的技术研究与咨询机构。依托对科技市场的深刻洞察、与行业领导者的深入对话以及庞大数据资源，Omdia帮助客户洞察趋势、把握机遇，抢占市场先机。从研发到投资回报，我们识别最具潜力的机遇，推动科技产业持续发展。