Когда человек впервые слышит аббревиатуру IDM, обычно происходит одна из двух вещей.

Разработчик делает умное лицо и произносит: "А, Identity Management...". Инфраструктурщик же тяжело вздыхает, потому что мгновенно вспоминает очередной ночной инцидент, в ходе которого выяснилось, что бывший сотрудник, уволившийся ещё несколько месяцев назад, по-прежнему может подключиться к production через старый VPN. А если повезёт особенно сильно, то у него ещё обнаружится действующий Jenkins token, забытый kubeconfig и сервисный аккаунт, который когда-то создавался "буквально на пару дней".

И именно в этот момент становится понятно, что IDM - это не про логин и пароль.

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

Пока инфраструктура небольшая, проблемы управления доступами почти незаметны. Но чем быстрее растёт компания, тем чаще возникают вопросы, на которые никто не может дать внятный ответ. Кто имеет доступ к production? Почему этот человек оказался в группе администраторов? Кто согласовал выдачу привилегий? Почему сотрудник, ушедший полгода назад, до сих пор присутствует в корпоративном LDAP? И именно тогда выясняется, что управление идентификацией - это не дополнительная функция, а один из базовых сервисов всей платформы.

В этой статье подробно разберём, что такое IDM, зачем он нужен, как устроен в крупных организациях, какие решения используют BigTech и enterprise-компании, как IDM связан с Kubernetes и DevOps, а также почему ручная выдача доступов через Jira-тикеты рано или поздно приводит к инфраструктурному алкоголизму.

Что такое IDM

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

На практике большинство инженеров сталкивается с IDM гораздо чаще, чем им кажется. Каждый раз, когда сотрудник входит в корпоративную почту, получает доступ к GitLab, открывает Jira, подключается к VPN или запускает kubectl для работы с кластером, где-то в фоне отрабатывают механизмы управления идентификацией. Они проверяют личность пользователя, анализируют его принадлежность к группам, оценивают уровень привилегий и принимают решение о том, разрешать действие или нет.

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

В какой-то момент оказывается, что никто уже не способен точно ответить, сколько действующих учётных записей существует в инфраструктуре, кому принадлежат сервисные аккаунты и почему аналитик внезапно получил доступ к production Kafka. Именно поэтому IDM постепенно превращается не просто в средство аутентификации, а в центральный мозг всей системы управления доступами.

Из чего состоит IDM

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

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

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

Типичная архитектура выглядит примерно следующим образом:

HR система
    ↓
IDM
    ↓
LDAP / Active Directory
    ↓
SSO / OAuth / SAML
    ↓
GitLab / Jira / VPN / Kubernetes / AWS / Jenkins

На первый взгляд схема кажется довольно простой. Однако за каждой стрелкой скрываются десятки сценариев обработки событий, проверки политик и интеграционных механизмов. Именно поэтому проекты внедрения IDM редко оказываются быстрыми и безболезненными.

Главная задача IDM

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

Этот процесс называется Identity Lifecycle Management и охватывает весь путь сотрудника внутри организации - от первого рабочего дня до окончательного отзыва всех полномочий.

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

Сотрудник пришёл

Представим типичную ситуацию. В компанию выходит новый разработчик. Без IDM этот процесс превращается в настоящий квест. Необходимо создать учётную запись, выдать VPN, добавить человека в GitLab, подключить Jira, создать корпоративную почту, предоставить доступ к мониторингу и объяснить, где искать инструкции. Каждый этап требует отдельного тикета и участия нескольких администраторов.

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

Разработчик приходит в первый рабочий день и действительно может заниматься разработкой, а не ожиданием очередного согласования. Onboarding сокращается с нескольких дней до нескольких минут, а инфраструктурная команда перестаёт выполнять роль живого API по выдаче доступов.

Сотрудник ушёл

Однако настоящая зрелость IDM проявляется вовсе не в onboarding.

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

Хороший IDM способен за считанные минуты отозвать все выданные ранее полномочия. Учётная запись блокируется в каталоге, активные сессии завершаются, VPN становится недоступен, облачные права удаляются, токены инвалидируются, а SSH-ключи перестают работать. Причём всё это происходит автоматически, без участия десятка администраторов и без необходимости создавать цепочку тикетов с пометкой "срочно".

