Перейти к содержанию

Безопасность

Архитектурный взгляд на модель безопасности платформы DataHUB: какие механизмы защиты применяются, на каких уровнях они работают, как взаимодействуют. Операционная сторона (как генерировать секреты, как настраивать TLS, как ротировать ключи) — в Развертывание / Настройка безопасности. Здесь — почему именно так, и где границы каждого механизма.

Уровни защиты

Защита платформы построена эшелонировано — на каждом уровне свои механизмы, рассчитанные на свой класс угроз.

Уровень Защищает от Механизмы
Сетевой Прямого доступа извне к внутренним сервисам nginx как единая точка входа, firewall, разделение dh_network на внутренний контур
Транспортный Перехвата трафика, MITM TLS на всех публичных эндпоинтах, опциональный mTLS для exchange-домена
Аутентификации Несанкционированного доступа в LK и в API JWT (access/refresh), service token для системных интеграций
Авторизации Доступа к чужим ресурсам Spring Security, роли для пользователей LK; маршруты и классы сообщений для клиентских систем
Хранения секретов Утечки при компрометации БД Pepper-хеширование паролей, JWT-ключи на ФС вне БД, шифрование БД на уровне инфраструктуры
Доступности DoS, перебор паролей Rate-limiting (Bucket4j), временная блокировка после N неудач, лимиты nginx
Аудита Нерасследованных инцидентов Лог authentication-событий, логи backend (docker logs), nginx access log, метрики RabbitMQ Management

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

В платформе два типа субъектов и, соответственно, два механизма аутентификации:

Пользователи LK

Администраторы, использующие веб-интерфейс. Аутентификация:

  • Логин по email + паролю.
  • Опциональный второй фактор (SMS-OTP).
  • После входа выдаётся пара токенов: access (короткий, ~15 минут) и refresh (~7 дней).
  • Refresh используется только для получения нового access — не для бизнес-операций.

JWT-токены — формата JOSE (HS/RSA, через spring-security-oauth2-jose + jjwt). Подписываются ключами Сервера DataHUB, лежащими в /etc/datahub/backend/certs/.

Полный флоу с экранами регистрации, входа, 2FA, сброса пароля — в Интеграции / Авторизация. Все детали реализации — в пакете com.datahub.backend.api.security.

Клиентские системы

Интегрируемые ИС, использующие шинный API напрямую. Аутентификация:

  • Не используют пользовательский логин/пароль.
  • Аутентифицируются service token'ом — долгоживущим (до года) ключом, выпущенным администратором для конкретной системы.
  • Service token позволяет получить access-токен для текущей сессии.
  • Реализация — ServiceTokenManager в api.security.services.

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

Авторизация

После аутентификации Spring Security применяет авторизацию — проверку, что именно субъекту разрешено делать.

Для пользователей LK — роли (ADMIN, OPERATOR, и т. п.), привязанные к учётной записи в PostgreSQL. Каждый контроллер LK-контура требует определённой роли.

Для клиентских систем — отдельного уровня «прав на типы сообщений» нет. Доступность обмена определяется конфигурацией в LK:

  • Если класс сообщения не зарегистрирован — Exchange-контур вернёт ошибку.
  • Если маршрут между отправителем и получателем не настроен — сообщение не доставляется; отправитель при этом получает подтверждение приёма (тихая недоставка).

Exchange-контур на каждом запросе проверяет валидность JWT и идентифицирует систему. Ограничение доступа к конкретным получателям обеспечивается маршрутной логикой, а не отдельным permission-уровнем. Подробнее — в Концепции / Маршруты и Концепции / Классы сообщений.

Защита от brute-force

Защита от перебора паролей и токенов реализована несколькими слоями.

Rate-limiting через Bucket4j

