Локальные шлюзы агентов через MDM для macOS

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

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

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

MDM должна распространять шлюз, а не полномочия разработчика

MDM должна знать, на каком Mac установлено одобренное приложение и какую версию оно использует. Она не должна становиться хранилищем личных API-токенов, закрытых SSH-ключей или скопированных файлов с учетными данными.

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

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

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

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

Разумная запись MDM для шлюза содержит только рабочие сведения:

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

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

Пакет является договором развертывания

Подписанный установочный пакет делает развертывание в парке воспроизводимым. Образ диска, которым обмениваются в чате, zip-архив в папке Downloads или скрипт, копирующий пакет приложения в /Applications, договором развертывания не являются.

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

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

Перед загрузкой пакета в MDM проверьте и сам пакет, и установленное приложение на чистом тестовом Mac. Для минимальной проверки подойдут такие команды:

pkgutil --check-signature Sallyport.pkg
spctl -a -vv -t install Sallyport.pkg

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

codesign --verify --deep --strict --verbose=2 /Applications/Sallyport.app
spctl -a -vv /Applications/Sallyport.app

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

Пусть пакет остается простым. Он должен установить приложение в ожидаемое место, не скачивать второй исполняемый файл во время postinstall и не записывать учетные данные или пользовательские настройки. Если для работы продукта пакету нужен сложный postinstall-скрипт, остановитесь и проверьте, не ошиблись ли вы в дизайне приложения или границе пакета. За этот скрипт придется платить при каждом обновлении macOS и каждом разборе инцидента.

Установленное приложение должно удаляться как приложение, а не как объект криминалистического расследования. Apple отмечает, что пакет может разместить приложение в /Applications, после чего служба управления устройствами сможет управлять им и удалять его отдельно. Это одна из причин не разбрасывать основные файлы по произвольным каталогам.

Запускайте приложение в сессии разработчика

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

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

Apple четко проводит эту границу. Login item запускается при входе пользователя и работает в его сессии. LaunchAgent тоже работает для вошедшего пользователя. LaunchDaemon работает на системном уровне, может запускаться до входа и выполняется от имени root. Apple также описывает login items как подходящий вариант для приложения, ориентированного на пользователя и активного в течение его сессии.

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

Если MDM должна принудительно контролировать запуск, используйте управляемый payload login item от Apple, а не придумывайте plist, который копирует скрипт. Payload com.apple.loginitems.managed может указать путь к приложению и определить, будет ли оно скрыто. В справочнике Apple по управлению устройствами приведена структура payload, а macOS его поддерживает.

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

\u003cdict\u003e
  \u003ckey\u003ePayloadType\u003c/key\u003e
  \u003cstring\u003ecom.apple.loginitems.managed\u003c/string\u003e
  \u003ckey\u003ePayloadIdentifier\u003c/key\u003e
  \u003cstring\u003edev.example.agent-gateway.login-item\u003c/string\u003e
  \u003ckey\u003ePayloadUUID\u003c/key\u003e
  \u003cstring\u003eREPLACE-WITH-UUID\u003c/string\u003e
  \u003ckey\u003ePayloadVersion\u003c/key\u003e
  \u003cinteger\u003e1\u003c/integer\u003e
  \u003ckey\u003eAutoLaunchedApplicationDictionary-managed\u003c/key\u003e
  \u003carray\u003e
    \u003cdict\u003e
      \u003ckey\u003ePath\u003c/key\u003e
      \u003cstring\u003e/Applications/Sallyport.app\u003c/string\u003e
      \u003ckey\u003eHide\u003c/key\u003e
      \u003cfalse/\u003e
    \u003c/dict\u003e
  \u003c/array\u003e
\u003c/dict\u003e

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

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

Кольца обновлений должны проверять реальную работу разработчиков

Кольца обновлений работают, когда каждое отвечает на свой операционный вопрос. Они перестают работать, когда становятся вежливым способом бесконечно откладывать обновления.

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

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

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

Относитесь к развертыванию как к машине состояний, а не к календарному ритуалу:

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

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

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

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

Отдельное хранилище меняет подключение и восстановление

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

В этом и состоит смысл. Локальный шлюз агента может получать запрос от Claude Code или другого агента с поддержкой MCP, но агент никогда не должен получать учетные данные в открытом виде или в виде ненастоящей подстановки, которой потом можно злоупотребить. Шлюз должен сам выполнить HTTP- или SSH-действие и вернуть результат.

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

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

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

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

До развертывания зафиксируйте таблицу ответственности:

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

Инвентарь и данные о действиях отвечают на разные вопросы

Инвентарь MDM показывает, достигло ли управляемое приложение устройства. Он не может установить, что запрашивал AI-агент после установки, кто подтвердил полномочие или какой API-вызов был выполнен.

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

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

Для инцидента или проверки релиза используйте простую процедуру:

sp audit verify

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

Audit chain: valid
Records checked: 184
First record: 2026-07-01T14:22:09Z
Last record: 2026-07-22T09:15:44Z

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

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

Вывод устройства из эксплуатации начинается с доступа, а не со стирания

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

Для обычного корпоративного возврата действуйте в таком порядке:

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

Не освобождайте Mac из Apple Business Manager только потому, что сотрудник покидает компанию. Освобождение является решением о владении оборудованием, которое продано, безвозвратно потеряно или иным образом больше не должно находиться под вашим контролем. Apple предупреждает, что такое освобождение необратимо в обычном процессе назначения, не позволяет в будущем назначить устройство в MDM и после освобождения требует стирания и восстановления. Apple также не рекомендует освобождать устройство, отправленное в ремонт, поскольку замена может не вернуться в Apple Business Manager.

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

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

Успешное развертывание остается скучным

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

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