Безопасность Fast User Switching для действий локального AI-агента

Общий Mac меняет смысл «локальных» полномочий. Fast User Switching позволяет нескольким сеансам пользователей одновременно оставаться в системе. Поэтому человек за клавиатурой, процесс агента, хранилище учетных данных и запрос на подтверждение могут относиться к разным контекстам безопасности. Если считать их одной личностью, обычная передача компьютера может закончиться непроверенным вызовом в production.

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

Безопасность Fast User Switching связана с одновременными сеансами

Безопасность Fast User Switching важна потому, что macOS может оставить предыдущую учетную запись в системе, пока другой человек пользуется тем же компьютером. Apple описывает Fast User Switching в руководстве пользователя macOS как способ переходить между учетными записями без выхода другого пользователя из системы. В этом и состоит удобство функции. Но переключение не доказывает, что предыдущая работа остановилась.

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

Разница становится серьезной, когда агент может вызвать API или подключиться по SSH. Агент мог запуститься под учетной записью Alex до обеда. После этого Sam мог переключиться в свою учетную запись и увидеть чистый рабочий стол. Процесс Alex все еще может существовать, его очередь может содержать задания, а состояние подтверждения может оставаться действительным для этого запуска. Mac не передал эти полномочия Sam, но небрежное программное обеспечение способно скрыть разницу.

Не путайте блокировку экрана, переключение пользователя и завершение процесса. Они решают разные задачи.

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

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

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

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

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

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

Зафиксируйте эту связь в архитектуре и рабочих правилах:

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

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

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

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

Скрытый процесс может пережить человека за столом

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

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

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

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

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

Нужен и видимый способ ответить на вопрос: «Что сейчас работает под моей учетной записью?» Ответ не должен зависеть от памяти. Дайте операторам журнал сессий, где видны запуск, его текущий статус разрешения и прямая кнопка отзыва. На личном компьютере это удобно. На общем Mac это часть границы безопасности.

Запросам на подтверждение нужна личность процесса, а не дружелюбная подпись

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

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

В запросе также нужно назвать учетные данные или категорию действия понятным для человека образом. «Использовать учетные данные X» заставляет вспоминать содержимое мысленной таблицы. «Отправить HTTP-запрос в API развертывания с учетными данными издателя staging» дает основу для решения. Не вставляйте полный текст запроса в каждое уведомление. Большие запросы утомляют и раскрывают данные, которым не место в уведомлении на рабочем столе. Показывайте действие, назначение, метод и личность учетных данных в форме, которую можно быстро просмотреть.

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

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

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

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

Общим Mac нужна процедура передачи, которая завершает полномочия

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

Используйте такую процедуру, когда другой человек должен продолжить локальную задачу агента:

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

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

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

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

Блокировка хранилища должна останавливать действия до появления запросов

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

Sallyport намеренно выстраивает контроль именно так: его шлюз хранилища абсолютен, а в macOS при заблокированном хранилище используются Secure Enclave и Touch ID, тогда как действия отклоняются. Благодаря этому старое разрешение агента не может заменить доступ к хранилищу после блокировки пользовательского сеанса.

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

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

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

Термин «человек в контуре» часто скрывает вопрос о личности. Какой человек? Под какой учетной записью? Какой процесс он подтверждает? Запрос, который не отвечает на эти вопросы, не дает meaningful контроля. Он лишь фиксирует, что кто-то нажал кнопку.

Записи аудита устанавливают временную последовательность, но не решают вопрос разрешения

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

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

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

sp audit verify

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

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

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

HTTP- и SSH-вызовы несут разные риски в общем сеансе

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

Для HTTP проверяйте назначение, метод и область действия учетных данных. Запрос на чтение к узкому API разработки должен подчиняться другому правилу, чем запрос на запись к конечной точке управления средой. Агент должен запрашивать действие через локальный шлюз, который сам добавляет учетные данные, чтобы агент получил результат, а не токен предъявителя. Это ограничивает раскрытие секрета, но не уменьшает последствия подтвержденного разрушительного запроса.

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

Fast User Switching добавляет локальное условие для обоих каналов. Работающий процесс агента одной учетной записи не должен продолжать отправлять HTTP-запросы или открывать SSH-сеансы только потому, что другой пользователь сделал Mac активным. Шлюз должен связывать запрос с исходным процессом и требовать, чтобы владелец хранилища прошел проверку. Экран второго пользователя не должен становиться поверхностью подтверждения для запуска первого.

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

Некоторым задачам не место на общем рабочем компьютере

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

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

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

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