OpenBao и доли Шамира: как устроено хранилище секретов

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

Руководства по хранилищам секретов обычно заканчиваются на команде инициализации. Дальше подразумевается, что всё работает. Ниже разобрано, из чего на самом деле состоит это «дальше»: как устроено распечатывание, почему я отказался от аппаратного модуля в роли печати, какие проверки оказались зелёными там, где должны были краснеть, и что до сих пор не проверено. Версии и даты сверены по первоисточникам на 24 сентября 2026 года.

Статус: собрано, отрепетировано, не запущено

Хранилище это OpenBao в контейнере, со встроенным хранилищем на протоколе Raft и распечатыванием по схеме Шамира. Развёртывание описано кодом на Ansible: одиннадцать плейбуков на инициализацию, распечатывание, смену ключей, ротацию, проверку и резервное копирование, и около двадцати пяти вспомогательных скриптов. Наружу хранилище не выставлено: доступ только из локальной сети и через туннель.

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

Чего нет: боевой церемонии, прогона смены версии, ротации ключа и журнала аудита на боевом узле, восстановления из снимка в новый кластер. Я не выдаю тестовый стенд за эксплуатацию, и дальше в тексте везде, где утверждение проверено только на стенде, так и сказано.

Почему OpenBao, а не Vault

OpenBao это форк HashiCorp Vault под лицензией MPL-2.0, который развивается в OpenSSF при Linux Foundation. Vault с 2023 года распространяется под лицензией Business Source License, и для меня этого достаточно: хранилище, на котором держится доступ ко всему остальному, не должно зависеть от того, как изменятся условия чужой лицензии. Плюс подписанные репозитории пакетов и пространства имён без коммерческой редакции.

Цена выбора конкретная: у OpenBao нет официальной коллекции Ansible, поэтому роль развёртывания пришлось писать самому. Это не катастрофа, но это неделя работы, которой при выборе Vault не было бы. Я её заплатил сознательно: роль, написанная под свою задачу, понятнее чужой, и каждое её решение записано рядом с кодом.

Схема Шамира не умеет обязательных долей

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

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

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

Какие отказы переживает раскладка

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

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

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

Аппаратный модуль я купил и не сделал печатью хранилища

Для хранилищ этого класса есть очевидный соблазн: аппаратный модуль безопасности в роли печати, чтобы хранилище распечатывалось само, без людей. Я купил YubiHSM 2 и после разбора от этой роли отказался. Устройство лежит в заводском состоянии, и причин четыре.

• Логическая. «Без аппаратного ключа не открыть» и «машина открывается сама» взаимоисключающи. При печати на модуле единственным фактором становится PIN в окружении контейнера плюс железка в том же хосте.
• Кодовая. В исходниках OpenBao 2.6.1 при автоматической печати шифрование долей ключами держателей отключено, а число долей и порог жёстко выставляются в единицу. Схеме пять из трёх просто негде жить.
• Рисковая. Одна USB-железка, потеря которой означает необратимую потерю всего хранилища, включая снимки.
• Временная. В версии 2.7.0, вышедшей 23 сентября 2026 года, встроенную печать через PKCS#11 вынесли во внешний плагин, а отдельную сборку для аппаратных модулей прекратили. Замена существует, но это плагин ранней версии, и корень доверия я на неё не ставлю.

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

Официальный на вид гайд навсегда привязывает хранилище к одной железке

Это находка, ради которой разбор окупился целиком. В репозитории OpenBao открыт запрос на слияние с документацией по автоматическому распечатыванию через YubiHSM. Выглядит он совершенно официально, но в команде создания ключа нет одного флага: exportable-under-wrap.

Документация Yubico на этот счёт однозначна: возможности объекта задаются в момент его создания или импорта, и добавить их к существующему объекту нельзя. Ключ, созданный без права экспорта под обёрткой, нельзя будет ни скопировать, ни восстановить на другом устройстве. Тот, кто скопирует гайд как есть, навсегда привяжет хранилище к одной железке и узнает об этом в день её смерти.

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

Автоматическое распечатывание убирает людей, а вместе с ними и защиту

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

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

Репетиция держателей обязательна, потому что церемония необратима

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

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

