Чтобы 80% запросов на доступ закрывал Service Desk, нужно перестроить процесс так, чтобы первая линия работала по чётким шаблонам, а не по “ручному согласованию” и переписке с админами. Ключ — стандартизировать типы доступов, жёстко описать правила и максимально автоматизировать “простые” сценарии.
1. Принципы: что именно должен делать Service Desk
В ITIL доступом формально управляет Access Management, но технически процесс часто исполняют команды эксплуатации и сама первая линия. При этом Service Desk — основной вход для запросов на доступ: пользователи создают запросы, а дальше либо всё решается по стандарту на первой линии, либо уходит на эскалацию.
Что важно определить на старте:
- Какие типы доступа Service Desk может сам выдавать/изменять (по шаблонам).
- Какие запросы он только регистрирует и маршрутизирует (админам, безопасности, владельцам систем).
- Какие запросы вообще запрещено обрабатывать без отдельного change / security approval (админские права, критичные системы).
2. Каталог доступов и “стандартные запросы”
Без нормального каталога сервисов и ролей любая попытка отдать 80% на Service Desk провалится. Нужно перевести “хаос прав” в понятный каталог стандартных запросов и ролей, к которым привязаны условия выдачи.
Сделайте:
- Каталог сервисов и приложений: что есть, кто владелец, какие есть типовые роли (User, Power User, Read-only и т.п.).
- Стандартные запросы на доступ: “Доступ к CRM: роль Sales”, “Доступ к Jira: роль Developer”, “Доступ к файловой шаре Отдел продаж: чтение/запись”.
- Для каждого стандартного запроса — чёткие правила:
Кто может запрашивать (роль, подразделение, должность).
Чья авто- или ручная approval нужна (руководитель, владелец системы).
Условия отключения (уход сотрудника, смена роли, пересмотр оргструктуры).
Чем лучше структурирован каталог, тем проще будет автоматизировать и отдать выполнение первой линии и/или самообслуживанию.
3. Ролевое управление (RBAC) как основа
Чтобы Service Desk не раздавал права “на глазок”, нужно перейти от “доступ конкретному пользователю” к ролевой модели. Сами роли настраивают безопасность и владельцы систем, а Service Desk распределяет людей по ролям по понятным правилам.
Практически:
- Определите базовые роли по функциям: “Сотрудник отдела продаж”, “Бухгалтер”, “HR-специалист”, “Стажёр IT” и т.д.
- Привяжите к ролям набор доступов: системы, группы в AD, лицензии, права в приложениях.
- Для Service Desk сформулируйте простые правила:
“Новый сотрудник отдела продаж” → назначить роль Sales → автоматический набор доступов.
“Перевод из Sales в Marketing” → убрать одну роль, добавить другую (в идеале — один запрос). - Для всего нестандартного — отдельный процесс (change или согласование с безопасностью).
Так Service Desk перестаёт “придумывать, что выдать” и просто исполняет заранее согласованные шаблоны.
4. Жизненный цикл доступа: от онбординга до офбординга
Большая часть запросов на доступ — это типовые события: приём на работу, перевод, отпуск, увольнение. Если связать их с HR и ITSM, до 80% можно обработать без ручного вмешательства второй линии.
Что сделать:
- Онбординг:
Интеграция с HR: при создании сотрудника с должностью/отделом автоматически создаётся стандартный запрос на набор ролей.
Service Desk контролирует корректность данных и статусы, но не “собирает” права вручную. - Перевод/изменение роли:
Шаблон “изменение роли” вместо десятка отдельных тикетов на разные системы.
Ясная логика: новые роли добавляются, старые снимаются (особенно доступы к старому отделу). - Офбординг:
Триггер из HR на увольнение/декрет и т.п.
Автоматический пакет: блокировка учётной записи, отзыв прав, отключение VPN, деактивация в SaaS.
Чем теснее связаны HR и ITSM/IDM, тем меньше ручных запросов вообще появляются на Service Desk.
5. Что можно отдать Service Desk на 100%
Чтобы первая линия закрывала до 80% запросов, нужно явным образом “списком” определить, что именно считается её зоной ответственности.
Типовые кандидаты:
- Пароли и учётные записи:
Сброс пароля (через self-service и/или по процедуре Service Desk).
Разблокировка аккаунта при соблюдении проверок. - Доступы “низкого риска”:
Доступ к общим информационным ресурсам (общие папки, Wiki, портал).
Read-only доступ к нефинансовым отчётам и некритичным данным. - Лицензии и SaaS с ограниченными рисками:
Назначение/снятие стандартных лицензий (Office 365, базовые роли в Jira, Confluence и т.п.) по заранее описанным правилам. - Временные доступы:
Временное расширение прав с автоматическим истечением (например, на 8 часов и только после approval менеджера).
По каждому из этих сценариев нужны подробные инструкции, чтобы сотрудник Service Desk мог отработать запрос без эскалации.
6. Что должно остаться у безопасности и второй линии
Чтобы не превратить Service Desk в “раздатчика админок”, важно зафиксировать запреты. Эти категории нельзя обрабатывать по упрощённым схемам первой линии.
Примеры:
- Администраторские права (local admin, domain admin, root-доступ, админские роли в бизнес-критичных системах).
- Доступ к финансовым, персональным и иным чувствительным данным выше определённого уровня.
- Любые нестандартные комбинации прав, которые не укладываются в роли.
- Запросы, требующие выполнения сложных технических операций (изменение конфигурации серверов, базы данных, firewall).
Для них нужны:
- Отдельные процессы (Change enablement, Security change).
- Обязательное участие владельца системы и/или безопасности.
- Документированное обоснование и журнал принятия решений.
7. Автоматизация и порталы самообслуживания
Чтобы Service Desk реально успевал закрывать 80% запросов, часть его “рутины” должна уйти в самообслуживание. Первая линия тогда контролирует, а не вручную “щёлкает” каждый доступ.
Что можно автоматизировать:
- Портал запросов:
Пользователь выбирает не “доступ в систему X”, а конкретный шаблон: “Хочу роль Y в системе X”.
Встроенные проверки: если нет нужной должности/отдела, такой запрос просто нельзя отправить. - Авто-approvals:
Для низкорисковых ролей — автоматическое одобрение (по утверждённым правилам).
Для остальных — быстрый маршрут руководителю/владельцу, но без участия админов до момента фактической выдачи. - Интеграция с IDM/AD:
Одобренный запрос → автоматическое добавление в группу в AD / назначение роли в приложении.
Service Desk следит за ошибками/исключениями, а не делает работу руками.
Такие схемы уменьшают нагрузку, сокращают ошибки и повышают долю “первой линии + автоматизация” до нужных 80%.
8. Регламенты, обучение и контроль
Даже лучший процесс не заработает, если его не закрепить регламентами и не обучить Service Desk. Одновременно важно иметь обратную связь от аналитиков первой линии, чтобы улучшать каталоги и роли.
Нужно:
- Регламенты:
Политика управления доступами (связь с информационной безопасностью).
Подробные рабочие инструкции для Service Desk по каждой категории запросов. - Обучение:
Базовые знания по безопасности, принципам минимально достаточных прав и конфиденциальности данных.
Тренинги по работе с каталогом ролей, IDM и порталом запросов. - Контроль:
Периодический аудит выданных доступов (особенно временных и расширенных).
KPI: доля запросов на доступ, закрытых на первой линии; время выполнения; количество инцидентов, связанных с неверно выданными правами.
Так выстроенный процесс делает Сервис Деск центральной точкой управления доступами в рамках понятных границ, снижает нагрузку на администраторов и безопасность, и при этом сохраняет контроль и соответствие политикам безопасности.