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

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

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

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

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

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

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

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

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

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

• Keylogger.

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

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

Что же мы реально вправе ожидать от «админа»? Камуфляж. Вероятно – весьма изощренный:

• обфусцирование команд с помощью ASCII и иных   кодировок;

• хитрые конвейеры команд;

• распределение действий во времени;

• формирование скриптовых файлов, выполняющих нужные ему (и вредные нам) действия.

Вот для наглядности пара примеров:

Первое (обфускация) эквивалентно ls, второе (обфускация плюс конвейер) – выведет на экран hello, третье (еще одна обфускация, уже в MS PowerShell) скрывает Get-Process.

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

А что PAM? Черный список команд с таким, очевидно, не справится: закамуфлированные действия пользователя просто не будут «мэтчиться» со списком запретов. С другой стороны, запрещать всем поголовно printf,   sh и многое другое, что может быть использовано для камуфляжа – заведомо слишком строго. Запись сессий и Keylogger? Там «админские» трюки, скорее всего, будут видны. Но увидим мы их потом, скорее даже - сильно потом, когда все полимеры будут… ну, вы поняли. И произойдет это только при условии, что конкретный субъект как-то еще, иным способом, «наследил», привлек внимание, создав этим повод внимательно изучать записи. Получается, что в данном случае PAM в своем базовом варианте – скорее про форензику, чем про предотвращение угроз.

Что все-таки можно противопоставить со стороны PAM-системы? Я бы выделил три группы инструментов:

• «Продвинутое» детектирование действий пользователя;

• Выявление опасных действий при помощи сигнатурного анализа;

• Определение аномалий в действиях пользователей.

Детектирование действий пользователя

Тут я имею в виду целый пласт функций, технологий и архитектурных решений, направленных на то, чтобы ответить на вопрос: «Что происходит в привилегированной сессии?»

Самое простое и естественное – «вытаскивать» команды из пользовательского ввода «как есть» – мы уже обсудили как недостаточно эффективное.

Следующий шаг   эволюции – эвристика, которая обрабатывает данные, полученные из пользовательского ввода (коды символов можно восстановить до исходного текста, разобрать конвейеры команд на отдельные элементы и т.п.) Для графических интерфейсов, вероятно, дополнительно понадобится OCR, который позволит определить, что в реальности вводит пользователь.

Многое из происходящего в привилегированных сессиях мы уже сможем таким образом разбирать. Однако эвристику все еще можно обмануть: какие-то способы камуфляжа она может просто не знать (классический пример соревнования щита и меча); какие-то способы ей в принципе не будут доступны (вспоминаем пример со скриптовым файлом, формируемым пользователем в несколько проходов).

Если добавить в PAM специализированные агентские модули, работающие на защищаемых узлах,   открывается возможность «мониторить» происходящее там на уровне системных вызовов. Пусть пользователь и скрыл от PAM свое действие, запуск нежелательного процесса, открытие какого-то потенциально опасного сетевого подключения и т.п. будут видны такому агенту; в большинстве случаев   даже можно увязать их с конкретной привилегированной сессией.

Сигнатурный анализ

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

Перед началом автоматизированного анализа данные целесообразно нормализовать. Например, их можно представить в виде потока событий, приведенных к некоторой единой модели: кто, где, какое действие и над каким объектом выполнил. Например, цепочка команд:

может быть промоделирована как совокупность событий:

Кажется, что PAM’у можно было бы «триггериться» уже на первое действие. На ряде серверов – и на четвертое. Модель нам это позволяет: мы различаем и действие, и его объект, и место, и многое другое. Следовательно, можно накладывать весьма гибкие условия на срабатывания триггеров. Далее уже Офицер ИБ проанализирует оригинальную запись сессий, конечно, разберется, что там произошло, и предпримет меры.

В реальной жизни подход чреват большим количеством ложно-положительных срабатываний: потенциально чувствительных мест в инфраструктуре много, нельзя при касании каждого из них «хвататься за пистолет». Загоняем мы так «Офицера ИБ».