Репетиция нашла и настоящую аппаратную проблему. На одном из ключей одновременно живут доля хранилища и сертификат, которым подписываются коммиты. Выбор апплета шифрования на этой карте рвёт сессию подписи: в журнале агента набралось 254 строки несовпадения PIN, а карта пропадала из системы. Теперь на время работы с долями агент подписи останавливается сам и возвращается обратно, даже если прервать процесс. Штатная тройка при этом составлена так, чтобы этот ключ обычно вообще не требовался.

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

Доли выдаются по имени, а не по номеру

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

• Доли выдаются по имени держателя, а не по индексу. В артефакте они лежат массивом, и перепутать чужую долю под стрессом это вопрос одной цифры.
• После показа доли экран очищается вместе с историей прокрутки.
• Необратимые действия требуют набрать «ДА» заглавными. Не нажать Enter, а набрать слово.
• Один пульт вместо десяти команд с флагами. Он показывает состояние, называет следующий шаг и перед запуском печатает точную команду. Ничего не прячет: всё, что он делает, работает и руками.
• Помощник распечатывания смотрит, какие токены вставлены, спрашивает PIN на каждую долю и добирает недостающее паролем и бумагой.

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

Проверки, которые зелёные, когда должны краснеть

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

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

Опрос прав. У хранилища есть способ спросить «какие права у этого токена на этот путь». Замерено: для части служебных путей опрос отвечает «запрещено», а запрос проходит, в том числе без токена и с заведомо мусорным токеном. Часть путей просто не доходит до подсистемы прав. Для проверки запретов это худший вид ошибки: зелёное там, где доступ есть. Теперь у каждого запрета две независимые проверки: опрос прав и живой запрос с требованием отказа.

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

Одно слово в политике возвращало права суперпользователя

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

Проверка «эта роль не может писать» была построена как список запрещённого: создание, изменение, удаление и повышенные права. Возможность patch в этот список не попала. Замерено руками: роль с правом только читать и патчить политики получала отказ на обычную запись, но успешно переписывала политику через PATCH и выдавала себе права на всё. Обе линии защиты при этом оставались зелёными, потому что пробовали только тот способ записи, который был в списке.

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

Там же нашлась вторая проблема из этого класса: разделение прав, которое не разделяет. Роль, которая пишет политики, может переписать и свою собственную тем же токеном. Разделение даёт видимость эскалации в журнале аудита, а не её невозможность. Утверждение «эта роль не читает секреты» в отчёте по безопасности было бы ложью. Честное решение одно: забрать у этой роли запись политик и сделать изменение прав церемонией, которая требует порога долей.

Сторож был мёртв при полностью зелёном такте

В хранилище есть приманка: секрет, который никому не нужен, и любое его чтение означает, что кто-то ходит там, где не должен. Рядом работает сторож, который каждые пять минут проверяет, не читали ли приманку. Задание планировщика запускалось исправно, выходило с кодом успеха и печатало «метрики приманки обновлены».

Внутри него сторож падал. Планировщик macOS даёт заданиям урезанный путь поиска программ, в котором нет ни Ansible, ни Docker, и дочерний процесс не находил нужную утилиту. Успехом при этом считалось само существование файла метрик, а не его свежесть. Итог: счётчик чтений приманки был заморожен. Прочитай кто-нибудь приманку в это время, счётчик остался бы нулём. Молчали оба канала: такт рапортовал об успехе, а файл ошибок был пуст, потому что вывод упавшего процесса никуда не шёл.

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

Урок записан отдельно: «запланировано» и «работает» это разные утверждения, и проверялось только первое. Теперь гарантия проверяет не то, что задание стоит в расписании, а свежесть замера, с порогом втрое больше такта, чтобы не краснеть после каждого закрытия крышки. Ложная тревога обесценивает гарантию так же надёжно, как молчание.

Тревога, которую перестали читать, хуже отсутствующей

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

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

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

Смена версии единственная операция, которая запечатывает хранилище

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

И она неизбежна. У OpenBao нет линии длительной поддержки: исправления получают только свежие версии, а брошенная линия 2.5 осталась с опубликованными уязвимостями, которые туда уже не переносят. Значит принудительная смена версии заложена в саму конструкцию. Наглядно это видно прямо сейчас: развёртывание закреплено на 2.6.1, а 23 сентября 2026 года вышли сразу 2.7.0 и 2.6.3, и в 2.6.3 закрыто восемь уязвимостей, в том числе утечка данных запроса в журнал аудита открытым текстом. Хранилище ещё не открыто, а уже отстаёт на две версии с исправлениями безопасности.

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

Что пока не проверено

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

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

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

