Хранилища агентов Migration Assistant требуют чистого старта

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

Migration Assistant может перенести документы, приложения, учетные записи пользователей и настройки с другого Mac, PC или резервной копии. Это удобно, чтобы быстрее вернуться к работе. Но это не означает, что все свойства безопасности исходной машины должны сохраниться. Apple прямо указывает: ключи Secure Enclave и элементы связки ключей с отметкой ThisDeviceOnly не переносятся на другое устройство.

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

Перенесенный Mac - это новое конечное устройство

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

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

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

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

До запуска Migration Assistant зафиксируйте правила переключения:

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

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

Четыре вида состояния дают разные сбои

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

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

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

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

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

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

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

Перед копированием заморозьте доступ агентов

Не начинайте с Migration Assistant. Сначала убедитесь, что ни один агент не может отправить запрос, пока неясно, какой Mac обладает полномочиями.

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

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

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

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

Используйте короткую запись передачи:

Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator

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

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

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

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

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

Apple говорит, что Migration Assistant переносит приложения, учетные записи, документы и настройки. Именно поэтому нужна такая проверка, а не предположение, что переместились только личные файлы.

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

В Sallyport хранилище зашифровано внутри приложения, а шлюз хранилища не допускает исключений. На Mac с поддерживаемым аппаратным путем шлюз использует Secure Enclave и Touch ID, а заблокированное состояние запрещает любое действие. Поэтому скопированный блок хранилища не доказывает, что новая машина может использовать полномочия старого Mac.

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

Старые подтверждения не должны разрешать новый процесс

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

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

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

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

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

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

Подходящая таблица проверки может быть небольшой:

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

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

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

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

Sallyport строит журналы Sessions и Activity из одного зашифрованного журнала аудита, доступного только для записи, с хеш-цепочкой. Его проверяющий инструмент может проверять цепочку офлайн по шифротексту, без ключа хранилища. Благодаря этому при миграции есть конкретная точка «успех» или «сбой», а не необходимость просматривать список старых действий.

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

sp audit verify \u003e audit-verify.txt 2\u003e\u00261
status=$?
printf 'sp audit verify exit=%s\\n' "$status"

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

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

Заново регистрируйте учетные данные, не извлекайте их

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

Повторная регистрация меняет вопрос «Как скопировать этот секрет?» на вопрос «Кто должен выдать новые полномочия этой конечной машине?» Это более здоровый подход. Он может потребовать создания нового API-токена, регистрации нового открытого SSH-ключа или получения новых учетных данных у владельца системы. Кроме того, он создает четкую точку отзыва для старого Mac.

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

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

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

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

Первое рабочее действие должно быть намеренно скучным

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

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

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

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

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

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

Не расставайтесь со старым Mac, пока свидетельства не собраны

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

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

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

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