Посмотрим еще раз на табличку, чтобы отметить следующее:

• Очевидно сомнительное событие – только первое. Возможно, что и четвертое – в зависимости от характера эксплуатации узла. Но для него мы не увидим в реальном URL признаков угрозы, проблемой будет только сам факт передачи чего-то наружу. А все остальные события – вообще выглядят как какая-то заурядная возня с файлами.

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

Поможет ли усложнение модели? Скажем, можно было бы первые два события представить как копирование /etc/shadow. Тогда в четвертом событии уже будет видно, что наружу передается содержимое /etc/shadow. Однако даже в этом простом примере «админ» может передавать не прямую копию /etc/shadow, а нечто иное, вот хотя бы так:

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

Как выйти из ситуации? Корреляция событий. Система должна позволять описывать правила, выявляющие некоторые закономерности в цепочках команд. В нашем примере можно сформировать правило:   если пользователь за относительно короткое время прочитал чувствительный файл и установил соединение к какому-то внешнему IP – бить тревогу.

Откуда, кстати, возьмутся эти правила? Для реально эксплуатируемой системы их потребуется много, в придачу – рубрикатор объектов на значительное количество позиций. Организация-внедренец правила корреляции, скорее всего, не сделает. Я долгое время занимался внедрением ПО и могу утверждать, что интеграторы, как правило, избегают такого рода задач как сопряженных с плохо контролируемыми рисками и неподходящих для проектной деятельности. У специалистов эксплуатирующей организации, с другой стороны, может не быть для этого ни компетенции, ни времени. В идеале PAM должен поставляться с готовым набором правил, разработанных вендором.

Выявление аномалий

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

Возьмем наш пример из секции о сигнатурном анализе. Допустим, у нас уже есть правило корреляции, которое реагирует на доступ к чувствительным файлам и последующим открытием сетевых портов на внешние IP. Есть и справочник этих чувствительных файлов:   /etc/shadow, /etc/passwd, /etc/sudoers, /etc/ssh/ssh_host_rsa_key и др. А вот, скажем, /etc/krb5.keytab в справочник добавить забыли: Kerberos ведь настраивают не на всех Linux. Тогда манипуляции над этим файлом PAM пропустит.

Чтобы такого не произошло, сигнатурный анализ целесообразно дополнить детекторами аномалий. Скажем, на основе статистического анализа или AI (в последнем случае имею в виду не LLM, а специализированную нейросеть, доступную on-premise).

Как это может работать? Представим, что у нас есть профиль пользователя. Мы знаем, на какие ресурсы и в какое время он «ходит», какие действия выполняет, над какими объектами он их выполняет, и где, каким IP-пользуется. Если пользователь делает нечто нетипичное для себя – можно подсветить это действие как риск. В нашем примере вспоминаем, что «злобный админ» – прежде всего «админ», и уже только потом – «злобный». Т. е., основная масса его действий укладывается в логику работы администратора. Вспоминаем теперь, что   /etc/krb5.keytab – бинарный файл, люди к нему на чтение не обращаются. Т.е., с точки зрения профилирования событие чтения такого файла будет аномальным. Если админ делал это ночью (когда никого поблизости нет) – время события станет еще одним признаком аномалии. По совокупности «ненормальностей» («кунштюк» со специфическим использованием curl, вероятно, тоже можно к таковым отнести) система вынесет вердикт: наблюдается подозрительная активность.

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

• Событийная обработка с возможностью корреляции;

• Выявление аномалий.

Напоследок поставлю перед вами, дорогие читатели, проблему: а следует ли доверять PAM автоматические реакции на выявленные угрозы? Здесь имею в виду не предупреждения, но реакции деятельные, как-то: разрыв сессии,   блокирование доступов и т. д. С одной стороны, повышаем скорость реакции на угрозы. С другой стороны, ложно-положительные срабатывания при таком режиме работы могут явиться большой головной болью.

Жду ваши соображения в комментариях!