Александр Махновский, Avanpost: Как меняется отечественный рынок ИБ — Часть 2

Продолжаем беседовать с Александром Махновским, техническим директором и сооснователем компании Avanpost, об изменениях на рынке кибербезопасности, а также о том, насколько российские компании готовы к интенсивной работе в связи с возросшим спросом из-за импортозамещения ПО.

Готовы ли российские компании работать в новых условиях, если смотреть с точки зрения окружения, инфраструктуры и так далее?

А. М.: Ответ — да. Об этом задумались гораздо раньше, примерно в 2015 году. У кого-то уже был технологический стек, который не вызывал вопросов (например, Java-стек). Кто-то находился на технологическом стеке платформы, адаптировался к ней и, соответственно, автоматически получил возможность работать на импортозамещённой инфраструктуре. 

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

Давно говорится о замене термина IdM на более прогрессивный IGA — Identity Governance and Administration. Что за этим стоит?

А. М.: За этим стоит именно Governance (плохо переводится на русский). Будем считать, что это надзор и верхнеуровневое управление. Здесь выполняются аудиты и аттестация.

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

А. М.: Насколько готов — трудно сказать. В целом, если брать наших клиентов, то небольшое количество пользуются той же самой функциональностью аттестации прав доступа, плановым пересмотром и так далее. Чуть больше клиентов пользуются разделением ответственности (segregation of duties), потому что оно так или иначе следует из определённых нормативных документов. В целом функция востребованна уже весьма давно. 

Практически ни у кого нет запроса на риск-менеджмент внутри IdM. Он только созревает на данный момент. Но при этом есть крупные компании, которые пользовались, предположим, тем же самым SAP, в котором был GRC, и сейчас активно выбирают себе решения на замену. Если у них этот модуль активно использовался, то и практика вокруг него сформировалась. Обычно в этом задействованы и внутренний комплаенс, и ещё много участников помимо ИТ и ИБ. Соответственно, с их стороны на данный момент сейчас вполне широко звучит запрос на рынке. За последний год мы несколько раз получали запросы, в которых эти функции упоминались и были в том числе критически значимыми.

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

Нельзя ли сказать, что это следствие незрелости процессов у многих заказчиков? Положим, если процесс не предполагает оценку доступов с точки зрения конфликта интерсов SoD, им это, возможно, и не нужно.

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

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

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

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

Анализ рисков таким компаниям в массовом подразделении тоже не нужен. Если у них нет рядом ИТ-подразделения (которое может быть при этом малочисленным), он там будет неоправдан. Это одна ситуация.

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

Можете ли вы назвать недооценённые функции IdM и IGA, о которых заказчики не знают или почему-то пренебрегают их использованием? 

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

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

Как насчёт так называемых киосков самообслуживания? Я думаю, не все компании дозрели до того, чтобы сотрудники сами выдавали или меняли себе права. А как вы считаете?

А. М.: У нас за последние лет семь нет ни одного внедрения, где не использовался бы сервис самообслуживания. Чаще он применяется в виде готовой продуктовой реализации. Иногда интерфейсы делаются в ITSM — в зависимости от потребностей того или иного клиента, его правил.

Как, исходя из сценариев использования, будет дальше меняться функциональность IdM- и IGA-продуктов? 

А. М.: Очень много сейчас говорится, например, про концепцию Zero Trust, то есть доступа с «нулевым доверием». Казалось бы, IdM или IGA — это как раз один из тех продуктов, которые могли бы стать хабами по управлению всеми доступами на динамическом уровне. Но если рассматривать Zero Trust, то здесь несколько ближе другие наши продукты — связанные, главным образом, с аутентификацией. Всё-таки IdM — это прикладная система или система автоматизации. Неважно, чья деятельность автоматизируется: ИТ-подразделений, ИБ или, в случае с риск-менеджментом, комплаенса. Это система автоматизации, которая работает на низком уровне в плане интеграции, но при этом имеет очень большую, развесистую бизнесовую функциональность. Уровень аутентификации ближе к концепции Zero Trust.

Если говорить об отношениях между решениями класса Identity Management и концепцией Zero Trust, то что здесь требуется от IdM?

А. М.: Сама минимизация полномочий. Но такого запроса на рынке, к сожалению, на данный момент ещё пока нет. Вот два актуальных аспекта: автоматизация и контроль полномочий. Один запрос, соответственно, от ИТ, второй — от информационной безопасности. Перевеса в сторону информационной безопасности в качестве заказчика я не вижу. Всё-таки большинство продаж — наверное, процентов 60 — это продажи в сторону ИТ-подразделений.

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

