Релиз версии 2.3

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

В результате в Балансировщике 5А появились гибридная модель доступа ABAC + RBAC, интеграция с ICAP/DLP, аутентификация пользовательского трафика и Pre-Authentication через OIDC, зеркалирование расшифрованного L7-трафика, новые health checks и дополнительные инструменты диагностики.

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

Управление доступом: объединили ABAC и RBAC в один подход

Чем больше инфраструктура и команда, которая с ней работает, тем сложнее становится модель «администратор может всё».

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

В версии 2.3 в Балансировщике 5А появилась полноценная ролевая модель управления доступом, но с нашей уже привычной детализацией и гранулярностью.

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

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

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

ICAP/DLP: проверяем трафик там, где он проходит

Еще одно большое направление релиза — интеграция балансировщика с внешними системами информационной безопасности.

Балансировщик находится непосредственно на пути трафика к приложениям, поэтому логично использовать эту точку не только для распределения запросов, но и для их передачи на анализ.

В версии 2.3 появилась интеграция с внешними ICAP/DLP-системами для HTTP, HTTPS, gRPC и TCP-трафика.

Предусмотрено два режима работы.

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

Синхронная проверка работает иначе: для HTTP/HTTPS/gRPC балансировщик ожидает результат анализа до передачи данных приложению. Если DLP-система возвращает запрет, данные до бэкенда не доходят.

Для HTTP-трафика поддерживаются REQMOD и RESPMOD. Можно задавать, какой именно трафик отправлять на проверку: например, ограничить ее определенными HTTP-методами, Content-Type или путями вроде /upload, исключив служебные /health и /metrics. Это помогает не отправлять в DLP весь поток подряд и не создавать лишнюю нагрузку на систему анализа.

Отдельно настраивается поведение при недоступности DLP. В зависимости от требований конкретного сервиса можно использовать fail-open, продолжая пропускать трафик, либо fail-close, запрещая его прохождение, если проверка невозможна.

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

Расшифровали один раз — анализируем там, где нужно

С HTTPS есть еще одна практическая проблема. Чтобы система безопасности могла анализировать содержимое зашифрованного трафика, его необходимо сначала расшифровать.

Если TLS уже терминируется на балансировщике, выполнять ту же операцию еще раз на следующем элементе инфраструктуры не всегда имеет смысл.

В новой версии появилась возможность зеркалировать L7-трафик после расшифровки на балансировщике и передавать его во внешние системы анализа.

Для HTTPS копия содержит запрос уже в открытом виде — метод, URI, заголовки и тело. При этом зеркалирование асинхронное: внешний приемник не находится в критическом пути запроса, его ответ не влияет на обработку клиентского трафика.

Это позволяет использовать балансировщик как точку, где TLS-трафик расшифровывается один раз, а дальше его содержимое становится доступно DLP и другим средствам анализа без дополнительного TLS-терминирования на их стороне.

Аутентификация теперь может происходить до приложения

Еще один большой блок релиза связан уже не с доступом администраторов к самому Балансировщику 5А, а с доступом пользователей к приложениям, которые через него публикуются.

Раньше для аутентификации на уровне балансировщика можно было использовать клиентские сертификаты. В версии 2.3 к этому добавились Basic Authentication и проверка JWT.

Балансировщик может получить учетные данные клиента, проверить их и только после успешной аутентификации передать запрос приложению. Для JWT поддерживается получение токена из Bearer-заголовка, cookie или параметра запроса, а также проверка подписи и, при необходимости, issuer и audience.

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

Это особенно полезно там, где публикуется несколько сервисов с одинаковыми требованиями к аутентификации: вместо реализации одной и той же логики на каждом бэкенде можно применять единый профиль на уровне балансировщика. Один профиль аутентификации может использоваться несколькими сервисами.

OIDC Pre-Authentication: единая точка входа перед приложением

Для компаний, которые уже используют централизованную систему управления идентификацией, в версии 2.3 появилась предварительная аутентификация через OpenID Connect.

Сценарий выглядит так: пользователь обращается к опубликованному сервису, Балансировщик 5А проверяет наличие действующей сессии и, если ее нет, перенаправляет пользователя на Identity Provider. После успешного входа балансировщик получает и проверяет ID-токен, создает сессию и только после этого передает запрос приложению.

Пароль пользователя при этом не хранится в 5А и не передается приложению. На бэкенд при необходимости можно передать сведения о пользователе и его группах.

Такой механизм позволяет поставить единый слой аутентификации перед приложениями и использовать уже существующего корпоративного Identity Provider вместо реализации собственной схемы входа в каждом сервисе.

Для машинных интеграций остается JWT: программный клиент самостоятельно получает токен и передает его балансировщику. OIDC Pre-Authentication рассчитан прежде всего на браузерный сценарий с перенаправлением пользователя на страницу входа.

Health Check стал ближе к реальному состоянию сервиса

Порт открыт — еще не значит, что приложение работает правильно.

Поэтому в версии 2.3 мы расширили набор проверок состояния сервисов двумя новыми мониторами.

XML Health Check позволяет оценивать состояние сервиса по содержимому XML-ответа. Это дает более точную проверку, чем сам факт установки соединения или получение успешного HTTP-кода: балансировщик может учитывать именно корректность ответа приложения.

SIP Health Check предназначен для инфраструктуры, использующей Session Initiation Protocol. Теперь состояние SIP-сервисов можно учитывать при принятии решения о направлении трафика — например, в инфраструктуре IP-телефонии и других коммуникационных системах.

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

MTR и curl: меньше переключений между системами во время диагностики

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

Это маршрут? Потери на промежуточном узле? Проблема с HTTP endpoint? Сервис отвечает с конкретного агента или только кажется доступным из другой части сети?

В версии 2.3 мы добавили в модуль диагностики Балансировщика 5А еще два привычных инженерам инструмента — MTR и curl.

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

А с помощью curl можно выполнить HTTP/HTTPS-запрос непосредственно с выбранного агента 5А: указать метод, заголовки и тело запроса, а в ответ получить HTTP-код, заголовки и содержимое.

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

 

Версия 2.3 получилась большой, но большинство изменений объединяет одна идея: дать инфраструктурной команде больше контроля в той точке, через которую уже проходит трафик приложений.

Новая гибридная модель доступа помогает точнее управлять тем, кто и что может менять в системе. ICAP/DLP и зеркалирование расшифрованного трафика упрощают интеграцию с контуром информационной безопасности. Basic, JWT и OIDC позволяют проверять пользователя еще до того, как его запрос попадет в приложение. Новые health checks дают больше информации о реальном состоянии сервисов, а MTR и curl помогают быстрее искать причины проблем.

Полное описание возможностей версии 2.3 и инструкции по настройке уже доступны в документации Балансировщика 5А.