Hoodik: своё зашифрованное облако для документов клиентов

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

Клиент фотографирует паспорт и отправляет в мессенджер. Бухгалтер пересылает скан договора на почту. Клиника просит анализы в переписке. Файл остаётся в десятке мест: в облаке мессенджера, на телефоне сотрудника, в почтовом ящике, в резервных копиях чужих сервисов. Удалить его оттуда потом нельзя, а при утечке непонятно, откуда она случилась.

Нужно место, куда клиент загружает документ по ссылке, а вы забираете его оттуда, и оно под вашим контролем. Один из вариантов нашёлся в репозитории hudikhq/hoodik. Проект описан в README как лёгкий самохостинговый сервер хранения со сквозным шифрованием. Поводом стал пост канала GitHub Community от 6 октября. Сам пост я не открывал, поэтому всё ниже сверено по репозиторию.

Что такое Hoodik по данным репозитория

Backend написан на Rust (Actix-web), интерфейс на Vue 3. Развёртывание через Docker: образ hudik/hoodik, один контейнер, порт 5443, данные в каталоге DATA_DIR. По умолчанию работает SQLite, PostgreSQL включается переменной окружения. Зашифрованные части файлов можно хранить на диске сервера или в S3-совместимом хранилище.

Из возможностей README называет загрузку файлов частями, публичные ссылки, зашифрованный поиск по именам файлов, заметки в формате markdown, двухфакторный вход по TOTP и панель администратора с пользователями и приглашениями. На сайте проекта hoodik.io сказано про общий доступ к файлу или целой папке с выбором прав и про отдельный вход для каждого человека. Есть приложения для Android, iOS и macOS.

Проект живой. Последний коммит в ветке master от 22 сентября 2026 года, последний релиз v2.5.5 от того же числа, репозиторий не архивирован, у него около 1,5 тысячи звёзд на GitHub.

Как устроено шифрование

По README, файл шифруется в браузере кусками, каждому файлу достаётся случайный ключ. Основной шифр AEGIS-128L, поддерживаются также AEGIS-256, Ascon-128a и ChaCha20-Poly1305. Ключи файлов оборачиваются гибридом X25519 и ML-KEM-768, то есть с расчётом на будущие квантовые компьютеры. Вход устроен по протоколу OPAQUE, пароль на сервер не уходит, а приватный ключ хранится там в зашифрованном виде и открывается только паролем.

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

Чем это отличается от облака с серверным шифрованием

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

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

Чего сквозное шифрование не даёт

Первое, лицензия. Репозиторий выпущен под CC BY-NC 4.0, то есть коммерческое использование без отдельного соглашения запрещено. В LICENSE.md автор предлагает написать ему для коммерческой лицензии. Юридическая контора, клиника или бухгалтерская фирма работают в коммерческих целях. Поэтому по моему прочтению, перед внедрением нужна коммерческая лицензия, а условия обсуждаются с автором. Цен на неё я не нашёл. Это моя трактовка, формальный ответ даст юрист.

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

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

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

152-ФЗ и сервер в России

Паспорта и анализы это персональные данные. Правила локализации и порядок переноса я разбирал в статье про локализацию баз по 152-ФЗ. Если разворачивать Hoodik на сервере в России, зашифрованные файлы и база пользователей лежат на территории страны. Считать ли зашифрованные данные персональными, решает юрист, я исхожу из осторожного варианта и отношусь к ним как к персональным.

Облачная версия Hoodik Cloud, которую предлагает автор проекта, это отдельный сервис. Где стоят её серверы, я не проверял, поэтому в расчёт её не беру. Статья не заменяет консультацию юриста.

Как я разворачиваю под ключ

Порядок такой. Сервер в российском дата-центре, домен для облака, HTTPS с настоящим сертификатом (самоподписанный из быстрого старта для клиентов не годится), контейнер Hoodik за обратным прокси, постоянный JWT_SECRET, чтобы сессии переживали перезапуск, настройки регистрации и приглашений в панели администратора. Для устойчивости ставлю PostgreSQL и хранилище на отдельном диске или в S3.

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

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

Можно ли использовать Hoodik бесплатно в организации?

По тексту лицензии CC BY-NC 4.0 нельзя, если использование коммерческое. Автор предлагает отдельную коммерческую лицензию. Условий и цен я не видел.

Что будет, если клиент или сотрудник забудет пароль?

Администратор файлы не вернёт, у сервера нет ключей. Вернуть доступ можно только сохранённым приватным ключом.

Чем это лучше одноразовой ссылки?

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

Коротко о главном

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

Если хотите разобраться, подходит ли такое облако вам, и получить сервер, домен, HTTPS, резервные копии и проверенный порядок восстановления, посмотрите безопасное хранение и доступ под ключ. Напишите мне в Telegram кодовое слово «СЕЙФ», и я отвечу, с чего начать.