Всем привет! Меня зовут Артём, я продуктовый лидер с опытом управления линейкой высоконагруженных продуктов информационной безопасности и клиентского сервиса — IDM, PAM, PKI, SSO, FAM — в крупнейших банках России и коммерческих организациях. На мне в этом плане всегда были стратегия и операционное управление бэклогом, координация 30+ разработчиков, DevOps, архитекторов, аналитиков и инженеров. Причем не в самой дружелюбной среде — с высочайшими требованиями к надежности, безопасности и соблюдению регуляторных стандартов.

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

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

И на этом фоне поставщики постоянно упирают на свою приверженности ИИ, машинному обучению, автоматизации, графам и вообще — всему новому и модному.

Но важно тут вот что. Допустимо ли для компании механическое приращение этих новинок к привычной инфраструктуре? Или, может, современные задачи требуют современных решений?

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

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

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

Специфика IdM как продукта

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

1. Положение на пересечении систем. IdM затрагивает HR, ИТ, ИБ, финансы, аудит, внешних подрядчиков. Изменение в любой из этих областей транслируется в требования к IdM. IdM не имеет собственного «владельца» в том смысле, в каком его имеет, например, ERP.

2. Высокая цена ошибки. Ошибочное предоставление прав — инцидент ИБ. Ошибочный отзыв — остановленный бизнес-процесс. Откат «задним числом» часто невозможен.

3. Долгий жизненный цикл. Платформа эксплуатируется 7– 10 лет. За это время сменяются бизнес-требования, регуляторика, технологии и команда.

4. Зависимость от качества данных. Качество IdM не выше качества учетных данных в источниках (HR, AD, кадровые системы). Источники часто находятся вне зоны контроля проекта.

5. Политическая природа. Вопросы владения ролью, утверждения доступа и recertification — это вопросы организационной власти, а не только технологии.

Сочетание инфраструктурной критичности и постоянной изменчивости делает IdM естественным полигоном для тактического, а не чисто стратегического мышления.

Три ловушки классического подхода внедрения IdM

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

1. Иллюзия «полного охвата» на старте

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

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

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

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

2. Автоматизация ради автоматизации

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

Механизм возникновения: ручной труд в управлении доступом воспринимается как безусловное зло, и это создает давление в сторону автоматизации всего подряд; метрики проекта строятся вокруг «доли автоматизированных процессов», а не вокруг бизнес-эффекта; вендоры и интеграторы, само собой, поддерживают такую постановку, потому что она расширяет объем работ; наконец, отсутствует анализ того, какие ручные операции являются ценными — например, ручное согласование доступа к критичным системам может быть осознанным контролем, а не бюрократией.

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

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

Важно понять, что цель IdM — не автоматизация как таковая, а управляемость и снижение риска. Автоматизировать стоит те операции, которые либо выполняются массово, либо критичны с точки зрения ИБ, либо порождают измеримую боль.

3. Погоня за зрелостью

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

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

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

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

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

Тактический подход, напротив, исходит из того, что неопределенность — не дефект, а среда. Задача — не устранить ее, а выстроить движение, устойчивое к ней.

Семь принципов тактического подхода

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

1. Целевое видение короткое, тактика — длинная

В неопределенной среде долгосрочное детальное планирование теряет смысл: чем дальше горизонт, тем ниже точность. Но полный отказ от видения приводит к потере направления и «дрейфу» проекта. Решение — разделить уровни: видение фиксирует зачем и в каком направлении, тактика определяет как и что именно сейчас. Видение формулируется на одной странице и включает бизнес-задачи, ключевые принципы (например, «единый источник истины для сотрудников — HR», «роли — бизнес-атрибуты, а не технические группы») и границы (что вне scope). Видение пересматривается не чаще раза в год, а лучше - реже.

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

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

2. «Вертикальные срезы» вместо «горизонтальных слоев»

Горизонтальное внедрение (сначала интеграция с HR, затем роли, затем recertification, затем SSO) создает длинный период, в течение которого ценность не производится.

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

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

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

3. Архитектурный каркас есть, детального дизайна — нет

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

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

4. Данные важнее процессов

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

Начинать следует с «расчистки» данных в критичных источниках, даже если это выглядит как «не IdM». Необходимо назначить владельца данных в каждом источнике, определить правила качества (какие атрибуты обязательны, как часто обновляются, кто отвечает за актуальность). IdM-команда не «чинит» данные — она предоставляет инструменты и правила.

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

5. Явное управление изменениями требований

Требования в IdM меняются не потому, что заказчик «не определился», а потому что среда объективно изменчива. Попытка реагировать на каждое изменение немедленно приводит к хаосу; попытка игнорировать изменения — к потере релевантности. Решение — явные «окна изменений». Фиксируются окна (например, раз в квартал), внутри которых требования стабильны; между окнами изменения накапливаются и приоритизируются; приоритизация опирается на метрики ценности и видение; срочные изменения (регуляторика, инциденты) обрабатываются вне окон по отдельной процедуре.

