Почему «non-human identities» станут вашей главной слепой зоной в сфере безопасности в 2026 году

В прошлом месяце, проводя плановый аудит доступа в нашей среде Azure, я обнаружил служебную учетную запись svc-dataloader-poc. Ею не пользовались 793 дня — два года бездействия. Когда я проверил ее разрешения, у меня упал живот: доступ уровня «Владелец» к трем производственным подпискам, включая нашу базу данных клиентов. Учетная запись была создана для пилотного проекта миграции, который так и не был запущен. Подрядчик, создавший ее, уволился 18 месяцев назад. Никто не знал о ее существовании.

Это был не единичный случай. В том же аудите я обнаружил 47 похожих учетных записей. Сорок семь дверей остались настежь распахнутыми.

Вот неутешительная реальность, с которой сталкивается каждый руководитель отдела безопасности в 2026 году: пока мы последние десять лет совершенствовали внедрение многофакторной аутентификации (MFA) и архитектуры нулевого доверия для наших пользователей-людей, в наших средах незаметно множилось нечто иное. Служебные учетные записи. API-ключи. Учетные данные для автоматизации. ИИ-агенты. Эти нечеловеческие идентификаторы теперь превосходят по численности реальных сотрудников в большинстве предприятий в соотношениях, которые показались бы абсурдными пять лет назад. Отчет ManageEngine’s 2026 Identity Security Outlook показал, что организации сообщили о соотношении машин к людям 100:1; некоторые достигли 500:1. И подавляющее большинство этих идентификаторов полностью выпадают из наших программ управления.

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

Почему взрывной рост NHI отличается на этот раз

Машинные идентификаторы — не новинка. Изменилась скорость. Пять лет назад типичное корпоративное приложение представляло собой монолит, взаимодействующий с базой данных. Сегодня это же приложение состоит из 50 микросервисов, каждый из которых нуждается в учетных данных для связи с другими. Каждый pod Kubernetes, запускаемый во время автомасштабирования, создает идентификаторы рабочей нагрузки. Каждый рабочий процесс GitHub Actions генерирует токены. Каждый запуск Terraform подготавливает служебные принципалы. Я наблюдал, как один конвейер развертывания создал больше машинных идентификаторов за 20 минут, чем во всей нашей компании было пользователей-людей.

Затем появились агентные ИИ, и проблема снова ускорилась. Это не чат-боты, отвечающие на вопросы. Это системы, уполномоченные выполнять команды, перемещать производственные данные, изменять конфигурации и автономно запускать последующие рабочие процессы. Microsoft Copilot имеет доступ к вашему SharePoint. GitHub Copilot может вносить изменения в ваши репозитории. ИИ-помощник, который только что внедрила ваша команда маркетинга, может извлекать записи клиентов из Salesforce. One Identity прогнозирует, что в 2026 году произойдет первая крупная утечка, отслеженная до чрезмерно привилегированного ИИ-агента. Самое ужасное? Это не будет выглядеть как атака. Это будет выглядеть точно так же, как система делает то, для чего она была разработана.

Наши IAM-системы никогда не были созданы для этого. Они предполагают, что идентификаторы принадлежат людям с менеджерами, которые отвечают на электронные письма с обзором доступа и в конечном итоге увольняются или выходят на пенсию. У машинных идентификаторов нет менеджера. Они никогда не отвечают на кампании сертификации. Они не увольняются. OWASP Non-Human Identities Top 10 ставит неправильное завершение работы на первое место среди рисков. Когда проект отменяется, когда интеграция с поставщиком устаревает, когда уходит разработчик — помнит ли кто-нибудь удалить служебные учетные записи? По моему опыту управления IAM-программами в нескольких организациях, ответ почти никогда не бывает утвердительным.

Три слепых зоны, которые я постоянно нахожу

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

