Согласование плоскости управления для шлюзов AI API

Шлюз AI API может сделать доступ во время выполнения унифицированным, в то время как плоскости управления вышестоящего поставщика продолжают дрейфовать. Команды часто централизуют вызовы логических выводов, выставление счетов, управление ключами API и аналитику использования на шлюзе, а затем оставляют проекты OpenAI, рабочие области Anthropic, проекты Google Cloud, ключи Gemini, сервисные учетные записи, бюджеты и области отчетности для настройки вручную. Это создает режим тихого сбоя: шлюз сообщает, что существует одна политика клиента, но учетная запись провайдера применяет или сообщает о чем-то другом.

Практическим примером является согласование плоскости управления. Рассматривайте административные объекты вышестоящего поставщика как инвентарь. Сравните наблюдаемый инвентарь с желаемой политикой клиента в шлюзе. Делайте выводы о отклонениях, корректируйте маршруты путем одобрения и резервируйте автоматические действия для состояний явно высокого риска.

В этой статье разделены факты, рекомендации и прогнозы. Факты – это поведение поставщиков, задокументированное сегодня. Рекомендации — это выбор архитектуры для оператора шлюза. Прогнозы, вероятно, создают операционное давление по мере развития стеков искусственного интеллекта с несколькими поставщиками.

Как выглядит изменение после внедрения шлюза

Шлюзы среды выполнения решают один уровень проблемы: приложения отправляют запросы к общей конечной точке, арендаторы получают ключи шлюза с ограниченной областью действия, а использование фиксируется в одном реестре. Но объекты вышестоящего поставщика по-прежнему имеют значение. Они решают, какому проекту или рабочему пространству принадлежит ключ, в какие отчеты включаются расходы, какие ограничения по тарифам и ресурсам применяются, а также какие меры экстренного контроля доступны.

Общие примеры отклонений включают в себя:

• Арендатор сопоставлен с проектом OpenAI в шлюзе, но ключ времени выполнения по-прежнему принадлежит общему проекту по умолчанию.
• Ключ Anthropic API был создан в неправильном рабочем пространстве и не может быть перемещен в предназначенное.
• Ключ Google API был создан. вне потока консоли и остается неограниченным, поскольку ограничения никогда не устанавливались явно.
• Порог расходов поставщика ниже, чем бюджет арендатора шлюза, что приводит к сбоям на стороне поставщика до того, как шлюз их ожидает.
• Порог расходов поставщика выше, чем политика шлюза, в результате чего учетная запись поставщика остается слабой опорой.
• Отчеты об использовании содержат нулевые или унаследованные поля рабочей области, поэтому финансы не могут четко согласовать затраты поставщика с арендаторами шлюза.
• A Сервисная учетная запись выдерживает увольнение сотрудника, поскольку она не привязана к модели владения шлюзом.

Риск заключается не только в безопасности. Дрейф нарушает атрибуцию, реагирование на чрезвычайные ситуации, контроль затрат и возможность аудита.

Факты, которые следует сохранить в проекте

Плоскости управления поставщика не являются взаимозаменяемыми. Средство согласования должно нормализовать достаточно данных, чтобы операторы могли эффективно работать, но при этом сохранять семантику, специфичную для поставщика.

Проекты OpenAI

Факт: проекты OpenAI позволяют организациям организовывать работу, управлять доступом и ограничениями, предоставлять учетные записи служб и отслеживать использование в рамках проекта. Использование можно разбить по проектам, а лимиты расходов можно установить для каждого проекта.

Факт: учетные записи сервисов проекта OpenAI уникальны для проекта, в котором они созданы. Сгенерированный ими секретный ключ отображается один раз, и для его потери требуется создание нового ключа.

Факт: ключи API OpenAI поддерживают такие уровни разрешений, как «Все», «Ограничено» и «Только чтение». Разрешения ключа API сервисного аккаунта по умолчанию предусматривают доступ на чтение и запись ко всем ресурсам API проекта, если они не изменены.

