Мы открыли код шифрования хранилища API-ключей и сразу написали, чего он не обещает. Это редкий случай, когда авторы сервиса не прячут главный риск за красивыми словами: если система расшифровывает секреты для работы, абсолютной недоступности для оператора не будет.

Речь идёт не о громком разоблачении, а о нормальной инженерной честности. Для читателя здесь важен не сам проект proxykey, а логика любого сервиса, который хранит и подставляет секреты в запросы: где у него сильные стороны, где окно риска и что можно сделать на своей стороне.

1) История инцидента

Авторы proxykey описали схему так: настоящие API-ключи лежат у них в зашифрованном виде, а приложения и ИИ-агенты работают с виртуальными токенами, которые можно отозвать. Затем они выложили крипто-модуль и отдельно расписали модель угроз.

Ключевой вопрос, который они вынесли в начало, звучит просто: может ли оператор прочитать ключи? Ответ тоже простой — технически да. Причина не в слабом шифре, а в самой архитектуре: чтобы подставить секрет в запрос, сервис должен ненадолго получить его в открытом виде.

Это и есть главный урок кейса. В статье про дыру в reverse proxy у Gitea Docker проблема тоже была не в красивой обёртке, а в том, как конкретная схема ведёт себя под нагрузкой и при ошибках конфигурации. В безопасности почти всегда важны не лозунги, а границы доверия.

2) Что пошло не так в защите

Авторы прямо сказали: zero-knowledge здесь невозможен. Менеджер паролей может не знать ваш пароль, а credential proxy — нет. В момент выполнения запроса плейнтекст ключа живёт в памяти процесса, и это делает полный доступ к серверу критичным риском.

Шифрование всё же не зря. Оно закрывает более вероятные сценарии: утечку базы, доступ только к дампу, просмотр логов, перехват виртуального токена. Но оно не спасает, если сервер скомпрометирован полностью или если оператор действует недобросовестно.

Отдельно авторы честно описали ограничения. fill(0) — это best-effort: среда выполнения могла уже успеть создать копии буфера, а строку в JavaScript вообще нельзя надёжно затереть. Проверка длины мастер-ключа тоже не означает проверку его качества — если ключ слабый, код этого не исправит.

Здесь полезно сопоставить этот подход с тем, как устроены утечки секретов в корпоративной среде. Разбор StarVault и LDAP показывает ту же логику: защита работает только пока вы понимаете, какие именно данные лежат в хранилище и кто может до них добраться.

3) Уроки для читателя

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

Второй урок — лимиты нужны не только в хранилище, но и у самого провайдера. Даже если кто-то доберётся до токена, квоты и бюджет на стороне сервиса срежут возможный урон.

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

Если вы работаете с ИИ-агентами, то смотреть надо не только на шифрование, но и на поведение системы в целом: кто видит секреты, кто может отозвать токен, где хранятся логи, как быстро меняются права. Об этом же, по сути, говорят и материалы о том, как собрали базу киберугроз для LLM-агентов и SOC.

4) Практические выводы и чек-лист

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

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

Чек-лист

  • Разделите ключи по проектам и задачам, а не храните один секрет «на всё».
  • Поставьте лимиты у провайдера, чтобы снизить ущерб от компрометации.
  • Настройте регулярную ротацию ключей и токенов.
  • Проверьте, пишут ли ваши сервисы секреты в логи и телеметрию.
  • Убедитесь, что критичные секреты лежат только там, где это действительно нужно, а не в нескольких системах сразу.
  • Для рабочих сценариев оцените сервисы, которые шифруют данные на устройстве до передачи в сеть, например решения для шифрования трафика на личных устройствах.
  • Если вы пользуетесь ИИ-агентами, пересмотрите, какой именно доступ у них есть к вашим данным и ключам.
  • Не верьте словам «полная безопасность» без описания модели угроз и ограничений.
Поделиться: