Привет, Хабр! Меня зовут Сергей Померанцев, я работаю в компании Avanpost и являюсь владельцем продукта Avanpost SmartPAM.
Я заметил, что на Хабре не так много действительно интересной информации о системах класса PAM (Privileged Access Management). Попробую это исправить и постараюсь периодически, скажем, пару раз в квартал, публиковать что-нибудь любопытное.
Итак, о Privileged Access Management. В целом, этот класс ПО оформился как обособленный, самостоятельный, в начале 2010-х гг, то есть – давно. Как это ни странно для столь зрелого направления, разные продукты абсолютно по-разному реализуют ключевую функцию: встраивание в привилегированную сессию и контроль происходящего там. Как следствие, одна и та же строчка о поддерживаемом протоколе в спецификациях (скажем, что поддерживается HTTP или RDP) у разных производителей означает совершенно разный пользовательский опыт.
Так что эту – свою первую здесь – статью я как раз и посвящу тому, чтобы разобраться в том, как архитектура PAM может влиять на эксплуатацию и ключевые свойства продукта.
Очевидно, что для решения задач управления привилегированным доступом PAM должен как-то встроиться в «механику» происходящего в сессиях. При этом привилегированные сессии разных типов имеют колоссальные различия в технологиях, при помощи которых организуются подключения (например, сеанс в конфигураторе 1С с точки зрения технологий – совсем не то же самое, что подключение к веб-консоли администрирования Unisphere дисковых массивов Dell/EMC Unity).
Посмотрим, как разные PAM могут встраиваться в инфраструктуру взаимодействия клиентов и серверов во всем их многообразии.
Вот основные способы, которыми PAM встраивается в инфраструктуру взаимодействия клиентов и серверов:
– Специализированные прокси;
– Встроенный в PAM браузер для работы с веб-консолями;
– Терминальный сервер;
– Устанавливаемый в ОС программный агент PAM;
– Сервер TACACS для работы с сетевым оборудованием.
Специализированные прокси
Возьмусь утверждать, что в настоящее время у лидеров рынка именно прокси являются основным инструментом контроля привилегированных сессий.
Наиболее распространённые типы прокси, применяемых в PAM – для RDP и для SSH, такие в том или ином виде есть у большинства серьезных производителей. Алгоритм работы ясен из названия: терминал��ный клиент (скажем, PuTTY) подключается к прокси. Последний устанавливает сессию к нужному SSH-ресурсу (например, ОС Линукс), выполняя аутентификацию от привилегированной УЗ, но не раскрывая ее секрет пользователю. Все команды, получаемые от PuTTY, прокси передает на Linux, все ответы ОС – возвращает в терминал. У PAM под контролем оказываются все действия пользователя, а запись можно и нужно выполнять в компактном и легко анализируемом текстовом виде. Отметим также, что бывают разновидности/режимы работы прокси, встраиваемые inline подобно IPS.
Наряду с SSH- и RDP- встречаются прокси для SQL и HTTP. Любопытная особенность некоторых SQL-прокси, перекликающаяся с возможностями решений класса DAM – способность маскировать чувствительные данные при выводе.
HTTP-прокси (точнее, реверсивные HTTP-прокси) – это мое любимое. Почему? Тут целый «огород» проблем! Во-первых, есть букет сложностей, специфичных для реверсивных прокси вообще:
– необходимость поддерживать множество способов аутентификации в веб-приложения (иначе найдется что-нибудь, что не будет поддерживаться);
– требование выполнять URL-Rewriting (подмена путей в ссылках, заголовках и др.), вытекающее из необходимости обеспечить работу приложений в условиях, когда внешние и внутренние URL-пространства не совпадают. Например, ссылки вида https://keycloak:8080/admin может потребоваться преобразовывать к виду https://portal.company.com/pam/kc/admin
Все? Не-а: тут у нас статья не про реверсивные прокси, а про PAM. Нам ведь мало пропустить трафик через себя, спутно выполнив аутентификацию от привилегированной УЗ. Нужна еще запись.
В современном мире веб-интерфейсы «рендерятся» в браузере, при помощи JavaScript. Многие их мутации происходят там же, не вовлекая сервер. То есть, обыденной является ситуация, когда состояние приложения объективно меняется, но локально, в браузере, а HTTP-прокси об этом ничегошеньки не узнает. Можно сделать вывод, что видимые в прокси вызовы GET, POST и что-там-еще ходит между браузером и «админкой» имеют лишь ограниченную практическую ценность для анализа происходящего в веб-сессиях (хотя на рынке есть решения, которые практикуют именно такой подход к анализу).
Как же, все-таки, организовать запись? Одно из возможных ноу-хау – инъектировать JavaScript, который «заставит» сам браузер отправлять на backend PAM скриншоты. Тогда в распоряжении офицера ИБ, работающего с PAM, появится полноценная картина действий пользователей.
В целом, прокси – прекрасное решение, при правильной реализации – с минимумом «побочек» с точки зрения эксплуатирующей организации. Примеры неправильного, с моей точки зрения, подхода – такие, которые требуют специализированных клиентов на АРМ привилегированного пользователя. Например, бывает так, что особый, доработанный производителем PAM терминальный клиент применять можно, а обычный PuTTY – нет; иногда на рабочую станцию пользователя нужно ставить некий агент/диспетчер; случается, что терминальный клиент применять нельзя вовсе, а всю работу пользователи должны выполнять только в браузере, подключаясь в личный кабинет пользователя PAM, куда транслируется видео с терминалом. Любопытно, что встречаются также уловки, когда вендор называет словом «прокси» или ему подобным компонент, который таковым по своей природе не является (например, тот же терминальный сервер).
Встроенный в PAM браузер
В ряде решений работа с веб-сессиями выстроена без применения прокси. «Внутри» PAM запускают т.н. «headless» браузер. Он не взаимодействует напрямую ни с каким графическим терминалом, а вместо этого транслирует свой вывод в личный кабинет пользователя PAM (как пиксельную графику). Выглядит это, конечно, «тяжеловато» по ресурсам: на каждую сессию потребен свой браузер, да еще нужно передавать на клиент, по сути, видеопоток. Опять же, из видео, которое будет транслироваться в личном кабинете, не скопироват�� текст; из-за того, что реальный рендеринг страницы выполняется в удаленном (в смысле – далеко расположенном) браузере, возникают несимпатичные нюансы с печатью, устройствами и при работе с файлами.
Терминальный сервер
В состав PAM включается терминальный сервер, например, на базе Microsoft RDP/Microsoft RemoteApp. На нем можно опубликовать клиенты приложений, привилегированный доступ к которым мы хотим контролировать (SSH- и RDP-клиенты, браузер, толстый клиент 1С и т.д.) Устанавливаемые сюда же компоненты PAM обеспечат аутентификацию в клиентах (так избегая разглашения пользователю секретов от привилегированной УЗ), выполнят видеозапись и др. Преимущества у метода веские – универсальность и относительная простота реализации. Но налицо и серьезные минусы:
– организация терминального сервера потребует много аппаратных ресурсов, необходимо лицензирование этого компонента (в моем примере – Microsoft RDS);
– запись сессий, вероятно, будет графической природы (серии скриншотов либо видео) – а это потребует и еще больше ресурсов для хранения данных;
– кроме того, PAM трудно будет разобраться в сути происходящего в сессии (видеть-то он будет пиксельную графику!), а значит, мы не сможем реагировать на угрозы проактивно;
– возникают более или менее преодолимые проблемы при работе с доступностью окружения (импорт/экспорт файлов, печать и т.п.);
– возможен «побег» пользователя из предоставленной ему песочницы-приложения в ОС терминального сервера.
Универсальность, однако, подкупает - подход практикуют многие производители PAM. Но у лидеров рынка, обычно, терминальный сервер выступает в качестве лишь «одного из», причем – не основного - механизма управления сессиями. Иначе говоря, если оказалось так, что другими инструментами организовать контроль привилегированной сессии не удается (что бывает, например, с толстыми клиентами) – производитель PAM рекомендует применить терминальный сервер.
Программный агент PAM
Для контроля работы в ОС может применяться следующая идея: вклинивать PAM не между пользователем и ресурсом, а непосредственно в ресурс. В Линукс (Windows) устанавливается программный агент, который организует запись, автоматически повышает привилегии (например, заменяя собой sudo), возможно, контролирует действия пользователя на уровне системных вызовов. Этот некогда популярный способ организации контроля с течением времени становится все менее привлекательным (не путаем с агентскими компонентами PAM, нацеленными исключительно на мониторинг происходящего в сессиях!), так как несет в себе яркие минусы:
– Вероятны проблемы совместимости (как с редакцией ОС и конкретными ее настройками, так и с системным и прикладным ПО, работу которого обеспечивает сервер);
– Само по себе распространение агентов – малосимпатичная задача с точки зрения эксплуатации.
Сервер TACACS
Данный способ применяют для организации контроля привилегированного доступа к сетевому оборудованию. Устройства Cisco, как один из примеров, реализуют возможность делегировать AAA (Authentication/Authorization/Accounting) третьей стороне по протоколу TACACS. Система класса PAM, выступая в роли сервера TACACS, получает запросы на аутентификацию, авторизацию и информацию о запускаемых пользователем командах. В теории, таким образом можно очень точно контролировать действия пользователя. Однако для того, чтобы уравнение «сошлось», не хватает полноценной записи сессии: что (какие команды) пользователь запускал – мы знаем, что ему отвечала IOS – TACACS не передает.
Резюме
Для удобства, сведем в табличку краткую информацию о рассмотренных механизмах:
Механизм | Защищаемые ресурсы | Особенности |
Специализированные прокси | ОС и сетевое оборудование; Базы данных; Веб-интерфейсы. | Наиболее зрелый способ контроля привилегированных сессий; Некоторые решения могут требовать применения специализированных клиентов/агентов на АРМ пользователя; Ряд решений не обеспечивают полноценную запись HTTP-сессий. |
Встроенный в PAM браузер для работы с веб-консолями | Веб-интерфейсы | Ресурсоемкое решение; Создает неудобства в работе пользователя при работе с буфером обмена, файлами печатью и др. |
Терминальный сервер | У лидеров рынка – толстые клиенты | Ресурсоемкое решение; Как правило, требует дополнительно лицензировать у третьей стороны сам терминальный сервер; Проблемы с безопасностью; Трудности с доступностью для пользователя окружения (печать, файлы и др.) |
Программный агент PAM | ОС | Потенциальные сложности с совместимостью агентов и с их установкой на защищаемые ресурсы |
Сервер TACACS для работы с сетевым оборудованием | Сетевое оборудование, поддерживающее одноименный протокол | Не позволяет в полной мере организовать запись привилегированных сессий |
Подведем окончательные итоги:
– мы констатировали, что актуальное программное и аппаратное обеспечение очень разнится между собой по способам организации привилегированных сессий;
– мы выяснили, что для контроля этих сессий в PAM применяется масса способов (публикация приложений, разнообразные прокси, агентские решения, TACACS и др.);
– мы также поняли, что архитектура PAM может оказывать определяющее влияние на пользовательский опыт.
