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

Чек-лист увольнения закрывает один день. Заявка закрывает все остальные: новый сотрудник, перевод, подрядчик на месяц, «дайте ещё админку на тест». Без формы права выдают в чате, а снимают, когда вспомнят. Заведите один канал заявки, двух согласующих и дату окончания там, где доступ не бессрочный.

Статья опирается на логику направления «Управление доступом» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Блокировка в день увольнения: привилегированный доступ и увольнение. Кого звать на согласование: матрица ответственности.

Что должно получиться

Нет доступа без строки в журнале заявок. Стандартная роль по должности идёт быстрее, чем исключение. У временного доступа есть дата окончания и напоминание. Отзыв при переводе не ждёт увольнения.

Какие поля вести

id,person,system,role,reason,from,until,manager_ok,ib_ok,it_done,revoked
2026-10-14-01,Иванов,crm,operator,новая должность,2026-10-15,,да,да,да,
2026-10-14-02,подрядчик-А,vpn,read,аудит договора,2026-10-20,2026-11-20,да,да,да,

Поля:

• person — человек, не группа «все из отдела».
• system и role — система из реестра активов и роль, а не «полный доступ».
• until — обязателен для подрядчика, совместителя, пилота и любого доступа шире должности.
• manager_ok — руководитель, которому нужны эти права у человека.
• ib_ok — ответственный за ИБ для привилегированных ролей, доступа к персональным данным и исключений.
• it_done — кто технически выдал; без этой отметки заявка не закрыта.
• revoked — дата отзыва; пусто только пока доступ действует.

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

Кто согласует

ИБ не подменяет руководителя: руководитель говорит «этому человеку это нужно», ИБ говорит «роль не шире необходимого и есть MFA». Парольные правила для класса учётки: парольная политика. Технически минимум прав: sudo и sudoers.

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

Как отозвать не только при увольнении

1. Перевод: в той же заявке или новой строке снимите старую роль в день выхода на новое место. Не копите доступы «на всякий случай».
2. Окончание until: за неделю календарь напоминает исполнителю ИТ; в день даты — блокировка или снятие роли, отметка revoked.
3. Отказ в доступе: строка остаётся со статусом отказа, чтобы повторный запрос был виден.
4. Подрядчик сдал работу раньше: владелец договора пишет отзыв, не ждите даты в договоре.

Сами команды блокировки те же, что при увольнении; здесь важен процесс заявки, а не повтор чек-листа кадрам. Забытые живые учётки ищите отдельно: в Active Directory и в Linux.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (хаб: управление доступом, карта: карта зрелости). Базовый уровень — личные учётки и выдача по заявке. Гигиена — заявка с ролью, согласованием и отзывом, а не продукт IDM. Увольнение остаётся отдельным срочным контуром; заявка закрывает плановую жизнь доступа.

Как проверить

1. Есть один журнал заявок с полями роли, согласующих и until.
2. Последние пять выдач привилегированного доступа имеют отметку ИБ до выполнения.
3. У действующих подрядчиков заполнена дата окончания, просроченных без revoked нет.
4. По последнему переводу старая роль снята в тот же день или на следующий рабочий.
5. Выдача «в чате» за последний месяц либо отсутствует, либо оформлена задним числом и запрещена дальше.

Источники

• CIS Controls v8.1, контроль 6 (создание, назначение и отзыв прав). Это не закон РФ: cisecurity.org.
• NIST Cybersecurity Framework 2.0, идентичности и доступ. Это не закон РФ: nist.gov/cyberframework.
• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.