Плохой IDM работает иначе. Он оставляет после себя цифровые призраки, которые годами продолжают жить внутри инфраструктуры. Старый kubeconfig, обнаруженный на ноутбуке бывшего подрядчика. Forgotten API Key, который никто не может идентифицировать. Сервисный аккаунт Jenkins, созданный для временной интеграции. Root-доступ "на пару дней", который неожиданно празднует уже третий день рождения. Именно такие артефакты потом становятся героями внутренних расследований и аудиторских отчётов.

Почему IDM критически важен в крупном фин/бигтехе

Пока инфраструктура состоит из пяти разработчиков, одного Docker Compose и виртуального сервера стоимостью несколько евро в месяц, полноценный IDM действительно может показаться избыточным. Большинство задач решается вручную, а количество пользователей позволяет держать всю картину в голове.

Но затем компания начинает расти.

Появляется несколько облаков. Возникает необходимость работать одновременно с AWS и локальными дата-центрами. В инфраструктуру приходит Kubernetes, за ним GitOps, десятки SaaS-сервисов, подрядчики, распределённые команды и требования регуляторов. Вчерашняя таблица Excel с перечнем доступов превращается в бесполезный артефакт, а вопрос "у кого есть доступ к production?" неожиданно требует полноценного расследования.

Именно в этот момент становится очевидно, что IDM - это не роскошь и не прихоть безопасников. Это инструмент обеспечения управляемости.

Без централизованного управления идентификацией enterprise-инфраструктура очень быстро превращается в инфраструктурный Wild West. Доступы выдаются вручную, полномочия наследуются по принципу "пусть будет, вдруг пригодится", а любые изменения требуют участия людей, которые давно уже не помнят, почему конкретное правило появилось в системе.

Основные компоненты IDM

Directory Service

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

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

Наиболее распространёнными решениями остаются Microsoft Active Directory, LDAP и FreeIPA. Несмотря на солидный возраст некоторых из этих технологий, они до сих пор лежат в основе огромного количества корпоративных инфраструктур. Причина проста: каталог пользователей - это не то место, где компании любят эксперименты.

SSO - Single Sign-On

Single Sign-On, или единый вход, давно стал обязательным элементом зрелой платформы. Его основная задача заключается в том, чтобы пользователь проходил аутентификацию один раз и получал доступ ко всем разрешённым системам без необходимости запоминать десятки различных паролей.

Без SSO корпоративная жизнь быстро начинает приобретать узнаваемые черты. На мониторах появляются стикеры с паролями, сотрудники используют одинаковые комбинации для разных сервисов, а где-нибудь на сетевом диске возникает файл passwords-final-v3.xlsx, который, вопреки своему названию, уже пережил пятнадцать версий.

Современные реализации единого входа обычно строятся на базе SAML, OAuth 2.0 и OpenID Connect. Пользователь проходит проверку личности у доверенного провайдера идентификации, после чего получает возможность работать со всеми необходимыми системами. Это не только повышает удобство, но и значительно упрощает сопровождение инфраструктуры.

MFA

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

Пароль больше нельзя считать надёжным фактором идентификации. Люди продолжают использовать повторяющиеся комбинации, придумывают предсказуемые последовательности и становятся жертвами фишинга. История человечества убедительно доказывает, что если предоставить выбор между сложным уникальным паролем и Summer2026!, значительная часть пользователей выберет именно второй вариант.

Поэтому компании всё активнее внедряют дополнительные факторы подтверждения личности. Используются TOTP-приложения, аппаратные ключи безопасности, WebAuthn, FIDO2 и YubiKey. Да, пользователи периодически жалуются на дополнительные действия при входе. Но стоимость нескольких лишних секунд несопоставима со стоимостью расследования компрометации административной учётной записи.

RBAC

Role Based Access Control - один из важнейших принципов зрелого IDM. Его основная идея заключается в том, что доступы выдаются не человеку напрямую, а через заранее определённые роли.

