Наличие IAM-платформы не гарантирует безопасность. Большинство провалов связано с типовыми ошибками архитектуры и процессов, а не с уязвимостями кода. На примере реальных инцидентов разбираем 10 ключевых ошибок при настройке IAM, которые превращают систему управления доступом в источник угроз.
- 1. Введение
- 2. Ошибка 1. Ручное управление жизненным циклом учётных записей
- 3. Ошибка 2. Нарушение принципа наименьших привилегий
- 4. Ошибка 3. Стратегический провал в управлении доступом
- 5. Ошибка 4. Слабая аутентификация для критичных активов
- 6. Ошибка 5. Неправильная настройка периферийных устройств удалённого доступа
- 7. Ошибка 6. Небезопасное хранение секретов
- 8. Ошибка 7. IAM не ограничивает перемещение внутри сети
- 9. Ошибка 8. Отсутствие мониторинга и реагирования на аномалии в поведении
- 10. Ошибка 9. Неконтролируемые технические учётные записи
- 11. Ошибка 10. IAM как технический проект, а не часть культуры безопасности
- 12. Выводы
Введение
Компрометация учётных данных остаётся одним из ключевых факторов киберинцидентов. По данным Verizon Data Breach Investigations Report, использование украденных или скомпрометированных учётных записей стало самым распространённым вектором начального доступа — чаще, чем эксплуатация уязвимостей или фишинг.
Аналитики Solar 4RAYS отмечают, что значительную долю рисков создают незаблокированные аккаунты уволенных сотрудников, отсутствие автоматизации управления доступом и компрометация учётных данных подрядчиков.
На этом фоне управление идентификацией и доступом (Identity and Access Management, IAM) становится ключевым элементом архитектуры безопасности. Современная модель предполагает не просто внедрение IAM-платформы, а построение целостной системы Identity Security. В её состав входят инструменты управления жизненным циклом учётных записей и прав доступа (IGA), решения для контроля привилегированных пользователей (PAM), а также механизмы аутентификации и авторизации. Вместе они формируют замкнутый контур: от создания идентичности до регулярной проверки обоснованности её прав.
Для российских организаций IAM — это не только вопрос зрелости безопасности, но и обязательное условие регуляторов. Стандарты ГОСТ Р 58833‑2020, ГОСТ Р 70262.1‑2022 и ГОСТ Р 71753‑2024 задают единые требования к идентификации, аутентификации и управлению доступом.
При этом наличие внедрённого решения само по себе не снижает риски. Практика показывает: инциденты чаще связаны не с отсутствием технологий, а с просчётами в проектировании процессов, разрозненностью инструментов и формальным подходом к управлению доступом. Именно повторяющиеся архитектурные ошибки становятся причиной компрометации даже в организациях с развитой ИТ-инфраструктурой.
Ошибка 1. Ручное управление жизненным циклом учётных записей
Управление жизненным циклом идентификаций — базовый процесс в системах управления идентификацией (Identity Management, IdM). Он определяет, как в инфраструктуре создаются, изменяются и выводятся из эксплуатации учётные записи сотрудников, подрядчиков и сервисных пользователей на всех этапах их взаимодействия с компанией: при приёме на работу, изменении роли и увольнении.
Проблема возникает, когда этим процессом управляют вручную: через почту, тикеты и разрозненные согласования, без автоматической синхронизации с HR-системой. Статус сотрудника в кадровой системе уже может быть изменён, а его аккаунты в Active Directory, облачных сервисах и бизнес-приложениях остаются активными. Так появляются «бесхозные» учётные записи, не привязанные к текущей бизнес-необходимости.
Такие аккаунты становятся удобной точкой входа для злоумышленников. Их компрометация соответствует технике Valid Accounts (T1078) в матрице MITRE ATT&CK. Расследовать эти инциденты сложнее, ведь в логах всё выглядит как обычная деятельность сотрудника.
Пример: атаки на облачную инфраструктуру Amazon Web Services
В конце 2025 года исследователи зафиксировали масштабную криптомайнинговую кампанию в Amazon Web Services (AWS). Атака началась с компрометации IAM-пользователя с административными правами.
Для разведки злоумышленники применяли вызов API RunInstances с флагом DryRun, проверяя доступ без фактического создания ресурсов.
Затем скрипты на базе Boto3 массово создавали кластеры Amazon ECS с вредоносным контейнером. Настраивались группы Auto Scaling на сотни GPU-инстансов (арендованных виртуальных машин) для майнинга. Для сохранения доступа блокировалось удаление инстансов и создавались бэкдоры в виде публичных функций AWS Lambda и новых IAM-пользователей.
AWS подтвердила, что атака не была связана с уязвимостью инфраструктуры, а полностью основана на компрометации IAM-учётных данных. Компания рекомендовала клиентам ужесточить политики доступа и усилить мониторинг подозрительных действий.
Чем опасна ошибка
Неотозванные и устаревшие учётные записи превращаются в легальные точки входа в инфраструктуру. Атака в этом случае происходит от имени формально действующего пользователя, поэтому в журналах событий она выглядит как обычная активность, что существенно усложняет своевременное выявление и последующее расследование.
Дополнительный риск связан с управляемостью: при ручном администрировании невозможно гарантировать, что все права отозваны полностью и синхронно во всех системах. В результате формируются «остаточные» доступы, которые могут сохраняться месяцами.
Такая практика также противоречит регуляторным требованиям. Нормативные документы ФСТЭК и положения ГОСТ Р 70262.1-2022 предусматривают контроль жизненного цикла идентификаторов и своевременное прекращение прав доступа при изменении статуса пользователя. Отсутствие автоматизации делает доказуемость этого контроля проблематичной.
Рисунок 1. Модель управления жизненным циклом учётных записей и прав доступа
Ошибка 2. Нарушение принципа наименьших привилегий
Принцип наименьших привилегий (Principle of Least Privilege, PoLP) предполагает, что пользователи, сервисные учётные записи и роли получают исключительно те права доступа, которые необходимы для выполнения конкретных рабочих задач, в пределах определённого времени и установленного контекста.
Ошибка возникает, когда PoLP нарушается на уровне повседневных операций:
- права, выданные для проекта, остаются активными после его завершения;
- при переводе сотрудника в другой отдел к его новым ролям добавляются старые доступы;
- временные административные привилегии не имеют срока действия;
- сервисным и техническим аккаунтам назначаются максимальные роли «про запас».
В результате права накапливаются, а реальный уровень доступа пользователя или системы давно не соответствует его текущим задачам. Особенно критична эта ситуация для привилегированных учётных записей — администраторов и сервисных ролей с расширенными правами.
Именно такие аккаунты остаются ключевой «ахиллесовой пятой» корпоративной защиты. В промышленном секторе до 80 % атак начинаются не с эксплуатации уязвимостей, а с использования скомпрометированных учётных данных с избыточными правами.
Пример: атака на Uber через цепочку избыточных доступов
Всё началось с банальной утечки пароля учётной записи внешнего подрядчика. Злоумышленник купил эти данные на теневом форуме, а защиту MFA обошёл с помощью атаки на утомление (MFA Fatigue) — просто засыпав владельца push-уведомлениями до момента подтверждения.
Попав в сеть, атакующий нашёл на общедоступном ресурсе PowerShell-скрипт. В нём в открытом виде лежали учётные данные администратора системы контроля привилегий (PAM).
Используя эти данные, злоумышленник легитимно вошёл в PAM-систему и получил доступ к корпоративным коммуникациям (Slack), рабочему пространству (Google Workspace), порталу программы Bug Bounty (HackerOne) и финансовым системам.
Нарушение принципа PoLP здесь было двойным: у подрядчика оказались ненужные для текущих задач доступы, и критичные пароли хранились в незащищённом скрипте.
Чем опасна ошибка
Компрометация учётной записи с избыточными правами позволяет атакующему перемещаться по инфраструктуре и получать доступ к системам, не связанным с исходной ролью пользователя. При этом вся активность выглядит легитимной для системы мониторинга (Security Information and Event Management, SIEM) и журналов доступа.
Такая практика также прямо нарушает требования регуляторов: ГОСТ Р 70262.1-2022 и указания ФСТЭК. Они предписывают предоставлять пользователям минимально необходимый набор привилегий и своевременно их отзывать.
Ошибка 3. Стратегический провал в управлении доступом
Частая ошибка — внедрение инструментов IAM без развёртывания полноценной системы управления идентификацией и доступом (Identity Governance and Administration, IGA). Если IAM-система — это движок, который исполняет политики («разрешить или запретить»), то IGA —система управления, которая создаёт, проверяет, актуализирует эти политики и доказывает их корректность.
Проблема возникает, когда процессы управления доступом не формализованы. Это проявляется в следующем.
Нет эталонной модели ролей. Права «приклеиваются» к конкретным людям или системам, а не к бизнес-функциям. Вместо роли «Работник с первичными документами в 1С» создаётся роль «Бухгалтер отдела А». Из-за этого автоматизация управления доступом становится невозможной.
Разрозненные данные. Информация об учётных записях хранится в HR-системе, облачных каталогах, Excel-таблицах и базах приложений. Без синхронизации статус сотрудника в HR может быть «уволен», а его аккаунты в CRM и других системах — активны.
Процессы не формализованы. Запрос, согласование и отзыв прав происходят в почте и чатах. Права отзываются не при изменении бизнес-необходимости, а по остаточному принципу.
Аудит отсутствует или эпизодичен. Пересмотр и подтверждение прав (сертификация) выполняются нерегулярно, часто уже после инцидента, вместо того чтобы быть непрерывным процессом.
Пример: утечка через сохранённые или избыточные привилегии сотрудников
В июле 2020 года в Twitter (ныне — социальная сеть «X») злоумышленники получили доступ к более чем 130 аккаунтам известных политиков и публичных фигур для публикации мошеннических сообщений. Атака произошла не из‑за уязвимости сервиса, а через компрометацию внутренних учётных данных сотрудников с помощью социальной инженерии. Получив доступ к внутренним административным инструментам, они могли сбрасывать пароли и публиковать сообщения от имени известных пользователей. Инцидент показал недостатки контроля привилегированных внутренних доступов и управления жизненным циклом учётных записей.
Чем опасна ошибка
Отсутствие IGA приводит к тому, что в компании не реализована ни ролевая (Role-Based Access Control, RBAC), ни атрибутивная (Attribute-Based Access Control, ABAC) модель управления доступом. Права назначаются напрямую пользователям и сервисам, без формализованных ролей и контекстных правил.
В результате невозможно корректно автоматизировать управление жизненным циклом учётных записей: нет правил — нечего исполнять. Принцип PoLP становится недостижимым, ведь нет эталона минимальных прав. Системы анализа поведения пользователей (User and Entity Behavior Analytics, UEBA) теряют контекст для выявления аномалий.
Соответствие требованиям регуляторов (ГОСТ Р 70262.1-2022, ФСТЭК) становится недоказуемым из-за отсутствия централизованного аудита и обоснования прав.
Ошибка 4. Слабая аутентификация для критичных активов
Недостаточно строгая многофакторная аутентификация (Multi-Factor Authentication, MFA) остаётся одной из самых серьёзных ошибок при защите доступа. Во многих организациях MFA внедряется формально и одинаково для всех пользователей — без учёта уровня привилегий и критичности ресурсов.
На практике это сводится к использованию уязвимых механизмов: SMS-кодов, одноразовых паролей по электронной почте или простых push-уведомлений. Такие методы легко обходятся фишингом, SIM-свопингом (SIM swapping, кражей номера телефона), компрометацией почты и атаками на утомление (MFA Fatigue), когда пользователь в итоге подтверждает вход под давлением потока запросов.
Для привилегированных аккаунтов и критичных сервисов такой подход недопустим. Компрометация одной административной или сервисной учётной записи даёт злоумышленнику контроль над всей средой. Защита этих ролей требует применения устойчивых к фишингу методов (phishing-resistant MFA): аппаратных ключей FIDO2/WebAuthn, сертификатной аутентификации и других механизмов с криптографической привязкой к устройству, исключающих перехват второго фактора.
Отдельный риск создаёт ставка на единственный метод MFA без продуманного резервного сценария. Даже надёжные механизмы могут временно оказаться недоступны — устройство утеряно, биометрия не работает, нет сетевого подключения. Решение должно предусматривать безопасные альтернативные методы, не снижающие уровень защиты.
Пример: атака на энергетическую инфраструктуру Польши
В декабре 2025 года польская энергетическая система подверглась масштабной кибератаке, которую эксперты связывают с российской APT‑группировкой Sandworm. Злоумышленники развернули деструктивное ПО DynoWiper, предназначенное для уничтожения данных на серверах и рабочих станциях.
Инцидент начался с получения доступа к привилегированным учётным записям домена. Одним из векторов могли быть внешние панели управления или точки удалённого доступа, защищённые недостаточно строгой аутентификацией. Получив высокие права, атакующие не только развернули вредоносные программы в ИТ‑сегменте, но и лишили операторов инструментов контроля над инфраструктурой, значительно усугубив последствия.
Чем опасна ошибка
Слабая или формальная многофакторная аутентификация (MFA) создаёт лишь видимость защиты, если не применяется ко всем критическим точкам входа. На практике уязвимыми остаются VPN-шлюзы, внешние панели администрирования, интерфейсы удалённого доступа, облачные консоли и доступы к OT-сегменту.
Получив учётные данные легитимного пользователя, атакующий действует в рамках разрешённых с точки зрения системы сессий. Периметровые средства защиты — межсетевые экраны, системы обнаружения вторжений (IDS/IPS) — в такой ситуации теряют значительную часть эффективности, поскольку активность выглядит как нормальная работа авторизованного аккаунта.
В промышленной среде компрометация учётной записи оператора или инженера способна привести к остановке процессов, нарушению технологических режимов, повреждению оборудования и потенциальному экологическому ущербу. Именно поэтому защита привилегированных и удалённых доступов должна рассматриваться как часть стратегии Identity Security, а не как вспомогательная мера.
Ошибка 5. Неправильная настройка периферийных устройств удалённого доступа
VPN‑шлюзы, маршрутизаторы, межсетевые экраны и системы удалённого доступа часто воспринимают как обычное сетевое оборудование, а не как критические точки входа в инфраструктуру. И управление доступом к ним напрямую связано с задачами IAM и PAM. Ошибки в их настройке часто становятся причиной серьёзных рисков.
На практике такие устройства нередко администрируются через учётные записи с избыточными правами. Многофакторная аутентификация либо отсутствует, либо реализована формально. Пароли могут не меняться годами, а доступы уволенных сотрудников продолжают работать. При этом действия администраторов не записываются, поэтому восстановить хронологию событий при инциденте крайне сложно.
Периферийные устройства находятся на границе сети и обрабатывают весь трафик. Ошибки в настройке превращают их в удобную точку скрытого проникновения. Получив доступ к такому устройству, злоумышленник может обходить внутренние механизмы контроля — антивирусы, SIEM-платформы, системы обнаружения и реагирования на инциденты на конечных точках (Endpoint Detection and Response, EDR) — и закрепляться в инфраструктуре под видом легитимного пользователя или сетевого узла.
Пример: атаки APT44
В декабре 2025 года группа Amazon Threat Intelligence опубликовала результаты многолетнего анализа активности группировки APT44 (Sandworm, Seashell Blizzard), которую власти США связывают с российским ГРУ. Исследование показало тактический сдвиг: вместо активной эксплуатации сложных уязвимостей «нулевого дня» атакующие всё чаще делали ставку на неправильно сконфигурированные периферийные устройства клиентов.
В ряде инцидентов доступ к VPN-шлюзам и маршрутизаторам в облаке (включая AWS) был получен не из-за уязвимостей облачного провайдера, а из-за неправильных настроек самого заказчика. Используя легитимные функции сетевых устройств, атакующие перехватывали трафик и учётные данные для последующего проникновения в корпоративные системы. Основными целями стали организации энергетического сектора и их подрядчики в Европе и Северной Америке.
Чем опасна ошибка
Компрометация сетевого шлюза нейтрализует саму идею периметровой защиты. Весь трафик злоумышленника становится «доверенным» для внутренних систем, сводя на нет эффективность IDS/IPS. Получив контроль, атакующий может перенаправлять, блокировать или подменять данные, маскируя свою активность и усиливая ущерб.
Отсутствие централизованного сбора логов с этих устройств делает расследование почти невозможным. Невосстановимая цепочка событий не позволяет определить масштаб компрометации и правильно локализовать инцидент. Для компаний с распределённой и облачной инфраструктурой такая ошибка создаёт устойчивый плацдарм для длительных целевых атак.
Ошибка 6. Небезопасное хранение секретов
Секреты — это цифровые ключи от критически важных систем компании. К ним относятся API-токены, пароли сервисных учётных записей, приватные SSH- и криптографические ключи. Грубой ошибкой является их хранение вне специализированных защищённых хранилищ: в коде приложений, конфигурационных файлах (.env, config.yaml), Docker-образах, документации, чатах или истории Git-репозиториев.
Такая практика нарушает базовый принцип DevSecOps — разделение кода и конфигурации. Уязвимость становится статичной: для компрометации не нужен эксплойт, достаточно доступа к репозиторию или резервной копии, чтобы получить прямые ключи от инфраструктуры.
Особенно критично, когда секреты попадают в неконтролируемые среды: публичные репозитории, сторонние облачные сервисы или ИИ-платформы. В этом случае невозможно обеспечить конфиденциальность, контроль доступа и гарантированное удаление, даже если прямого взлома не происходило.
Пример: утечки на GitHub
По данным исследований GitHub и независимых аналитиков, только за 2023 год в открытых репозиториях было обнаружено более 12 миллионов опубликованных секретов: API-ключей, токенов доступа и паролей. Утечки затронули миллионы публичных репозиториев, причём значительная часть ключей оставалась действующей в течение нескольких дней или недель после публикации, прежде чем их отзывали владельцы.
Из-за сохранения истории коммитов (снимки состояния проекта в определённый момент времени) даже удаление файла не устраняет проблему: секрет остаётся доступным в предыдущих версиях репозитория и может быть автоматически найден с помощью специализированных сканеров, которыми активно пользуются как киберпреступники, так и APT-группировки.
Чем опасна ошибка
Компрометация секрета даёт злоумышленнику валидный ключ, с которым он действует как легитимный пользователь или сервис, получая доступ к облачным аккаунтам, базам данных и системам CI/CD. Поскольку операции выполняются от имени доверенного токена, они не вызывают срабатывания SIEM и других систем мониторинга, что позволяет атаке оставаться незамеченной длительное время.
При утечке ключей разработки или сборки атакующий может внедрить вредоносный код в цепочку поставок программного обеспечения, распространив атаку на клиентов и партнёров.
Отсутствие централизованного учёта и контроля секретов делает невозможным точное определение момента компрометации и гарантированный отзыв всех копий, закрепляя последствия инцидента.
Рисунок 2. Рост числа утечек секретов на GitHub
Рисунок 3. Топ‑10 секретов, утёкших на GitHub в 2024 году
Ошибка 7. IAM не ограничивает перемещение внутри сети
Управление доступом должно работать не только на входе, но и внутри сети. Иначе пользователь или сервис, получив доступ, оказывается внутри «плоской» инфраструктуры и может свободно перемещаться между системами. Это создаёт идеальные условия для бокового перемещения злоумышленника после первоначального взлома.
Современная архитектура безопасности требует ограничивать перемещение внутри сети. Это достигается двумя взаимодополняющими подходами.
Первый — сетевая сегментация: разделение инфраструктуры на изолированные зоны с помощью VLAN, виртуальных файрволов или других механизмов контроля трафика.
Второй — сегментация на основе идентификации, применяемая в концепции нулевого доверия (Zero Trust). В этом случае доступ определяется не расположением в сети, а контекстом: ролью, устройством, уровнем риска и конкретным ресурсом. IAM, интегрированный с решениями Zero Trust, предоставляет доступ не ко всей сети, а только к тем приложениям и сервисам, которые разрешены политиками для данной роли.
Пример: массовое заражение через Kaseya VSA
В 2021 году группировка REvil провела цепную атаку, использовав уязвимость в платформе управления Kaseya VSA. Они скомпрометировали серверы управляемых сервис-провайдеров (MSSP), которые администрировали с её помощью сети своих клиентов.
Ключевой ошибкой, усугубившей последствия, стало полное отсутствие сетевой сегментации между клиентами одного провайдера. Вредоносные программы, внедрённые в Kaseya VSA, беспрепятственно распространились с серверов MSSP прямо в сети всех их заказчиков. В результате одна точка входа привела к заражению более 1500 компаний по всему миру.
Чем опасна ошибка
Компрометация одной учётной записи способна вызвать полномасштабное заражение всей инфраструктуры, а без внутренних барьеров практически невозможно локализовать распространение атаки, будь то ransomware (программное вымогательство) или действия злоумышленника.
Такая архитектура разрушает принцип Zero Trust: после проверки доступа пользователь получает неограниченные права, что делает бессмысленной саму идею «не доверяй, проверяй каждый запрос». Кроме того, отсутствие сегментации напрямую противоречит требованиям регуляторов. Например, для АСУ ТП и обработки персональных данных предписывают обязательное разделение сетей по уровню критичности информации.
Ошибка 8. Отсутствие мониторинга и реагирования на аномалии в поведении
Ключевая ошибка заключается не в самом IAM, а в его изоляции от систем мониторинга и реагирования. IAM часто воспринимается как завершённый контур контроля, задача которого — выдать или отказать в доступе, после чего дальнейшая активность пользователя остаётся вне поля зрения безопасности.
В такой архитектуре IAM не выступает источником контекстуальных данных для SIEM, UEBA и XDR. В системы мониторинга либо вовсе не передаются события доступа, либо они поступают в усечённом виде — без информации о роли пользователя, типе учётной записи, уровне привилегий, источнике доступа и актуальности выданных прав. В результате события авторизации и действий внутри приложений лишаются критически важного контекста: невозможно определить, кто именно выполняет действие, допустимо ли оно для данной роли и соответствует ли текущему статусу пользователя.
Без этой интеграции аналитика поведения становится формальной. SIEM фиксирует отдельные технические события, но не способен выявлять аномалии: например, резкое изменение модели доступа, нетипичную активность администратора, массовые операции с данными или использование привилегий за пределами служебных задач. Формально доступ легитимен, но его использование остаётся неконтролируемым.
Пример: массовая утечка документов Пентагона
В 2023 году рядовой Национальной гвардии Джек Тейшейра, имея законный доступ к секретным документам как ИТ‑специалист, систематически выносил и публиковал их в закрытых чатах Discord. Он скачивал материалы, не относящиеся к его служебным обязанностям, включая документы высшей категории секретности.
Внутренние системы мониторинга и IAM не выявили аномальные действия, так как доступ считался легитимным. Инцидент был раскрыт только после публикации документов в открытых источниках и расследования СМИ, что сделало предотвращение ущерба невозможным.
Чем опасна ошибка
Злоумышленник или недобросовестный сотрудник, используя легитимные учётные данные, остаётся невидимым для систем безопасности: формально его действия корректны, и он находится в «слепой зоне» контроля. Инциденты обычно выявляются только постфактум, когда данные уже похищены, системы повреждены или внедрены вредоносные программы, и время на реакцию и локализацию равно нулю.
Без детализированных логов сессий, записей действий и их контекста команда SOC не может восстановить полную цепочку событий, оценить масштаб ущерба и определить все затронутые системы.
Ошибка 9. Неконтролируемые технические учётные записи
Сервисные учётные записи (или технические учётные записи, ТУЗ) — это аккаунты, от имени которых работают приложения, базы данных и автоматизированные процессы. Их главная проблема в том, что они не вписываются в стандартную модель управления доступом, построенную вокруг человека.
Они выпадают из поля зрения IGA, потому что у них нет «менеджера» в HR-системе, который мог бы запросить для них доступ или подтвердить его актуальность. И они часто остаются вне контроля PAM-систем, потому что их пароли и ключи десятилетиями лежат в конфигурационных файлах, а не в защищённых хранилищах. По сути, это «невидимые сотрудники» с огромными привилегиями, но без ответственного владельца и жизненного цикла.
Пример: цепная компрометация через атаку Kerberoasting
Суть атаки Kerberoasting заключается в краже и последующем взломе паролей служебных учётных записей Active Directory. Для начала атаки злоумышленнику достаточно получить контроль над любой учётной записью обычного пользователя домена, права администратора не требуются. Используя эти легитимные учётные данные, атакующий запрашивает у контроллера домена служебные билеты Kerberos для аккаунтов, связанных со службами (имеющих атрибут Service Principal Name, SPN). Эти билеты зашифрованы хешем пароля соответствующей ТУЗ.
Ключевой этап происходит офлайн. Атакующий выгружает украденные билеты за пределы сети и с помощью инструментов для взлома паролей методом перебора пытается расшифровать пароль. Если пароль ТУЗ слабый, предсказуемый или не менялся годами, его взлом — вопрос времени. Успех даёт злоумышленнику полный контроль над скомпрометированной служебной учётной записью и всеми её привилегиями, что часто позволяет перемещаться по сети, повышать права и получать доступ к критическим данным и системам.
Чем опасна ошибка
Неконтролируемые технические учётные записи создают в инфраструктуре долгоживущие слепые зоны. Поскольку такие идентичности не проходят процессы централизованного управления и не имеют ответственного владельца, они продолжают существовать независимо от кадровых изменений и трансформации ИТ-ландшафта. Скомпрометированный сервисный аккаунт может оставаться активным годами, обеспечивая злоумышленнику устойчивый, скрытый и практически неотслеживаемый доступ.
Рисунок 4. Протокол Kerberos и процесс обмена данными
Ошибка 10. IAM как технический проект, а не часть культуры безопасности
Даже самый продвинутый IAM‑проект не работает, если его рассматривают исключительно как инженерную систему. Ключевая ошибка — отсутствие культуры безопасности, в которой управление доступом встроено в повседневные процессы компании. Когда IAM существует отдельно от бизнеса, он превращается в набор технических инструментов, которые никто не считает своей зоной ответственности: руководство не видит стратегической ценности, сотрудники обходят правила ради удобства, а служба безопасности воспринимается как источник ограничений.
Правила вводятся без объяснения рисков, и сотрудники начинают их обходить: делятся паролями, передают учётные данные подрядчикам, запрашивают избыточные права «на всякий случай». В результате формально настроенный IAM сосуществует с неформальными практиками, которые полностью обнуляют технический контроль.
В ряде случаев IAM внедряется ИТ‑подразделением без интеграции в бизнес‑процессы. Найм, переводы, смена проектов и увольнение сотрудников остаются ручными и разрозненными. Процессы управления жизненным циклом учётных записей не автоматизированы, согласования происходят по инерции, а пересмотр прав носит формальный характер. Со временем система накапливает устаревшие и избыточные доступы и перестаёт выполнять свою основную функцию — управление рисками.
Без назначенного руководителя по информационной безопасности, ответственного за IAM, и без дорожной карты с метриками, связывающими систему с бизнес‑результатами (снижение операционных рисков, ускорение онбординга, прозрачность доступа), проект остаётся на уровне «ещё одной ИТ‑системы». Формально он есть, но поведение людей и реальный уровень риска почти не меняются.
Пример: атака на Clorox через социальную инженерию
В инциденте с Clorox злоумышленники из группировки Scattered Spider получили доступ в инфраструктуру компании не за счёт технических уязвимостей, а через ошибку в процедуре верификации личности. Атакующие позвонили в службу поддержки ИТ‑поставщика Cognizant, представились сотрудниками Clorox и убедили инженера выдать пароль от рабочей учётной записи. Стандартные проверки подлинности личности были проигнорированы, что сделало выдачу учётных данных возможной.
Полученная учётная запись обеспечивала широкий доступ к внутренним системам Clorox. Этого оказалось достаточно, чтобы развернуть вредоносные программы, нарушить работу ключевых сервисов и провести масштабную ransomware‑атаку. По оценкам компании, совокупный ущерб превысил 380 млн долларов США.
Чем опасна ошибка
Отсутствие культуры безопасности вокруг IAM приводит к последствиям, которые выходят далеко за рамки технического инцидента. Компания несёт прямые расходы на ликвидацию атаки, сталкивается с претензиями регуляторов и теряет доверие клиентов и партнёров.
Неправильно внедрённый IAM превращается в «зомби‑проект»: вложенные миллионы не дают ожидаемого эффекта, система работает фрагментарно, не снижает риски и лишь увеличивает операционную нагрузку на сотрудников. При этом организация остаётся уязвимой к самым распространённым атакам, поскольку человеческий фактор продолжает оставаться главным вектором компрометации. Без изменения поведения людей и управленческих практик даже лучшие технические решения не обеспечивают реальной защиты.
Выводы
Все описанные ошибки взаимосвязаны. Невозможно соблюсти принцип наименьших привилегий, если нет модели ролей (IGA). В то же время ролевой подход теряет смысл, если не автоматизированы процессы создания, изменения и блокировки учётных записей при приёме, переводе и увольнении сотрудников. Даже выстроенные кадровые процессы не обеспечат безопасность, если вне периметра управления остаются технические и сервисные учётные записи, требующие отдельного контроля со стороны PAM.
Поэтому решение не сводится к формальному внедрению отдельного инструмента. Необходимо отказаться от силосного подхода, при котором IAM, IGA и PAM существуют изолированно. Требуется выстраивать целостную программу управления идентификацией и доступом, где управление жизненным циклом учётных записей, контроль прав и привилегий и мониторинг технических аккаунтов интегрированы в единый цикл управления рисками.
Архитектура и процессы должны быть подкреплены культурой: ответственность за доступы должна лежать на бизнес-владельцах, а безопасность — восприниматься не как помеха, а как часть рабочего процесса.
