Руслан Ложкин: «Абсолют Банк» рассматривает PAM от One Identity как перспективный источник событий для SOC

Руководитель службы информационной безопасности «Абсолют Банка» Руслан Ложкин в интервью Anti-Malware.ru рассказал об опыте внедрения PAM от One Identity, о вынужденном предоставлении сотрудникам удалённого доступа, а также о грядущих требованиях ЦБ и о возможных трудностях, которые они могут повлечь за собой.

Не так давно у нас прошла онлайн-конференция AM Live, посвящённая выбору системы контроля действий привилегированных пользователей (PAM). Поэтому хотелось бы обсудить, как в вашей компании используется PAM.

Р. Л.: Основные задачи, для которых нужен PAM: с одной стороны, мы бы хотели им закрыть регуляторные требования, так как мы — банк и на нас распространяется множество требований, в том числе банковский ГОСТ, в котором чётко прописано, что должен быть контроль привилегированных пользователей; с другой стороны, это — потребность бизнеса, мы ведь все понимаем, что соблюдение регуляторных требований и обеспечение / организация безопасности — немного разные термины в контексте российского регулятора. С одной стороны, мы должны выполнять требования, так как находимся на российском рынке и подчиняемся регулятору; с другой стороны — у нас есть собственные интересы, такие как защита клиентов, защита конфиденциальной информации, защита конфигураций оборудования, и мы хотели бы контролировать привилегированных пользователей — наших администраторов.

Доступ к какому количеству систем у вас контролирует PAM?

Р. Л.: У нас порядка двадцати систем. Эти двадцать систем состоят из тысячи серверов, как физических, так и виртуальных. На них развёрнуты базы, сервисы и другие компоненты.

Как в вашем банке на использование PAM повлияла «удалёнка»?

Р. Л.: «Удалёнка» не была для нас чем-то новым и активно использовалась, но не в масштабах всего банка. PAM только дополнил контроль администраторов и разработчиков.

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

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

Я правильно понимаю, что основной мотив — «комплаенс» (в том числе требования Центрального банка, о которых вы сказали), а дальше уже вы стали смотреть, как получить от этого продукта дополнительную пользу с точки зрения безопасности?

Р. Л.: Я пришёл сюда (в банк. — Прим. ред.) в конце прошлого года, когда PAM уже был куплен, лицензии были поставлены. Я не знаю, какие были изначальные предпосылки для выбора решений у предыдущей команды. Лично я стараюсь дать новые возможности в части организации каких-то новых сервисов под бизнес-потребности, там, где у банка были проблемы с их реализацией из-за высоких рисков. А внедрив решение, позволяющее минимизировать риски привилегированных пользователей, мы даём возможность, например, активно применять распределённые команды. То есть решение должно приносить пользу. А то, что отсутствие контроля за администраторами несёт риск, — это и так понятно, это акцентируют стандарты по безопасности и требования регуляторов. «Комплаенс» — это только базовые требования и чек-лист, по которому можно как-то оценить степень защищённости.

В вашем случае получается, что администратором и основным заказчиком этого проекта является департамент ИБ?

Р. Л.: В большей степени — да. Бизнесу тема ИТ не особо интересна, а в части защиты информационных активов инициатором является служба, занимающаяся информационной безопасностью.

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

Р. Л.: Я считаю, что ИБ и ИТ должны находить компромиссы, уметь действовать дружно и понимать, что в первую очередь они работают на достижение конкретных бизнес-показателей. ИБ занимается защитой информационных активов, то есть обеспечивает их целостность, конфиденциальность и доступность. ИТ обеспечивает сервис, чтобы активы работали и все потребители получали услугу. Мы — по разные стороны, но одно не должно мешать другому. Кроме того, у нас сейчас очень активный председатель правления, который стимулирует развитие кибербезопасности, и она — в тренде.

Хотел узнать о масштабе самого проекта: примерно какое количество привилегированных учётных записей на данный момент контролируется и кому они принадлежат? Это — внутренние сотрудники департамента ИТ или внешние подрядчики?

Р. Л.: Думаю, порядка 100 человек.

Кто эти люди? Это — наши администраторы, которым нужен удалённый доступ, потому что их задача — обеспечивать поддержку определённого ресурса, и часто это нужно делать в режиме 24х7. И вторая большая категория — разработчики.

Здесь, наверное, всё понятно. Распределённая команда разработчиков может находиться, где угодно, но система CI / CD (Continuous Integration / Continuous Delivery, непрерывная интеграция и непрерывная поставка. — Прим. ред.) находится на территории банка, и к ней нужно каким-то образом подключаться. Помимо CI / CD есть ещё тестовые зоны, куда разработчики тоже должны как-то заходить. Соответственно, для них мы в том числе данный PAM и внедряли.