1. Секреты там, где им не место. Я до сих пор нахожу API-ключи, жестко закодированные в исходных файлах. До сих пор. В 2026 году. В прошлом году GitGuardian обнаружил 13 миллионов секретов, раскрытых в общедоступных репозиториях GitHub. Ключи API Google, учетные данные MongoDB, ключи доступа AWS — все в открытом тексте, готовые для сбора кем угодно. Но общедоступные репозитории — это даже не самая большая проблема. В моих собственных оценках я находил пароли от производственных баз данных в билетах Jira, сообщениях Slack, руководствах Confluence и общих документах Google. Коллега однажды обнаружил административный токен платежного шлюза, вставленный в чат Teams в 2023 году, все еще действующий и предоставляющий полный доступ. Как только секреты попадают в инструменты для совместной работы, вы теряете контроль. Их копируют, пересылают, индексируют, архивируют. Они никогда по-настоящему не исчезают.
2. Служебные учетные записи с абсурдным уровнем привилегий. Это меня злит, потому что этого так легко избежать. Разработчику нужна служебная учетная запись для новой функции Lambda. Они находятся под давлением сроков. Выяснение точных минимальных разрешений занимает время, поэтому они прикрепляют AdministratorAccess и двигаются дальше. Функция работает. Никто к ней не возвращается. Эта учетная запись теперь имеет доступ уровня «бога» ко всей вашей среде AWS для задачи, которая требовала только чтения одного S3-бакета. Умножьте это на каждую команду, каждый спринт, каждый год. Отчет 2025 State of Non-Human Identities от Entro Security показал, что 97% NHI имеют чрезмерные привилегии. Девяносто семь процентов. Еще более тревожно: всего 0,01% машинных идентификаторов контролируют 80% облачных ресурсов. Скомпрометируйте одну из этих учетных записей, и злоумышленник получит контроль над вашей средой.
3. Полное отсутствие владения жизненным циклом. Когда уходит сотрудник, HR запускает процесс увольнения. Доступ отзывается. Существует процесс. Когда служебная учетная запись больше не нужна, что происходит? Ничего. Она остается там. Я регулярно нахожу учетные записи, неактивные в течение шести месяцев, двенадцати месяцев, иногда трех лет — все еще имеющие производственный доступ. Исследование Veza показало, что количество неактивных учетных записей удвоилось по сравнению с предыдущим годом. Количество «осиротевших» идентификаторов выросло на 40%. Бывшие сотрудники — 78 000 человек в одном наборе данных — все еще имели активные учетные данные, потому что HR-системы пометили их как неактивных, но никто не отозвал их служебные учетные записи. Это не теоретические уязвимости. Это действующие учетные данные, ожидающие, пока их кто-нибудь найдет.

Практический путь вперед для руководителей служб безопасности

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

• Создайте реальный реестр. Вы не можете защитить то, чего не видите. Прежде всего, обнаружите каждый нечеловеческий идентификатор в вашей среде. Каждую служебную учетную запись на ваших облачных платформах. Каждый API-ключ в ваших приложениях. Каждый секрет в ваших хранилищах, конфигурационных файлах, конвейерах CI/CD. Каждую стороннюю интеграцию с доступом к вашим системам. Большинство организаций, с которыми я работаю, сильно недооценивают свой охват. Фактическое число обычно в три-пять раз превышает ожидания команд. Это не может быть ручным упражнением или ежегодным аудитом. Идентификаторы создаются быстрее, чем люди могут их сосчитать. Автоматизируйте обнаружение и сделайте его непрерывным.
• Обеспечьте наименьшие привилегии без исключений. Каждый NHI должен быть ограничен минимальным доступом, необходимым для его функционирования. Да, это требует работы. Да, разработчики будут сопротивляться. Делайте это в любом случае. Начните с новых развертываний и сделайте принцип наименьших привилегий стандартом с первого дня. Для существующих учетных записей сравните назначенные разрешения с фактическими шаблонами использования. Вы найдете множество учетных записей с широким доступом, которые касаются только одного или двух ресурсов. Это быстрые победы. Требуйте одобрения безопасности перед тем, как любой NHI получит повышенные привилегии. Сделайте это обязательным условием, а не предложением.
• Устраните статические учетные данные везде, где это возможно. Долгоживущие секреты являются основной причиной большинства взломов NHI. Цель должна состоять в их полном устранении. Замените постоянные API-ключи краткосрочными токенами, которые автоматически истекают. Внедрите доступ по требованию, который предоставляет разрешения для конкретной задачи и немедленно отзывает их после выполнения. Автоматизируйте ротацию учетных данных по установленному расписанию — еженедельно, ежедневно, даже ежечасно для конфиденциальных систем. Исследования показывают, что 71% нечеловеческих идентификаторов не ротируются в рекомендуемые сроки. Каждый день, когда учетные данные остаются неизменными, — это еще один день, когда злоумышленник может использовать их без обнаружения.

Индустрия безопасности сходится во мнении на 2026 год: машинные идентификаторы станут основным вектором взлома в облачных средах. Tenable предсказывает это. Delinea предсказывает это. One Identity предсказывает это. Злоумышленники уже знают, что скомпрометировать служебную учетную запись часто проще и тише, чем атаковать людей. Они больше не ломают двери. Они проходят через те, которые мы забыли запереть.

Организации, которые опередят эту угрозу, будут теми, кто относится к своим нечеловеческим идентификаторам с той же серьезностью, с какой они относятся к своим исполнительным учетным записям. Полная видимость. Строгое управление. Без исключений. Те, кто продолжает относиться к NHI как к чему-то второстепенному, будут объяснять своим советам директоров, как забытая служебная учетная запись от отмененного проекта разрушила все.

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

Эта статья опубликована в рамках Foundry Expert Contributor Network.
Хотите присоединиться?