Как безопасно использовать отдельные учётные записи Unix для AI-агентов программирования

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

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

Отдельная учётная запись Unix даёт агенту другую идентичность

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

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

Учётная запись вроде agentbuild даёт проверяемую отправную точку:

id agentbuild
getent passwd agentbuild
sudo -u agentbuild sh -lc 'umask; pwd; env | sort'

На обычном Linux-хосте первая команда должна показать UID и небольшой список групп. Вторая должна показать домашний каталог вроде /srv/agentbuild или /home/agentbuild, а не домашний каталог разработчика. Последняя команда помогает обнаружить незаметную проблему: унаследованные переменные окружения могут указывать на файлы с учётными данными, прокси, кэши токенов или необычные пути к исполняемым файлам.

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

Используйте стабильную учётную запись для стабильной функции. Если один агент собирает pull request, а другой разворачивает релизные артефакты, дайте им разные идентичности. Тогда можно без догадок ответить на неприятный операционный вопрос: какая учётная запись изменила этот файл, открыла сетевое соединение или создала этот процесс?

Граница учётной записи не сдерживает все виды ущерба

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

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

Не путайте разделение учётных записей с контейнером, виртуальной машиной или сетевым межсетевым экраном. У них разные задачи:

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

Выбирайте минимальный набор мер, соответствующий последствиям сбоя. Для одноразовой тестовой копии выделенной учётной записи на изолированном worker-хосте может быть достаточно. Для production-хоста развёртывания используйте границу учётной записи вместе с ограниченным SSH, узкими правами развёртывания, журналированием и политикой исходящего трафика. Если агент может обращаться к production-базам данных или материалам для подписи, одного отдельного UID явно недостаточно.

Популярный, но ошибочный совет предлагает создать отдельную учётную запись и добавить её в те же рабочие группы, что и разработчика, «чтобы сборка работала». Так исходная проблема просто появляется под другим именем. Группы вроде docker, libvirt, групп резервного копирования, групп устройств и привилегированных журналов могут давать гораздо больше полномочий, чем обещают их названия. Во многих системах членство в docker фактически позволяет управлять хостом: участник может запустить контейнер с подключённой файловой системой хоста.

Создайте учётную запись без унаследованных прав

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

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

sudo adduser --disabled-password --gecos '' --home /srv/agentbuild agentbuild
sudo passwd -l agentbuild
sudo install -d -m 700 -o agentbuild -g agentbuild /srv/agentbuild/.ssh
sudo -u agentbuild touch /srv/agentbuild/.hushlogin

--disabled-password запрещает обычную аутентификацию по паролю для новой учётной записи. passwd -l явно закрепляет это намерение в системах, которые поддерживают блокировку пароля. Не считайте ни одну из этих настроек единственным средством контроля SSH: у SSH-сервера есть собственные параметры аутентификации по паролю, а установленный ключ всё равно позволит войти.

В системах с useradd используйте параметры, которые создают домашний каталог и отдельную группу, а затем проверьте результат, не полагаясь на память. В BSD и macOS используются другие инструменты управления учётными записями, поэтому обратитесь к локальным dscl, sysadminctl или руководству по администрированию, а не вставляйте команды Linux на другой хост.

Сразу проверьте владельцев:

namei -l /srv/agentbuild/.ssh
sudo -u agentbuild sh -lc 'touch ~/permission-test && ls -ln ~/permission-test'
sudo rm /srv/agentbuild/permission-test

Вывод namei проходит по каждому компоненту пути. Ни один родительский каталог не должен давать посторонней группе право записи: иначе кто-то сможет заменить каталог .ssh или изменять файлы внутри него. Тестовый файл должен показывать числовые UID и основной GID этой учётной записи.

