• Все разделы
  • Статьи
  • Медиа
  • Новости
  • Нормативные материалы
  • Конференции
  • Глоссарий

Статьи по теме: «Информационная безопасность»

Главная Специалистам Статьи Интервью с экспертом. «IDM: на стыке классической автоматизации и информационной безопасности»

Интервью с экспертом. «IDM: на стыке классической автоматизации и информационной безопасности»

Генеральный директор компании «Аванпост» Андрей Конусов в интервью порталу «Безопасность пользователей сети Интернет» (www.safe-surf.ru) рассказал о ключевых аспектах применения технологий управления доступом в интересах информационной безопасности организаций.

Интервью с экспертом. «IDM: на стыке классической автоматизации и информационной безопасности»

Когда у российских специалистов по информационной безопасности (ИБ) возник интерес к решениям для управления доступом IDM (Identity Management), и чем он был мотивирован?

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

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

Осознание этого риска стало отправной точкой, после которой интерес к тематике IDM на рынке ИБ резко вырос. Начиная работу в компании «Аванпост», я видел, как люди, с которыми мне приходилось общаться, впервые задумывались об этом. Поначалу увязка IDM с безопасностью была для них неочевидной: они все еще воспринимали IDM как средство автоматизации в ИТ. Но в течение двух-трех лет к ним пришло понимание, что возможности системы управления гораздо шире. Ведь IDM – это еще и аудит прав доступа, автоматизированное отслеживание возникающих отклонений, своевременное информирование о них офицеров безопасности и быстрое оперативное исправление отклонений с (возможным) последующим расследованием инцидентов. Это все тот функционал, который теперь, спустя восемь лет работы компании «Аванпост» на рынке IDM, объективно воспринимается специалистами по информационной безопасности как свой. И сейчас примерно половина заходов «Аванпост» к заказчикам происходит через службы ИБ, хотя вторая половина – через службы ИТ.

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

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

Какова принципиальная роль IDM в обеспечении информационной безопасности организаций, вступивших на путь цифровой трансформации производственных и бизнес-процессов?

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

Ведь одной из задач цифровой трансформации является повышение эффективности бизнеса. А эффективность подразумевает скорость (это один из параметров эффективности), в том числе скорость реагирования на изменения. Цифровая компания должна быстро перестраиваться под меняющиеся условия рынка, быстро адаптировать свою деятельность и продукты, предлагать новые товары и услуги. А их обычно создают новые команды. И вот тут остро проявляется потребность в динамическом распределении прав доступа, но с соблюдением требований информационно безопасности. Формально можно открыть доступ ко всем ресурсам для всех сотрудников, включая новых. С точки зрения доступа это абсолютное удобство – любая информация доступна всем. Но это и полное несоответствие требованиям безопасности. Обратная ситуация: закрыт доступ везде и всем – безопасность полная, но большое неудобство в работе. Нормальная ситуация – это компромисс между двумя этими подходами. Нельзя допускать перегибов. Безопасность должна быть обеспечена, но не в ущерб скорости и удобству использования информационных ресурсов. Так вот IDM, как средство автоматизации процесса управления доступом, помогает сбалансировать скорость изменений в цифровой компании и ограничения, продиктованные соображениями безопасности.

К сожалению, пока уровень проникновения IDM даже в крупном российском бизнесе гораздо ниже, чем на западе. По ощущениям, за рубежом 95% компаний с числом сотрудников более 10 тыс. человек имеют внедренную систему IDM в том или ином виде. В России этот показатель наверняка меньше 50%. Может быть 30 или 40%, точных оценок нет.

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

Какие нюансы необходимо учитывать при внедрении IDM? В чем сложность внедрения таких систем?

