Почему старые доступы живут годами
Подрядчик получает доступ к задаче, папке, CRM и чату. Проект завершается, но владельцы систем по-разному понимают, кто отвечает за отзыв. Иногда аккаунт формально выключен, а токен интеграции или приглашение в облачную папку остаётся. ИИ может помочь собрать несоответствия из нескольких реестров, но не знает организационного контекста сам по себе. Цель работы — составить проверяемый список потенциально лишних прав, а не нажать кнопку «заблокировать всех, кто давно не входил». Редкий вход не доказывает, что доступ больше не нужен.
Соберите минимальный реестр
Нужны четыре источника: договор или заявка на подрядчика, список систем, фактически выданные роли и дата завершения работы. Добавьте владельца доступа в компании и ожидаемую дату пересмотра. Не передавайте в языковую модель пароли, токены и полный дамп журналов. Для сопоставления достаточно идентификаторов, ролей и статусов. Если реестры называют одного человека по-разному, установите однозначное соответствие вручную. Поспешное объединение двух тёзок приведёт к отзыву не того доступа. Сохраните исходные выгрузки и время их получения.
Сначала правила, потом подсказка модели
Запишите правила выявления кандидатов: договор завершён, владелец не подтвердил продление, роль шире задачи, доступ в системе без заявки, токен не привязан к активному сервису. Каждый признак — повод проверить, а не автоматический приговор. ИИ может разложить записи по причинам и подготовить вопросы владельцам. Требуйте, чтобы ответ ссылался на конкретную строку реестра и правило. Запретите модели формировать письмо подрядчику с обвинением в нарушении. Ошибка данных или задержка обновления HR-системы случается чаще, чем злой умысел.
Проверяйте цепочку зависимостей
Перед отзывом технический владелец смотрит, не использует ли аккаунт действующая интеграция и не связан ли он с обязательной отчётностью. Отдельно находят общие аккаунты — они опасны сами по себе, но их нельзя отключать без плана замены. Доступ к файлам, гостевое приглашение и OAuth-разрешение требуют разных процедур отзыва. ИИ может составить чек-лист по системам, но действия выполняет администратор с журналом изменений. Для чувствительных данных нужен приоритетный срок, а не общее «проверим позже».
Пилот без риска остановки
Начните с десяти уже завершённых проектов и только режима чтения. Два владельца независимо проверяют предложенный список. Измерьте, сколько действительно лишних прав найдено, сколько ложных срабатываний и сколько времени ушло на каждое решение. Добавьте контрольные записи: действующий подрядчик, продлённый договор, сервисный аккаунт. Если модель путает их с бывшими сотрудниками, уточните правила сопоставления. Не расширяйте пилот до всех систем, пока в журнале нет объяснения каждой рекомендации.
Оформите отзыв как управляемое изменение
После подтверждения владелец назначает исполнителя и порядок: завершить активную задачу, передать файлы, отключить вход, отозвать токены, проверить общий доступ, уведомить ответственных. Для некоторых систем нужно сохранить отчёт или экспорт перед закрытием. Запишите дату, конкретное право и результат повторной проверки. Не публикуйте подробности доступа в общем чате; короткого уведомления о завершении работ достаточно. Если подрядчик вернётся, доступ выдаётся по новой заявке и новой роли, а не включением старого пакета без пересмотра.
Как поддерживать порядок
Разовая большая чистка быстро устареет. В каждой новой заявке на доступ заранее указывайте владельца, цель, минимальную роль и дату пересмотра. При закрытии проекта создавайте задачу на отзыв прав. Раз в месяц сверяйте список подрядчиков и активных учётных записей. ИИ может подготовить расхождения, а человек — подтвердить их и оставить причину исключения. Сравните процесс с материалом о безопасном запуске ИИ-процесса и гайдом по проверке ответов: во всех случаях важны исходник, решение человека и журнал.
Частые вопросы
Можно ли блокировать по отсутствию входа 90 дней? Нет, это только сигнал для проверки: сезонные задачи могут быть редкими. Нужно ли давать модели журналы целиком? Обычно нет; подготовьте минимальную обезличенную выгрузку. Как понять, что ревизия закончена? Не по числу закрытых карточек, а по подтверждённому владельцу каждого остающегося доступа и проверке фактического отзыва лишнего. Что делать с неясным владельцем? Назначить ответственного за выяснение и ограничить риск до решения, а не оставлять запись без статуса.
Проверка спустя месяц
Через месяц после ревизии возьмите десять закрытых карточек и независимо проверьте доступ в каждой системе. Иногда запись об отзыве есть, а гостевое приглашение или токен остались активными. Сравните дату закрытия проекта с датой фактической блокировки и причиной задержки. Для разрешённых исключений запросите новое подтверждение владельца и ближайший срок пересмотра. Если одна и та же ошибка повторяется, исправьте этап закрытия проекта, а не просто просите нейросеть чаще искать забытые учётные записи. Устойчивый результат зависит от понятной ответственности и проверки действия в системе.