Цикл статей: PAM на практике: как защитить привилегированные доступы и взять их под контроль

Проект развивается международным сообществом и поддерживается коммерческой командой, предлагающей Enterprise-редакцию и техническую поддержку.

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

Отдельно стоит упомянуть основные преимущества Enterprise-версии продукта:

• Нативные клиенты и Enterprise-базы данных. Инженеры могут использовать клиенты со своих рабочих станций (нативный RDP-клиент, DBeaver для БД). К тому же открывается доступ к коммерческим СУБД: Oracle, MS SQL Server, ClickHouse, DB2.
• Бесшовная интеграция в корпоративную среду (SSO). Enterprise -версия поддерживает протоколы SAML, OpenID, OAuth и сторонний RADIUS. Пользователи логинятся через привычные корпоративные порталы, а администраторы могут создавать гибкие роли.
• Just-in-Time политики. Нужен временный доступ подрядчику? Встроенная система заявок (доступа по запросу) решает эту проблему. Кроме того, имеют место гранулярные ограничения: пускать пользователя только в рабочие часы, по определенным дням недели или со строго заданных IP-адресов.
• Мультитенантность. Позволяет разделить один кластер PAM на несколько полностью изолированных независимых организаций.
• Официальная поддержка. Техническая поддержка вендора на русском языке уже включена в стоимость лицензии.

Помимо этого, Enterprise-версия умеет проксировать HTTP-трафик внутри контейнеров без развертывания и лицензирования MS RDS (используя модуль Panda) и жестко ограничивать методы подключений к ресурсам.

Ознакомиться с полной таблицей сравнения версий можно на официальном сайте.

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

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

Поделить их можно следующим образом:
1. Слой идентификации

• LDAP / AD
• SSO
• MFA

2. Слой управления доступом

• RBAC
• JIT
• Политики

3. Слой проксирования

• SSH
• RDP
• DB

4. Слой аудита

• Запись сессий
• Журнал команд

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

Их можно разбить на условные роли:

Интерфейс и управление:

Протокольные коннекторы:

Расширенные модули (Enterprise):

Все это объединяется в единую модель для предоставления подключения через PAM-систему:

Благодаря широкому спектру поддерживаемых протоколов (SSH, RDP, VNC, Telnet, SQL, HTTP/HTTPS, Kubernetes), JumpServer позволяет покрыть практически любые сценарии доступа в современной инфраструктуре.

Сценарий 1: Защита доступа подрядчиков (RDP/VNC/Web).
Внешним интеграторам выдается доступ только в рабочие часы через веб-браузер к конкретным Windows-серверам или веб-панелям без установки VPN-клиентов. Все их действия записываются на видео.

Сценарий 2: Доступ разработчиков к базам данных (DB Proxy).
Разработчикам нужен доступ к PostgreSQL или Oracle для дебага. Через компонент Magnus они могут использовать свои привычные инструменты (DBeaver, DataGrip), но реальные пароли от БД им не выдаются — JumpServer подставляет их «под капотом» и логирует каждый SQL-запрос.

Сценарий 3: Замена классических Bastion Hosts (SSH/Telnet).
Вместо самописных Linux-шлюзов с ключами администраторы получают централизованную точку входа на тысячи серверов с ролевой моделью и интеграцией с AD.

Такая модульность позволяет развернуть систему как в формате All-in-One (все компоненты на одной виртуальной машине) для небольших компаний, так и в виде распределенного кластера балансировки нагрузки для крупных Enterprise-инсталляций. Далее давайте разберем модели развертывания.

Существует несколько вариантов развертывания PAM-системы JumpServer:
1. All-In-One
Самый простой метод, позволяющий протестировать решение или развернуть его для небольших сред. При выборе данной модели сессии будут храниться локально на сервере.

2. Внешние хранилища

В режиме «всё-в-одном» JumpServer PAM хранит записи сессий и прочую мета-информацию локально на сервере, где был установлен. Чтобы не ограничивать объем хранимых записей сессий локальным сервером, можно подключить внешнее хранилище.

Поддерживаются:

• сетевое расположение, доступное по протоколу nfs;
• любое сетевое хранилище, поддерживающее протоколы S3 и Ceph;
• хранилища Swift, OSS, Azure, OBS и COS.

3. Кластеризация

Для обеспечения отказоустойчивости и надежности хранения данных JumpServer поддерживает кластеризацию СУБД. Решение поддерживает MySQL/MariaDB и PostgreSQL. Временные данные хранятся в Redis. И СУБД, и Redis можно установить в режиме кластера, указав в настройках JumpServer PAM соответствующие IP-адреса (или общее имя хоста).

Также JumpServer можно развернуть в режиме кластера с горизонтальным масштабированием. В этом случае для балансировки будет использоваться HAProxy.

4. Гео-репликация и катастрофоустойчивая установка

Для особо крупных организаций доступна установка JumpServer PAM в режиме кластеризации с гео-репликацией.

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

Желательно заранее определиться с редакцией (Community или Enterprise), чтобы сразу использовать соответствующую инструкцию по развертыванию. При необходимости переход на Enterprise-версию возможен — он выполняется путём установки соответствующего дистрибутива поверх существующей инсталляции.