Факт: документация OpenAI описывает ежемесячные лимиты расходов проекта как мягкие пороговые значения в одной справочной статье, а в материалах по устранению неполадок также документируются ошибки жесткого ограничения, такие как project_spend_limit_exceeded. Шлюз не должен предполагать, что каждый настроенный лимит расходов поставщика ведет себя как синхронное жесткое ограничение в каждой конфигурации учетной записи.

Anthropic Workspaces

Факт: Anthropic Workspaces организует ключи API, командный доступ и затраты. Дополнительные рабочие области могут содержать участников, учетные записи служб, ключи API и ограничения ресурсов.

Факт: ключи API привязаны к рабочей области, в которой они созданы, и не могут перемещаться между рабочими областями. Anthropic оценивает применимые ограничения рабочего пространства и организации при каждом запросе.

Факт: рабочее пространство по умолчанию имеет особое поведение при составлении отчетов. В отчетах об использовании и расходах может отображаться нулевой идентификатор workspace_id, что имеет значение, когда шлюз пытается сопоставить отчеты поставщика обратно с арендаторами.

Факт: API Anthropic Admin and Analytics охватывают администрирование организации и рабочего пространства, ключи API, отчеты об использовании, отчеты о расходах и соответствующую аналитику, но доступ зависит от ключей администратора и соответствия учетной записи или роли.

Google Cloud и Gemini Keys

Факт: в руководстве по ключам Google Cloud API указано неограниченное количество ключей API небезопасны. Ограничения API ограничивают возможности вызова API, а ограничения приложений ограничивают возможности использования ключа.Google рекомендует устанавливать оба варианта, где это применимо.

Факт: в документации Google Cloud указано, что ключи API, созданные через консоль, требуют хотя бы одного ограничения API, в то время как ключи, созданные через gcloud или REST, не имеют ограничений, если ограничения не указаны явно.

Факт: в документации Google AI for Developers говорится, что Gemini API переходит от стандартных ключей к ключам авторизации, неограниченные стандартные ключи отклоняются, а стандартные ключи необходимо перенести на ключи авторизации до сентября 2026 года, чтобы избежать обслуживания. прерывание.

Факт: бюджеты Google Cloud Billing с оповещениями не ограничивают расходы автоматически. Программные уведомления Pub/Sub могут автоматизировать ответы по контролю затрат, но доставка Pub/Sub осуществляется хотя бы один раз, и сообщения могут приходить не по порядку.

Эталонная архитектура

Рекомендация: создайте сверку как службу плоскости управления рядом со шлюзом среды выполнения, а не внутри пути горячих запросов. Он должен считывать поверхности администрирования поставщика, сравнивать их с политикой арендатора шлюза и генерировать события отклонения.

Практическая архитектура состоит из пяти частей:

• Хранилище желаемого состояния: политика арендатора шлюза: арендатор, владелец, разрешенные поставщики, профили модели, бюджетная политика, политика ставок, разрешенные вышестоящие проекты или рабочие области, ключевое владение и аварийный статус.
• Инвентаризация наблюдаемого состояния: объекты поставщика, обнаруженные с помощью администратора API, экспорт счетов, экспорт в консоль или запланированное сканирование.
• Адаптеры поставщиков: OpenAI, Anthropic, Google Cloud и другие сборщики данных для конкретного поставщика, которые сохраняют собственные идентификаторы и семантику.
• Механизм дрейфа: детерминированные сравнения, которые дают результаты, а не незаметно изменяют состояние поставщика.
• Рабочий процесс исправления: заявки, утверждения, оповещения в чате и узкие области автоматические действия с ограниченной областью действия для предотвращения отклонений с высоким риском.

Шлюз остается источником достоверной информации о выставлении счетов арендаторам. Отчеты поставщика о расходах и использовании становятся входными данными для расчетов и сигналами об аномалиях. Это различие важно, поскольку отчеты поставщика могут запаздывать, использовать разные измерения или отображать поля отчета, которые не четко сопоставляются с арендаторами шлюза.

Нормализация инвентаризации, а не потеря смысла

