macOS Keychain для автономных инструментов программирования

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

Для агента это различие важнее, чем для обычного настольного приложения. Человек выбирает команду и сразу видит результат. Агент интерпретирует текст, вызывает инструменты, обрабатывает их вывод и может работать часами. Хранилище Keychain отвечает на вопрос: «Кто может прочитать этот секрет?» Выполнение через посредника отвечает на более сложный вопрос: «Может ли именно этот процесс выполнить именно это действие сейчас, ни разу не получив секрет?» Аутентификация сессии PAM отвечает на связанный, но иной вопрос: кто открыл сеанс входа. Если считать три механизма взаимозаменяемыми, в системе останутся пробелы, незаметные на демонстрации и неприятные при расследовании.

Keychain защищает хранение, а не каждое использование

Keychain шифрует секретные данные и регулирует доступ через службы безопасности macOS. Токену там намного безопаснее, чем в файле .env, истории shell, репозитории или конфигурации агента. Для элемента можно задать контроль доступа, а система может потребовать присутствия пользователя перед выдачей. Такая защита действительно мешает случайной краже файлов и неразрешенному чтению.

Граница заканчивается при выдаче. Если вспомогательная программа возвращает токен как текст, он уже находится в ней, в канале IPC и в процессе-получателе. Он может попасть в отладочное сообщение, объект исключения, стенограмму, отчет о сбое, swap, скопированное окружение, дочерний процесс или вредоносный исходящий запрос. Keychain не отзовет эти байты. Последующая блокировка не отменит bearer-токен, уже скопированный в память.

Документация Apple Keychain Services говорит о хранении и извлечении паролей, ключей и сертификатов. Формулировка точная: извлечение предусмотрено. Keychain не превращает любой секрет в неэкспортируемый ключ подписи. Некоторые криптографические ключи можно создать с контролем доступа и использовать через API безопасности без экспорта закрытого материала. Но обычный токен API должен где-то стать заголовком HTTP. Вопрос в том, какой доверенный компонент строит и отправляет запрос.

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

security find-generic-password -a agent-test -s example-api -w

Форма вывода: секрет и перевод строки:

test_token_7f3a...

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

Разрешенный читатель может экспортировать секрет

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

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

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

При проверке проследите путь секрета как данных, а не как блока на схеме. Ответьте на четыре вопроса:

• Какой процесс первым получает открытый текст?
• Может ли копию получить дочерний процесс, плагин, команда shell или стенограмма?
• Выбирает ли получатель адрес, метод HTTP, путь или узел SSH?
• Какое событие прекращает полномочия и удаляет ли оно уже раскрытый материал?

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

PAM подтверждает вход, а не намерение агента

Pluggable Authentication Modules, или PAM, позволяют службе применять правила аутентификации на границе входа. В macOS службы sudo, login и удаленного входа используют именованные конфигурации PAM. Стек PAM может аутентифицировать пользователя, проверить учетную запись, установить учетные данные, открыть и закрыть сессию. Так решают, может ли человек начать привилегированную сессию ОС.

PAM обычно не контролирует каждый HTTP-вызов уже запущенного агента. После аутентификации процесс действует с полученной системной идентичностью и возможностями. Если он читает токен, PAM не привязывает прежнее касание Touch ID или ввод пароля к одному последующему запросу. Без другого компонента PAM не знает, что POST /releases опаснее, чем GET /status.

Слово «сессия» обозначает несколько независимых сроков жизни. Сессия PAM может окружать вход или работу sudo. Сессия терминала остается в окне. Сессией агента называют один процесс, разговор или возобновленную задачу. Сессия API может совпадать со сроком действия bearer-токена. Завершение одной не завершает остальные.

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

Используйте PAM, когда решаете, может ли учетная запись ОС создать сессию. Не называйте такую аутентификацию доказательством свежего человеческого намерения для каждого действия внутри. У PAM нет такого смысла.

Аутентификация и авторизация решают разные задачи

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

Для автономного инструмента точно назовите субъект. «Пользователь» слишком расплывчато. Оператор, подписанный исполняемый файл агента, новый процесс агента, сервер MCP, дочерний shell и удаленная учетная запись API отличаются. Если одно разрешение охватывает их всех, система должна сообщать об этом прямо.

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

