Обзор One Identity Safeguard, системы для защиты привилегированного доступа

1. Введение
2. Подход One Identity
3. Safeguard for Privileged Passwords
4. Safeguard for Privileged Sessions
5. Safeguard for Privileged Analytics
6. Архитектура Safeguard
7. Сценарии использования Safeguard
   1. 7.1. Доступ с ручным согласованием
   2. 7.2. Доступ с автоматическим согласованием на основе политик
   3. 7.3. Доступ без предварительного согласования
8. Схема лицензирования Safeguard
9. Интерфейс системы Safeguard
10. Выводы

Введение

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

В данной статье описан подход One Identity к теме управления привилегированным доступом, а также приведены основные возможности линейки продуктов Safeguard, охватывающих тему РАМ в продуктовом портфеле компании.

Подход One Identity

Решения класса Privileged Access Management (PAM) помогают снижать риски для информационной безопасности и соответствовать требованиям и стандартам. При этом важно не забывать, что безопасность должна помогать бизнесу и в идеале не создавать сложностей смежным подразделениям. Именно поэтому при создании продуктов класса РАМ One Identity отталкивался от следующих принципов:

1. Решение должно повышать уровень обеспечения информационной безопасности.
2. Решение должно помогать соответствовать требованиям и стандартам.
3. Решение должно быть производительным, обеспечивая возможность работы в крупнейших мировых компаниях.
4. Решение должно быть удобным для тех людей, кто им управляет.
5. Решение не должно создавать сложностей тем людям, доступом которых будут управлять.

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

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

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

В рамках данной статьи акцент сделан на трёх модулях, ключевые задачи которых упоминались в самом начале:

1. Safeguard for Privileged Passwords — управление паролями привилегированных УЗ;
2. Safeguard for Privileged Sessions — управление сессиями привилегированного доступа;
3. Safeguard for Privileged Analytics — анализ поведения привилегированных пользователей.

В отдельной статье мы осветим темы делегирования учётной записи суперпользователя («root») и использования аутентификации в Active Directory в UNIX / Linux.

Safeguard for Privileged Passwords

Привилегированные учётные записи необходимы для управления инфраструктурой. При этом используются общие УЗ — например, «root» в Unix и «Администратор» в среде Windows. Одной из проблем, связанных с применением подобных учётных записей, является то, что сложно (а порой — и невозможно) определить, кто произвёл действия с их помощью. Использование РАМ позволяет избавиться от данной проблемы.

Модуль Safeguard for Privileged Passwords даёт возможность организовать жизненный цикл по управлению паролями привилегированных учётных записей, обеспечивая запросы, согласование, предоставление, отзыв и анализ доступа.

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

Safeguard for Privileged Sessions

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

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

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

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

Модуль Safeguard for Privileged Sessions позволяет организовать контроль за действиями в рамках привилегированных сессий. Активность пользователей может быть записана и проанализирована. При необходимости можно предотвратить опасные действия и завершить работу сеансов. Удобство поиска по сессиям серьёзно упрощает задачу разбора инцидентов из области информационной безопасности, ведь чем быстрее будет произведено реагирование, тем меньший урон будет нанесён инфраструктуре и бизнесу компании.

Safeguard for Privileged Analytics

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

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

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

Архитектура Safeguard

Давайте рассмотрим архитектуру решения.

Как мы отметили ранее, данная статья будет сфокусирована на трёх модулях:

• Safeguard for Privileged Passwords (SPP) — управление паролями;
• Safeguard for Privileged Sessions (SPS) — управление сессиями;
• Safeguard for Privileged Analytics (SPA) — анализ поведения.

Схема взаимосвязи модулей представлена на рисунке 1. Для упрощения каждый из модулей представлен в виде одного блока. Естественно, продукт позволяет создавать отказоустойчивые конфигурации; об этом будет рассказано немного ниже.

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

Рисунок 1. Архитектура решения Safeguard

Примечание: СКПП — система контроля привилегированных пользователей.

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

Модуль управления паролями (SPP) поставляется как образ виртуальной машины для популярных сред виртуализации (Hyper-V, VMware). SPP представляет собой сейф для паролей, который может организовать жизненный цикл управления ими. На роль начального шага подходит процесс поиска привилегированных учётных записей. При необходимости найденные УЗ можно взять на управление с помощью модуля SPP: предоставлять по запросу, осуществлять ротацию паролей и, конечно же, вести журнальную информацию о том, кто получал доступ от имени каждой из них. При этом можно быть уверенным в том, что в любой момент времени никто не знает пароли от учётных записей на управляемых системах, пока доступ не заказан. Это существенно повышает уровень защищённости как от инсайдеров, так и от внешних злоумышленников.

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

Рисунок 2. Архитектура кластера SPP

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

