Если в компании налажен контроль доступа к внутренним ИТ-ресурсам, хорошо не только спецам по ИБ, но и многим другим. Например, лидам, которые отвечают за доступы к базам данных в своих командах. И новым сотрудникам, избавленным от необходимости вручную собирать логины-пароли, а затем где-то их самостоятельно хранить.
В Сравни больше 300 технических спецов, и в силу тематики наших продуктов зачастую они работают с чувствительными данными. Нам требовалось решение, которое поможет не просто централизованно управлять политиками доступов, но и проводить полноценный аудит всех действий в системе (предыдущий процесс логирования явно нуждался в модернизации).
Под обе эти задачи заточены так называемые PAM-инструменты (Privileged Access Management). Под катом рассказываем, как мы обеспечили контроль доступов и аудит инфраструктуры с помощью одного из них. В том числе об особенностях его внедрения, возможностях и некоторых ограничениях, выявленных на практике.
Привет, Хабр! Меня зовут Евгений, я Head of Systems Engineering в Сравни. Выбирая PAM-решение, мы составили список основных задач, в которых он был бы полезен нашей команде ИБ. Вот что нам требовалось в плане функциональности:
1. Ограничить прямой доступ к базам данных — сотрудники не должны подключаться напрямую, только через авторизованный шлюз.
2. Логировать каждое действие — включая команды SQL, открытие сессий и даже временные файлы.
3. Централизовать доступы — управление должно быть удобным, с разграничением прав по ролям и группам.
4. Интегрироваться с текущей инфраструктурой (LDAP) — без лишних костылей и с учётом существующих процессов.
5. Автоматизировать создание сущностей на PAM в соответствии с текущей инфраструктурой — PAM должен отражать актуальное состояние текущей инфраструктуры и автоматически поддерживать актуальное состояние.
Из других пожеланий к инструменту: хотелось, чтобы его можно было быстро и удобно развернуть, а в дальнейшем поддерживать без особых трудозатрат — в общем, искали классический вариант «дёшево и сердито».
После общения с вендорами и изучения функциональности решений, остановились на конкретном варианте: JumpServer. Это PAM-система, ориентированная на контроль и мониторинг привилегированных доступов к ресурсам (SSH, RDP, базы данных, web-интерфейсы). Есть как бесплатная (open-source), так и enterprise-версия.
Помимо очевидных возможностей (гибкое централизованное управление доступами, запись сессий), подкупили дополнительные фичи. Например, возможность интегрировать решение с внутренними инструментами компании посредством API, поддержка работы с облачными БД (в нашем случае это Яндекс Облако), интеграция с AD из коробки и наличие SSO.
Забегая вперед: решение полностью покрыло наши потребности в плане контроля доступов и аудита инфраструктуры; спустя полгода использования JumpServer об этом можно говорить смело. Мы обеспечили изоляцию подключения к базам, централизованное управление доступами, полную запись действий и автоматизацию через API.
Но чтобы всё заработало как надо, самого инструмента было недостаточно — требовалось логичным образом интегрировать его в нашу имеющуюся ИБ-систему. Об этом и поговорим ниже.
Реализация: от изоляции к полному контролю
Для начала обозначу, как инструмент в целом вписан в нашу архитектуру:
JumpServer PAM установлен в изолированной подсети.
Подключение к базам данных осуществляется только через JumpServer.
Интеграция с RDS-сервером — реализована поддержка подключения через опубликованные приложения (например, DBeaver через веб-интерфейс JumpServer).
Интеграция с Active Directory — реализована аутентификация, авторизация и построение RBAC-модели на базе групп и пользователей нашей AD.
Интеграция с Terraform — автоматическое создание ассетов (серверов, баз данных) в PAM при развёртывании ресурсов в облаке
Репозиторий в GitLab с workflow для управления составом AD групп — эта опция позволяет лидам (они отвечают за БД своих команд) оперировать доступами к ресурсам PAM, минуя при этом прямой доступ к AD.
HMAC-аутентификация — для автоматических сервисов и скриптов.
А теперь пройдемся подробнее по специфике каждого пункта.
JumpServer PAM в изолированной подсети
Инструмент был развёрнут в отдельной подсети внутри on-prem инфраструктуры с ограниченным доступом из внешнего мира. Это позволило нам контролировать трафик к JumpServer с помощью ACL и Security Group, плюс создать уровень изоляции между пользовательским трафиком, инфраструктурой и базами данных.
Подход обеспечил «бастионную» модель, где все подключения к ресурсам проходят через один проверяемый и логируемый шлюз.
Интеграция с RDS (Remote Desktop Services) и опубликованными приложениями
Для предоставления пользователям доступа к графическим инструментам (например, DBeaver\MongoDB Compas и т.д.) без установки на локальный компьютер, мы использовали RDS:
В разделе RemoteApp на JumpServer загрузили приложение из App Market (DBeaver, MongoDB Compass, Redis Desktop Manager и т.д.).
-
Эти приложения — преднастроенные шаблоны .app (по сути, конфиги), которые:
определяют команду запуска (например: C:\Program Files\DBeaver\dbeaver.exe);
включают иконку, описание и категорию (Database, Web и т.д.);
могут быть установлены автоматически на RDS-хост.
JumpServer сам устанавливает эти приложения, через PAM-компонент Tink.
Как это работает:
Tink, подключаясь по WinRM, проверяет, установлено ли приложение на RDS-хосте.
Если нет — автоматически его загружает и устанавливает, при наличии соответствующего дистрибутива.
Приложения устанавливаются на сервере с настроенным Remote Desktop Services (RDS) под Windows.
RDS добавлен в JumpServer как remote app machine и используется в режиме «Published Application».
Через JumpServer пользователю становится доступно опубликованное приложение (например, DBeaver) — оно запускается удалённо на RDS-сервере, но отображается в веб-интерфейсе пользователя.
Всё подключение происходит через RDP, проксируемое и логируемое PAM.
К подобному решению я пришел, когда при работе с JumpServer столкнулся с ограничениями для пользователей MongoDB (об этом расскажу в далее в статье) — подход позволил не обделять их функциональностью.
В целом решение позволяет:
запускать GUI-инструменты из браузера без установки на рабочую станцию;
строго контролировать, какие приложения доступны пользователю;
вести запись и аудит действий, включая запуск приложений и взаимодействие с интерфейсом;
при необходимости — ограничивать файловый доступ и буфер обмена.
Подключение к базам данных только через JumpServer
Модель доступа к ресурсам выглядит следующим образом:
1. Пользователь проходит аутентификацию на PAM-сервере.
2. Во время аутентификации JumpServer получает список групп пользователя из AD.
3. На основе полученных групп, пользователю назначаются права доступа к ассетам и разрешенные действия.
В рамках политики безопасности было запрещено прямое подключение к базам и использование учетных данных непосредственно от БД.
JumpServer стал единой точкой входа. Пользователь сначала аутентифицируется в PAM, после чего может подключиться к назначенной базе.
Режимы подключения:
Web-интерфейс (CLI, GUI, Applet — позволяет в веб-интерфейсе JumpServer открыть опубликованное на RDS приложение).
DBguide — генерация временных кредов для подключения базе через JumpServer, с их помощью можно подключиться к базам из стандартных профильных приложений для работы с БД, при этом PAM будет проксировать это подключение.
JumpServer client — локальный клиент, который может запустить профильное ПО для работы с базой, например SSMS, DBeaver и прокинуть в них коннекшен-стринги для автоматического подключения к БД.
Таким образом вся активность фиксируется, и реальные учётные данные баз остаются скрыты от конечных пользователей.
Интеграция с Active Directory (LDAP)
Аутентификация и авторизация пользователей реализована через LDAP-интеграцию с существующим Active Directory. Это дало следующие преимущества:
единый вход;
автоматическая синхронизация пользователей и групп;
построение RBAC на базе AD-групп;
прозрачное управление доступами на уровне PAM через привязку групп к ресурсам.
Доступ к инфраструктурным ресурсам регулируется через механизм Asset Authorization Rules и Command Filter внутри JumpServer.
Основные компоненты, которые позволяют управлять доступом к ресурсам:
PAM-аутентификация. Пользователь проходит аутентификацию через JumpServer, как правило, с использованием LDAP или другого внешнего провайдера.
-
Asset Authorization Rules. Это центральный механизм контроля доступа. В нём задаются:
группы пользователей из AD (AD user group);
целевые ресурсы (Target Asset);
разрешённые аккаунты на ресурсах (Target account);
разрешённые протоколы подключения (например, SSH, RDP);
разрешённые действия (доступ, передача файлов, буфер обмена и т.д.).
-
Command Filter (Фильтр команд). Для повышения уровня безопасности доступ может ограничиваться только разрешёнными командами. Используются:
регулярные выражения для определения допустимых команд;
назначение групп команд (Command group) пользователям и активам.
-
Asset (Ресурсы). Конечные целевые системы (БД, серверы и т.д.), к которым осуществляется подключение. Связь происходит по:
строке подключения (Connection string);
указанным аккаунтам (DB accounts).
При этом поддерживаются действия (Permissions): Connect, Transfer, Upload, Download, Delete, Clipboard, Copy, Paste, Share.
Вот пример работы схемы:
Пользователь проходит аутентификацию.
На основании его группы в AD проверяется наличие правил доступа (authorization rules).
Если доступ разрешён, проверяется соответствие командам (если активен фильтр команд).
Предоставляется доступ к целевому ресурсу с ограничениями по действиям и командам.
Таким образом добавление пользователя в группу в AD автоматически даёт ему нужный уровень доступа в JumpServer.
Интеграция с Terraform
Для автоматического добавления ресурсов в PAM мы реализовали интеграцию на основе анализа Terraform state-файлов, без прямой связи с Terraform-провайдерами.
Как это работает:
Terraform state-файлы хранятся в Object Storage (например, S3-совместимом);
-
PowerShell-скрипт:
подключается к бакету с помощью ключей доступа;
читает .tfstate;
извлекает из него данные об инфраструктуре (имя ресурса, IP-адрес, теги, тип — VM или база).
-
После парсинга данных:
создаются или обновляются ассеты в JumpServer через API (с HMAC-подписью);
происходит автоматическое распределение по группам, согласно тегам или шаблонам.
Вследствие такого подхода у нас нет зависимости от Terraform-провайдеров или Git-хуков, а скрипт можно запускать по расписанию (cron/CI/CD). При этом обнаруживаются как новые ресурсы, так и изменения существующих.
Плюс, работая со стейтами Terraform, я могу сам контролировать ситуацию с добавлением ресурсов — без необходимости привлекать DevOps-команду. Сканирую текущую инфру, делаю скан PAM-сервера, вычисляю дельту, смотрю, чего не хватает и добавляю на PAM-сервер в автоматическом режиме недостающие элементы: учётные записи, ассеты и т.д.
HMAC-аутентификация для автоматизации
Вместо базовой авторизации мы внедрили безопасную HMAC-подпись для запросов к API JumpServer.
HMAC-подпись формируется из AccessKey, SecretKey и Timestamp, после чего передаётся в заголовках запроса. Это исключает риски, связанные с хранением паролей в скриптах, MitM-атаками, и позволяет точно определить, какой сервис выполнил какой вызов.
Рабочий пример:
function Generate-Signature {
param (
[string]$Key, # Секретный ключ (SecretID) для HMAC
[string]$Data # Строка, которую нужно подписать (stringToSign)
)
# Преобразуем ключ и данные в байты
$KeyBytes = [System.Text.Encoding]::UTF8.GetBytes($Key)
$DataBytes = [System.Text.Encoding]::UTF8.GetBytes($Data)
# Создаем объект HMAC-SHA256 и задаем ключ
$HMAC = New-Object System.Security.Cryptography.HMACSHA256
$HMAC.Key = $KeyBytes
# Вычисляем хэш и возвращаем его в формате Base64
return [Convert]::ToBase64String($HMAC.ComputeHash($DataBytes))
}
# Функция Get-AuthHeaders
# Назначение: формирует заголовки для HMAC-аутентифицированного запроса к JumpServer API.
function Get-AuthHeaders {
param (
[string]$KeyID, # Идентификатор ключа (используется в поле keyId)
[string]$SecretID, # Секретный ключ для подписи
[string]$Path, # Путь запроса, например: "/api/assets/"
[string]$Method # HTTP-метод запроса (GET, POST и т.д.)
)
# Получаем текущее время в формате RFC1123 (обязательный заголовок 'date')
$Date = (Get-Date -Format "R")
# Формируем строку request-target для подписи
$RequestTarget = "(request-target): $Method $Path"
# Формируем полную строку, которую нужно подписать
$StringToSign = "$RequestTarget`naccept: application/json`ndate: $Date"
# Генерируем подпись с помощью функции Generate-Signature
$Signature = Generate-Signature -Key $SecretID -Data $StringToSign
# Возвращаем словарь (hashtable) с заголовками для запроса
return @{
"Accept" = "application/json"
"Content-Type" = "application/json"
"X-JMS-ORG" = "00000000-0000-0000-0000-000000000002" # ID организации в JumpServer
"Authorization" = "Signature keyId=`"$KeyID`",algorithm=`"hmac-sha256`",headers=`"(request-target) accept date`",signature=`"$Signature`""
"Date" = $Date
}
}
Пример использования:
# Функция Get-Assets-By-Name
# Назначение: выполняет запрос к JumpServer API для поиска ассетов (ресурсов) по имени.
# Возвращает массив ассетов, имя которых соответствует строке поиска.
# Параметры:
# - $JmsUrl — базовый URL JumpServer (например, https://pam.example.local)
# - $KeyID — идентификатор HMAC-ключа
# - $SecretID — секретный ключ HMAC
# - $SearchName — строка для поиска ассетов (имя, полное или частичное)
function Get-Assets-By-Name {
param (
[string]$JmsUrl,
[string]$KeyID,
[string]$SecretID,
[string]$SearchName
)
# Формируем путь запроса с параметром поиска
$Path = "/api/v1/assets/assets/?search=$SearchName"
# Генерируем заголовки с HMAC-подписью
$Headers = Get-AuthHeaders -KeyID $KeyID -SecretID $SecretID -Path $Path -Method "get"
try {
# Выполняем GET-запрос к JumpServer API
$response = Invoke-RestMethod -Uri "$JmsUrl$Path" -Method Get -Headers $Headers -UseBasicParsing
# Если ассеты не найдены — возвращаем пустой массив
if ($response.Count -eq 0) {
# Write-Warning "Ассет не найден на ПАМ | '$SearchName'"
return @()
}
# Фильтруем результаты по имени ассета (точное или частичное совпадение)
return $response | Where-Object { $_.Name -like "$SearchName" }
}
catch {
# Обработка ошибок при выполнении запроса
Write-Error "Ошибка при запросе списка ассетов: $_"
return @()
}
}
$assets = Get-Assets-By-Name -JmsUrl $JmsUrl -KeyID $KeyID -SecretID $SecretID -SearchName $SearchName
Репозиторий в GitLab с workflow
Этот механизм пока не внедрён в наш прод, но уже протестирован.
В теории доступами в PAM можно управлять вручную через GUI JumpServer, используя разделение на воркспейсы и организационные сущности («организации»). Но этот подход не был для нас оптимальным.
Во-первых, смущала невозможность прямой синхронизации OU из AD в раздельные воркспейсы PAM. То есть пользователей, импортированных из AD, пришлось бы вручную перемещать по организациям, либо дополнительно автоматизировать этот процесс через API.
Во-вторых, нам требуется централизованное и автоматизированное управление доступом через AD, в контексте интеграции PAM с внутренними сервисами.
В результате выбрали такое решение: GitLab → AD → PAM.
Общая схема:
Конфигурации AD-групп хранятся в GitLab-репозитории в виде JSON-файлов. Управление доступом реализовано через механизм Merge Request и CI/CD Pipeline. Процесс выглядит следующим образом:
Создание изменений. Тимлид создает Merge Request (MR), в котором редактирует JSON-файл: добавляет или помечает на удаление пользователей (например, с флагом ##).
Проверка и утверждение. Ответственный инженер по безопасности (или указанный в CODEOWNERS) проверяет и утверждает MR.
-
CI/CD-пайплайн после слияния. После слияния MR запускается GitLab CI/CD Pipeline, который выполняет:
Валидацию JSON. Проверка синтаксиса и структуры JSON-файлов.
-
Запуск скрипта управления AD и PAM. Скрипт (на PowerShell или Python) выполняет:
проверку, что имена групп и ассетов соответствуют разрешённым шаблонам (исключение управления чужими группами);
проверку наличия групп и их состава в AD;
создание новых групп в AD, если они отсутствуют;
обновление состава существующих групп в AD — добавление и удаление пользователей;
проверку, что группы синхронизированы в PAM;
создание или обновление правил доступа к ассетам в PAM через API с использованием AD-групп.
-
Обновление репозитория (при необходимости). Скрипт вносит изменения в JSON-файл в репозитории только в следующих случаях:
если пользователь был помечен на удаление с флагом ## — он удаляется из АД группы, а сам файл актуализируется;
если были автоисправления (например, напрямую из АД удалили пользователя);
при добавлении пользователей через MR скрипт не изменяет файл — только применяет изменения в AD.
Безопасность исполнения. Все действия выполняются self-hosted GitLab Runner’ом, работающим во внутренней сети с доступом к AD и PAM.
Логика синхронизации Git ↔ AD ↔ PAM выглядит так:
Добавление пользователей:
Если пользователь присутствует в AD-группе, но отсутствует в JSON-файле — он автоматически добавляется с постфиксом # (автодобавление).
Если пользователь прописан вручную в JSON, но не найден в AD-группе — он автоматически добавляется в группу AD.
Удаление пользователей:
-
Если пользователь помечен как ##:
он удаляется из AD-группы;
удаляется из JSON-файла;
коммит с изменениями формируется автоматически и пушится в GitLab при выполнении скрипта.
-
Если пользователь удалён напрямую из AD, но в JSON-файле имел #:
он считается автодобавленным и удаляется из файла.
-
Если пользователь удалён из AD, но в JSON указан без #:
скрипт восстанавливает его членство в AD-группе.
И немного о том, как в рамках процесса мы работаем с безопасностью:
Все изменения фиксируются в истории GitLab (MR, commit-log).
Журнал изменений в AD может быть синхронизирован с SIEM.
-
Доступ к репозиторию ограничен:
только тимлиды и секьюрити-инженеры имеют права на запись;
используется CODEOWNERS для обязательного ревью.
-
Секреты (например, LDAP_USER, LDAP_PASS) хранятся в GitLab CI/CD Variables:
помечены как Protected и Masked;
доступны только в нужных окружениях (prod, staging).
Рекомендуется использовать подписанные коммиты, Protected branches, Environments для разграничения prod/dev логики.
Заметки из опыта внедрения
Проблем, с которыми мы столкнулись в ходе внедрения, по факту было больше, чем я указываю в этом разделе. Но поскольку многие из них довольно специфичны, подсвечу наиболее значимые загвоздки. (К слову, с некоторыми вопросами нам быстро помогла разобраться русскоязычная поддержка продукта: в том числе с их помощью можно отправлять запросы разработчикам.)
-
Проблемы с RDS и русифицированной ОС
После успешной интеграции Remote Desktop Services (RDS) с JumpServer возникла проблема: новые пользователи перестали автоматически пробрасываться с PAM-сервера на RDS. Причина оказалась в русифицированной ОС, где системные группы имели локализованные (русские) названия. JumpServer не мог корректно их интерпретировать.
Рекомендация: использовать ОС без локализации. По последним данным, проблема была решена в более поздних релизах JumpServer.
-
Отображение JSON в Web-интерфейсе PostgreSQL
При выполнении SQL-запросов с JSON-ответами данные отображаются некорректно в веб-интерфейсе JumpServer.
Временное решение:SELECT response_body::text FROM ...
Рекомендация: поскольку приведение JSON к тексту позволяет обойти проблему отображения, при работе с JSON-ответами PostgreSQL имеет смысл использовать текстовую интерпретацию — до появления нативной поддержки.
-
Ограничения при работе с кластерными managed-базами
При работе с MongoDB в JumpServer отсутствовала поддержка проксирования — разработчик уже это исправил, но мы с нюансом успели столкнуться.
Также в многоадресной строке подключения MongoDB не поддерживается формат mongodb://host1,host2,host3/... Подключение к каждому хосту кластера выполняется отдельно — каждый в своём ассете.
Есть нюансы и при использовании Redis Sentinel. Так, JumpServer не поддерживает Sentinel-режим при подключении через ассеты. Подключение к Redis происходит напрямую, минуя механизмы отказоустойчивости Sentinel.
Рекомендация: в проектах с MongoDB и Redis предусматривать временные архитектурные обходные пути (например, отдельные ассеты или использование клиентов вне PAM до появления поддержки).
***
В итоге мы не просто получили в распоряжение подходящий инструмент для контроля привилегированных доступов. Но и на практике убедились: JumpServer можно гибко адаптировать под реальные процессы — от интеграции с AD и Terraform до публикации GUI-приложений через RDS. Отдельно радует, что продукт развивается: появляются новые фичи и фиксятся баги, а разработчики оперативно реагируют на обратную связь по проблемам, возникающим в ходе эксплуатации.
Будем рады узнать о вашем опыте использования подобных инструментов — и ответить на вопросы по нашей реализации. Пишите в комменты!