Перейти к содержанию

Секреты и ключи

Главное правило

Секрет должен попадать только в тот компонент, которому он действительно необходим.

минимальное число копий
+
минимальное число читателей
+
минимальное время жизни

— базовая стратегия для паролей, ключей и токенов.

Что относится к секретам

В контексте ИИ Студии секретами могут быть:

  • пароль пользователя;
  • пароль администратора;
  • закрытая часть авторизованного ключа Яндекс Облака;
  • IAM-токен;
  • ключ внешнего программного интерфейса;
  • секрет сеанса;
  • пароли баз данных;
  • мастер-ключ поискового индекса;
  • ключи внешнего корпоративного сервиса;
  • резервные коды дополнительной проверки входа;
  • закрытый TLS-ключ.

Не все они имеют одинаковый срок жизни и область действия.

1. Пароли пользователей

Пароль вводится только в предназначенную форму входа или смены пароля.

Не отправляйте пароль в чат даже локальной модели.

Почему:

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

Для обращения в поддержку достаточно:

вход возвращает «неверный пароль»

без самого пароля.

2. Временный административный пароль

Если установщик создаёт временный пароль:

  1. получите его через защищённый канал;
  2. войдите;
  3. смените пароль;
  4. подтвердите повторный вход;
  5. удалите временный файл, если он создавался установщиком;
  6. не включайте этот файл в диагностический архив.

Наличие временного пароля в каталоге после завершения первого запуска следует считать дефектом эксплуатационного процесса.

3. Авторизованный ключ Яндекс Облака

Авторизованный ключ содержит закрытую криптографическую часть и используется сервером для выпуска временных IAM-токенов.

Важно:

  • ключ создаётся для отдельной служебной учётной записи;
  • закрытая часть требует безопасного хранения;
  • фактические возможности ограничиваются ролями служебной учётной записи;
  • файл ключа должен быть доступен только нужному серверному компоненту;
  • браузер не должен получать содержимое ключа обратно после загрузки.

Подробнее: Авторизованный ключ.

4. IAM-токен

IAM-токен — краткоживущая техническая учётная сущность.

авторизованный ключ
   ↓
серверный обмен
   ↓
IAM-токен
   ↓
API Яндекс Облака

Пользователь в нормальном сценарии не должен работать с ним вручную.

Не делайте

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

При диагностике достаточно статуса:

IAM auth available: YES

или кода ошибки обмена.

5. Закрытый TLS-ключ

TLS-сертификат может быть публичным. Его закрытый ключ — нет.

Он должен:

  • храниться с ограниченными правами;
  • не попадать в Git;
  • не попадать в публичный архив документации;
  • не отправляться в чат;
  • резервироваться только согласно политике ключей организации.

При обращении в поддержку обычно достаточно имени сертификата, срока действия, отпечатка и сообщения об ошибке.

6. Пароли баз данных

Студия использует несколько хранилищ. Их пароли — серверные секреты.

Никогда не публикуйте наружу порт базы только ради удобства ручной диагностики.

Предпочтительнее проверять:

  • с хоста;
  • из внутреннего административного контейнера;
  • через штатную проверку состояния.

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

7. Переменные окружения

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

Проверьте права:

stat .env

Рекомендуется:

  • ограничить чтение владельцем и необходимой группой;
  • не коммитить рабочий .env;
  • хранить пример конфигурации без реальных секретов;
  • не печатать весь файл при диагностике.

Плохая команда для обращения в поддержку:

cat .env

Лучше извлечь только безопасные параметры или сформировать очищенный отчёт.

8. Секрет и модель

Модель не должна использоваться как хранилище секретов.

Не просите:

Запомни этот пароль и используй его позже.

Не сохраняйте секрет:

  • в память;
  • в инструкцию помощника;
  • в базу знаний;
  • в название проекта;
  • в обычный разговор.

9. Очистка журналов

Перед отправкой журнала третьему лицу или в поддержку проверьте:

  • Authorization:;
  • Bearer;
  • Cookie;
  • пароли в строках подключения;
  • поля private_key;
  • ключи программных интерфейсов;
  • адреса электронной почты, если они не нужны;
  • внутренние адреса, если их раскрытие нежелательно;
  • содержимое пользовательских запросов.

Было:

Authorization: Bearer eyJhbGciOi...

Должно стать:

Authorization: Bearer [СКРЫТО]

10. Скриншоты

Скриншот — такой же канал утечки, как текстовый файл.

Перед публикацией закрывайте:

  • токены;
  • электронную почту;
  • чувствительные идентификаторы;
  • внутренние адреса;
  • имена приватных каталогов;
  • секретные значения полей;
  • QR-коды входа;
  • резервные коды.

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

11. Ротация

Поводы для ротации:

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

12. Ротация авторизованного ключа

Безопасная последовательность:

  1. создайте новый ключ;
  2. загрузите его в Студию;
  3. проверьте IAM;
  4. проверьте рабочий каталог;
  5. проверьте Yandex AI, если используется;
  6. проверьте Billing;
  7. убедитесь в работе пользователей;
  8. отзовите старый ключ;
  9. подтвердите отказ старого ключа;
  10. удалите временные копии.

Не оставляйте два действующих ключа неопределённо долго.

13. Действия при утечке секрета

Если секрет мог быть раскрыт:

  1. считайте его скомпрометированным;
  2. ограничьте соответствующий доступ;
  3. отзовите ключ, токен или пароль;
  4. создайте новый;
  5. проверьте журналы использования;
  6. определите период возможной компрометации;
  7. проверьте, куда секрет мог попасть дополнительно;
  8. удалите или отзовите опубликованные материалы;
  9. зафиксируйте инцидент по внутренней процедуре.

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

14. Секреты в резервной копии

Резервная копия может содержать секреты прямо или косвенно.

Поэтому:

  • не храните её в общедоступном каталоге;
  • ограничивайте владельца;
  • шифруйте по политике организации;
  • учитывайте старые ключи внутри исторических копий;
  • контролируйте доступ к хранилищу;
  • уничтожайте просроченные копии по процедуре.

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

15. Секреты и Git

Перед коммитом проверяйте:

git status

и используйте средство поиска секретов, если оно принято в организации.

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

16. Минимальная проверка сервера

Проверьте:

  1. рабочий .env не читается всеми пользователями;
  2. каталог secrets/ имеет ограниченные права;
  3. закрытый TLS-ключ защищён;
  4. авторизованный JSON не раздаётся веб-сервером;
  5. базы данных не опубликованы наружу без необходимости;
  6. журналы не содержат полных токенов;
  7. резервные копии недоступны обычным пользователям;
  8. диагностические архивы очищаются перед передачей.

См. также