На практике это означает, что сотруднику назначается роль вроде k8s-prod-readonly, gitlab-developer или vault-operator, а вместе с ней автоматически применяется необходимый набор разрешений. Если обязанности человека меняются, достаточно изменить его принадлежность к группам.

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

Именно тогда начинают происходить удивительные открытия. Например, выясняется, что стажёр имеет права администратора Kafka, потому что несколько лет назад его временно включили в нужную группу и забыли вернуть всё обратно.

Provisioning

Provisioning отвечает за автоматическую выдачу и настройку доступов. Именно здесь IDM начинает приносить компании прямую экономическую выгоду.

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

Фактически provisioning превращает управление доступами из ручного ремесла в промышленный процесс. И чем крупнее организация, тем заметнее оказывается эффект от такой автоматизации.

Audit и Compliance

"А кто вообще выдал доступ этому человеку?"

Если компания небольшая, ответ обычно звучит так: "Кажется, это делал Пётр. Хотя, возможно, ещё Андрей. Надо посмотреть в переписке". В enterprise после такого ответа аудиторы начинают нервно улыбаться, а служба безопасности открывает блокнот.

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

На практике требования аудита часто становятся главным драйвером внедрения IDM. Пока всё работает нормально, бизнес неохотно инвестирует в подобные проекты. Но как только появляются требования SOC 2, ISO 27001, PCI DSS или регуляторные проверки, выясняется, что ответы вроде "мы всегда так делали" больше никого не устраивают.

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

IDM и Kubernetes

Вот здесь начинается территория настоящего DevOps.

Kubernetes без нормального управления идентификацией очень быстро превращается в платформу, где все пользователи обладают правами cluster-admin. Сначала это кажется разумным компромиссом. Команды развиваются быстрее, никто не жалуется на ограничения, инженеры могут самостоятельно решать возникающие задачи.

Проблемы начинаются позже.

Оказывается, что никто не знает, сколько людей имеют полный доступ к кластеру. Разработчики случайно получают возможность изменять критические системные компоненты. Временные подрядчики продолжают видеть production спустя месяцы после завершения проектов. А во время инцидентов становится невозможно определить, кто именно выполнил то или иное действие.

Именно поэтому зрелые Kubernetes-платформы практически всегда строятся вокруг внешней системы идентификации.

Как IDM интегрируется с Kubernetes

Современный Kubernetes изначально проектировался с расчётом на интеграцию с внешними поставщиками идентификации. Сам кластер не должен хранить пользователей и управлять их жизненным циклом. Его задача заключается в проверке полученного токена и применении политик доступа.

Чаще всего интеграция строится через OpenID Connect, Dex, Keycloak или облачные механизмы идентификации. Пользователь проходит аутентификацию в корпоративном IDM, получает токен, содержащий информацию о принадлежности к группам, а Kubernetes API Server использует эти сведения для применения правил RBAC.

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

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developers-readonly

subjects:
- kind: Group
  name: developers

roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

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

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

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

Что используют крупные компании

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

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

Microsoft

Microsoft делает ставку на Microsoft Entra ID, ранее известный как Azure Active Directory. Сегодня это один из наиболее распространённых продуктов на enterprise-рынке.

Он объединяет единый вход, многофакторную аутентификацию, условный доступ, защиту идентичностей и интеграцию с огромным количеством облачных сервисов. Для компаний, глубоко использующих экосистему Microsoft, Entra ID фактически становится центральной точкой управления доступами.

Интересно, что именно благодаря массовому распространению Entra многие организации впервые начали серьёзно относиться к концепции Conditional Access. Теперь решение о предоставлении доступа принимается не только на основании логина и пароля, но и с учётом состояния устройства, географии подключения и оценки рисков.

Google

Google пошёл ещё дальше и построил собственную модель безопасности BeyondCorp, которая стала одним из символов движения Zero Trust.

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

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

Фактически именно Google популяризировал мысль о том, что VPN сам по себе больше не является границей безопасности.

Amazon

Если существует отдельная религия в мире управления доступами, то её вполне можно назвать AWS IAM.

