idm системы что это такое

Что скрывает IdM: функциональное сравнение IdM-решений

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

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

Мы не ставили себе целью охватить всех вендоров, представленных на российском рынке, и рассматривали только тех из них, которые являются наиболее показательными. А именно: Oracle, IBM и Microsoft – решения, которые существуют на нашем рынке уже более 7 лет, имеют свою аудиторию, и на чью долю приходится основная часть всех внедрений. И, чтобы показать, куда движутся технологии IdM, SailPoint – новое на нашем рынке решение, получившее наивысшие оценки западных аналитиков.

Критерии сравнения взяты из реальных проектов. Мы собрали данные по 20 проектам внедрения IdM в российских компаниях и выделили все основные функциональные требования, которые в этих проектах встречались. Численность компаний, попавших в выборку, составляет от 1500 до 70 000 сотрудников. В ней представлены как локальные московские компании, так и компании, географически распределенные по территории России.

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

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

Для удобства таблица сравнения представлена несколькими спойлерами:

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

Источник

Identity Management — основы управления учетными записями

Сегодня мы начнем разговор о системах класса Identity Management. Как многие из вас знают, 1 июля закончился срок действия отсрочки вступления в силу федерального закона РФ от 27 июля 2006 года № 152-ФЗ «О персональных данных»

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

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

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

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

Я искренне надеюсь, что после прочтения данного материала у коллег прибавится ясности по данному вопросу, и многие программисты или системные администраторы смогут перейти в лагерь бизнес-аналитиков по IDM, чтобы составить достойную конкуренцию тем немногим работающим в этой области «звездам».

Что такое Identity Management?

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

Где хранится персональная информация о сотрудниках компании? Разумеется, в кадровой системе. А еще – в каталоге Active Directory, в карточках пользователей нескольких десятков прикладных систем, в данных почтовых программ, в системах управления клиентами, в биллинговых системах, в системах сервис-деск… Зачастую эта информация не согласованна. Один и тот же человек может быть прописан в десятке систем одновременно, и никто не даст гарантии, что он прописан в них одинаково и корректно.

Одна из основных задач IDM – создание единого и актуального каталога персональной информации как основы для дальнейшего развития процессов управления.

IDM, IAM, RM — WTF?

Учетные записи пользователя и их атрибуты (например, группы доступа) являются такой же частью персональной информации, как и почтовые адреса, имена и должности. Специалисты по Active Directory подтвердят, что это все хранится в системной базе данных сходным образом. Соответственно, логично было бы включить в рамки процесса IDM заодно и управление доступом к информационным системам (Access Management). Часто под IDM как раз и понимается Identity and Access Management (IAM), просто аббревиатура IDM людям нравится больше.

Результаты успешного внедрения IDM можно разделить на «статические» и «динамические». Первые – это результаты «что же стало?». А вторые «И как же это работает?»

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

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

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

Еще более сложный случай – когда в компании действуют внутренние проекты или иная нерегулярная деятельность, требующая временных группировок сотрудников по тем или иным признакам. Например, внедряется ERP система, и все участники рабочей группы получают временный доступ к тестовой площадке. Или в компании идет работа над новым шаблоном презентации, и ключевых сотрудников допустили на портал службы маркетинга для оценки дизайнерских макетов. Да мало ли что еще может быть! Дать необходимые полномочия в подобной ситуации еще полдела. Попробуйте правильно и вовремя их отозвать! В 90% компаний полномочия никогда у пользователей не отзываются. Давно работающие сотрудники постепенно обрастают доступами, словно корабли ракушками. Через два-три года никто толком не может сказать, откуда у них такое количество привилегий. Если сами учетные записи еще хоть как-то контролируются прикладными администраторами по количеству и предполагаемым владельцам, то в рамках одной учетной записи сам черт ногу сломит.

Чтобы разобраться во всем этом, как вы понимаете, нужно проделать серьезную работу. В ручном режиме управиться можно при небольшом количестве систем и железной дисциплине. Но если сущностей становится слишком много для обычного человека, приходится думать об автоматизации процесса и о применении элементов ролевого управления доступом (Role Management). RM – это сейчас крайне модное и популярное направление в сфере middleware. Для стороннего наблюдателя стоит оно немыслимых денег и непонятно чего делает. Системы этого класса предлагают наперебой ведущие гиганты софтостроения, такие как Oracle (он же Sun), IBM, Microsoft. Множество копий сломано в бессмысленных спорах о преимуществах той или иной платформы. По опыту могу сказать, что все системы будут одинаково бестолковыми, если мы не уделим должного внимания наведению порядка в бизнес-процессах.

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

В случае внедрения IDM не нужно, как у нас принято, сразу же кидаться ставить софт в надежде на то, что телега вытянет за собой лошадь. Чуда, как обычно, не произойдет, а дров наломаете на годы вперед. Ведь системы IDM внедряются в самое «наше все» системных администраторов — в аутентификацию пользователей. Упавший IDM может парализовать работу всей компании. Криво настроенный движок приведет к тому, что прежний «геморрой» с прописыванием нового пользователя вручную покажется админам доброй сказкой. Стоит ли говорить, как все вокруг воспримут после этого вас и вашу систему.

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

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