В 2014–2015 годах неспособность заказчиков ко внутреннему согласованию была распространённой историей. Мне кажется, что взаимопонимание между ИТ-подразделениями и ИБ вышло на качественно лучший уровень. Часто ИТ — это внутренний исполнитель; интегратор сдаёт результаты ИТ-подразделению, а оно сдаёт те функции, которые интересуют безопасников, ИБ-подразделению. Экспертиза сопровождения должна быть в информационной безопасности; при этом, так или иначе, администратора мы сильно не ограничим в правах.

Расскажите о своём опыте работы с ролевой моделью.

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

Сейчас мы наблюдаем активный рост российского рынка облачных услуг. Смотрите ли вы в сторону IdM из облака? Можете ли вы сейчас предложить что-то для так называемых «cloud native» компаний, которые уже давно находятся в облаке, но хотят иметь тот самый инструмент по управлению доступом, к которому они, возможно, привыкли ранее?

А. М.: Пока что к полноценному IdM как SaaS, мне кажется, рынок не готов совсем. Компания обратит внимание на полноценный IdM в качестве SaaS-решения только в том случае, если она имеет только облачный ландшафт, в котором отсутствует IaaS-сегмент. Но этого практически нет на данный момент на российском рынке.

Если мы говорим про полнофункциональную модель, то очень немногие будут готовы открыть часть своей инфраструктуры для того, чтобы внешнее решение управляло извне. Это всё-таки информационная безопасность. Мы не видим в перспективе ближайших нескольких лет возможности предоставления полноценного IdM- / IGA- решения как сервиса из облака. Наоборот, если какая-то часть инфраструктуры находится в облаке, хочется при помощи нашего привычного IdM-решения управлять всем этим. Таких решений немало. Это Office 365, G Suite и так далее. Были разработаны коннекторы, у нас они есть и использовались ранее.

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

Как известно, началось активное перестроение ИТ-ландшафтов, прикладных систем и так далее. Чем импортозамещают тот же самый SAP, когда возникает такая необходимость?

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

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

К чему вы будете стремиться в развитии своих продуктов? Какой вы видите компанию Avanpost через год-два?

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

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

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

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

Я вижу, что компания Avanpost не стоит в стороне от общего тренда на построение своих экосистем. Можете ли вы назвать основные интеграции, которые усиливают внедрение IdM / IGA, и сказать, за счёт каких смежных продуктов эта экосистема должна полноценно выстраиваться?

А. М.: В целом, вот у нас есть Identity Access Management; некоторые вещи погранично к нему относятся, но так или иначе за эти рамки на данный момент мы не хотим далеко выходить. Есть ещё целый ряд продуктов, которые можно сделать в этом направлении вместо тех, что поступали от западных вендоров. Вот куда мы движемся сейчас применительно к линейке продуктов в своей экосистеме.

Если говорить про смежные с IdM-системой решения, которые, как правило, присутствуют, то первое — это ITSM, конечно же. Не берём классические интеграции, кадровые интеграции, управляемую систему: здесь всё понятно, IdM для этого и нужен. Берём прочие смежные системы. Там есть и управление изменениями (change management), и управление инцидентами. Очень часто строятся сквозные бизнес-процессы — как минимум, передача отчётности. Это касается большинства проектов, где есть подобная интеграция.

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

Почему PAM?

А. М.: Потому что сами PAM-системы не могут полноценно управлять доступом: правил уровня ролевой модели или знаний о том, в каком проекте какую систему обслуживает тот или иной администратор, у них нет, а у IdM — есть. Самому IdM интеграция с PAM много пользы не приносит, но компании, у которых есть и то и другое, извлекают значительную выгоду. Это важно.

Почему вы до сих пор не упомянули системы многофакторной аутентификации?

А. М.: Да, конечно, SSO, MFA. Это тоже управляемая система, но особенная. У неё есть свои разрешения на доступ к другим системам. Поэтому для нас она — часть управления некоторым внутренним ресурсом, то есть немного отличается в плане логики интеграции. 

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

Александр, большое спасибо за содержательное интервью. Надеюсь, в будущем мы ещё встретимся и обсудим, что изменилось. Всего вам самого безопасного!