Автоматизация выдачи доступов (IGA) для 1 000+ сотрудников

Почему ручное управление доступами перестает работать

Пока сотрудников сотни, ручная выдача доступов держится на личных договоренностях: письмо в ИТ, согласование в мессенджере, отметка в Excel. Но когда компания вырастает до 1 000+ людей, этот подход начинает сбоить почти ежедневно. Заявок больше, систем больше, а людей, которые помнят «как правильно», не прибавляется.

Первое, что ломается, - скорость и качество. Ручной процесс обычно приводит к одному и тому же:

• доступы выдаются с задержкой: новичок простаивает или просит «временно дать всё»
• появляются ошибки: не тот профиль, не та роль, доступ не в ту среду
• копятся лишние права «на всякий случай», потому что снимать их некогда
• согласования теряются, а решения принимаются «по памяти»
• при увольнении доступы снимаются частично или с опозданием

Рост до 1 000+ сотрудников увеличивает нагрузку на ИТ и ИБ не только из-за количества заявок. Усложняется контур: больше приложений, филиалов, типов пользователей (штатные, временные, подрядчики). В результате специалисты тратят время на ручные проверки и переписки вместо работы с рисками.

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

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

Когда ручной подход уже не тянет, обычно появляется запрос на IGA (Identity Governance and Administration): не ради «витрины», а чтобы права выдавались предсказуемо, согласования фиксировались, а лишние доступы не жили годами.

Что такое IGA и какие задачи она закрывает

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

Важно не путать IGA с IAM и SSO. IAM чаще отвечает за вход (учетные записи, аутентификация, парольные политики), SSO делает вход удобнее (один логин для многих систем). IGA стоит рядом, но решает другую задачу: порядок в правах и доказуемость. Даже при идеальном SSO у сотрудников могут оставаться лишние роли в ERP, почте, файловых ресурсах или сервисах разработки.

Базовые сценарии: joiner, mover, leaver

IGA обычно строится вокруг жизненного цикла сотрудника (JML). Когда человек приходит, переводится или уходит, доступы должны меняться быстро и одинаково для всех.

Пример: новый бухгалтер выходит на работу. По данным из HR-системы IGA автоматически создает учетную запись, выдает базовый набор доступов (почта, ERP/1С, папки отдела), отправляет на согласование доступ к чувствительным модулям и сохраняет историю: кто и когда одобрил. При переводе система снимает старые права и добавляет новые. При увольнении учетные записи блокируются и права снимаются по понятным правилам, без ручных обходов.

Роли, группы, политики и SoD простыми словами

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

Отдельная тема - разделение обязанностей (SoD, segregation of duties). Это запрет на опасные комбинации прав. Простой пример: один человек не должен одновременно создавать контрагента и утверждать оплату. Или заводить пользователя и сам себе выдавать админские роли. IGA помогает находить такие конфликты и либо блокировать выдачу, либо требовать дополнительное согласование.

Что такое access review и зачем оно нужно

Access review (периодический ревью прав доступа) - регулярная проверка, все ли права у сотрудников оправданы сейчас. Руководители и владельцы систем подтверждают или снимают доступы, а результат фиксируется для безопасности и аудита.

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

От IGA обычно ждут простых результатов: быстрее выдаются доступы новичкам, меньше инцидентов из-за лишних прав, выше прозрачность (кто выдал и почему), проще проходить аудит, и появляется единый порядок вместо десятков ручных процедур.

SailPoint, Saviynt, One Identity: как выбирать под ваш контур

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

Сначала опишите «скелет» доступа: HR-источник (откуда приходит сотрудник), корпоративный каталог (часто Microsoft AD/Azure AD), почта, ключевые бизнес-системы (например, SAP или Oracle), а также приложения, где доступ до сих пор выдается вручную. Затем сравнивайте платформы по тому, что реально придется сделать в первые 3-6 месяцев.

На что смотреть в первую очередь

Обычно достаточно пяти критериев:

• коннекторы и интеграции: есть ли готовые подключения к вашим системам и поддерживаются ли они в ваших версиях
• workflow и правила: можно ли описать согласования без обходных схем, и насколько легко менять их после запуска
• модель развертывания: on-prem, облако или гибрид, и где будут храниться данные и журналы
• трудоемкость внедрения: сколько нужно инженеров, и насколько много будет кастомного кода
• отчетность и аудит: насколько быстро формируются ответы «кто, когда и почему получил доступ», плюс контроль SoD

