Консалтинг в IdM: намечаем дорожную карту31.01.2023 17:15

Что такое консалтинг в широком смысле, знает почти каждый: проконсультировать заказчика, чтобы решить его задачи, которые он сам решить не в состоянии. Да-да: «Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник». Вполне логично, что у компании, работающей в определенной отрасли, часто возникают сложности при попытках разобраться в сути проблем в той сфере, в которой она не специализируется. О том, зачем нужен консалтинг в управлении доступом и как он помогает решить проблемы доступа в организациях, рассказывают руководитель направления консалтинга департамента inRights Максим Мордачев и заместитель директора департамента inRights Илья Антонов.

Задачи управления доступом

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

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

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

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

Откуда берутся проблемы

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

Как учат лучшие практики — процесс есть, когда он описан, согласован и соблюдается. Для описания процессов есть специальные языки/нотации BPMN (Business Process Model and Notation), EPC (Event-driven Process Chain) или IDEF0 (Integrated DEFinition). А если процессы не описаны, то они могут пониматься каждым участником по-своему.

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

Необходимость выстраивать в компании процессы управления доступом давно признана на организационном уровне. Соответственно, в фреймворках ИТ — например, в таких, как COBIT (Control Objectives for Information Related Technology) и ITIL (IT Infrastructure Library)— есть описанные процессы, связанные с управлением доступом; так же, как и в стандартах ИБ весомая часть процессов имеет непосредственное отношение к управлению правами доступа. Еще одним драйвером налаживания процессов служит риск возникновения инцидентов ИБ.

В отчете центра противодействия кибератакам Solar JSOC по атакам за первую половину 2022 г. к тематике управления доступом можно отнести 23% событий ИБ с подозрением на инцидент. Но событие ИБ — это еще не инцидент, к инцидентам рассматриваемой тематики относятся порядка 15% зафиксированных событий. То есть тема, безусловно, требует внимания, и при этом она непростая.

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

Аналогично и с правами доступа. У каждого права есть критичность. Права могут входить в бизнес-роли. Между правами доступа могут быть конфликты. Плюс эти права необходимо периодически аудировать и актуализировать.

Каждый из объектов живет по своему жизненному циклу. Учетные записи кто-то создает, кто-то использует в работе, кто-то обновляет, кто-то выводит из эксплуатации. Как и права доступа — их тоже кто-то создает, кто-то с ними работает, обновляет, удаляет.

И у каждого этого процесса должны быть исполнители: его кто-то должен инициировать, кто-то выполнять, кто-то контролировать, кто-то корректировать.

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

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

Казалось бы, при чем здесь психология?

Посмотрим на примеры в процессах управления доступом, согласно классификации ментальных ловушек, приведенной доктором психологических наук Андре Кукла.

Ловушка вычеркивания — когда мы что-то неосознанно не замечаем, просто не догадываемся о существовании некоторых процессов. Например, в компании должен быть куратор, который отвечает за внешних сотрудников и их учетные записи (УЗ). При увольнении старого куратора внешних УЗ и назначении нового должен ли новый куратор согласовать свое назначение? Что вообще такое «куратор внешнего сотрудника», что он должен делать как куратор? Делает ли он то, что должен? Кто это контролирует? А ведь внешние пользователи зарегистрированы в IdM, ходят через PAM и имеют возможность выкладывать файлы в неструктурированные хранилища. Кто за этим следит и следит ли? Искусственный интеллект? SOC?

Пример: на одном из проектов процесс ведения внешних пользователей выстраивался больше двух месяцев, и срок реализации проекта подходил к концу. В результате проект не вписался в сроки, что было критичным не только для исполнителя, но и для заказчика. У многих проекты внедрения включаются в KPI и завязаны на выделение бюджетов, поэтому переносы «на потом» сказываются негативно. Да и команды заняты как со стороны исполнителя, так и со стороны заказчика на весь срок проекта, а это тоже деньги.

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

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

Противоречия при внедрении IdM

Обычно проблемы вызваны совокупностью противоречий. Например, поиск точки уместности между избыточностью и недостаточностью: с одной стороны, можно в ТЗ написать в одну строчку требование «система должна управлять учетными записями внешних пользователей» и уйти в проект с заведомо слабо прогнозируемыми сроками и с соответствующими последствиями. С другой стороны, поступить, как в следующем кейсе: в одном из проектов месяца четыре или больше прорабатывались детальные требования к процессу, он согласовывался, выстраивался. При этом можно было запустить контракт без данного процесса, обработать/загрузить «учетки» внутренних работников, автоматизировать базовые процессы, получить результат и как раз месяца через четыре-шесть запустить проект развития. Для выработки решений можно было использовать ТОС (Theory of Constraints — теория ограничений) и ТРИЗ (Теория решения изобретательских задач), а для внедрения технологии управления проектами в числе применяемых методологий Scrum (Фреймворк для управления проектами).

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

