Эволюция PAM-систем в России

Развитие функциональности систем класса PAM (Privileged Access Management) в России позволяет дать обзор необходимых функций контроля удалённого доступа, применяемых на практике. Какие функции контроля доступа актуальны сейчас? Как решаются задачи превентивного контроля и на что обратить внимание при выборе системы контроля привилегированных пользователей?

 

 

 

 

1. Введение
2. Обзор функциональных возможностей систем «ранее»
   
   1. 2.1. Пользователи и источники знаний о них
   2. 2.2. Что собирают и хранят
   3. 2.3. Подозрительные паттерны
   4. 2.4. Типы систем
   5. 2.5. Предоставляй, но согласуй
   6. 2.6. Три варианта входа
   7. 2.7. Придумав пароль, регулярно меняй его
   8. 2.8. Разделяй и властвуй
   9. 2.9. Следи за собой
   10. 2.10. Отказоустойчивость?
3. Обзор функциональных возможностей систем «сейчас»
   
   1. 3.1. «Всё катится к лучшему»
   2. 3.2. SIEM и «сырые события»
   3. 3.3. UEBA
   4. 3.4. Масштабируемость и катастрофоустойчивость
   5. 3.5. Доверенная среда
   6. 3.6. Принятие решений
   7. 3.7. Поддержка и собственная компетенция
4. Выводы

Введение

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

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

Как показывают только публичные кейсы утечек и взломов за последний год (а сколько таких историй удаётся скрыть, остаётся только гадать), одним из самых популярных сценариев начала крупных атак были именно «привилегированный пользователь» и его «привилегированный доступ» — те самые сущности, для работы с которыми и создавались системы класса PAM (Privileged Access Management) и PUM (Privileged User Management).

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

Обзор функциональных возможностей систем «ранее»

Базовая идея подобных систем сводится к максимально полному контролю происходящего в рамках сессий на целевых устройствах (в информационных системах, на сетевом или другом оборудовании), к которому получает доступ сотрудник, отвечающий за его исправную работу или же имеющий неограниченный доступ. В основном речь идёт о контроле доступов получаемых средствами протоколов RDP и SSH, но также контроль может быть наложен и на HTTP(S), и на приложения-клиенты и связанные с ними протоколы.

Пользователи и источники знаний о них

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

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

Что собирают и хранят

Поскольку система контроля сосредоточена на «понимании» происходящего в пользовательских сессиях, базово она должна обеспечивать наличие следующей функциональности:

1. Сбор текстовых данных — клавиатурного ввода, содержимого буфера обмена, запуска или остановки процессов, в некоторых случаях — текстового содержания элементов интерфейса, и т. п.
2. Запись видеокартинки, подобно регистратору, чтобы в случае неоднозначной трактовки текстовых событий была возможность «увидеть всё глазами пользователя».

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

Подозрительные паттерны

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

1. Уведомление офицера безопасности о наличии подозрительного паттерна.
2. Блокировка или разрыв сессии, содержащей подозрительный паттерн.

Системы строят как чёрные списки, так и белые, в зависимости от концепции: разрешать или запрещать.

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

Типы систем

По принципу работы и встраиванию в контур можно разделить системы контроля на три типа:

1. Режим «маршрутизатор» (L2 или L3).
2. Агентский режим.
3. Режим «бастион» или «прокси».

Каждый из вариантов имеет свои особенности и специфику, и в каждом конкретном случае владелец инфраструктуры принимает собственное решение о применении того или иного варианта.

Так как данная статья не претендует на полный обзор всех типов решений, за скобками оставим первые два варианта — в том числе по причине того, что на взгляд автора они имеют значительные недостатки и сложности в эксплуатации. Первый вариант характеризуется потребностью в перенаправлении и передаче значительной части трафика через PAM, что далеко не всегда оправданно, а второй — необходимостью решать отдельную задачу по развёртыванию и обслуживанию агентов на всех подконтрольных системах (в настоящее время подобных агентов и так достаточное количество, а увеличивать его не всегда есть силы, возможности, да и вычислительные ресурсы).