bucket4j-spring-boot-starter интегрирован в Spring-фильтры. Применяется на:

  • /api/auth/login — ограниченное число попыток входа в минуту с одного IP.
  • /api/auth/2fa/* — ограниченное число попыток ввода OTP.
  • API в целом — общий потолок RPS на источник.

При превышении — HTTP 429 с указанием времени до следующей попытки. Конкретные значения — параметры конфигурации (см. Сервер DataHUB).

Блокировка учётной записи

После N неудачных попыток входа учётная запись блокируется на M минут. Это не «навсегда» — автоматический unlock через таймаут предотвращает denial-of-service атаку на конкретного пользователя через намеренные неверные пароли.

nginx rate-limiting

Дополнительный слой на уровне reverse-proxy — лимиты по IP и по эндпоинту в самой nginx (limit_req_zone). Это работает до того, как запрос дойдёт до backend, и защищает в том числе от вырожденного флуда.

Хеширование паролей

Пароли пользователей никогда не хранятся в открытом виде и никогда не хешируются «голым» bcrypt'ом. Применяется конструкция «pepper + bcrypt»:

  • Pepper — секретная серверная константа, лежащая в /etc/datahub/backend/certs/pepper.txt, не попадающая в БД.
  • На входе: пароль конкатенируется с pepper, результат хешируется bcrypt'ом.
  • Хеш сохраняется в БД.

Если злоумышленник украл дамп БД — у него хеши без pepper'а; даже rainbow-tables по bcrypt не помогут, потому что без pepper нельзя проверить пароль. Если украден pepper, но не БД — без хешей он бесполезен.

Это стандартная конструкция для систем, в которых разные классы данных могут быть скомпрометированы независимо (БД и файловая система хоста). Подробнее в Развертывание / Настройка безопасности / Секреты.

Парольная политика

Параметры:

  • Минимальная длина пароля.
  • Запрет повторного использования (история N последних паролей).
  • Срок действия пароля — после истечения принудительный логаут и требование смены.
  • Минимальный набор классов символов (цифры, буквы разных регистров, спецсимволы).

Все параметры настраиваются через .env backend'а и должны быть согласованы с frontend (для валидации формы при вводе). Реализация — api.security.services.PasswordPolicy*.

TLS и mTLS

Стандартный TLS обязателен на всех публичных эндпоинтах:

  • lk.<domain> — Let's Encrypt или другой доверенный CA.
  • exchange.<domain> — то же.
  • Админ-порты (15432, 15672) — отдельные сертификаты.

mTLS опционален на exchange.<domain> — для случаев, когда заказчик хочет на сетевом уровне ограничить, какие именно клиенты вообще могут открыть TLS-соединение с шиной (а не только пройти аутентификацию). Клиент должен предъявить сертификат, подписанный своим CA, известным шине. Это второй фактор поверх токенной авторизации.

Реализация — на уровне nginx, не backend'а. Backend получает заголовки X-Client-Cert-* от nginx и при необходимости их использует. Детали настройки — в Развертывание / Настройка безопасности / TLS-сертификаты.

Кеш аутентификации

Валидация JWT — операция дешёвая (проверка подписи), но загрузка конфигурации обмена (маршруты, классы сообщений, данные системы) — требует похода в БД. Чтобы Exchange-контур не упирался в БД на каждом сообщении, конфигурация кешируется в Caffeine — с TTL и явной инвалидацией при изменении настроек в LK.

Это снимает большую часть нагрузки на БД при высоком RPS. Trade-off — при изменении маршрутов или классов через LK Exchange может несколько секунд работать со старой конфигурацией (до сброса кеша).

Аудит

Логируются:

  • Все попытки аутентификации (успешные и неуспешные) — для отслеживания brute-force и аномалий.
  • Все административные операции в LK (создание пользователя, изменение прав, изменение маршрутов).
  • HTTP-запросы — в nginx access log.
  • Технические события обмена (приём сообщения шиной, перепубликация, ошибки) — в логи backend (docker logs backend).

Централизованного лога доставки сообщений на стороне шины пока нет — статус прохождения видится через клиентские модули (в 1С — отдельная страница статусов исходящих и входящих) и через RabbitMQ Management (длины очередей, in-flight). Централизованный трекинг — в roadmap; до его выпуска расследование инцидентов обмена опирается на лог клиентского модуля + операционные метрики RMQ.

Все логи структурированы (JSON), что позволяет интегрировать их с централизованной системой агрегации (ELK / Loki / Splunk). Подробнее — в Развертывание / Мониторинг и логи.

Security headers

nginx устанавливает на ответах публичных доменов:

  • Strict-Transport-Security (HSTS).
  • X-Content-Type-Options: nosniff.
  • X-Frame-Options: DENY (на pgAdmin — SAMEORIGIN из-за iframe SQL-вывода).
  • X-XSS-Protection.

Это защита от наиболее частых клиентских атак — clickjacking, MIME-sniffing, downgrade на HTTP.

Что НЕ входит в модель

  • Шифрование payload сообщений end-to-end между отправителем и получателем. Шина видит payload (для маршрутизации и логирования). Если двум системам нужно скрыть данные даже от шины — они должны зашифровать их на своём уровне (например, AES-ключом, которым обладают только обе стороны). Платформа этому не препятствует, но и не реализует.
  • Антивирус на S3-хранилище. Это вопрос настройки самого хранилища (некоторые S3-провайдеры дают сканирование «из коробки»). DataHUB сам файлы не сканирует.
  • DLP и контроль содержимого сообщений. Шина — транспорт, не DLP-инструмент. Все политики «что можно отправлять, а что нет» — на стороне отправителя.

Что дальше