治理,而非守门:SAP 如何为 AI 连接性提供企业级安全

发布: (2026年5月8日 GMT+8 15:00)
15 分钟阅读

Source: VentureBeat

(请提供您希望翻译的正文内容,我将为您翻译成简体中文并保持原有的格式。)

由 SAP 提供

企业软件行业已经经历了根本性的转变,供应商正在调整其方法,以更好地保护依赖它们的客户。多年来,所有运营多租户云基础设施的全球平台供应商都保持了已记录的速率限制、使用控制以及对未记录内部接口使用的限制。

Source:

典型平台控制

  • CRM 平台 – 每个组织的每日 API 调用限制、平台层面的限制,以及批量数据 API 与事务性 REST 接口之间的严格分离。
  • 生产力与协作套件 – 限流的图形 API;批量工作负载会被重定向到专为该负载设计的专用数据访问通道。
  • 人力资源与劳动力管理平台 – 并发请求限制和每会话数据检索上限。
  • IT 服务管理平台 – 每用户速率限制和实例级别的限流。
  • 超大规模云服务商 – 在基础设施层面强制执行的每项服务配额;明确禁止调用非 SDK 或未发布的接口。

这些是面向企业级软件平台在大规模共享基础设施上运行的基本卫生措施。十余年来,这些措施一直在实施,未出现严重异议。

为什么 SAP 的统一 API 政策不是新限制

随着 SAP 承担起在云端保护客户关键业务负载的责任,统一的 API 政策并明确使用控制并非限制,而是企业级治理的体现。

  • 该政策引入新限制;它仅仅命名并统一了多年来在各个 SAP 产品中已存在的控制措施。
  • SAP 并未创造 API 治理。诸如 SAP SuccessFactors、SAP Ariba、SAP LeanIX 等解决方案以及许多其他产品,已经实施了有文档记录的速率限制和使用控制。
  • SAP 说明(SAP Notes)和 SAP 文档历来对 API 使用进行了定义。

最近的政策所做的,是整合这些已有的做法,形成一个跨产品组合的统一标准——这一举措因自主、代理式的工具的出现而变得迫在眉睫,SAP 完全致力于支持这些工具。这些代理对 API 接口施加了截然不同的性能、稳定性和安全负载,而这些接口从未为大规模的自主编排和数据提取而设计。

自定义接口:SAP 的 API 政策的限制 & 不限制内容

客户开发的 API

  • 由客户在自己的命名空间(Z 命名空间)中构建的自定义 API,用于可扩展性、集成和迁移,属于 客户开发的接口
  • 政策对未发布 API 的限制 不等同 于对这些自定义服务的拆除命令。

政策范围

  • 重点是 SAP 自身的内部接口,这些接口从未发布、从未为客户使用而编写文档,也未作为可靠的集成基础提供。
  • 大多数自定义代码从不涉及这些内部接口,且将继续保持不受影响。若涉及到,则风险一直存在;政策只是 明确指出 这一点,而不是创造新的风险。

明确禁止的接口

  • ODP‑RFC 属于一小类 被禁止 的接口。它位于 SAP 的命名空间中,作为内部、未发布的接口,SAP 明确将其归类为“不允许”客户或第三方使用(见 SAP Note 3255746)。

这些接口将在说明和自动化工具中标记为禁止,以便能够在部署或运行后期之前及早识别此类使用,而不是在后期才发现。

注意: Clean Core 与 API 政策不同,但方向相同。客户在经历替代方案的升级成本后,屡次请求 Clean Core 的建议。在代理时代——SAP 将关键任务 ERP 作为服务运行——Clean Core 建议和 API 政策都是云运营实现企业级可靠性的前提条件。

AI 代理如何改变 SAP 系统中的 API 使用模式

虽然有些评论者认为此政策主要是商业举措,但技术证据却讲述了不同的故事。

传统事务接口

  • 设计用于 请求‑响应 交互:获取销售订单、提交收货、触发付款运行。
  • 通常由 人工编写的集成流程 按可预测的频率、为定义的业务目的调用。

自主 AI 编排

  • AI 代理对这些 API 发起 数千次顺序调用,以提取业务模型的语义上下文。
  • 这种模式 不是 干净核心的集成方式。

架构区别

  • 传统集成工具:读取销售订单,将其转换为目标模式,然后传递下去。SAP 的数据模型是一个瞬时的解释步骤。
  • AI 代理:做的是完全不同的事。它不仅仅是检索一个值;它 解释关联对数据采取行动,方式是原始 API 设计从未预料到的。

由于 AI 代理在 API 表面施加 高频率、高容量、上下文丰富 的工作负载,统一的 API 政策对于在新兴的代理时代保持性能、稳定性和安全性至关重要。

理解 SAP 数据模型

代理读取明细行数据,学习各个项目如何与订单关联。它读取净值,并了解到该数字只有在与凭证币种配对时才有意义。它追踪销售订单在交付、开票,最终进入会计账簿的路径,内化 SAP 如何在其业务对象模型中将运营与财务对账。

代理不仅在消费客户的交易数据;它还在消费 语义本体

  • 业务对象定义
  • 实体之间的关系
  • SAP 在五十多年企业知识编码中构建和完善的概念架构