Первое, что нужно учесть: IDM – это все-таки не классическая информационная система типа «включил и забыл». IDM – это система управления процессом. Наделение сотрудников правами доступа, определение ролей, периодическое их обновление, порядок действий по согласованию ролей – все это должно появиться в организации в виде процесса. Бывает, что такой процесс неплохо выстроен в компании, но без средств автоматизации. В этом случае внедрение системы упрощается: то, что раньше бытовало на уровне служебных записок, переходит на уровень информационной системы. Но сначала данный процесс действительно нужно выстроить, договориться о правилах игры.

Сложный момент (особенно в крупной компании) – создание первичной ролевой модели. Это было камнем преткновения при внедрении IDM лет восемь-десять назад. Тогда рынок IDM контролировали большие зарубежные компании: IBM, Oracle и другие. Они предлагали заказчику понятный им классический путь, когда в рамках проекта внедрения выделялась большая консалтинговая зона. К заказчику высаживался десант консультантов, которые общались со всеми людьми в подразделениях заказчика, выясняли какие права доступа им нужны. Вся эта информация обобщалась, а потом выносилась на утверждение. И вот тут начинались проблемы.

Прежде всего, руководство организации впервые знакомилось с реальным распределением прав – кто, и к каким ресурсам у них, оказывается, имеет доступ. И обычно это был шок для руководства, которое естественно сразу же требовало многое поменять, оптимизировать. Желание оптимизировать бизнес-процесс на ходу – классическая ошибка при внедрении IDM. Потому что велик риск упустить из виду огромное количество особенностей, которые потом болезненно проявятся. Типичный пример: руководство после первичного сбора информации увидело, что у них работает 300 торговых представителей, которые выставляют счета клиентам за различные товары. И все эти 300 человек имеют доступ к бухгалтерской системе, потому что они сами в ней готовят счета для контрагентов. При этом в этой же системе ведется основная бухгалтерия компании. А текучка кадров среди торговых представителей – высокая. Такое положение руководству не понравилось – небезопасно. И оно решило поменять процесс: пусть торговые представители пишут заявки в бухгалтерию, а там уже для них формируются счета. Логично. Но никто не учел, что бухгалтеров всего пять человек, и они физически не в состоянии обработать такой поток заявок. Пришлось все отыграть назад. Эта ситуация иллюстрирует ошибку, когда руководство с лету пытается оптимизировать что-то, не оценив сопутствующие риски. Какой здесь может быть выход? Нужно уже в начале внедрения проанализировать и согласовать требуемые изменения в бизнес-модели. Однако согласования такого рода занимают много времени, и это ведет к задержке проекта внедрения IDM. А самая большая беда в том, что ролевая модель сама по себе – структура очень живая, постоянно меняющаяся. И если модель согласовывали, например, полгода, то еще через полгода она потеряет актуальность, поскольку за это время очень многое в компании поменяется.

Стало понятно, что создание ролевой модели до этапа самого внедрения – эта консалтинговая подготовка – путь в никуда, он вообще не работает. И, как показала практика, этот этап можно обойти. Возникла иная парадигма.

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

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

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

Ресертификацию можно проводить последовательно по подразделениям – не обязательно сразу во всей компании. И пока происходит ресертификация одного подразделения, все остальные спокойно работают.

Есть и более передовые технологии (реализованные в концепции Identity Governance and Administration, IGA), которые предусматривают сочетание ресертификации с управлением рисками. В данном случае каждому праву доступа присваивается определенный коэффициент риска. И сотруднику, имеющему доступ к некоторому числу информационных систем, присваивается свой коэффициент риска для компании. Просуммировав оценки для отдельно взятых прав, мы получаем совокупный риск на данного сотрудника. Далее мы можем определить уровень риска, выше которого подниматься нежелательно. И если у кого-то уровень риска превышает предельный уровень, нужно пристально посмотреть на его набор ролей: может быть, ему какие-то права не нужны, тогда их можно изъять и понизить для него уровень риска.

