За 2024 год в публичный GitHub утекло 23,7 млн секретов — ключей API, токенов и паролей, по данным GitGuardian State of Secrets Sprawl. Подавляющее большинство утечек происходит не из-за взлома, а из-за случайных коммитов, логов и клиентских бандлов. Один ключ OpenAI в среднем проекте присутствует в пяти местах одновременно: в.env на ноутбуках разработчиков, в секретах CI, в конфиге продакшена, в скриптах «на минутку» и в контексте ИИ-агентов. Каждая копия — независимая точка отказа.
Традиционные меры защиты, такие как.gitignore, сканеры утечек (gitleaks, trufflehog) и секрет-менеджеры (Vault, ASM), имеют ограничения: они не закрывают все каналы, а ключ в итоге оказывается у потребителя и может утечь вместе с ним. Альтернативный подход — credential proxy, разрывающий прямую связь между приложением и секретом. В этой схеме приложение получает не ключ, а виртуальную проходку (pass), привязанную к IP-адресу, лимитам rpm/rpd и сроку жизни. Прокси-сервер проверяет проходку, расшифровывает ключ в памяти на время одного запроса и подставляет его в запрос к провайдеру. Если проходка утекает, с чужого IP она не работает, а её отзыв не затрагивает оригинальный ключ.
| Мера | Что закрывает | Что не закрывает |
|---|---|---|
| .env + .gitignore | случайный коммит | логи, CI, агентов, «скрипт на минутку» |
| Сканеры (gitleaks, trufflehog) | утечку в git до пуша | все остальные каналы |
| Секрет-менеджеры (Vault, ASM) | хранение и доставку | ключ всё равно в runtime-окружении приложения |
| Скоуп-ключи провайдера | радиус поражения | есть не у всех провайдеров; отзыв всё равно ломает всех потребителей ключа |
Команда proxykey реализовала такую схему как сервис на Node 22, Fastify 5, PostgreSQL и Redis. В основе — конвертное шифрование: на каждый секрет генерируется свой DEK (AES-256-GCM), который заворачивается KEK из окружения. Токены не хранятся в открытом виде — в базе только SHA-256-хэши проходок. Реализована деградация по-разному в разные стороны: при падении Postgres сервис работает с Redis-кэша, при падении Redis — валидирует по Postgres, но рейт-лимиты становятся fail-open. Для пользовательских апстримов добавлен SSRF-guard, резолвящий и проверяющий base URL на приватные диапазоны. Логи запросов партиционированы по месяцам, метаданные не содержат авторизационных заголовков.
Традиционные меры (gitignore, сканеры, секрет-менеджеры) не закрывают все каналы утечки.
Отдельная проблема — Telegram-боты, где токен живёт в пути URL. proxykey принимает формат bot<digits>:vlt_…, проходящий валидацию клиентских библиотек, и подставляет токен на сервере. Ещё один новый потребитель ключей — ИИ-агенты (Claude Code, Cursor). Они разворачивают сервисы и настраивают ботов, и всё, что попадает в контекст модели, считается опубликованным. Решение — MCP-сервер хранилища: агент подключается по URL с токеном mcp_… и может выписывать, ротировать, отзывать проходки и читать логи, но операция «прочитать ключ» в наборе инструментов отсутствует. Любимый сценарий — «отложенный секрет»: агент создаёт pending-проходку, прописывает её в конфиг, а человек вводит токен позже.
У такого подхода есть trade-offs. Прокси — критичная точка: если он лежит, лежат все вызовы. Это лечится репликами и кэшем валидации. Прокси видит трафик, поэтому важно, что именно логируется: в proxykey логи не содержат значений ключей. Тем не менее, для команд, уставших от бесконечной борьбы с утечками, credential proxy может стать прагматичным решением.