Подтверждение каждого вызова само по себе не гарантирует безопасность. Диалог «Разрешить доступ к сети?» почти не дает оснований для решения. Он должен назвать процесс и показать детали риска: псевдоним учетных данных, метод и адрес HTTP либо пользователя и узел SSH. Нельзя провоцировать усталость от запросов. Если безопасное чтение прерывает работу так же, как запись в рабочей среде, человек начнет подтверждать оба не глядя.

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

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

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

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

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

Получается фиксированная лестница решений, а не одно огромное разрешение:

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

Первые три вопроса регулируют полномочия, четвертый касается исполнения и доказательств. Размытый флаг «доверенный агент» усложняет отзыв и расследование.

Посредник не передает учетные данные агенту

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

Запрос к HTTP API может выглядеть так:

{
  "credential": "staging-release-api",
  "method": "POST",
  "url": "https://api.example.invalid/v1/releases",
  "headers": {"content-type": "application/json"},
  "body": {"commit": "8a31c2e", "channel": "candidate"}
}

После авторизации посредник добавляет bearer-, basic- или нестандартный заголовок. Видимый агенту ответ сохраняет статус, выбранные заголовки и тело, но не содержит добавленный секрет:

{
  "status": 201,
  "headers": {"content-type": "application/json"},
  "body": {"release_id": "rel_1042", "state": "queued"}
}

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

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

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

Посредник не предотвращает все разрешенные вредные действия

Скрытый токен устраняет большой класс сбоев, но не делает запрошенное действие правильным. Разрешенный DELETE удалит данные без утечки секрета. Команда SSH повредит узел при идеально защищенном ключе. Посредник контролирует способ применения полномочий, но не выводит деловое намерение из синтаксиса.

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

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

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

Популярный совет «положите все секреты в Keychain и требуйте Touch ID» смешивает хорошее хранение со слишком широким решением об использовании. Touch ID подтверждает присутствие при выдаче, но не мешает получателю затем копировать или неправильно применять материал. Биометрия нужна на границе чувствительного действия, а токен агенту лучше не выдавать вовсе.

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

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

Разделяйте события сессий и вызовов, сохраняя связь. Журнал сессий показывает появление процесса, способ идентификации, одобрение, отзыв и выход. Журнал активности показывает каждую операцию HTTP или SSH и ее результат. Тогда расследование ответит и на «Был ли запуск разрешен?», и на «Что он сделал?».

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

Команда проверки должна возвращать простой автоматизируемый результат. Sallyport строит журналы Sessions и Activity из одного зашифрованного хеш-цепочечного аудита с записью без обратного чтения; проверка работает офлайн по шифротексту без ключа расшифрования:

sp audit verify

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

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

Проверяйте весь путь атакующими тестами

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

Короткий план покрывает основные границы:

1. Запустите новый процесс и убедитесь, что старое разрешение не перешло. Запишите показанную идентичность.
2. Запросите безопасное чтение API, затем защищенную отдельным подтверждением запись. Карточка должна различать адрес и операцию.
3. Ищите секрет и его кодированные формы в видимых агенту stdout, stderr, окружении, стенограммах, данных инструментов и отчетах о сбое.
4. Отзовите сессию и повторите из родителя и существующего потомка. Оба должны отказать до сети или SSH.
5. Измените, удалите и переставьте копии записей аудита. Офлайн-проверка должна отвергнуть каждую испорченную цепочку.

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

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

Критерии должны быть наблюдаемыми. «Секрет защищен» проверить нельзя. «Последовательность байтов и ее форма base64 не появляются в видимых агенту файлах, окружении, ответах или журналах» проверить можно. Вместо «Отзыв работает» требуйте отказа каждого вызова отозванного процесса и его существующих детей до открытия сокета.

Выбирайте контроль по полномочиям агента

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

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

До выбора схемы запишите самое сильное требуемое утверждение. Шифрование на диске требует контроля хранения; операции только от этого подписанного процесса требуют идентичности и сессии; вызов API без выдачи токена требует посредника; обнаружение изменений оставшихся журналов требует доказательства целостности. У каждого утверждения свой тест и владелец.

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

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

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

Sallyport применяет эту модель в macOS: агенты обращаются за действиями HTTP и SSH через сервер sp mcp, а ключи API и SSH остаются в зашифрованном внутрипроцессном хранилище. Фиксированная лестница включает абсолютный шлюз хранилища, стандартную авторизацию каждого нового процесса агента и необязательное подтверждение каждого использования выбранного ключа.

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

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