Средства защиты агентов: один процесс или демон

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

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

Число процессов не определяет границу безопасности

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

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

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

В обсуждениях архитектуры об этом условии часто забывают. Unix-сокет, доступный одной учетной записи, дает доступ к транспорту, но не доказывает, что соединяется именно нужный агент или одобренное приложение. Открыть его может любой процесс, запущенный от имени этого пользователя. Если демон принимает от любого локального участника запрос вроде «использовать учетные данные X для URL Y», такое же действие сможет запросить вредоносное расширение редактора, скрипт оболочки или взломанный агент.

Разделяйте три понятия:

• Граница процесса разделяет память.
• Граница привилегий ограничивает действия кода после взлома.
• Граница авторизации определяет, какой вызывающий может запросить конкретное действие.

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

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

Локальный сокет это API, которое может вызвать вредоносный код

Сторонники демонов часто справедливо говорят, что служба слушает только localhost или Unix-сокет. Но обычно умалчивают о том, что большинство интеграций агентов работает именно с локальным кодом. Агент программирования, терминал, редактор, скрипты сборки, хуки пакетов и помощники браузера используют один компьютер.

Относитесь к локальному IPC-совместимому endpoint так же, как к небольшому сетевому API. Жестко определите форматы сообщений. Отклоняйте неизвестные поля, если это допускает протокол. Привязывайте каждый запрос к личности вызывающей стороны и короткоживущему сеансу. Ограничьте размер запросов, параллелизм и допустимые назначения. Записывайте неудачные запросы так же, как успешные: повторяющиеся отказы могут показать, что интеграция пытается обойти предусмотренный путь.

В macOS проверьте инструмент до того, как поверите его заявлению о работе только локально:

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[d]aemon'
lsof -nP -iTCP -sTCP:LISTEN
launchctl print gui/$(id -u) 2>/dev/null | grep -i -C 2 'agent\|vault\|security'

Если процесс слушает TCP, вторая команда обычно выводит столбцы примерно такого вида:

COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
service  4128 sam     9u  IPv4 0x...            0t0  TCP 127.0.0.1:48120 (LISTEN)

Отсутствие вывода lsof не доказывает, что у инструмента нет IPC. Unix-сокеты не попадают в этот TCP-запрос. Проверьте каталоги поддержки приложений, временные каталоги и документацию службы, чтобы найти пути к сокетам. Затем проверьте права командой ls -l и спросите себя, сможет ли другой процесс от имени вашей учетной записи подключиться к сокету.

В руководстве Apple по launchd.plist параметр KeepAlive описан как набор условий, при которых launchd перезапускает задачу. Это удобно с точки зрения эксплуатации, но создает обязательство по безопасности. Перезапускаемая служба должна правильно восстановить состояние блокировки, состояние сеанса и состояние аудита. Фраза «она автоматически возвращается» не отвечает на вопрос, что служба принимает в первую секунду после перезапуска.

Хороший демон делает личность вызывающей стороны частью протокола, а не предположением, которое клиент передает сам. Точный механизм зависит от операционной системы. На платформах, где локальный сокет может предоставить данные о стороне соединения, используйте их. Если доступны сведения о подписи кода, проверяйте их до выдачи разрешения на сеанс. Не принимайте за идентификатор имя процесса, PID из JSON или путь, указанный вызывающей стороной. Все это легко подделать, а к моменту проверки сведения могут устареть.

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

Однопроцессное приложение обычно запускается, когда пользователь открывает его. Жизненный цикл чувствительного состояния прост: приложение запускается, пользователь разблокирует его, одобренные сеансы выполняются, а закрытие или сбой приложения прекращает доступ. Это легко объяснить и проверить.

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

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

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

Опишите конечный автомат явно. Он должен без расплывчатых формулировок отвечать на вопросы:

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

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

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

Учетные данные должны попадать к исполнителю, не проходя через агента

Главный вопрос о credential не в том, шифрует ли инструмент хранилище. Важно, получает ли агент секрет в форме, которую можно скопировать, вывести на экран, записать в файл или передать другой точке.

Самый безопасный вариант, когда учетные данные находятся в хранилище под контролем шлюза. Агент отправляет запрос на действие. Шлюз проверяет состояние авторизации, добавляет учетные данные в исходящий HTTP-запрос или SSH-операцию, выполняет действие и возвращает результат. Агент получает данные от удаленной системы, а не bearer-токен или закрытый ключ.

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

В Secrets Management Cheat Sheet от OWASP командам советуют не встраивать секреты в код и менять их при подозрении на раскрытие. Совет правильный, но для сценариев с агентами недостаточен. Секрет может не попасть в систему контроля версий и все равно утечь через ответ инструмента. Шлюз должен предотвращать раскрытие в момент выполнения действия.

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

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

Избегайте следующих заманчивых вариантов:

• Хранить API-токены в переменных окружения процесса агента.
• Записывать временный файл с учетными данными, который читает дочерний процесс.
• Возвращать заменитель, который клиент позже обменивает на настоящий токен.
• Для удобства добавлять локальному демону метод «получить секрет».
• Передавать байты закрытого ключа SSH через стандартный ввод.

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

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

Большее число процессов означает больше обслуживания, а не большую зрелость

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

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

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

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

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

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

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

Подтверждение должно относиться к определенному запуску, а не к запомненному компьютеру

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

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

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

У демона здесь появляется дополнительная обязанность. Он должен связать IPC-соединение с личностью, которую одобрил человек, и удалить эту связь, когда клиент завершится или подключится снова. Никогда не позволяйте клиенту возобновлять старый сеанс, просто предъявив кэшированный идентификатор. Если идентификатор можно передать через файл или аргумент команды, это bearer-учетные данные с красивым названием.

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

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

Сбой при перезапуске показывает слабое место

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

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

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

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

Проверить это можно без специального оборудования:

1. Откройте новый сеанс агента и разрешите допустимый запрос с низким воздействием.
2. Запустите другой запрос, который остановится на этапе подтверждения или тестовой точке.
3. Завершите процесс безопасности или службу, пока запрос ожидает.
4. Перезапустите их и повторите запрос из исходного процесса агента.
5. Убедитесь, что требуется новая авторизация, а итог появился в записи аудита ровно один раз.

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

Для аудита нужен исполнитель записи, который нельзя обойти

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

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

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

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

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

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

Выбирайте минимальную архитектуру, которая подходит нужному жизненному циклу

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

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

Настольный инструмент вроде Sallyport использует однопроцессную архитектуру приложения и обычный MCP shim для запросов агентов. Его хранилище само выполняет HTTP- или SSH-действие, поэтому агент никогда не получает настроенные API- или SSH-учетные данные.

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