Перейти к основному содержанию
Ключ всплыл в публичном коммите, логе CI, скриншоте или утечке вендора. Часы идут: каждый, кто держит строку sk-orca-…, может тратить ваш баланс и управлять вашими агентами, пока вы его не отрежете. Эта страница — runbook инцидента — сначала отрежьте учётку, затем аудируйте, что она делала — для клиентов, управляющих собственными ключами в консоли. Механика жизненного цикла (отключение vs. удаление, состояния ключа, роли) живёт в Управлении ключами; эта страница — под-атакой последовательность и, что критически важно, что проверить в аудиторском следе, когда кровотечение остановлено.
Остановите расходы, прежде чем расследовать. Ограниченный ключ с лимитом credit_limit_usd и списком allow_ips ограничивает ущерб, но утёкший ключ без лимитов может жечь баланс столько, сколько остаётся живым. Сначала отзовите; форензика второй.

​
1. Отзовите утёкший API-ключ (сделайте это первым)

У вас два хода отсечения, оба на экране Keys в консоли (/console/token). Оба требуют роли Developer или выше — действие выполняется на вашем сессионном / access-токене, никогда на ключе ретрансляции.

Отключение — обратимая пауза

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

Удаление — необратимый отзыв

Выберите Delete на ключе. Учётка больше никогда не сможет авторизовать запрос и невосстановима. Используйте это, когда утечка подтверждена и вы захватили из следа то, что нужно.
Распространённый паттерн: отключить мгновенно в момент, когда вы подозреваете раскрытие (сдерживание с нулевой задержкой, ничего не потеряно), провести аудит в §3–§4, затем удалить, когда вы определили радиус поражения. Что бы вы ни делали, выпустите свежий ключ для замены — никогда не включайте снова учётку, которую видели в дикой природе. Передача без простоя — в Ротации ключей.
Отключение или удаление вступает в силу на следующем запросе — нет передеплоя и нет задержки распространения.

​
2. Заодно ужесточите замену

Утечка — это момент исправить область, которая дала ей навредить. Ключ-замена должен нести самую узкую идентичность, которая реально нужна нагрузке, так чтобы следующая утечка была несобытием:
Список разрешённых IP означает, что утёкший ключ бесполезен с любого адреса, кроме вашего. Запросы с не указанных в списке IP отклоняются на уровне аутентификации, прежде чем что-либо стоят.
Лимит расходов (0 = без ограничения) ограничивает худший случай. Утёкший ключ с тесным недельным потолком не может опустошить баланс вашего рабочего пространства.
Лимиты моделей не дают вору переключить ваш дешёвый ключ на вашу самую дорогую модель.
Срок действия (-1 = никогда) означает, что ключ, ускользнувший от вашего внимания, всё равно перестаёт авторизовать сам по себе.
См. Чек-лист минимальных полномочий для полной позиции один-ключ-на-агента.

​
3. Аудируйте логи запросов — что вызывал ключ?

С отрезанной учёткой определите ущерб. Каждый вызов ретрансляции, который делал этот ключ, записан в логах запросов вашего рабочего пространства, и каждая строка несёт поля, нужные вам для реконструкции инцидента:
ПолеЧто оно вам говорит
token_name / token_idКакой ключ — подтвердите, что вы смотрите на утёкший.
ipАдрес источника каждого вызова. Всплеск с IP, который вы не узнаёте, — это улика.
модель + использованиеКакие модели были задействованы и сколько стоили — ваша экспозиция расходов.
Отфильтруйте вид лога на утёкший ключ и отсортируйте по времени. Два вопроса быстрее всего отвечают на «насколько всё плохо»:
  1. Есть ли трафик с IP, который не ваш? Это подтверждённое злоупотребление, а не ложная тревога.
  2. Скакнули ли расходы или паттерн вызовов вокруг окна утечки? Внезапный скачок — это отпечаток злоумышленника.
Если ключ нёс список allow_ips, вызовы извне него никогда не авторизовались в первую очередь — так что отсутствие строк с чужим IP само по себе чистый счёт здоровья. Именно поэтому закрепление источника (§2) превращает утечку в несобытие.

​
4. Прочитайте след политик — что он пытался сделать?

Логи запросов говорят вам, что вызывал ключ; плоскости политик говорят вам, что он пытался заставить модель сказать или сделать, и поймали ли это ваши guardrails и firewall. Оба ограничены рабочим пространством. Совпадения guardrail читаемы любым участником рабочего пространства; представление firewall Events / Runs требует роли Developer или выше (политики и настройки firewall остаются открыты каждому участнику).

Совпадения guardrail

Каждый раз, когда трафик ключа попадал в правило guardrail, запись совпадения приземлялась на GET /api/guardrail/match — неся тип правила, action (block / mask / flag), stage и проблемную деталь. Отфильтруйте на окно утёкшего ключа, чтобы увидеть, какое содержимое он проталкивал (PII, секреты, попытки jailbreak).

События firewall

Каждый вызов инструмента, который выпустил ключ, — это событие firewall — allow, audit, deny, sanitize или удержано. Серия событий deny — это агент, попытавшийся что-то, что ему не было разрешено. Сверните их по прогону в представлении Events / Runs.
Несколько конкретных вещей, которые стоит знать, читая след:
  • Совпадения guardrail логируют совпавшую подстроку, только если был включён «Log raw content» для этого guardrail (он выключен по умолчанию) — так что строка совпадения может показывать правило и действие без сырого текста. Тип / действие / стадия всегда на месте.
  • mark-fp на совпадении (POST /api/guardrail/match/:id/mark-fp, Admin) позволяет пометить попадание как ложное срабатывание, чтобы оно перестало искажать ваш вид инцидента — не используйте его, чтобы закопать реальное злоупотребление.
  • Отказы firewall — до-инструментальные. Событие deny означает, что вызов инструмента злоумышленника был заблокирован до того, как достиг инструмента — firewall уже сдержал это действие. Событие — ваше свидетельство, что он пытался.
Сверьте три следа на одном временном окне: чужой IP в логах запросов, всплеск совпадений guardrail и кластер событий deny firewall вместе рисуют полную картину — что было у злоумышленника, что он пытался и что было остановлено.

​
5. После инцидента

Перепроверьте список Keys: утёкший ключ должен читаться Disabled или исчезнуть полностью. Если вы его только отключили, запланируйте удаление, когда закончите аудит — см. Управление ключами.
Переведите трафик на новый, более узко ограниченный ключ, прежде чем выводить старый из эксплуатации, так чтобы никогда не было разрыва без рабочего ключа. Полная передача: Ротация ключей.
Если у утёкшего ключа не было allow_ips, не было credit_limit_usd и были широкие model_limits, это и есть реальная находка. Дайте каждому агенту собственный узко ограниченный ключ — Чек-лист минимальных полномочий и Область и ключи проходят всю позицию.

​
6. Связанное

Управление ключами

Отключение vs. удаление, состояния ключа и ролевые шлагбаумы за каждым действием.

Ротация ключей

Передача без простоя от скомпрометированного ключа к чистому.

Список разрешённых IP

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

Эксфильтрация данных

Угроза, которую утёкший ключ чаще всего питает, и как egress-поверхность firewall её ограничивает.
Вся последовательность намеренно коротка: отзовите, затем аудируйте. Чем уже область каждого ключа изначально, тем меньше аудит, который вам придётся проводить — и тем быстрее утёкшая учётка переходит из экстренной ситуации в сноску.