Хранилища учетных данных поставщика для многомодельных шлюзов AI: отдельная среда выполнения, администрирование, выставление счетов и доступ BYOK
Практичный шаблон хранилища учетных данных для многомодельных шлюзов искусственного интеллекта: классифицируйте ключи вышестоящего поставщика, изолируйте среду выполнения от доступа администратора, привязывайте учетные данные BYOK к арендаторам, безопасную ротацию и проверяйте каждое решение по учетным данным.
Ключи нисходящего API и учетные данные вышестоящего поставщика решают разные проблемы. Ключ разработчика, выданный вашим шлюзом, идентифицирует приложение, команду, клиента, бюджет и контекст политики. Ключ вышестоящего поставщика позволяет шлюзу тратить деньги и получать доступ к моделям в учетной записи поставщика. Если относиться к ним как к одному и тому же секрету, команды в конечном итоге получают один неограниченный ключ в общем проекте, учетные данные администратора в службах среды выполнения и отсутствие надежного способа ответить, какой арендатор вызвал какую плату со стороны поставщика.
Практический образец — это хранилище учетных данных поставщика: выделенная плоскость управления для импорта, классификации, хранения, выбора, ротации и аудита восходящих учетных данных. Он должен находиться за маршрутизатором, регистром счетов, механизмом политик и рабочим процессом операций, а не внутри кода приложения, файлов конфигурации модели, записей клиентов или событий аналитики.
Проблема считывателя: учетные данные восходящего потока становятся невидимой инфраструктурой
Большинство развертываний с несколькими моделями начинаются с простой цели: направить один OpenAI-совместимый запрос к лучшему доступному поставщику. Затем появляются дополнительные учетные записи: один проект поставщика для производства, другой для оценки, рабочее пространство Anthropic для бизнес-подразделения, проект Google Cloud для Gemini и несколько предоставленных клиентом ключей для контрактов BYOK.
Риск заключается не только в утечке секретной информации. Это потеря контекста авторизации. Действительный ключ поставщика технически может быть способен вызвать конечную точку, но шлюзу все равно необходимо знать, разрешен ли этот ключ для этого клиента, этого семейства моделей, этой политики хранения данных, этого бюджета, этого региона и этого пути автоматизации.
Факт: платформы поставщиков предоставляют разные границы учетных записей и типы учетных данных. OpenAI документирует проекты и учетные записи служб, а разрешения ключа API учетной записи службы по умолчанию обеспечивают доступ на чтение и запись для ресурсов API проекта. OpenAI также предоставляет ключевые объекты API администратора отдельно от обычного использования API проекта или среды выполнения. Anthropic документирует рабочие пространства как организационные границы и заявляет, что конечным точкам Admin API требуются ключи Admin API, отличные от стандартных ключей API; Anthropic также отмечает, что ключи API привязаны к рабочему пространству, в котором они созданы, и не могут перемещаться между рабочими пространствами. В документации по ключу Gemini API Google говорится, что каждый ключ Gemini API связан с проектом Google Cloud, и рекомендуются ограничения API, чтобы уменьшить ущерб в случае компрометации ключа.
Рекомендация: не создавайте одно общее поле «provider_key» и не называйте это завершенным. Создайте реестр учетных данных, который сохранит границы, специфичные для поставщика, и при этом предоставит шлюзу нормализованную модель политики.
Определите таксономию учетных данных перед принятием ключей
Хранилище должно отклонять неоднозначные учетные данные. Во время импорта оператор или рабочий процесс автоматизации должны классифицировать учетные данные. Используйте как минимум следующие категории:
<ул>Эта таксономия — не просто документация. Он должен управлять контролем доступа, правомочностью маршрутизации, оповещением и ротацией рабочих процессов. Если учетные данные импортируются без категории, владельца, границ учетной записи поставщика и разрешенного использования, они должны оставаться отключенными.
Храните секреты в хранилище, а не в записях о продуктах
Хранилище должно быть единственным компонентом, который может расшифровать учетные данные восходящего потока. Другие системы могут хранить ссылки, хеши, поля статуса и метаданные политики, но не само значение учетных данных.
Не храните в этих местах секреты исходного кода
<ул>Пригодная для использования конструкция хранилища имеет две плоскости. Секретная плоскость хранит зашифрованные учетные данные и строго контролирует операции расшифровки. В плоскости метаданных хранятся несекретные атрибуты, используемые маршрутизацией и управлением. Маршрутизатору обычно требуется только идентификатор учетных данных и кратковременное извлечение секрета из памяти во время отправки, а не широкий доступ к базе данных для каждого ключа поставщика.
Защитите хранилище как ценную инфраструктуру: шифрование конвертов или управляемый KMS, строгие удостоверения служб, процедуры взлома, тестирование резервного копирования и восстановления, проверку доступа и оповещение о необычном расшифрованном томе. Центральное хранилище упрощает управление, но также концентрирует риски. Это компромисс.
Прикрепите метаданные политики к каждому учетным данным
Модель метаданных должна быть достаточно явной, чтобы шлюз мог решить, подходят ли учетные данные до того, как они коснутся конечной точки поставщика.
Практическая квалификационная запись включает в себя:
<ул>Сохраняйте эту модель нейтральной по отношению к поставщикам, но не стирайте реалии поставщиков. Ключ, привязанный к рабочему пространству Anthropic, и ключ Gemini, привязанный к проекту Google Cloud, не являются взаимозаменяемыми только потому, что оба могут генерировать текст. Это происхождение необходимо шлюзу для аудита, возврата платежей и безопасного переключения при сбое.
Отдельный доступ к среде выполнения, администрированию и оплате
Самое важное правило простое: ключ, используемый для вывода во время выполнения, не должен управлять организациями-поставщиками, рабочими пространствами, пользователями, проектами или административными ресурсами.
Трафик во время выполнения имеет большой объем и подвержен самой большой рабочей поверхности. Он проходит через маршрутизаторы запросов, логику повторов, обработчики потоковой передачи, адаптеры моделей и рабочие процессы инцидентов. Учетные данные администратора встречаются редко и оказывают большое влияние. Для них должен использоваться отдельный путь утверждения с коротким сроком жизни, именуемым «утверждением человеком», где это необходимо, строгим журналированием и отсутствием права на маршрутизацию во время выполнения.
Платежные данные также заслуживают отдельного разделения. Задание отчетности, которое согласовывает счета, не должно иметь возможности генерировать завершения, а ключ вывода во время выполнения не должен быть единственным способом получения отчетов об использовании. Если поставщик не предлагает детальное разделение, компенсируйте это с помощью шлюза: изолируйте учетные данные, ограничьте количество внутренних идентификаторов службы, которые могут их получить, и регистрируйте каждое использование.
Рекомендация. Сделайте класс учетных данных жесткой границей авторизации, а не меткой. Диспетчер среды выполнения не должен иметь возможности запросить расшифровку учетных данных администратора, даже если ошибка конфигурации ссылается на его идентификатор.
Создание механизма политики выбора учетных данных
Выбор учетных данных должен происходить после того, как шлюз аутентифицирует нижестоящего вызывающего абонента и до попытки вызова провайдера. Механизм политики должен объединить несколько входных данных:
<ул>Система должна возвращать один из трех результатов: разрешить с выбранными учетными данными, отклонить с указанием политики или потребовать утверждения. Отказы должны быть достаточно точными, чтобы оперативные группы могли устранить проблему, не раскрывая секретные материалы разработчикам.
Пример решения:
{
"tenant_id": "tenant_42",
"requested_profile": "fast-text-prod",
"endpoint": "chat.completions",
"data_policy": "no_prompt_logging",
"credential_requirements": {
"класс": "время выполнения",
«окружающая среда»: «производство»,
"tenant_binding": "tenant_42",
"allowed_model_family": "текст",
"health_status": "здоров"
},
«решение»: «разрешить»,
"credential_id": "cred_8f2...",
"audit_reason": "Учетные данные BYOK клиента соответствуют текстовому профилю среды выполнения и политике данных"
Не реализуйте откат типа «попробуйте следующий ключ». Резервный вариант должен повторно запустить политику. Учетные данные общей платформы могут быть действительны для доступа поставщика, но недействительны для клиента, использующего только BYOK. Учетные данные в другом проекте могут иметь квоту, но могут нарушать требования к распределению или сохранению затрат.
Рассматривайте BYOK как доступ, принадлежащий арендатору, а не как резервную мощность
BYOK меняет модель доверия. Клиент предоставил учетные данные, чтобы его трафик можно было взимать, регулировать или изолировать в учетной записи поставщика. Эти учетные данные должны быть привязаны к источнику учетной записи арендатора клиента и поставщика.
Рекомендуемые элементы управления BYOK:
<ул>Для агентств, реселлеров и партнеров по автоматизации API BYOK может быть более сложным, поскольку служба может предоставлять клиентов и учетные данные программным способом. То же правило по-прежнему применяется: автоматизация может импортировать и привязывать учетные данные, но она не должна размывать владение арендатором.
Добавьте предполетную проверку работоспособности без утечки подсказок
Учетные данные могут не работать по многим причинам: отозван ключ, неправильное рабочее пространство, отсутствие доступа к модели, отключение выставления счетов, исчерпание квоты, ограничение конечных точек, несоответствие региональной политики или сбой в работе поставщика. Обнаружение этого только после поступления производственного запроса приводит к шумным инцидентам.
Используйте проверки работоспособности, которые проверяют возможности без отправки запросов клиентам. Синтетическая проверка может вызвать минимальную конечную точку, перечислить разрешенные модели, где это необходимо, или отправить безобидное фиксированное приглашение, если это единственный практический вариант. Пусть эти проверки будут дешевыми, ограниченными по скорости и помеченными как синтетический трафик в телеметрии и выставлении счетов.
Необходимо выполнить проверку работоспособности:
<ул>Компромисс: автоматические проверки рано выявляют ключи с истекшим сроком действия или недостаточной областью действия, но плохо разработанные проверки могут привести к ненужным звонкам поставщикам, шуму при выставлении счетов или ложным срабатываниям сигналов тревоги во время перебоев в работе поставщика. Сохраните результат работоспособности с отметкой времени, классом ошибки поставщика, протестированной конечной точкой и протестированным семейством моделей. Не храните секретные значения или конфиденциальные запросы.
Ротация с двумя слотами, а не с одной рискованной заменой
Ротация учетных данных не должна быть операцией «удалить и выполнить». Используйте модель ротации с двумя слотами:
<ол>Сроки ротации должны быть видны в операционных представлениях и оповещениях. Для экстренной ротации требуется более короткий путь: отключить учетные данные, заблокировать маршрутизацию, разрешить утвержденную замену и сохранить все записи аудита для анализа инцидентов.
Ограничить использование ключей поставщика там, где поставщик это поддерживает
Политика шлюза необходима, но ограничения на стороне провайдера уменьшают радиус атаки, если ключ скомпрометирован или используется неправильно. Для ключей API Gemini и других облачных платформ используйте ограничения API/сервисов и подходящие ограничения приложений, если они доступны. При работе с проектами поставщиков, рабочими областями и учетными записями служб избегайте широких организационных привилегий, если достаточно ключа среды выполнения на уровне проекта.
Рекомендация: ведите контрольный список ограничений на стороне поставщика для каждого класса учетных данных. Контрольный список должен быть частью одобрения импорта и ротации, а не отдельной задачей безопасности, которую можно пропустить под давлением.
Компромисс. Ограничения на стороне поставщика увеличивают операционные издержки. Новые конечные точки, семейства моделей, регионы или функции автоматизации могут потребовать изменения политики и ограничений. Это предпочтительнее, чем обнаружить после утечки, что один ключ может получить доступ ко всем рабочим нагрузкам в общем проекте.
Сохраняйте журнал аудита учетных данных только для добавления
В журнале аудита должно быть указано, кто импортировал учетные данные, что ему было разрешено делать, какие решения по маршрутизации выбрали его, когда произошел сбой, а также когда он был заменен или отозван.
Зарегистрируйте эти события:
<ул>Не добавляйте необработанные значения учетных данных в события аудита. Используйте идентификаторы учетных данных, границы учетных записей поставщика, идентификаторы трассировки запросов, идентификаторы субъектов и причины принятия решений по политике. Для большого объема трафика во время выполнения вы можете получить подробные данные расшифровки телеметрии, но выбор маршрутизации и распределение затрат должны оставаться достаточно полными для выставления счетов и реагирования на инциденты.
Контрольный список реализации
<ул>Практическое заключение
Начните с инвентаризации всех учетных данных вышестоящего поставщика, которые в настоящее время используются шлюзом, сценариями, заданиями CI, средствами оценки и средствами автоматизации партнеров. Для каждого из них назначьте класс, владельца, границу учетной записи поставщика, привязку клиента, разрешенные конечные точки, разрешенные семейства моделей, крайний срок ротации и статус аварийного отключения. Все, что вы не можете классифицировать, следует отключить или поместить в карантин до тех пор, пока у него не будет четкой цели.
Затем примените одно архитектурное правило: последующие разработчики получают ключи области шлюза; только шлюз контролирует доступ вышестоящего провайдера. Такое разделение позволяет сохранить минимальные привилегии, атрибуцию арендаторов, точность выставления счетов, маршрутизацию политик данных и безопасную автоматизацию даже при увеличении количества поставщиков, проектов, рабочих пространств и клиентов BYOK.