Итак, режим «бастион» или «прокси» характеризуется в первую очередь тем, что пользователь предварительно и в явном виде входит не в целевую систему, а на отдельный сервер с установленной PAM-системой. Далее он проходит этап аутентификации и в результате получает список целевых систем или приложений, разрешённых ему в рамках матрицы доступа (политик). Отчасти такой режим идентичен современной концепции Zero Trust, в основе которой лежит принцип «не доверяй никому»: без явного разрешения на предоставление доступа последний просто отсутствует.

Предоставляй, но согласуй

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

Три варианта входа

Каким же образом обеспечиваются доступ и непосредственное подключение к «цели»?

Обычно предоставляются несколько вариантов:

1. Сохранённая учётная запись от цели в самой PAM. Этот вариант решает как проблему передачи привилегированной УЗ внешнему сотруднику, так и просто задачу «меньше знаешь — лучше спишь». В этом варианте подключение к цели происходит без необходимости знания и ввода пары «логин — пароль» от целевого хоста, система подключает пользователя «прозрачно», самостоятельно передавая необходимую информацию для аутентификации.
2. Интерактивный вход. Этот вариант наиболее распространён в ситуациях, когда требуется разделить сферы влияния служб ИТ и ИБ и, к примеру, не передавать пары «логин — пароль» службе ИБ, но обеспечить наблюдение с её стороны за коллегами из ИТ-подразделений. В этом случае пользователь, подключающийся к цели, сам вводит логин и пароль от целевого хоста и осуществляет вход.
3. Переиспользование учётных записей. Это — не менее распространённый сценарий, и базируется он на полной интеграции каталога пользователей для аутентификации на цели. Таким образом, пользователь вводит логин и пароль единожды и для доступа к цели используется ранее введённая пара «логин — пароль». Это позволяет существенно сократить процесс по наполнению PAM-системы пользователями и задействовать единый каталог для них.

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

Придумав пароль, регулярно меняй его

Предлагаю более детально рассмотреть первый вариант входа с точки зрения сохранённых паролей. Тут кроется дополнительная функциональность PAM-систем, а именно — возможность автоматической ротации таких паролей на целевых системах, чтобы минимизировать число случаев их компрометации. Речь идёт о менеджере паролей, который уже давно является необходимой функциональностью PAM.

Помимо смены паролей учётных записей для подключения пользователей к сессиям удалённого доступа, такой механизм используется и в целях предоставления «секретов» для автоматизированных систем.

Здесь продукты в общем случае весьма похожи, различаются они только по списку поддерживаемых целевых систем для смены паролей и по возможности (или отсутствию её) расширения этого списка, а также по способу доступа к хранилищу «секретов» через специальные клиенты или API.

Разделяй и властвуй

Понятие привилегированного доступа значительно шире, чем просто доступ к консоли удалённой системы. С ростом уровней автоматизации, цифровизации и ухода в сторону «удобства интерфейсов» под это определение подпадают доступы к интерфейсам как сетевого оборудования, так и обработки / конфигурации различных систем, будь то веб-интерфейсы или собственные приложения-клиенты. В современных системах также активно используются протоколы и механизмы доступа систем автоматизации, взаимодействие между программными интерфейсами (API) различных систем.

Если говорить о доступе к веб-интерфейсам, то первым «подходом к снаряду» было использование проксирования протокола HTTP(S). Но, опять-таки, с развитием технологий и, в частности, HTML5 оно стало менее практичным и теперь несёт минимум полезной информации: зачастую между браузером пользователя и серверной частью передаются только наборы данных, такие как JSON-объекты, а обработка и представление происходят на стороне браузера клиента. Таким образом, восстановить в точности последовательность действий оператора становится максимально сложно.

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

Стоит отдельно отметить следующие особенности:

1. В данном случае сохраняется возможность «прозрачного» подключения с пробросом логина и пароля в целевой интерфейс. Как ранее, так и сейчас практически все решения используют идентичную технологию — язык сценариев, например AUTO-IT, для имитации действий пользователя, выбора нужных полей и ввода в них пары «логин — пароль». (Примечание из опыта автора по эксплуатации систем данного класса: если вендор напрямую об этом не говорит, то это не означает, что используется что-то иное).
2. В свете импортозамещения встал также вопрос об отказе от классических терминальных серверов на базе ОС Microsoft Windows. Над этой задачей работают не один год, и уже сейчас многие разработчики PAM и отечественных ОС не только воплотили подобные сценарии в своих лабораториях, но и реализовали ряд реальных кейсов у заказчиков. Ограничение тут, естественно, одно: требуется приложение-клиент под замещающую ОС на базе Linux.

Следи за собой

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

Тут на помощь приходит собственный аудит. Важно, чтобы были максимальное протоколирование доступа и изменений в рамках интерфейса (веб и API) и возможность получения журнала в удобном виде. Рекомендую обращать на это внимание при выборе, чтобы впоследствии не придумывать «костыли с изолентой» для собственного спокойного сна.

Отказоустойчивость?

Подавляющее большинство PAM-систем имеют такую функциональность, но зачастую она ограничивается только режимом «active — passive»: одна активная нода и одна пассивная. Активная принимает соединения и настройки, а пассивная — только конфигурацию с активной, чтобы в любой момент занять её место. Технологии реализации варьируются от репликации БД и использования механизмов синхронизации файловых систем до внутреннего резервного копирования по расписанию.

Обзор функциональных возможностей систем «сейчас»

«Всё катится к лучшему»

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

SIEM и «сырые события»

Первым шагом в этом направлении становится возможность передачи информации о событиях во внешние системы, к примеру SIEM. Тут стоит обратить внимание на то, что рынок средств защиты постепенно поворачивается лицом к клиентам. Многие разработчики PAM наладили работу и партнёрские отношения с производителями SIEM-систем, чтобы их решение уже поддерживалось «из коробки». Это сильно упрощает жизнь не только интеграторам, но и самим заказчикам, так как более не надо тратить ни время, ни деньги на создание «велосипеда» для получения корректно обработанных событий в едином центре.

Следующим этапом в клиентоориентированности стало создание систем с локальной экспертизой внутри самих PAM-продуктов. Одна из целей — снизить нагрузку на SIEM-системы, предоставляя им не весь спектр событий в рамках сессий, а уже обработанные данные «инцидентов». На крупных инсталляциях такой спектр может достигать значительных размеров, а его сокращение — это в том числе экономия как на лицензиях и мощностях SIEM, так и на разработке правил корреляции событий с использованием знаний и опыта производителя PAM-решения.

UEBA

Развивая тему экспертизы внутри PAM-системы, логично раскрыть то, что она в себя включает.

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

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

Что может дать такой подход конкретному сотруднику, отвечающему за предоставление доступа?

Во-первых, отсутствие необходимости разбирать вручную все сессии подряд или делать произвольную выборку сессий в надежде найти проблемы. Система подсветит те сессии, где будет обнаружена аномалия в действиях. Разумеется, о полноценном ИИ пока речи не идёт, но даже такие модели могут обучаться, в том числе на информации от сотрудника, который их обрабатывает как ложные и положительные срабатывания. Таким образом экономится время и повышается скорость реакции на потенциальный инцидент.

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

В-третьих, если система позволяет агрегировать информацию со всех точек доступа в инфраструктуру, то это — отличный централизованный механизм поиска, анализа и мониторинга, который найдёт своё место во внутреннем центре реагирования.

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

Масштабируемость и катастрофоустойчивость

