Управление доступом как услуга: заявки, роли и ревизии прав

Доступ через заявку, а не «по-быстрому»

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

• Согласование владельцем ресурса — доступ к финсистеме одобряет финдиректор, а не ИТ по своему усмотрению (см. маршруты согласования);
• След в аудите — кто, когда, на основании чего получил доступ. Бесценно при проверке и расследовании;
• Обоснование — в заявке зафиксировано «зачем», а не «потому что попросил».

Это частный, но важнейший случай Request Fulfillment: запрос на доступ — типовая услуга с шаблоном, согласованием и SLA. И в отличие от «дать монитор», цена ошибки тут — инцидент безопасности.

Ролевые модели вместо ручной выдачи

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

• «Бухгалтер» = 1С + банк-клиент + папка «Бухгалтерия» — один пакет;
• новому сотруднику выдаётся РОЛЬ, а не 15 отдельных прав;
• при переводе на другую должность — меняется роль, старые права снимаются.

Это та же логика, что ролевая модель в самом helpdesk, применённая к корпоративным ресурсам. Матрица «роль → права» — главный артефакт: она же используется при онбординге (что выдать) и офбординге (что отозвать). Поштучную выдачу оставляют для редких исключений — и они тоже идут через заявку с усиленным согласованием.

Регулярные ревизии прав (recertification)

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

• раз в квартал/полгода владельцы ресурсов подтверждают, кому доступ ещё нужен;
• неподтверждённые права отзываются;
• особое внимание — привилегированным учёткам (админы) и доступу к чувствительным данным.

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

Отзыв доступа: увольнение и смена роли

Самая частая дыра — не отозванный вовремя доступ. Уволенный сотрудник с работающим VPN — прямой канал утечки и нарушение 152-ФЗ. Процесс должен срабатывать в момент события, а не «когда дойдут руки»:

• Увольнение → немедленный отзыв всех доступов по матрице роли (учётка, VPN, токены, облако). Триггер — из HR-системы или офбординг-заявки.
• Перевод/смена роли → снять права старой роли, выдать новой (а не «добавить новые поверх старых»).
• Окончание проекта → отозвать временные проектные доступы (их полезно выдавать с датой истечения сразу).

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

Аудит и соответствие

Управление доступом как услуга даёт то, чего нет при «раздаче по чату», — полную аудируемость:

• по каждому доступу видно: кем запрошен, кем согласован, когда выдан, когда отозван;
• по сотруднику — полный текущий профиль доступов;
• по ресурсу — список всех, у кого есть доступ (для ревизии).

Это закрывает требования 152-ФЗ/187-ФЗ/ФСТЭК по управлению доступом и разграничению прав, и превращает страшный вопрос проверяющего «покажите, кто и на основании чего имеет доступ к ПДн» из паники в выгрузку из системы. Принцип, который всё это связывает, — минимальные привилегии: каждый имеет ровно те права, что нужны для работы, не больше, и ровно столько времени, сколько нужно.