Доступ sudo для AI-агентов: контролируйте каждое повышение прав

Выдавать AI-агенту sudo только потому, что он уже может открыть удалённую оболочку, значит смешивать разные задачи. Удалённое выполнение отвечает на вопрос «может ли он попасть на эту машину?». Повышение прав отвечает на вопрос «может ли этот запрос изменить защищённое состояние?». Для этих решений нужны разные свидетельства, меры контроля и записи.

Я видел, как команды объединяли их ради удобства: агент подключается по SSH, запускает sudo, а после него остаётся транскрипт чата. Всё выглядит аккуратно, пока плохая команда не перезапустит не тот сервис, не заменит файл конфигурации или не выполнит инструкцию, спрятанную в репозитории. После этого никто не может сказать, какой процесс обладал полномочиями, кто их одобрил и зачем вообще понадобился доступ root.

Доступ sudo для AI-агентов должен означать узкое исключение, привязанное к конкретному действию и понятной причине. Это не должно превращаться в постоянные права администратора на всё время задачи.

Удалённая оболочка и sudo отвечают на разные вопросы

SSH-сеанс подтверждает, что клиент аутентифицировался в удалённой учётной записи. Он не доказывает, что каждой команде, введённой или сгенерированной в этом сеансе, нужны права root. Обычная учётная запись должна позволять собирать сведения, запускать сборки и тесты, читать разрешённые журналы и готовить развёртывание. Небольшой набор защищённых изменений вынесите в отдельный путь повышения прав.

Разницу легко не заметить, потому что оболочка превращает повышение прав в деталь синтаксиса:

ssh deploy@api-02 'sudo systemctl restart payment-worker'

В одной строке скрыто как минимум пять решений: какой процесс агента её отправил, на какой хост она рассчитана, правильно ли указано имя сервиса, зачем нужен перезапуск и согласился ли человек с последствиями. SSH аутентифицирует подключение. sudo может сменить эффективного пользователя. Но ни один из этих инструментов сам по себе не фиксирует причину и не создаёт подходящую для автономной работы точку принятия решения.

Обычные удалённые команды должны оставаться обычными. Агент может выполнить systemctl status, прочитать доступный ему журнал сервиса, сравнить отрендерированную конфигурацию или запустить проверку состояния без прав root. Это даёт практическое преимущество: сначала агент собирает свидетельства, а уже потом просит одобрить изменение.

Не стоит и ставить каждую команду оболочки за человеческое подтверждение. Так возникает усталость от согласований, и люди начинают нажимать кнопки, не читая карточки. Добавляйте трение там, где действие пересекает защищённую границу: управление сервисами, изменения системных пакетов, запись привилегированных файлов, операции с учётными записями, сетевые правила, секреты, настройки загрузки и данные в продакшене.

Риск определяется не написанием команды. sudo cat /var/log/... может раскрыть чувствительные данные. sudo systemctl restart ... способен прервать работу сервиса для клиентов. Даже на вид безобидный sudo install может заменить исполняемый файл. Оценивайте эффект, цель и возможность того, что аргументы превратят команду в произвольное действие от root.

Правила sudoers задают список разрешений, но не доказывают безопасность

Руководство sudoers говорит, что sudo решает, может ли пользователь выполнить команду, по пути к команде и, если это настроено, по аргументам командной строки. Это полезный механизм, но широкое разрешение не становится безопасной делегацией само по себе.

Например, такое правило даёт больше полномочий, чем многие предполагают:

autobot ALL=(root) NOPASSWD: /usr/bin/systemctl *

Оно разрешает запускать, останавливать, перезапускать, включать, отключать, маскировать и проверять любой модуль, который поддерживает локальный systemctl. Если агент может влиять на файл модуля, файл окружения или исполняемый файл сервиса, разрешённый перезапуск может превратиться в выполнение кода от root. В правиле также нет ни причины изменения, ни срока действия.

Ограничения аргументов помогают только тогда, когда разрешённая программа имеет небольшой стабильный интерфейс и не трактует данные, контролируемые атакующим, как путь, выражение оболочки, плагин, редактор, pager или источник конфигурации. Абсолютный путь к бинарному файлу сам по себе не делает команду узкой.

Лучше использовать специально созданную оболочку с фиксированной операцией и явной проверкой. Например, оболочка перезапуска может принимать только заранее заданное имя сервиса, а не произвольные аргументы systemctl:

