Кто, к чему и до какого числа
Вся работа с доступами вырастает из трёх событий: человек пришёл, человек перешёл в другой отдел, человек ушёл. Процесс почти всегда построен только под первое. Причина простая и обидная: новичок, которому не выдали доступ, приходит и жалуется сам. Никто и никогда не приходит жаловаться, что у него остался доступ, которого быть не должно.
Разговор идёт сразу для двух ролей. Системный администратор приходит сюда с учётной записью в домене, почтовым ящиком, файловыми ресурсами, VPN, учёткой в 1С, локальным администратором на рабочих станциях и общей записью «на смену» в цеху. DevOps-инженер — с ключом доступа к облаку, SSH-ключами на серверах, токеном в системе контроля версий, доступом в конвейер сборки и выката и сервисной учёткой, от имени которой ходит автоматика. Предметы разные, события одни и те же, поэтому примеры в темах чередуются.
- называть три события жизненного цикла учётной записи и объяснять, почему перевод и расставание опаснее приёма;
- показывать, что «роли вместо персональных прав» и «минимальные права» — это текст нормы, а не совет из блога;
- объяснять, почему широко описанная роль хуже трёх точечных выдач;
- называть день, в который гасится доступ увольняющегося, и цену ошибки на день раньше;
- отличать «нажал отключить» от «доступ закрыт» и знать, что живёт дольше учётной записи;
- составлять список того, что не гасится общим рубильником;
- назначать срок ревизии, понимая, откуда берутся цифры и чего в российских нормах нет.
Парольной политики, второго фактора, хранилища секретов и порядка действий при компрометации самого секрета: здесь разбирается, кто и на какой срок получает право, а не чем это право закрыто. Кадровой стороны расставания — выходного интервью, сроков расчёта, отчётности. Политики хранения журналов: журнал появится только как условие доказывания. Нормативки для государственных информационных систем. Договорной стороны аутсорса и инвентаря машин и сервисов. Всё перечисленное — соседние темы каталога.
Уровень не предполагает подготовки. Слова «федерация», «refresh-токен», «роль», «привилегированная учётная запись» объясняются с нуля, в том месте, где впервые понадобятся.
Приём, перевод, расставание — и одна общая ошибка
Жизненный цикл учётной записи — это три события: приём, перевод, расставание. В англоязычных документах их называют joiner, mover, leaver; устоявшихся русских терминов нет, и дальше используются именно «приём», «перевод», «расставание».
Первое событие видно всем. Человек вышел на работу, ему не завели почту — он не может работать и приходит с этим сам, в первый же день. Обратная связь мгновенная, поэтому процесс приёма в организациях обычно есть, пусть и в виде переписки.
Два других события не видны никому. При переводе человек получает права нового отдела и молчит о правах старого — они ему не мешают. При расставании человек уходит, и жаловаться на живую учётную запись некому: он ей не пользуется, а вы о ней не помните.
Два накопительных эффекта
Человек прошёл три отдела. При каждом переводе ему выдавали новое и не снимали старое. Формально он специалист одного отдела, фактически у него права трёх. Английское название — privilege creep, ползучее расширение привилегий.
Запись жива, человека в организации нет. Она ничего не нарушает, не подаёт сигналов и не попадает ни в один отчёт, пока ею кто-нибудь не воспользуется.
Насколько это вообще про утечки
Здесь нужна честная рамка, иначе тема продаётся обманом. Отчёт Verizon DBIR за 2026 год даёт такую картину действий в утечках.
Обратите внимание на третью цифру. Внутренние акторы — это 12% утечек, а умышленное злоупотребление правами (паттерн Privilege Misuse) занимает в отчёте 2026 года менее 4% утечек — против почти 8% в отчёте 2024 года. Для сравнения: ошибки персонала дают около 9%.
Отчёт формулирует это прямо: ваши собственные люди гораздо вероятнее потеряют актив или совершат ошибку, чем намеренно злоупотребят своим доступом. Поэтому обещание «наведём порядок в доступах — не будет утечек» неверно: главный вектор внешний. Управление доступом делает другое — уменьшает ущерб от того, что всё-таки случилось, и делает разбор возможным. Без персонифицированных учётных записей разбирать нечего.
Мотивы у внутренних нарушителей тоже не такие, как принято думать. В паттерне Privilege Misuse отчёт насчитал 1 141 инцидент, из них 766 с подтверждённым раскрытием данных; акторы внутренние в 100% случаев, а главный мотив — удобство, 60%. Финансовый мотив — 33%, шпионаж и обида — по 4%. Типовой пример из отчёта: сотрудник хочет поработать из дома и отправляет корпоративные данные на личную почту. Умысла навредить нет, утечка есть.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.