Привет, Хабр! Это Сергей Померанцев и в этот раз предлагаю обсудить, почему системы класса Privileged Access Management не всегда защищают от администратора, действующего злонамеренно.

Давайте договоримся, кто является нашим сегодняшним героем. Я буду считать, что «злонамеренный администратор» – это:

во-первых, пользователь – мы сами предоставили ему полномочия доступа в инфраструктуру (как наш собственный сотрудник, так и подрядчик);

во-вторых, привилегированный пользователь – полномочия доступа у него широкие;

в-третьих – субъект, действующий злонамеренно, с пониманием, что причиняет ущерб.

Ну, т. е., о хакерах из какого-нибудь далекого островного государства мы сегодня не говорим – как и о тех несчастных, кто, набрав rm –rf, перед нажатием «Enter» зацепил слэш вместо точки.

На всякий случай кратко отвечу на вопрос о том, зачем администратору такое творить. Мотивов может быть много: месть работодателю/руководителю, обоснование собственной значимости (сами формируем проблему – сами ее устраняем – получаем поощрение), в отдельных случаях – личная выгода (скажем, банально провести самому себе в «кадрах» сверхурочные) и др.

Посмотрим на арсенал средств контроля и реагирования, которыми оснащена типичная PAM-система:

1. Запись сессий.

2. Черный список команд для текстовых протоколов.

3. Keylogger.

А что и как будет делать наш «злонамеренный администратор», чтобы реализовать свои «злые намерения»? Исходя из того, что о присутствии PAM-системы он знает?

Запустит какие-то «плохие» команды как есть? Нет, это же откровенное «палево»! Пойдет в оснастку Active Directory и что-то настроит в ней? Снова нет: все это будет на видео! Решит свои вопросы в веб-интерфейсе какого-то приложения? И тут – мимо!

Всем привет! Сегодня хочу затронуть «стыдную» тему – то, о чем ни вендоры, ни интеграторы, ни даже сами заказчики на уровне менеджмента обычно не говорят.

Привилегированные пользователи ненавидят PAM.

Предлагаю разобраться, почему это так, и что тут можно улучшить.

Отвечая на вопрос, сформулированный в названии статьи, я бы выделил три основные проблемы, возникающие при использовании PAM:

● Отрицательное влияние PAM на UX;

● Восприятие PAM как инструмента слежки;

● Проблемы с надежностью.

Давайте разберем каждую из них подробнее.

Влияние на UX

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

● Необходимость для работы с защищаемыми ресурсами применять на АРМ какие-то агенты/клиенты от вендора PAM (либо вовсе – безальтернативное использование браузера в качестве административного клиента);

● Не поддерживаются, либо требуют от пользователя дополнительных телодвижений часть обычных для администратора операций, таких как передача файлов, работа с буфером обмена, sudo и т.п. (в наиболее одиозных ситуациях – буфер обмена работает только в одном направлении из-за того, что сессия транслируется как поток графики);

● «Лишние» и лишние шаги при доступе к ресурсу. Иногда пользователей может в принципе раздражать необходимость зайти в ЛК или предъявлять второй фактор – все-таки тут больше действий, чем при простом подключении, скажем, по SSH или RDP. Но бывает и так, что у вендора не пробрасываются «креды» и состояние аутентификации: зашел пользователь в личный кабинет, предъявил «креды», выбрал ресурс для доступа – и на каком-нибудь шлюзе/прокси/jump ему опять надо предъявлять те же «креды». В числе моих «любимых» – накладываемая на пользователя обязанность указать причину, по какой нужен доступ. Как правило, в реальной практике туда пишут нечто вроде: «Работа». Как эта информация используется потом – остается только гадать;

Привет, Хабр! Меня зовут Сергей Померанцев, я работаю в компании Avanpost и являюсь владельцем продукта Avanpost SmartPAM.

Я заметил, что на Хабре не так много действительно интересной информации о системах класса PAM (Privileged Access Management). Попробую это исправить и постараюсь периодически, скажем, пару раз в квартал, публиковать что-нибудь любопытное.

Итак, о Privileged Access Management. В целом, этот класс ПО оформился как обособленный, самостоятельный, в начале 2010-х гг, то есть – давно. Как это ни странно для столь зрелого направления, разные продукты абсолютно по-разному реализуют ключевую функцию: встраивание в привилегированную сессию и контроль происходящего там. Как следствие, одна и та же строчка о поддерживаемом протоколе в спецификациях (скажем, что поддерживается HTTP или RDP) у разных производителей означает совершенно разный пользовательский опыт.

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

Очевидно, что для решения задач управления привилегированным доступом PAM должен как-то встроиться в «механику» происходящего в сессиях. При этом привилегированные сессии разных типов имеют колоссальные различия в технологиях, при помощи которых организуются подключения (например, сеанс в конфигураторе 1С с точки зрения технологий – совсем не то же самое, что подключение к веб-консоли администрирования Unisphere дисковых массивов Dell/EMC Unity).