Сравнение · 5 из 5
Wardhold и «как есть сейчас»
Чаще всего выбирают не между продуктами, а между хранилищем и привычкой. Секреты лежат в .env на серверах, в переменных проекта CI, в константах информационной базы 1С и в сообщениях мессенджера — и это работает ровно до первого увольнения, аудита или переезда.
Где секреты лежат сегодня
| Где | Чем это заканчивается | Что вместо этого |
|---|---|---|
.env и конфиги на серверах | Файл уезжает в бэкап, в образ и на ноутбук подрядчика; кто читал — неизвестно | Агент рендерит файл на месте и обновляет его при ротации, значения не хранятся в репозитории |
| Переменные проекта в CI | Не переживают переезд между GitLab, GitHub и SourceCraft; видны всем, у кого есть доступ к настройкам | wardhold ci export и ci run в любом пайплайне, маскирование в логах |
| Константы и справочники 1С | Копия базы для подрядчика увозит боевые токены обменов и банк-клиента | Конфигурация забирает значение запросом в момент выполнения; в базе остаётся только адрес и токен доступа |
| Параметры роботов и бизнес-процессов Битрикс24 | Токен внешнего API виден каждому, кто редактирует сценарий, и уезжает в экспорт шаблона и журнал процесса | Действие «Wardhold: получить секрет»: значение запрашивается в момент выполнения шага, в шаблоне остаётся только имя секрета |
| Переписка и заметки | Пароль остаётся в чате навсегда и расходится вместе с историей | Одноразовая ссылка: запись шифруется в браузере, ключ живёт во фрагменте адреса и до сервера не доходит |
| Таблица или документ «пароли» | Никто не знает, какая строка актуальна, и правки затирают друг друга | Версии: активная всегда одна, прежние сохраняются, изменить версию нельзя |
Когда что
Не всякому контуру нужно хранилище
Внедрять инструмент ради инструмента — плохая идея. Но у привычки есть точка, после которой она начинает стоить дороже, чем любое хранилище, и эту точку видно по вопросам, на которые нет ответа.
Можно оставить как есть
- Один сервис и один человек: внедрение не окупится
- Секреты уже лежат в управляемом хранилище облака, других потребителей нет
- Контур временный и будет снесён раньше, чем истечёт первый токен
Пора заводить хранилище
- На вопрос «кто читал боевой токен и когда» ответа нет ни у кого
- При увольнении ротируется всё подряд — или, что чаще, не ротируется ничего
- Значение меняли перезаписью, и прежнего уже не восстановить
- Подрядчику пароль ушёл в переписку и остался там навсегда
- Копию базы или бэкап отдают наружу вместе с боевыми токенами
- Секреты нужны сразу нескольким потребителям: кластеру, пайплайну и 1С
Что спросить обеим сторонам
- Сколько времени займёт ответ на вопрос «какие секреты знал этот подрядчик»?
- Что придётся сделать, если завтра утечёт один токен из двадцати?
- Кто сегодня может прочитать пароль от боевой базы и как это проверить?
Переезд
С чего начать, чтобы не переделывать всё сразу
Возьмите один болезненный секрет
Обычно это доступ к боевой базе или токен обмена, который знают слишком многие. Заведите его как секрет и создайте первую версию — остальные значения пока живут где жили.
Подключите одного потребителя
Пайплайн, под в кластере или агент на сервере. С этого момента у вас появляется журнал: видно, кто и когда читал значение.
Ротируйте и посмотрите, что сломается
Новая версия — и потребители подхватывают её сами. Именно этот шаг показывает, сколько мест на самом деле знало старое значение.
Повторите для остальных
Дальше это рутина: каждый следующий секрет переезжает за минуты, а список того, что ещё лежит по файлам, сокращается.
Другие сравнения
Пассворк
Корпоративный менеджер паролей, доросший до машинных секретов.
Yandex Lockbox
Управляемый сервис внутри одного облака; его семантику мы повторили намеренно.
HashiCorp Vault и OpenBao
Динамические секреты, PKI и transit — задача шире нашей.
Bitwarden, 1Password и подобные
Менеджеры паролей для людей: расширение, приложения, автозаполнение.
Начать
Аккаунт в облаке — за минуту
Регистрация открыта: почта и пароль. Организация, проект и личный сейф создаются сразу, платить за личное использование не нужно.