Модуль управления сессиями (SPS) поставляется в виде ISO-образа Linux-машины. Этот модуль позволяет анализировать сетевой трафик протоколов взаимодействия с целевыми системами. На текущий момент поддерживается перехват следующих протоколов: HTTP, ICA, MSSQL, RDP, SECURE SHELL, TELNET, VNC. Устройство может работать на уровне L3, и в силу того что перехватывается сам протокол, нет необходимости изменять способ работы с целевыми системами, нет привязки к ОС, сотрудник будет продолжать использовать удобные для него инструменты в своей работе.

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

Рисунок 3. Визуализация поведения пользователя для анализа отклонений от стандартного поведения

Сценарии использования Safeguard

Доступ с ручным согласованием

Одним из часто встречающихся сценариев использования РАМ является запрос доступа с последующим согласованием, которое может осуществляться конкретным человеком или представителем группы возможных согласующих либо требовать цепочки согласования, состоящей из нескольких человек.

В этом сценарии портал модуля SPP будет являться точкой входа для пользователей систем. На нём располагается веб-интерфейс, где можно запросить доступ к целевой системе. Запросы могут быть дополнительно согласованы владельцами систем или отделом безопасности. Есть два возможных варианта: сессия (RDP, SSH) и пароль.

В случае запроса сессии доступ предоставляется без раскрытия пароля учётной записи, от имени которой он будет осуществляться. Пользователь получает строку подключения, которая содержит в себе УЗ, адрес целевой системы и одноразовый токен. В случае RDP-протокола сотрудник может получить сформированный RDP-файл для однократного подключения. В момент открытия файла RDP пользователь подключается к модулю SPS, который в свою очередь передаёт одноразовый токен модулю SPP, чтобы получить пароль для авторизации на конечной системе, после чего пароль автоматически подставляется в сессию. Трафик от пользователя проходит через сервер SPS, все действия протоколируются.

Рисунок 4. Схема подключения пользователя с запросом через портал

Цифрами на рисунке обозначены следующие события:

1. Пользователь подключается к порталу на SPP и запрашивает доступ.
2. Происходит обращение к SPS с полученной строкой подключения.
3. SPS отправляет запрос к SPP на получение пароля согласно токену, УЗ и адресу системы для подключения.
4. SPP возвращает SPS текущий пароль.
5. SPS вставляет в сессию пользователя логин и пароль для подключения, без их раскрытия.

Доступ с автоматическим согласованием на основе политик

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

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

Доступ без предварительного согласования

Для тех случаев, когда не хочется или нет возможности поменять рабочий процесс, существует вариант реализации привилегированного доступа без предварительного согласования. В этом сценарии люди не меняют схему подключения к системе и продолжают пользоваться теми же инструментами, к которым привыкли. При этом SPS перехватит сессию и при авторизации, например, с помощью обычной доменной УЗ предоставит пользователю сеанс с привилегированной учётной записью без раскрытия пароля.

Рисунок 5. Схема подключения пользователя без дополнительного согласования

Здесь цифрам на схеме соответствуют следующие события:

1. Пользователь пытается подключиться к целевой системе — указывает её имя «как обычно» и попадает на шлюзовую аутентификацию SPS.
2. SPS авторизовывает пользователя и запрашивает у SPP информацию о том, есть ли политики для этого подключения.
3. SPP возвращает SPS логин и пароль от УЗ согласно своим политикам.
4. SPS вставляет логин и пароль в сессию пользователя, и тот получает доступ к целевой системе с привилегированной УЗ без раскрытия пароля.

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

Схема лицензирования Safeguard

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

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

По поводу последнего пункта можно отметить, что модуль SPS очень производителен и позволяет контролировать до 500 одновременных RDP-сессий. Количество одновременных SSH-сессий может быть значительно выше. Если есть необходимость достичь более высоких показателей, то стоит использовать несколько SPS-устройств.

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

Интерфейс системы Safeguard

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

На главной странице портала (рис. 6) пользователь может получить информацию о согласованных доступах, посмотреть статусы ранее заведённых запросов на согласование, а также запустить рабочие процессы по согласованию. Раздел «Избранное» помогает упростить работу с наиболее часто используемыми типами доступов.

Рисунок 6. Главная страница портала пользователя для управления доступами

При запросе доступа необходимо указать целевую систему, учётную запись и тип подключения. При необходимости продукт позволяет одновременно запрашивать доступ к нескольким системам, чтобы сотрудникам не приходилось проходить процедуру запроса несколько раз (рис. 7).

Рисунок 7. Запрос доступа

Сотрудник, запрашивающий доступ, имеет возможность выбора различных УЗ, от имени которых будет выполняться подключение. Настройку можно производить в соответствии с заданными политиками, например в зависимости от членства в доменных группах (рис. 8).

Рисунок 8. Выбор учётной записи и типа доступа

Если необходимо запросить доступ от имени нескольких учётных записей, то можно это сделать одновременно (рис. 9).

Рисунок 9. Выбор учётной записи, от имени которой будет производиться подключение