Не копируйте сюда свой .bashrc, .zshrc, .gitconfig или каталог редактора «ради экономии времени». В этих файлах часто находятся частные реестры пакетов, вспомогательные псевдонимы, настройки SSH, менеджеры учётных данных и хуки оболочки. Добавляйте отдельные настройки только после того, как сможете объяснить, зачем они нужны агенту. Для удалённой автоматизации обычная оболочка без интерактивного режима всё равно должна быть стандартом.

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

Для общих репозиториев нужно заранее определить владельцев

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

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

Иногда агенту нужно записывать в общее дерево сборки. Тогда создайте отдельную группу проекта и установите бит setgid на общем каталоге, чтобы новые файлы наследовали группу:

sudo groupadd projectbuild
sudo usermod -aG projectbuild agentbuild
sudo install -d -m 2770 -o releasebot -g projectbuild /srv/project-build
sudo setfacl -m u:agentbuild:rwx /srv/project-build
sudo setfacl -d -m g:projectbuild:rwx /srv/project-build

Этот пример нужно адаптировать под вашу модель владения. Дело не в том, что списки контроля доступа модны. Нужно явно обозначить поверхность совместной работы и ограничить право записи этой поверхностью. Не реагируйте на ошибку разрешений командой chmod -R 777 и не меняйте всё дерево исходного кода на общую административную группу. Оба подхода скрывают проблему, пока кто-то не запишет файл там, где не должен.

Тонкая проблема появляется, когда каталог сборки содержит символические ссылки. У агента может быть право записи в /srv/project-build, а ссылка внутри него может вести в /etc, каталог релизов или домашний каталог человека. Перед выдачей широкого рекурсивного доступа проверьте скрипты настройки и созданные каталоги. Граница учётной записи защищает только те пути, для которых файловая система действительно проверяет права этой учётной записи.

У Git есть похожая проверка владельца. Современный Git может отклонить репозиторий, который, по его мнению, принадлежит другому пользователю, сообщив о «сомнительном владении». Не исправляйте это добавлением произвольных каталогов в глобальные настройки safe.directory агента. Сделайте копию принадлежащей учётной записи, которая запускает Git. Если общей копии не избежать, документируйте её владельца и добавляйте только конкретный путь после того, как поймёте причину отказа Git.

SSH должен идентифицировать управляющую систему и ограничивать сессию

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

OpenSSH описывает доступные средства в sshd_config(5) и authorized_keys. PasswordAuthentication no отключает вход по паролю на уровне сервера. AllowUsers может ограничить круг пользователей. Параметры отдельного ключа могут отключить перенаправление портов, SSH-агента и X11, а также выделение псевдотерминала. Это обычные средства контроля, а не экзотическая настройка SSH.

Для агента, которому нужно только принять команду Git или запустить фиксированную оболочку-обёртку, запись authorized_keys может выглядеть так:

restrict,command="/usr/local/libexec/agent-git-wrapper" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-controller

Параметр restrict в OpenSSH является сокращением, отключающим несколько возможностей перенаправления и сессии, с учётом версии сервера и руководства. Принудительная command означает, что сервер запускает обёртку, а не команду, которую запросил клиент. Проверьте установленную версию OpenSSH, прежде чем полагаться на конкретный параметр: старые хосты могут не поддерживать все ограничения.

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

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

Проверяйте действующую конфигурацию SSH, а не только изменённый файл:

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|allowusers|allowgroups'
ssh -vvv agentbuild@build-host true

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

Правила sudo обычно уничтожают добавленную защиту

Не выдавайте учётной записи агента неограниченный sudo. agentbuild ALL=(ALL) NOPASSWD: ALL делает отдельный UID почти декоративным, поскольку любая команда или скрипт агента сможет стать root.

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

Руководство sudoers(5) предупреждает, что сопоставление команд имеет ограничения. Важны аргументы. Маски могут совпасть с большим числом вариантов, чем ожидает администратор. Разрешение редактора, интерпретатора, менеджера пакетов, скрипта оболочки, доступного для изменения агенту, или команды, загружающей конфигурацию из доступного для записи каталога, может снова привести к произвольному выполнению от root.

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

