Управление доступом в организации

Управление правами доступа в организации

Когда сотрудникам для работы нужны корпоративная почта, CRM, репозитории и облачные хранилища, права доступа легко начинают выдавать по запросу. Со временем у людей накапливаются разрешения, которыми они уже не пользуются, а у бывших участников проекта могут оставаться активные аккаунты.

Если такую учётную запись взломают или сотрудник случайно изменит важные данные, избыточные права увеличат возможный ущерб. Поэтому доступом нужно управлять на протяжении всей работы сотрудника с системой.

Сначала определите, кому и что нужно делать

В доступе есть два разных вопроса. Аутентификация подтверждает, кто вошёл в систему. Авторизация определяет, какие действия этому пользователю разрешены.

Например, сотруднику может требоваться просмотр карточек клиентов, а изменение финансовых данных — только отдельной группе. Такие границы важно определить до настройки конкретных систем.

Объединяйте права в роли

Если выдавать разрешения отдельно каждому сотруднику, со временем становится трудно понять, у кого и почему есть доступ. Ролевая модель упрощает управление. Права объединяются по рабочим функциям, а сотрудникам назначаются подходящие роли.

Например, редактор может создавать и изменять материалы, а руководитель редакции — также публиковать их. В модели RBAC разрешения назначаются ролям, а пользователи получают доступ через эти роли. NIST описывает RBAC как управление доступом на основе ролей и связанных с ними привилегий.

Выдавайте минимум, расширяйте по обоснованию

Мой принцип — сотрудник с самого начала получает только права, необходимые для его текущей работы. Если ему нужен доступ выше базового уровня, запрос должен объяснять, для какой задачи он нужен, к каким данным и системам открывает доступ и на какой срок.

Формулировки «может пригодиться» недостаточно. Расширение прав стоит согласовать с ответственным за систему или руководителем задачи и ограничить нужными ресурсами. Когда задача завершена, дополнительный доступ убирается.

В веб-приложении каждое защищённое действие должно проверяться на сервере. Скрытая кнопка в интерфейсе не ограничивает доступ сама по себе. Если правило для нового действия ещё не настроено, безопаснее отказать в доступе по умолчанию. Эти подходы рекомендует OWASP Authorization Cheat Sheet.

Отзывайте доступ сразу после завершения работы

Если сотрудник закончил работу над проектом и больше не будет в нём участвовать, его доступ к проектным системам нужно отозвать сразу. Не стоит ждать планового пересмотра прав. Это касается репозитория, облачной среды, документов и других ресурсов проекта.

При переходе сотрудника в другую команду старые разрешения нужно пересмотреть вместе с его новыми обязанностями. Если человек уходит из организации, его учётную запись и доступ к корпоративным системам нужно отключить сразу. Такой порядок соответствует жизненному циклу управления аккаунтами, описанному в NIST SP 800-53, контроле AC-2.

Отделяйте повседневную работу от администрирования

Для обычных задач сотруднику не нужны права администратора. Повышенные привилегии стоит использовать только для действий, которым они действительно необходимы. Для административных и удалённых аккаунтов следует включить многофакторную аутентификацию. CISA также рекомендует разделять обычные и привилегированные аккаунты и регулярно проверять, нужны ли выданные разрешения. Рекомендации CISA для организаций.

У каждого сотрудника должна быть собственная учётная запись. Общие логины затрудняют понимание того, кто выполнил действие, и мешают разбирать ошибки.

Разделяйте ответственность за важные действия

Некоторые операции требуют дополнительной проверки. Например, рискованно, когда один аккаунт может подготовить и самостоятельно подтвердить платёж.

Разделение таких действий между сотрудниками помогает снизить риск ошибок и злоупотреблений. Для каждого важного процесса стоит определить, кто выполняет действие и кто его подтверждает.

Закрепите ответственность за доступ

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

Затем проверьте, у кого есть административные права, остались ли активными аккаунты бывших участников проектов и что происходит с доступом при смене задач или увольнении сотрудника.

Доступ должен соответствовать текущей работе человека. Когда работа заканчивается, заканчивается и необходимость в выданных для неё правах.