Все чаще крупные компании задумываются о контроле и отслеживанию доступа к критичным для бизнеса серверам. Кто зашел, что сделал и когда? Встроенное логирование не всегда удобно и «читабельно», и вот на российский рынок постепенно стали выходить продукты по «контролю привилегированных пользователей». Мне показалось интересным сравнить два «основных» продукта этой линейки, а именно Balabit Shell Control Box и Wallix Admin Bastion.

Примечание: Для сокращения объема статьи сравнение будет только в разрезе протокола rdp и функционала в целом, в результате чего имеет относительно общий характер. Протокол ssh также поддерживается данными продуктами, однако в этой статье он НЕ рассматривается, чтобы не мешать все «в одну кучу».


Кому нужны системы по контролю админов?


Системный администратор в наше компьютеризированное время стал едва ли не «царем и богом» it-пространства Компании. Как следствие этого, руководство предпочитает с ними особо не конфликтовать и по возможности идти на уступки, ведь уходя «по-плохому», бывший админ может нанести бизнесу порядочный ущерб. Поэтому сама фраза «контроль админов», возможно, покажется многим топ-5-сотрудникам избавлением от щекотливой проблемы и отличным ее решением, но…все ли так просто? Конечно, нет. Поэтому, в первую очередь, хотелось бы кратко обозначить компании, в которых действительно подобные продукты могут принести какой-то положительный выхлоп. Список рожден на базе собственного опыта и не претендует на истину в последней инстанции, т.е. носит изначально субъективный характер.

Итак, «контроль админов» пригодится:

  • Компаниям, численность системных администраторов в которых превышает ~7-10 человек;
  • Компаниям, it-поддержку в которой осуществляет сторонняя организация (аутсорс);
  • Компаниям со специфичным ПО, которым требуется пускать на целевые сервера специалистов вендора\дистрибьютора;
  • Компаниям, которых мучают регуляторы и требуют от них соответствия различным стандартам (не сталкивалась, но не исключаю).

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

Обе нижеописанные системы представляют собой аппаратный или виртуальный appliance, базирующийся на несколько видоизмененных unix системах: Wallix разворачивается на базе Debian, Balabit – ZorpOS. Требуемые аппаратные мощности зависят от числа активных пользователей и количества защищаемых серверов.

Как это работает — Wallix Admin Bastion


Wallix умеет работать только в режиме «бастион» на прикладном уровне модели OSI, т.е. ставится в разрыв сети в явном, видимом для администратора виде. На сервере Wallix настраиваются правила (о них чуть ниже), на основании которых тот пропускает\блокирует подключения администраторов. Администратор подключается на сервер wallix по протоколу rdp (порт стандартный) и логинится на нем при помощи созданной локальной учетки (или импортированной из AD). После этого ему предоставляется доступный список пар сервер + конечная учетка, и он выбирает нужный сервер. Wallix может сам подставить пароль конечной учетки, но можно и запросить этот пароль у администратора. Для наглядности логическая схема подключения показана ниже:

Логическая схема подключения админов к защищаемым серверам через Wallix

Настройки Wallix представляют собой бинарные (истина-ложь\можно-нельзя) сопоставления между двумя типами групп: группы учетных записей на самом Wallix (можно заменить на учетные записи, импортированные из AD) и группы пар Сервер + конечная учетная запись.


Форма добавления\редактирования защищаемого сервера и конечной учетки

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

Wallix хранит записи rdp в виде видео-роликов (в файловом виде), которые можно прогнать через встроенный распознаватель текста (ocr), после чего искать по заголовкам (поиск по заголовкам в рамках не только одного видео обещали прикрутить в ближайших версиях).


Список сохраненных видео записей rdp-сессий

Как можно «заставить» админа ходить к нужным серверам через wallix?

  • Закрытием маршрутов на уровне сети в купе с оргмерами «или так, или никак, иначе последуют суровые меры…»;
  • Разрешить вход на защищаемые сервера только под специально созданными доменными учетками, пароль на которые Wallix будет менять раз в час\день\неделю\месяц (пароли высылаются в зашифрованном виде на указанный ящик. Нужен GPG-сертификат и ЗК к нему).

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

Минусы продукта
  • Нет стабильно работающего «прозрачного» режима. Тот, что заявлен, работает с бубном и через пень-колоду или не работает вовсе;
  • Присутствуют неучтенные продакшн-нюансы (версия 4.2), которые приходится закрывать костылями и на бегу.

