Дорога к безопасности айдентити: пять шагов или бег с препятствиями
Управление айдентити (пользователями, сервисными учетными записями, компьютерами) – это один из фундаментальных процессов любой ИТ-инфраструктуры. Айдентити определяет, кто и к каким системам имеет доступ, и какие действия допустимы. Без этого невозможно отличить легитимного пользователя от злоумышленника.
Автор статьи для Information Security Лев Овчинников, руководитель продукта Indeed ITDR Индид.
Айдентити по-прежнему остается одной из главных целей для атак. Согласно Microsoft Digital Defense Report 2025, более 97% инцидентов в облаке начинаются с подбора паролей, массовых попыток входа или фишинга, то есть с атак на айдентити, а не на саму инфраструктуру. Причина проста: легитимный доступ труднее обнаружить, чем эксплуатацию уязвимости. Злоумышленник, вошедший под чужой учетной записью растворяется в потоке обычной активности и может долго оставаться незамеченным.
Область управления айдентити существует уже много лет, давно изучена, как и методы атак и защиты. Относительно новыми можно считать облачные системы аутентификации и расширение классических протоколов, вроде Kerberos для работы с облачными средами. Но суть угроз не изменилась – это все та же кража учетных данных и злоупотребление избыточными привилегиями.
Проблема в том, что все это хорошо известно, но на практике часто игнорируется. Управление айдентити исторически остается зоной ответственности ИТ, тогда как ИБ фокусируется на периметре: на межсетевых экранах, рабочих станциях и фишинге. В итоге и возникает серая зона, в которой риск максимален. Граница ответственности между подразделениями стирается: формально отвечают все, а по факту – никто. Именно поэтому злоумышленнику часто не нужно ничего взламывать, достаточно войти с чужими учетными данными.
Давайте разберем ключевые меры защиты айдентити и сложности их внедрения. Главная мысль проста: отдельные шаги защиты больше не работают, и не потому, что меры неправильные, а потому что они применяются разрозненно. Защита айдентити требует комплексного подхода, где каждая мера не существует сама по себе, а усиливает остальные.
Шаг 1. Полный аудит доступа в инфраструктуре
Чтобы принимать обоснованные управленческие решения, нужно объективно понимать текущее состояние управляемой системы и видеть последствия принятых мер.
В процессах управления айдентити это означает, что нужно четко видеть полную и непротиворечивую картину, как используются учетные записи: к каким сервисам они обращаются и какие права при этом получают. В условиях современной инфраструктуры такая картина уже не ограничивается логами контроллеров домена. Она охватывает взаимодействие с системами единого входа (SSO), облачными сервисами аутентификации и специализированными протоколами, а в идеальном случае также включает также историю обращений к приложениям с локальной аутентификацией.
На практике аудит чаще всего строят через SIEM-коннекторы, устанавливаемые на контроллеры домена и, реже, на серверы приложений. Такой подход прост технически и дает быстрый результат, но у него есть минус: в данных остаются пробелы. Как правило, эти пробелы проявляются при разборе инцидентов, когда нехватка информации обходится дороже всего. Логи, собираемые с контроллеров домена, показывают лишь часть картины взаимодействия пользователей и служб сервисов, да и то в довольно специализированном виде, который нужно дополнительно интерпретировать. Например, данные для корреляции отдельных Kerberos-билетов появились в журналах Windows Server только в 2025 г.
Правильно построенная система аудита должна включать этап обогащения данных, когда сырые логи дополняются контекстом, чтобы аналитик SOC смог их нормально понять и использовать. Это означает приведение имен пользователей и служб к единому виду, автоматическую классификацию запросов доступа по функциональным сценариям, а также оценку уровня привилегий задействованных учетных записей. Этап аудита проходят практически все организации, однако полнота и качество его реализации напрямую определяют эффективность всех последующих мер по защите айдентити.
Шаг 2. Сокращение разрешений
В защите айдентити есть две ключевые задачи: предотвратить несанкционированный доступ к ресурсам и снизить ущерб, если он все-таки произошел. Если у каждой учетной записи есть только права, необходимые для выполнения бизнес-функций, то последствия ее компрометации окажутся минимальными.
На практике это реализуется через несколько взаимосвязанных мер. Во-первых, выстраивается процесс оффбординга сотрудников, чтобы доступы вовремя отзывались при увольнении или смене роли. Во-вторых, права администраторов выдаются только отдельным привилегированным учетным записям с повышенными требованиями к защите. В-третьих, ранее выданные разрешения регулярно пересматриваются, чтобы убрать лишние или устаревшие права.
Проще всего внедрять меры на этапе проектирования инфраструктуры, пока число активных пользователей и бизнес-процессов еще не много. Но чаще всего о безопасности задумываются позже, когда ИТ-среда уже сложилась и на ней держится операционная работа бизнеса. В зрелой ИТ-инфраструктуре сокращать лишние привилегии гораздо сложнее. Часто службам ИБ трудно точно определить роли сотрудников: их функции пересекаются, а ролевая модель в системах не совпадает с реальной работой. В таких условиях ключевую роль играют данные аудита доступа, полученные на предыдущем шаге. Именно сведения о том, к каким сервисам пользователь действительно обращается, а не исторически выданные доступы должны определять решение о его разрешениях. Отсюда следует простой вывод: все зависит от качества аудита. Если есть белые пятна – системы, доступ к которым не охвачен аудитом, или нет данных об привилегиях, анализ становится неточным. В итоге приходится опираться на разрозненные и часто субъективные знания о людях и бизнес-процессах, рассредоточенные по подразделениям.
Шаг 3. Внедрение многофакторной аутентификации
По экспертным оценкам, большинство атак с использованием украденных учетных данных можно было бы остановить при помощи многофакторной аутентификации (MFA). Случайно угаданный, подсмотренный или похищенный посредством фишинга пароль открывает злоумышленнику прямой путь внутрь защищенного периметра, где дальше продвигаться вглубь и повышать привилегии ему оказывается значительно проще. Минимизация привилегий ограничивает масштаб такого продвижения, в то время как MFA призвана остановить несанкционированный доступ еще на входе.
Однако на деле возникает противоречие: чем критичнее система, тем сложнее внедрить в нее механизмы MFA. Проще всего многофакторная аутентификация реализуется для современных веб-приложений и облачных SaaS-сервисов, при этом СУБД, административные консоли и общие сетевые папки чаще всего остаются незащищенными. Как следствие, рядовые пользователи сталкиваются с неудобствами и сопротивляются внедрению, а администраторы в технически сложных сценариях просто обходят механизмы MFA, потому что для них она так и не была реализована.
Чтобы инструменты MFA действительно снижали риски компрометации айдентити, их необходимо внедрять не в тех системах, где это технически удобно, а там, где риск взлома и его последствия максимальны. Для этого нужны решения, которые охватывают все ресурсы и протоколы в инфраструктуре – включая те, которые не поддерживают многофакторную аутентификацию в стандартной конфигурации.
Многие популярные MFA-решения основаны на расширении функционала приложений или операционных систем при помощи специализированных агентов. Зачастую в крупных инфраструктурах надежно выполнить этот шаг не удается даже при значительных инвестициях. Агент не будет установлен на устройстве внешнего подрядчика, его не будет в системах после слияний и поглощений компаний, а какие-то подразделения вообще нередко самостоятельно закупают и развертывают программное обеспечение без согласования со службами ИБ и ИТ. В итоге конфиденциальные данные оказываются вне зоны контроля.
Альтернативой являются MFA-решения, основанные на прокси-серверах и перехвате трафика. Они могут перехватывать запросы доступа к максимально широкому кругу систем и запрашивать дополнительный фактор аутентификации до того, как пользователь получит доступ. Даже если целевая система не поддерживает MFA напрямую. Это позволяет, например, включить многофакторную аутентификацию для всех критичных пользователей, независимо от того, к какому приложению они обращаются.
Шаг 4. Регулярный аудит конфигураций
На практике менее половины компаний останавливаются на внедрении дополнительного фактора аутентификации, считая задачу решенной. Даже при полном покрытии пользователей MFA и строгом ограничении прав сервисные учетные записи остаются вне этой защиты. К ним нельзя применить MFA, а управление их разрешениями подчиняется другим процессам и логике, чем для живых пользователей.
Да, можно регулярно менять пароли при помощи gMSA или систем типа HashiCorp Vault – и это хорошее решение. Но частая проблема в другом: злоумышленник компрометирует сам сервис и использует уже авторизованную сервисную учетную запись для продвижения по инфраструктуре. Эта проблема становится актуальным сценарием: по данным Microsoft за 2025 г., такие атаки становятся все более распространенными, поскольку, позволяют обходить MFA и сохранять закрепление внутри периметра даже после смены паролей.
Дополнительный риск создают настройки в Active Directory и других системах управления доступом. Они расширяют возможности администрирования, но при их неосторожном использовании открывают новые векторы атак, даже для опытных администраторов.
Речь идет, например, об атрибутах msDS-AllowedToActOnBehalfOfOtherIdentity, msDS-AllowedToDelegateTo, msDS-ManagedAccountPrecededByLink, правах на запись в каталоге LDAP, а также разрешениях на доступ к общим файловым ресурсам. Известен случай, когда из-за ошибочно выданных прав злоумышленник подменил дистрибутивы ПО, и вредоносный код был автоматически установлен на большинстве рабочих станций организации.
Схожая угроза это устаревшие протоколы и режимы работы с известными уязвимостями, используемые в инфраструктуре ради совместимости со старыми приложениями и устройствами. Зачастую такие протоколы продолжают быть активными даже тогда, когда сами приложения и устройства выведены из эксплуатации! Классический пример – протокол NTLM. Его отключение выглядит логичным, но при наличии старых систем или приложений его отключение может остановить бизнес-процессы
Здесь, как и в предыдущих шагах, все упирается в качественный аудит запросов доступа. Зная, что тот или иной устаревший протокол фактически не используется, руководитель ИБ может запретить его без риска нарушить работу бизнеса; обнаружив отдельные уязвимые компоненты – принять адресные меры по их обновлению и дополнительной защите. Там же, где запросы с использованием уязвимых протоколов перехватываются в реальном времени, появляется наиболее гибкое решение: избирательно разрешать такой доступ только тем устройствам и учётным записям, для которых он действительно необходим, не затрагивая остальную инфраструктуру.
Шаг 5. Обнаружение признаков компрометации
Как бы хорошо не была выстроена защита, нельзя полностью исключить ситуацию, когда злоумышленник все-таки получает доступ через скомпрометированные учетные данные к какому-либо ресурсу внутри периметра. Этот ресурс почти никогда не является конечной целью атаки, за ним следует длительное продвижение вглубь инфраструктуры: разведка, выбор тактики, последовательное повышение привилегий. Этот процесс занимает время, и именно здесь открывается шанс остановить атаку.
Первый час после первичного проникновения называют золотым: по данным CrowdStrike Global Threat Report 2025, в среднем злоумышленник начинает горизонтально перемещаться по сети через 48 минут, а в наиболее стремительных атаках менее чем через минуту. Если обнаружить его в этот период, масштаб ущерба резко снижается.
Первое типовое решение – правила корреляции в SIEM. Тем не менее золотой час нередко оказывается упущен. Причина в том, что даже сработавшая корреляция направляется на расследование в SOC, где за короткое время не всегда успевают провести полноценный анализ и принять ограничительные меры. Для реализации этих мер часто подключается отдел инфраструктуры, и согласование действий между подразделениями растягивается на часы или даже дни.
Второе распространенное решение – системы обнаружения и предотвращения сетевых атак. Они способны распознавать признаки разведки и попыток повышения привилегий, но в большинстве случаев стоят на границе сетевого периметра. А значит, то, что происходит внутри периметра, крайне редко подвергается тотальному анализу. Кроме того, многие действия, характерные для разведки и повышения привилегий, внешне слабо отличимы от легитимной активности других пользователей. Все решает контекст: какая учетная запись выполняет эти действия, с какого устройства, что делал этот пользователь до этого. Даже относительно простые системы детектирования, встроенные прямо в инфраструктуру айдентити и учитывающие ее контекст, могут сильно усложнить злоумышленнику действия в «золотой час». А если еще добавить автоматическое реагирование, то такие системы могут блокировать подозрительную активность еще до того, как SOC успеет приступить к расследованию, и таким образом дать аналитикам достаточно времени, чтобы взять ситуацию под контроль.
Пять шагов или пять препятствий?
Каждый из описанных шагов хорошо известен любому специалисту по ИБ или архитектору в области айдентити. Более того, под каждый шаг уже есть решения, которые частично или полностью автоматизирует его реализацию: сбор журналов с контроллеров домена, аудит конфигураций, многочисленные решения для MFA. Тем не менее доля айдентити, как вектора успешной первичной атаки не сокращается, а растет. Анализ показывает закономерность: из пяти шагов в инфраструктуре в лучшем случае пройдены три, причем с ошибками и пробелами. То что на бумаге выглядит простым, на практике превращаются в бег с препятствиями.
Объяснений этому феномену можно найти немало: усложнение инфраструктуры айдентити вследствие распространения облачных систем, требования к импортозамещению, размытая зона ответственности между ИТ и ИБ. Но главная проблема глубже – отсутствие системного комплексного подхода к защите. Если аудит сделан плохо, то невозможно нормально ограничить привилегии и контролировать сервисные учетные записи. В то же время, когда аудит конфигураций поверхностный, то MFA не покрывает самые рискованные сценарии. В итоге даже при формально внедренной технологии вероятность успешного проникновения остается высокой, так как защита работает не как единая система, а как набор отдельных несвязных мер.
Большинство решений для защиты айдентити устроены по тому же принципу: они хорошо закрывают одну конкретную задачу, часто только для определенного типа инфраструктуры. Но реальные инфраструктуры сложнее и столь же разнообразны, сколь разнообразны бизнес-сценарии, которые они обеспечивают. Большинство экспертных рекомендаций по-прежнему направлены на устранение точечных слабостей – значимых и актуальных, но лишь для ограниченного круга инфраструктур.
Комплексный подход к защите айдентити – это не новая технология, а скорее новая необходимость. Пока ее еще не все осознали, но разрыв между уровнем защиты, которого ожидает бизнес, и тем, что дает традиционный подход, с каждым годом становится очевиднее. При этом меры защиты не меняются, а объединяются, усиливая друг друга и покрывая инфраструктуру максимально полно. Многие вендоры, работающие в области Identity Security, поддержали необходимость создания решений класса ITDR (Identity Threat Detection and Response – обнаружение и реагирование на угрозы идентификации). Возможно, именно это постепенное, но необратимое изменение сделает путь к защищенной инфраструктуре айдентити не столь тернистым, каким он остается сегодня.