Различия между SailPoint, Saviynt и One Identity чаще проявляются не в «витринных» возможностях, а в деталях: как платформа ведет себя в гибридной среде, как устроены кампании ревью и сколько усилий требует сопровождение.

Что обязательно проверить на пилоте

Пилот нужен не для презентации, а для проверки на ваших данных. Возьмите один департамент (например, 150-200 человек) и 3-5 систем, где больше всего заявок.

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

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

Подготовка данных и интеграций перед автоматизацией

Внедрение IGA начинается не с выбора «кнопок», а с понимания, насколько вы доверяете данным и источникам. Если источники расходятся, система просто начнет быстрее раздавать ошибки.

Первый шаг - определить «источники истины» для сотрудников и учетных записей. Обычно это HR-система, Active Directory (или другой каталог), корпоративная почта и 3-5 ключевых бизнес-систем, где риск выше всего (финансы, документооборот, ERP/CRM, сервис-деск, отраслевые приложения).

Приведите кадровые данные в порядок

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

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

Определите модель ролей и владельцев

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

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

Продумайте интеграции: заявки, уведомления, журналирование

Даже если вы не автоматизируете все сразу, заранее решите, где будут жить заявки и согласования (Service Desk, ITSM, внутренний портал), как уйдут уведомления (почта, мессенджер) и где хранится журнал действий для аудита.

Минимальный набор для запуска обычно такой: HR как мастер-данные о сотрудниках, каталог (AD) как учетные записи и группы, почта как базовый ресурс, 1-2 критичных приложения (финансы, документооборот), а также ITSM или единый процесс согласования, чтобы approvals не жили в переписках.

Остальное подключают волнами: VPN, базы данных, файловые ресурсы, отраслевые системы, облака. В организациях на 1 000+ сотрудников часто начинают с онбординга и увольнений (HR + AD + почта), затем добавляют доступы в финансовую систему и наводят порядок с исключениями. Если проект ведет интегратор, важно заранее согласовать владельцев данных и формат журналов - иначе все упрется не в платформу, а в организационные пробелы.

Пошаговый план внедрения IGA для 1 000+ сотрудников

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

Начните с небольшой, но заметной первой волны: 10-20% доступов, которые критичны для бизнеса и аудита. Часто это учетная запись в AD и почта, ключевые бизнес-приложения (ERP/CRM), а также привилегированные доступы.

Логика первых шагов:

• определить цель и охват: какие системы и подразделения, какой измеримый результат через 8-12 недель (например, онбординг за 1 день вместо 5)
• описать JML-процессы и правила выдачи: что положено по должности, подразделению, локации и типу занятости
• настроить коннекторы и сверку учетных записей: убрать дубликаты, согласовать «источник истины», убедиться, что платформа видит реальные права

Дальше переходите от данных к управлению:

• запустить каталог ролей: простые роли по должностям и типовые наборы доступов, без попытки покрыть все исключения
• настроить заявки и согласования для 2-3 сценариев (новый доступ, временный доступ, расширение роли)
• включить ревью и базовые отчеты: владельцы доступа, история согласований, непройденные ревью, изменения за период

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

Автоматизация заявок и согласований на доступ

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

Самообслуживание обычно строится вокруг ролей и шаблонов. Сотрудник выбирает нужный набор, видит статус и сроки. Руководитель подтверждает потребность и срок. Владелец приложения проверяет, что роль корректна для процесса. ИБ подключается там, где есть риск: критичные системы, персональные данные, финансы, администрирование.

Чтобы заявки не были «в свободной форме», используйте стандартные роли вроде «Новый бухгалтер», «Инженер техподдержки», «Менеджер продаж» с заранее описанными системами и уровнями прав. Тогда обсуждать приходится исключения, а не базовые вещи.

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

Автовыдача уместна, когда риск низкий и условия понятны (стандартная роль, сотрудник в нужном подразделении, выполнены обязательные условия вроде обучения). Она не подходит для привилегированных прав, финансовых операций, админ-панелей, данных пациентов или клиентских баз, а также для просьб «сделайте как у Петрова».

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

Периодические ревью прав и контроль конфликтов (SoD)

Когда выдача доступов уже автоматизирована, следующий источник рисков - «старые» права, которые никто не пересматривает. Периодические ревью (recertification) помогают убрать лишнее, закрепить ответственность и спокойно проходить аудит.

