Поделиться
IdM с человеческим лицом, или как эволюционируют системы управления правами доступа
Внедрение IdM-решений требует кастомизации под заказчика, последующего сопровождения и развития. Сильно кастомизированную систему почти всегда сложно и дорого поддерживать. Создатели системы Solar inRights захотели переломить сложившуюся ситуацию. Об этом в своей статье для CNews рассказывает Дмитрий Бондарь, руководитель направления Solar inRights компании Solar Security.
Говоря о развитии IdM-систем, прежде всего надо сказать, что на международном рынке само понятие Identity Management практически вытеснено термином Identity Governance & Administration (IGA). По оценке Gartner, рынок IGA за 2016 вырос на 12% и уже находится на том уровне зрелости, когда вендоры начинают стремиться в облака и предлагать IGA-решения как сервис.
Разница между IdM и IGA состоит и в подходе к решению задач, и в их объеме: если основной задачей IdM является корректное предоставление прав доступа к ИТ-системам, то IGA-продукты обеспечивают управление жизненным циклом пользователей и ролей, управление заявками, пересмотр полномочий сотрудников, аудит, отчетность и аналитику по правам доступа сотрудников. В рамках такого подхода в центре внимания находится человек и его деятельность, а не корпоративные системы. Задачей IGA-решений является такое управление пользователями в ИТ-ландшафте, которое соответствует существующим в компании бизнес-процессам и бизнес-задачам. Важную роль здесь играет анализ действий сотрудников. Поэтому в качестве одного из наиболее перспективных направлений развития IGA-решений Gartner называет интеграцию с решениями по анализу действий пользователей – User and Entity Behavior Analytics (UEBA).
Эта технологическая ниша действительно кажется очень интересной в свете возможностей, которые она предоставляет для контроля поведения пользователей и предотвращения нарушений, связанных с избыточным или полученным в обход политик согласования доступом. Выявлять такого рода угрозы можно, проводя регулярные аудиты, но технологии UEBA могут справляться с этой задачей гораздо эффективнее. IdM-решения имеют в распоряжении информацию о полномочиях сотрудников в ИТ-инфраструктуре и историю их изменения.
Технологии UEBA позволяют строить профили нормальной рабочей активности сотрудников. Анализируя профили поведения сотрудников с учетом имеющейся картины полномочий, можно выявлять аномалии. Анализируя их и отличая правильные паттерны поведения от потенциально опасных, удастся снизить число конфликтов разделения полномочий и прочих злоупотреблений. А в перспективе решение сможет обучаться и в автоматическом режиме идентифицировать нарушителей и отзывать права доступа, не дожидаясь компрометации учетных записей и критичных данных.
Российский рынок следует за мировыми трендами, но пока с большим опозданием. Причина этого как в инертности российских компаний, так и в незрелости самих IdM-решений.
Долго, дорого и плохо
IdM находятся на стыке ИТ и ИБ и отражают общий уровень зрелости корпоративных систем. Когда российские IdM только начали появляться, они унаследовали все проблемы ИТ-систем корпоративного уровня. IdM-решения были громоздкими и неудобными, а главное – навязывали свои правила и подходы вместо того, чтобы подстраиваться под заказчика.
Однако если многие B2B-решения доросли до таких понятий, как гибкость, интуитивно понятный интерфейс и удобство взаимодействия с системой, в мире IdM мало что изменилось. Основными проблемами систем Identity Management остаются длительный срок внедрения, высокая стоимость сопровождения и обновления системы.
В других сегментах производители корпоративных систем начали делать свои продукты не только функциональными и надежными, но и удобными, понятными, красивыми, наконец. Однако для IdM-решений понятия «интуитивно понятный интерфейс», «юзабилити» и «гибкость» все еще остаются чем-то вроде концепт-кара в автомобильной отрасли: идея выглядит отлично, но к промышленному производству отношения не имеет.
Внедрение IdM включает в себя автоматизацию процессов управления доступом компании. Эти процессы хотя и схожи в общих чертах, тем не менее, в каждой компании имеют большое число уникальных особенностей. Логично, что каждый раз IdM требуется кастомизировать под заказчика, что для большинства решений означает доработку кода. В результате мы получаем множество проектов внедрения IdM, растянувшихся на несколько лет.
Но вот, наконец, внедрение завершено. Теперь IdM-решение, как и любую другую информационную систему, надо сопровождать и развивать. Сильно кастомизированную систему почти всегда сложно и дорого поддерживать. Она содержит множество нетипового кода, в котором ориентируются только люди, которые его написали. Результатом становится практически крепостная зависимость клиента от интегратора, который внедрял и дорабатывал систему. Казалось бы, это хорошая новость для системных интеграторов, но тут тоже все не так просто. Договор поддержки, который клиент заключает с интегратором, предполагает SLA или соглашение об уровне сервиса, включающее в себя фиксированное время по обработке обращений и исправлению ошибок. И если конкретный человек, который дорабатывал IdM-систему у клиента, уходит из компании-интегратора, у нее моментально возникают проблемы с исполнением SLA.
Обновить кастомизированную систему тоже не так просто. Кастомизация, достигнутая через изменения в коде, всегда зависит от внутренних особенностей продукта. При выходе новых версий эти внутренние особенности нередко меняются – скажем, система переходит на новый движок графических инструментов. Соответственно, при обновлении системы IdM всю кастомизацию приходится делать с нуля, заново пытаясь найти пути ее реализации. В итоге стоимость и длительность обновления кастомизированной системы IdM, как правило, сопоставима с изначальным внедрением. Поэтому-то на рынке так много организаций, которые вынуждены использовать устаревший IdM.
Когда мы создавали Solar inRights, мы хорошо представляли себе сложившуюся ситуацию и хотели ее изменить. В результате важнейшей конструктивной особенностью нашей системы стала конфигурируемая структура исполнения. Благодаря ей конфигурацию системы можно изменять в режиме онлайн. Все основные структуры, процессы и объекты можно редактировать непосредственно через графический интерфейс. Это позволяет вносить изменения практически во все аспекты работы решения без программирования, компилирования и перезапуска системы. Эти особенности платформы Solar inRights позволяют внедрять и кастомизировать систему под заказчика с минимумом стороннего программирования, что сразу снимает многие последующие проблемы. В дополнение к этому Solar inRights имеет уникальную систему расширений (по типу plug-ins). Они позволяют добавлять в систему новую функциональность (формы, объекты, процессы и т.п.), которая сохраняется при обновлении системы.
Изменения в работу решения можно внести в любой момент (в том числе силами специалистов заказчика), не дожидаясь технологических окон для ее остановки. Это очень важно, потому что если у компании есть региональные офисы, то IdM работает 24/7. «Окно», когда можно остановить систему и установить обновления, появляется раз в квартал или даже раз в полгода. А с Solar inRights это можно делать без остановки системы и, следовательно, не влияя на непрерывность бизнеса. Соответственно и обновляется система без потери имеющихся настроек.
Дополняют картину простота масштабирования и мультиплатформенность нашей системы. Чтобы обеспечить работу Solar inRights для десятков тысяч сотрудников, требуется лишь пара серверов средней конфигурации для обработки пользовательских запросов, пара серверов для исполнения технологических задач и процессов и кластер СУБД. Причем серверы, которые обрабатывают запросы пользователей и исполняют технологические задачи, являются практически stateless. То есть при выходе любого из них из строя потеряются максимум текущие сессии пользователей.
Solar inRights работает на большинстве распространенных ОС и СУБД. В качестве операционных систем поддерживаются Windows Server, RHEL, CentOS, Astra Linux. В качестве СУБД Oracle DB, MS SQL Server, PostgreSQL. Такая широкая вариативность – тоже часть нашей стратегии по созданию удобной IdM. Заказчики могут выбрать для развертывания системы наиболее подходящую платформу – ту, по которой есть специалисты, или ту, которая снизит совокупную стоимость владения системой.
Королевство кривых зеркал или загадочная логика IdM
Удобство интерфейса, гибкость продукта и продуманная логика взаимодействия с конечным пользователем – это показатели зрелости ИТ-системы. Поэтому мы стремились с самого начала создать такой пользовательский интерфейс, который, с одной стороны, будет удобен ИБ- и ИТ-службам, работающим с Solar inRights каждый день, и, с другой стороны, позволит бизнес-пользователям, которые изредка заходят в систему, подать заявку без посторонней помощи. На мой взгляд, нам это вполне удалось: более чем в 95% случаев люди, работающие с системой, отмечают удобство и лаконичность ее интерфейса. Он был разработан на заказ российской компанией Usethics, которая специализируется на usability. В итоге эргономичный пользовательский интерфейс, который можно настраивать под конкретную организацию, стал лицом Solar inRights.
Отдельная боль пользователей IdM-решений – это системы подачи заявок на доступ. Например, часто решения не позволяют запросить в рамках одной заявки несколько полномочий для разных сотрудников – либо несколько полномочий для одного человека, либо одно полномочие для нескольких людей. При этом заявку, как правило, можно отклонить или согласовать только целиком. То есть если человек запрашивает 10 полномочий, и в одном ему отказывают, приходится отклонять всю заявку целиком. Если дело происходит в корпорации или просто компании с регионально разветвленной структурой, для исполнения заявки может требоваться прохождение множества ступеней согласования. Иногда такой процесс занимает до двух недель. И если заявку целиком отклонили на одном из последних шагов, сотруднику надо заново проходить весь путь и терять время на ожидание согласования.
Многие системы IdM до сих пор не умеют грамотно работать с разбиением заявок. Допустим, в заявке запрашивается доступ двух сотрудников к десяти системам. Что делает большинство IdM-решений в таком случае? Первый вариант – заявка остается монолитной, и руководитель каждого из сотрудников получит ее целиком. Хотя базовая логика подсказывает, что руководитель должен получать запрос только на своего подчиненного. А ведь еще есть владельцы тех десяти ресурсов, к которым запрашивается доступ, и они тоже получат всю заявку целиком. Второй вариант – это подход, при котором любая сложная заявка автоматически разбивается на независимые подзаявки. Результат получается едва ли не хуже. Согласно статистике, собранной с наших проектов внедрения, в среднем в одной заявке запрашиваются 10-20 полномочий для 1-2 человек. Посчитаем: если в заявке есть 2 человека и 20 полномочий, такой запрос будет разбит на 40 подзаявок. Служба ИБ получит 40 оповещений, и каждую из заявок надо будет исполнять отдельно.
Поэтому при создании Solar inRights нашим главным намерением был уход от этой странной и малопонятной логики. В итоге созданная система заявок отражает наш подход к управлению доступом – автоматизировать налаженные бизнес-процессы заказчика, а не навязывать ему свои; упрощать жизнь, а не создавать новые сложности.
Solar inRights позволяет предоставлять права доступа как по мере согласования каждого из полномочий, так и единовременно. Заявки на доступ можно подавать для любого числа сотрудников и любого числа ролей и полномочий. Для каждого шага согласования можно определить таймаут и маршрут эскалации. Они определяют, что будет происходить с заявкой, если по ней не было принято решение в течение определенного времени (например, если ответственный сотрудник заболел). На период запланированного отсутствия (например, отпуска) сотрудники могут назначать себе заместителей.
Маршруты согласования могут быть какими угодно и способны учитывать массу нюансов и тонкостей бизнес-процессов, принятых в компании. Скажем, маршруты могут различаться в зависимости от информационных систем, к которым запрашивается доступ, от регионов и даже отдельных ролей. Это особенно актуально для очень крупных компаний, где для разных дочерних обществ или филиалов используются различные процессы согласования доступа. Маршруты согласования в Solar inRights могут быть последовательными и параллельными. В качестве согласующих лиц можно назначать конкретных сотрудников, контекстные роли (например, руководитель), бизнес-роли (например, офицер информационной безопасности) или использовать скрипты, чтобы автоматически вычислять согласующих по более сложной логике (например, в зависимости от решений на предыдущих шагах или информации из другой системы).
Благодаря этому на базе Solar inRights можно автоматизировать практически любые бизнес-процессы и подходы к предоставлению доступа. По нашему опыту, такая гибкость важна для IdM-решения еще и потому, что в российских компаниях в любых процессах очень много исключений. Поэтому предустановленные шаблоны и западные «лучшие практики» в российских реалиях просто бесполезны.
руководитель направления Solar inRights компании Solar Security
Короткая ссылка
