Доверие к серверу: что на самом деле скрывается за словами Zero Knowledge

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

С чего начинается разговор

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

Причина простая. Этот продукт хранит не рабочие документы и не таблицы, а доступы ко всей остальной инфраструктуре — к серверам и облакам, к CRM и сетевому оборудованию, к админ-панелям, банковским кабинетам, боевым средам и внутренним сервисам. Компрометация такой базы — это не утечка одного сервиса, а потенциальный ключ ко всей компании.

Отсюда и главный вопрос при выборе. Не «хорошо ли защищён сервер», а «что достанется атакующему, когда защита не сработает». Ответ на него и определяет принцип Zero Knowledge.

Суть в одной фразе

Zero Knowledge (нулевое знание) означает, что сервер хранит ваши данные в зашифрованном виде, но ключа к ним у него физически нет. Список того, что сервер при этом делает, остаётся длинным: он принимает зашифрованные хранилища и синхронизирует их между устройствами, держит бэкапы, управляет пользователями, ролями и политиками, ведёт аудит, проверяет права. Одного он не делает никогда — не читает содержимое: пароли, заметки, TOTP-секреты, вложения.

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

Именно так работают 1Password и Keeper. У 1Password пароль аккаунта и Secret Key соединяются локально и наружу не уходят. Keeper строит модель на локальном шифровании и расшифровании прямо на устройстве пользователя.

Алгоритм шифрования вторичен

Самое распространённое заблуждение звучит так: раз данные шифруются, значит это уже Zero Knowledge. Это не так.

Строчка «применяется ГОСТ или AES-256» описывает инструмент, но молчит о модели доверия. Ключевой вопрос не в том, чем шифруют, а в том, в какой момент и где.

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

Нулевое знание существует только во втором сценарии.

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

Четыре условия настоящего Zero Knowledge

Полноценная модель не сводится к одной галочке. Она держится на нескольких опорах сразу.

Первая опора — клиентское шифрование. Пользователь вводит мастер-пароль, и прямо на устройстве из него вычисляется ключ шифрования. Его называют производным: он выводится из мастер-пароля по специальной функции и нигде отдельно не хранится. Этим ключом данные шифруются локально и только после этого уходят на сервер.
Вторая опора — серверу не достаётся материал для расшифровки. Стоит мастер-паролю, приватному ключу или тому самому производному ключу хоть раз оказаться на сервере, и вся конструкция теряет смысл.
Третья — восстановление доступа не работает как тайная отмычка. Если администратор сбрасывает мастер-пароль и сразу читает прежнее хранилище сотрудника, нулевого знания здесь нет. В честной схеме потеря ключа ведёт либо к потере данных, либо к заранее подготовленной криптографической процедуре восстановления — третьего не дано.
Четвёртая — защищается вся запись, а не одно поле с паролем. Зашифрованный пароль рядом с открытыми URL, логином, названием, комментариями, тегами и историей действий — это уже компромисс. Иногда допустимый, но называть его полным Zero Knowledge нечестно.

Именно на вопросе о том, что шифруется, а что остаётся открытым, рекламные заявления чаще всего расходятся с реальной архитектурой.

Метаданные выдают не меньше пароля

Интуиция подсказывает, что прятать надо пароль, а остальное второстепенно. В корпоративном контексте остальное бывает не менее опасным.

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

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

Что компания выигрывает

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

Второй выигрыш меняет роль администратора. Он по-прежнему управляет системой, пользователями, группами, политиками и аудитом, но открыть чужой пароль уже не может: полномочия и доступ к содержимому разведены.

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

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

За что приходится платить

Бесплатной такая защита не бывает, и честно знать цену заранее.

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

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

Усложняется обмен записями. Передать коллеге одну запись означает безопасно вручить ему ключ этой записи или переупаковать данные под его ключ.

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

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

Тот же принцип за пределами паролей

Zero Knowledge встречается не только у менеджеров паролей.

В облачных хранилищах родственный подход называют zero-access encryption. Proton описывает его так: данные на сервере зашифрованы и открыть их может только владелец, но не сам сервис. В почте письма и вложения закрывают сквозным (end-to-end) и zero-access шифрованием.

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

Локальные продукты решают задачу проще всего. KeePass — это зашифрованный файл, который раскрывается только мастер-ключом. Криптография крепкая, но командные функции (роли, аудит, совместная работа, единое управление) остаются за кадром и требуют отдельных решений. В корпоративных облачных и on-premise-платформах планка выше: туда нужно уместить и клиентское шифрование, и роли с группами, и аудит, и обмен записями, и восстановление, и удобство.

Расстановка сил на рынке

Для зарубежных вендоров нулевое знание давно превратилось в пункт конкурентного сравнения.

1Password опирается на локальную связку пароля аккаунта и Secret Key, оставляя на сервере лишь зашифрованное хранилище. Keeper выстраивает шифрование и расшифрование исключительно на устройстве, а каждую запись закрывает отдельным клиентским ключом. Bitwarden открыто называет Zero-Knowledge Encryption своей базовой моделью защиты данных.

В российском выделяется корпоративный менеджер паролей ОдинКлюч, в котором клиентское шифрование используется по умолчанию: вычисления идут локально, на сервер уходит только зашифрованный контейнер. В результате, даже администратор с полным доступом к хосту не видит содержимого записей. Для on-premise-рынка это сильный признак полноценной архитектуры нулевого знания.

В целом, при выборе менеджеров паролей, важно не только опираться на маркетинговые материалы, а проверять, что именно шифруется, какие метаданные открыты, как работает возврат доступа, какие поля видны и как ключи передаются между сотрудниками, что доступно администратору и можно ли самому изучить сетевой трафик и дамп базы?

Частичная модель — это нормально, пока её называют своим именем

Реализации различаются по силе, и различия принципиальны. Где-то шифруют только пароль, оставляя на виду URL и логин. Где-то закрывают записи, но не трогают названия, теги и комментарии. Где-то клиентское шифрование — лишь опция. Где-то личные сейфы защищены лучше общих. А где-то серверное шифрование выдают за надёжную защиту, умалчивая, что ключи остаются у сервера.

Каждый из этих вариантов лучше открытого хранения. Но ни один не равноценен полноценному нулевому знанию.

Чтобы не путаться, заказчику удобно держать в голове четыре уровня:

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

Беда не в существовании частичных моделей. Беда в том, когда их продают как полную защиту от взлома сервера или от администратора.

Семь вопросов для проверки на месте

Перед внедрением имеет смысл пройтись по короткому списку и сверить ответы поставщика с тем, что считается правильным.
1. Где шифруются данные? Должно быть — на клиенте, до отправки.
2. Уходит ли мастер-пароль на сервер? Должно быть — нет.
3. Сможет ли сервер восстановить хранилище без пользователя? Если да, это не полное нулевое знание.
4. Что видит администратор? Доступ к чужим паролям ломает всю модель.
5. Что произойдёт при краже базы? В норме атакующему достаются только зашифрованные контейнеры и метаданные в заявленном объёме.
6. Какие поля остаются открытыми на клиенте? Открытые URL, логины, названия и теги нужно осознавать заранее.

Можно ли проверить самому? Крепкая архитектура спокойно проходит проверку сетевым трафиком, дампом базы и админ-интерфейсом.

Почему тема острее для российского бизнеса

Российские компании смотрят на менеджер паролей не только через удобство. На первый план выходят on-premise-установка, импортонезависимость, контроль над инфраструктурой, отечественные криптоалгоритмы, аудит, связка с AD/LDAP, работа в закрытых контурах и соответствие внутренним требованиям ИБ.

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

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

Коротко для решения

Zero Knowledge — это не строчка рядом с названием шифра, а свойство, которое можно проверить. Когда сервер не получает мастер-пароль, не хранит ключей расшифровки, не видит содержимого записей и не позволяет администратору вскрывать чужие секреты, защита действительно сильная.

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

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

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

2026-06-09 20:49 Статьи