Начните с зон, где эффект максимальный: критичные бизнес-системы (финансы, закупки, кадры, медицинские данные) и привилегированные права. В приоритете также общие учетные записи, администраторские группы, доступ к клиентским данным и настройкам безопасности.

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

Частоту выбирайте по риску. Часто работает простая схема: привилегированные права - ежеквартально, критичные бизнес-роли - раз в полгода, остальное - раз в год. Плюс ревью «по событиям»: перевод, смена должности, длительный отпуск, увольнение.

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

Параллельно настройте контроль SoD. Смысл простой: один человек не должен иметь полный цикл действий, где можно незаметно совершить ошибку или злоупотребление. Типовые конфликты: «создать поставщика» + «провести платеж», «завести сотрудника» + «утвердить начисление», «создать заявку» + «утвердить и исполнить», «администратор системы» + «просмотр конфиденциальных данных без необходимости».

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

Операционная модель, метрики и готовность к аудиту

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

Начните с метрик, которые легко измерять и которые показывают пользу бизнесу и ИБ:

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

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

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

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

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

Типовые ошибки при внедрении и как их избежать

Чаще всего IGA-проект ломается не на выборе SailPoint, Saviynt или One Identity, а на мелочах: данные, владельцы, границы первого этапа и правила изменений.

Ошибка 1: начинать с «идеальных ролей» без фактических прав

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

Как избежать: сначала соберите фактические права из ключевых систем, сравните по подразделениям и должностям, найдите повторяющиеся наборы. Стройте роли итерациями: 5-10 базовых ролей на пилоте, затем расширение.

Ошибка 2: слишком широкий первый охват

Когда подключают «все системы сразу», команда тонет в нестандартных доступах, локальных админах и ручных договоренностях. Проект буксует, бизнес теряет доверие.

Как избежать: начните с 2-3 критичных систем и одного процесса (например, прием на работу и перевод). Отдельно зафиксируйте, что будет во второй и третьей волне.

Ошибка 3: нет владельцев со стороны бизнеса

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

Как избежать: назначьте владельца приложения и владельца роли/набора доступов с правом финального решения. Особенно важно для финансовых и кадровых систем.

Ошибка 4: плохие HR-данные и игнорирование увольнений и подрядчиков

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

Как избежать: договоритесь, какие поля в HR являются «истиной», и настройте контроль качества (обязательный руководитель, подразделение, дата начала, тип занятости). Для увольнений и окончания договора подрядчика задайте правило с приоритетом: отключение в день события.

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

Ошибка 5: нет процесса изменений

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

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

Короткий чеклист и следующие шаги

Перед стартом IGA проверьте базовые вещи. Ошибки на старте почти всегда связаны не с продуктом, а с тем, что нет ясных владельцев, данных и правил.

Быстрые проверки перед стартом

Соберите минимум, без которого пилот будет буксовать:

• источники идентичностей: HR, AD или Azure AD и другие учетные источники, с понятным «главным» полем для ФИО, подразделения, должности и статуса
• список целевых систем: почта, файловые ресурсы, ERP/CRM, сервис-деск, базы, с указанием типа доступа (роль, группа, учетная запись)
• владельцы: кто утверждает доступ по каждой системе и кто отвечает за состав ролей
• правила JML: что выдавать при найме, что менять при переводе, что снимать при увольнении, и в какие сроки
• минимальные требования аудита: какие отчеты нужны и как долго хранить логи

Дальше определите пилот. Хороший ориентир - быстрый эффект без перегруза интеграциями: 2-3 системы, один процесс и одна кампания ревью. Частый вариант: HR как мастер-данные, AD как базовые учетные записи, плюс одна бизнес-система с ролями.

Отдельно спланируйте надежность. Для on-prem сценария заранее решите, где размещать компоненты, как делать резервное копирование, кто отвечает за обновления, и какие SLA нужны на критичные процессы (например, блокировка при увольнении).

Если нужна помощь с архитектурой, внедрением и сопровождением IGA, это часто удобнее делать вместе с интегратором, который умеет закрыть и инфраструктуру. Например, GSE.kz (gse.kz) как производитель и системный интегратор может взять на себя интеграционные работы и поддержку, а при необходимости подобрать и поставить серверы под IGA и обеспечить круглосуточную техническую поддержку через сервисную сеть.