🔐 Безопасность Секретов и отличие от Паролей - мастер-ключ, шифрование и общая архитектура.

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

Коротко

Значения секретов шифруются до записи в базу алгоритмом AES-256-GCM. Ключ, которым их можно расшифровать, в базе не лежит. Утёкший дамп БД без мастер-ключа — это бесполезный набор зашифрованных данных.

Пароли и секреты: две разные модели безопасности

В Tuna есть два хранилища для чувствительных данных — Менеджер паролей и Секреты. Они намеренно построены по-разному, потому что решают разные задачи.

Менеджер паролей — модель нулевого знания (zero-knowledge). Ключи шифрования создаются на вашем устройстве и никогда не покидают клиент — браузер или приложение. Шифрование и расшифровка происходят только на вашей стороне, а на сервер уходит уже зашифрованный текст. Принцип, заложенный в основу: компрометация нашей инфраструктуры не должна приводить к компрометации ваших паролей — расшифровать их можно лишь там, где есть мастер-ключ, а он есть только у вас. Обратная сторона — данные доступны только владельцу мастер-ключа: автоматически выдать пароль скрипту или пайплайну, не раскрывая его, в такой модели невозможно.

Секреты — серверное шифрование. Здесь мастер-ключ находится на стороне платформы, и шифрование выполняет сервер. Это осознанный компромисс, и сделан он ради главного сценария секретов — автоматизации. Секрет должен сам, без участия человека, попадать в приложение при запуске, в CI/CD-пайплайн, в скрипт развёртывания. Запуск приложения с подгрузкой переменных, сервисные ключи для CI, автоматический перезапуск при изменении значения — всё это работает именно потому, что сервер способен выдать секрет по запросу авторизованного клиента, не требуя мастер-пароль каждый раз.

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

	Пароли	Секреты
Модель	Нулевое знание	Серверное шифрование
Где находится ключ	Только у клиента	На стороне платформы
Где идёт шифрование	На клиенте	На сервере
Может ли Tuna прочитать данные	Нет	Да, для авторизованных операций
Автоматизация (CI/CD, скрипты)	Ограничена	Полноценная
Главный сценарий	Хранение и обмен паролями	Доставка конфигурации приложениям

Модель доверия секретов

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

Достигается это классической схемой конвертного шифрования (envelope encryption) — двухуровневой иерархией ключей.

Конвертное шифрование: два уровня ключей

В системе два уровня ключей:

1. Мастер-ключ платформы (KEK, Key Encryption Key). Хранится на стороне Tuna и в базу данных не попадает. Сам по себе он ничего пользовательского не шифрует — его единственная задача «оборачивать» (защищать) ключи команд.

2. Ключ команды (DEK, Data Encryption Key). Для каждой команды генерируется свой случайный ключ — криптографическим генератором случайных чисел. Именно им шифруются значения секретов этой команды.

Ключ команды не хранится в открытом виде: он зашифрован мастер-ключом и в таком «обёрнутом» виде лежит в базе. Чтобы им воспользоваться, сервер сначала разворачивает его мастер-ключом в памяти.

Получается цепочка зависимостей: значение секрета защищено ключом команды, а ключ команды защищён мастер-ключом. Разорвав любое звено, дальше пройти нельзя.

Любопытно, что менеджер паролей построен на той же идее конвертного шифрования — с двумя принципиальными отличиями: «конверт» там запечатывается асимметрично, на паре открытого и закрытого ключей, а корневой ключ остаётся на стороне клиента, а не сервера. Схема одна и та же, по-разному распределено лишь доверие: секреты настроены на автоматизацию, пароли — на нулевое знание.

Где и как хранится мастер-ключ

Это основной для всей схемы вопрос, поэтому разберем каждое место хранения:

• Не в базе данных. Мастер-ключ принципиально отделён от данных, которые он защищает. В дампе базы его нет.
• Не в коде и не в репозитории. Он не зашит в исходники, а передаётся сервису извне — из защищённого хранилища конфигурации платформы.
• Только в памяти процесса. Сервер держит ключ в оперативной памяти на время работы и не пишет его на диск в открытом виде.
• Полноценный 256-битный ключ. Этого достаточно, чтобы перебор был вычислительно невозможен.

Главный вывод: доступ к базе данных и доступ к мастер-ключу — это два разных уровня доступа с разными правами. Компрометация одного из них не означает автоматически компрометацию второго.

Жизненный цикл секрета: запись и чтение