Теперь, уже после всей теоретической информации мы можем приступить к практике. Предлагаем развернуть JumpServer Community Edition используя модель All-In-One.
Напомним, что в такой модели все компоненты системы, в том числе мета информация, будут храниться на одном узле.

Начнем с системных требований. У Community и Enterprise версий они почти одинаковы, кроме одного пункта — в Enterprise-версии рекомендуется производить установку на ОС семейства Redhat, Debian, Ubuntu.

В остальном они идентичны:

• ОС: Linux/AMD64 (arm64) x86₆₄(aarch64) ядро версии 4.0 или выше
• CPU: 4 ядра
• RAM: 8 ГБ
• HDD: 60 ГБ

Первым делом развернем ОС, в нашем случае это будет Ubuntu server 22.04, которой выделим минимальные рекомендованные ресурсы. Также для корректной работы потребуется установить дополнительные компоненты с помощью соответствующих команд.

Команды выполняем из-под учетной записи root :
# apt-get update
# apt-get install -y wget curl tar gettext iptables

Далее перед нами встает выбор по какому пути установки идти.

Есть два варианта:

• Быстрая онлайн установка предполагает установку с параметрами по умолчанию, СУБД MySQL и Redis будут установлены в контейнеры на том же сервере.
• Стандартная онлайн установка. В таком случае у нас будет возможность изменить конфигурацию установки перед развертыванием.

Для наглядности пойдем по пути стандартной установки. Сначала нам следует перейти в директорию /opt/ и скачать в нее установщик последней версии после чего его распаковать.

На момент написания статьи актуальная версия решения — 4.10.16, а значит для нас будет актуален следующий набор команд:
# cd /opt/

# tar -xf jumpserver-installer-v4.10.16.tar.gz

После выполнений данных команд мы будем иметь в /opt директорию jumpserver-installer-v4.10.16 с которой далее будем работать.

В ней присутствует файл config-example.txt, который нужен для понимания какие настройки можно изменить для развертывания (например, внешний Redis). По данной ссылке можно почитать подробнее про каждую переменную в конфигурационном файле.

В рабочей директории есть основной служебный скрипт jmsctl. sh предназначенный для обслуживания системы JumpServer и управления ее жизненным циклом. Для полного списка команд вы можете ввести ./jmsctl.sh --help 

Основные сценарии и функции скрипта:

• Применение конфигурации — после внесения любых изменений в конфиг-файл необходимо выполнить команду jmsctl restart чтобы применить параметры.
• Управление обновлениями — скрипт используется для обновления системы до новых версий.
• Мониторинг — Администраторы системы могут отслеживать здоровье системы и статусы ее компонентов.
• Обслуживание компонентов — он позволяет удобно управлять развертыванием, запуском и остановкой всей связки Docker-контейнеров, из которых состоит JumpServer.

В нашем случае мы используем этот скрипт для начала установки, введя следующую команду:
./jmsctl.sh install

В процессе выполнения скрипта можно будет изменить данные установки чтобы, например, изменить язык/временную зону или порты, по которым будет доступен JS. В рамках нашей установки мы укажем только язык ru, остальные параметры — дефолтные.

Важно! В процессе установки сгенерируются два ключа — SECRET_KEY и BOOTSTRAP_TOKEN, которые система автоматически добавит в конфиг-файл. Они оба очень важны для функционирования системы и запрещены к распространению. Они обязательно понадобятся в случае миграции системы.

• SECRET_KEY: используется для шифрования паролей активов (нельзя менять после миграции).
• BOOTSTRAP_TOKEN: необходим для регистрации коннекторов (KoKo, Lion, Magnus) в системе.

После завершения установки запускаем Jumpserver командой ./jmsctl.sh start и переходим по адресу веб-интерфейса <ipадрес>:80.

Тут нам следует авторизоваться со стандартными данными admin/ChangeMe, пароль система сразу попросит поменять.

После смены пароля нас встретит страница, на которой нам следует заполнить данные администратора и оставить согласие. На этом развертывание завершено, далее приступим к настройке системы.

• Обратите внимание на довольно частую проблему при развертывании — конфликт портов. Если на сервере уже запущен веб-сервер, порты 80 и 443 будут заняты, и контейнеры lina /core не поднимутся. В таком случае стоит перед установкой освободить порты или изменить их в файле конфигурации, расположенному по пути /opt/jumpserver/config/config.txt

• После установки для удобства стоит сразу поменять часовой пояс системы и решения, иначе время не будет совпадать с реальным, так как по умолчанию устанавливается временная зона Шанхая.

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

2. Отредактируйте файл конфигурации. В раздел «# The current running version number of JumpServer» нужно добавить следующие строчки (пример для Москвы):

• TZ=Europe/Moscow
• TIME_ZONE=Europe/Moscow
• Если в файле только один параметр TZ, и нет параметра TIME_ZONE, то его следует добавить, чтобы было именно так, как указано выше.

3. После проделанной работы перезапустите JumpServer c помощью команды jmsctl restart

На этом этапе система уже развернута и готова к работе.

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

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

До встречи на портале TS University!