Amazon построил чрезвычайно гибкую модель авторизации, включающую IAM, IAM Identity Center, Organizations и Service Control Policies. Возможности настолько широки, что одна и та же задача может быть реализована несколькими различными способами.

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

GitHub

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

GitHub Enterprise активно использует SAML-аутентификацию, Enterprise Managed Users и SCIM Provisioning. Такой подход позволяет автоматически создавать и удалять учётные записи сотрудников, синхронизировать их принадлежность к группам и централизованно управлять жизненным циклом доступа.

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

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

Что любят enterprise-компании

Если посмотреть на инфраструктуру крупных организаций, можно заметить одну интересную закономерность. Никто не использует только одну систему.

Типичный enterprise-зоопарк выглядит примерно так:

  • Active Directory;

  • Okta;

  • Ping Identity;

  • SailPoint;

  • CyberArk;

  • ForgeRock;

  • OneLogin;

  • внутренние самописные сервисы;

  • несколько приложений, написанных пятнадцать лет назад.

И всё это каким-то образом интегрировано между собой.

Когда инженеры впервые сталкиваются с подобными ландшафтами, они часто задаются вопросом:

"Почему бы просто не заменить всё одной современной системой?"

Ответ обычно довольно прозаичен.

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

И потому что существует негласное правило enterprise: нет ничего более постоянного, чем временное решение, которое успешно проработало десять лет.

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

Open Source IDM решения

А теперь перейдём к самому любимому разделу инфраструктурщиков.

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

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

Тем не менее, open source-мир предлагает действительно сильные решения.

Keycloak

Если попросить десять DevOps-инженеров назвать первую открытую IDM-платформу, большинство без раздумий ответит: Keycloak.

За последние годы этот продукт фактически стал стандартом де-факто в мире open source идентификации. Его используют стартапы, крупные компании и платформенные команды, строящие внутренние экосистемы вокруг Kubernetes.

Популярность Keycloak объясняется достаточно просто. Он поддерживает практически все основные сценарии корпоративной идентификации: OpenID Connect, SAML, LDAP Federation, многофакторную аутентификацию, управление пользователями, федерацию с внешними каталогами и брокеринг идентичностей.

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

Dex

Если Keycloak напоминает многофункциональный швейцарский нож, то Dex представляет собой его противоположность.

Это лёгкий OpenID Connect-провайдер, который отлично чувствует себя в cloud-native среде и не пытается решить абсолютно все задачи управления идентификацией.

Dex особенно любят за простоту. Он хорошо интегрируется с Kubernetes, Argo CD и внешними источниками идентификации. Если компании требуется лишь выдача OIDC-токенов без сложной логики управления пользователями, Dex оказывается весьма элегантным решением.

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

FreeIPA

FreeIPA многие называют Active Directory для Linux-мира. Это не совсем корректно, но сравнение действительно помогает быстро понять назначение продукта.

FreeIPA объединяет в себе LDAP, Kerberos, DNS, PKI и механизмы применения политик безопасности. Для организаций, эксплуатирующих большое количество Linux-систем, он способен стать фундаментом всей инфраструктуры идентификации.

Вместе с тем FreeIPA требует понимания внутренних механизмов работы. Особенно ярко это проявляется при интеграции с внешними каталогами и историческими системами. Именно здесь инженеры начинают глубже знакомиться с особенностями LDAP-схем, Kerberos и многочисленными нюансами совместимости.

Authentik

Если несколько лет назад разговоры об open source IDM практически всегда сводились к Keycloak, то сегодня всё чаще звучит другое название - Authentik.

Этот проект стремительно набирает популярность, особенно среди команд, которым требуется современное решение без избыточной сложности. Authentik предлагает удобный интерфейс, понятную модель настройки приложений и хорошую интеграцию с Kubernetes-средой. Многие инженеры впервые сталкиваются с ним после очередной попытки разобраться в очередном XML-файле SAML-конфигурации и начинают задаваться вопросом: "А что, так можно было?"

Неудивительно, что всё чаще можно услышать фразу: "Authentik - это Keycloak без Java-боли". Конечно, подобное сравнение несколько упрощает ситуацию. Keycloak значительно старше, функционально богаче и обладает огромной экосистемой. Но нельзя отрицать, что Authentik сумел найти баланс между гибкостью и удобством эксплуатации. Для небольших и средних компаний это часто оказывается серьёзным аргументом в его пользу.

