Суть. У пользователя, службы или программы должны быть ровно те права, что нужны для задачи. Две основные модели: доступ по роли — просто и понятно, доступ по признакам — гибко и сложнее. Выбор зависит не от вкуса, а от того, сколько исключений накопилось в ролевой модели.
Две модели
| По роли | По признакам | |
|---|---|---|
| Логика | Права привязаны к должности | Права вычисляются из свойств: подразделение, проект, время, устройство, чувствительность данных |
| Плюс | Понятно и легко проверяется | Один набор правил вместо сотни ролей |
| Минус | Число ролей растёт от исключений | Труднее объяснить, почему доступа нет |
| Признак, что пора менять | Ролей больше, чем людей | Никто не может объяснить решение системы |
Что работает на практике
- Пересмотр раз в полгода. Обычно показывает, что у трети сотрудников остались доступы от прошлых задач.
- Права по запросу на срок. Повышенный доступ выдаётся на часы, а не навсегда.
- Отдельные учётные записи для программ. Особенно для ИИ-агентов: разбирать инциденты под человеческой записью невозможно.
- Процедура при увольнении. Отзыв доступов в тот же день, а не когда вспомнят.
Почему права всегда расширяются
Доступ выдают быстро — под задачу и под срок, — а отзывают почти никогда: некому и незачем. Через два года у половины сотрудников набор прав, отражающий их прошлые роли, а не текущие. Это не халатность, а свойство процесса, в котором нет обратного хода.
Четыре механизма
| Механизм | Что решает | Стоимость внедрения |
|---|---|---|
| Роли вместо персональных прав | Права привязаны к должности, а не к человеку | Средняя: нужен разбор реальных задач |
| Временный доступ | Права выдаются на срок и снимаются сами | Средняя, зато решает основную проблему |
| Повышение по запросу | Административные права берутся на операцию | Высокая, требует инструментов |
| Регулярный пересмотр | Раз в квартал руководитель подтверждает права команды | Низкая: только дисциплина |
Последняя строка даёт лучшее соотношение эффекта к затратам и почему-то внедряется реже всех.
С чего начать
- Выгрузить, у кого есть административные права в ключевых системах. Список почти всегда удивляет.
- Снять права у тех, кто сменил роль больше полугода назад.
- Отделить учётные записи администраторов от повседневных: работа под правами администратора — источник большинства инцидентов.
- Ввести правило: доступ подрядчику выдаётся на срок договора и с датой окончания в системе.
- Назначить квартальный пересмотр с именем ответственного.
Где ломается
Права выдают «чтобы не мешать». Самая частая причина: запрос доступа обрабатывается три дня, поэтому выдают с запасом.
Нет владельца системы. Некому решить, кому что положено.
Пересмотр формальный. Руководитель подтверждает список из ста строк не читая — и всё остаётся как было.
- Ограничения мешают работать. Люди находят обход — общий пароль, личный ноутбук, экспорт в таблицу. Это хуже широких прав, потому что невидимо.
- Пересмотр формальный. Руководитель подтверждает всё списком не глядя; помогает показывать только изменения и неиспользуемые права.
- Сервисные учётные записи забыты. У них обычно самые широкие права и самые старые пароли.
- Нет процесса выхода. Увольнение отражается в кадровой системе и не отражается в доступах.
Частые вопросы
Связанное
Права выдают на старте и почти никогда не забирают. Пересмотр раз в квартал даёт больше безопасности, чем любая новая система защиты.
Материал обновлён 3 сентября 2026