Проверка доступа к AI API — это контроль, который подтверждает, что у каждого ключа шлюза по-прежнему есть правильный владелец, область действия, среда, план ротации и процедура офбординга. Это не просто сканирование секретов. Это периодическая проверка, которая задает вопросы: должен ли каждый ключ все еще существовать, кто несет за него ответственность, к чему он имеет доступ, какие расходы он может создавать, какие журналы подтверждают его использование и что происходит, когда уходит сотрудник, поставщик, проект или рабочая нагрузка.
Для шлюзов ИИ это важнее, чем для обычных API-ключей отдельных сервисов. Один учетный ключ шлюза может иметь доступ ко многим моделям, провайдерам, семействам эндпоинтов, бюджетам и продуктам. Устаревший ключ может поддерживать работу выведенной из эксплуатации автоматизации. Ключ с широкой областью действия может позволить задаче в песочнице вызывать производственные модели. Ключ уволившегося подрядчика может по-прежнему отправлять запросы через общую интеграцию. Резервный маршрут может продолжать использовать провайдера, которого отдел закупок больше не одобряет.
Используйте эту проверку доступа к AI API, чтобы превратить доступ к шлюзу в файл доказательств, принадлежащий покупателю. Проверка должна позволить командам безопасности, платформы, закупок, финансов и продукта позже ответить на одни и те же вопросы: кто владелец этого ключа, почему он существует, какие области действия разрешены, когда он был ротирован, какие маршруты он может вызывать и какое событие офбординга его отзывает?
Для покупателей Flatkey проверка относится к учетной записи шлюза и области ключей/маршрутов. Текущий публичный сайт Flatkey позиционирует продукт как единый шлюз AI API для доступа к моделям, маршрутизации, биллинга, аналитики использования и операционного контроля, с одним API-ключом, одним базовым URL и одной панелью управления. Это делает шлюз удобным местом для централизации доказательств доступа. Это не отменяет необходимости проверять специфичные для учетной записи роли, журналы, обработку необработанных данных, условия провайдера и процедуры офбординга перед использованием в производственной среде.
Что должна решать проверка доступа к AI API
Проверка доступа к AI API должна утверждать учетные данные и маршрут, к которому они имеют доступ. Если проверка останавливается на этапе «ключ все еще работает», она упускает риск управления.
| Область проверки | Принимаемое решение | Сохраняемые доказательства | Условие сбоя |
|---|---|---|---|
| Бизнес-цель | Какому продукту, рабочему процессу или команде нужен этот ключ? | Запись о варианте использования, одобрение владельца, тег среды | Нет текущего бизнес-владельца |
| Владелец-человек | Кто принимает на себя риск и бюджет для этого ключа? | Именованный владелец, резервный владелец, привязка к менеджеру или команде | Владелец уволен, неизвестен или является только общим почтовым ящиком |
| Технический владелец | Кто может ротировать, отключать и устранять неполадки с ключом? | Runbook, дежурная группа, путь к хранилищу ключей | Никто не может безопасно его ротировать |
| Среда | Это доступ для разработки, тестирования, производства, CI, поставщика или экстренный доступ? | Тег среды, граница проекта, конфигурация маршрута | Ключ непроизводственной среды может вызывать производственные маршруты |
| Область действия | Какие модели, эндпоинты, инструменты, файлы, промпты, экспорты использования, административные API или маршруты он может использовать? | Список областей действия, сопоставление ролей, настройки провайдера | Область действия шире, чем требуется для рабочей нагрузки |
| Бюджет и квота | Какие лимиты на расходы, токены, частоту запросов и модели применяются? | Политика квот, владелец оповещений, финансовый ревизор | Ключ может расходовать средства без именованного владельца |
| Логирование и аудит | Какие события подтверждают использование и изменения? | Метаданные запроса, журналы изменений маршрутов, журналы изменений ключей, строки использования | Использование не может быть связано с ключом, владельцем, маршрутом и временем |
| Ротация | Как будет заменен старый ключ без простоя? | Дата ротации, переход на второй ключ, проверка последнего использования, подтверждение удаления | У ключа нет триггера ротации или истечения срока действия |
| Офбординг | Какое событие отзывает доступ? | Триггер ухода сотрудника/поставщика/завершения проекта, удаление из группы, запись об отключении ключа | Ключ продолжает действовать после ухода пользователя, поставщика или завершения проекта |
Результатом является реестр доступа плюс список действий: сохранить, сузить, ротировать, переназначить, отключить, удалить или эскалировать.
Сначала создайте реестр ключей
Не начинайте проверку доступа к AI API со слепой ротации ключей. Создайте реестр, который описывает фактическую роль ключа в производственной среде.
Каждый ключ шлюза должен иметь следующие поля:
| Поле | Почему это важно |
|---|---|
| Псевдоним или ID ключа | Позволяет проверяющим обсуждать ключ, не раскрывая его секретное значение |
| Проект или рабочее пространство шлюза | Разделяет границы продукта, среды, клиента или команды |
| Владелец и резервный владелец | Предотвращает появление бесхозного доступа и задержки в ротации |
| Рабочая нагрузка или интеграция | Показывает, почему ключ существует и где он развернут |
| Среда | Предотвращает совместное использование учетных данных между средами разработки, тестирования, CI и производства |
| Разрешенные маршруты и модели | Делает проверку доступа к ИИ специфичной для поведения модели и эндпоинта |
| Разрешенные эндпоинты и инструменты | Фиксирует, может ли ключ вызывать чат, изображения, видео, файлы, выполнение инструментов или административные API |
| Область действия или роль | Подтверждает принцип наименьших привилегий вместо унаследованного административного доступа |
| Место хранения секрета | Показывает, находится ли ключ в хранилище, хранилище секретов CI, локальном файле или неподдерживаемом месте |
| Последнее использование и шаблон использования | Отделяет активные ключи от устаревших или скомпрометированных учетных данных |
| Владелец затрат и квота | Связывает расходы на модель с владельцем бюджета |
| Дата и метод ротации | Показывает, когда и как ключ может быть заменен |
| Триггер офбординга | Определяет, какое изменение отзывает или сужает доступ |
Реестр не должен содержать секретные значения. Он должен содержать достаточно метаданных для быстрой ротации и отзыва ключа.
Назначайте владельцев перед областями действия
Проверка доступа к AI API не проходит, если каждый ключ принадлежит «инженерному отделу» или «команде платформы». Общее владение приводит к тому, что доступ сохраняется после ухода сотрудников, подрядчиков, поставщиков и завершения проектов.
Используйте четыре роли владельца:
| Роль владельца | Отвечает за | Должен утверждать |
|---|---|---|
| Бизнес-владелец | Необходимость доступа к ИИ для рабочего процесса | Сохранение, отзыв или передача ключа |
| Технический владелец | Ротация, хранение, развертывание, откат и реагирование на инциденты | План ротации и подтверждение перехода |
| Владелец по безопасности | Область действия, принцип наименьших привилегий, ведение журналов, раскрытие данных и офбординг | Изменения области действия и обработка исключений |
| Владелец по финансам или операциям | Расходы, квоты, аномалии использования и сверка счетов | Бюджет и политика квот |
Бизнес-владелец и технический владелец не должны быть одним и тем же лицом, если только команда не очень маленькая. Для производственного ключа нужен кто-то, кто принимает на себя бизнес-риски, и кто-то, кто может безопасно изменить учетные данные.
Для ключей, принадлежащих людям, укажите конкретного человека и команду. Для ключей, принадлежащих сервисам, укажите сервисную учетную запись, идентификатор рабочей нагрузки, репозиторий, конвейер развертывания и группу владельцев. Для ключей поставщиков укажите владельца контракта, владельца данных, дату истечения срока действия и план удаления.
Проверяйте области действия на соответствие реальной рабочей нагрузке
Принцип наименьших привилегий — основа проверки доступа к AI API. Вопрос не в том, «нужен ли этому пользователю ИИ?», а в том, «какие именно действия API необходимы для этой рабочей нагрузки?»
Руководство по RBAC от OpenAI — полезная модель, поскольку она разделяет роли в организации, роли в проекте, группы, разрешения, ключи API проекта, администрирование проекта и сервисные учетные записи. В нем также отмечается, что границы проекта могут изолировать эксперименты, промежуточные среды (staging) и производственные среды. Используйте тот же подход для любого шлюза ИИ: ограничьте область действия ключа наименьшим проектом, маршрутом, конечной точкой, классом моделей и набором действий, которые поддерживают рабочую нагрузку.
Документация OpenAI по федерации удостоверений рабочих нагрузок добавляет еще один важный шаблон: внешние удостоверения могут быть сопоставлены с определенной сервисной учетной записью, проектом и необязательными разрешениями API, и эти разрешения сопоставления не могут предоставлять доступ за пределами сопоставленной сервисной учетной записи. Это правильная ментальная модель для доступа к шлюзу: задание CI, серверная рабочая нагрузка или автоматизация не должны наследовать широкий доступ к консоли от владельца-человека.
Для каждого ключа зафиксируйте, может ли он:
- Делать запросы к моделям.
- Использовать только утвержденные модели или резервные маршруты.
- Вызывать конечные точки для работы с файлами, векторами, промптами, оценками, пакетами, изображениями, аудио, видео или администрированием.
- Читать выгрузки по использованию или данные биллинга.
- Изменять маршруты, квоты, ключи, роли, журналы или настройки провайдера.
- Получать доступ к необработанным промптам, результатам, аргументам инструментов, файлам, трассировкам или только к метаданным.
Затем сравните фактическую область действия с необходимой:
| Если ключу нужно только... | Он не должен также иметь возможность... |
|---|---|
| Вызывать один производственный маршрут чата | Управлять ключами, пользователями, маршрутами, биллингом или учетными записями провайдера |
| Запускать оценки в промежуточной среде | Вызывать производственные маршруты или обращаться к источникам данных клиентов |
| Генерировать изображения в пакетном задании | Читать несвязанные файлы, промпты или выгрузки по использованию |
| Экспортировать данные об использовании для финансового отдела | Изменять модели, промпты, квоты или маршруты шлюза |
| Запускать дымовые тесты в CI | Использовать долгоживущие учетные данные человека |
| Поддерживать интеграцию с поставщиком | Получать доступ к внутренним маршрутам или средам других клиентов |
Если провайдер или шлюз не предоставляет гранулярные области действия, компенсируйте это разделением проектов, разделением маршрутов, ограничениями квот, ограничениями по IP или рабочим нагрузкам, более частой ротацией и усиленным мониторингом.
Выполняйте ротацию ключей по плану перехода
Ротация — это задача обеспечения надежности, а не только безопасности. В руководстве по обновлению ключей доступа от AWS описан практический шаблон: создайте второй ключ, пока первый еще активен, обновите приложения для использования нового ключа, проверьте использование старого ключа, деактивируйте его перед удалением, подождите достаточно долго, чтобы выявить пропущенные вызовы, а затем удалите его. Эта последовательность полезна для ключей шлюза ИИ, поскольку внезапное удаление может нарушить работу вызовов моделей, фоновых заданий и агентов, взаимодействующих с клиентами.
Руководство по ключам сервисных учетных записей от Google Cloud также рассматривает ключи сервисных учетных записей как конфиденциальные учетные данные и рекомендует по возможности использовать более безопасные альтернативы аутентификации. Его документация по ротации ключей подчеркивает, что ротация должна планироваться, а не импровизироваться после компрометации.
Используйте следующую схему ротации:
| Шаг | Действие | Подтверждение |
|---|---|---|
| 1. Подготовка | Подтвердить владельца, рабочую нагрузку, расположение ключа, маршруты, квоты и путь отката | Запись в реестре и инструкция (runbook) |
| 2. Создание замены | Сгенерировать новый ключ или сопоставление рабочей нагрузки, не удаляя старый | ID нового ключа, время создания, владелец |
| 3. Развертывание | Обновить хранилище, секрет CI, секрет времени выполнения или интеграцию шлюза | Запись о развертывании или заявка на изменение |
| 4. Дымовое тестирование | Отправить контролируемые запросы по каждому утвержденному маршруту | ID запроса, маршрут, модель, статус, пример стоимости |
| 5. Наблюдение за старым ключом | Проверить данные о последнем использовании, журналы и оповещения об ошибках для трафика старого ключа | Скриншот последнего использования или ответ API |
| 6. Деактивация | Отключить старый ключ перед его удалением, если платформа поддерживает такое состояние | Отметка времени отключения и владелец |
| 7. Удаление | Удалить старый ключ по истечении периода наблюдения | Подтверждение удаления |
| 8. Закрытие | Обновить реестр и дату следующей проверки | Запись о проверке доступа |
Экстренная ротация пропускает длительный период наблюдения, но не отменяет сбор подтверждений. Если ключ был скомпрометирован, отзовите его, проведите ротацию зависимых рабочих нагрузок, найдите в коде и журналах раскрытый секрет и зафиксируйте, какие системы были протестированы после этого. Здесь будет полезна шпаргалка по управлению секретами от OWASP, поскольку она рассматривает аудит, ротацию, отзыв, удаление и отслеживание жизненного цикла как часть управления секретами.
Офбординг должен включать отзыв не только учетных данных пользователя
Офбординг — это этап, на котором терпят неудачу многие программы проверки доступа к AI API. Удаление пользователя из SSO не всегда приводит к удалению сервисных ключей, секретов CI, общих учетных данных поставщиков, локальных файлов .env, ключей консоли провайдера моделей или ключей шлюза, созданных под учетной записью этого человека.
Создайте триггеры офбординга для следующих случаев:
- Увольнение сотрудника.
- Прекращение работы с подрядчиком или поставщиком.
- Перевод в другую команду.
- Закрытие проекта.
- Архивация репозитория.
- Миграция среды клиента.
- Замена учетной записи провайдера.
- Вывод из эксплуатации маршрута шлюза.
- Инцидент безопасности или подозрение на компрометацию ключа.
Для каждого триггера определите, что должно произойти:
| Триггер офбординга | Требуемое действие | Подтверждения для сохранения |
|---|---|---|
| Уход владельца-человека | Переназначить бизнес-владельца и технического владельца; провести ротацию ключей, созданных пользователем | Удаление из HR/IdP, обновление владельца, журнал ротации |
| Уход подрядчика | Удалить роли в проекте, отозвать ключи поставщика, провести ротацию общих ключей интеграции | Заявка на офбординг поставщика |
| Вывод из эксплуатации сервисной учетной записи | Отключить маршрут, отозвать ключ, удалить секрет CI, удалить неиспользуемую запись в хранилище | Ответ маршрута и подтверждение удаления секрета |
| Закрытие проекта | Отключить все ключи проекта и заархивировать подтверждения использования/биллинга | Контрольный список закрытия проекта |
| Смена провайдера | Провести ротацию ключа на стороне провайдера и секрета на стороне шлюза | Подтверждение из консоли провайдера и тест шлюза |
| Вывод маршрута из эксплуатации | Удалить маршрут модели, резервный вариант, квоту, оповещения и скомпрометированный ключ | Подтверждение удаления маршрута |
| Подозрение на утечку ключа | Немедленный отзыв, ротация, поиск, разбор инцидента | Хронология инцидента и тест после ротации |
Не ждите ежеквартальной проверки для проведения офбординга. Ежеквартальная проверка доступа к AI API должна подтверждать, что триггеры офбординга сработали.
Используйте файл подтверждений, специфичный для шлюза
Для AI-шлюзов обычной проверки IAM недостаточно. Файл подтверждений должен связывать доступ по ключу с поведением маршрутов AI, расходами на модели и границами провайдеров.
| Элемент подтверждения | Что должны видеть проверяющие |
|---|---|
| ID ключа или псевдоним | Стабильный, несекретный идентификатор |
| Сопоставление владельцев | Бизнес-владелец, технический владелец, проверяющий по безопасности, проверяющий по финансам |
| Список маршрутов | Утвержденные маршруты шлюза, модели, провайдеры, семейства конечных точек и резервные варианты |
| Список областей действия | Действия, которые ключ может выполнять, и действия, которые явно запрещены |
| Граница среды | Среда разработки, тестирования, производственная, CI, среда поставщика или клиента |
| Расположение секрета | Хранилище, хранилище секретов CI, менеджер секретов в облаке или другое утвержденное место |
| Последнее использование | Недавнее использование по маршруту, модели и рабочей нагрузке |
| События изменений | Кто создал, провел ротацию, отключил, удалил или изменил ключ |
| Подтверждение расходов | Записи об использовании, квота, баланс, владелец счета, порог оповещения |
| Подтверждение данных | Хранятся или экспортируются ли промпты, результаты, файлы, трассировки и метаданные |
| Запись о ротации | Создание нового ключа, деактивация старого ключа, удаление старого ключа, дымовые тесты |
| Триггер офбординга | Условие, связанное с пользователем, командой, поставщиком, рабочей нагрузкой или проектом, которое отзывает доступ |
| Исключения | Временный широкий доступ, дата истечения, утверждающий и компенсирующие меры контроля |
Свяжите этот файл с контрольным списком для корпоративного AI API-шлюза, журналами аудита использования AI API и оценкой рисков поставщиков AI API. Проверка доступа определяет, кто может вызывать шлюз. Журнал аудита подтверждает, что изменилось. Проверка рисков поставщика подтверждает, какие границы вышестоящих провайдеров все еще действуют.
Контрольный список для проверки доступа по API-ключам
Используйте этот контрольный список для каждого проекта производственного шлюза, проекта промежуточной среды с высоким риском, интеграции с поставщиком и автоматизации CI, которые могут вызывать модели ИИ.
- Экспортируйте инвентарь ключей.
Извлеките каждый ключ шлюза, ключ провайдера, сервисную учетную запись, сопоставление идентификаторов рабочей нагрузки, секрет CI и учетные данные поставщика, которые могут инициировать запросы к ИИ.
- Подтвердите активных владельцев.
Сопоставьте каждый ключ с бизнес-владельцем, техническим владельцем, специалистом по безопасности и ответственным за расходы. Переназначьте или отключите бесхозные ключи.
- Подтвердите назначение рабочей нагрузки.
Свяжите ключ с функцией продукта, автоматизацией, репозиторием, поставщиком, средой клиента или операционным рабочим процессом.
- Проверьте разделение сред.
Убедитесь, что для разработки, промежуточной среды, производства, CI, поставщиков и экстренного доступа не используется один и тот же ключ.
- Проверьте области действия и маршруты.
Сравните разрешенные области действия, модели, семейства конечных точек, резервные маршруты, учетные записи провайдеров, разрешения для инструментов, файлы, промпты и административные возможности с фактическими потребностями рабочей нагрузки.
- Проверьте использование и данные о последнем использовании.
Ищите неиспользуемые ключи, необычный трафик, неожиданные модели, всплески активности в нерабочее время, новые географические регионы или шаблоны расходов, которые не соответствуют владельцу.
- Проверьте ведение журналов и обработку данных.
Убедитесь, какие метаданные, промпты, выходные данные, файлы, трассировки и строки биллинга сохраняются. Используйте контрольный список по хранению данных AI API, если правила хранения полезной нагрузки и метаданных не ясны.
- Ротируйте или сузьте доступ.
Для каждого ключа выберите одно из действий: сохранить, сузить, ротировать, переназначить, отключить, удалить или эскалировать. Отслеживайте выполнение действия до его завершения.
- Протестируйте офбординг.
Выберите недавние случаи ухода сотрудников, прекращения работы с поставщиками, закрытия проектов и маршрутов. Убедитесь, что доступ был удален и что устаревшие ключи не остались после прекращения работы.
- Установите следующий триггер.
Определите периодичность проверок и триггеры на основе событий: смена владельца, изменение маршрута, изменение модели, изменение области действия, смена провайдера, утечка ключа, инцидент, офбординг поставщика или аномалия в расходах.
Пример политики маршрутизации
Проверка доступа к AI API должна приводить к созданию политики, которую инженеры могут реализовать. Точная схема зависит от вашего шлюза, но форма контроля должна быть четко определена.
key_id: support-agent-prod-gateway
owners:
business: support_ops
technical: ai_platform
security: appsec
finance: finops
environment: production
workload:
service: support-agent-api
repository: support-platform
deployment: production
routes:
allowed:
- support-summary-prod
- support-classification-prod
denied:
- experimental-tools
- unrestricted-admin
models:
allowed_groups:
- approved-support-models
fallback_requires_same_data_policy: true
scopes:
allow:
- model_request
- usage_metadata_read
deny:
- key_management
- route_management
- raw_payload_export
- admin_api
quotas:
monthly_budget_usd: 500
alert_owner: finops
burst_limit: controlled
logging:
request_metadata: enabled
raw_payload_storage: verify_in_account
audit_events_required:
- key_created
- key_rotated
- key_disabled
- route_changed
rotation:
cadence: 90d_or_owner_change
method: create_second_key_cutover_deactivate_delete
last_completed: 2026-07-04
offboarding:
triggers:
- owner_departure
- vendor_exit
- service_retirement
- route_decommission
- suspected_exposure
exceptions:
allowed: false
Эта политика делает проверку доступа операционной. Если шлюз не может напрямую выразить решение, сохраните его в файле доказательств и добавьте компенсирующие меры контроля, такие как отдельные проекты, узкая конфигурация маршрутов, более низкая квота, более короткий период ротации и усиленные оповещения.
Как это соотносится с Flatkey
Flatkey может служить операционной платформой для проверки доступа к AI API, поскольку публичная часть продукта сосредоточена на унифицированном доступе к моделям, одном ключе, одном базовом URL, совместимом с OpenAI, маршрутизации, биллинге, аналитике использования, лимитах квот и панели управления для ключей и маршрутизации. Текущая главная страница показывает шаблон маршрутизатора с использованием https://router.flatkey.ai/v1/chat/completions, в то время как страницы с ценами и моделями описывают доступ к моделям, покрытие провайдеров, предоплаченный баланс, аналитику использования и биллинг для производственного API.
Используйте Flatkey для централизации проверки, а затем проверьте следующие детали, специфичные для учетной записи, прежде чем полагаться на контроль:
- Какие роли могут создавать, просматривать, ротировать, отключать или удалять ключи шлюза.
- Можно ли разделять ключи по проектам, средам, рабочим нагрузкам, поставщикам и клиентам.
- Какие модели, провайдеры, семейства конечных точек и резервные маршруты может вызывать каждый ключ.
- Какие квоты, балансы и оповещения об использовании применяются к каждому ключу или маршруту.
- Какие события аудита существуют для изменений ключей, маршрутов, квот, настроек логирования и провайдеров.
- Сохраняются ли необработанные промпты, выходные данные, файлы, аргументы инструментов, трассировки или только метаданные.
- Можно ли связать офбординг с пользователями, командами, поставщиками, проектами и сервисными учетными записями.
Преимущество шлюза заключается в централизации доказательств. Покупатель по-прежнему несет ответственность за проверку доступа к AI API.
Периодичность проверки доступа
Установите как плановые, так и событийные проверки.
| Тип проверки | Триггер | Минимальное действие |
|---|---|---|
| Ежемесячная операционная проверка | Ключи производственного шлюза | Проверка владельца, последнего использования, расходов, неудачных вызовов, новых маршрутов |
| Ежеквартальная проверка безопасности | Все производственные и вендорские ключи | Повторное подтверждение владельца, области действия, ротации, офбординга, исключений |
| Проверка релиза | Новый маршрут, модель, конечная точка, провайдер или резервный вариант | Утверждение области действия ключа перед запуском |
| Проверка при офбординге | Уход сотрудника, вендора, завершение проекта или сервиса | Переназначение, ротация, отключение или удаление затронутых ключей |
| Проверка инцидента | Утечка, аномалия, непредвиденные расходы, злоупотребление, обход политики | Отзыв, ротация, расследование и обновление средств контроля |
| Проверка при продлении | Контракт, DPA, условия провайдера, доступность модели, изменение цен | Повторная проверка данных провайдера и шлюза |
Самое важное правило: у каждого исключения должен быть срок действия. Ключи с широким доступом, общие ключи, экстренные ключи и ключи поставщиков должны иметь явных владельцев, даты истечения срока действия и триггеры для проверки.
Часто задаваемые вопросы
Что такое проверка доступа к AI API?
Проверка доступа к AI API — это периодическая проверка управления, которая подтверждает, что каждый ключ шлюза ИИ или провайдера по-прежнему имеет действительного владельца, назначение, область действия, границу маршрута, шаблон использования, план ротации, журнал аудита и триггер для офбординга.
Чем проверка доступа к AI API отличается от ротации ключей API?
Ротация заменяет учетные данные. Проверка доступа к AI API определяет, должны ли существовать учетные данные, кто ими владеет, к чему они могут получить доступ, как они тратят деньги, какие журналы подтверждают использование и какое событие должно их отозвать.
Кто должен владеть ключами шлюза ИИ?
Каждый производственный ключ должен иметь бизнес-владельца, технического владельца, ревьюера по безопасности и владельца со стороны финансов или операционного отдела. Ключи, принадлежащие человеку, не должны быть долгосрочными учетными данными для производственных сервисов; ключи, принадлежащие сервису, требуют подтверждения идентификатора рабочей нагрузки, репозитория, развертывания и группы владельцев.
Как часто следует проводить ротацию ключей AI API?
Частота ротации зависит от риска, возможностей платформы и требований соответствия, но для производственных ключей должен быть запланированный график, а также триггеры на основе событий. Проводите ротацию немедленно при подозрении на компрометацию, уходе владельца, прекращении работы с поставщиком, изменении области действия, изменении учетной записи провайдера или закрытии проекта.
Что должен включать офбординг для ключей AI API?
Офбординг должен включать удаление ролей пользователей, переназначение или ротацию созданных пользователями ключей, отзыв учетных данных поставщиков, удаление секретов CI, отключение выведенных из эксплуатации сервисных учетных записей и проверку журналов шлюза/провайдера на предмет устаревшего использования после удаления.
Как шлюз ИИ помогает в проверках доступа?
Шлюз ИИ может централизовать ключи, политику маршрутизации, использование, квоты, биллинг и данные об изменениях от разных провайдеров. Он не заменяет проверку по принципу наименьших привилегий или верификацию конкретных учетных записей. Используйте шлюз как поверхность для сбора данных, а затем проверяйте поведение провайдера и учетной записи покупателя.
Заключение
Проверка доступа к AI API должна делать каждые учетные данные шлюза объяснимыми. Ведите реестр, назначайте реальных владельцев, сужайте области действия, проводите ротацию с планом перехода, тестируйте офбординг и закрывайте каждое исключение с подтверждением. Когда вы будете готовы централизовать доступ к моделям ИИ, маршрутизацию, использование и биллинг за одним шлюзом, ознакомьтесь с текущими ценами и каталогом моделей Flatkey, а затем получите ключ.