Рекомендация: используйте нормализованную таблицу инвентаризации, но включайте собственные поля поставщика. Не считайте, что проект OpenAI, рабочая область Anthropic и проект Google Cloud — это один и тот же объект.

Полезная модель инвентаризации включает:

• поставщик: openai, anthropic, google, azure или другое имя адаптера.
• provider_account_id: идентификатор организации, платежного аккаунта или облачного аккаунта.
• container_type: проект, рабочее пространство, облачный проект, папка или учетная запись.
• container_id: собственный идентификатор проекта или рабочей области поставщика.
• container_name: удобочитаемая метка от поставщика.
• tenant_id: клиент сопоставленного шлюза или значение NULL, если оно не сопоставлено.
• service_account_id: учетная запись службы поставщика или идентификатор рабочей нагрузки, где доступно.
• api_key_id: отпечаток ключа, идентификатор ключа или хешированный идентификатор ключа. Не храните необработанные секреты поставщика в этой таблице.
• key_scope: проект, рабочая область, организация, ограничение приложения, ограничение API или эквивалентная область, зависящая от поставщика.
• разрешения: собственный уровень разрешений, привязка роли, список ограниченных возможностей или состояние чтения/записи.
• model_allowlist: модели или семейства API, к которым может получить доступ ключ, где поставщик раскрывает их. control.
• rate_policy: наблюдаемый предел поставщика и политика шлюза, которую он должен поддерживать.
• spend_policy: наблюдаемое пороговое значение или бюджет поставщика и бюджетная политика арендатора шлюза.
• reporting_scope: измерения, ожидаемые в отчетах поставщика, включая известные нулевые или унаследованные поля.
• last_seen_at: временная метка самого последнего сканирование.
• владелец: арендатор шлюза, команда, владелец службы или владелец человека.
• источник: API администратора, экспорт счетов, экспорт консоли, импорт конфигурации или ручное подтверждение.

Эта таблица должна быть удобна для добавления. Операторам нужна история: когда ключ впервые появился, когда он перестал появляться, когда изменились его разрешения и какой сканер заметил это изменение.

Явно определите желаемое состояние

Рекомендация. Согласование работает только в том случае, если желаемое состояние является конкретным. Такая политика, согласно которой арендатор А может использовать Anthropic, слишком расплывчата.Такая политика, как клиент А, должна использовать рабочую область ws_123, учетную запись службы svc_billing_prod, отсутствие ключей времени выполнения, принадлежащих человеку, быстрая поддержка профиля модели и порог расходов поставщика от 80 до 110 процентов бюджета шлюза.

Желаемое состояние должно включать следующее:

• Какие восходящие контейнеры могут использоваться каждым арендатором.
• Использует ли клиент принадлежащие шлюзу учетные данные, учетные данные BYOK арендатора или и то, и другое.
• Должны ли ключи времени выполнения принадлежать сервисному аккаунту.
• Какие API и модели поставщика разрешены.
• Максимально и минимально допустимые пороговые значения расходов на исходящие ресурсы.
• Ожидаемые параметры отчетности поставщика для расчета.
• Требуемые ограничения приложений и API для ключей Google.
• Аварийное отключение для каждого поставщика и арендатор.

Сохраните желаемое состояние в таблице политик с поддержкой версий. Каждое обнаруженное отклонение должно ссылаться на версию политики, используемую для сравнения. Это делает возможными проверки и откат, когда изменения в политике приводят к появлению множества новых результатов.

Внедрить операторы классов отклонения, на которые могут действовать

Рекомендация: публиковать типизированные результаты отклонения. Избегайте общих предупреждений о несоответствии. Операторы должны знать, что сломалось, почему это важно и какие действия разрешены.

К полезным дрейфующим классам относятся:

• missing_container: политика клиента предполагает, что проект поставщика или рабочая область не существует или не видна сканеру.
• unmapped_container: проект поставщика, рабочая область или облачный проект существует, но не имеет клиента. сопоставление.
• wrong_container: ключ, используемый трафиком клиента, принадлежит другому проекту или рабочей области, чем разрешено политикой.
• stale_key: ключ поставщика не был замечен в трафике шлюза в течение определенного периода, но остается активным в восходящем направлении.
• orphaned_owner: ключ или учетная запись службы принадлежит отключенному пользователю или не сопоставлен личность.
• excessive_permission: ключ имеет более широкие разрешения поставщика, чем того требует политика шлюза.
• unrestricted_google_key: ключ Google не имеет необходимых ограничений API, ограничений приложений или состояния миграции авторизации, совместимой с Gemini.
• limit_below_policy: ограничения поставщика могут блокировать трафик до политики шлюза. ожидает.
• limit_above_policy: ограничения поставщика слишком разрешительны, чтобы служить защитой.
• reporting_unreconcilable: отчеты об использовании поставщика или расходах не могут быть четко сопоставлены с клиентом, ключом, проектом или рабочей областью.
• scanner_blind: необходимые API-интерфейсы администратора или роли отсутствуют, поэтому средство согласования не может выполнить утверждение.

Каждый результат должен включать серьезность, достоверность, затронутого клиента, собственные идентификаторы поставщика, время первого наблюдения, время последнего наблюдения, рекомендуемое действие, разрешенные автоматические действия и метаданные отката.

Устранение: начать с нуля, автоматизировать узко

Рекомендация: по умолчанию выполняется пробный прогон результатов перед мутацией. Учетные данные администратора поставщика являются мощными. Неправильное сопоставление может привести к отключению производственных рабочих нагрузок, удалению атрибуции или созданию дорогостоящего простоя.

Двухэтапная модель работает хорошо:

• Уведомление и уведомление: для случаев с низким уровнем риска или неоднозначных отклонений, таких как отсутствие меток владельца, несопоставленные поля отчетов или пороговые значения расходов, немного выходящие за рамки политики.
• Предварительно одобренное автоматическое действие: для узких случаев с высоким риском, таких как утечка ключей, ключей принадлежат отключенным пользователям, неограниченным ключам с поддержкой Gemini или ключам, привязанным к арендаторам, уже отключенным в шлюзе.

По возможности автоматизация должна быть обратимой. Например, отключение ключа шлюза легче отменить, чем удаление восходящего ключа. После раскрытия может потребоваться смена ключа вышестоящего поставщика, но для этого требуется координация развертывания нижестоящего поставщика. Снижение бюджета шлюза до нуля происходит немедленно и поддается проверке, в то время как оповещения о бюджете поставщика могут запаздывать или вести себя асинхронно.

Сборник сценариев аварийного отключения

Рекомендация: напишите модуль выполнения аварийного отключения поставщика до того, как он понадобится.Он должен охватывать как элементы управления шлюзом, так и элементы управления поставщиком.

Практическая последовательность действий такова:

1. Отметьте затронутые ключи шлюза отключенными, чтобы новые запросы среды выполнения останавливались на шлюзе.
2. Установите бюджет шлюза клиента или лимит резервирования расходов на ноль.
3. Заблокируйте маршрутизацию клиента к затронутому поставщику или профилю модели.
4. Отзовите, отключите или поменяйте ключи восходящего поставщика, если это поддерживается.
5. Снизьте пороговые значения на стороне поставщика, если они доступны и полезны для конфигурацию учетной записи.
6. Записывайте каждое действие с указанием субъекта, отметки времени, причины, объекта поставщика и инструкции по откату.
7. Согласуйте использование и затраты на стороне поставщика после сообщения о задержках распространения.
8. Откройте обзор изменений после инцидента: как объект стал неуправляемым и какая проверка политики должна была обнаружить его раньше?

Эта последовательность намеренно сначала останавливает трафик на шлюзе. Элементы управления поставщика по-прежнему важны, но они могут различаться по скорости, доступности и семантике применения.

Компромиссы

Автоматическая сверка уменьшает дрейф, но для нее требуются учетные данные администратора. Рекомендация: изолируйте учетные данные администратора от учетных данных среды выполнения, храните их в отдельном пути к хранилищу, ограничивайте права на изменение и проверяйте каждое чтение и запись.

