# Чек-лист увольнения AI-агента для контролируемого отключения Увольнение сотрудника - один из немногих моментов, когда контроль доступа проверяется на скорость. Обычной инструкции по отключению учетной записи недостаточно для AI-агентов: полезная работа часто продолжается через локальные процессы, фоновые задачи, общие API-учетные данные, SSH-материалы и скопированную конфигурацию, которая находится за пределами идентичности уходящего сотрудника. Относитесь к увольнению как к контролируемой передаче полномочий, а не к уборке в ИТ-системах. Нужно остановить новые действия, найти уже выполняющуюся работу, заменить общие полномочия и сохранить записи до того, как кто-то удалит свидетельства, объясняющие произошедшее. ## Отключение учетной записи не закрывает все пути в production Отключение учетной записи в каталоге закрывает только те пути доступа, которые действительно обращаются к этому каталогу в момент использования. Оно не отзывает API-токен в локальном файле конфигурации, закрытый SSH-ключ, загруженный в рабочую область агента, ранее выданный облачный токен или общие сервисные учетные данные, переданные заданию CI. Разницу легко не заметить, потому что человек, процесс агента и учетные данные часто отображаются на панели под одним именем сотрудника. Это разные сущности, и для каждой нужны свои действия: - Учетная запись человека показывает, кто прошел аутентификацию. - Локальный процесс агента показывает, что может действовать на компьютере сотрудника прямо сейчас. - Учетные данные показывают, что примет удаленный сервис. - Сессия или задание показывают, какая работа уже может выполняться. - Аудиторская запись показывает, что можно будет доказать позже. Если перепутать эти понятия, возникает знакомая ситуация. HR отмечает сотрудника как уволившегося в 09:00. В 09:05 ИТ отключает единый вход. В 09:20 запланированная задача агента запускается на ноутбуке, который еще не забрали. Она использует общий токен развертывания из переменных окружения и меняет настройку production. Каждая команда может честно сказать, что удалила учетную запись сотрудника. Но никто не удалил полномочия, которыми воспользовался агент. Начните заявку на увольнение с конкретного вопроса: «Какие действия все еще могут успешно выполниться, если обычный вход сотрудника перестанет работать?» Не принимайте ответ «его учетная запись отключена». В NIST SP 800-53 связанные меры контроля вынесены в разные семейства не случайно. AC-2 посвящен управлению учетными записями, IA-5 - управлению средствами аутентификации, а AU-9 - защите аудиторской информации. Команды, которые сводят все три пункта к одному флажку, обычно находят пропущенную работу уже после инцидента. ## Сначала заморозьте пути действий, потом забирайте ноутбук Сначала остановите удаленные полномочия: физический сбор компьютера может занять несколько часов, а включенный ноутбук продолжит работать. Ответственный за увольнение должен уведомить владельца безопасности и владельцев сервисов, а затем ненадолго приостановить автоматические действия, связанные с уходящим сотрудником или его рабочей станцией. В первую очередь проверьте такие пути: 1. Отзовите активные удаленные сессии там, где это поддерживают поставщик удостоверений, облачная платформа, хост системы контроля версий или система привилегированного доступа. 2. Отключите или изолируйте зарегистрированные исполнители сборки, запланированные задачи агентов и удаленные среды разработки, которыми владел сотрудник. 3. Удалите устройство из списков доверенных устройств, VPN и систем управления, если это допускает ваш рабочий процесс. 4. Приостановите фоновые задачи, которые могут выполнять развертывание, менять инфраструктуру, отправлять сообщения или записывать данные в клиентские системы. 5. Заберите рабочую станцию или установите для нее управляемые сетевые ограничения до того, как сотрудник перестанет контролировать ее. Не начинайте с удаления локальных файлов. Если увольнение оспаривается, выглядит необычно или связано с вопросом безопасности, сохраните состояние устройства по процедуре реагирования на инциденты. Поспешная очистка уничтожит историю командной оболочки, расшифровки работы агента, локальную конфигурацию, очереди задач и временные метки, которые могут показать, было ли действие разрешено. При обычном плановом увольнении ответственный за безопасность может решить, что действуют стандартные правила возврата и переустановки устройства. Это решение должно быть записано в заявке, а не храниться в чьей-то памяти. Полезная контрольная точка - граница процесса агента. До остановки локально работающего агента запишите путь к исполняемому файлу, родительский процесс, идентификатор процесса, время запуска, рабочий каталог и данные о подписывающей код организации. В macOS оператор может снять базовый снимок процессов так: ```sh ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent' # Output shape: # 8421 611 alice Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release ``` Сама по себе команда ничего не доказывает. Она дает расследованию привязанный ко времени ориентир и не позволяет свести всю запись к расплывчатому утверждению «агент работал». ## Составьте список полномочий, а не список программ Список установленных AI-инструментов не показывает, кто может изменить сервис. Учитывайте каждый путь к полномочиям, в том числе инструменты, которые вы не считаете AI. Сотрудник мог использовать агента через терминал, расширение редактора, исполнитель CI, локальный скрипт или удаленную среду. Важен маршрут, а не его название. Используйте одну строку для каждой пары «учетные данные или идентичность и связь с сервисом». Если один токен дает доступ к трем сервисам, перечислите все три последствия в поле области действия, а не прячьте их в примечаниях. | Путь к полномочиям | Где находится | Что позволяет делать | Владелец после увольнения | Действие | Подтверждение | | --- | --- | --- | --- | --- | --- | | Личная учетная запись в системе контроля версий | поставщик удостоверений | читать и изменять репозитории | руководитель разработки | отозвать сессии и отключить учетную запись | идентификатор заявки и временная метка | | Общий токен развертывания | хранилище секретов CI | развертывать в выбранных средах | владелец релиза | заменить и отозвать старый токен | событие ротации | | Закрытый SSH-ключ | рабочая станция и целевые узлы | получать доступ к оболочке на указанных узлах | владелец инфраструктуры | удалить открытый ключ и выпустить замену | запись об изменении узла | | Регистрация задания агента | сервис сборки | запускать запланированную работу | владелец платформы | отключить регистрацию и проверить очередь | экспорт задания | | Локальная конфигурация агента | профиль рабочей станции | указывать конечные точки и имена секретов | ответственный за безопасность | сохранить или удалить по решению о блокировке | квитанция о сборе | Сложнее всего найти общие полномочия. Задайте владельцам сервисов прямые вопросы: знает ли сотрудник токен, который продолжает действовать после отключения его учетной записи? Администрировал ли он учетную запись бота? Может ли его устройство подключаться по SSH-ключу? Запускалась ли какая-либо задача под общей учетной записью? Кто будет получать уведомления от этой задачи после сегодняшнего дня? Не делайте уходящего сотрудника единственным источником такой информации. Он может помочь, но ответ должны подтверждать репозитории, хранилища секретов, файлы authorized_keys, конфигурация CI, записи о владельцах сервисов и журналы аудита. Люди забывают о токене, созданном во время аварии. Они также забывают о тестовом исполнителе, который два года спустя стал частью production-инфраструктуры. ## Меняйте общие учетные данные в порядке зависимостей Меняйте любые общие учетные данные, которые уходящий сотрудник мог прочитать, скопировать, экспортировать или использовать вне надежного механизма отзыва, связанного с идентичностью. Сюда входят API-ключи, пароли basic-аутентификации, секреты вебхуков, токены развертывания, пароли баз данных, SSH-ключи, ключи облачного доступа и коды восстановления. Популярная, но ошибочная рекомендация - поменять все одновременно. Это выглядит решительно и дает впечатляющий список измененных секретов. Одновременно такой подход ломает неизвестные зависимости, усложняет диагностику и подталкивает команды вернуть старый секрет под давлением. Меняйте учетные данные поэтапно, сохраняя понятный и ответственный путь замены. Для каждой пары учетных данных действуйте так: 1. Назначьте владельца сервиса и точно перечислите вызывающие системы, которые используют эти данные. 2. Создайте замену с минимально возможной областью действия. 3. Обновите известные вызывающие системы и убедитесь, что они работают с заменой. 4. Отзовите старые данные, а затем проверьте, что они действительно перестали работать. 5. Запишите хранителя замены, время ее создания, область действия и результат отзыва. Проверка отказа важна. Фраза «ротация завершена» часто означает, что кто-то создал новый токен и обновил одно приложение. Она не означает, что старый токен перестал работать. Выполните безвредный аутентифицированный запрос, который раньше разрешали старые данные. Зафиксируйте ожидаемый отказ сервиса, например HTTP 401 или 403, но не вставляйте секреты в заявку. Для доступа по SSH удалите открытый ключ сотрудника из каждого источника authorized_keys на целевых узлах и из центральной системы доступа. Затем найдите автоматизацию, использующую тот же закрытый ключ. Если агент применял общую SSH-идентичность, выпустите новую пару ключей, замените открытый ключ на целевых узлах, обновите разрешенного вызывающего клиента и выведите старый открытый ключ из обращения. Удаление ключа только с рабочей станции ничего не меняет, если его копия уже существует. Никогда не отправляйте замену через чат или электронную почту в рамках передачи дел. Дайте новому владельцу разрешение получить или использовать ее через утвержденный механизм работы с секретами. Цель ротации - уменьшить число копий, которые невозможно учесть. ## У общих учетных записей должен быть конкретный владелец Сервисная учетная запись может быть оправданной, но общая учетная запись без названного оператора скрывает проблему владения. При передаче дел нужно назвать человека, который принимает ответственность за назначение учетной записи, ее область действия, расходы, способ восстановления и будущую ротацию учетных данных. Отделяйте операционное владение от самих учетных данных. Боту релизов может быть необходимо продолжать развертывания после ухода сотрудника. Это не означает, что новый сотрудник должен унаследовать личный токен бывшего владельца или использовать его локальную конфигурацию. Если сервис позволяет, дайте боту собственную идентичность, назначьте только необходимые разрешения и закрепите за новым владельцем ответственность за нее. Короткая запись о передаче должна отвечать на пять вопросов: - Какой сервис или рабочий процесс поддерживает учетная запись? - К каким средам и действиям она дает доступ? - Какие системы используют ее сегодня? - Кто может менять ее учетные данные или восстанавливать доступ? - Когда нужно проверить, нужен ли ей этот доступ по-прежнему? Здесь же часто обнаруживаются предположения агента, замаскированные под удобство. Локальная конфигурация может указывать агенту общую идентичность развертывания, потому что первоначальному разработчику было некогда настроить отдельную. Не сохраняйте такой обходной путь ради непрерывности. До возобновления работы замените его контролируемым путем доступа с назначенным владельцем. ## Сохраните записи до того, как их удалят задания хранения Сохраняйте записи, которые позволяют восстановить картину полномочий и действий без объяснений уходящего сотрудника. Зафиксируйте заявку на увольнение, список доступов, событие отключения идентичности, отзывы сессий, события ротации, историю заданий CI, записи запусков агента, решение о сборе устройства и экспорты аудита сервисов. Укажите часовой пояс и источник времени, если системы используют разные настройки. Сохранение - это не несколько скриншотов. На скриншоте теряются поля и фильтры, а сам снимок редко можно проверить. По возможности экспортируйте исходные записи в их родном формате, сохраняйте хеши собранных файлов, ограничьте доступ группой, работающей с делом, и документируйте, кто обрабатывал каждую копию. Следующая короткая заметка достаточно компактна для работы и достаточно конкретна для аудита: ```text Case: OFF-2025-041 Collected by: security-operator Collected at: 2025-03-12T09:37:16Z Source: build-service job history export Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z File: build-jobs.json SHA-256: Storage: restricted evidence repository Reason: employee exit and agent authority review ``` Храните исходный экспорт без изменений. Если расследующий специалист фильтрует его или добавляет пометки, сохраняйте это как отдельную рабочую копию. Такое простое разделение предотвращает больше споров, чем сложные криминалистические инструменты: анализ можно проверять, не меняя исходную запись незаметно. В NIST SP 800-92 управление журналами описывается как процесс генерации, передачи, хранения, анализа и удаления. При увольнении слабым местом обычно становится удаление. Короткий срок хранения по умолчанию может уничтожить единственную запись запуска, которая показывает, действовал ли агент до или после изменения доступа. Установите блокировку хранения для записей, которые разрешает сохранять ваша политика, а затем снимите ее обычным утвержденным способом. ## Сделайте разрешение агента отзывным для каждого процесса Одобрение одного процесса агента разработчиком не должно превращаться в безусловное разрешение для любого процесса, который может появиться на его компьютере. Процесс можно заменить, перезапустить из другого рабочего каталога или вызвать расширением редактора после ухода человека. В записи разрешения должны быть указаны идентичность процесса и возможность немедленного отзыва. Здесь может помочь шлюз, но только если он не передает учетные данные самому агенту. Sallyport хранит API- и SSH-учетные данные в зашифрованном локальном хранилище, по умолчанию авторизует новые процессы агентов отдельно для каждой сессии и записывает сессии и отдельные действия раздельно. При увольнении экспортируйте или сохраните нужные записи сессий и действий, отзовите активные сессии и заблокируйте хранилище до передачи устройства. Такой порядок создает понятную границу: агент не может выполнить новый внешний вызов, а записи его прошлых вызовов остаются доступными для проверки. Не путайте одобрение сессии с разрешением на любое важное действие. Агенту может быть достаточно сессии для чтения репозитория, тогда как каждое производственное изменение должно требовать отдельного подтверждения. Более строгий контроль нужен для учетных данных, злоупотребление которыми приведет к расследованию инцидента, а не для безвредных запросов только на чтение, которые быстро создадут усталость от подтверждений. Усталость от подтверждений - это ошибка проектирования. Если человек получает запрос на каждое обычное действие, он перестает их читать. Если одно подтверждение молча охватывает доступ к несвязанным production-системам, оно слишком широкое. Хорошая авторизация создает четкую границу, которую оператор может объяснить позже. ## Проверьте выполняющуюся работу и отложенные запуски Отзыв учетной записи не всегда останавливает работу, уже принятую удаленным сервисом. Проверьте сборки в очереди, удаленные оболочки, расписания автоматизации, ручные запуски рабочих процессов репозитория, публикацию пакетов, планы инфраструктуры и очереди сообщений, которые могут запустить работу позже. Для каждого выполняющегося или ожидающего элемента решите, отменить его, дать ему завершиться под наблюдением или передать новому владельцу. Решение должно зависеть от действия, масштаба возможного ущерба и возможности воспроизвести задачу. Развертыванию с известной записью об изменении можно позволить завершиться. Задача, которая меняет контроль доступа или перемещает данные, обычно должна остановиться, пока владелец не подтвердит намерение. До отмены сохраните идентификаторы. Одна ссылка на задание - слабое свидетельство, если сервис удаляет подробности после окончания срока хранения. Сохраните идентификатор задания, инициирующую идентичность, ссылку на коммит или задачу, время начала и окончания, использованные разрешения и результат. Если во время увольнения задача завершилась ошибкой, укажите, была ли она вызвана вашим отзывом доступа. Иначе в будущем успех контроля доступа могут ошибочно принять за операционную неисправность. Проверьте и отложенное выполнение. Записи cron, launch agents, расписания CI, правила облачных событий и рабочие процессы репозитория могут возобновить активность после того, как команда сочтет увольнение завершенным. Периодическую задачу нужно передать управляемому владельцу или отключить. Если оставить ее включенной под заброшенной учетной записью, следующая ошибка будет предсказуемой, но сложной для диагностики. ## Закрывайте заявку только после независимой проверки Человек, который вносит изменения, не должен единолично объявлять увольнение завершенным. Попросите специалиста по безопасности, владельца сервиса или руководителя проверить главное: бывший владелец не может войти, старые общие учетные данные не работают, под прежним владельцем не осталось запланированной работы агента, а собранные свидетельства доступны для чтения и защищены. Используйте заключительную запись, в которой указаны проверенные факты, а не расплывчатое «завершено»: ```text Former identity: disabled and active sessions revoked Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked Agent work: 2 scheduled jobs transferred, 1 queued job canceled Evidence: exports and collection hashes stored under case OFF-2025-041 Exceptions: none Verified by: service owner and security reviewer ``` Если учетные данные нельзя сразу заменить, не закрывайте заявку. Запишите компенсирующее ограничение, ответственного и срок. Фраза «сделаем позже» не является мерой контроля. Ограничение на уровне брандмауэра, отключенный рабочий процесс или временная приостановка сервиса могут быть такой мерой, если кто-то проверяет их и знает срок окончания. Начните с простого изменения: добавьте список полномочий и решение о блокировке хранения свидетельств в существующую HR-заявку на увольнение. Эти два поля заставляют обсудить важное до того, как исчезнет ноутбук, сохранится токен или задание хранения журналов удалит единственную запись о действии агента.