Управление матрицей доступа
Матрица доступа — основа информационной безопасности организации и ключевой инструмент системы управления доступом. Через матрицу доступа учётные записи каждого сотрудника связаны с набором ролей и прав доступа в информационной системе компании. Правильное управление доступом в корпоративных системах предотвращает утечку персональных данных и обеспечивает соответствие требованиям законодательства при обработке персональных данных. Типичный сценарий: разработчик получил избыточные права доступа к базе данных и скопировал персональные данные клиентов. Система управления матрицей доступа должна контролировать каждую учетную запись, назначение прав и разграничение доступа между подразделениями организации. Это критично для обеспечения информационной безопасности и достижения высокого уровня защищенности. Модель управления доступом, основанная на разделении обязанностей, снижает риски и обеспечивает эффективный контроль доступа над объектами доступа.
Современная матрица доступа строится на трех взаимосвязанных элементах: на субъектах (кто запрашивает доступ), объектах доступа (какие ресурсы защищаются) и правах доступа (какие действия разрешены). Это не просто абстрактная модель доступа — это практическая архитектура, которая определяет информационную безопасность в соответствии с требованиями законодательства каждой организации и становится основой внутреннего контроля защиты информации.
Компоненты матрицы: субъекты, объекты, права
Субъектами в контексте управления доступом выступают учетные записи пользователей, сервис-аккаунты приложений и технические средства для систем корпоративных сетей. Каждая учетная запись — это точка входа в информационные ресурсы организации. Объектами доступа служат базы данных, серверы, файлы, приложения и другие компоненты информационной системы. Права доступа — это набор разрешенных действий: чтение данных, запись, выполнение процессов, администрирование и другие операции.
Представьте матрицу как таблицу в элементарном виде: строки — это субъекты (каждая учётная запись пользователя), столбцы — объекты доступа (активы компании), ячейки содержат права доступа, определяющие взаимодействие субъектов с объектами доступа. Разработчик John_Dev получает доступ к определенной роли с учетной записью. Его объекты доступа включают базу данных Production, репозиторий кода и рабочую станцию. В матрице доступа указано: может читать данные из базы (например, чтение), может писать в develop-ветку репозитория, может выполнять развертывание, но не имеет административного доступа.
Основные модели управления доступом
Ролевая модель управления (RBAC) — распространённый подход к управлению доступом и учётными записями в организации. В RBAC права доступа не выдаются напрямую каждому пользователю. Вместо этого создаются роли, которые группируют права в соответствии с функциями и должностями сотрудников. Назначение прав в системе происходит в зависимости от определенной роли и направления каждого сотрудника. Младший разработчик получает роль «Developer_Junior», которая содержит набор прав: чтение кода, создание ветвей, отправка коммитов. Старший разработчик получает несколько ролей, например «Developer_Senior», с расширенными правами, включая администрирование конфигурации с минимально необходимыми правами для выполнения служебных рабочих задач.
Дискреционный контроль доступа (DAC — discretionary access control) представляет альтернативную модель управления доступом, где владелец каждого ресурса сам решает, кому предоставить доступ к своим объектам. Владелец папки документов может выбрать, какие группы пользователей получат доступ к информации и право на запись. DAC более гибкий, но создает проблемы с согласованностью управления доступом. Каждый владелец принимает собственные решения, что приводит к несогласованности с политикой обработки персональных данных.
Обе модели управления должны соблюдать фундаментальный принцип информационной безопасности — принцип наименьших привилегий. Каждой учетной записи должен быть предоставлен только минимум необходимых прав для выполнения служебных рабочих задач. Если разработчику требуется получить доступ к информации и читать данные из базы данных, он получает только право на чтение — не административный доступ, не удаление, не управление пользователями. Это ограничение доступа сокращает число лишних прав и ограничивает масштаб потенциального вреда, если учетная запись будет скомпрометирована.
Риски неправильного управления доступом
Over-provisioning происходит, когда сотрудник получает лишние права к большему числу систем, чем требует его работа. Бухгалтер может получить доступ к системе управления проектами, репозиториям кода и панели администратора просто потому, что при создании учётной записи не было правильного планирования назначения прав и разграничения доступа. Каждая учетная запись с избыточными правами увеличивает окно для внутренних угроз. Даже честный сотрудник может случайно нарушить целостность активов компании, которыми управлять не должен.
Orphaned accounts — это учетные записи, от которых не отозваны права доступа при увольнении или смене должности сотрудника. Автоматизация процесса отзыва прав важна: при окончании трудовых отношений система сразу должна осуществить отзыв больше не нужных прав ко всем объектам в матрице доступа и передачу данных по регламенту.
Нарушение разделения обязанностей — когда один человек может одновременно одобрить операцию и выполнить её. Сотрудник учета создает счет-фактуру и авторизует платеж. Матрица доступа должна разделить эти роли в соответствии с требованиями законодательства: один утверждает, другой выполняет действие и фиксирует инциденты ИБ.
Требования комплаенса и регулирование
Управление доступом становится еще более строгим под влиянием регулятивных требований. GDPR и российский ФЗ-152 требуют контроля доступа к персональным данным: организация должна задокументировать, кто может получить доступ к информации, проводить регулярные проверки фактических прав пользователей и вести журналы событий. SOX требует наличия контроля доступа для финансовых данных и систем. ISO 27001 требует, чтобы управление доступом и управление учетными записями были включены в политику обработки персональных данных и защиты информации.
При проведении аудитов организации должны продемонстрировать, что матрица доступа задокументирована, что разрешения и права в системе назначаются в соответствии с утверждённой политикой обработки персональных данных, что регулярные проверки фактических прав пользователей проводятся, и что любое изменение доступа к информационным ресурсам зафиксировано с указанием даты и причины. Когда сотрудник переходит из должности разработчика в должность менеджера, его старые права должны быть отозваны, новые предоставлены согласно определенной роли, и это должно быть записано в системе управления доступом для реагирования на инциденты.