SAP объединяет политику API на фоне вызовов в сфере ИИ
Материал предоставлен SAP
Индустрия корпоративного программного обеспечения претерпевает фундаментальные изменения, и разработчики адаптируют свои подходы, чтобы лучше защитить клиентов, которые на них полагаются. Годами все поставщики глобальных платформ, управляющие многоарендной облачной инфраструктурой, поддерживали документированные лимиты запросов, средства контроля использования и ограничения на применение недокументированных внутренних интерфейсов.
Платформы CRM устанавливают суточные лимиты на вызовы API для каждой организации, применяют ограничения на уровне платформ и поддерживают строгое разделение между API пакетной передачи данных и транзакционными интерфейсами REST. Платформы для повышения производительности и совместной работы ограничивают частоту запросов к своим графовым API (graph API) и перенаправляют пакетные рабочие нагрузки на специализированные каналы доступа к данным, созданные для таких нагрузок. Платформы HR и управления персоналом вводят ограничения на одновременные запросы и ограничения на извлечение данных за сеанс. Платформы управления ИТ-услугами устанавливают лимиты запросов на пользователя и регулирование пропускной способности на уровне инстансов. Крупнейшие облачные провайдеры (гиперскейлеры) публикуют квоты для каждого сервиса, применяют их на уровне инфраструктуры и прямо запрещают приложениям обращаться к неофициальным интерфейсам, не входящим в состав SDK.
Это не спорные меры. Это базовая гигиена для платформ корпоративного уровня, работающих с общей инфраструктурой в больших масштабах. Более десяти лет эти меры действуют без каких-либо серьезных возражений.
Поскольку SAP берет на себя ответственность за защиту критически важных рабочих нагрузок клиентов в облаке, единая политика в отношении API с уточненными правилами контроля использования — это не ограничение, а проявление корпоративной заботы. Некоторые восприняли эту политику как новое ограничение. Однако она не вводит новых ограничений. Она лишь называет и объединяет те меры контроля, которые годами существовали в рамках отдельных продуктов SAP.
SAP не вводит управление API как нечто принципиально новое. SAP SuccessFactors, SAP Ariba, SAP LeanIX и целый ряд других решений SAP уже давно применяли документированные лимиты запросов и средства контроля использования. Использование API также регламентировалось в прошлых заметках SAP Notes и документации SAP.
Суть новой политики заключается в том, чтобы объединить существующую практику в единый стандарт для всего портфолио. Этот шаг стал насущной необходимостью в связи с появлением автономных агентных систем (autonomous agentic harnesses). SAP полностью поддерживает их внедрение, однако они создают принципиально иную нагрузку на производительность, стабильность и безопасность интерфейсов API, которые изначально не проектировались для автономной оркестровки и масштабного извлечения данных.
Пользовательские интерфейсы: что политика SAP в отношении API ограничивает, а что нет
Пользовательские API, созданные клиентами в своем собственном пространстве имен для собственных целей расширяемости, интеграции и миграции, являются интерфейсами собственной разработки клиентов. Если вы годами создавали пользовательские службы данных, кастомные RFC и интерфейсы ABAP, чтобы связать свою систему SAP с окружающим миром, ограничение политики в отношении неопубликованных API при первом знакомстве может показаться приказом о сносе. Но это не так. Ограничение политики нацелено на собственные внутренние неизданные объекты SAP. Оно не затрагивает пространство имен Z и не отменяет результаты двух десятилетий разработки на ABAP.
Клиенты SAP Private Cloud находятся в значительно более привилегированном положении по сравнению со многими компаниями корпоративного сектора, поскольку они давно имеют возможность создавать решения в собственном пространстве имен и формировать среду, которую они могут свободно модифицировать и расширять, и эта свобода у них не отбирается.
Политика сосредоточена на более узком круге объектов: собственных внутренних интерфейсах SAP, которые никогда не публиковались, не документировались для использования клиентами и никогда не предлагались в качестве надежной основы для интеграции. Большинство пользовательских кодов никогда не затрагивают эти внутренние компоненты и будут работать без изменений; там же, где затрагивают, риски для клиентов существовали всегда, и политика лишь называет их своими именами, а не выдумывает.
Тем не менее, среди этого набора есть меньший класс интерфейсов, который не подлежит обсуждению — он просто запрещен. К такому классу относится ODP-RFC: он находится в пространстве имен SAP как внутренний, невыпущенный интерфейс, который SAP прямо классифицирует как «недопустимый» для использования клиентами или сторонними приложениями, как задокументировано в заметке SAP Note 3255746.
Именно такие интерфейсы SAP будет отмечать как запрещенные в примечаниях и автоматизированных инструментах, чтобы подобное использование можно было выявить на ранних этапах с помощью средств диагностики и рекомендаций, а не обнаруживать слишком поздно в процессе развертывания или эксплуатации. Концепция Clean Core («Чистое ядро») отличается от политики API, но направлена в ту же сторону. Стоит отметить, что клиенты не просто приняли ее, но и неоднократно просили о ней, столкнувшись с затратами на обновление в альтернативных сценариях. В эпоху искусственного интеллекта и агентов, когда SAP управляет критически важными ERP-системами как сервисом, как рекомендации Clean Core, так и политика API являются условиями надежности корпоративного уровня, которую делают возможной облачные технологии.
Как ИИ-агенты меняют шаблоны использования API в системах SAP
Хотя некоторые комментаторы утверждают, что эта политика носит преимущественно коммерческий характер, технические факты говорят об обратном.
Искусственный интеллект полностью изменил наше традиционное представление о транзакционных интерфейсах. API, которые предприятия использовали десятилетиями для интеграции систем SAP со сторонними приложениями, представляют собой интерфейсы запрос-ответ, созданные для транзакционных рабочих нагрузок. Они проектировались для получения заказа на продажу, регистрации поступления материалов или запуска платежной ведомости. Предполагалось, что вызовы к ним будут осуществляться преимущественно написанными людьми интеграционными потоками с предсказуемой частотой для определенных бизнес-целей. Они не были рассчитаны на то, чтобы автономная система оркестровки на базе ИИ выполняла к ним тысячи последовательных вызовов в поисках семантического контекста о заложенной внутри бизнес-модели. Это не шаблон интеграции «чистого ядра».
Многие участники дискуссии упускают из виду ключевое архитектурное различие. Традиционный инструмент интеграции считывает заказ на продажу из SAP, преобразует его в формат, необходимый целевой схеме, и передает дальше. Модель данных SAP при этом играет роль лишь транзитного этапа интерпретации.
ИИ-агент делает кое-что принципиально иное. Он не просто извлекает значение. Он считывает данные заголовка заказа на продажу и понимает, что эта структура представляет собой обязательство клиента по покупке. Он считывает данные товарных позиций и понимает, как отдельные позиции соотносятся с этим заказом. Он считывает чистую стоимость и понимает, что это число имеет смысл только в паре с валютой документа. Он прослеживает путь, который заказ на продажу проходит через отставку, выставление счетов и, наконец, бухгалтерский учет, и усваивает то, как SAP сводит операции и финансы воедино в рамках своей модели бизнес-объектов.
Агент не просто потребляет транзакционные данные клиента. Он потребляет семантическую онтологию: определения бизнес-объектов, связи между сущностями, концептуальную архитектуру, которую SAP создавала и совершенствовала на протяжении пяти десятилетий кодирования корпоративных знаний.
SAP уже давно проводит различие между предоставлением транзакционного доступа к клиентским данным и более широким извлечением или репликацией лежащей в их основе онтологии. Политика не создает эту границу, поскольку она уже существовала. Автономные агенты должны продолжать уважать эту границу, а не переопределять ее.
Риски безопасности в сторонних реализациях MCP
Существует также аспект безопасности, и он вполне реален. В ту же неделю, когда была опубликована эта политика, атака на цепочку поставок под названием Mini Shai-Hulud — вариант червя npm — незаметно скомпрометировала сотни программных пакетов. Пакеты npm из экосистемы SAP были скомпрометированы, и мы отреагировали на это этой рекомендацией по безопасности для клиентов. Это не теоретическая модель угроз. Это реальная среда угроз, в которой созданные сообществом серверы MCP подключаются к работающим системам SAP, выполняющим критически важные для бизнеса процессы.
В списке OWASP MCP Top 10 систематически описаны классы уязвимостей: отравление инструментов, внедрение подсказок (prompt injection), повышение привилегий за счет расширения области действия, неправильное управление токенами и компрометация цепочки поставок. Недавние исследования тысяч проанализированных реализаций MCP показывают, что большинство из них работают со статической долгоживущей учетной записью или имеют выявленные проблемы безопасности, а один скомпрометированный пакет в экосистеме MCP может привести к лавинообразному заражению сотен тысяч открытых сред разработки. Издание VentureBeat буквально на прошлой неделе сообщило о серьезной уязвимости выполнения команд, из-за которой под угрозой оказались до 200 000 серверов MCP.
Подумайте, что это значит на практике. ИИ-агент, который только что усвоил семантическую структуру вашей модели данных SAP и работает через общественный сервер MCP, переходит из разряда инструментов повышения производительности в категорию повышенного риска — риска, который объединяет широкий доступ к системе с постоянно эволюционирующей поверхностью атак.
Почему один лишь MCP не может запускать бизнес-процессы SAP
Дискуссия вокруг MCP также затушевала техническую реальность, с которой корпоративным архитекторам необходимо столкнуться лицом к лицу. Протокол Model Context Protocol (MCP) — это всего лишь сантехника. Он определяет, как модель искусственного языка вызывает инструмент. Он ничего не говорит о том, понимает ли модель назначение инструмента в бизнес-контексте, в какой последовательности должны вызываться инструменты, какие побочные эффекты вызовет конкретный вызов API или каковы будут последствия неправильного параметра. Наивная реализация MCP, подключающаяся к службам SAP OData, может вызвать инструмент. Но она не способна запустить бизнес-процесс.
Показательны данные о потреблении токенов в производственных агентных развертываниях. Для примера: запрос на поиск руководителя сотрудника с обходом списка коллег в системе SAP SuccessFactors при стандартной реализации MCP потребил 565 000 токенов. Тот же запрос при реализации с учетом контекста потребил 80 000 токенов. Это разница между запросом стоимостью $1,70 и запросом стоимостью $0,24, например, для одной операции, повторяющейся в ходе тысяч ежедневных транзакций. Стандартная реализация MCP — это вовсе не автоматизация. Это дорогая аппроксимация автоматизации, которая дает сбои при обработке сложных запросов и одновременно нагружает интерфейсы API трафиком, для которого они не предназначались.
Архитектура SAP для открытой сторонней интеграции ИИ через A2A
Реакция SAP на эти вызовы заключается не в закрытии экосистемы, а в создании правильной инфраструктуры для ее открытости. На этом различии стоит остановиться подробнее.
Политика в отношении API закрепляет требования соответствия в документированных, совместно разработанных архитектурах. Эталонные архитектуры агентной функциональной совместимости, разработанные совместно с ведущими технологическими партнерами, опубликованы и доступны в Центре архитектуры SAP (SAP Architecture Center). Они ранжируются в соответствии с требованиями клиентов и обновляются по мере проверки новых паттернов.
Двусторонняя интеграция SAP Joule и Microsoft 365 Copilot — самый наглядный пример того, как выглядит совместно разработанная агентная интеграция в рабочей среде: две системы искусственного интеллекта от двух разных вендоров работают в интерфейсах друг друга, причем ни одна из сторон не обходит модель безопасности другой. Одобренным путем для доступа внешних ИИ-агентов к SAP является шлюз агентов (Agent Gateway) по протоколу A2A с использованием эталонного подхода AI Golden Path в Центре архитектуры SAP. Граф знаний SAP, спецификация Open Resource Discovery (ORD) для метаданных и продукты данных SAP BDC обеспечивают тот слой контекста, который превращает подключение по протоколу во взаимодействии, способное решать бизнес-задачи. SAP также предлагает управляемые серверы MCP для CAP, UI5, Fiori Elements и заявляет о намерении распространить этот подход на другие среды разработки, включая разработку на ABAP. Это не закрытые двери — это правильные двери.
В сообществе стандартов SAP выступает как активный участник, а не привратник. SAP является одним из основателей протокола Agent2Agent (A2A) в рамках Linux Foundation и обладает золотым членством в фонде Agentic AI Foundation, сопредседательствуя в рабочей группе по идентификации и доверию агентов (Agent Identity and Trust) наряду с организациями, которые определяют, как ИИ-агенты проходят аутентификацию, авторизацию и взаимодействуют через корпоративные границы.
A2A и MCP — это не внешние ограничения, с которыми SAP смирилась из-под палки. Это протоколы, которые SAP использует внутри компании и активно укрепляет посредством работы над стандартами. Когда сообщество и фреймворки с открытым исходным кодом достигнут уровня безопасности, требуемого для корпоративного развертывания, появятся и пути внешней интеграции.
Опубликованная SAP политика в отношении API не знаменует собой конец открытости. Индустрия потратила два года на развертывание ИИ-агентов в корпоративных системах с использованием протоколов, которые сообщество корпоративной безопасности еще не успело полностью защитить, против API, которые никогда не проектировались для автономной оркестровки, с помощью инструментов сообщества, которые задокументированные злоумышленники уже научились взламывать. Управление безопасностью было не опцией, оно было своевременным.
Анирбан Маджумдар — руководитель аппарата технического директора (CTO) в SAP.
Спонсорские статьи — это контент, подготовленный компанией, которая либо оплачивает публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко промаркированы. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.