Шифрование и расшифровка встроены в слой работы с данными и происходят прозрачно — приложение никогда не пишет открытое значение в базу и никогда не читает его оттуда напрямую.

При сохранении значение шифруется ключом команды ещё до записи. Для каждого значения берётся свой случайный одноразовый вектор (nonce) — поэтому даже два одинаковых секрета выглядят в базе по-разному. В хранилище попадает только зашифрованный текст.

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

Мы используем режим GCM (Galois/Counter Mode) — это аутентифицированное шифрование. Помимо конфиденциальности оно гарантирует целостность: если кто-то изменит хотя бы один байт зашифрованных данных в базе, расшифровка не вернёт «мусор», а честно провалится с ошибкой проверки. Подделать или незаметно подменить значение в обход сервера не получится.

В транзите всё дополнительно защищено TLS — между вашим клиентом и API данные идут по зашифрованному каналу.

Что лежит в базе зашифровано, а что открыто

Разбор того, какие данные и в каком виде реально хранятся в базе:

Зашифровано (AES-256-GCM)	В открытом виде
Значения секретов	Имена переменных
Заметки к секретам	Типы значений
Ключ команды (в обёрнутом виде)	Уровень видимости
	Структура: проекты, окружения, конфигурации
	Метки времени создания и изменения

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

Что будет, если утечёт база данных

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

Что у него на руках:

• Зашифрованные значения секретов — шифр AES-256-GCM, статистически неотличимый от случайного шума.
• Ключ команды — но он сам зашифрован мастер-ключом.
• Метаданные — имена, типы, структура проектов.

Чего у него нет:

• Мастер-ключа. Его нет в базе — он на стороне сервера, куда дамп базы доступа не даёт.

Цепочка обрывается на первом же шаге. Чтобы расшифровать значение, нужен ключ команды. Чтобы развернуть ключ команды — нужен мастер-ключ. Мастер-ключа в дампе нет, а взломать AES-256 перебором невозможно. Значения секретов остаются защищены. Злоумышленник видит лишь каркас: имена и структуру, но не содержимое.

Границы защиты

Никакая схема не защищает от всего, и важно понимать её рамки:

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

Дополнительные уровни защиты

Шифрование — это фундамент, но не единственный слой. Доступ к секретам ограничен ещё на нескольких уровнях:

• Скрытые значения (Restricted). Секрет с такой видимостью не отдаётся через API и не попадает в выгрузки — даже авторизованному пользователю показывается только факт его существования.
• Сервисные ключи с узким доступом. Для CI/CD выпускаются ключи, привязанные к конкретной конфигурации, с правами только на чтение или на чтение и запись, и с опциональным сроком действия. Утечка такого ключа не открывает доступ ко всем секретам команды.
• Ограничение по IP (Trusted IP). Доступ к конфигурации можно ограничить списком разрешённых адресов и подсетей в формате CIDR.
• Полный аудит. Все изменения внутри конфигураций журналируются — видно, кто и когда менял каждый секрет.

Что в планах

Сейчас Tuna Секреты — это централизованное и зашифрованное хранилище. Логичный следующий шаг — сделать его источником истины, из которого секреты автоматически синхронизируются туда, где они нужны.

В планах — интеграции для односторонней синхронизации:

• HashiCorp Vault — отправка секретов в Vault, чтобы Tuna стала удобным интерфейсом управления, а приложения продолжали читать их привычным способом.
• Kubernetes Secrets — синхронизация конфигурации напрямую в секреты нужного namespace кластера.
• GitHub Actions — публикация в encrypted secrets репозитория или организации для использования в пайплайнах.
• GitLab CI/CD — синхронизация в CI/CD variables проектов и групп.

Идея в том, чтобы вы редактировали секрет в одном месте, а он автоматически и безопасно доходил до всех ваших окружений — без копирования значений между десятком панелей.

Итог

Безопасность Tuna Секретов держится на нескольких простых и проверенных принципах:

• Две модели под две задачи — пароли шифруются на клиенте (мы их не видим), секреты — на сервере, ради автоматизации.
• AES-256-GCM — аутентифицированное шифрование значений до записи в базу.
• Конвертное шифрование — мастер-ключ защищает ключи команд, ключи команд защищают данные.
• Мастер-ключ отделён от данных — его нет ни в базе, ни в коде, и утёкший дамп БД бесполезен.
• Слои доступа сверху — видимость, сервисные ключи, ограничение по IP и аудит.

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

Оставьте отзыв

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

Помощь

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество