Перейти к основному контенту

Модель безопасности

Эта страница описывает, какие данные и компоненты Клавдия требуется защищать, какие меры встроены в продукт и какие меры необходимо обеспечить на уровне инфраструктуры.

Технические детали шифрования, сертификатов и аудита приведены в Проверке защиты данных и аудита и Замене TLS-сертификата.

Защищаемые данные и компоненты

Ресурс Основной риск Механизм защиты
Тела писем и вложения перехват, кража носителя шифрование на диске AES-256-GCM, TLS в каналах
Пароли источников и каталога кража из базы, утечка шифрование AES-256-GCM, расшифровка только в памяти
Учётные записи пользователей подбор пароля, кража сессии MFA/TOTP, LDAP/AD, RADIUS
Настройки и права изменение в обход интерфейса контроль целостности HMAC
Каналы связи перехват трафика TLS
Секретный ключ кластера компрометация и расшифровка данных хранение в secrets/ с правами 0600, резервное хранение и ротация
Журнал аудита подмена или удаление записей неизменяемый журнал

Встроенные средства защиты

TLS

  • Веб-интерфейс работает по HTTPS с сертификатом из базы. См. TLS-сертификат веб-интерфейса и публичных служб.
  • IMAP и SMTP используют тот же централизованно хранимый сертификат. См. Настройка IMAP-сервера Клавдия и Настройка SMTP-сервера Клавдия.
  • Подключения к источникам IMAP, EWS и SMTP выполняются по защищённым каналам; открытый канал не используется.
  • LDAP/AD подключается только через TLS/SSL; конфигурация с открытым каналом отклоняется. См. Подключение LDAP / Active Directory.
  • Внутрикластерный трафик хранилища на порту 8444 передаётся по HTTPS. Проверка сертификата по умолчанию отключена для доверенной внутренней сети; для внешних узлов через публичную сеть включите KLVD_STORAGE_SSL_VERIFY=1.
  • Локальный Solr также работает по HTTPS с тем же сертификатом.

Один сертификат используется всеми службами узла. Его можно загрузить и заменить через веб-интерфейс без перезапуска узла.

Шифрование архива на диске

Шифрование AES-256-GCM включается для группы хранилищ. Для каждой группы используется свой ключ. Шифрование не меняет поведение поиска, просмотра и дедупликации: хеш блока рассчитывается по открытым данным. Ключи не хранятся в базе и выводятся из секрета узла.

См. Как устроены хранилища.

Аутентификация

Клавдий поддерживает:

  • TOTP-коды из приложения-аутентификатора;
  • RADIUS как резервный способ проверки учётных данных; можно настроить несколько серверов с приоритетами и проверкой связи;
  • единый вход SAML 2.0 через ADFS, Microsoft Entra ID, Keycloak и Okta. Клавдий работает как Service Provider, проверяет подпись SAML-ответа (xmldsig) и может автоматически создавать учётные записи.

RADIUS настраивается в [Настройки] → [RADIUS], SAML — в [Настройки] → [SSO (SAML)].

Права доступа

RBAC(!) работает по принципу запрета по умолчанию: пользователь получает только явно разрешённые права. Можно ограничивать доступ к разделам, ящикам, источникам и отдельным действиям. Массовый сбор и серверные настройки доступны только администратору; массовый сбор не выдаёт права на чужие ящики автоматически.

См. Правила доступа и RBAC.

Контроль целостности настроек

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

Аудит

Клавдий фиксирует:

  • удаление писем по сроку хранения в [Хранение] → [Аудит удалений];
  • наложение, применение и снятие заморозок legal hold(!);
  • отказы в доступе, которые также отображаются на панели состояния.

Меры на уровне инфраструктуры

Сеть

  • Ограничьте сетевым экраном доступ к портам Клавдия только доверенными сетями: веб-интерфейс 8001, IMAP 993, SMTP 25, хранилище 8444.
  • Для административного доступа из публичных сетей используйте VPN.
  • При Docker Compose используйте network_mode: host только на доверенном хосте. В Kubernetes применяйте NetworkPolicy.

Операционная система

  • Регулярно устанавливайте обновления безопасности ОС и Docker.
  • Ограничьте доступ к secrets/ и .env; рекомендуемые права — 0600, владелец root.
  • При необходимости включите auditd для контроля доступа к файлам секретов.

Резервное копирование

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

База данных

  • Для локальной PostgreSQL ограничьте доступ к порту 5432 узлами Клавдия.
  • Для внешней базы используйте SSL, например POSTGRESQL_SSL=require или verify-full, особенно при передаче трафика через публичную сеть.
  • Регулярно обновляйте СУБД.

Минимальная проверка перед эксплуатацией

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

Связанные материалы

Навигация по книге