Ротация доступов раз в квартал: простой регламент для маленькой команды

MAATRIX

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

Почему без регламента ротация просто не случается

«Мы же не большая компания, у нас и так все на виду» — самое частое объяснение, почему в команде из пяти-семи человек никогда не пересматривали доступы. Логика понятна, но она проверяется не размером команды, а количеством решений, принятых за последний год: каждый новый подрядчик, каждый тестовый сервер, каждая интеграция, которую подключили «на попробовать», оставляет за собой доступ, о котором через полгода не вспомнит никто, кроме того, кто его выдавал — а иногда и он тоже.

Проблема не в том, что кто-то плохо делает свою работу. Проблема в асимметрии: выдача доступа занимает минуту и происходит по конкретному поводу (нового человека нужно посадить за задачу прямо сейчас), а отзыв доступа не привязан ни к какому событию — повод для него нужно создавать искусственно. Без регламента этот повод либо не появляется годами, либо появляется в худший момент: после инцидента, утечки или прямого вопроса от клиента «а кто вообще может зайти в наши данные».

Ротация раз в квартал — это способ превратить отзыв доступов из события, которое должно кто-то «вспомнить», в рутину, которая происходит сама, потому что стоит в календаре и у неё есть владелец. Дальше по тексту — не про то, как провести глубокий технический аудит (это отдельная и более трудоёмкая задача, которая подробно разобрана в статье про квартальную ревизию доступов), а про то, как выстроить лёгкий регулярный процесс, который команда из трёх-десяти человек реально будет соблюдать, а не забросит после второго раза.

Кто отвечает за ротацию — даже если админ один

У любого регламента, который не привязан к конкретному человеку, есть ровно один сценарий: он существует на бумаге и не выполняется никогда. «Ответственный — вся команда» на практике означает «ответственного нет», потому что задача, которая формально принадлежит всем, психологически не принадлежит никому конкретно.

В маленькой команде роль владельца ротации не требует отдельной штатной единицы — её можно и нужно совместить с уже существующей ролью:

• Если в команде есть выделенный админ или DevOps — ротация естественным образом ложится на него, потому что он и так ближе всех к серверам и панелям.
• Если техническая работа распределена между несколькими людьми без явного «главного» — назначьте владельца явно, одним сообщением в общем чате: «с этого квартала ротацию доступов раз в три месяца делает Х». Это не должность, а просто закреплённая обязанность.
• Если в команде всего два-три человека и все технические — ротацию всё равно стоит закрепить за одним, а не выполнять её «как получится» каждый раз силами того, кто первым вспомнил. Иначе сработает тот же эффект размытой ответственности, только в миниатюре.

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

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

Как поставить ротацию в календарь, чтобы про неё не забыли

Самая частая причина, по которой регламент умирает после одного-двух прогонов, — он держится на человеческой памяти вместо системы напоминаний. «Мы договорились делать это раз в квартал» без привязки к конкретной дате означает, что квартал незаметно превратится в полгода, а полгода — в «когда-нибудь вспомним».

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

Практический способ закрепить это без специального инструмента:

• Повторяющееся событие в общем календаре команды (Google Calendar, Outlook — не важно) с точной датой и владельцем в качестве обязательного участника. Напоминание за три-пять дней до даты, а не в самый день, чтобы был запас времени на вечер вместо аврала.
• Повторяющаяся задача в трекере (Trello, Jira, Linear, простой список задач) с чек-листом из трёх вопросов прямо в описании — тогда чек-лист и напоминание живут в одном месте, и не нужно отдельно помнить, что смотреть.
• Если в команде уже есть еженедельная или ежемесячная планёрка — добавьте туда разовый пункт «раз в квартал: проверить, прошла ли ротация доступов» как элемент повестки, который сам себя контролирует через регулярность встречи.

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

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

Что делать с находками: отозвать, сменить, зафиксировать

Чек-лист без действия по его итогам — это просто список наблюдений, а не ротация. Найденные лишние доступы стоит закрывать в тот же вечер, а не переносить на «на следующей неделе» — практика показывает, что отложенное на потом почти всегда доживает до следующего квартала нетронутым.

Порядок действий по итогам чек-листа:

1. Явно лишние доступы отзывайте сразу. Учётка подрядчика с закрытым полгода назад проектом, тестовый аккаунт без владельца, доступ бывшего сотрудника, который почему-то ещё жив, — здесь не нужно дополнительное согласование, отзывайте прямо во время вечера ротации.
2. Сомнительные случаи — на короткое уточнение, не на паузу. Если непонятно, нужен ли доступ (например, это может быть сервисный аккаунт для автоматизации, а не забытая учётка человека), напишите короткое сообщение ответственному за систему и подождите ответа день-два — но зафиксируйте в таблице сам факт «на уточнении», чтобы вопрос не потерялся между кварталами.
3. Общие пароли меняйте и раздавайте заново осознанно. После смены пароля от общего ресурса не рассылайте его всем по старой привычке — раздайте только тем, кому он реально нужен по итогам вопроса 2. Смена пароля без пересмотра списка получателей воспроизводит ту же проблему в следующем квартале.
4. Зафиксируйте итог в таблице с датой и подписью того, кто отзывал. Это не бюрократия ради бюрократии: через год без этой записи вы не сможете отличить ротацию, которая реально прошла, от той, которую формально запланировали, но забыли провести.

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

Чем плановая ротация отличается от срочного отзыва при увольнении

Важно не путать два разных процесса, которые решают разные задачи. Плановая квартальная ротация — это профилактика: вы проверяете всю команду сразу, по расписанию, независимо от того, произошло что-то заметное или нет. Срочный отзыв при увольнении или уходе конкретного человека — это реакция на конкретное событие, и она не может ждать ближайшего квартала.

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

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

Полезно держать в голове ещё одну параллель: у команды, где уже есть привычка составлять карту доступов — понимание, кто и куда реально может попасть прямо сейчас, — квартальная ротация занимает заметно меньше времени, потому что чек-лист превращается в сверку актуального состояния с картой, а не в расследование с нуля.

Частые вопросы