Существует возможность запросить доступ как непосредственно после согласования, так и на указанный промежуток времени в будущем (рис. 10). Это позволяет подать заявку заранее и быть уверенным в том, что рабочие задачи будут решены даже в то время, когда согласующие недоступны.

Рисунок 10. Выбор дополнительных параметров при запросе доступа

После отправки запроса можно отслеживать его статус через консоль управления. Примеры запросов, находящихся на стадии согласования, можно увидеть на рисунке 11.

Рисунок 11. Запрошенный, но ещё не согласованный доступ

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

Рисунок 12. Ожидающие согласования запросы

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

Рисунок 13. Согласование запроса на предоставление доступа

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

Рисунок 14. Информация о предоставленном доступе с раскрытием пароля

В случае согласования доступа без раскрытия пароля предоставляется строка для осуществления подключения (рис. 15). Многие компании предпочитают этот формат доступа для внешних подрядчиков.

Рисунок 15. Предоставление доступа без раскрытия пароля

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

Если облачные сервисы нежелательны, можно использовать для добавления второго фактора другое решение, работающее на стороне заказчика, например One Identity Defender или любой другой продукт, работающий по протоколу RADIUS.

Рисунок 16. Предоставление доступа без раскрытия пароля

Для максимального удобства использования продукта можно реализовать привилегированный доступ без предварительного согласования запросов. Многие заказчики прибегают к этому варианту для того, чтобы обеспечить безопасность доступа внутренних сотрудников компании: появляется возможность отказаться от обезличенного применения общих учётных записей, таких как «root» или «administrator». На рис. 17 приведён пример настроек Putty, позволяющих использовать стандартные инструменты доступа, но при этом благодаря запросу аутентификации с использованием доменной учётной записи через модуль SPS всегда можно понять, кто выполнял действия от имени «root».

Рисунок 17. Настройки Putty для подключения с аутентификацией на SPS

Если настроена аутентификация на шлюзе SPS, то при открытии сессии будут запрошены доменные учётные данные (рис. 18).

Рисунок 18. Запрос учётных данных для аутентификации в сессии

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

Рисунок 19. Доступ от имени «root» после аутентификации с использованием доменной УЗ

Для защиты от выполнения опасных действий предусмотрено составление списка нежелательных команд. Можно настроить различные реакции на попытки ввести команду из этого перечня, в том числе имеется возможность разорвать сессию (рис. 20). Важно отметить, что разрыв сессии произойдёт до момента выполнения команды, так что опасное действие будет предотвращено.

Рисунок 20. Разрыв сессии по «чёрному» списку команд

Спектр возможностей по запросу доступов пользователями регулируется с помощью политик. На рис. 21 показаны различные типы доступа.

Рисунок 21. Возможные типы доступа

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

Рисунок 22. Политики согласования доступа

Для обеспечения более высокого уровня безопасности имеется возможность ротации паролей после окончания сессий (рис. 23). При необходимости можно разрешить или запретить одновременный доступ нескольких пользователей от имени одной УЗ.

Рисунок 23. Ротация паролей

В некоторых компаниях есть потребность в ограничении длительности сессий привилегированного доступа. В этом случае можно устанавливать принудительный лимит и прерывать сеанс по истечении настроенного интервала времени (рис. 24).

Рисунок 24. Разрыв сессий, превышающих разрешённую длительность

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

Рисунок 25. Политики по временному ограничению действий

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

Рисунок 26. Выявление аномалий в поведении пользователей

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

Рисунок 27. Поиск по ключевым словам и выражениям

Наличие фильтров помогает сузить количество сессий для проведения более детального разбора (рис. 28).

Рисунок 28. Использование фильтров при поиске необходимой информации

При необходимости можно подключиться к активной сессии. Это позволяет более детально понять, что в ней происходит в режиме реального времени (рис. 29).

Рисунок 29. Подключение к сессии в режиме онлайн

В случае выявления опасных действий сессию можно мгновенно разорвать (рис. 30).

Рисунок 30. Возможность разрыва сессии

При подключении к сессии в режиме реального времени можно видеть всё происходящее на мониторе пользователя (рис. 31).

Рисунок 31. Отображение сессии, к которой было произведено подключение

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

Рисунок 32. Поиск по ключевым словам внутри сессии

Ускоренному разбору инцидентов способствует и визуализация важной информации. Ключевые эпизоды активности и время простоя обозначаются на временной шкале специальными метками. Особенно ярко подсвечиваются интервалы, в которые на экране отображались искомые слова (рис. 33).

Рисунок 33. Визуальное отображение найденных слов на временной шкале

Выводы

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

One Identity рекомендует комплексно подходить к выбору технологий и обязательно опробовать продукт, прежде чем принимать финальное решение. Желаю вам успехов в выборе правильного РАМ!

Редакция Anti-Malware.ru благодарит Александра Едриванова, технического эксперта One Identity, за помощь в подготовке данного обзора.