Преимущества: команда не перестраивается еженедельно, изменения обрабатываются осознанно, а не реактивно, появляется предсказуемость для бизнеса.

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

6. Инкрементальная ценность вместо инкрементальной функциональности

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

7. Готовность к откату как часть тактики

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

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

Признак работающего принципа: команда может ответить на вопрос «Что мы будем делать, если этот релиз сломает процесс?» до релиза, а не после.

Если мы с вами сведём принципы воедино, то увидим некоторое соответствие.

• Принцип короткого видения фиксирует «зачем» и направление, оставляя гибкими конкретные шаги, и при нарушении грозит дрейфом проекта или параличом.

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

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

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

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

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

• Принцип готовности к откату фиксирует план отката, оставляя гибким механизм реализации, и при нарушении грозит неконтролируемыми инцидентами.

Причем ловушки напрямую связаны с принципами, смотрите. Принцип короткого видения полностью отвечает иллюзиям полного охвата и нивелирует этот риск. Беспокоимся насчет автоматизации ради автоматизации? На помощь приходит принцип приоритета данных и ценности, а не просто функций для галочки. Принцип окон изменений поможет в гонке за зрелостью — и так по каждому пункту.

Главное здесь — в попытке так или иначе устранить неопределенность, потому что это и есть общая природа всех трех ловушек. И этой природе отвечает тактическая рамка, которая воспринимает эту неопределенность не как какой-то дефект, а как среду.

Рамка выбора подхода к внедрению

Универсального ответа на вопрос «как внедрять IdM» нет. Но, на мой взгляд и на основе накопленного опыта, можно сформулировать рамку принятия решения, которая опирается на четыре фактора. Разберем каждый.

1. Зрелость данных и процессов

Если зрелость низкая — источники разрознены, процессы держатся на ручном труде, у данных нет владельцев — тактика будет вида «Сначала фундамент». Это значит: строим минимальный IdM, заводим единый идентификатор, подключаем ключевые источники, настраиваем базовый provisioning. А роли и сложные согласования откладываем до тех пор, пока данные не стабилизируются.

Если зрелость средняя — тактика «Вертикальные срезы по бизнес-сценариям»: роли и процессы вводим постепенно, по мере готовности данных.

Если зрелость высокая — тут уже можно позволить «быстрые итерации по функциональности»: здесь реальны recertification, ролевое моделирование и аналитика.

2. Регуляторное давление

Когда давят жесткие сроки, штрафы и аудит, работает тактика «Сначала compliance-минимум»: быстро закрываем критичные требования — например, отзыв доступа при увольнении и обязательную отчетность, — а все остальное делаем позже.

Когда давления нет, логичнее тактика «Сначала бизнес-ценность»: автоматизируем то, что болит у бизнеса, а не то, что беспокоит аудитора.

3. Скорость организационных изменений

Если организация часто меняется — слияния, реструктуризации, смена бизнес-модели, — выбираем тактику «гибкий каркас, минимальные зависимости» и инвестируем в инструменты миграции и синхронизации.

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

4. Ресурсы и компетенции команды

При ограниченных ресурсах тактика — «Минимальный жизнеспособный IdM»: готовые интеграции, минимум кастомизации, внешняя экспертиза точечно.

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

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

Практические тактики

Из описанных принципов вытекают конкретные практические тактики — то, что можно применить уже завтра.

«Тонкий слой сейчас, толстый потом»: IdM внедряется как тонкий слой - единый идентификатор, интеграция с двумя - тремя критичными системами, базовый provisioning. Покрытие расширяется по мере стабилизации.

«Владелец данных в каждом источнике»: назначается ответственный за качество данных в каждом источнике. IdM-команда не чинит данные — она предоставляет инструменты и правила.

«Роли — от бизнеса, не от ИТ»: ролевая модель, построенная ИТ сверху, обречена на саботаж. Начинаем с пяти –десяти бизнес-ролей для критичных сценариев, согласованных с бизнес-владельцами, а расширяемся по мере доверия.

«Измерение боли, а не функций»: определяем три–пять метрик, значимых для бизнеса - время выдачи доступа, доля ручных операций, количество инцидентов доступа, время отзыва при увольнении. Отчитываемся по ним, а не по количеству внедренных функций.

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

«Документирование решений, а не процессов»: вместо детальных регламентов ведем журнал архитектурных решений (ADR): что решили, почему, какие альтернативы отклонили. Это ускоряет вход новых участников и позволяет пересматривать решения осознанно.

«Подготовка выхода заранее»: для каждого крупного компонента — вендора, интеграции, ролевой модели — определяем стоимость и сложность отказа. Если отказ невозможен, это риск, который принимается явно и берется под управление.

Заключение

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

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

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