Один вышестоящий проект или рабочее пространство на каждого арендатора улучшает атрибуцию и контроль радиуса распространения. Компромиссом является разрастание объектов, ограничения поставщиков, операционные накладные расходы и сложности с общим кешем, выделенной емкостью или стратегиями объединенной пропускной способности.

Ограничения поставщиков обеспечивают полезную поддержку, но они не заменяют резервирование бюджета на стороне шлюза. Ограничения поставщика могут быть мягкими, асинхронными, зависеть от плана или оцениваться по-разному в зависимости от запросов и отчетов.

Частое сканирование обнаруживает отклонение быстрее, но увеличивает использование API администратора, давление на квоты и объем предупреждений. Лучшей схемой являются обновления, управляемые событиями, если они доступны, а также запланированная сверка для обеспечения полноты.

Нормализация делает информационные панели удобными для использования, но чрезмерная нормализация скрывает важные различия. Держите собственные поля поставщика видимыми в выводах и отчетах.

Прогнозы

Прогноз: операторы шлюзов AI API будут все чаще рассматривать объекты администрирования поставщика как регулируемую конфигурацию, аналогичную конфигурации облачного IAM и платежного аккаунта. Проксирование во время выполнения само по себе не удовлетворит отделы финансов, безопасности или платформы, поскольку расходы и масштабирование доступа к многочисленным арендаторам не удовлетворят.

Прогноз: ключевые модели будут продолжать меняться. Наглядным примером является переход Gemini от стандартных ключей к ключам авторизации. Системы сверки, которые хранят собственный тип объекта поставщика, состояние миграции и последний обнаруженный источник, будут обрабатывать эти изменения лучше, чем системы, которые хранят только необработанный секретный ключ и имя поставщика.

Прогноз: отчеты поставщика останутся полезными для урегулирования, но неравномерными для принудительного исполнения в реальном времени. Шлюзы, которые ведут собственную книгу запросов, модель резервирования и атрибуцию арендаторов, будут более предсказуемыми, чем шлюзы, которые ждут экспорта счетов поставщика.

Контрольный список реализации

• Создайте таблицу политики желаемого состояния для сопоставлений между арендатором и поставщиком.
• Создайте наблюдаемую таблицу инвентаризации с собственными идентификаторами поставщика и хешированными идентификаторами ключей.
• Создайте адаптеры поставщика, доступные только для чтения. в первую очередь.
• Классифицируйте сбои сканера как выводы, а не скрывайте их.
• Выдавайте типизированные события смещения с серьезностью и уверенностью.
• Направляйте результаты в заявки, оповещения или очереди утверждения.
• Включайте автоматические действия только для узких, предварительно утвержденных классов высокого риска.
• Храните учетные данные администратора отдельно от учетных данных времени выполнения.
• Объединяйте записи реестра шлюза с отчетами поставщика для урегулирования и аномалий. обнаружение.
• Протестируйте аварийное завершение работы в непроизводственном клиенте, прежде чем полагаться на него.

Полезный вывод

Не останавливайтесь на маршрутизации вызовов вывода через общую конечную точку. Если вышестоящие плоскости управления смещаются, шлюз все равно может потерять атрибуцию, пропустить устаревшие ключи, неправильно прочитать поведение поставщика по расходам или выйти из строя во время чрезвычайной ситуации.

Самый сильный шаблон прост: напишите желаемую политику клиента в шлюзе, просканируйте наблюдаемые объекты поставщика, сохраните значение, специфичное для поставщика, выдайте типизированные результаты отклонения и исправьте ситуацию с помощью контролируемого рабочего процесса. Запуск только для чтения. Докажите наличие инвентаря.Затем автоматизируйте только те действия, риск которых ниже, чем ошибка, которую они исправляют.

Связанное чтение

• отдельные учетные данные среды выполнения, администратора, выставления счетов и BYOK
• регистр выставления счетов на стороне шлюза и резервирование бюджета
• отключение и сервисный аккаунт правила владения