Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS Active Directory.
Квест начался в тот момент, когда безопасники попросили проверить некоего Петрова. По их ощущениям, прав у него было куда больше, чем ему дали по заявкам от подразделений. Админу пришлось поднимать все эти бумажные документы из архива и обходить половину подразделений компании. Ради одного сотрудника. Пока он ходил около двух недель, проверить решили целый отдел.
Параллельно админ понял ещё одну страшную вещь: в компании по факту работает примерно в три раза меньше людей, чем учёток у него в системе. Почему? Да всё просто: учётки заводились по письменным заявкам, а при увольнениях и переводах обновлять статус зачастую забывали.
В этот момент мы начали работать над внедрением общего решения по управлению учетными записями и правами доступа, IdM. Для начала пришлось избавиться от раздробленности и свести все кадровые базы в одну промежуточную кадровую систему. Её связали с Active Directory через новый центр-репозиторий. Потом подключили к репозиторию остальные бизнес-системы вот так:
Дальше мы удалили все лишние учётки, оставили только действительных сотрудников (заодно увидели пару уволенных, но активно логинящихся). Потом нашли пару очень странных людей...
Например, были учётки А. М. Иванова и А. М. Ивaнова (визуально – один сотрудник, но у второго буква a в фамилии английская: либо ошибка, либо кто-то специально его «клонировал»).
Затем автоматизировали процесс назначения прав по документам кадровиков. Сделали портал самообслуживания, где сотрудники могли запросить доступ, куда было нужно. И уже не админ, а руководитель соответствующего подразделения его подтверждал. На аудит и понимание процессов ушло месяца два, ещё два на допиливание софта и тесты, последний — на внедрение и обучение IT-специалистов.
Вот примерно так. История эта в целом реальная, но некоторые детали я специально изменил, чтобы не раскрывать заказчика. Самое интересное в ней то, что мало кто, оказывается, вообще понимал, как работают IdM-системы. Поэтому я и пишу этот топик.
Общее об IdM
Обычно в крупной компании в какой-то момент начинается настоящий ад с учётными записями пользователей. У одного сотрудника появляется минимум 3-4 разных учётных записи. Управлять ими из единого центра не получается. При переводе из отдела в отдел нужно делать кучу вещей руками. Плюс появляются требования законодательства по защите персональных данных, политике безопасности по каждой учётке и так далее.
С этим можно жить, увеличивая количество ручных операций, а можно настраивать IdM — систему управления идентификационными данными и правами доступа.
Как это выглядит? Довольно красиво: например, при всё том же переводе сотрудника из одного подразделения в другое, вы обновляете его данные в одном репозитории. Дальше, например, в 1С меняются права, в корпоративном телефонном справочнике меняется должность, в бизнес-приложении обновляется учётка, в системе документооборота появляются новые связи по бизнес-процессам. И так далее.
Итак, если ваша компания достаточно большая, то есть три варианта развития ситуации:
— С учётками наблюдается некоторый хаос. Например, когда приходит на работу сотрудник, ему необходимо предоставить доступ во множество информационных систем. Первые пару дней он может вообще не использовать корпоративные ресурсы, либо сидеть с учётки предшественника, что не очень хорошо. Во-вторых, если всё делается вручную — будут ошибки, типа избыточных прав в ряде систем. В-третьих, если нет точного процесса, многое будет завязано на конкретных людей, при повышении или уходе которых придётся заново восстанавливать систему управления доступами. Когда такие звоночки появляются, это, собственно говоря, является поводом, чтобы задуматься над внедрением IdM.
— У вас полный порядок, но много действий делается руками. IdM поможет это автоматизировать. Чем больше вендоров корпоративных систем, тем больше «стыков» можно будет построить через IdM.
— У вас системы одного вендора (когда IdM просто не нужна, всё и так делается через одну учётку), либо есть IdM в том или ином виде. Я видел, например, что в одновендорных системах действует согласование заявок (да хоть по почте, если бизнес-процессы отлажены), и всё работает. Так что здесь всё просто.
Каждому сотруднику компании соответствует пользователь IdM-системы, создаваемый на основании кадровых данных, получаемых из доверенной системы (например, HR-системы). Учетные записи в целевых информационных системах создаются только с помощью IdM-системы и привязываются к конкретному сотруднику. Таким образом, любой учетной записи в информационной системе всегда соответствует её владелец — сотрудник компании
Надо сказать, что внедрение IdM в сложной мультивендорной среде с множеством разных систем и ещё географически разделёнными подразделениями — задача нетривиальная. И сложная для руководства. Обычно действует принцип — «не трогай, пока работает», поэтому надо думать о таких вещах либо заранее, когда ещё легко внедрить систему, либо искать доводы. И вот здесь вашими лучшими друзьями становятся безопасники. Потому что они-то уж точно знают, чего может стоить всего одна учётка. И более того, наверняка у них есть примеры весьма неприятных ситуаций для компании, повторения которых они бы о-очень не хотели. И вы можете им помочь.
Как система выдаёт права?
Есть два способа: на основе правил, настраиваемых в системе (например, всем сотрудникам безопасности — доступны такие-то ресурсы, всем руководителям подразделений — такие-то и так далее). И по заявкам. Например, кто-то из закупки хочет больше данных о товаре и ему нужно получить доступ в 1С. Он отправляет заявку, система отслеживает иерархию, отправляет её, например, финдиректору. Если он подтверждает заявку, человек получает доступ.
Как идёт внедрение
Первый этап — это обязательное проведение обследования. По результатам этого аудита мы определяем сложившиеся бизнес-процессы, связанные с управлением учётными данными и доступом. И второе, мы рисуем целевую картину, в которой систему должны реализовать, и предлагаем техническое решение, с помощью которого эту идею, в общем-то, можно, опять же, реализовать.
В этап обследования обязательно включается аудит — проверка технической инфраструктуры. Речь идёт о том, что одна система может хранить идентификационные данные, например, в базе данных, другая система – в плоском файле. Ещё мы обследуем интерфейсы, по которым эти системы могут общаться в будущем с IdM (интерфейс и протоколы) для того, чтобы понять возможность вообще и трудоёмкость интеграции.
Тут, главное, без излишнего фанатизма. Знаете, как бывает — «потратил 5 часов на написание алгоритма, который решает за 5 секунд задачу, которую я считал бы вручную 3 часа». Так вот, есть системы, которые не надо полностью интегрировать. Например, в компании тысяча сотрудников и в одной из систем работает только 50 человек. И это один отдел, и текучка этого отдела очень небольшая. Возможно, есть экономическая необходимость не интегрировать эту систему с IBT-менеджером, а скрестить её с IdM в ручном режиме. То есть, администратору этой системы будет при необходимости отправляться письмо с просьбой выдать права доступа тому или иному сотруднику. Такие варианты тоже возможны. У нас, в частности, был пример в компании на 10 тысяч человек, когда кадровая система, в которой работает 5 человек, имела технические ограничения, и мы предложили заказчику рассмотреть именно такой вариант. В итоге так и сделали.
Для интеграции разрабатываются коннекторы — небольшие программные модули, которые позволяют забирать данные из систем и, наоборот, эти данные в системы предоставлять. Обычно делается или доработка штатных коннекторов или разработка с нуля (чаще всего для отечественных систем: у американцев обычно всё сразу из коробки заточено под нужды крупного бизнеса).
Чтобы пользователи работали по привычным схемам, большая часть событий может дублироваться в почту. Как подтверждал раньше финдиректор доступ письмом, так и может продолжать — только теперь письмо ему пишет робот из IdM и просит просто кликнуть по ссылке «да» или «нет».
Счастье безопасников
Когда всё готово, получается схема, где у каждого человека в компании прописаны права. И это — настоящее счастье для всего отдела безопасности и финансового директора. Появляется комплексная отчётность и целостное видение. Например, до внедрения системы понимание того, у кого какие права есть, — это был целый квест с обходом всех подразделений. После внедрения — пара кликов. Два любимых вопроса на этой стадии: «насколько выданные права соответствуют правам, запрошенным в заявках», «насколько они соответствуют служебной необходимости и корпоративным политикам безопасности». Ответы исчерпывающи и часто неожиданны для тех, кто только оценил уровень ошибок до внедрения системы.
Параллельно появляется вторая часть математической задачи — расчёт оптимальных прав. Да-да, мы делаем некоторый Data Mining (хотя, громковато сказано для большей части случаев). И показываем, как можно оптимально разделять права. Выявляются какие-то вещи, которые не должны быть в нормальной структуре, которые могут привести к повышению рисков, связанных именно с доступом.
Ещё одна особенность: каждое изменение прав имеет основание. Например, когда раньше админ руками проставлял новому сотруднику права — это всегда было на его страх и риск. Сейчас система отрабатывает по основаниям: приказу о приёме человека, подтверждению запроса от руководителя и так далее. Просто взять и поменять данные в корпоративном справочнике не получится: данные от кадровиков считаются более доверенными.
Очень радует удобство обновления прав. Системы IdM умеют следить за ситуациями, когда права выданы, но человеку уже не нужны. Например, по должности сотрудник не выполняет работу, требующую доступа к финансовым отчётам компании, а такой доступ у него имеется. Система может обнаружить эту закономерность и выдать рекомендацию эти права убрать.
Счастье пользователей
Потом счастливыми становятся пользователи. У них — система одного входа, когда достаточно один раз залогиниться на рабочем месте и автоматически получать доступы в рамках своих полномочий. Никаких бумажек с паролями с кучей приложений и сервисов — помнить надо только свой, на вход (обратите внимание, это более широкая задача SSO, не всегда системы IdM решают её).
Счастье IT-отдела
После внедрения, когда вся компания косо смотрела на «выдумщиков» из IT-отдела, меняющих привычный уклад вещей, можно расслабиться и начать получать удовольствие. Изменения из одного места, удобная картина прав, заскриптованные действия, типа создания ящика новому сотруднику по факту обновления документов у кадровиков и так далее, — это кайф. Пароль сотрудник сбрасывает себе сам, учётку разблокирует его руководитель, а у IT-отдела есть лог действий, если понадобится найти причину проблемы. Правда, придётся некоторое время попотеть с кропотливой настройкой (будет период довольно продолжительного «допиливания»), но это того стоит.
Да, вы правильно поняли, что IdM очень бережёт нервы. Дело в том, что заявки на доступ отправляются уже не системному администратору, а тому, кто должен такой доступ подтверждать. Руководителю подразделения, финансовому директору, безопасникам — в общем, тем, кто прямо отвечает за вопрос. И это значит, что если раньше, когда что-то было не так, был виноват админ, то сейчас чётко понятно, кто, что и кому дал. А админ только обеспечил протокол:
Бухгалтерия тоже счастлива
Для них есть специальные слова, которые как музыка ласкают слух всего отдела. Это уменьшение суммарной стоимости внедрения, снижение стоимости владения, уменьшение требуемых технических ресурсов, прозрачность архитектуры, снижение затрат на обслуживание и эксплуатацию решения, поэтапность внедрения решения без влияния на непрерывность процессов компании. Уф. В общем, это как рефакторинг и оптимизация сразу.
Идеология
В США и Европе такие системы уже давно, и к ним многие привыкли. Было бы странно, если бы в нашей стране не было особенностей менталитета, связанных с правами доступа. Главная проблема — доверенность источников. Например, кадровики много где просто обожают заносить все данные задним числом в систему, уже при увольнении. Это профессиональный сдвиг, ведь рабочая книжка заполняется по факту именно в этот момент.
Часто бывают ситуации, когда нужно делать особые привилегии руководству. То есть, вводится какое-то правило, но по факту топы ему не следуют. Когда правило автоматизируется, боссов может ждать сюрприз — например, автоматическая выгрузка сотовых телефонов в общий справочник контактов компании. Понятно, что после пары звонков от клиентов сразу директору, мы такое правило на практике доработали.
Деньги
Лицензии дорогие. Условий множество, но обычно получается от десятков до нескольких сотен долларов на сотрудника. Впрямую, за счёт сэкономленного времени, системы окупаются за 3-4 года, но обычно оценка идёт всё-таки по выгодам безопасников и прозрачной отчётности. Ещё особенность — когда компания проходит аудит, например, перед продажей (слиянием) или сертификацией, такие системы воспринимаются очень позитивно.
Эволюция
Изначально, как таковых репозиториев управления доступами не было. Стояла задача понять, «кто и куда имеет право заходить». Ко всем точкам логина подключались модули, которые просто фиксировали, кто входит. Медленно выстраивалась карта доступов, которая шла в отчёт. С другой стороны, параллельно развивались центры выдачи единых прав, которые такую карту формировали. В итоге сейчас появились симбиозные решения: сначала они действуют в режиме read-only и собирают актуальные данные по правам, потом переносят модуль за модулем в активный менеджмент, а потом позволяют сделать глобальную автоматизацию. И это всё спокойно, плавно и без рывков для пользователей.
P.S. Если у вас есть вопросы по конкретной конфигурации для вашего случая или вы не можете задать вопрос в комментариях, пишите прямо мне на AZaikin@croc.ru.
Автор: azaikin