#!/bin/sh
set -eu

case "${1:-}" in
  payment-worker|report-worker) ;;
  *) echo "unsupported service" >&2; exit 64 ;;
esac

exec /usr/bin/systemctl restart "$1"

Затем ограничьте sudo этой оболочкой и точными аргументами, если платформа это поддерживает:

autobot ALL=(root) /usr/local/sbin/restart-approved-service payment-worker, \
                    /usr/local/sbin/restart-approved-service report-worker

Так вы не даёте разрастаться подкомандам systemctl. Но вопрос, разумен ли перезапуск именно сейчас, всё ещё остаётся. Оболочка должна принадлежать root, родительские каталоги не должны быть доступны для записи, а окружение не должно контролироваться агентом. Если агент может изменить оболочку или заменить запускаемый ею файл, правило уже не работает.

Не следуйте популярному совету «просто используйте NOPASSWD для автоматизации». Он удобен, потому что фоновые задания перестают падать на запросах пароля. Но запрос пароля никогда не был содержательным контролем для автономного агента. Заменить его неограниченным повышением прав значит убрать последнюю заметную паузу. Нужны конкретное разрешение и ответственная запись, а не удобство без контроля.

В запросе на повышение прав нужна причина, которую можно оценить

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

Свяжите в запросе следующие поля:

• Точную цель, например api-02 и payment-worker.
• Запрошенную привилегированную операцию, включая фиксированные аргументы.
• Причину, связанную с инцидентом, развёртыванием, техническими работами или наблюдаемым состоянием.
• Ожидаемый эффект и действие для отката.
• Достаточно короткий срок действия, чтобы заброшенный запрос не превратился в постоянное разрешение.

В причине должны быть факты, которые человек может оценить. «Нужен sudo, чтобы починить сборку» показывает, что агент ещё не провёл достаточную диагностику. «Заменить /etc/acme/client.conf на проверенную конфигурацию релиза после ошибки разбора при продлении текущего сертификата; при неудаче проверки восстановить прежнюю версию» указывает файл, условие и способ восстановления.

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

Используйте неизменяемый идентификатор запроса. Одобрение должно разрешать именно этот идентификатор, указанную цель и указанную операцию. Не одобряйте естественно-языковую инструкцию вроде «разберись со сбоем», оставляя агенту возможность позднее решить, какие команды root к ней относятся. Это превращает человеческое одобрение в пустой чек.

Пример записи запроса:

{
  "request_id": "elev-7f4c2",
  "agent_session": "run-91b0",
  "host": "api-02",
  "operation": "/usr/local/sbin/restart-approved-service payment-worker",
  "reason": "Deployment 482 left payment-worker unhealthy; status shows repeated configuration parse errors.",
  "expected_effect": "Service restarts with the reviewed configuration.",
  "rollback": "Restore the previous configuration revision and restart the service.",
  "expires_at": "2025-03-08T14:25:00Z"
}

В запись выполнения нужно передавать request_id. Без этой связи проверяющий мог одобрить одну операцию, а агент выполнить другую.

У процесса агента должна быть собственная идентичность

Общая учётная запись deploy делает всех исполнителей одинаковыми после инцидента. Идентичность запуска агента должна показывать, какой исполняемый файл его запустил, кто из людей или сервисов начал работу, какой репозиторий и задачу он получил и когда его полномочия заканчиваются.

Идентичность человека и идентичность процесса, это разные факты. Разработчик может запустить агента, но сам процесс агента отправит команду через несколько часов, после чтения файлов, вывода инструментов и сетевых ответов. В аудите должны сохраняться оба факта: «Jamie запустил run 91b0» и «подписанный процесс агента 91b0 запросил повышение прав». Так расследование отличает инициатора от непосредственного исполнителя.

Подпись кода помогает определить локальный исполняемый файл, запросивший доступ. Но она не доказывает безопасность инструкции модели и не делает скомпрометированный репозиторий надёжным. Считайте идентичность процесса ограничением того, кто может запрашивать доступ, а не доказательством разумности запроса.

Не передавайте агенту многоразовый пароль root, закрытый SSH-ключ, который напрямую попадает в учётную запись администратора, или долгоживущий таймер sudo, который можно бесконечно обновлять. Каждый такой секрет превращает узкий запрос в переносимую возможность. Если агент сможет скопировать её в рабочую область, журнал, артефакт сборки или дочерний процесс, контроль над распространением будет утрачен.

