Безопасность и модель угроз
Вы доверяете нам самое чувствительное — API-ключи. Поэтому эта страница написана без маркетингового тумана: что именно защищено, что НЕ защищено, и на какой вопрос вам всё равно придётся ответить самостоятельно.
Как устроено шифрование
- Конвертная схема. На каждый секрет генерируется свой ключ шифрования (DEK), секрет шифруется алгоритмом AES-256-GCM с привязкой к идентификатору секрета (AAD). Сам DEK зашифрован мастер-ключом (KEK), который существует только в окружении процесса — в базе данных его нет.
- Расшифровка — только в момент запроса. Настоящий ключ расшифровывается в памяти на время одного проксируемого запроса, нигде не кэшируется в открытом виде, не логируется, а буфер с DEK зануляется после использования.
- Ключ не возвращается никогда. После сохранения ни один API сервиса — ни панель, ни MCP — не отдаёт значение секрета. Операции «прочитать секрет» просто не существует.
- Токены не хранятся. Проходки и MCP-токены лежат в базе только как SHA-256-хэши.
- Код шифрования открыт. Модуль конвертного шифрования опубликован целиком, вместе с тестами: github.com/neostorm112-boop/proxykey-crypto. Честная оговорка: открытый код — жест прозрачности, а не криптографическое доказательство того, что на сервере исполняется именно он.
Модель угроз: честная таблица
| Сценарий | Защищено? | Чем |
|---|---|---|
| Утечка дампа базы данных | ✅ | Секреты зашифрованы, KEK в базе отсутствует; токены — только хэши. |
| Кража бэкапов | ✅ | В бэкапах те же шифртексты без KEK. |
| Слив логов | ✅ | В логах нет ключей, auth-заголовков и значений query-параметров; превью тел — только по явному включению, с редактированием секретоподобных строк. |
| Утечка проходки (vlt_…) | ✅ | Привязка к IP, лимиты rpm/rpd, отзыв в один клик; оригинал не раскрывается. |
| Утечка MCP-токена агента | ✅ | MCP-поверхность не умеет читать и создавать секреты — только управлять проходками. |
| Враждебный кастомный base URL (SSRF) | ✅ | Guard с проверкой приватных/метаданных-диапазонов и пиннингом DNS-резолва. |
| Компрометация только БД (без сервера приложения) | ✅ | Без KEK из окружения процесса шифртексты бесполезны. |
| Полная компрометация сервера или злонамеренный оператор | ❌ | Тот, у кого есть и шифртексты, и KEK, и код — может расшифровать секреты. Подробнее ниже. |
Самый неудобный вопрос
«А вы сами можете прочитать мои ключи?» Технически — да. Прокси обязан расшифровать ключ, чтобы подставить его в запрос к провайдеру — в этом суть сервиса. Значит, процесс с полным доступом (а следовательно, и оператор сервера) в принципе способен получить открытый текст. Это не наша недоработка, а архитектурное свойство любого credential proxy: «zero-knowledge» здесь невозможен — в отличие, например, от менеджера паролей, которому ваш секрет на сервере не нужен.
Важно понимать: у любых hosted-решений этого класса — так же (секрет-менеджеры, прокси, облачные хранилища ключей). Разница лишь в том, говорят ли об этом прямо. Мы говорим.
Как снизить даже этот риск
- Заводите в proxykey не мастер-ключи, а скоуп-ключи. У OpenAI это проектные ключи с бюджетом, у большинства провайдеров есть аналоги. Тогда даже полная компрометация proxykey стоит вам не «весь аккаунт», а ограниченный бюджет одного ключа.
- Ставьте лимиты на стороне провайдера — вторая линия обороны после наших лимитов на проходки.
- Ротируйте оригиналы — перевыпуск ключа у провайдера обнуляет ценность всего, что могло утечь раньше, а проходки продолжают работать после обновления секрета.
- Не доверяете вообще? Это рациональная позиция. Схема credential proxy воспроизводима — мы описали её устройство, а крипто-модуль открыт. Можно собрать свою инсталляцию.
Что мы логируем
Метаданные каждого проксируемого запроса: метод, путь, HTTP-статус, задержку, IP источника, провайдера. Никогда: auth-заголовки, значения ключей, query-строки. Полный перечень данных и сроков — в политике конфиденциальности.
Вопросы к модели угроз?
Технические детали — в документации (раздел Security model). Нашли слабое место — расскажите нам, это лучший вклад в общую безопасность.
Попробовать со скоуп-ключом →