Чего я сознательно не делаю

• Не держу доли и корневой токен в git ни в открытом, ни в зашифрованном виде. Приватный репозиторий не то же самое, что неопубликованный.
• Не делаю автоматическое распечатывание. Удобство покупается точкой отказа, которую нельзя восстановить.
• Не ставлю печать на аппаратный модуль через плагин ранней версии. Корень доверия не должен стоять на версии 0.1.
• Не отзываю корневой токен, пока аварийный вход не проверен настоящим логином. Иначе можно остаться без единого способа войти.
• Не даю пересоздать боевой контейнер без явного флага. Пересоздание означает запечатывание, и случайно его сделать нельзя.
• Не пишу проверки запретов списком запрещённого. Только списком разрешённого.
• Не выпускаю сертификат для самого хранилища из его же движка PKI. Запечатанный сервер не может выписать себе сертификат, и это классическая курица и яйцо.
• Не выдаю стенд за эксплуатацию. Всё, что проверено только на стенде, так и называется.

Стек

• OpenBao: хранилище секретов, закреплено на 2.6.1 по цифровому отпечатку образа; встроенное хранилище на Raft.
• Ansible: развёртывание, церемония, распечатывание, проверки; своя роль, потому что официальной коллекции нет.
• Docker: контейнер хранилища.
• YubiKey: три доли из пяти, зашифрованные на OpenPGP-ключи токенов.
• YubiHSM 2: куплен, в роли печати отклонён, назначен под офлайн-корень внутреннего удостоверяющего центра.
• Let’s Encrypt: сертификат самого хранилища через проверку DNS, а не из собственного движка.
• Prometheus: метрики, живость, сторож приманки.

Почему это важно тому, кто платит

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

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

Частые вопросы

Почему OpenBao, а не HashiCorp Vault?

OpenBao это форк Vault под лицензией MPL-2.0 в OpenSSF при Linux Foundation, а Vault с 2023 года распространяется под Business Source License. Для хранилища, на котором держится доступ ко всему остальному, я не хочу зависеть от условий чужой лицензии. Цена выбора: официальной коллекции Ansible у OpenBao нет, роль развёртывания пришлось писать самому.

Можно ли в схеме Шамира сделать долю обязательной?

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

Почему не распечатывать хранилище автоматически через аппаратный модуль?

Потому что «без аппаратного ключа не открыть» и «открывается само» взаимоисключающи, а потеря единственного модуля означает необратимую потерю хранилища, включая снимки. Кроме того, в OpenBao 2.7.0 встроенную печать через PKCS#11 вынесли во внешний плагин ранней версии. Переход на неё позже возможен без потери текущих долей.

Что опасного в гайдах по YubiHSM для OpenBao?

Если ключ создан без права экспорта под обёрткой, его нельзя будет ни скопировать, ни восстановить на другом устройстве, а добавить это право позже нельзя. Такой ключ навсегда привязывает хранилище к одной железке. Ключ нужно создавать с флагом exportable-under-wrap и выгружать в резервную копию до инициализации хранилища.

Как проверить, что журнал аудита действительно пишется?

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

Сколько стоит обновление такого хранилища?

Смена версии единственная операция обслуживания, которая запечатывает хранилище, поэтому к её началу должны быть доступны держатели долей. У OpenBao нет линии длительной поддержки, так что смена версии происходит регулярно, раз в несколько месяцев. Это операция с владельцем и календарём, а не разовый проект.

Зачем репетировать держателей, если шифрование долей уже проверено?

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

Источники

• Релизы OpenBao, в том числе 2.7.0 и 2.6.3 от 23 сентября 2026 года.
• Печать и распечатывание в OpenBao: схема Шамира, автоматическая печать, ключи восстановления.
• Запрос на слияние с гайдом по YubiHSM, открыт на 24 сентября 2026 года.
• Руководство пользователя YubiHSM 2: возможности объектов и экспорт под обёрткой.
• HashiCorp: переход Vault на Business Source License и покупка компании IBM.
• Схема разделения секрета Шамира.

Нужна консультация?

Если вы выбираете хранилище секретов или у вас уже есть такое и хочется понять, переживёт ли оно плохой день, запишитесь на разговор. Разберём раскладку долей, список держателей, проверки аудита и то, когда хранилище последний раз восстанавливали из снимка. Смежные материалы: кластер Kubernetes на своих серверах, кластер Proxmox как код.