Краткоживущие учётные данные уменьшают риск, но не делают плохую команду хорошей. Используйте срок действия вместе с заданной операцией, привязанным процессом и причиной. Если чего-то из этого нет, перед вами всего лишь токен доступа с более приятным названием.

Оболочка root оставляет агенту слишком много места для переосмысления инструкций

Никогда не одобряйте для сеанса агента sudo -i, sudo su, sudo sh или неограниченный sudo bash. Оболочка root разрешает все последующие команды, в том числе собранные из вывода инструментов, которого не существовало в момент одобрения первой команды.

То же относится к формам, скрывающим произвольный интерпретатор:

sudo python3 -c "$AGENT_TEXT"
sudo env CONFIG="$AGENT_TEXT" /usr/local/sbin/apply-config
sudo tee /etc/some-file.conf

Каждый пример кажется ограниченным, пока не посмотреть на канал ввода. Python выполняет произвольный код. env может изменить поведение программы неожиданным для вызывающего образом. tee даёт право записи в произвольный путь от root, если путь не ограничен. Политика, которая игнорирует аргументы и окружение, является лишь политикой имён файлов.

Лучше разделять диагностику и выполнение. Агент может изучить факты без привилегий, подготовить предлагаемое изменение и отправить его на проверку. Узкий привилегированный помощник получает только одобренные входные данные. Он должен проверить их ещё раз, потому что проверки во время одобрения и во время выполнения защищают от разных сбоев.

Представим агента развёртывания, который заметил сбой сервиса. При широком sudo он может изменить переопределение модуля, перезагрузить менеджер и перезапустить сервис. Вредоносная строка в конфигурации из репозитория способна стать строкой ExecStart, после чего при перезапуске выполнится код от root. В ограниченной схеме агент читает состояние и готовит проверенную конфигурацию, а привилегированный помощник принимает только хеш содержимого из одобренного места. Файлы модулей, произвольные пути и неуправляемые переопределения он отклоняет.

Это сложнее, чем передать оболочку. Зато так вы получаете известную операцию, а не интерпретатор, который после одобрения может придумать новые действия.

Одобрение должно соответствовать риску операции

Одного одобрения на сеанс может хватить для обычных ограниченных удалённых действий. Но оно не подходит для каждого использования административных возможностей. Разделяйте авторизацию сеанса и авторизацию отдельного вызова.

Авторизация сеанса отвечает на вопрос: «Может ли этот идентифицированный процесс агента использовать обычные удалённые каналы во время запуска?» Она не позволяет неизвестному локальному процессу молча выдать себя за известного агента. Авторизация должна закончиться при завершении процесса, а оператор должен иметь возможность немедленно её отозвать.

Авторизация отдельного вызова отвечает на вопрос: «Можно ли выполнить именно это действие сейчас?» Используйте её для операций с большим радиусом воздействия, дефицитными учётными данными, влиянием на продакшен или необратимыми последствиями. В начале карточки одобрения показывайте идентичность процесса, затем цель, операцию, причину, срок и ожидаемый эффект. Если спрятать идентичность среди длинного текста, смысл контроля теряется.

Не заставляйте оператора разбирать сотню строк сгенерированной оболочки. Дайте агенту словарь именованных операций с отображаемыми подробностями. «Перезапустить payment worker на api-02» можно проверить. Блок оболочки с вложенными кавычками заставляет человека одобрять то, чего он не понимает.

В процессе одобрения нужен и понятный путь отказа, который помогает агенту восстановить работу. Возвращайте ясный отказ и, если уместно, пояснение вроде «требуется запись об изменении развёртывания» или «эта операция недоступна в продакшене». Не позволяйте агенту повторять запрос с небольшими изменениями формулировки, пока уставший человек не согласится. После отказа запрос должен закрываться, если человек не создал новый запрос с существенно иной информацией.

В экстренной ситуации сохраняйте ту же дисциплину. Дежурный инженер может одобрить узкий запрос с коротким сроком и ссылкой на инцидент. Срочность может ускорить проверку, но не оправдывает удаление записи или выдачу интерактивной оболочки root.

Записи аудита должны пережить агента, который создал запрос

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

