Замена Mac разработчика означает ротацию учётных данных агента

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

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

Переносите данные отдельно от полномочий

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

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

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

Разумный перенос включает два реестра:

• Реестр данных перечисляет репозитории, документы, файлы настроек, локальные базы данных, места хранения резервных копий и лицензии.
• Реестр полномочий перечисляет все удалённые системы, которые примут действие благодаря чему-то, что хранится на старом Mac, было ему выдано или одобрено с него.

Не объединяйте эти списки. Репозиторий можно восстановить дважды без серьёзных последствий. Дважды скопированный bearer-токен создаёт два места, которые нужно защищать. Поэтому привычный совет «сначала перенести, а потом навести порядок» не подходит для учётных данных.

Apple описывает Migration Assistant как инструмент для переноса документов, приложений, учётных записей пользователей и настроек. Он не удаляет информацию со старого Mac. Apple правильно описывает обычный перенос, но именно поэтому Migration Assistant не заменяет процедуру отзыва учётных данных. Старая машина остаётся рабочей копией, пока вы намеренно не лишите её полномочий.

Новое подключение - выбор по умолчанию

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

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

Выбирайте новое подключение, если выполняется хотя бы одно условие:

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

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

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

У зашифрованного переноса узкая задача

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

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

Перед разрешением экспорта зашифрованного хранилища проверьте следующее:

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

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

Есть и ещё один неприятный момент: зашифрованный экспорт может оказаться замаскированной резервной копией. Команда импортирует его на новый Mac, объявляет задачу выполненной, а затем оставляет архив в Time Machine, общем файловом сервисе или на внешнем диске. Такой экспорт всё ещё содержит учётные данные. Для него нужно принять такое же решение о сроке хранения, как и для старого Mac.

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

Составьте реестр полномочий до начала работы с новым Mac

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

Достаточно простого файла. Храните его в закрытом рабочем месте, которое не попадёт в публичный репозиторий.

Service: production deployment API
Purpose: release automation
Credential form: bearer token
Old-device location: agent vault record deploy-prod
Issuer: deployment service administrator
Replacement method: create new device token
Cutover test: read release status only
Old-access action: revoke old token
Owner: platform team
Status: pending

Service: build host
Purpose: remote build troubleshooting
Credential form: SSH identity
Old-device location: agent vault record build-ssh
Issuer: build host authorized_keys
Replacement method: create a new SSH key pair
Cutover test: ssh hostname
Old-access action: remove old public key
Owner: build infrastructure
Status: pending

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

Проверьте места, о которых разработчики часто забывают:

• Хранилища агентов и файлы их настроек.
• Конфигурацию SSH, состояние SSH-агента, идентификаторы, защищённые аппаратными средствами, и списки удалённых авторизованных ключей.
• Сессии браузера для облачных консолей и поставщиков удостоверений.
• Реестры пакетов, инструменты для работы с репозиториями, системы деплоя и административные аккаунты CI.
• Локальные файлы окружения, файлы запуска оболочки, парольные менеджеры, архивы резервных копий и зашифрованные съёмные диски.

Не записывайте в реестр настоящие bearer-токены, закрытые ключи, коды восстановления или пароли. Реестр полезен тем, что даёт достаточно сведений для замены и отзыва доступа, но не превращается в ещё одно хранилище секретов высокой ценности.

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

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

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

Для хранилища, в котором находятся учётные данные агентов, используйте тестовую последовательность в таком порядке:

1. Заблокируйте хранилище и попробуйте выполнить безвредное действие. Пока хранилище заблокировано, запрос должен быть отклонён.
2. Разблокируйте его обычным локальным способом и повторите то же безвредное действие.
3. Запустите новый процесс агента и убедитесь, что поведение авторизации соответствует нужным настройкам сессии.
4. Проверьте отдельную запись активности для вызова и запись сессии для запуска агента.
5. Изучите журнал аудита до удаления любых исходных материалов со старого Mac.

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

Добавьте команду аудита в запись о приёмке:

sp audit verify

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

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

Migration Assistant полезен, но не заменяет протокол хранилища

Migration Assistant может сэкономить часы, если нужно перенести приложения, учётные записи пользователей, файлы и настройки со старого Mac. Он также умеет переносить всю пользовательскую среду из резервной копии Time Machine. Apple документирует оба сценария. Такая широта удобна для восстановления рабочей станции, но не даёт точного ответа, какие файлы с учётными данными, сессии, кэши и записи приложений были перенесены.

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

Типичная ошибка выглядит так. Разработчик переносит свою учётную запись, открывает проект агента и видит успешный HTTP-вызов. Он решает, что новое хранилище работает. На самом деле вызов выполнила облачная сессия, полученная из браузера, или токен, который остался в скопированном файле конфигурации. Через неделю сессия истекает. Разработчик в спешке добавляет заменяющий credential, оставляет старый скопированный credential на месте, и теперь старый Mac, резервная копия и новое хранилище дают пути к одному сервису.

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

Apple также указывает, что Migration Assistant не удаляет информацию со старого Mac. Стройте переход с учётом этого факта. Экран о завершении переноса означает, что копирование закончено. Он не означает, что прежнее устройство стало безопасным для передачи другому человеку.

Отзовите доступ старого Mac до очистки

Отзыв состоит из нескольких уровней, и если свести их к одному действию, возникает ложная уверенность. Завершение запуска агента останавливает процесс. Удаление устройства из поставщика удостоверений может завершить некоторые сессии. Отзыв bearer-токена запрещает дальнейшее использование API. Удаление SSH открытого ключа останавливает удалённый вход с помощью этой идентичности. Смена пароля может сделать недействительными одни сессии, но оставить другие, в зависимости от сервиса.

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

Практический порядок такой:

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

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

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

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

Утилизация - отдельный элемент защиты

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

Для Mac с Apple silicon или Intel Mac с чипом безопасности T2 под поддерживаемой версией macOS откройте «Системные настройки», выберите «Основные», затем «Перенос или сброс» и «Стереть контент и настройки». Apple сообщает, что «Ассистент стирания» удаляет учётные записи пользователей, пользовательские данные, установленные приложения, входы в сервисы Apple, Find My и Activation Lock. Он также стирает тома, а не только учётную запись текущего пользователя.

Если этот пункт недоступен, не пытайтесь заменить его удалением файлов или быстрой очисткой диска. Для старого неподдерживаемого оборудования Apple рекомендует соответствующую процедуру очистки через Recovery и Disk Utility. Метод отличается, потому что отличается поддерживаемое оборудование и модель безопасности.

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

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

Сделайте процедуру замены достаточно простой для повторения

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

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

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