Zitadel

Zitadel относится к новому поколению систем управления идентификацией. В отличие от многих предшественников, он проектировался уже в эпоху облачных платформ, Kubernetes и распределённых архитектур.

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

Пока что Zitadel уступает по популярности более зрелым конкурентам. Однако интерес к нему стабильно растёт. История инфраструктурных инструментов уже не раз показывала, что сегодняшние нишевые решения через несколько лет могут превратиться в новые стандарты.

Authelia

Authelia занимает несколько особое положение среди решений этого класса. Чаще всего её используют не как полноценную IDM-платформу, а как дополнительный уровень защиты внутренних сервисов.

Она отлично справляется с ролью authentication gateway и MFA-прокси. Многие небольшие компании и владельцы домашних лабораторий используют её для защиты внутренних панелей управления, систем мониторинга, медиасерверов и других сервисов, которым требуется современная аутентификация без развёртывания тяжёлой корпоративной платформы.

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

Почему IDM - это боль

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

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

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

  • службы информационной безопасности;

  • инфраструктурных команд;

  • платформенных инженеров;

  • HR-подразделений;

  • аудиторов;

  • руководителей направлений;

  • владельцев бизнес-систем;

  • внешних подрядчиков.

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

  1. Безопасники стремятся минимизировать риски.
  2. Бизнес хочет получать доступ мгновенно.
  3. Разработчики требуют максимальной свободы действий.
  4. Поддержка мечтает о снижении количества заявок.
  5. А руководство ожидает сокращения расходов.

Именно поэтому проекты внедрения IDM часто оказываются не техническими, а организационными инициативами.

Главная проблема IDM

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

Главная проблема - люди.

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

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

При этом практически все уверены, что инциденты происходят где-то в других компаниях.

Поэтому даже самая современная IDM-платформа не способна заменить дисциплину и зрелые процессы. Она лишь помогает сделать правильное поведение более удобным, а неправильное - более заметным.

Типичные проблемы enterprise IDM

Permission Creep

Permission Creep - одна из наиболее распространённых проблем крупных организаций.

Представьте сотрудника, который работает в компании пять или семь лет. За это время он успел сменить несколько проектов, перейти между командами и получить десятки временных доступов. Каждый новый руководитель добавлял ему необходимые привилегии. Никто не занимался отзывом старых. В результате человек постепенно собирает доступы компании подобно тому, как дети собирали карточки Pokémon.

Со временем выясняется, что инженер поддержки способен управлять облачной инфраструктурой, аналитик имеет доступ к production-базам данных, а разработчик мобильных приложений неожиданно оказывается администратором Kafka.

Именно поэтому регулярные ревизии полномочий являются обязательным элементом зрелого IDM.

Shadow Admins

Ещё одна классическая проблема - Shadow Admins. Сценарий всегда выглядит одинаково. Возникает срочная задача. Кому-то временно выдают административный доступ. Через несколько дней кризис заканчивается. Но права забывают отозвать. Проходит месяц. Потом квартал. Потом несколько лет.

Во время очередного аудита обнаруживается учётная запись вроде intern-prod-admin, обладающая практически безграничными полномочиями. И никто уже не может объяснить, каким образом она появилась в системе.

Именно такие находки чаще всего становятся причиной самых нервных встреч с аудиторами.

Legacy Integration Hell

Если существует отдельный круг инфраструктурного ада, то он почти наверняка посвящён интеграции IDM с устаревшими системами.

Новая платформа управления идентификацией должна взаимодействовать с SAP, Oracle, древним LDAP, внутренней CRM, несколькими самописными приложениями и Java-монолитом, разработчик которого уволился восемь лет назад.

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

Именно в этот момент инженеры начинают по-настоящему понимать смысл слова enterprise.

Zero Trust и IDM