Как было сказано ранее, инфраструктуры растут и усложняются, а требования к их работоспособности повышаются. Всё чаще стандартной задачей является реализация точек доступа в инфраструктуру не просто в режиме отказоустойчивости в рамках одного ЦОДа, а в виде сложных систем с отказоустойчивой схемой в одном ЦОДе и дублирующей его инфраструктурой в другом ЦОДе, географически находящемся в другом месте. Подобные сценарии уже работают на площадках заказчиков, и спрос на них в крупных компаниях явно будет.

Другим требованием является пограничный вопрос о масштабировании и отказоустойчивости. На текущий момент одним из наиболее реалистичных сценариев кажется появление систем, которые способны строить кластеры точек доступа по принципу «active — active», когда каждая из нод кластера является условно активной, синхронизация политик и конфигурации осуществляется внутренними средствами решения, а выбор активного узла перекладывается на внешний сервис балансировки в соответствии с конкретной задачей. Такой подход, с одной стороны, позволяет достичь отказоустойчивой конструкции изо двух и более активных нод, а с другой — реализовать сценарий масштабирования системы при ограниченных мощностях конкретного физического сервера, при этом без необходимости точного копирования его характеристик. Грубо говоря, он даёт возможность строить инфраструктуру из того, что есть, планомерно наращивая мощность единого комплекса.

У таких реализаций есть, разумеется, свои сложности в архитектуре и построении, но это уже зависит от конкретной решаемой задачи.

Доверенная среда

Если бы каждое решение находилось в вакууме и было изолировано от другого в рамках каждой решаемой задачи, всё было бы просто. Но реальность — иная: практически под каждый сценарий атаки или группы таковых есть свой набор специализированных средств анализа, детектирования и реакции, однако в то же время иногда возникает зазор в безопасности между средствами защиты. Одним из вариантов его устранения является обеспечение тесного взаимодействия между средствами защиты. PAM-решения — не исключение. Они предоставляют очень специфичный, хоть и ограниченный, набор данных, который в некоторых условиях получить возможно только с их помощью, — тем и живут.

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

Для простого выстраивания доверенного контура стоит обращать внимание на интеграционные возможности системы и на наличие открытого и функционального API. Это будет полезно не только для получения информации, но и для её внесения в систему, объединяя её с IdM, системами заявок и средствами автоматизации и оркестровки.

Принятие решений

Говоря о связи систем и цели, замечу, что сложно обойти задачи по автоматическому принятию решений на основе собранных данных. В силу специфики на отечественном рынке пока нет реальных кейсов за пределами самих PAM, но задачи такие ставятся, а это значит, что и соответствующие реализации появятся. Одним из очевидных решений в данном случае является построение схемы реагирования на критические инциденты через связку с другими решениями классов IRP / SOAR при помощи реализованных в них сценариев реагирования. В таком разрезе PAM становится важным источником информации в сложном ландшафте с нечёткими границами периметра.

Поддержка и собственная компетенция

В конце стоит вспомнить и о том, как не остаться с системой наедине.

Речь, конечно же, — о технической поддержке от разработчика и интегратора. Для большинства решений, в особенности импортных, модель, когда экспертизу и поддержку осуществляет не разработчик, а интегратор решения, допустима. Но не стоит забывать, что опыт и понимание продукта «под капотом» есть только у разработчика. С такой проблемой многие столкнулись в текущий момент, когда некоторые решения полностью покинули рынок и даже интеграторы оказались без «плеча поддержки» со стороны разработчиков. Это — понятный риск, и сейчас его уже все учитывают в первую очередь.

Есть и другая причина, чтобы иметь выход на разработчика и его техническую поддержку: оперативное реагирование на нестандартные ситуации, глубокое знание продукта и, как следствие, наличие чётких рекомендаций по построению сложных систем, адаптированных к инфраструктуре заказчика. Здесь — и встраивание в бизнес-процессы, и взаимодействие с другими производителями для корректной интеграции решений в единый контур, и, конечно же, передача части своей экспертизы сотрудникам на местах. Как бы ни хотелось отдать всё на аутсорс, не все задачи критической тематики позволяют это сделать.

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

Выводы

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

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

Безопасного удалённого доступа.