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. Часть 1: что такое IdM и какая функциональность к нему относится
…Всё началось с отдела маркетинга. Эти милые люди подумали и решили, что нам (специалистам пресейла и сервисов) следует написать некоторое количество статей «на разные интересные темы». Темы они, как водится, придумали сами, исходя из видящихся им «потребностей рынка». (При этом, если взглянуть на них с нашего ракурса, темы были, мягко говоря, «не очень»…)
Нашей команде, отвечающей за развитие системы управления доступом и учётными записями пользователей Solar inRights, пришла в голову идея миссионерства (как бы громко это ни звучало): если уж писать обращение «к граду и миру», то пусть оно будет полезным инструментом для принятия взвешенных решений. Поэтому решено составить целостный цикл материалов, который поможет чётко осознать, какие действия и процедуры сопровождают внедрение IdM-решения.
Постараемся избегать непонятной терминологии и всё пояснять. Если что-то будет непонятно или вызовет вопросы, всегда можете задавать их в комментариях. Мы открыты и для ваших предложений — каким аспектам уделить особое внимание.
На начальном этапе мы видим следующее разбиение по темам:
Часть 1. Что такое IdM?
Разговор об IdM стоит начать с пояснения, что же такое управление учётными записями и правами пользователей и что такое управление доступом.
Давайте разбираться. В первую очередь стоит понять, откуда пошло название класса IdM-решений. Это сокращение от «Identity Management», т.е. «управление учётными данными». Обратимся к Википедии (да, именно к ней, это же первая ссылка в Гугле):
«Управление учётными данными (англ. Identity management, сокр. IdM, иногда IDM) — комплекс подходов, практик, технологий и специальных программных средств для управления учётными данными пользователей, системами контроля и управления доступом (СКУД) с целью повышения безопасности и производительности информационных систем при одновременном снижении затрат, оптимизации времени простоя и сокращения количества повторяющихся задач». (Источник).
Это – выдержка из статьи на русском языке, которая, впрочем, этим абзацем и ограничивается, если не считать ссылок на статьи об идентификации, аутентификации, авторизации и контроле доступа. Определение не настолько плохо, как можно было бы ожидать. На что стоит обратить внимание в приведённом отрывке? Специально выделю для акцента курсивом:
«Управление учётными данными (англ. Identity management, сокр. IdM, иногда IDM) — комплекс подходов, практик, технологий и специальных программных средств для управления учётными данными пользователей, системами контроля и управления доступом (СКУД), с целью повышения безопасности и производительности информационных систем при одновременном снижении затрат, оптимизации времени простоя и сокращения количества повторяющихся задач.»
Т.е. мы видим, что суть управления учётными данными и доступом не сводится просто к какой-то одной системе, которая будет своеобразной кнопкой «сделать, чтобы было хорошо». Это целый комплекс, включающий:
Вспоминается притча о трёх слепых, пытающихся описать слона: один из них подошёл к слону сзади, ощупал хвост и сказал, что слон похож на верёвку; второй подошёл спереди, ощупал хобот и сказал, что слон похож на змею; третий же подошёл сбоку, ощупал ногу и сообщил, что слон напоминает столб или колонну. Суть в том, что каждый в отдельности имел неполные сведения и потому не мог осознать слона как целое, до этого со слоном не сталкиваясь и не имея понятия о том, что он такое.
С IdM похожая история – слишком много различных функций и возможностей, чтобы осознать системно всю полноту. Иногда возникают совсем неожиданные темы, о которых до начала работы с решением никто и не задумывался. Профессионалам ИБ и ИТ важно понимать не только техническую составляющую управления доступом и учётными данными, но и то, каковы потребности в отношении связанных с IdM процессов в каждой конкретной компании. Стоит учитывать, что с каждым годом инфраструктурный ландшафт усложняется, и прежде эффективные методы управления доступом и учётными данными (ручное управление группами доступа, службами каталога, попытки вести ролевые модели на бумаге, профили пользователей и т.д.) оказываются уже не способными соответствовать потребностям бизнеса. Потому со временем они будут заменены современными средствами управления идентификацией, аутентификацией, авторизацией (совокупно – управления доступом) и системами аудита.
Когда начинаем говорить о внедрении какого-то IdM-решения, представители компаний часто с удивлением открывают для себя, что ещё до запуска собственно процесса внедрения нужно во всей полноте понимать:
Общаясь с коллегами, которые уже пережили внедрение IdM-решения, я пыталась выяснить, а что же нового в связи с внедрением и освоением IdM приходилось делать ИТ- и ИБ-специалистам компаний-заказчиков. В ходе бесед выяснилось, что им пришлось пересмотреть подходы к управлению доступом, внести изменения в существующие бизнес-процессы, в ряде информационных систем произошли изменения и т.д.
Всё указанное привожу здесь не для того, чтобы отбить у кого-либо желание связываться с внедрением IdM-решений, а для того, чтобы каждому приблизительно стал понятен фронт работ, и чтобы не было обманутых ожиданий типа: «А мы-то думали, что с внедрением IdM сразу можно расслабиться…».
Внедрение IdM – это история не о том, как инженеры интегратора развернули выбранное вами решение, и «всё сразу стало хорошо».
Это история о том, как в процессе трансформации и роста зрелости сервисов ИТ и ИБ создаётся целая система управления доступом с понятными всем участникам процесса целями и задачами, учётными записями и правами пользователей, которая включает в себя перечень процессов и процедур, физических, технических и административных мер, а также само IdM-решение или IGA-платформу.
О том, как взвешенно и грамотно подойти к созданию такой системы, мы будем рассказывать в серии статей максимально подробно.
В качестве анонса приведу то, о чём расскажем в следующей статье:
Какие задачи решают IAM системы?
Какие задачи решают IAM системы?
Терминология
Чаще всего мы встречаем термин Identity Management (IdM), что означает управление учетными записями или электронными представлениями пользователей. Как правило, от IdM-системы требуется управление не только учетными записями, но и доступом к системам. Поэтому обычно говоря об IdM, подразумевают Identity and Access Management.
Под Identity and Access Management (IAM) понимают набор технологий и программных продуктов, отвечающих задачам управления жизненным циклом учетных записей и управления доступом к различным системам в компании. Аналитические агентства (Gartner, Forrester, KuppingerCole) и разработчики IAM-систем выделяют как минимум две области внутри IAM: User Administration and Provisioning (UAP) и Identity and Access governance (IAG). Современное IAM-решение должно предоставлять функциональность в обеих областях.
UAP-решения появились в конце 1990-х как средства автоматизации работы со службами каталогов. UAP решает задачи автоматизации создания, изменения и удаления учетных записей в информационных системах организации, а также обеспечивает доступ к приложениям и ресурсам, которые нужны пользователю для работы.
Типовые задачи IAM
Задачи UAP
Представим себе процесс организации доступа к IT-ресурсам (приложения, данные, сервисы) в компании без автоматизации. Сотрудника при приеме на работу отдел кадров вносит в 1С. Затем информация о нем попадает в ИТ-отдел. IT-отдел создает учетную запись в службе каталогов Active Directory. Доступ к папкам, приложениям, рассылкам новый работник получает, обратившись к системному администратору или в службу поддержки по электронной почте, в некоторых случаях требуется согласие руководителя или владельца ресурса. При этом сотрудник никогда не просит «отобрать доступ» и за годы работы в компании может «обрасти» доступом в различные системы.
Если в небольшой компании организация доступа решается путем прямых коммуникаций и новичок сможет в течение дня получить доступ ко всему, что требуется для работы, то в географически распределенной компании со штатом более 500 человек на это могут уйти дни.
У сотрудников могут меняться должности, телефонные номера, фамилии, и эти изменения должны отражаться в информационных системах. В некоторых компаниях есть работники по контракту или сезонные работники. При расторжении контракта или смене должности доступ к ресурсам должен быть прекращен.
Если же в компании несколько информационных систем, например система документооборота, бухгалтерская система, внешний портал, появляется задача управления паролями. Каждая система управляется разными людьми. Пароль в каждой системе создается отдельно (т. е. присваиваются персональные пароли). Пользователю сложно запомнить несколько паролей, и это приводит к тому, что они хранятся на бумаге. Если пароль требуется поменять, нужно найти владельца приложения, который может быть в отпуске, а доступ необходим сейчас.
Представим ситуацию, когда сотрудник в командировке решил подключить доступ к почте на мобильный телефон и ошибся при вводе пароля. Его учетная запись будет заблокирована при многократных попытках ввода неправильных данных, и он не сможет самостоятельно получить доступ к почте.
При увольнении сотрудника необходимо заблокировать его доступ ко всем системам компании, иногда важно сделать это в течение минуты.
Такой процесс в масштабах крупной организации отнимает много времени у IT-отдела, неизбежно приводит к ошибкам и, как следствие, финансовым потерям.
Достаточно часто в Интернете можно прочитать о судебных делах, связанных с тем, что у уволенного сотрудника остался доступ к системам предприятия, например:
www.kuzbass85.ru/2012/04/11/uvolennyiy-sistemnyiy-administrator-udalil-chetyirehletniy-arhiv-buhucheta-byivshego-predpriyatiya
Суд установил, что в июле 2011 года Приходько, находясь у себя дома в г. Кемерово, осуществил неправомерный доступ на почтовый сервер предприятия, где он ранее работал. Затем он удалил программу «1С Предприятие» за период с 2007 по 2011 год. В результате данные бухгалтерского учета на серверах трех обществ холдинговой компании, находящихся в г. Прокопьевске, были уничтожены.
О многих подобных случаях мы не узнаем, поскольку банки или страховые компании предпочитают не афишировать подобные инциденты.
Теперь посмотрим, как выглядит автоматизированный процесс.
После появления учетной записи в кадровой системе UAP-решение автоматически создает учетные записи в подключенных системах, выдает доступ на основе атрибутов пользователя (например, должность и отдел) и групп. UAP-система позволяет проверять значения атрибутов на соответствие правилам и запрещать создание «неправильных записей», в частности, с незаполненной должностью. При изменениях достаточно внести их в одном месте – и они автоматически будут отражены во всех подключенных системах. Так, например, пользователь, изменяя пароль в AD, автоматически получает такой же пароль во всех системах. При переводе или увольнении сотрудника система отбирает доступ во всех системах практически мгновенно.
Важно отметить, что UAP изначально были нацелены в большей степени на решение рутинных задач отделов IT по администрированию пользователей и ресурсов. Однако такие решения не предполагались для организации контроля доступа к системам и не были предназначены для не IT-пользователей. То есть UAP-системы автоматически выдавали доступ и отбирали его, но не могли дать ответ на вопрос, к каким ресурсам пользователь имеет доступ сейчас. Также важно было дать пользователям возможность самостоятельно запрашивать доступ к ресурсам (приложения, данные, сервисы), а их руководителям (или владельцам ресурсов) подтверждать правомочность доступа при запросе, организовывать аттестации на предмет проверки, кто имеет доступ к тому или иному ресурсу.
Эти потребности сначала закрывались набором расширенной функциональности UAP-продуктов, но было понятно, что такие задачи требуют новых решений.
Задачи IAG
В середине 2000-х начали появляться специализированные IAG-предложения. IAG-система решает задачи запроса, подтверждения, аттестации и аудита доступа к приложениям, данным и сервисам, а также обеспечивает контроль и предоставляет бизнес-аналитику процессов создания учетных записей, управления этими записями и как эти записи были использованы для доступа. В отличие от UAP, где права в системах привязывались напрямую к учетным записям, IAG-решения оперируют ролями, которые связаны с организационной структурой предприятия. Можно сказать, что в UAP-решениях за выдачу доступа отвечал ИТ-отдел, а IAG-системы вернули бразды управления доступом бизнес-пользователям.
Посмотрим на конкретные примеры использования IAG-решений. Допустим, требуется использовать Adobe Photoshop на рабочем компьютере. Сначала пользователь отправляет заявку в службу техподдержки. Ее сотрудники ждут подтверждения руководителя, который добавляется в переписку. В результате пользователь получает установленное приложение, потратив на это пару дней. Бывает, что в согласовании участвует несколько человек (так, чтобы получить новый ноутбук, нужно подтверждение руководителя и директора).
IAG-решения предлагают автоматизацию подобных процессов с помощью веб-портала, где можно запросить ресурс, затем запустится «невидимый» процесс, который при необходимости запросит подтверждение руководителя и после его получения автоматически произведет требуемые изменения. 
IAG-система позволяет руководителю или сотруднику службы безопасности увидеть, к каким системам у пользователя есть доступ, и также управлять этим доступом. 
Доступ может предоставляться и на основе «вычисляемых» правил, то есть если сотрудника назначили работать над конкретным проектом и у него появилась соответствующая роль, он автоматически получит доступ к требуемой документации, что позволит избежать «ручных согласований».
Если у пользователя появились лишние права (например, администратор Active Directory добавил пользователя в группу), которые не соответствуют его роли, служба безопасности получит уведомление об этом и может подтвердить исключение или принять меры к его устранению.
Важной составляющей процесса управления ролями является политики Separation of Duties (SoD) или разделение полномочий. Эти политики запрещают совмещение определенных ролей. Например, сотрудник, формирующий заказ, не должен участвовать в финансовых операциях.
Некоторые направления развития IAM
IAM-решения быстро развиваются, охватывая новые области, такие как управление данными на основе содержимого, управление мобильными устройствами, авторизация на основе рисков и многие другие.
Как мы видим, существующие IAM-решения хорошо позволяют управлять доступом к централизованным ресурсам. Однако в современных компаниях есть огромные объемы неструктурированных данных, хранящихся на компьютерах пользователей, в сетевых папках. Пользователь может легко скопировать ценные данные на свой компьютер и потом распространять их бесконтрольно.
Для решения этой проблемы в IAM-продуктах появляются модули, позволяющие классифицировать данные по содержимому и атрибутам документа и предоставлять доступ на основе сравнения данных, предоставленных пользователем (кто пользователь и какое устройство он использует), и данных классификации документа (какие данные содержит документ).
Еще одним перспективным направлением является управление и взаимодействие с мобильными устройствами. В современных компаниях пользователи используют для работы не только стационарные компьютеры, но и смартфоны, и планшеты. Во многих случаях это не корпоративные устройства, а личные. Политика BYOD (Bring your own device, или принеси свое устройство) набирает популярность за счет снижения затрат компании на поддержку инфраструктуры, покупку устройств. C популяризацией этой политики появляются новые задачи. Как защитить данные компании, хранящиеся на устройстве, но при этом соблюсти неприкосновенность частной информации сотрудника?
Технология использования логина и пароля для доступа к ресурсам компании критикуется давно, однако достойной замены предложить никто не смог. Методы двухфакторной аутентификации (например, комбинация традиционного способа и СМС) широкого распространения не получили. Сейчас поставщики IAM-решений двигаются в направлении аутентификации на основе контекстных данных о пользователе, устройстве, приложении, откуда пришел запрос. Эти данные анализируются, и принимается решение о личности пользователя. Такой алгоритм работы существует в некоторых социальных сетях. Так, при вводе логина из другой страны можно получить предложение указать дополнительные данные (номер телефона, например).
Как выбрать подходящую IAM-систему
Рынок IAM-решений
Рынок IAM активно развивается, происходят слияния и поглощения. Сложность IAM-систем существенно увеличивается с каждым годом. Для оценки современных IAM-предложений требуется серьезная экспертиза не только в области информационных технологий, но и в сфере бизнес-аналитики.
Существует несколько аналитических агентств, специализирующихся на исследованиях и сравнениях IAM-решений: Forrester, KuppingerCole, Gartner. Они, как правило, выпускают ежегодный отчет по рынку IAM-решений, а также отдельные документы о трендах в отрасли, опросники, помогающие выбрать наиболее подходящую систему. Если ежегодные отчеты можно найти на сайтах поставщиков решений, то специализированная документация, как правило, стоит от сотен до десятков тысяч долларов.
Для ежегодных отчетов у каждого из агентств своя методика сравнений и наглядного представления результатов.
Так, например, Gartner оценивает поставщиков IAM по шкале «Видение» (видение того, как развивается и будет развиваться рынок, способность к инновациям) и «Способность к реализации» (способность занимать долю рынка, продавать систему). 
В отчете KuppingerCole есть несколько диаграмм, где поставщики IAM-решений оцениваются по какой-то одной шкале (оценка продукта в целом на скриншоте ниже).
Такие отчеты позволяют получить понимание предметной области, тенденций развития рынка и общее представление о крупных игроках на рынке IAM.
Важно понимать, что на российском рынке многие системы не представлены вовсе. Также могут быть и локальные решения, достаточно успешные на российском рынке, но не имеющие распространения в мире.
Критерии выбора систем
Как не бывает двух одинаковых предприятий с одинаковым набором приложений и бизнес-процессов, так не бывает и универсальных и самых лучших IAM-систем. Каждая IAM-система обладает уникальным набором функциональности, коннекторов к целевым системам, фреймворков для расширения функциональности.
Начать выбор можно с формальных требований, таких как стоимость владения (стоимость лицензий, внедрения и поддержки на протяжении нескольких лет), лицензионная политика, наличие успешно завершенных проектов в близких по размеру/отрасли предприятиях, наличие специалистов по внедрению и поддержке на территории России.
Технические требования тоже могут помочь: наличие коннекторов к распространенным системам, используемым на предприятии, веб-интерфейса для бизнес-пользователей, автоматизации бизнес-процессов (например, согласований), механизма аттестаций, требования к открытому расширению функциональности (когда систему можно расширять без производителя).
Отобрав несколько наиболее подходящих поставщиков, можно посмотреть, как система работает с основными и самыми важными сценариями, которые требуется автоматизировать.
Обычно это сценарии жизненного цикла сотрудника: прием на работу, перевод в другой отдел или офис, отпуск, увольнение. Также важен набор сценариев по управлению доступом: выдача временного и постоянного доступа к системам по запросу, автоматически или по согласованию на основании ролей в компании или проекте, контроль доступа по расписанию (аттестации) и запросу.
При работе с данными учетных записей важно проверять их корректность (например, формат телефонного номера), а также преобразовывать данные при синхронизации, в частности, выполнять транслитерацию имен при синхронизации кадровой системы и Active Directory.
Для автоматизации жизненного цикла пользователей в целевых системах, как правило, используются коннекторы. Это выделенные модули IAM, осуществляющие взаимодействие с внешней системой, обеспечивающие создание, изменение, удаление учетных записей и выдачу доступа путем перевода ролей в IAM-системе в набор прав, понятный для целевой системы, например группы. Коннекторы часто меняются по причине изменений в целевой системе. Будет ли IAM поддерживать новую версию 1С или SalesForce? Как дорого стоит доработка коннектора?
Важно понимать, что IAM-система не коробочный продукт и в большинстве проектов стоимость услуг может в разы превышать стоимость лицензий. IAM-проекты никогда не заканчиваются (кроме неудачных), поскольку целевые системы под управлением IAM-предложения постоянно меняются и требуют переконфигурирования, обновления или доработки. Поэтому расширяемость системы – очень важный критерий выбора. Потребуется ли привлекать специалистов поставщика для каждого изменения или с этим могут справиться администраторы и бизнес-пользователи заказчика?
Примеры сценариев для оценки IAM-системы
Сценарий: После того как отдел кадров заводит учетную запись нового сотрудника в кадровой системе (например, 1С), сотрудник должен получить учетные записи и наборы прав во всех системах соответственно его роли не позднее чем через n минут.
Результат:
Сотрудник может пользоваться всеми системами в рамках полномочий его роли.
Запрос доступа к ресурсу
Сценарий: После того как сотрудник запрашивает ресурс через веб-портал, он должен получить ответ в течении n часов. Временный доступ к ресурсу регулируется путем ручного согласования. То есть запрос получает владелец ресурса и/или его заместитель. Если в течение заданного времени запрос остался не отвеченным, происходит эскалация.
Результат:
а) Сотрудник получает доступ к ресурсу;
б) Сотрудник получает отказ.
Сценарий: Раз в месяц владелец ресурса проводит аттестации списка тех, кто имеет доступ к ресурсу. Для каждого участника списка он продлевает или прекращает доступ.
Результат: Проведена аттестация, доступ к ресурсу имеют только сотрудники, подтвержденные владельцем.
Сценарий: Доступ сотрудника в отпуске должен автоматически быть прекращен на время его отсутствия. Прекращение доступа не требует ручных действий.
Результат: Сотрудник не имеет доступ к системам компании во время отпуска.
Сценарий: У сотрудника должен быть аннулирован доступ во все системы предприятия не позднее чем через n минут после инициации процесса руководителем на веб-портале.
Результат: Сотрудник не имеет доступ к системам компании.
Сценарий: Руководитель назначает сотруднику роль, которая не совместима с уже имеющимися ролями. Сотрудник не может совмещать взаимоисключающие роли.
Результат: Система отказывает в изменении и фиксирует нарушение политики.
Сценарий: Сотрудник забыл пароль.
Он заходит на веб-сайт, где, ответив на вопросы системы, инициирует сброс пароля и получает новый пароль в виде СМС. Новый пароль автоматически должен быть синхронизирован в подключенные системы.
Результат: Сотрудник получает новый пароль, которым может пользоваться во всех системах, где у него есть доступ.
Это первая часть статьи, будет продолжение.
Автор: Александр Цветков, инженер Dell Software
