Сегодня мы начнем разговор о системах класса Identity Management. Как многие из вас знают, 1 июля закончился срок действия отсрочки вступления в силу федерального закона РФ от 27 июля 2006 года № 152-ФЗ «О персональных данных»
Соответственно, для управления персональными данными в ИТ крупные компании будут вынуждены внедрять специализированные системы класса IDM для управления информацией о пользователях своих корпоративных систем. Если раньше наблюдался некоторый дефицит квалифицированных кадров в этой области, то теперь этот дефицит примет катастрофические масштабы, так как гром грянул, и мужику положено начать креститься.
Дефицит кадров в этой специализированной области обусловлен тем, что специалист по IDM должен обладать сразу несколькими навыками в ИТ – он должен хорошо разбираться в устройстве различных систем информационной безопасности, иметь практический опыт системного администрирования, быть неплохим программистом для написания адаптеров и сценариев обработки данных, уметь описывать и ставить бизнес-процессы. И при этом он не должен беситься от огромного количества рутинной работы по выверке персональных данных. Могу практически со стопроцентной уверенностью утверждать, что таких людей в природе не существует. С этим фактом связана извечная головная боль сотрудников HR, которые вообще смутно себе представляют нашу специфику, а тут еще им приходится иметь дело с такой гремучей смесью несовместимых навыков.
Единственным выходом из ситуации является разделение работы минимум на двоих. Один может программировать коннекторы к системам безопасности, настраивать внутренние workflow, писать скрипты и заниматься развертываением. Второй должен работать с пользовательскими данными, описывать бизнес-процессы, заниматься документированием и продвижением идеи IDM в ИТ массы.
Спешу разочаровать коллег-программистов. В этом цикле статей акцент будет сделан на бизнес- и постановочную часть внедрения IDM, а также на практические приемы внедрения и работы с пользовательскими данными. Потому что толковых программистов у нас хоть и мало, но найти можно. А вот людей, понимающих зачем все это делается, можно пересчитать в Москве по пальцам.
Я искренне надеюсь, что после прочтения данного материала у коллег прибавится ясности по данному вопросу, и многие программисты или системные администраторы смогут перейти в лагерь бизнес-аналитиков по IDM, чтобы составить достойную конкуренцию тем немногим работающим в этой области «звездам».
Identity – это личность. Все, что составляет информацию о реальном человеке, является Identity: его имя, пол, должность, год рождения, атрибуты его учетных записей в системах. В определенных сочетаниях информация о человеке является предметом защиты федеральных законов и должна управляться. Процессы и системы управления персональными данными называются Identity Management, или IDM.
Где хранится персональная информация о сотрудниках компании? Разумеется, в кадровой системе. А еще – в каталоге Active Directory, в карточках пользователей нескольких десятков прикладных систем, в данных почтовых программ, в системах управления клиентами, в биллинговых системах, в системах сервис-деск… Зачастую эта информация не согласованна. Один и тот же человек может быть прописан в десятке систем одновременно, и никто не даст гарантии, что он прописан в них одинаково и корректно.
Одна из основных задач IDM – создание единого и актуального каталога персональной информации как основы для дальнейшего развития процессов управления.
Учетные записи пользователя и их атрибуты (например, группы доступа) являются такой же частью персональной информации, как и почтовые адреса, имена и должности. Специалисты по Active Directory подтвердят, что это все хранится в системной базе данных сходным образом. Соответственно, логично было бы включить в рамки процесса IDM заодно и управление доступом к информационным системам (Access Management). Часто под IDM как раз и понимается Identity and Access Management (IAM), просто аббревиатура IDM людям нравится больше.
Результаты успешного внедрения IDM можно разделить на «статические» и «динамические». Первые – это результаты «что же стало?». А вторые «И как же это работает?»
Статическим результатом успешного внедрения IDM является порядок в учетных записях пользователей, заключающийся в следующем:
Динамическая составляющая успешного внедрения – это, собственно, работающий как часы процесс управления учетными записями. Вот пример критериев такого процесса:
Во всей описанной благостной картине не хватает одной маленькой, но очень важной составляющей. Внимательный читатель может заметить, что мы научились заводить и блокировать учетки, синхронизировать каталоги, но у нас пока нет ответа на вопрос: «А куда, собственно, нужно допускать того или иного пользователя и какие права ему требуются для работы?» Поиск ответа на этот вопрос зачастую составляет большую часть всей работы в рамках проекта внедрения IDM.
Права (привилегии) пользователя в различных системах зависят только и исключительно от его служебных обязанностей. И чем разнообразнее его обязанности, тем сложнее определить принципы назначения этих привилегий.
В простейшем случае права пользователя определяются его должностью, и физическим расположением его рабочего места. Это характерно для массовых взаимозаменяемых должностей – разнообразных операторов, сотрудников центров обработки звонков, работников конвейерной линии и т.п.
Задача усложняется, когда в обязанности сотрудника входит дополнительная деятельность, не характерная для его коллег. Например, сотрудник отвечает за заказ канцтоваров на весь свой отдел. Для этого ему предоставляется доступ в некую систему, куда он заходит раз в квартал, нажимает там три кнопки и забывает о ней на следующие три месяца. И такие пользователи есть в каждом отделе. Подобную головную боль представляют также бухгалтеры крупных компаний, которые, как известно, часто специализируются в разных областях и используют разные системы, будучи при этом на одной должности.
Еще более сложный случай – когда в компании действуют внутренние проекты или иная нерегулярная деятельность, требующая временных группировок сотрудников по тем или иным признакам. Например, внедряется ERP система, и все участники рабочей группы получают временный доступ к тестовой площадке. Или в компании идет работа над новым шаблоном презентации, и ключевых сотрудников допустили на портал службы маркетинга для оценки дизайнерских макетов. Да мало ли что еще может быть! Дать необходимые полномочия в подобной ситуации еще полдела. Попробуйте правильно и вовремя их отозвать! В 90% компаний полномочия никогда у пользователей не отзываются. Давно работающие сотрудники постепенно обрастают доступами, словно корабли ракушками. Через два-три года никто толком не может сказать, откуда у них такое количество привилегий. Если сами учетные записи еще хоть как-то контролируются прикладными администраторами по количеству и предполагаемым владельцам, то в рамках одной учетной записи сам черт ногу сломит.
Чтобы оценить масштаб бедствия приведу некоторые цифры. Допустим, в компании 1000 пользователей, 10 систем и в каждой системе по 10 разных привилегий. Часть систем завязана, например, на Active Directory, а часть имеет свою систему аутентификации. Таким образом, в среднем на каждого пользователя приходится, к примеру, по 3 учетные записи. Итого имеем 3000 учетных записей. Каждый пользователь имеет в среднем по 5-7 привилегий в своих системах. Итого имеем 15 -20 тысяч назначений привилегий пользователям. Каждое назначение привилегий было сделано в свое время не просто так, а со смыслом. А смысл имеет свойство со временем исчезать.
Чтобы разобраться во всем этом, как вы понимаете, нужно проделать серьезную работу. В ручном режиме управиться можно при небольшом количестве систем и железной дисциплине. Но если сущностей становится слишком много для обычного человека, приходится думать об автоматизации процесса и о применении элементов ролевого управления доступом (Role Management). RM – это сейчас крайне модное и популярное направление в сфере middleware. Для стороннего наблюдателя стоит оно немыслимых денег и непонятно чего делает. Системы этого класса предлагают наперебой ведущие гиганты софтостроения, такие как Oracle (он же Sun), IBM, Microsoft. Множество копий сломано в бессмысленных спорах о преимуществах той или иной платформы. По опыту могу сказать, что все системы будут одинаково бестолковыми, если мы не уделим должного внимания наведению порядка в бизнес-процессах.
Вообще говоря, механика работы этих систем меня интересует мало, так как успех внедрения заключается не в фирменном движке и не в используемом языке программирования, а в правильном формировании ролевых моделей и в точной настройке бизнес-правил. Качество же конкретной системы определяется удобством формирования ролевой модели и гибкостью в настройке бизнес-правил. Все ведущие производители стараются оптимизировать именно эти параметры своих разработок наряду с расширением количества готовых коннекторов и общим повышением надежности работы движка.
В случае внедрения IDM не нужно, как у нас принято, сразу же кидаться ставить софт в надежде на то, что телега вытянет за собой лошадь. Чуда, как обычно, не произойдет, а дров наломаете на годы вперед. Ведь системы IDM внедряются в самое «наше все» системных администраторов — в аутентификацию пользователей. Упавший IDM может парализовать работу всей компании. Криво настроенный движок приведет к тому, что прежний «геморрой» с прописыванием нового пользователя вручную покажется админам доброй сказкой. Стоит ли говорить, как все вокруг воспримут после этого вас и вашу систему.
Как пример могу привести забавный глюк в алгоритме разрешения конфликтов при формировании учеток однофамильцев, который приводил к автоматической генерации сразу сотни учетных записей. Представьте себе теперь восторг заказчика, который оплачивает лицензию за каждую учетную запись в купленной им системе. Только чудом удалось тогда замять скандал. Но ложки-то нашлись, а осадочек остался.
Российские реалии таковы, что даже в самых развитых и прогрессивных компаниях бардак в пользовательских привилегиях стоит неимоверный. Несмотря на периодическую зачистку и инвентаризацию учетных записей, привилегии пользователей никто не вычесывает мелким гребнем, особенно у высокопоставленных сотрудников. Также зачастую нет порядка со служебными, гостевыми и административными учетными записями, так как они не связаны с конкретными людьми и вообще непонятно что с ними делать.
Получается, что сотрудники отделов информационной безопасности сидят на мине замедленного действия, так как они не знают ответа на элементарный вопрос аудитора: «Кто и на каком основании имеет доступ к той или иной системе?» А то, что с этим вопросом им придется встречаться все чаще и чаще, есть установленный наукой факт. Ответить же на него в любой момент времени (а не только после месяца ручной выверки привилегий) помогут системы класса IDM с дополнительной функциональностью ролевого управления доступом.
В следующих публикациях мы затронем вопросы организации проекта внедрения IDM, а также различные практические подходы к созданию ролевых моделей.
P.S. Изменил название топика, чтобы оно лучше отражало его суть.
Было: Identity Management — основы управления персональными данными
Стало: Identity Management — основы управления учетными записями
Соответственно, для управления персональными данными в ИТ крупные компании будут вынуждены внедрять специализированные системы класса 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 можно разделить на «статические» и «динамические». Первые – это результаты «что же стало?». А вторые «И как же это работает?»
Статическим результатом успешного внедрения IDM является порядок в учетных записях пользователей, заключающийся в следующем:
- Все учетные записи во всех системах распределены по конкретным людям, включая технологические («учетки» процессов и систем) и системные («админские учетки»)
- Все атрибуты учетных записей согласованы между собой (например, фамилия и номер корпоративного телефона везде одинаковые)
- Мы точно знаем, какие права в каких системах имеет каждый сотрудник
Динамическая составляющая успешного внедрения – это, собственно, работающий как часы процесс управления учетными записями. Вот пример критериев такого процесса:
- При приеме на работу новых сотрудников, переводах сотрудников на другие должности, увольнении сотрудников параллельно и согласованно изменяются атрибуты их учетных записей в информационных системах
- Учетные записи для новых сотрудников формируются автоматически по заранее установленным правилам (включая запуск разных волшебных скриптов и прочие танцы с бубном). Новый сотрудник может приступать к работе практически сразу после оформления в кадрах, если ему дали компьютер, разумеется.
- Учетные записи уволенных или неблагонадежных сотрудников блокируются одновременно во всех системах, с которыми они работали. Таким образом ущерб от «обиженных» будет сведен к минимуму.
- Каждый сотрудник имеет в каждый момент времени только тот набор привилегий, который необходим ему для выполнения служебных обязанностей. Лишние привилегии отсутствуют.
Во всей описанной благостной картине не хватает одной маленькой, но очень важной составляющей. Внимательный читатель может заметить, что мы научились заводить и блокировать учетки, синхронизировать каталоги, но у нас пока нет ответа на вопрос: «А куда, собственно, нужно допускать того или иного пользователя и какие права ему требуются для работы?» Поиск ответа на этот вопрос зачастую составляет большую часть всей работы в рамках проекта внедрения IDM.
Права (привилегии) пользователя в различных системах зависят только и исключительно от его служебных обязанностей. И чем разнообразнее его обязанности, тем сложнее определить принципы назначения этих привилегий.
В простейшем случае права пользователя определяются его должностью, и физическим расположением его рабочего места. Это характерно для массовых взаимозаменяемых должностей – разнообразных операторов, сотрудников центров обработки звонков, работников конвейерной линии и т.п.
Задача усложняется, когда в обязанности сотрудника входит дополнительная деятельность, не характерная для его коллег. Например, сотрудник отвечает за заказ канцтоваров на весь свой отдел. Для этого ему предоставляется доступ в некую систему, куда он заходит раз в квартал, нажимает там три кнопки и забывает о ней на следующие три месяца. И такие пользователи есть в каждом отделе. Подобную головную боль представляют также бухгалтеры крупных компаний, которые, как известно, часто специализируются в разных областях и используют разные системы, будучи при этом на одной должности.
Еще более сложный случай – когда в компании действуют внутренние проекты или иная нерегулярная деятельность, требующая временных группировок сотрудников по тем или иным признакам. Например, внедряется ERP система, и все участники рабочей группы получают временный доступ к тестовой площадке. Или в компании идет работа над новым шаблоном презентации, и ключевых сотрудников допустили на портал службы маркетинга для оценки дизайнерских макетов. Да мало ли что еще может быть! Дать необходимые полномочия в подобной ситуации еще полдела. Попробуйте правильно и вовремя их отозвать! В 90% компаний полномочия никогда у пользователей не отзываются. Давно работающие сотрудники постепенно обрастают доступами, словно корабли ракушками. Через два-три года никто толком не может сказать, откуда у них такое количество привилегий. Если сами учетные записи еще хоть как-то контролируются прикладными администраторами по количеству и предполагаемым владельцам, то в рамках одной учетной записи сам черт ногу сломит.
Чтобы оценить масштаб бедствия приведу некоторые цифры. Допустим, в компании 1000 пользователей, 10 систем и в каждой системе по 10 разных привилегий. Часть систем завязана, например, на Active Directory, а часть имеет свою систему аутентификации. Таким образом, в среднем на каждого пользователя приходится, к примеру, по 3 учетные записи. Итого имеем 3000 учетных записей. Каждый пользователь имеет в среднем по 5-7 привилегий в своих системах. Итого имеем 15 -20 тысяч назначений привилегий пользователям. Каждое назначение привилегий было сделано в свое время не просто так, а со смыслом. А смысл имеет свойство со временем исчезать.
Чтобы разобраться во всем этом, как вы понимаете, нужно проделать серьезную работу. В ручном режиме управиться можно при небольшом количестве систем и железной дисциплине. Но если сущностей становится слишком много для обычного человека, приходится думать об автоматизации процесса и о применении элементов ролевого управления доступом (Role Management). RM – это сейчас крайне модное и популярное направление в сфере middleware. Для стороннего наблюдателя стоит оно немыслимых денег и непонятно чего делает. Системы этого класса предлагают наперебой ведущие гиганты софтостроения, такие как Oracle (он же Sun), IBM, Microsoft. Множество копий сломано в бессмысленных спорах о преимуществах той или иной платформы. По опыту могу сказать, что все системы будут одинаково бестолковыми, если мы не уделим должного внимания наведению порядка в бизнес-процессах.
Вообще говоря, механика работы этих систем меня интересует мало, так как успех внедрения заключается не в фирменном движке и не в используемом языке программирования, а в правильном формировании ролевых моделей и в точной настройке бизнес-правил. Качество же конкретной системы определяется удобством формирования ролевой модели и гибкостью в настройке бизнес-правил. Все ведущие производители стараются оптимизировать именно эти параметры своих разработок наряду с расширением количества готовых коннекторов и общим повышением надежности работы движка.
В случае внедрения IDM не нужно, как у нас принято, сразу же кидаться ставить софт в надежде на то, что телега вытянет за собой лошадь. Чуда, как обычно, не произойдет, а дров наломаете на годы вперед. Ведь системы IDM внедряются в самое «наше все» системных администраторов — в аутентификацию пользователей. Упавший IDM может парализовать работу всей компании. Криво настроенный движок приведет к тому, что прежний «геморрой» с прописыванием нового пользователя вручную покажется админам доброй сказкой. Стоит ли говорить, как все вокруг воспримут после этого вас и вашу систему.
Как пример могу привести забавный глюк в алгоритме разрешения конфликтов при формировании учеток однофамильцев, который приводил к автоматической генерации сразу сотни учетных записей. Представьте себе теперь восторг заказчика, который оплачивает лицензию за каждую учетную запись в купленной им системе. Только чудом удалось тогда замять скандал. Но ложки-то нашлись, а осадочек остался.
Российские реалии таковы, что даже в самых развитых и прогрессивных компаниях бардак в пользовательских привилегиях стоит неимоверный. Несмотря на периодическую зачистку и инвентаризацию учетных записей, привилегии пользователей никто не вычесывает мелким гребнем, особенно у высокопоставленных сотрудников. Также зачастую нет порядка со служебными, гостевыми и административными учетными записями, так как они не связаны с конкретными людьми и вообще непонятно что с ними делать.
Получается, что сотрудники отделов информационной безопасности сидят на мине замедленного действия, так как они не знают ответа на элементарный вопрос аудитора: «Кто и на каком основании имеет доступ к той или иной системе?» А то, что с этим вопросом им придется встречаться все чаще и чаще, есть установленный наукой факт. Ответить же на него в любой момент времени (а не только после месяца ручной выверки привилегий) помогут системы класса IDM с дополнительной функциональностью ролевого управления доступом.
В следующих публикациях мы затронем вопросы организации проекта внедрения IDM, а также различные практические подходы к созданию ролевых моделей.
P.S. Изменил название топика, чтобы оно лучше отражало его суть.
Было: Identity Management — основы управления персональными данными
Стало: Identity Management — основы управления учетными записями
