Внутренний менеджер паролей с Zero-Knowledge архитектурой, разработанный для безопасного хранения корпоративных секретов. Основной принцип системы — мастер-пароль никогда не покидает браузер пользователя, а сервер физически не способен прочитать содержимое хранимых данных.
Ключевые особенности проекта:
- Zero-Knowledge архитектура;
- аутентификация без передачи пароля по протоколу SRP;
- клиентское шифрование данных;
- безопасный обмен секретами между сотрудниками;
Контекст
В компании постепенно накопилось большое количество чувствительных данных, требующих
безопасного хранения: пароли от серверов, API-ключи, учётные записи внешних сервисов,
содержимое .env-файлов и другие корпоративные секреты.
Фактически они хранились в переписках, заметках и различных документах, что создавало риск случайной утечки и затрудняло управление доступами.
Я выступил с инициативой о том, что эти чрезвычайно важные данные должны храниться в безопасном и одновременно удобном месте.
После обсуждения с руководством были сформулированы несколько обязательных требований к будущей системе:
- хранение всех данных исключительно внутри собственной инфраструктуры;
- отсутствие зависимости от облачных сервисов;
- полный контроль над развитием продукта;
- возможность безопасно предоставлять доступ сотрудникам без раскрытия секретов серверу.
Почему не готовое решение
Перед началом разработки было рассмотрено несколько существующих решений. В частности, был изучен Psono — open-source менеджер паролей, который можно развернуть внутри собственной инфраструктуры.
Однако после анализа стало понятно, что использование стороннего продукта не позволит полностью контролировать архитектуру и дальнейшее развитие системы, а также не даст свободно адаптировать её под внутренние процессы компании. В результате было принято решение разработать собственный менеджер паролей.
Помимо решения бизнес-задачи, этот проект позволил мне глубоко разобраться в современных подходах к построению Zero-Knowledge систем, безопасной аутентификации и защите данных.
Главный архитектурный принцип
С самого начала существовало одно фундаментальное требование:
Сервер не должен иметь технической возможности прочитать пользовательские секреты.
Даже если злоумышленник получит полный доступ к серверу или базе данных, он не должен иметь возможности восстановить содержимое паролей, API-ключей или других конфиденциальных данных. Именно это требование определило практически всю архитектуру системы.
Браузер знает │ Сервер хранит
────────────────────────┼──────────────────────────────
мастер-пароль │ только зашифрованные данные
ключ шифрования │ служебные данные протоколов
секреты в открытом виде │ (расшифровать их не может)Мастер-пароль и ключ шифрования никогда не передаются серверу и не сохраняются за пределами браузера пользователя.
Аутентификация без передачи пароля
Классическая схема входа с передачей пароля серверу противоречила выбранной архитектуре. Поэтому для аутентификации использовался протокол Secure Remote Password (SRP) — он позволяет доказать знание пароля без его передачи по сети.
Во время регистрации браузер вычисляет специальные проверочные данные (salt и verifier) и отправляет серверу только их. При последующих входах происходит криптографический обмен, в результате которого:
- сервер убеждается, что пользователь действительно знает пароль;
- браузер убеждается, что взаимодействует с настоящим сервером.
Сам пароль при этом никогда не передаётся.
Защита от перечисления пользователей. Даже если ввести email несуществующего аккаунта, сервер всё равно формирует полноценный ответ — на случайных данных. Это исключает возможность определить существование учётной записи по особенностям ответа сервера.
Осознанный инженерный компромисс. После первого этапа SRP состояние нужно временно сохранить до завершения второго этапа обмена. Изначально рассматривалась высокопроизводительная реализация протокола на C, однако она не поддерживала сериализацию состояния, необходимую для хранения в кэше. В результате была сознательно выбрана реализация на Python: несмотря на несколько меньшую производительность, она позволила безопасно сохранять промежуточное состояние в кэше, использовать его ровно один раз и значительно упростить архитектуру аутентификации.
После успешной проверки пользователю выдаётся стандартная JWT-сессия — короткоживущий access token и refresh token в HttpOnly-cookie.
Клиентское шифрование данных
Вторым следствием выбранной архитектуры стало полное шифрование данных на стороне клиента.
Из мастер-пароля прямо в браузере вычисляется ключ шифрования с использованием Argon2 — алгоритма, специально разработанного для защиты от перебора. Далее каждое поле секрета шифруется алгоритмом AES-GCM с собственным случайным nonce. На сервер передаются исключительно зашифрованные данные.
Ни мастер-пароль, ни ключ шифрования никогда не покидают браузер пользователя. Для сервера все записи — лишь непрозрачный набор байтов, независимо от их типа.
Самая сложная задача — безопасный обмен секретами
Хранение собственных секретов оказалось сравнительно простой задачей. Гораздо сложнее было реализовать безопасный обмен секретами между сотрудниками, не нарушая Zero-Knowledge модель: сервер не может расшифровать данные, а значит не способен самостоятельно передать секрет другому пользователю.
Для решения этой задачи была реализована система групповых ключей. У каждой группы есть собственный ключ шифрования, которым шифруются все записи внутри неё. При этом сам ключ группы хранится отдельно для каждого участника — в зашифрованном виде. Когда владелец добавляет нового участника, браузер переупаковывает ключ группы специально для него.
В результате:
- новый участник получает доступ к общим секретам;
- сервер продолжает хранить исключительно зашифрованные данные;
- модель Zero-Knowledge полностью сохраняется.
Поверх этой модели реализованы привычные механизмы управления: создание групп, приглашение и удаление участников, смена владельца и выход из группы.
Итоги
Этот проект стал для меня одним из самых интересных с инженерной точки зрения. Во время разработки я разобрался в современных подходах к проектированию безопасных систем, познакомился с практическим применением Zero-Knowledge архитектуры, протокола SRP, современных алгоритмов вывода ключей и клиентского шифрования данных.
Главной проблемой оказалось не само шифрование данных, а построение модели безопасного обмена секретами между пользователями без нарушения основного принципа — сервер не должен иметь возможности прочитать пользовательские данные. Именно работа над этой задачей сильнее всего повлияла на моё понимание архитектуры защищённых систем.