Разработчики имеются в виду ваши внутренние, которые разрабатывают банковские системы?

Р. Л.: Это могут быть и штатные сотрудники, и компании-аутсорсеры, и лица оформленные по гражданско-правовому договору. Таким образом, разработчиков достаточно много, и они рассредоточены. Агрегировать их в банке мы в принципе никогда не сможем.

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

Что касается непосредственно сценариев: правильно ли будет сказать, что у вас в банке PAM в первую очередь начал использоваться как некое средство контроля действий привилегированных пользователей (запись сессий, логов и так далее), а уже потом — с целью реализации дополнительных сценариев?

Р. Л.: Мы покупали и внедряли решение для этих целей — но использовать везде PAM не можем вследствие особенностей нашей инфраструктуры. Например, у нас очень много баз на Oracle, а текущий PAM пока не может контролировать сессии Oracle. Вендор говорит, что раньше у них не было такой потребности, поэтому такой функционал не был реализован. Обещает это исправить в скором времени. В связи с этим нам приходится чуть ли не силовым путём указывать администратору на необходимость подключаться к базе Oracle через специальный jump-сервер, с которого мы уже смотрим сессию PAM, но это сложно назвать контролем. Поскольку администраторы работают через эти jump-серверы, мы можем говорить о неких функциях контроля; но, опять же, администратор может входить и иначе, и тогда мы ничего не увидим. Поэтому нам приходится принимать дополнительные меры защиты.

Как вам удаётся добиться того, чтобы пользователи заходили в целевые системы не напрямую, а через PAM?

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

Используете ли вы PAM-систему как некий инструмент аудита имеющихся привилегированных учётных записей, чтобы понять, какие учётные записи реально используются, какие — устарели и нуждаются в удалении, как часто и кто куда заходит — вещи, которые позволяют навести порядок?

Р. Л.: Безусловно, решение позволяет отслеживать активность учётных записей и есть статистика по их активности. Но в целом это — задача систем типа IDM. PAM — больше для контроля того, что делает привилегированный пользователь. Также можно настраивать определённые запреты.

Остаётся некая «серая зона» за счёт того, что PAM не видит все возможные привилегированные учётные записи в целевых системах?

Р. Л.: Нужно иметь пул административных учётных записей, его нужно постоянно обновлять и куда-то выгружать (в какой-то реестр), чтобы PAM-система могла в онлайне (или хотя бы раз в сутки) с этого ресурса подгружать весь этот перечень административных учётных записей.

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

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

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

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

Р. Л.: Просто часть систем досталась нам от старой команды. Для контроля подобных систем в РАМ может потребоваться доработка интеграции. На каких-то коммерческих решениях мы можем сделать автоматическую смену пароля — но это не будет применяться ко всем системам, поэтому пока для нас это не совсем актуально. Либо делать, если есть возможность охватить всё, либо не делать, если это будет охватывать лишь половину систем.

Как вы смотрите на возможность интеграции PAM и системы Single Sign-On, чтобы администратор использовал одну учётную запись и через неё заходил в целевые системы?

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

Возникает ли у вас потребность использовать PAM-систему для расследования инцидентов информационной безопасности? Например, в случае сбоев.

Р. Л.: Таких явных кейсов на данный момент не было, просто внедрение PAM у нас затянулось на достаточный промежуток времени. Поэтому можно сказать, что мы его ещё «обкатываем» и имеем недостаточно статистики.

Хорошо, что таких кейсов ещё не было.

Р. Л.: Согласен. Но в дальнейшем мы хотим интегрировать PAM с SIEM-системами, с нашим SOC, и, возможно, как первоисточник каких-то событий PAM будет интересен. Аналитик или оператор SOC сможет зайти туда и дообогатить сведения, чтобы сформулировать инструкции или поставить задачу исполнителю.

Чтобы посмотреть, что там происходило в определённые моменты времени?

Р. Л.: Да. Всё автоматизировать — это достаточно дорого и ресурсозатратно. Но если PAM используется именно в качестве средства обогащения некоторой аналитики, то при возникновении инцидента оператор SOC может «провалиться» в частную систему и исследовать ситуацию, найти причины, которые привели к конкретному инциденту, и использовать логи PAM для написания корректной задачи, чтобы исполнитель — администратор ресурса — уже мог правильно устранить причину, которая привела к инциденту.

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

Р. Л.: Мы рассматриваем облака, активно за этим наблюдаем. Но здесь есть различные нюансы.

Когда начинаешь просчитывать себестоимость облака — с учётом обеспечения средств безопасности, — то это получается не дешевле решения on-premise.

То есть экономический фактор — в пользу on-premise?