Получается, что сотрудники отделов информационной безопасности сидят на мине замедленного действия, так как они не знают ответа на элементарный вопрос аудитора: «Кто и на каком основании имеет доступ к той или иной системе?» А то, что с этим вопросом им придется встречаться все чаще и чаще, есть установленный наукой факт. Ответить же на него в любой момент времени (а не только после месяца ручной выверки привилегий) помогут системы класса IDM с дополнительной функциональностью ролевого управления доступом.

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

Источник

IdM/IGA система: что это такое, как работает и зачем нужно

IdM (Identity Management) или IGA (Identity Governance&Administration) решение обеспечивает централизованное управление правами доступа и учетными записями пользователей в различных информационных системах /приложениях, используемых компанией для работы. С его помощью:

· Снижается нагрузка на системных администраторов. Работа с учетными записями (создание новых, временная блокировка, изменение прав доступа, удаление) занимает немалую часть времени сисадмина. Чем больше в компании решений, в которых есть учетные записи, тем больше временные затраты. Организовав централизованное управление ими через IdM, вы существенно снизите загрузку системного администратора.

· Минимизируются риски информационной безопасности. Автоматизированное централизованное управление правами доступа со своевременными оповещениями существенно уменьшает вероятность возникновения инцидентов информационной безопасности, связанных с избыточными правами доступа.

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

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

· Уменьшаются затраты на поддержку IT-инфраструктур. Вы сможете контролировать количество активных учетных записей и своевременно отключать неактивные, чтобы не платить за них (при использовании модели оплаты за каждую «учетку»).

Кроме того, Identity Management позволит компании выполнить ряд требований и рекомендаций руководящих документов / регуляторов. Например, таких как БР ИББС, PCI DSS или ISO 27001.

Как и в каких системах организуется централизованное управление учетными записями с помощью IdM/IGA

Решение класса Identity Management или Identity Governance&Administration может управлять учетными записями в различных информационных системах и программах. Например, наша IdM/IGA Solar inRights совместима с:

· C популярными системами и инфраструктурами, в том числе построенными на базе SAP и 1C.

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

· Программами для электронного документооборота, CRM, ERP, почтовыми системами, организации кадрового учета и другими решениями с собственным API и без.

При отсутствии API интеграция с целевой системой возможна посредствам выгрузок в файл (например, Solar inRights поддерживает выгрузку excel, csv или xml).

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

Работа IdM/IGA в комплексе с другими системами обеспечения информационный безопасности

IdM, как правило, не используются отдельно. Это — эффективные составляющие системы информационной безопасности компании, которые могут интегрироваться с другими решениями.

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

Интегрировав Identity Management или Identity Governance&Administration систему с SIEM, вы обеспечите защиту от несанкционированного добавления или изменения учетных записей. Злоумышленник может попытаться сделать это в обход Service Desk, совершив необходимые манипуляции прямо в целевой системе. IdM выявляет такие события и формирует оповещения для SIEM-системы. Это значительно ускоряет процесс выявления подобных инцидентов. Ведь без Identity Governance&Administration-решения в SIEM поступают только логи, которые еще нужно обработать, на что уходит время (а его при действиях злоумышленников может и не быть).

Кроме того, современные решения класса IdM/IGA могут интегрироваться и с другими элементами ИБ. Например, с ITSM, инфраструктурами открытых ключей (PKI), решениями, использующими SSO (технологию единого входа).

Взаимодействие с целевыми информационными системами (CRM, ERP, кадровыми и так далее) и другими элементами, обеспечивающими информационную безопасность компании, организуется посредствам коннекторов. Это — специальные программные компоненты, которые включаются в IdM «из коробки». В зависимости от того, с чем взаимодействует решение, коннекторы могут использовать API целевой системы, запросы, хранимые процедуры, выгрузки в файл другие средства. Если у вас в компании используется какой-то специфический программный продукт, для которого нет коннектора «из коробки», это не проблема. Например, мы в Solar inRights кастомизируем предлагаемое решение под нужды заказчика и при необходимости дорабатываем уже имеющиеся коннекторы или, в течение пары недель, создаем их с нуля под конкретный продукт. Все обсуждаемо. Поддержка стандарта Identity Connector Framework (ICF) без необходимости использования дополнительных адаптеров существенно облегчает процесс разработки коннектора и снижает сроки и ресурсы для интеграции с системой.

Кому стоит подумать об использовании IdM/IGA

Такое решение необходимо далеко не любой компании. Подумать о его внедрении есть смысл если:

· системным администраторам и другим специалистам приходится обрабатывать большие потоки заявок на предоставление доступа, создание и изменение учетных записей в разных системах;

· есть предпосылки к возникновению инцидентов, связанных с чрезмерным доступом и избыточными правами, или наоборот — с недостаточными полномочиями;

· при большой текучке кадров и активной ротации сотрудников;

· при использовании в компании большого количества различных IT-решений с возможностями управления правами доступа.

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

Источник