Всем привет! Меня зовут Артём, я продуктовый лидер с опытом управления линейкой высоконагруженных продуктов информационной безопасности и клиентского сервиса — IDM, PAM, PKI, SSO, FAM — в крупнейших банках России и коммерческих организациях. На мне в этом плане всегда были стратегия и операционное управление бэклогом, координация 30+ разработчиков, DevOps, архитекторов, аналитиков и инженеров. И не в самой дружелюбной среде — с высочайшими требованиями к надежности, безопасности и соблюдению регуляторных стандартов.
Средства управления идентификационными данными (IdM) в контуре корпоративной информационной архитектуры давно стало чем‑то привычным и не выходящим за рамки базовой информационной безопасности компании. На мой взгляд, отрасль повзрослела: поставщики ИБ услуг располагают выверенными продуктовыми линиями, а службы защиты информации накопили богатый опыт развертывания и наличия широкого спектра специалистов для эксплуатации подобных решений.
Но давайте вместе зададим вопрос, а что поменялось? Исходя из моего опыта, изменение заключается в содержании задач, ради которых закупают IdM и занимаются его внедрением. Раньше, минимально было важно обеспечение базовых потребностей безопасности и управления доступом к инфраструктуре (сопровождение учетных записей работников, обработка обращений, утверждение ролей). А теперь, организационный контекст стал заметно сложнее. Вычислительные ресурсы рассредоточены, число ИС в компаниях растет. И мой совет, не стоит забывать, что субъектность сотрудника уже приобретают и ИИ‑агенты в компаниях, об этом поговорим чуть позже.
С моей точки зрения, если в сегодняшних условиях развития рынка услуг ИБ, а также развития продуктовых линеек крупнейших компаний, занимающихся производством продуктов для обеспечения безопасности информации, а именно управления доступом к системам внутренних ИС своих потенциальных заказчиков, идти по пути внедрения посредством «идеальной» водопадной стратегии, можно зайти в тупик: пока на фазе пилотирования согласуется целевая архитектура, часть требований устаревает, а часть — уже вступает в противоречие начальным.
Цель моей статьи заключается в обобщении практического опыта построения крупных IdM‑систем в неустойчивой среде рынка ИБ РФ и предложении, как мне кажется, основных вариантов для выбора подхода к внедрению. Сразу оговорюсь, это не будет универсальным рецептом. Скорее всего, я назову это набором тактических принципов, позволяющих двигаться, не теряя управляемости. В тексте я рассматриваю управление идентичностями в условиях архитектурного сдвига внутри компании, а также личный опыт построения крупной IdM‑системы в информационном периметре Сбербанка.
Специфика IdM как продукта
Перед тем, как мы начнем обсуждать тактику и основные подходы к внедрению, нам необходимо зафиксировать свойства продукта класса IdM, которые делают его «сложным по умолчанию».
Положение на пересечении систем. IdM, как одна из основ управления доступом на предприятии любого масштаба, объединяет в себе различные компоненты (HR, ИТ, ИБ, финансы, аудит, внешних подрядчиков и так далее). Любое изменение в этих областях немедленно транслируется в IdM.
Высокая цена ошибки. Ошибочное или несанкционированное (например ролевой моделью) предоставление прав доступа не предприятии, это, безусловно, инцидент ИБ. Как показывает опыт, порой, большого масштаба. А ошибочный отзыв прав — нередко, остановленный бизнес‑процесс, что влечет за собой финансовые потери.
Долгий жизненный цикл. Обычно, IdM эксплуатируется 7–15 лет. За это время сменяются бизнес‑требования, требования регуляторов, технологии и команда.
Три ловушки классического подхода внедрения IdM
Давайте кратко поговорим о классическом подходе (с вашего позволения, я буду называть его так) к внедрению IdM и проблематике, несостоятельности для сегодняшних условий крупных внедрений.
Классический подход сформировался во время, когда инфраструктурные проекты внедрений разворачивались в относительно стабильной среде: требования к системе фиксировались на старте проекта, вендоры выпускали большие релизы раз в несколько лет, организационная структура заказчика менялась медленно или вовсе оставалась глобально неизменной. Если мы последуем этой логике и перенесем ее в современные условия, то породим три ловушки, каждая из которых имеет собственный механизм возникновения и характерные симптомы. Перейдем к ним.
1. Иллюзия «полного охвата» на старте
Проект строится исходя из допущения, которое, по опыту, впоследствии будет глобальной архитектурной ошибкой, что на этапе обследования можно собрать исчерпывающую картину всех источников, всех целевых систем, всех сценариев и всех ролей. Формируется объемный реестр интеграций и матрица доступов и ролевой модели, которая воспринимается заказчиком и командой внедрения, как основа для планирования.
Последствия этой ловушки серьезны: архитектурный план проекта строится на неполноценных данных и потому регулярно пересматривается; архитектурные решения принимаются без учета «скрытых» систем, которые потом приходится интегрировать в авральном режиме.
2. Автоматизация ради автоматизации
По опыту (это и правильно, порой) заказчик формулирует цель как перевод максимального числа ручных операций сотрудников и бизнес‑единиц в автоматические, не задаваясь вопросом, какие из этих операций вообще стоит автоматизировать. Цель моих проектных команд заключается в донесении нашим заказчикам корректной картины автоматизации (автоматизируем то, что повысит управляемость ИС и прозрачность доступов к ним).
Последствия ненужной автоматизации: IdM становится сложной и неповоротливой системой; стоимость владения растет; реальная нагрузка на команду внедрения и сопровождения не снижается, а только возрастает.
Здесь важно понять, что цель IdM — не автоматизация как таковая, а управляемость и снижение риска. Автоматизировать стоит те операции, которые либо выполняются массово, либо критичны с точки зрения ИБ, либо порождают измеримую боль.
3. Игнорирование работы с данными
В классическом подходе внедрения IdM, по опыту, у многих заказчиков, принято считать, что внедрение новой, будем называть, продвинутой системы автоматически наведет порядок в «делах». Но, к сожалению или счастью, это работает с точностью до наоборот. IdM, всего лишь, мощный исполнительный механизм. Если на вход этому механизму мы подаем полный хаос (разрозненный формат данных с ИС), он начнет в автоматизированном режиме, системно и молниеносно тиражировать этот хаос по всей вашей инфраструктуре.
Последствия: Я думаю, они всем понятны и они печальны.
Давайте теперь перейдем к моему «тактическому подходу» во внедрении IdM и его основным принципам.
Основные принципы тактического подхода
Сразу замечу, что данные принципы не являются исцеляющим рецептом. Это скорее набор правил, которые помогут снизить сложность проекта и уменьшить критичность его основных этапов.
1. Продуктовая зрелость команды
Показатель эффективности: моя команда может объяснить, зачем делается текущий релиз, ссылаясь на архитектурное видение ситуации у конкретного заказчика. Но при этом свободна в выборе конкретных шагов.
2. Архитектурный каркас есть, но детального дизайна нет
Показатель эффективности: Мой главный совет: дайте команде бизнес‑цель на ближайший релиз (видение) и попросите их предоставить варианты реализации.
В контексте моего прошлого тезиса о продуктовой зрелости команды, это идеальный полигон. Бизнес и архитектор задали правила игры (каркас), но не стали связывать руки инженерам и команде разработки и аналитики.
3. «Вертикальные срезы» вместо «горизонтальных слоев»
Показатель эффективности: мы имеем ранний работающий результат, это я называю проверкой архитектуры на прочность в реальных условиях, выявление проблем данных на раннем этапе развития проекта, накопление организационного знания ИС у конкретного заказчика.
4. Данные важнее процессов
Показатель эффективности: моя проектная команда может назвать три‑пять источников, качество данных в которых критично, и владельцев этих источников.
5. Явное управление изменениями требований
Показатель эффективности: моя команда не перестраивается еженедельно, изменения обрабатываются осознанно, а не реактивно, появляется предсказуемость для бизнеса.
6. Инкрементальная ценность вместо инкрементальной функциональности
Показатель эффективности: ценность создается, когда бизнес чувствует разницу: быстрее выдают доступ, меньше ручных операций, ниже риск. Необходимо в команде определить три‑пять метрик, значимых для бизнеса и понятных всему проекту: время выдачи доступа, доля ручных операций, количество инцидентов доступа, время отзыва при увольнении. Каждый релиз должен улучшать хотя бы одну метрику.
7. Готовность к откату как часть тактики
Показатель эффективности: моя команда может ответить на вопрос «Что мы будем делать, если этот релиз сломает процесс?» до релиза, а не после.
Практическое правило простое: выбирайте подход, который дает первый работающий результат за три, шесть месяцев и не закрывает возможность пересмотреть архитектурные решения через год.
Заключение
На сегодняшний день, тактика перестает быть «мелким» уровнем управления. Она становится способом проверять стратегические гипотезы малыми ставками, накапливать знания и адаптироваться быстрее, чем меняется информационная среда.
Для IdM, да в целом и для любого инфраструктурного продукта, это означает, прежде всего, отказ от иллюзии, что можно спроектировать идеальную систему «для закрытия всех потребностей управления доступом на предприятии», и принятие реальности, в которой система достраивается и перестраивается постоянно, модернизируется. На мой взгляд, выигрывает тот, кто построил достаточно гибкий каркас, накопил качественные данные, выстроил доверие с бизнесом и научился быстро менять курс.
