Техподдержке нужен не «админ на всякий случай», а заранее описанный набор действий для конкретной задачи. Безопасная модель отвечает на пять вопросов: кто подключается, к какому ресурсу, что может сделать, на какой срок и где останется запись. Постоянные широкие права заменяют ролями, временным повышением привилегий и контролируемыми сессиями. Начните с задач, а не должностей Соберите типовые операции: посмотреть состояние сервиса, прочитать диагностические журналы, перезапустить компонент, изменить настройку, восстановить данные. Для каждой укажите объект, среду и последствия ошибки. Разделите права на уровни: просмотр; стандартное исправление; изменение конфигурации; критическая операция. Базовая роль должна содержать минимум, необходимый ежедневно. Опасные действия выдаются отдельно. Формулировка «доступ ко всему контуру» означает, что границы роли ещё не определены. Постройте матрицу доступа Для каждой роли зафиксируйте: • ресурсы и среды: тестовую, промышленную, резервную; • разрешённые операции и категории данных; • способ подключения и требования к устройству; • необходимость согласования и максимальный срок; • владельца, подтверждающего право. Запретите доступ по умолчанию. Чтение отделите от изменения, поддержку приложения — от управления платформой, работу с заявками — от управления учётными записями. Для промышленной среды и персональных данных создайте более узкие роли. Выдавайте привилегии по запросу Повышенный доступ включается только под зарегистрированную заявку: с причиной, целевым ресурсом, ролью и сроком. После завершения работ право отзывается автоматически. Это JIT-подход: доступ появляется непосредственно перед задачей и не остаётся постоянной возможностью для атаки. Для чувствительных операций добавьте подтверждение владельца сервиса или второго специалиста. Требуйте MFA, управляемое устройство и утверждённый шлюз либо PAM-систему. Общие учётные записи исключите: каждое действие должно однозначно связываться с человеком. Контролируйте сессию и результат Журналируйте вход, выдачу роли, административные действия, изменение объектов и завершение сессии. Для критичных систем полезна запись привилегированной сессии; срок её хранения и круг допущенных к просмотру тоже должны быть ограничены. В закрытой заявке укажите результат и перечень изменений. Настройте оповещения о работе вне согласованного окна, массовом чтении, попытках расширить роль и действиях без заявки. Регулярно сверяйте права с обязанностями; при смене роли или увольнении отзывайте их автоматически. Закон и аварийный доступ Если поддержка получает доступ к персональным данным, действует 19 Федерального закона № 152-ФЗ: оператор обязан принимать правовые, организационные и технические меры для защиты данных. Практический вывод — ограничивать круг допущенных лиц, фиксировать действия и не открывать сведения, которые не нужны для устранения сбоя. Для аварии создайте отдельный break-glass-доступ: индивидуальную защищённую учётную запись, сильную аутентификацию, немедленное уведомление ответственных, короткий срок и обязательный разбор после использования. Аварийный путь не должен становиться повседневным. Проверьте модель на реальной заявке Пройдите весь маршрут: запрос, согласование, MFA, подключение, выполнение операции, аудит и автоматический отзыв. Затем испытайте запреты: роль не видит соседний сервис, не меняет чужие права, не работает после срока и не подключается в обход контролируемого канала. Хороший показатель — доля задач, выполненных минимальным набором разрешений без постоянных привилегий и ручных исключений. Что почитать и попробовать • CIS Control 6: Access Control Management Практический ориентир для инвентаризации, выдачи, пересмотра и отзыва прав, а также применения MFA. • Microsoft Privileged Access Strategy Помогает выстроить разрешённые пути повышения прав, временный доступ и защиту привилегированных операций. Я в соцсетях TG TikTok Сетка Пикабу MAX