Как обеспечить безопасность ИИ-агентов, если ваша программа управления идентификацией разрабатывается уже много лет? Начните с доступа, который могут использовать эти агенты.
Эми закончила свой последний пост четырьмя вопросами, которые применимы к любой человеческой, машинной и агентной идентификации с критическим доступом. Кто владелец? Как долго она существует? Какова область её действия? Как быстро можно отозвать её доступ?
Я добавлю пятый: как нам ответить на эти вопросы за 90 дней, не разрушая уже существующую программу?
Ключевой вывод: злоумышленники, использующие передовые модели ИИ, действуют быстро. Начните свой 90-дневный план безопасности агентного ИИ с одной ключевой системы. Выясните, кто и что может получить к ней доступ, ограничьте ненужные права и проверьте, как быстро вы сможете заблокировать доступ при появлении угрозы.
Я потратил более десяти лет на создание программ управления идентификацией. Я считаю, что стандартный список мер, включающий хранение секретов в сейфах, принцип наименьших привилегий и регулярные проверки доступа, по-прежнему актуален. Большинство из нас работали над этим десятилетие, так и не завершив процесс.
Что должно измениться, так это порядок работы и временные рамки.
Что 10-часовое вторжение говорит о контроле идентификации
В ходе расследования Unit 42 злоумышленник-человек использовал ИИ-агентов для перемещения по системе, получения секретов, учетных данных администратора и облачных ключей менее чем за 10 часов. Одна деталь из этого отчета заслуживает вашего внимания.
Злоумышленник пытался внедрить бэкдоры в конфигурации Terraform — код, используемый для управления облачной инфраструктурой. Защита веток заблокировала эти изменения. Вторжение продолжилось, но этот шаг оказался неудачным.
Почему это важно: привычный механизм контроля, находящийся в нужном месте, сработал против злоумышленника, действующего на машинной скорости. Это означает, что вам не нужны новые средства контроля в первую очередь. Вам нужны те, что у вас уже есть, на путях, которые действительно будет использовать злоумышленник. Управляйте доступом в момент совершения действия идентификацией.
Эта возможность не ограничивается одним инцидентом. Исходите из того, что любой злоумышленник может действовать таким образом. Unit 42 уже зафиксировала, как китайскоязычная хакерская группа использует DeepSeek через агентскую инфраструктуру с открытым исходным кодом для автономной разведки и попыток эксплуатации. Забытая сервисная учетная запись не может оставаться в списке задач на второй год только потому, что её трудно найти. Планируйте так, будто любая постоянная привилегия на критическом пути будет обнаружена.
Пять изменений в управлении вашей программой идентификации
Чтобы применить этот урок, мы должны 1) найти наиболее важные пути доступа и 2) задействовать уже имеющиеся у нас средства контроля на этих путях.
Для этого я бы изменил следующее:
Ранжируйте работу по доступности
Учетные записи в сейфах и подключенные приложения говорят вам о покрытии, но злоумышленнику всё равно, какая часть вашего имущества защищена. Они ищут то, что не защищено, на путях, ведущих к производственному облаку, CI/CD или консоли администратора самого сейфа. Перестаньте подключать приложения в порядке, установленном календарем аудита. Начните с систем, где компрометация будет наиболее опасной, и двигайтесь в обратном направлении к каждой идентификации, которая может получить к ним доступ.
Поставьте машинные и агентные идентификации в начало очереди
Цепочка атак Unit 42 проходила через секреты, учетные данные администратора и облачные ключи. Большинство программ по-прежнему ориентированы на людей, потому что люди создают заявки, а сервисные учетные записи — нет. Перестаньте относиться к «слишком рискованно для ротации» как к постоянному исключению. Уделяйте каждой идентификации на критическом пути одинаковое внимание, включая разрешения, которые ИИ-агент наследует или получает через делегирование. У исключений должны быть владелец, план исправления и крайний срок.
Относитесь ко времени как к средству контроля
Вторжение Unit 42 сжало недели работы до часов. Окно, которое вы всё ещё контролируете, — это окно доверия, то есть время, в течение которого предоставленная привилегия остается активной. Каждый час, пока она существует, украденный ключ или взломанный агент могут её использовать. Нулевые постоянные привилегии (ZSP) и доступ «точно в срок» (JIT) сокращают это окно. Перестаньте считать 90-дневную ротацию учетных данных и ежеквартальную сертификацию достаточной защитой от злоумышленника, который работает часами. Отслеживайте, как долго существует привилегия и кто ею владеет.
Проверяйте процесс отзыва доступа
Эми предложила засекать время, необходимое для завершения сеанса, отзыва токена и ротации учетных данных. Сделайте это и посмотрите, кому вам приходится звонить. Учетные записи, сеансы, токены и учетные данные — это отдельные точки контроля, часто принадлежащие разным командам. Отключение учетной записи может оставить существующие сеансы или токены активными.
Перестаньте предполагать, что «отключить пользователя» означает, что доступ закрыт. Убедитесь, что доступ запрещен, замерьте время полного процесса отзыва и задокументируйте каждую ручную передачу полномочий.
Принимайте решение о реагировании заранее
В контролируемой симуляции Unit 42 ИИ-атака с использованием программ-вымогателей прошла путь от первоначального взлома до кражи данных за 25 минут. Заявка и конференц-звонок не вписываются в это окно. Мы называем эту связь между обнаружением идентификации и сдерживанием IdentitySecOps. Перестаньте отправлять оповещения об идентификации в очередь без каких-либо действий. Выберите несколько высоконадежных сигналов идентификации, которые могут запускать предварительно одобренные действия, такие как отзыв токена или завершение сеанса, и протестируйте эти ответы. Привяжите протестированный ответ к приоритетным оповещениям об идентификации.
90-дневный план: начните с одного критического пути доступа
Под давлением команды пытаются охватить всё сразу. Они оценивают всё и перезапускают дорожную карту. Широкий первый месяц дает длинный список выводов, не снижая при этом риски. Я бы прошел весь путь на одном примере, а затем использовал полученные знания на следующих десяти.
Дни 1–30: Картирование, сокращение и тестирование
Выберите путь, который вы меньше всего хотели бы видеть доступным для злоумышленника. Для большинства организаций он ведет к администрированию производственного облака, CI/CD и инфраструктуре как коду, сейфу привилегированного доступа или правам администратора каталога. Если вы не можете назвать его с уверенностью, проведите оценку идентификации, сфокусированную на этом единственном вопросе.
На этом пути:
- Проинвентаризируйте каждую человеческую, машинную и агентную идентификацию, которая может получить к нему доступ, и назначьте каждому владельца.
- Немедленно удалите доступ, который никто не может обосновать.
- Перенесите оставшиеся привилегии на JIT-доступ, ограниченный конкретной задачей, где это возможно.
- Проведите учения по отзыву доступа, замеряя каждый шаг и записывая каждую передачу полномочий.
- Подключите один высоконадежный сигнал идентификации к одному предварительно одобренному действию по сдерживанию и протестируйте его.
К 30-му дню стремитесь к тому, чтобы один критический путь был полностью отображен, необоснованный доступ сокращен, время отзыва измерено, а действие по сдерживанию протестировано. Назначьте владельца и крайний срок для любого оставшегося исключения по постоянному доступу.
Теперь у вас есть шаблон, и вы знаете, с какими организационными препятствиями бороться дальше.
Дни 31–60: Повторите на следующих десяти путях
Примените шаблон к следующим путям, ранжированным по доступности. Десять — это полезная цель, если вы можете провести каждый из них через полный цикл упражнений. Не меняйте проверенное снижение рисков на красивое круглое число. Устраните препятствия, выявленные на первом пути: владение сервисными учетными записями, завершение сеансов и межкомандное взаимодействие.
Попутно:
- Разорвите связи, которые позволяют одной скомпрометированной идентификации открыть доступ к следующей.
- Авторизуйте каждый шаг и по умолчанию ограничивайте делегированные разрешения для агентов и сервисных идентификаций.
- Изолируйте привилегированные сеансы, чтобы учетные данные не попадали на конечные точки, и удалите постоянные права локального администратора на конечных точках.
- Удалите постоянные права локального администратора на конечных точках вдоль этих путей.
К 60-му дню у вас должно остаться меньше постоянных прав доступа на наиболее рискованных путях. Вы должны знать, где процесс отзыва прав все еще буксует и какие исключения остаются.
Дни 61–90: пересмотр приоритетов и оценка
Используйте полученные знания для корректировки общей дорожной карты:
- Ранжируйте оставшуюся работу по критерию достижимости, а затем переходите к вопросам покрытия.
- Переведите учетные записи на критических путях с ежеквартальной сертификации на непрерывную проверку.
- Расширьте применение предварительно одобренных мер сдерживания на те немногие типы обнаружения идентификационных данных, которым ваш SOC доверяет больше всего.
- Установите базовый показатель того, как долго сохраняются привилегии на ваших критических путях, потому что совет директоров обязательно об этом спросит.
К 90-му дню: покажите, какой доступ вы удалили, как быстро можете отозвать оставшийся и где сдерживание все еще затруднено.
Что показать совету директоров на 90-й день
К 90-му дню вы должны быть в состоянии показать совету директоров, что изменилось на ваших критических путях доступа: сколько постоянных привилегий вы удалили, сколько учетных записей теперь имеют подтвержденных владельцев и отзывный доступ с ограничением по времени, и как быстро вы можете этот доступ аннулировать. Покажите, какие пробелы были закрыты благодаря учениям по отзыву прав и сколько высоконадежных сигналов об идентификации теперь запускают протестированное действие по сдерживанию.
Обратите внимание, что ни один из этих показателей не измеряет покрытие. Они показывают, становится ли критический доступ сложнее для злоупотребления и быстрее для сдерживания.
Как Idira поддерживает 90-дневный план
Все это работает с инструментами, которые у вас уже есть, и именно с них стоит начать. Idira собирает все в одном месте. Платформа безопасности идентификации Idira обнаруживает человеческие, машинные и агентные учетные записи, заменяет постоянные разрешения на JIT-доступ и связывает риски идентификации с автоматизированным реагированием. Путь, который вы исправили на второй неделе, не окажется разбросанным по трем консолям и трем командам.
«План быстрого снижения рисков идентификации» содержит полную стратегию, а также контрольный список того, что необходимо программе идентификации, когда злоумышленники обладают возможностями передовых моделей ИИ.
Учения по отзыву прав показывают, сколько времени требуется, чтобы забрать доступ. Но как долго этот доступ остается полезным в принципе? В следующей статье Энди Кляйн представит концепцию «Среднего окна доверия» (Mean Trust Window), покажет, как его измерить, и объяснит, что это число говорит совету директоров.
Если вам нужна помощь в выборе вашего первого пути, наша команда может провести оценку того, где в вашей среде все еще сохраняется постоянное доверие.
Часто задаваемые вопросы
Почему мы не можем продолжать использовать нашу существующую программу идентификации?
Вы можете сохранить большую ее часть. Контроли по-прежнему применимы. Что меняется, так это порядок и время: ранжируйте работу по тому, какие учетные записи могут достичь критических систем, измеряйте, как долго живут привилегии, и репетируйте отзыв прав так же серьезно, как вы проектируете процессы утверждения.
Что нам следует сделать в первые 30 дней, чтобы снизить риски безопасности, связанные с агентным ИИ?
Выберите один путь доступа, который вы меньше всего хотели бы видеть доступным для злоумышленника. Составьте карту всех человеческих, машинных и агентных учетных записей на нем и назначьте владельцев. Удалите необоснованный доступ, переведите остальное на JIT-доступ, проведите учения по отзыву прав и подключите один сигнал идентификации к предварительно одобренному действию по сдерживанию.
Как ZSP и JIT-доступ снижают риски?
Нулевые постоянные привилегии (ZSP) удаляют доступ, который учетной записи не нужно иметь постоянно. JIT-доступ (Just-in-time) предоставляет привилегии для утвержденной задачи и удаляет их по завершении работы. Вместе они сокращают то, что злоумышленник может унаследовать от скомпрометированной учетной записи.
Как мы можем проверить, сможем ли мы отозвать доступ во время атаки?
Выберите путь доступа с высоким уровнем риска. Завершите привилегированный сеанс, отзовите его токен и смените учетные данные, стоящие за ним. Подтвердите, что в доступе отказано, засеките время учений и зафиксируйте каждую ручную передачу управления.