Р. Л.: Да. Но и здесь есть дополнительный «блокер» — это, опять же, наш регулятор, Центральный банк, который пока что ещё не дал разъяснений по поводу того, можно или нельзя использовать облачные решения, и если можно, то как выполнить все его требования. Многие сталкиваются с этой проблемой. Есть некая конфиденциальная информация — банковская тайна, — и непонятно, как её передавать третьим лицам. Передавая в облако, мы должны понимать, какие риски мы из-за этого несём. В нашем законодательстве, в том числе банковском, много таких коллизий, которые пока не позволяют банкам полноценно использовать облачные ресурсы. И второй фактор заключается в том, что соблюдение всех требований Банка России при облачном размещении экономически нецелесообразно.

Если перейти в техническую плоскость, то какие положительные моменты можно выделить по опыту личной эксплуатации и внедрения One Identity Safeguard? Что оказалось удобным в продукте? Что понравилось или не понравилось?

Р. Л.: Что понравилось? В принципе достаточно несложная интеграция, простое добавление и подключение пользователя. Что не понравилось? Это скорее является некой недоработкой функциональных возможностей: мы сейчас не можем контролировать Oracle-сессии, приходится устраивать обходные пути, которые не всегда работают, потому что администраторы не всегда хотят по ним ходить. Контроль этих администраторов мы теряем.

Мы смотрели и российские системы, но в них тоже нет контроля Oracle- и SQL-сессий — пожалуй, всё это ещё находится в процессе работы у всех вендоров (в том числе и у One Identity).

Если смотреть на перспективу, то что было бы интересно увидеть в PAM, чего ещё не хватает?

Р. Л.: Хотелось бы видеть PAM частью нашей экосистемы. Для этого он должен легко интегрироваться, отдавать достаточно информации и управляться, например, через SOAR-системы.

То есть нужен инструмент более лёгкого внедрения PAM-системы и её интеграции с другими продуктами по информационной безопасности?

Р. Л.: Да. Условно, мы не можем плодить системы и содержать кучу людей, которые бы их все мониторили. Когда их десять, сколько требуется содержать человек, чтобы они их непрерывно мониторили? А если количество систем увеличится в два раза? Нет просто таких ресурсов. С точки зрения эффективности — эффективность никакая.

Поэтому в любом случае как-то надо их объединять в некий ландшафт или в некую экосистему. Пусть это будет сделано на базе SIEM или на базе SOC. И хотелось бы, чтобы эта система легко интегрировалась.

Есть ещё один фактор у банков, тоже бы это упомянул здесь, — это требования регулятора: мы пока не знаем, насколько будут или не будут к нам предъявляться требования по использованию только отечественного ПО, программ из реестра Минцифры. По критической инфраструктуре такие требования имеются, но наш банк пока не настолько велик, чтобы попасть в КИИ. Однако всё-таки есть некоторые опасения, что ЦБ может ввести такие требования (не в следующем году, но на какую-то перспективу). И придётся искать либо альтернативу, либо возможность для One Identity сертифицировать свой продукт для российского рынка.

Получив доступ к PAM, мы теоретически можем много куда «залезть». Как подходить к её защите? Какие практики вы со своей стороны порекомендовали бы?

Р. Л.: Введение второго фактора, который привязывается непосредственно к сотруднику банка. Соответственно, после ввода логина и пароля происходит ещё ввод какого-либо второго фактора, и тогда уже человек попадает в систему. Мы сейчас работаем над этой концепцией и, возможно, её реализуем, потому что она закрывает много проблемных мест. Это может быть и токен, и пароль, и биометрия (отпечаток пальца, например). Впрочем, я — не сторонник биометрии: как показывает практика, развитие идёт в сторону распределённых команд, а биометрию не всегда удобно передать из удалённого места. Дешевле применять одноразовый пароль, USB-токен или какой-нибудь сертификат.

Как вы смотрите на перспективы использования One Identity Safeguard в режиме работы «в разрыв»? Насколько я понимаю, такой режим у них тоже есть и при подозрительной активности, при каких-то опасных командах сессия будет прерываться, тем самым останавливая действия администратора, который может замышлять что-то нехорошее.

Р. Л.: Здесь данную проблематику нужно решать более комплексно. Один PAM её не решит. PAM может «задетектить» какие-то действия администратора — но надо понимать, что сейчас мы ставим PAM на контроль только части удалённых сессий и мы его ставим только на jump-серверы, через которые ходят «удалёнщики».

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

Это может быть и SIEM-система (зафиксировать какие-то события), и система управления конфигурациями (администратор, например, изменил конфигурацию, и она является небезопасной) — то есть все эти системы должны работать в комплексе, они должны информировать единый ситуационный центр, который будет быстро принимать решение.

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

Спасибо за беседу! Желаю успехов!