Записывайте решение отдельно от действия. В записи одобрения должны быть указаны одобривший, время, идентичность процесса, точное содержимое запроса и срок действия. В записи выполнения должны быть результат работы помощника, достигнутый хост, возвращённые данные, время завершения и идентификатор запроса, который это действие разрешил.

Вместо полного вывода чувствительной команды сохраняйте хеш результата или ограниченное резюме. Следователю достаточно знать, что payment-worker перезапустился и стал работоспособным. Ему не нужен пароль базы данных, случайно попавший в stderr.

Защита от изменений важна, потому что журналы становятся особенно ценными после инцидента. Хеш-цепочка связывает каждую запись с предыдущей. Если запись изменить или удалить, проверка обнаружит разрыв. Проверка должна быть независимой от агента и по возможности от учётных данных, использованных для выполнения действий. Журнал, для проверки которого нужен скомпрометированный ключ администратора, мало полезен в самый важный момент.

Например, офлайн-проверка может вывести такую последовательность:

$ sp audit verify --file agent-audit.enc
verified records: 184
chain start: 8c1a...e72d
chain end: 4bf0...193a
status: valid

Важно не имя команды, а то, что проверка обнаружит изменённую зашифрованную запись без просьб к агенту объясниться. Храните копии вне машины, где работает агент: злоумышленник, контролирующий эту машину, может удалить весь журнал.

Sallyport разделяет эти функции: учётные данные остаются вне агента, а журналы сеансов и отдельных действий создаются из доступного только для записи зашифрованного аудита с хеш-цепочкой. Такая модель полезна, когда агенту нужны HTTP- или SSH-действия, но сами ключи авторизации он получать не должен.

Привилегированные помощники нуждаются в узких интерфейсах и тестах на вредоносные входные данные

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

Начните с перечня операций. Запишите каждый привилегированный эффект, который действительно нужен агенту, например перезапуск конкретного сервиса или установку подписанного артефакта релиза. Если эффект нельзя описать без слов «выполнить произвольную команду», операция ещё не спроектирована.

Перед добавлением помощника в sudoers ответьте на вопросы:

1. Какие точные входные данные может передать вызывающая сторона и как проверяется каждый из них?
2. Какие пути, исполняемые файлы, конфигурации и переменные окружения влияют на поведение?
3. Может ли принятый вход запустить оболочку, интерпретатор, pager, редактор, загрузчик плагинов или сетевой запрос?
4. Проверяет ли помощник владельца, права доступа и идентичность содержимого до выполнения?
5. Какую запись он создаёт при ошибке проверки и при успешном выполнении?

Проводите не только позитивные тесты. Передавайте пути с ../, метасимволы оболочки, пустое имя сервиса, слишком длинный ввод, неожиданный Unicode и корректное имя, указывающее на небезопасное состояние. Попробуйте заменить файл между проверкой и использованием. Проверьте, не позволяют ли доступные для записи каталоги журналов, временные или родительские каталоги перенаправить вывод root.

После обновлений проверяйте и зависимости. Помощник, безопасный для одной версии команды, может стать опасным, если новая опция принимает путь к конфигурации или загружает расширение. Узкие интерфейсы уменьшают нагрузку на сопровождение, но не устраняют её.

Внедряйте повышение прав как контролируемое исключение

Начните с удаления самых опасных форм постоянных привилегий: общих административных учётных записей, неограниченного NOPASSWD, многоразовых секретов root в конфигурации агента и оболочек root. Не обязательно останавливать всю автоматизацию. Сначала сохраните диагностику только для чтения, затем переносите по одной защищённой операции в явный помощник и путь одобрения.

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

Анализируйте отклонённые запросы так же внимательно, как успешные. Много запросов на произвольную запись файлов может означать, что в интерфейсе развёртывания не хватает нужной операции. Но это может показывать и попытки агента обойти границу. Это разные проблемы, и аудит помогает их различить.

Затем отработайте отзыв доступа. Завершите сеанс, пока агент работает, отклоните уже выданный запрос после истечения срока и проверьте, что скопированный идентификатор запроса не может разрешить второе действие. Команды часто тестируют экран одобрения и пропускают эту часть. Именно отзыв нужен, когда поведение агента меняется в середине запуска.

Зрелость определяется не числом команд, которые агент может выполнить от root. Она определяется тем, остаётся ли каждое повышение прав узким, связанным с ответственным субъектом, ограниченным по времени, проверяемым и обратимым, когда агент или его входные данные дают сбой.