Также нужно учитывать, что возможны критические пересечения, при которых одному и тому же сотруднику предоставляются права, противоречащие друг другу. Этого нельзя допускать. Наиболее показательный пример: в банке есть специалист (операционист) с правами оформления платежного поручения, и есть контролер, который должен подтвердить этот платеж. Эти роли разделены, чтобы работало правило «двух рук», при соблюдении которого никто единолично не смог бы отправить какую-то сумму на сторону. Один сотрудник должен оформить платежку, а другой подтвердить, что согласен с ее отправкой. Однако при распределении ролей без IDM случается, что на одном сотруднике сойдутся и право инициации транзакции, и ее одобрение. IDM же такого не допустит. Система сможет своевременно выявить критические пересечения. Можно даже задать жесткое правило, запрещающее такое критическое пересечение ролей. Если же это избыточное право кому-то делегируется, то осознанно, с учетом всех сопутствующих рисков. А привилегированный сотрудник уже несет полную ответственность за все последствия возможных инцидентов. У него это прописано в договоре. Риск злоупотреблений при этом гораздо ниже.

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

Большинство российских компаний, внедривших у себя системы IDM, ограничиваются их базовым функционалом. А управление рисками, выявление критических пересечений, аналитика – это все для 90% компаний воспринимается как дополнительный и необязательный функционал. Они говорят: хорошо, что это есть, но мы еще не пробовали.

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

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

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

Эти три базовых функциональных элемента наиболее востребованы.

Как обеспечить эффективное сопряжение систем IDM с другими управляющими системами ИБ, такими как SIEM, Authentication Management Systems и др.?

Думаю, из всех классических систем безопасности лишь SIEM может иметь ценность сопряжения с IDM. Ведь SIEM – это система, анализирующая события, происходящие в инфраструктуре. И для нее можно задать определенную комбинацию событий, которая станет поводом для тревоги и инициации каких-то действий в IDM. Например, с помощью SIEM, интегрированной с IDM, можно проанализировать необычное поведение пользователей. Положим, у сотрудника есть права доступа к десяти ИТ-системам. Восемь из них он использует всегда, а два – никогда. И вдруг возникает аномальная активность. Это может быть поводом, чтобы присмотреться к действиям такого сотрудника и ограничить его права. Но возможен и другой вариант, когда IDM выступает управляющей системой доступа к SIEM. Классически внедренная система IDM управляет доступом во все системы компании. Несколько экзотически реализуется лишь интеграция IDM с кадровой системой. Здесь IDM с одной стороны управляет правами доступа сотрудников отдела персонала, но при этом кадровая система является для IDM источником данных о сотрудниках организации.

Насчет систем аутентификации – тут скорее некоторая конкуренция. Authentication Management Systems может выступать заменителем системы управления доступом, где ее нет. Но возможны и разные варианты сосуществования с IDM. Я видел разные конфигурации, когда IDM управляла доступом к одним прикладным системам организации, а доступ к другим (например, к ERP) регламентировался средствами AMS. Многое зависит от специфики компании и постановки задач.

Есть ли особенности применения систем IDM на объектах КИИ? В чем они заключаются?

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

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

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

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

Первое. По мере цифровизации экономики будет очень сильно увеличиваться глубина проникновения средств IDM, то есть через 10-15 лет отсутствие системы управления доступом будет восприниматься как аномалия.

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

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

Четвертое. С распространением Интернета вещей проявится потребность предоставить учетные записи умным устройствам. Управление технологическими учетными записями – это тот функционал, который мы уже сейчас реализуем в IDM. У некоторых вендоров это уже реализовано, и многие работают в данном направлении.

Наконец, в системах IDM могут быть использованы «Большие данные» и искусственный интеллект – они могут помочь в процессах интеллектуального формирования ролевых моделей, в оценке поведения пользователей и так далее. То есть решение ряда сложных вопросов организационного порядка в будущем смогут взять на себя интеллектуальные системы, встроенные в решения управления доступом.
Чем опасны процессорные уязвимости. Часть 2: Спекулятивные атаки Как продолжить построение системы безопасности КИИ в условиях удаленной работы