#РазборКейса
Админки раздали, а отозвать забыли...
КАК ЭТО ПРЕВРАЩАЕТСЯ В ИНЦИДЕНТ 🚨
Такие истории почти всегда начинаются более менее спокойно: сотруднику выдали расширенные права на время, подрядчику открыли доступ к админке для настройки, разработчику дали роль администратора, чтобы быстрее исправить проблему.
Работу сделали, а доступ остался. Через месяц уже никто не помнит, зачем он был нужен.
Проблема не в самой выдаче админских прав, а в том, что у компании нет управляемого жизненного цикла доступа:
⏩кто запросил
⏩кто согласовал
⏩на какой срок выдали
⏩что именно разрешили
⏩кто проверил отзыв прав
В итоге временный доступ становится постоянным, а исключение — нормой.
Лишние права могут сработать после увольнения сотрудника, при компрометации пароля, конфликте с подрядчиком или просто при ошибке. Чем шире права, тем меньше действий нужно для ущерба: выгрузить базу, изменить настройки, отключить логирование, удалить записи, создать новую учетную запись, открыть доступ наружу.
Отдельный риск — общие админские учетные записи. Когда несколько человек работают под одним логином, расследование почти сразу упирается в пустоту. В журнале видно только admin. Кто именно, с какого рабочего места, по какой заявке и с каким основанием — уже вопрос к процессу, а не к средствам защиты. Если ответов нет, компания теряет управляемость в первые часы разбора.
💬 Правильное закрытие начинается не с покупки новой системы, а с инвентаризации привилегированных доступов.
Нужно отдельно поднять администраторов домена, админов бизнес-систем, владельцев облачных кабинетов, доступы подрядчиков, сервисные учетные записи, роли в CRM, HRM, DLP, MDM, Git, BI и хранилищах данных. Именно здесь обычно всплывают бывшие сотрудники, старые подрядчики, тестовые пользователи и «временные» роли двухлетней давности.
Дальше доступы нужно привести к понятной модели. У каждого привилегированного доступа должны быть владелец, основание, срок действия, зона ответственности и журнал действий. Постоянные админские права стоит оставлять только тем, кому они действительно нужны. Все остальное через временное повышение прав, заявку, согласование и автоматический отзыв.
Для подрядчиков правило еще жестче: доступ выдается под конкретную задачу, на ограниченный срок, с MFA и журналированием действий. После завершения работ отзыв доступа должен быть таким же обязательным шагом, как подписание акта. Иначе договор закончился, а техническая возможность влиять на систему осталась.
Быстрая проверка процесса: можно ли за 15 минут ответить, кто имеет административные права в критичных системах, почему они выданы и когда последний раз пересматривались. Если нельзя, то это открытый контур риска.
📎 По требованиям 152-ФЗ и подзаконных актов оператор должен принимать меры по предотвращению несанкционированного доступа к персональным данным.
В технической плоскости это упирается в управление доступом, разграничение прав, учет действий пользователей и контроль администраторов. Без этого документы по ИБ живут отдельно, а реальная безопасность отдельно.
Вывод следующий: лишние админские права редко выглядят как инцидент до момента, пока ими не воспользуются. Но после этого вопрос будет уже не в том, почему доступ когда-то выдали, а в том, почему его не отозвали, не контролировали и не видели в перечне критических рисков.
Если у вас похожая ситуация и нужно быстро привести привилегированные доступы в управляемый вид, мы можем помочь с аудитом, инвентаризацией и настройкой рабочего процесса выдачи и отзыва прав 👍
😎