За последние несколько лет термин Zero Trust успел превратиться одновременно и в один из важнейших принципов современной безопасности, и в одну из самых затёртых маркетинговых фраз. Его можно встретить в презентациях производителей межсетевых экранов, систем мониторинга, облачных платформ и даже решений, которые к Zero Trust имеют весьма отдалённое отношение.

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

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

Проблема заключалась в том, что мир изменился.

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

Именно поэтому на смену принципу "доверяй, если находишься внутри сети" пришёл принцип "не доверяй никому по умолчанию".

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

  • Кто именно пытается получить доступ?
  • С какого устройства выполняется подключение?
  • Соответствует ли устройство корпоративным требованиям безопасности?
  • Не наблюдаются ли признаки компрометации?
  • Из какой географической точки выполняется вход?
  • Насколько рискованной выглядит текущая активность?

Только после анализа этих факторов принимается решение о предоставлении доступа.

И здесь становится очевидно, почему без зрелого IDM построить Zero Trust практически невозможно.

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

Получается любопытный парадокс.

Многие компании начинают внедрять Zero Trust ради повышения уровня защиты, а в итоге приходят к выводу, что сначала им необходимо навести порядок в идентификациях, группах, ролях и процессах управления доступами. И только потом строить всё остальное.

Passwordless будущее

Если внимательно посмотреть на развитие индустрии, становится очевидно, что эпоха классических паролей постепенно подходит к своему завершению.

Нет, завтра утром пароли не исчезнут. И через год они тоже останутся.

Но их роль будет становиться всё менее значимой.

Причина довольно проста. За несколько десятилетий человечество убедительно доказало, что совершенно не умеет обращаться с паролями.

Люди используют одинаковые комбинации в разных системах. Хранят их в текстовых файлах. Отправляют коллегам через мессенджеры. Пишут на бумажках и приклеивают к мониторам. Создают шедевры вроде CompanyName2026!, Password123 и Qwerty2025.

Именно поэтому индустрия постепенно движется к passwordless-подходам.

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

Всё чаще применяются:

  • аппаратные ключи безопасности;

  • WebAuthn;

  • FIDO2;

  • Passkeys;

  • биометрическая аутентификация;

  • встроенные механизмы современных операционных систем.

Особенно интересны Passkeys.

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

Конечно, переход к passwordless происходит медленно. Во многом этому мешает огромное количество legacy-систем, разработанных в эпоху, когда логин и пароль считались универсальным решением всех проблем.

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

IDM в DevOps-культуре

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

  • Инженеры платформы занимаются Kubernetes.
  • DevOps отвечает за CI/CD.
  • Команды эксплуатации поддерживают инфраструктуру.
  • А доступы пусть выдаёт кто-нибудь другой.

На практике всё устроено совершенно иначе.

Хороший DevOps-инженер достаточно быстро понимает, что практически вся современная инфраструктура вращается вокруг идентичностей.

  • GitLab не может работать без управления пользователями.
  • Argo CD должен понимать, кто имеет право изменять приложения.
  • Vault обязан проверять полномочия перед выдачей секретов.
  • Kubernetes применяет политики RBAC.
  • Облачные платформы используют собственные модели IAM.
  • Даже автоматизация CI/CD невозможна без сервисных аккаунтов и корректного разграничения прав.

Поэтому IDM постепенно становится частью платформенной инженерии.

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

Представьте внутреннюю платформу для разработчиков.

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

Но при этом он не должен случайно удалить production-кластер, изменить системные политики или получить доступ к чужим данным.

Реализовать подобный баланс без зрелой системы идентификации практически невозможно.

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

Что будет дальше

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

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

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

Именно поэтому всё больше внимания привлекают проекты SPIFFE и SPIRE. Они позволяют автоматически выдавать, обновлять и отзывать идентичности рабочих нагрузок. Для мира Kubernetes, где одновременно могут существовать тысячи подов и сервисов, подобный подход становится особенно актуальным.

Третьим важным направлением становится Just-in-Time Access. Его идея удивительно проста.

Если административный доступ нужен человеку только для выполнения конкретной задачи, зачем хранить его постоянно?

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

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

