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

Мы продолжаем обсуждать самые важные темы по части импортозамещения в сфере ИТ и кибербезопасности. Сегодня мы поговорим с Александром Махновским, техническим директором и сооснователем компании Avanpost, о том, как изменился за последние годы рынок ИБ.

В проектах по внедрению новых программ всё зависит не только от самого продукта. Вы говорили ещё в 2021 году, что главную роль играет команда: как на стороне заказчика, так и на стороне интегратора. Как вы считаете, сейчас это справедливо?

А. М.: От самого продукта, от его выбора очень многое зависит. Тут можно сказать и «да», и «нет». Естественно, от продукта как зависело, так и продолжает зависеть весьма многое. 

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

За последние несколько лет экспертиза на рынке в нашем направлении значительно возросла, потому что раньше был такой период, в который крупные гиганты — IBM, Oracle и так далее — потеряли актуальность. Мы и наши конкуренты ещё не набрали обороты должным образом. Был и некоторый дефицит экспертизы на рынке, который за прошедшие четыре-пять лет в значительной степени устранился.

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

Нужно это эффективно продать внутри компании, чтобы этим начали пользоваться. Где-то — добровольно, где-то — принудительно, по-разному бывает. Где-то мы стараемся кому-то отдать функцию, которая ему необходима и сделает лучше конкретному подразделению; где-то это решение принимается сверху, «по указке». Речь шла не только об экспертизе команды внутри и команды интегратора, но и о наличии спонсора, достаточно высокоуровневого проекта и административных рычагов влияния на внутренние подразделения, которые должны принять этот сервис и начать им пользоваться.

Вы говорили в 2021 году, что зрелость российских продуктов была не столь высока. В то же время стоит отметить, что импортозамещение в сегменте IdM пошло гораздо раньше, ещё до 2022 года. Сейчас это уже воспринимается как данность, а тогда за это надо было побороться. Тем не менее этот процесс шёл. Если говорить о зрелости, которую сейчас набрали IdM-продукты в России (на примере Avanpost), то в чём выражается экспертиза?

А. М.: Если сравниваем состояние в 2021 году и сейчас, то функционально продукты в 2021 году соответствовали запросам большинства участников рынка. Но в 2021 году у нас не было заказчиков из крупного бизнеса, искушённых заказчиков, работавших с топовыми западными решениями, у которых очень сложная инфраструктура. Всего, что касается крупных негосударственных компаний, которые с 2021–2022 года во многом стимулировали очередной виток развития продуктов IAM, на тот момент не было.

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

Было важно, чтобы ПО стало удобнее и понятнее для конечного потребителя. Здесь можно рассматривать два аспекта: с одной стороны — функциональный (возможности, пользовательский опыт и так далее), с другой стороны — уровни архитектуры и инфраструктуры. И там и там было что делать.

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

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

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

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

Допустим, у вас есть подменный кассир, который должен выйти в офис банка прямо сейчас, потому что туда не вышел тот, кому следовало. Можно было бы дать ему права напрямую, но у нас же IdM. Для того чтобы запустить правильный процесс, нужно оформить заявку, которая передаётся на согласование. В конечном счёте он получит на период выхода те самые права, с которыми сможет работать в этом офисе; но от того, насколько он быстро их получит, напрямую зависит, сколько денег потеряет банк прямо сейчас. Это уже уровень «business critical». И если у вас непроизводительный рабочий процесс в IdM, если у вас ручные или полуручные интеграции и так далее (что тоже весьма часто встречается), вы не достигнете целей бизнеса с таким внедрением. Бизнес же просто будет терять на этом деньги.

Иначе говоря, в некоторых случаях — когда важны текущие права доступа, важно их поддерживать в минимальном достаточном объёме и своевременно их предоставлять для решения возникших бизнес-задач — IdM критически важен. 

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

Служебных?

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

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

Казалось бы, поставьте рядом ещё один сервер, сделайте кластер, и всё будет нормально. Верно?

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

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

А. М.: Я помню, опять-таки, что несколько лет назад все мерились количеством коннекторов: с какими системами у нас есть интеграция, с какими — нет. Сейчас кажется, что все эти проблемы ушли на второй план. Коннекторами мы не меряемся уже давно, лет пять-семь, наверное. Все поняли, что это дело или наживное, или проектное, и так или иначе в каждом проекте оно модифицируется. Все научились это делать, но это уже давно не преимущество.

Может ли быть сложно внедрить IdM в каком-то конкретном ландшафте?

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

Как бы вы оценили готовность и способность IdM-продуктов (и компании Avanpost) обеспечить и поддержать переход на полностью отечественный технологический стек без Windows, Active Directory и так далее? 

А. М.: Первая волна внедрения IAM-решений продолжалась где-то с 2006 года по 2010–2012 годы. Внедрения были масштабными, тяжеловесными. Западные продукты — от тех же Oracle и IBM, — которые внедрялись на нашем рынке, были на тот момент недостаточно функциональными. То же касается SAP или Microsoft. В основном те внедрения, которые были сделаны в нашем сегменте, — это уже устаревшие системы. На данный момент мы приходим, например, куда-то, где использовался SAP IdM, и открываем какие-то новые вещи (как функциональные, так и нефункциональные) для заказчика, который пользовался до этого западным продуктом.

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

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

Продолжение интервью скоро на нашем сайте…