За почти два десятилетия руководства программами идентификации и управления рисками я усвоил отрезвляющую истину, с которой рано или поздно сталкивается каждый CISO: хакеры не взламывают системы — они входят под своим логином. Мы часто зацикливаемся на периметре и изощренности технических эксплойтов, но многие из самых разрушительных сбоев в области безопасности, которые я наблюдал, не были связаны с уязвимостями нулевого дня или […] — csoonline.com
За почти два десятилетия руководства программами идентификации и управления рисками я усвоил отрезвляющую истину, с которой рано или поздно сталкивается каждый CISO: хакеры не взламывают системы — они входят под своим логином. Мы часто зацикливаемся на периметре и изощренности технических эксплойтов, но многие из самых разрушительных сбоев в области безопасности, которые я наблюдал, не были связаны с уязвимостями нулевого дня или передовыми методами. Они были связаны с совершенно «законным», аутентифицированным запросом на доступ, одобренным кем-то, кто плохо понимал риск, который он санкционировал.
Я видел, как это происходило в самом широком спектре — от высокоценных производственных баз данных до, казалось бы, низкорисковых вспомогательных систем, которые едва попадали в поле зрения команды безопасности. В каждом случае результат был одинаковым: действительный пользователь, действительная сессия и действительное одобрение, которые тихо открыли дверь для компрометации.
Это обнажает две неприятные истины в современной безопасности идентификационных данных. Аутентификация — подтверждение того, кто является пользователь — в значительной степени решена с помощью MFA и SSO. Авторизация — определение того, что кому-то должно быть разрешено делать — остается гораздо более хрупкой. Более глубокая проблема заключается не просто в том, как предоставляется доступ, а в том, что организации на самом деле считают, чем они управляют.
Каков ваш истинный знаменатель?
Во многих предприятиях программы идентификации работают внутри тщательно очерченного пузыря «управляемых приложений». Команды вкладывают значительные средства в рабочие процессы адаптации для тех приложений, которые видят их инструменты IGA — часто не более нескольких сотен систем. Но содержательная оценка рисков начинается с гораздо более неудобного вопроса: откуда организация знает, у кого есть доступ к чему в рамках всей среды?
Это создает настоящую проблему знаменателя. Если организация не может учесть полный объем своих приложений, облачных арендаторов, учетных записей служб и сред, любые метрики по охвату MFA или обзорам доступа становятся в значительной степени перформативными. Быть «на 100% покрытым» в известной подмножестве дает мало уверенности, если это подмножество представляет лишь часть фактического актива.
Согласно Отчету MuleSoft Connectivity Benchmark Report за 2025 год, среднее предприятие управляет почти 1000 приложениями, однако менее чем в одной трети из них интегрированы центральные платформы интеграции и системы учета — те самые системы, на которые команды безопасности часто полагаются для установления области видимости и управления. Приложения, которые никогда не попадают в эти системы, с гораздо меньшей вероятностью будут последовательно инвентаризироваться, проверяться или управляться с точки зрения доступа.
Злоумышленники инстинктивно понимают это. Они не ограничивают свой поиск хорошо управляемыми производственными системами. Они зондируют периферию — устаревшие порталы, тестовые среды, инструменты теневого IT — именно потому, что эти активы часто находятся вне формального управления. Взлом Microsoft «Midnight Blizzard» высветил эту динамику. Первоначальная точка входа была не в критически важной производственной системе, а в устаревшем непроизводственном тестовом арендаторе, которому не хватало защиты, примененной к управляемому активу.
SSO-заблуждение: почему аутентификация не является гарантией
Руководители бизнеса и технологий часто спрашивают меня: «Если у нас включен SSO, почему мы все равно должны беспокоиться о гранулярном контроле доступа?» Основное предположение состоит в том, что как только пользователь аутентифицирован через центральный, безопасный портал, самая сложная работа выполнена.
На практике SSO функционирует скорее как периметр, чем как хранилище. Рассмотрение его как всеобъемлющего средства контроля безопасности вводит два стратегических слепых пятна — и подвергает риску критическое последующее последствие, когда эксплуатируется любое из них.
Пропасть в охвате
Немногие предприятия работают с полным охватом SSO. Не каждый актив является современным, соответствующим требованиям или способным к федеративной аутентификации. Устаревшие локальные системы, специализированные платформы, нестандартные приложения и теневые SaaS-инструменты часто остаются за пределами зонтика SSO.
Когда решения о доступе в первую очередь зависят от наличия SSO, эти немодернизированные активы часто получают меньше внимания. В результате увеличивается разрыв между средами, которыми, по мнению команд безопасности, они управляют, и теми, на которые нацелены злоумышленники.
Реальность обхода
Даже там, где присутствует SSO, он не неуязвим. Злоумышленники все чаще сосредотачиваются на путях, которые полностью обходят центральную аутентификацию — локальные учетные записи, учетные данные служб или методы перехвата сеансов. Взлом Snowflake предоставил наглядный пример того, как противники могут обойти федеративные средства контроля и действовать, используя в противном случае действительные пути доступа.
В этих сценариях аутентификация либо успешна, либо вообще избегается, а результат безопасности зависит от того, что этой аутентифицированной учетной записи разрешено делать дальше.
Радиус поражения: последствие неявного доверия
Когда скомпрометирована учетная запись с действительными данными — это «вход под логином», а не «взлом» — единственным значимым ограничением ущерба является радиус поражения этой учетной записи. Широкие, накопленные разрешения превращают одну скомпрометированную учетную запись в угрозу для всего предприятия. Узкие, хорошо понятные границы доступа ограничивают, как далеко может продвинуться злоумышленник, попав внутрь.
В этом контексте управление доступом — это меньше об отказе в доступе, а больше об ограничении воздействия. Оно определяет, станет ли успешный вход в систему локализованным инцидентом или системным сбоем.
Расширяющаяся поверхность атаки, не связанная с человеком
Знаменатель продолжает расти не только за счет роста SaaS, но и за счет распространения нечеловеческих идентификаторов и стороннего доступа. Учетные записи служб, ключи API, секреты и идентификаторы автоматизации теперь во много раз превышают количество пользователей-людей во многих организациях, но ими редко управляют с такой же строгостью.
В то же время современное предприятие все больше полагается на подрядчиков, поставщиков и партнеров, которым требуется постоянный доступ к внутренним системам. Взлом системы поддержки Okta продемонстрировал, как неуправляемый сторонний доступ может стать точкой входа. Компрометация произошла в учетной записи службы внутри сторонней среды поддержки — актива, который находился за пределами основного фокуса управления организации. После компрометации эта учетная запись позволила осуществить перехват сеанса и последующее раскрытие данных.
Эти инциденты подчеркивают повторяющийся шаблон: доступ, который выходит за рамки признанного знаменателя, часто получает меньше внимания, меньше контроля и более слабую подотчетность.
Рост «цифрового сотрудника»
Знаменатель снова расширяется, поскольку организации развертывают автоматизацию на базе ИИ и агентские системы, которые действуют как виртуальные работники. Это уже не простые скрипты. Они выполняют многоэтапные задачи в финансовых системах, платформах данных и операционных инструментах.
Когда агенту ИИ поручено генерировать финансовые отчеты или оркестровать рабочие процессы в различных системах, он наследует широкий доступ. Если этот агент принимает ненадлежащее решение о доступе, подотчетность становится неоднозначной. Первоначальное одобрение менеджера часто применяется только при создании, а не по мере развития области действия и поведения.
В то же время использование теневого ИИ усугубляет проблему. Сотрудники часто используют личные учетные данные для подключения неуправляемых инструментов ИИ к конфиденциальным источникам данных, создавая параллельные пути доступа, которые никогда не отображаются в формальных системах идентификации. Управление идентификацией, исторически ориентированное на сотрудников-людей, теперь сталкивается с растущим числом цифровых акторов, действующих за пределами традиционной видимости.
Почему менеджеры по умолчанию ставят штамп
Если бы самая хрупкая точка в программе идентификации имела физическое местоположение, это был бы почтовый ящик менеджера поздно вечером в пятницу.
Проставление штампов одобрения редко является признаком халатности. Обычно это результат системного сбоя контекста. Рабочие процессы идентификации регулярно представляют утверждающим лицам запросы на доступ, описанные плотным техническим жаргоном — названия групп и коды прав доступа, которые требуют специальных знаний для интерпретации.
Строка вроде FIN-PRD-DB-USR-RW может быть совершенно ясна инженеру IAM. Для бизнес-менеджера она не поддается расшифровке. Столкнувшись с несколькими такими запросами, менеджеры оказываются перед неявным выбором: приостановить свою работу для изучения незнакомых технических деталей или предположить, что запрос законный, и двигаться дальше. В условиях высокой динамики доверие становится по умолчанию, а одобрение — рефлекторным.
Когда запросы на доступ представляются без четкого, понятного человеку контекста, одобрение становится актом доверия, а не суждения. Решение фиксируется, но риск никогда по-настоящему не оценивается.
Скрытые права и эрозия принципа наименьших привилегий
Одной из основных целей управления доступом является обеспечение принципа наименьших привилегий. На практике современные рабочие процессы часто подрывают эту цель посредством накопления скрытых прав.
Знакомый шаблон повторяется в организациях. Сотрудник запрашивает доступ для конкретного проекта, получает его и сохраняет на неопределенный срок. Во время последующих обзоров доступа менеджеры сталкиваются с правами, которые кажутся давними и, следовательно, неявно оправданными. Без видимости фактического использования мало стимулов для отзыва доступа, который «не вызвал проблем».
Эта динамика превращает периодические обзоры в упражнения по административному продолжению, а не по оценке рисков. Доступ сохраняется потому, что он существует, а не потому, что он все еще необходим. С течением времени права накапливаются, и принцип наименьших привилегий становится скорее устремлением, чем операционной реальностью.
Почему проблема продолжает усугубляться
Эти проблемы обостряются по мере того, как среды становятся более распределенными, а темпы изменений ускоряются. Новые системы появляются быстрее, чем адаптируются модели управления. Нечеловеческие идентификаторы множатся. Сторонние отношения расширяются. Каждый дополнительный уровень увеличивает разрыв между предоставленным доступом и понятым доступом.
Добавление большего количества инструментов или контрольных точек процесса не улучшает качество принятия решений. Во многих случаях это усиливает фрагментацию и замедляет реакцию без повышения уверенности.
Возвращение контроля над решением
Сбои в доступе сегодня редко вызваны отсутствием средств контроля. Они вызваны решениями, принятыми без достаточного контекста, владения или подотчетности. По мере того как среды идентификации расширяются за пределы сотрудников, включая подрядчиков, автоматизацию и процессы, управляемые машинами, разрыв между предоставленным доступом и понятым доступом продолжает расти.
Для CISO задача сегодня заключается не просто в обеспечении соблюдения политики. Она заключается в определении того, действительно ли решения о доступе снижают риск — или просто документируют его. До тех пор, пока организации не смогут четко ответить, кто несет ответственность за решения о доступе, какой контекст их информирует и как долго эти решения остаются действительными, управление идентификацией будет продолжать выдавать одобрения без гарантий.
Эта статья опубликована в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Puneet Bhatnagar