Cmnd_Alias AGENT_RELEASE = /usr/local/sbin/restart-project-service
agentbuild ALL=(root) NOPASSWD: AGENT_RELEASE

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

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

Учётным данным нужна отдельная граница

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

Выпускайте учётные данные для конкретного действия, области и окружения, которые действительно нужны агенту. Учётные данные системы контроля исходного кода с правом отправки в один репозиторий отличаются от учётных данных production-реестра. Ключ развёртывания, ограниченный одним хостом, отличается от закрытого ключа, принимаемого во всей инфраструктуре. Сохраняйте эти различия заметными в именах учётных записей, комментариях и записях об отзыве.

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

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

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

Для автоматизации SSH не копируйте личный закрытый ключ в /srv/agentbuild/.ssh. Создайте отдельные учётные данные и ограничьте сервер, который их принимает. Если удалённая система поддерживает принудительные команды или ограничения источника, используйте их. Если нет, ограничьте учётную запись на целевом хосте. Отзыв должен означать удаление одного ключа агента, а не замену ключа, которым вы пользуетесь для обычного администрирования.

Журналы должны разделять намерение и выполнение

Записывайте сеанс агента, команды этой учётной записи, где это практически возможно, и сделанные изменения. Журнал с единственной записью agentbuild logged in не поможет восстановить, запросил ли действие человек, предложил ли его агент или выполнил удалённый скрипт.

Unix уже даёт полезные свидетельства. Журналы аутентификации SSH показывают принятый ключ и исходный адрес. Учёт процессов или средства аудита могут отслеживать выполнение, в зависимости от хоста. Система контроля версий фиксирует коммиты и изменённые файлы. Журналы сборки записывают команды и артефакты. Синхронизируйте время, чтобы эти записи можно было сопоставить.

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

После запуска полезно ответить на четыре конкретных вопроса:

1. Какой контроллер аутентифицировался от имени учётной записи агента?
2. Какие команды или задания сборки выполнялись под этим UID?
3. Какие файлы за пределами рабочего пространства изменились?
4. С какими удалёнными системами и аутентифицированными сервисами связался процесс?

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

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

Общий логин разработчика ломается предсказуемо

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

Агент запускает тест. Скрипт начальной настройки читает окружение разработчика и находит токен реестра. Установка зависимости выполняет postinstall-скрипт. Этот скрипт может читать домашний каталог разработчика, просматривать настройки SSH, использовать доступный помощник учётных данных и подключаться через существующий сетевой доступ разработчика. Не нужно эксплуатировать уязвимость ядра. Процесс просто получает те же полномочия, что и разработчик.

Позже скрипт развёртывания завершается ошибкой, потому что ему нужен доступный для записи путь к артефактам. Кто-то исправляет это, расширив группу. Теперь учётная запись может писать в каталог релизов. Вторая правка добавляет sudo без пароля, потому что перезапуск сервиса заблокирован. К этому моменту настройка агента унаследовала идентичность разработчика, широкую запись в файловой системе, повторно используемые учётные данные и повышение до root.

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

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

Проверьте границу от имени агента и удалите всё неожиданное

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

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

ssh -i ./agentbuild_key agentbuild@build-host 'id; umask; pwd; find ~ -maxdepth 1 -printf "%M %u %g %p\\n"'
ssh -i ./agentbuild_key agentbuild@build-host 'sudo -n true; echo sudo_status=$?'
ssh -i ./agentbuild_key agentbuild@build-host 'find /srv/project-build -xdev -type f -perm -0002 -print'

Первая строка подтверждает идентичность, рабочий каталог, маску создания файлов и права домашнего каталога. Вторая обычно должна завершаться ненулевым статусом, поскольку у учётной записи не должно быть общего sudo. Третья ищет в общем каталоге проекта обычные файлы, доступные для записи всем. В системах, где find не поддерживает GNU-параметр -printf, используйте вместо него ls -ld и stat.

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

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

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