Как это работает — Balabit Shell Control Box


Balabit также ставится в «разрыв», но умеет работать в нескольких режимах на разных моделях OSI. При этом настройка «прозрачного»\ «непрозрачного» режима производится непосредственно в самом подключении, что весьма удобно с точки зрения «тонкой» настройки того или иного подключения.

«Прозрачный режим»


Главное преимущество Balabit, что он умеет работать в «прозрачном» режиме, располагаясь в сети в скрытом для администраторов виде. IP-spoofing позволяет сделать его «невидимым» даже для FW и маршрутизаторов, подставляя в качестве ip-src ip-адрес ПК-админа, таким образом нет необходимости настраивать для него отдельные разрешения на сетевом оборудовании.

Для работы balabit в прозрачном режиме на маршрутизаторе прописываются соответствующие маршруты (что весь трафик из подсетки N направляем на IP-адрес Balabit). При этом трафик, который balabit не сможет распознать (выявить в нем контролируемые протоколы), будет пропускаться без изменений дальше (на указанный шлюз).

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

Настройки balabit имеют разрез по защищаемым серверам – для каждого сервера задаются свои мгносоставные настройки и права доступа (для прозрачного режима: из какой сети можно подключаться к защищаемому серверу). Вариант настроек представлен ниже:


Настройки для доступа на защищаемый сервер через balabit

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

Режим «Бастион»


Режим бастион имеет несколько реализаций:
  1. Режим TS Gateway. В этом режиме в rdp-клиенте прописывается DNS-имя сервера balabit в качестве сервера шлюза удаленных рабочих столов. Этот режим использует сертификаты, шифруя трафик как до TS GW (сертификат сервера balabit), так и от balabita до защищаемого сервера (либо сгенерированный «на лету» сертификат, либо загруженный на balabit). При таком подключении возможно подставить заведенный заранее на сервере balabit пароль конечной учетной записи, таким образом администратор может не знать учетных данных для подключения на защищаемый сервер. Однако сам balabit автоматически не умеет менять пароли и как-либо ими «управлять». Интегрируется с отдельной SSO-системой Thycotic Secret Server.

    Примечание: Такая схема весьма капризна в своей работоспособности, т.к. требует довольно приличное количество тонких настроек и понимания, что и почему настраивается. Порой могут возникнуть несколько непредсказуемые «затыки» (например, при прописанной в свойствах обозревателя проксе, rdp-клиент отказывался резолвить DNS-имя сервера balabit).

  2. Режим «Авторизация на GW». В этом режиме администратору нужно иметь два монитора потребуется начать подключаться к защищаемому серверу, после инициализации подключения авторизоваться в web-интерфейсе balabit и «разрешить» свое подключение. Этот вариант подключения также требует маршрутизации сетевого трафика и соответствующих настроек на роутере (-ах).
  3. Режим «4 глаза». Принцип работы тот же, что в п. 2, но тут уже «разрешить» должен другой человек.


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

Система также хранит все сессии в виде видео-роликов. OCR производится единоразово. Поиск по распознанному тексту во всех видео-роликах уже присутствует. Для просмотра сессии необходимо клиентское ПО (Audit Player), которое поставляется вместе с дистрибутивом и устанавливается на ПК «оператора» с MS-операционкой на борту.


Список сохраненных видео записей rdp-сессий

Плюсы продукта
  • Умеет стабильно и профессионально работать в прозрачном-MiTM режиме;
  • Имеет множество тонких настроек практически на любой вкус;

Минусы продукта
  • Интегрируется только с одним AD (требуется ввод в AD);
  • Режим «бастион» требует порой танцев с бубном и длительного курения манулов;
  • Не умеет управлять паролями;
  • Двойная авторизация имеет довольно запутанный характер и нрав;

Подводя итог


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

Также хотелось бы отдельно отметить, что по типу Wallix на рынке присутствует система CyberArk, имеющая схожий, но более расширенный функционал в режиме «бастион». За основу ее работы взят механизм MS Remote Application, что позволило увеличить количество поддерживаемых протоколов и возможностей подключения. К сожалению, автор не обладает достаточной компетенцией, чтобы добавлять ее в сравнение, однако и промолчать о ней считает преступным.