Перейти к основному содержанию
Учётка, которую можно прочитать с экрана, — это учётка, которую можно слить. Скопировав новый ключ, вы почти никогда не нуждаетесь в его открытом тексте снова — вам нужно его узнать: какой это ключ, в каком окружении, тот ли это, который использует падающий агент. Консоль OrcaRouter отвечает на это, ни разу не перепечатывая рабочий секрет: каждый ключ отрисовывается в маскированной форме, которая сохраняет ровно достаточно символов, чтобы его опознать, и прячет остальное. Эта страница покрывает, как выглядит маскированная форма, когда открытый текст показывается, а когда нет, и как безопасно маскировать значения API-ключа в ваших собственных логах и инструментарии.

​
1. Зачем маскировать значения API-ключа на отображении

Полный ключ — это bearer-учётка: каждый, кто его прочитает, может вызывать шлюз как вы, в пределах лимитов этого ключа. Виды консоли постоянно попадают в скриншоты, демонстрации экрана, тикеты поддержки и баг-репорты — так что показ живого секрета в списке ключей превратил бы каждый из них в утечку учётки. Маскирование решает это, разделяя две потребности, которые обычно смешивают:
  • Идентификация — какой это ключ? Отвечается стабильным, маскированным отпечатком, который вы читаете с одного взгляда.
  • Использование — что за секрет? Отвечается ровно один раз при создании и за намеренным, ограниченным ролью раскрытием после этого.
Консоль удовлетворяет первую потребность везде и шлагбаумит вторую, так что поверхность по умолчанию — список ключей, на который вы пялитесь весь день — никогда не несёт пригодного секрета.
Маскированный ключ не является рабочей учёткой. Он не может аутентифицировать запрос. Только полный открытый текст (sk-orca-…), который вы скопировали при создании, или повторно раскрытый через ограниченный эндпоинт, может вызвать шлюз.

​
2. Как выглядит маскированная форма

Консоль показывает брендовый префикс ключа, затем фиксированную серию звёздочек, затем последние четыре символа — достаточно, чтобы отличить два ключа, недостаточно, чтобы восстановить любой из них.
Вы создалиКонсоль показывает
sk-orca-9f3aK2…long…7Qm4sk-orca-9f3****7Qm4
Первый сегмент сохраняет префикс sk-orca- и несколько начальных символов; финальные четыре символа — это хвост, который вы узнаете, когда сверяете строку лога или ошибку. Всё между ними сворачивается в фиксированную маску — серия звёздочек это константа, так что её ширина никогда не выдаёт истинную длину ключа.
Сочетайте маскированный хвост с меткой environment ключа и именем, когда вам нужно быстро найти конкретный ключ — четырёхсимвольный хвост плюс тег prod / staging почти всегда достаточны, чтобы выбрать нужный из списка, ни разу не раскрывая открытый текст.

​
3. Когда открытый текст показывается — и когда нет

Есть ровно один момент, когда полный ключ ваш для копирования, и один ограниченный путь, чтобы получить его снова.
Когда вы выпускаете ключ, консоль отображает полный открытый текст sk-orca-… один раз. Скопируйте его в свой менеджер секретов тогда. Каждый последующий вид этого ключа — список, панель деталей, результаты поиска — показывает только маскированную форму.
Вы можете повторно раскрыть открытый текст обычного ключа по требованию, но это намеренное действие за ролью Developer+ — не то, что список по умолчанию когда-либо выставляет. Повторное раскрытие ключа с областью шлюза (is_firewall_gateway) требует роли Admin (или Owner), потому что этот токен может читать учётки зарегистрированных MCP-серверов.
Перечисление ключей, открытие деталей ключа, поиск и каждое чтение объекта токена возвращают маскированную форму. Открытый текст никогда не включается в список или ответ поиска.
Поскольку повторное раскрытие ограничено, а ключу с областью шлюза нужен Admin, чтобы прочитать снова, относитесь к копии во время создания как к вашему одному надёжному захвату. Сохраните её в менеджер секретов немедленно. Если вы потеряете открытый текст обычного ключа, вы можете повторно раскрыть его (Developer+); если вы не можете его раскрыть и не можете восстановить, ротируйте на свежий ключ вместо того, чтобы обходить ключ, который вы больше не можете прочитать.

​
4. Один конкретный пример: опознание утёкшего ключа

Скажем, срабатывает алерт — ключ делает вызовы с неожиданного IP — и строка лога несёт маскированный хвост …7Qm4. Вам не нужен открытый текст, чтобы действовать:
  1. Откройте список Keys в консоли (/console/token). Каждая строка показывает свой маскированный отпечаток — sk-orca-9f3****7Qm4 — и свою метку environment.
  2. Сопоставьте хвост …7Qm4 (и тег prod) с проблемной строкой. Маскированная форма — это в точности тот идентификатор, который вам нужен здесь — никакой секрет не раскрыт в списке, алерте или вашем скриншоте его.
  3. Отключите этот ключ, чтобы поставить на паузу, или удалите его, чтобы отозвать навсегда — оба действия безопасны для маскирования и никогда не печатают открытый текст. См. Управление ключами и Реагирование на утечку ключа.
Весь разбор работает на маскированном отпечатке. Открытый текст остаётся в вашем менеджере секретов, где ему и место.

​
5. Маскирование в ваших собственных логах и инструментах

Шлюз маскирует свои собственные поверхности; вы контролируете свою сторону. Тот же принцип применяется везде, где ключ может приземлиться в вашем стеке:
  • Никогда не логируйте заголовок Authorization или сырое значение sk-orca-…. Если вам нужно записать, какой ключ сделал вызов, логируйте ту же форму, что использует консоль — префикс и последние четыре символа — а не полный секрет.
  • Храните открытый текст только в менеджере секретов, никогда в системе контроля версий, логах CI или конфиг-файле, закоммиченном в репозиторий. Ключ маскируется в консоли именно для того, чтобы ваши собственные системы были единственным местом, где живёт живой секрет.
  • Ограничивайте ключи узко, чтобы даже утёкшая учётка имела ограниченный радиус поражения — одна модель, один диапазон IP, один лимит расходов. См. Чек-лист минимальных полномочий.
Маскирование уменьшает отображаемую экспозицию; оно не уменьшает мощь ключа, который таки утечёт. Маскированный отпечаток в логе безопасен, но живой ключ в менеджере секретов всё ещё полностью аутентифицирует — поэтому узкая область и быстрая ротация важны ровно так же, как маскирование.

​
6. Как это вписывается в остальную гигиену ключей

Маскирование — один слой позиции глубокой защиты для учёток:

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

Создавайте, отключайте и отзывайте ключи — жизненный цикл за каждой маскированной строкой в списке.

Объект токена

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

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

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

Реагирование на утечку ключа

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