Безопасность агентного DevOps: старые проблемы IAM на новой скорости
ИИ-агенты в DevOps-пайплайнах не изобрели новых угроз безопасности — они лишь со скоростью машины эксплуатируют те самые дыры в управлении доступом, которые инженеры десятилетиями предпочитали не замечать.
Агентный DevOps — это незапланированный аудит, который работает непрерывно, на машинной скорости и по живой инфраструктуре. Он не составляет отчёт — он просто использует те права, которые вы выдали, но которыми никто не пользовался.
О чём речь
ИИ-агенты проникают в DevOps-процессы: они запускают скрипты, управляют облаком, делают деплои, закрывают тикеты. Вокруг этого сложилась тревога — мол, агент может превысить полномочия, сломать продакшен, сделать что-то без одобрения человека. На профильных конференциях и в блогах появляются платформы «агентного гувернанса», стартапы привлекают инвестиции на решение «новой» проблемы.
Автор оригинальной публикации — практик с опытом в инфраструктурной безопасности — утверждает: проблемы реальные, но новые только по форме. По содержанию это те же нарушения управления доступом (IAM), которые существовали задолго до появления LLM. Агенты просто сделали их заметными, потому что работают на скорости, при которой разница между «выдано» и «использовано» превращается в инцидент за секунды, а не за месяцы.
Проблема №1: избыточные привилегии
Принцип минимальных привилегий (least privilege) описали ещё в 1975 году — Сальцер и Шрёдер в классической работе «The Protection of Information in Computer Systems». Суть проста: каждая программа и каждый пользователь должны иметь ровно тот набор прав, который необходим для выполнения задачи. Ни битом больше.
Полвека спустя Microsoft опубликовала данные, которые эту простоту хорошо иллюстрируют. В отчёте о состоянии облачных рисков за 2024 год говорится: в 2023 году всего 2% выданных прав для человеческих и сервисных идентификаторов были реально использованы. При этом более 50% облачных идентификаторов имели доступ ко всем разрешениям и всем ресурсам.
Почитайте эти цифры вместе: организация выдаёт почти полный доступ, а использует одну пятидесятую от него.
Оставшиеся 98% не были безопасными. Они были неиспользованными. Пока обладатель прав был человеком, это не сильно волновало: люди работают на человеческой скорости, колеблются перед деструктивными командами и в основном следуют ранбуку. Права выдавались широко, использовались узко, а разницу закрывала привычка.
У агента привычек нет. Дайте ему AdministratorAccess и задачу — и пространство его действий определяется выданными правами, а не инструкцией.
Это весь механизм. Агенты не расширили ничьих привилегий. Они схлопнули зазор между тем, что было выдано, и тем, чем реально пользовались. Каждый страх вида «агент сделает больше, чем я просил» — это переформулировка старого страха: «этот идентификатор всегда мог сделать больше, чем я просил».
И речь не только о человеческих аккаунтах. Тот же отчёт Microsoft показал, что сервисные (workload) идентификаторы составляют 83% всех облачных идентичностей, а в средней организации на три человеческих супер-аккаунта приходится семь сервисных с неограниченным доступом. Нечеловеческие принципалы с широкими правами были большинством ещё до того, как кто-то подключил языковую модель к облачному API.
Зазор сохранялся, потому что минимальные привилегии — это налог, который платят заранее, в виде фрикции, тот, кто выдаёт доступ. А дивиденды — это инцидент, который не случился. Для чьей-то квартальной отчётности, измеряемой в доставленных фичах, это плохая сделка. Поэтому доступ выдавали широко, в расчёте на то, что никто им в полной мере не воспользуется.
Проблема №2: одобрение человеком
Самое частое требование к агентным пайплайнам: прежде чем агент сделает что-то деструктивное, человек должен это одобрить.
В терминах информационной безопасности это называется step-up authentication — повышение уровня аутентификации при выполнении чувствительной операции. Стандарт NIST SP 800-63B требует, чтобы каждая сессия имела явный таймаут переаутентификации, и рекомендует не более 24 часов для уровня AAL2 с часовым таймаутом неактивности. Стандарт уже исходит из того, что аутентификация сессии «протухает» и должна быть подтверждена присутствующим человеком.
Облачные IAM-системы дают инструменты для этого. AWS exposes глобальные condition-ключи aws:MultiFactorAuthPresent и aws:MultiFactorAuthAge. В документации AWS есть готовый пример: разрешить все действия с EC2, но запретить StopInstances и TerminateInstances, если MFA не подтверждён. Добавьте политику с условием — и деструктивные вызовы будут отклоняться, если человек не прошёл MFA за последние пять минут.
Важный нюанс: суффикс IfExists в условии. Ключ aws:MultiFactorAuthAge отсутствует вовсе, когда запрос приходит по долгоживущим учётным данным, а NumericGreaterThanIfExists трактует отсутствующий ключ как совпадение. Таким образом, политика запрещает и устаревшее MFA, и полное отсутствие MFA. Вариант без IfExists тихо «открывает» доступ в этом случае — классическая ловушка, на которую указывает сама документация AWS.
Конкретная политика — не главное. Главное: фраза «ни один агент не может удалить продакшен-данные, если человек не аутентифицировался за последние пять минут» выражается на языке контроля доступа, который уже работает в продакшене. Это condition-ключ. Технология не отсутствует. Отсутствует политика, которую никто не написал.
Проблема №3: одобрение сессии — не одобрение действия
Здесь у опасений есть реальное основание, и автор оригинальной публикации честно это признаёт.
MFA в начале сессии аутентифицирует человека. Но это не авторизует конкретное действие. Как только агент получил сессионный токен, выпущенный под MFA, он получает bearer-токен вашего согласия — на пять минут (по приведённой выше политике) или до 24 часов (по потолку AAL2). Всё, что агент делает в этом окне, несёт вашу аутентификацию. Человек — в начале цикла, а не внутри него.
У этого тоже есть решение, только пришло оно не из IT, а из финансовой регуляторики. Европейская комиссия столкнулась с идентичной проблемой: клиент аутентифицируется в банке, затем выполняется транзакция, и нужно как-то связать одно с другим. Регламент EU 2018/389, статья 5, решает это через динамическое связывание (dynamic linking): код аутентификации должен быть привязан к конкретной сумме и конкретному получателю. Если что-то изменилось — код недействителен. В платёжной индустрии принцип называется «what you see is what you sign».
Применительно к агентам это значит: не одобряйте сессию и не позволяйте агенту действовать внутри неё. Одобрите завершение инстанса i-0abc123def456 — и пусть одобрение покрывает только это. Изменился ID инстанса — одобрение аннулируется.
Облачные IAM этого не обеспечивают. Condition-ключи работают с фактом и давностью MFA, но не с тем, видел ли и согласовал ли человек конкретный вызов с конкретными параметрами. Это реальный пробел. Но пробел в переносе, а не в изобретении: европейские банки обязаны работать так с 2019 года, и примитив отлаженно работает в целой регулируемой отрасли.
Проблема №4: постоянные привилегии
Третье возражение: некоторые задачи периодически требуют расширенного доступа. Нельзя ограничить идентификатор узким набором прав, если широкий нужен раз в месяц.
Это верно, и это старейшая из решённых проблем. sudo написали около 1980 года — Боб Коггесхолл и Клифф Спенсер в Университете Буффало, на VAX-11/750 под 4.1BSD. Его модель — полный ответ: вы не держите root, вы имеете право на root. Вы повышаете привилегии для одной команды. Повышение ограничено по времени, и когда окно истекает, вы аутентифицируетесь заново. В современных sudoers это параметр timestamp_timeout.
Мы взяли эту модель, перенесли в облачную инфраструктуру — и забыли о ней. Эквиваленты существуют: Microsoft Entra Privileged Identity Management различает eligible- и active-назначения ролей, AWS публикует решение для временного повышения доступа через IAM Identity Center, HashiCorp Vault выдаёт динамические учётные данные с TTL и отзывает их по истечении. Но развёртывание любого из этих инструментов остаётся скорее исключением, чем правилом.
«Агенту может понадобиться расширенный доступ» — это аргумент за eligibility (право запросить), а не за standing grant (постоянное право). Агент, который запрашивает повышение, получает его на одну операцию и автоматически теряет, имеет радиус поражения, ограниченный этой операцией. Это не «агентный контроль». Это sudo, применённый к тому доступу, который вы собирались выдать навсегда.
Что действительно новое
Автор оригинала честно выделяет две проблемы, которые не сводятся к недоделанному IAM.
Prompt injection — инъекция через промпт. MFA и минимальные привилегии здесь не помогут, и вот почему: при атаке через инъекцию агент правильно аутентифицирован и правильно авторизован. Он использует свои собственные легитимные права для действия, к которому его подтолкнула третья сторона. Контроль доступа спрашивает «разрешено ли этому принципалу делать это?», честно отвечает «да» — и атака succeeds.
Эта уязвимость описана ещё в 1988 году: Норм Харди назвал её confused deputy — «запутанный помощник», привилегированная программа, обманутая так, что она использует свои права от имени вызывающего, у которого этих прав нет. Новое — поверхность атаки. Компилятор мог быть запутан именем файла. Агент, читающий логи, тикеты и описания пул-реквестов, может быть запутан чем угодно, что попадает в его контекстное окно.
Известная митигация — полномочия, которые «путешествуют» с запросом, а не с идентификатором: одноразовый токен, авторизующий один вызов с заранее фиксированными параметрами. Это снова dynamic linking, только пришедший с другой стороны. Capability-системы моделировали это десятилетиями, но почти ни один продакшен-IAM не работает так.
Атрибуция — когда агент вносит изменение, системы управления изменениями хотят одного человека-исполнителя и одного согласующего. Если человек отправил промпт — это одобрение? Если агент действовал на основании собственной интерпретации метрики — кто подписал? Пока у индустрии нет хорошего ответа на этот вопрос.