SAP 长期以来一直区分对客户数据的事务性访问与对底层本体的更广泛提取或复制。该政策并 创建此边界——它本已存在。自主代理必须继续尊重该边界,而不是重新定义它。

第三方 MCP 实现的安全风险

然后还有一个安全角度,而且它并非抽象的。就在该政策发布的同一周,一个名为 Mini Shai‑Hulud 的供应链攻击——npm 蠕虫的变种——悄然危及了数百个软件包。SAP 生态系统的 npm 包被攻破,我们已通过向客户发布安全说明来应对。这不是理论上的威胁模型;它是社区构建的 MCP 服务器连接到运行关键业务流程的生产 SAP 系统时所面临的真实威胁环境。

OWASP MCP Top 10 系统性地列出了漏洞类别:

  1. 工具投毒
  2. 提示注入
  3. 通过范围蔓延进行特权提升
  4. 令牌管理不当
  5. 供应链妥协

对数千个已分析的 MCP 实现的最新研究表明,大多数使用 静态长期凭证 或携带可识别的安全问题。MCP 生态系统中单个被攻破的包可能导致数十万开发环境暴露。

VentureBeat 上周刚报道了一个严重的 com.mand 执行缺陷,使多达 200,000 台 MCP 服务器 面临风险。

考虑一下这在实际中的意义。一个刚刚内化了你的 SAP 数据模型语义结构并通过社区 MCP 服务器运行的 AI 代理,已经超越了生产力工具的范畴,进入了 高风险类别,该类别将广泛的系统访问权限与仍在演进的攻击面相结合。

为什么仅靠MCP无法运行SAP业务流程

MCP 争论也掩盖了企业架构师必须直接面对的一个技术现实。

  • Model Context Protocol (MCP) 是底层管道。它规定了 AI 模型如何调用工具。
  • 它并未说明模型是否理解 工具在业务场景中的作用工具调用的顺序特定 API 调用会触发的副作用,或 参数错误的后果

一个将 SAP OData 服务连接进去的朴素 MCP 实现可以调用工具,但它 无法运行业务流程

Token 消耗示例

实现方式消耗的 Token大致成本*
标准 MCP565,000$1.70
上下文感知80,000$0.24

*成本基于单次操作的典型大语言模型定价模型。

标准 MCP 实现并非自动化;它是 昂贵的自动化近似,在复杂查询上会失败,同时向 API 表面加载了其未设计承载的流量。

Source:

SAP 对通过 A2A 实现开放第三方 AI 集成的架构

SAP 对这些挑战的回应 不是 关闭生态系统,而是为开放的生态系统构建合适的基础设施。这一点值得深入探讨。

关键要素

  • API 政策 – 在有文档、共同设计的架构中确保合规。
  • Agentic 互操作性参考架构 – 与主要技术合作伙伴共同开发,发布在 SAP Architecture Center,依据客户需求进行优先排序,并在新模式得到验证后进行更新。
  • SAP Joule 与 Microsoft 365 Copilot 的双向集成 – 这是生产环境中最直观的共同设计的代理集成示例:两个来自不同供应商的 AI 系统在彼此的应用界面上协同工作,且不绕过对方的安全模型。
  • 通过 A2A 协议的代理网关 – 外部 AI 代理访问 SAP 的官方路径。
  • 参考 AI 金色路径 – 可在 SAP Architecture Center 获取。
  • SAP 知识图谱、开放资源发现(ORD)元数据规范以及 SAP BDC 数据产品 – 提供将协议连接转换为业务可用交互的上下文层。
  • 受管 MCP 服务器 – 用于 CAP、UI5、Fiori Elements,计划扩展到包括 ABAP 在内的其他开发环境。

这些 不是封闭的门;它们是正确的门

标准社区参与

  • SAP 是 积极的贡献者,而非守门人。
  • Agent‑to‑Agent (A2A) 协议 的首批合作伙伴,隶属于 Linux 基金会。
  • Agentic AI Foundation 中拥有 金牌会员 身份,联合主持 Agent Identity and Trust 工作流,与定义 AI 代理在企业边界之间如何进行身份验证、授权和互操作的组织共同推进。

A2A 和 MCP 不是 SAP 勉强接受的外部约束。它们是 SAP 在内部使用并通过标准工作积极加固的协议。当社区和开源框架符合这些加固的标准时,企业即可获得在 SAP 环境中安全、可扩展地利用 AI 代理的路径。

企业安全与 API 开放性

企业部署所需的安全底线,外部集成路径将随之而来。SAP 发布的 API 政策并不标志着开放性的终结。行业已经花了两年时间,在企业系统上部署 AI 代理,使用的协议尚未被企业安全社区完成加固,针对从未为自主编排设计的 API,并且使用的社区工具已被攻击者学会利用。治理不是可选的;它是及时的。

Anirban Majumdar 是 SAP 首席技术官办公室的主管。

赞助内容披露

赞助文章是由公司制作的内容,该公司要么为帖子付费,要么与 VentureBeat 有业务关系,并且这些文章始终会被明确标记。如需了解更多信息,请联系 sales@venturebeat.com

0 浏览
Back to Blog

相关文章

阅读更多 »