# Что делать при пропаже Mac разработчика: безопасно отзовите доступ

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

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

## Считайте пропажу активным доступом, пока не завершите сдерживание

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

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

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

Перед распределением задач классифицируйте ситуацию:

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

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

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

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

## Ограничьте устройство, не уничтожая материалы расследования

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

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

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

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

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

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

Не следуйте популярному, но слабому совету «просто сменить основной пароль пользователя». Он привлекателен быстротой и наглядностью. Иногда это помогает, особенно если пароль могли подсмотреть, но личные токены доступа, OAuth-разрешения, SSH-ключи, браузерные сессии, токены обновления CLI и сервисные учётные данные часто продолжают работать. Сброс пароля лишь одна задача в более широком плане сдерживания.

## Сначала отзовите полномочия работающего агента

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

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

Журнал Sessions в Sallyport позволяет немедленно отозвать запуск агента, а журнал Activity записывает отдельные вызовы приложения. Используйте оба источника при реагировании на пропажу: первый показывает, какой запуск нужно остановить, второй показывает, что он успел сделать.

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

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

Для агентов, подключающихся через MCP-сервер, отзовите или отключите путь соединения для идентичности затронутой рабочей станции. Затем проверьте конфигурацию агента в исходных репозиториях, профилях оболочки, каталогах проектов и управляемых настройках. Не переносите её на новый Mac, пока не удалите старые токены, не проверите хуки команд и не выясните, не указывает ли она на личные или production-аккаунты.

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

## Меняйте учётные данные в порядке, удобном злоумышленнику

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

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

Затем смените доступы, позволяющие перемещать код или запускать рабочие нагрузки: учётные данные CI, токены публикации в реестре пакетов, ключи подписи, ключи развёртывания, токены облачных рабочих нагрузок, токены реестра контейнеров и SSH-ключи для бастионов или production-хостов. В последнюю очередь займитесь трекерами задач, документацией, API-токенами с небольшими правами и паролями отдельных сервисов.

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

| Поле | Что записать |
| --- | --- |
| Учётные данные | Точный идентификатор токена, ключа, сертификата, сессии или OAuth-разрешения |
| Владелец | Человек или сервисный аккаунт, отвечающий за использование |
| Полномочия | Разрешённые системы и действия |
| Место хранения | Известные хранилища, переменные CI, файлы устройства, настройки приложений |
| Действие | Отозвать, сменить, отключить аккаунт, удалить публичный ключ или выпустить заново |
| Проверка | Тест, доказывающий, что старые полномочия больше не работают, а обычная работа продолжается |

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

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

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

```
curl -i -H "Authorization: Bearer $OLD_TOKEN" https://api.example.internal/whoami
```

После отзыва ожидается ошибка аутентификации, например `HTTP/1.1 401 Unauthorized` или документированный ответ провайдера о недействительном токене. Ответ `200` означает, что старый токен всё ещё работает. Фразы «мы изменили его в менеджере секретов» недостаточно, поскольку удалённый сервис может продолжать принимать прежние данные.

К SSH относитесь особенно внимательно. Разработчики часто помнят про `~/.ssh/id_ed25519`, но забывают ключи развёртывания, аппаратные ключи, SSH-сертификаты, перенаправленные агенты, ключи у провайдеров контроля версий, ключи в CI и публичные ключи на бастионах. Ищите места, где контролируется доступ, а не только содержимое потерянного диска. Каждый путь, принимающий публичный ключ, должен перестать его принимать.

## Проверяйте активность до и после периода пропажи

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

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

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

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

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

Для SSH-назначений проверьте журналы аутентификации, записи команд, если вы их собираете, историю оболочки только как вспомогательное доказательство, журналы привилегированных команд и новые записи в `authorized_keys`. Успешный вход по ключу после времени сообщения о пропаже требует объяснения, даже если исходный адрес выглядит знакомым. Через корпоративный VPN многие пользователи могут выглядеть как один и тот же адрес.

Sallyport хранит зашифрованный журнал аудита, защищённый от записи и построенный на хеш-цепочке, за своими журналами. На чистом Mac сохраните доступные материалы аудита и выполните офлайн-проверку целостности, прежде чем считать записи доказательствами:

```
sp audit verify
```

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

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

## Ищите закрепление, а не только кражу

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

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

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

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

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

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

## Восстанавливайте доступ с чистого устройства, а не из резервной копии

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

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

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

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

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

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

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

## Закрывайте инцидент только после доказательного отказа старых путей

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

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

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

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

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