Руководитель управления технических средств защиты департамента информационной безопасности Финансовой Группы БКС.
Окончил Сибирский государственный университет телекоммуникаций и информатики по специальности «Многоканальная электросвязь».
С 2004 года работает в сфере ИТ. С 2008 года занимается информационной безопасностью в финансовой и банковской сферах.
Александр Пирогов, начальник управления технических средств защиты департамента информационной безопасности Финансовой Группы БКС, рассказал Anti-Malware.ru о том, насколько важным является контроль привилегированных пользователей, и почему эта задача стала такой актуальной в настоящее время. В ходе диалога была затронута тема выбора средств контроля, а также ключевых требований к ним. Специалист поделился результатами внедрения системы PAM в работу компании и дальнейшими планами развития этого направления.
С чем было связано ваше решение приступить к реализации проекта по внедрению системы контроля привилегированных пользователей?
А. П.: Современный бизнес требует от администраторов прикладных систем достаточно быстрой реакции на происходящие в них инциденты, аварии, поломки и т. п. В связи с этим важной становится возможность подключения для настройки этих систем удалённо. Администратор прикладной системы должен иметь к ней доступ даже тогда, когда не находится в офисе, например, в выходные дни или в вечернее время. И в этом случае возникает задача организации удалённого доступа привилегированных пользователей к управляемым ими системам. Когда мы столкнулись с такой задачей, возникла подзадача — контроль этих пользователей. Он может осуществляться разными способами; один из наиболее очевидных — логирование этих подключений и запись видеосессий.
ИТ-инфраструктура БКС сосредоточена в одном месте или распределена?
А. П.: У нас, конечно же, распределённая инфраструктура, распределённая сеть. БКС имеет достаточно большое количество офисов — более шестидесяти, не считая агентов. Но с точки зрения ИТ-инфраструктуры она достаточно централизована. Это облегчает задачу контроля подключений привилегированных пользователей.
Правильно ли я понял, что основной задачей был именно контроль собственных администраторов, которые подключаются извне?
А. П.: Да, задача была именно такой.
А задачи контроля подрядчиков или аутсорсеров на тот момент не было?
А. П.: Нет, такой задачи перед нами не стояло, потому что по нашим корпоративным правилам на продуктовых системах внешние подрядчики и аутсорсеры не работают.
У кого в первую очередь возникла потребность в реализации такого проекта? У ИТ-департамента?
А. П.: Нет, в первую очередь этот запрос шёл от бизнеса, поскольку бизнес был заинтересован в быстром реагировании ИТ-специалистов на его запросы, на возможность подключения этих специалистов из любой точки.
В настоящее время на рынке, как на зарубежном, так и на российском, выбор PAM-решений весьма велик. Когда перед вами встала задача выбора решения для контроля подключения удалённых администраторов, какие из них вы рассматривали?
А. П.: Решений действительно достаточно много. Но если на этот рынок посмотреть несколько укрупнённо, то мы увидим, что все варианты относятся к двум классам. Первый класс решений — это клиент-серверные, они подразумевают установку на целевой сервер некоего клиента, который будет записывать сессии пользователя и логировать их. Второй класс — это решения проксирующие, которые ставятся в разрыв между клиентским компьютером и целевым сервером. Трафик проходит через них, там реализуется его расшифровка, записи видеосессии, логирования и т. д.
Мы после многих размышлений и тестирований остановились именно на классе проксирующих решений, потому что в этом случае мы оказываем наименьшее влияние на работу продуктовых систем. Агент, каким бы он ни был, так или иначе использует ресурсы сервера. Для высоконагруженных систем это может быть критичным.
Таким образом мы остановились на решении от One Identity. Мы говорим о бывшем Balabit Shell Control Box, который сейчас называется Safeguard for Privileged Sessions.
Из PAM-решений проксирующего типа почему в конечном итоге остановились на One Identity и почему стали внедрять именно его?
А. П.: Это было сделано по многим причинам. Во-первых, мы получили очень хороший отзыв от наших коллег из других финансовых организаций, использующих его для схожих задач. С ними мы пообщались в процессе выбора. Во-вторых, мы развернули собственный пилот, проверили и увидели, что эта система очень стабильна, она не требует больших затрат на администрирование и поддержку, большого количества аппаратных ресурсов для её развертывания. В-третьих, немаловажную роль, конечно же, сыграла ценовая политика One Identity. В итоге выбор был сделан в пользу One Identity SPS (Safeguard for Privileged Sessions).
Вопрос о поддержке протоколов удалённого администрирования. Основные из них — SSH, RDP, Telnet, HTTPS — большинством поддерживаются. Однако есть и много других протоколов. Могут возникнуть трудности: кто-то их поддерживает, кто-то — нет. Была ли у вас какая-то специфика именно с технической точки зрения?
А. П.: К сожалению, мы должны признать, что совсем идеальных решений нет. Но Safeguard for Privileged Sessions нас удовлетворяет в первую очередь потому, что он поддерживает протокол RDP, и архитектурно мы выстроили схему удалённого доступа так, что подключение пользователей происходит через промежуточный терминальный сервер, с которого они уже запускают требуемую им консоль для доступа к целевым серверам. Таким образом, осуществляются запись протокола RDP и запись сессии, поэтому с точки зрения контроля привилегированных пользователей этого достаточно. Но, как справедливо было замечено, Safeguard Privileged Sessions имеет достаточно богатый в этом смысле функционал. Также у нас есть и опыт прямого проброса SSH-трафика с его логированием. И это тоже достаточно хорошо себя показывает.
В случае протокола RDP система позволяет записывать видео сеанса. А как потом это всё просматривать, что и где человек нажимал, да и в целом, понимать, что нужно запускать расследование?
А. П.: Здесь нам всем в помощь система SIEM. Мы используем расширенное логирование на целевых системах и фиксируем действия администраторов в них. Дальше, при необходимости, администратор безопасности, видя какие-то подозрительные действия, может поднять видеосессии и просмотреть их, получая более детальную информацию.
Не менее важный момент — управление паролями для конечных систем. Какая политика у вас действует в этом вопросе? Каким образом вы настраивали решение для управления паролями?
А. П.: Именно вот этот функционал от One Identity Safeguard мы не используем. У нас для управления паролями и парольной политикой используется Active Directory и, соответственно, доменные политики.
Насколько мне известно, в настоящее время развитие продуктов PAM двигается в сторону автоматического пресечения опасных действий. Например, администратором случайно введены какие-то команды, которые могут удалить часть данных или полностью отформатировать диск. Нужна ли подобная функциональность — для купирования такого рода действий, для разрыва сессии и прочего? Или это пока маловозможно и малоприменимо в реальной жизни?
А. П.: User Behavior Analytics (UBA) — это наиболее активно развивающееся направление в области контроля действий пользователей и в информационной безопасности, а также наиболее интересное сейчас. И мы, конечно, очень внимательно смотрим в сторону этого функционала. Особенно приятно видеть, что подобный функционал начинает реализовываться в One Identity Safeguard. Мы в конце прошлого года брали его на тестирование. Пока ещё не сделали конкретного выбора в его пользу, но продолжаем об этом думать.
На мой взгляд, этот функционал очень востребован и его развитие, безусловно, будет для решения дополнительным плюсом.
В будущем вам это было бы интересно?
А. П.: Безусловно! Очевидно, что это — основная тенденция развития всех систем, которые «завязаны» на контроле действий пользователя.
Давайте рассмотрим более конкретный сценарий использования Safeguard for Privileged Sessions. Например, когда «падает» целевая система, или когда есть подозрение на инцидент. Расскажите немного об использовании этого продукта именно для информационной безопасности.
А. П.: Использование и применение — достаточно широкое. Начиная от простого учёта рабочего времени сотрудников при удалённом доступе, что тоже, кстати, актуально. Ведь необходимо понять, сколько времени сотрудник на самом деле затратил на работу, находясь на удалённом подключении. Это — самое простое применение, самое очевидное, но достаточно актуальное для всех компаний, реализующих схему удалённого доступа. И заканчивая расследованием инцидентов, когда возникает вопрос, кто и при каких обстоятельствах выполнил те или иные действия на целевых серверах. И в этом случае просмотр записи сессии даёт неоценимую информацию, в том числе и для подразделения информационной безопасности.
Нередкими бывают ситуации, когда происходит «падение» целевой системы и неизвестно, что в действительности произошло. Чтобы это выяснить, можно просматривать многочисленные логи, разбираться, кто и что сделал, а можно обратиться в PAM-систему, быстро поднять сессии и посмотреть, что происходило, а также быстро восстановить работоспособность целевой системы. Такой сценарий на практике у вас имеет место или это всё-таки — некая специфическая вещь?
А. П.: Я уверен, что это — вещь специфическая, но не в том смысле, что она не может происходить, а в том, что мы, к счастью, не сталкивались с ситуациями критичного падения целевых систем и разбора действий администраторов, которые её почему-то «уронили». Мы сталкивались с существенно менее критичными последствиями действий. В первую очередь это можно объяснить высокой квалификацией администраторов.
Это — один из теоретических сценариев.
А. П.: Конечно, его нельзя не учитывать. Как раз запись видеосессий призвана помочь в этом случае.
Расскажите немного об опыте внедрения PAM-системы. Это происходило постепенно, для каких-то отдельных групп администраторов или для целевых систем? Или же переход осуществлялся сразу на всех администраторов? Или каким-то иным способом? Какие этапы можете выделить на пути внедрения этой системы?
А. П.: На первом этапе мы внедряли её именно как средство контроля удалённого доступа привилегированных пользователей. В достаточно ограниченном количестве лицензий и на достаточно ограниченном количестве пользователей. Но последние события в мире и переход многих подразделений компаний на удалённый режим работы потребовали от нас более широкого развёртывания этой системы на существенно большем количестве пользователей. Мы смогли договориться с коллегами из One Identity о комфортных условиях использования лицензии, при этом существенно расширенной. И за последние две-три недели мы внедрили эту систему как целевое средство контроля удалённого доступа для всех пользователей сети компаний.
То есть, получается, не только для ИТ-департамента, но и для всех остальных пользователей?
А. П.: В том числе и бизнес-пользователи подключаются через эту систему. Мы протестировали её работу на практике на большом количестве пользователей с большим количеством одновременных сессий.
Можете озвучить какие-то цифры по нагрузке? Сколько одновременных сессий выдерживала система?
А. П.: Мы сделали следующее: развернули несколько «инстансов» системы и настроили балансировку нагрузки сторонними средствами.
На данный момент на один «инстанс» приходится порядка 60-70 одновременных сессий, то есть одновременно большое количество пользователей.
Все видеосеансы нужно куда-то складывать для хранения. Какие требования на вашей практике предъявляются к хранилищу?
А. П.: Решение имеет встроенный функционал экспорта видеозаписей в хранилище, поддерживает различные протоколы — от стандартного SMB до NFS. Мы развернули файловый сервер, на который экспортируются видеозаписи старше определённого возраста. На данный момент мы ориентируемся на калькулятор, который нам предоставили коллеги из One Identity, и рассчитываем, что в пике (на тысячу пользователей) это примерно составляет порядка восьмидесяти гигабайт за восьмичасовой день.Во всяком случае, на такой объём мы ориентируемся.
Во всех крупных компаниях есть бизнес-пользователи, которым, как правило, даются расширенные права. По отношению к ним используются ли какие-то особые политики?
А. П.: Наши подходы на самом деле достаточно стандартны. Мы экстраполируем тот же подход, который используется для ИТ-администраторов — это контроль действий в целевой системе. Соответственно, — сбор этих событий в SIEM, отчёты в SIEM и просмотр видеосеансов при каких-то подозрительных или нетиповых действиях.
Сейчас наша страна переживает очень непростой период, связанный с коронавирусом и карантинными мерами. Большинство сотрудников различных компаний по возможности перешли и продолжают переходить на удалённую работу. Это всё случилось быстро, в течение недели, максимум — двух. У вас, разумеется, тоже какое-то число сотрудников перешло на «удалёнку». Как быстро удалось настроить и масштабировать этот продукт на резко возросшее количество пользователей? Насколько это оказалось сложно и трудоёмко?
А. П.: Это оказалось очень просто. Нам потребовалось два дня для того, чтобы договориться с коллегами из One Identity об использовании расширенной лицензии, и два дня на масштабирование инфраструктуры.
Никаких существенных изменений архитектуры и настроек не понадобилось?
А. П.: Существенных — нет. Наиболее нестандартным решением была балансировка нагрузки между «инстансами». К сожалению, в Safeguard for Privileged Sessions такого функционала на борту не имеет, поэтому нам пришлось использовать внешние балансировщики.
Настройка с использованием внешнего балансировщика нагрузки была наиболее интересной и сложной задачей. Масштабирование же самого Safeguard Privileged Sessions — достаточно типовое, и его развёртывание занимает считаные минуты.
Я правильно понял, что в вашем случае встроенный механизм Single Sign-On не понадобился, потому что вы решили использовать Active Directory?
А. П.: Да, верно, в нашем случае этот механизм не понадобился. Мы не меняли схему авторизации пользователей.
А как быть в том случае, если кроме Windows присутствуют какие-то другие системы, например, Linux?
А. П.: Во-первых, системы Linuxмогут быть введены в домен и интегрированы с доменом различными средствами. Во-вторых, в тех случаях, когда это невозможно, используется внутренняя авторизация систем Linux.
Сколько прошло времени с момента начала проекта?
А. П.: Мы развернули решение ещё тогда, когда оно называлось Balabit Shell Control Box. Это было примерно три-четыре года назад.
А сейчас пошла вторая волна по масштабированию?
А. П.: Да. Это — совсем свежая история. Март.
Как вы оцениваете эффективность проекта? Можете ли оценить проект на коммерческом уровне? Оправдали ли себя, на ваш взгляд, финансовые затраты?
А. П.: Я оценил это решение достаточно высоко. Оно эффективно. При его оценке необходимо коснуться нескольких аспектов. Аспект номер один — это его эффективность для бизнеса и именно с точки зрения контроля действий привилегированных пользователей. Второй аспект — это себестоимость решения и ресурсы для его развёртывания и сопровождения, аппаратные и физические. Это — то, что мы увидели. Решение действительно позволяет эффективно контролировать привилегированных пользователей в случае удалённого доступа. Оно предоставляет достаточно большой набор информации для проведения расследований офицерами безопасности и не требует существенных ресурсов при развёртывании и сопровождении. Всё это, безусловно, показывает хорошую эффективность.
А если говорить о каких-то конкретных метриках по отношению к этому продукту? Например, о количестве инцидентов, обнаруженных в течение какого-то периода. Возможно, с применением такого подхода сотрудники стали выполнять свою работу быстрее? Повысилась ли эффективность труда, по вашему мнению, за счёт того, что теперь, несмотря на удалённую работу, всё прозрачно и видно, кто чем и сколько по времени занимается?
А. П.: Отличный и очень правильный вопрос. Мы действительно с этим столкнулись.
Мы обнаружили, что это решение позволило существенно сократить сроки реагирования администраторов на различные инциденты.
Благодаря развёртыванию системы удалённого доступа им не нужно приезжать в офис для проверки сообщений мониторинга, алертов и тому подобных вещей. Это существенно сокращает сроки реагирования, а также способствует своевременному выполнению внутренних SLA. И, естественно, повышает надёжность работы ИТ-системы.
Какие у вас есть планы на развитие этого проекта в ближайшем будущем?
А. П.: Во-первых, развёртывание нескольких «инстансов» и существенное расширение количества пользователей удалённого доступа прямо поставило перед нами задачу интеграции с системой SIEM. Ранее мы такого не делали, поскольку в этом не было существенной необходимости. Сейчас она действительно появилась, и мы начали осуществлять это объединение. Во-вторых, мы, скорее всего, снова вернёмся к задаче анализа модулей поведенческой аналитики.
Это — как раз те активные аномальные действия, о которых мы говорили?
А. П.: Да, именно. И, наверное, можно прогнозировать, что не только у нас, но и везде в мире сейчас изменится отношение к удалённой работе. Вероятно, какие-то подходы к её использованию останутся и после эпидемии коронавируса. Соответственно, необходимость решений по контролю тоже останется.
Переход на удалённую работу, который сейчас происходит, очень серьёзно меняет бизнес-процессы. Думаю, сама модель угроз отчасти тоже поменяется. При удалённой работе существенно возрастут риски компрометации рабочих станций и несанкционированного доступа.
А. П.: Именно этот риск мы всё-таки минимизируем за счёт использования двухфакторной аутентификации. Это сводит риски доступа в корпоративную сеть при компрометации клиентского пользовательского компьютера к минимуму. Но в целом с этим утверждением невозможно поспорить. Сейчас многие компании лихорадочно настраивают удалённый доступ, могут некоторые части своей инфраструктуры неожиданно, в том числе и для себя, выставить в интернет. Мы к этому относимся очень внимательно и непродуманных решений здесь не принимаем.
Спасибо за интервью. Успехов!