Линейность и разветвленность или скорее однообразие и разнообразие хорошо показать на примере корпораций, которые состоят из нескольких относительно самостоятельных блоков, иногда даже разнесенных территориально, в каждом из которых есть хранилище файлов. В одних хранилище напоминает оргштатную структуру, в других основано на разделении производственных функций. В одних доступ предоставляется выполнением bash-скриптов, в других — администраторами, в третьих — через группы безопасности, где-то, не дай бог, на samba мигрируют. Автоматизация такой разрозненной структуры обычно вызывает ряд затруднений и множество согласований, опять же — сроки, затраты, бюджеты, KPI. Проблема далеко не единичная.

Если говорить про очевидность и условность, тут хорошим кейсом будет построение оргштатной структуры компании. Многие крупные компании состоят из совокупности разрозненных юридических лиц, которые логически объединены в одну структуру, то есть юридическая структура — максимально очевидная и логическая, часто ее называют управленческая оргштатная структура. С одной стороны, очевидно, что согласовывать доступ должен линейный руководитель, он юридически может быть привлечен к ответственности. А с другой стороны, случается, что линейный руководитель за несколько лет ни разу не видит своего подчиненного и на самом деле не представляет или представляет очень приблизительно его круг обязанностей.

И ведь таких примеров можно привести массу. В каждом новом проекте появляются новые кейсы, и возникают они, в основном, по двум причинам.

Первая — технологически растут требования, нужна интеграция с системами мониторинга, с порталами самообслуживания. Это все достаточно свежие потребности на рынке.

Вторая — процессы в компаниях взаимно пересекаются и тем самым дают новые варианты комбинаций.

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

Нельзя или скорее не стоит относить системы IdM (Identity Management) или PAM (Privilege Identity Management), или DAG (Data Access Governance) только к системам класса ИБ. Этот класс систем используется также и подразделением ИТ, и со стороны операционных процессов от бизнеса к ним тоже могут предъявляться требования. Соответственно процессы и требования, их выявление и объединение, а также их согласование является неотъемлемой частью внедрения систем. И от того, с каким качеством будут проработаны эти процессы, напрямую зависит успех всего мероприятия.

Чем и как поможет IdM-консалтинг

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

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

1. Аудит

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

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

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

2. Подготовка организационных изменений

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

Представьте, что руководителю службы ИБ выделили бюджет на внедрение IdM, но он не всегда представляет, как устроены процессы в других подразделениях, каким образом увязать их с процессами управления доступом и IdM. А ведь чтобы безопасность была реальной, а не бумажной, работать по новым правилам будут все сотрудники, использующие IdM. А они готовы? Знают, что им придется делать?

Подобные проекты называются организационными изменениями. Представлю их в виде метафоры.

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

Риски связаны в первую очередь с сопротивлением сотрудников: люди боятся изменений, и в целом это нормально. Если сотрудники не представляют, как нововведения на них повлияют, они 100% будут сопротивляться. В нашей практике часто происходило сопротивление исполнителей работе в новой информационной системе. Оно продолжалось до тех пор, пока коллеги не почувствовали, что новая система облегчает их работу. В этой точке они «ломаются» и становятся уже вашими союзниками. Например, было внедрение одной из систем BPM, которая отвечает за управление исполняемыми бизнес-процессами в компании. Ее год настраивали, сотрудники привыкали к ней, а сейчас уже не представляют, как без нее работать.

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

3. Дорожная карта

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

Представьте: к вам приходит генеральный директор и просит рассказать, как идут дела по проекту внедрения, на который мы выделили Х млн. руб. Показывать ему диаграмму Ганта с техническими вехами и задачами бесполезно, для него это совсем не информативно и непонятно. Если вы ему покажете, кто в каком отделе какие результаты должен получить и к какому сроку, ему сразу будет ясно, кто и что должен сделать в компании и с кого можно спросить за результат.

На карте отображено, для чего мы внедряем те или иные решения на каждом уровне компании — какие решаем проблемы, что сейчас происходит в проекте. Например, ИТ должен развернуть систему к 30.09. Отдел обучения — закончить курс подготовки сотрудников к работе в новой ИС к 10.10. и так далее. И держать ответ перед руководством за тот или иной этап будут не только организаторы проекта, но и те руководители, на кого возложена ответственность за результаты проекта в своих отделах. Всем участникам проекта будет легко отследить, движемся мы или не движемся по плану. Если отклоняемся, то понимаем, с кого спрашивать. Все наглядно, просто и понятно.

Выводы

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

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

Будет разработана соответствующая методологическая база, которая учитывает все актуальные требования, как внутренние, так внешние регуляторные.

Ну, и возвращаясь к тому, о чем говорили в начале: не будет таких ситуаций, когда проект стартовал и его через какое-то время закрыли как не успешный. Затраты будут оправданы, рабочие места сохранены, будут внедрены необходимые решения по автоматизации процессов, компетенции сотрудников вырастут, что позволит далее расширять и масштабировать процессы с использованием новых передовых технологий. ■ Токен: Pb3XmBtzt7sGqwjqpM39Rb5j8WsK1A18sJqVZyaРекламодатель: ООО «РТК ИБ»ИНН/ОГРН: 7704356648/1167746458065Сайт: http://www.rt-solar.ru

Полный текст статьи читайте на CNews