Сотрудник уволился, мне сразу закрывать все его аккаунты? Насколько срочно нужно действовать?

закрывай сразу не тяни но в течение часа после последнего дня отключишь весь доступ. отключи AD, отзови VPN, настрой переадресацию почты, сделай бэкап. если сотрудник проблемный то тем более срочно. github/aws закрывай по одному...

Чек-лист по увольнению: 1) Active Directory: отключить юзера + сброс пароля, антивирус; 2) Почта: правило пересылки (на менеджера или в архив), 3) Облако: удалить/отозвать AWS IAM юзера, приостановить Google Workspace, отключить в Azure AD, 4) VPN/SSH: удалить публичный ключ, отозвать сертификат, 5) Сторонние приложения: отозвать права админа в Slack, убрать коллаборатора с GitHub, 6) Физика: деактивировать пропуск, забрать ноут/телефон, отключить SIM. Автоматизация: платформа управления идентичностью (Okta, Azure AD), единый выход (отключение юзера = автоматический отзыв доступа ко всем приложениям). Передача знаний: документация, передача кода в репо, контакты для эскалации.

не тяни братан, как только сотрудник уходит в этот же день (end of day) рубим весь доступ. настрой пересылку почты на другого админа, сделай бэкап файлов это обязательно потом если корпоративные данные останутся на его девайсе — будут проблемы, он мог скопировать всю компанию...

Этапы offboarding'а: 1) Перед уходом (период отработки): передача знаний, инвентаризация активов, бэкап данных, 2) День увольнения: отключение доступа, сбор активов, вайп устройств, 3) После ухода: аудит доступа архивация данных хранение почты (compliance). Ритуал: exit interview (опрос уходящего сотрудника), подпись чек-листа по комплаенсу. Автоматизация: мониторинг логов в SIEM (флаг активности экс-сотрудника), алерты. Аудит-трейл: логи доступа хранятся 6-12 месяцев (compliance, расследования).

15 лет в IT-менеджменте, не раз косячил. Позднее отключение доступа при увольнении = риск кражи данных. Best practice: даже если есть период отработки, ограничиваем доступ, полное удаление доступа — в конце дня увольнения, без задержек. Пересылка почты 1 год, потом удаление. Файлы компания должна бэкапить.

У меня было наоборот поэтому и пишу. Пытаться сделать это в одиночку — самый дорогой путь.

Я бы пошел этим путем.

Я столкнулся с тем же два года назад. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Я бы пошел этим путем.

Редко встретишь текст с такой ясностью изложения. Без измерений мы всегда приходим к одному и тому же.

Исправьте, если я ошибаюсь.

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

Пишите, если есть вопросы, отвечу по мере возможности.

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

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

Вы правы.

Здесь нужно провести различие. Ответ сильно зависит от отрасли, универсального правила нет.

Конечно если ваша ситуация отличается, всё меняется.

Именно так. Главное не цифра, а то, на основе чего она получена.

Исправьте, если я ошибаюсь.

Я проходил через это, расскажу. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Забытые тестовые среды становятся входом в систему чаще, чем продакшн. Исправьте, если я ошибаюсь.

Попробую. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Ответ сильно зависит от отрасли, универсального правила нет. Если напишете результат здесь, это поможет и другим.

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

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

Хочу предупредить. Непроверенная резервная копия — не резервная копия.

Все, кто торопится с отключение доступа при увольнении сотрудника, спотыкаются на одном и том же. Удачи.

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