Фактически индустрия постепенно движется от мира "вечных доступов" к миру временных разрешений. И, пожалуй, это одно из самых разумных изменений последних лет. Потому что production должен быть страшным местом. Не настолько страшным, чтобы инженеры боялись к нему прикасаться. Но достаточно серьёзным, чтобы никто не относился к административным полномочиям как к безобидной формальности.

Итог

Если попробовать кратко ответить на вопрос, что такое IDM в современном крупном техе, то ответ получится гораздо короче всей этой статьи.

IDM - это система, которая позволяет компании не потерять контроль над собственной инфраструктурой.

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

Проблема в том, что современная инфраструктура перестала быть простой.

Сегодня даже средняя компания может одновременно использовать несколько облаков, десятки SaaS-сервисов, собственные Kubernetes-кластеры, внутренние платформы разработки, системы мониторинга, средства аналитики и корпоративные приложения. Количество цифровых идентичностей начинает исчисляться не сотнями, а десятками тысяч. Причём речь идёт уже не только о сотрудниках. Полноценными участниками инфраструктуры становятся сервисные аккаунты, приложения, контейнеры, фоновые задачи и автоматизированные процессы.

В такой среде ручное управление доступами перестаёт быть неудобным. Оно становится опасным.

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

Именно поэтому IDM постепенно превращается в один из ключевых элементов корпоративной архитектуры.

Он становится центральной нервной системой безопасности. Через него проходят процессы onboarding и offboarding сотрудников. Он обеспечивает работу единого входа и многофакторной аутентификации. На нём строятся модели разграничения доступа в Kubernetes и облачных платформах. Он помогает проходить аудиты, соответствовать требованиям регуляторов и отвечать на неудобные вопросы безопасников.

Но самое интересное заключается в другом.

Несмотря на огромное количество технологий, протоколов и продуктов, главной задачей IDM остаётся вовсе не защита инфраструктуры от хакеров.

Главная задача - сделать правильное поведение естественным и удобным.

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

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

Хороший IDM практически незаметен. Сотрудники не задумываются о его существовании. Они просто работают.

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

Именно в этом заключается настоящий признак зрелости.

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

Кто-то выбирает Keycloak и получает огромную гибкость ценой дополнительной сложности. Кто-то строит процессы вокруг Microsoft Entra ID и получает прекрасную интеграцию с экосистемой Microsoft. Кто-то делает ставку на Authentik, Dex или FreeIPA. А кто-то вынужден одновременно поддерживать Active Directory, несколько облаков, старый LDAP и пару приложений, написанных во времена, когда Internet Explorer считался вершиной инженерной мысли.

И это нормально.

IDM никогда не был исключительно технологической задачей.

Это компромисс между безопасностью и удобством. Между скоростью бизнеса и требованиями аудита. Между желанием разработчиков получить максимальную свободу и необходимостью защищать критически важные системы.

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

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

  • Здесь невозможно добиться абсолютного совершенства.
  • Всегда останутся унаследованные системы.
  • Всегда будут существовать временные исключения.
  • Всегда найдётся руководитель, которому срочно нужен доступ "буквально на пять минут".
  • Всегда обнаружится сервисный аккаунт, про который никто ничего не знает.

Но именно наличие зрелого IDM позволяет превратить этот хаос в управляемую систему.

А значит, даёт возможность инфраструктуре расти вместе с бизнесом, не превращаясь в набор случайных решений и накопленных компромиссов.

И если посмотреть на развитие отрасли в целом, становится очевидно, что значение идентичности будет только увеличиваться. Zero Trust, Passkeys, Workload Identity, SPIFFE, Just-in-Time Access, краткоживущие учётные данные - всё это разные проявления одной и той же идеи.

В современном мире главным новым периметром становится не сеть. Главным периметром становится идентичность.

Поэтому IDM в крупном техе - это уже не просто система логинов.

Это фундамент Zero Trust. Основа платформенной инженерии. Центральный элемент управления жизненным циклом сотрудников. Механизм автоматизации инфраструктуры. Фундамент Kubernetes RBAC. Инструмент прохождения аудитов.

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

Потому что в мире enterprise существуют две по-настоящему вечные истины.

Доступы всегда выдаются слишком медленно. А root-доступ почти всегда есть у кого-то лишнего.