Модели управления доступом

Дискреционная модель управления доступом (DAC)

Дискреционная модель позволяет владельцу ресурса самостоятельно решать, кто получит доступ к его файлам и данным. Если вы создали документ на Windows, именно вы контролируете, кому разрешить доступ к чтению и копированию. Владелец назначает разрешения прямо через меню «Безопасность» — выбираете пользователя, ставите галочку Read или Write. Решение об управлении доступом принимает сам владелец, а не администратор.

На практике DAC реализуется через список управления доступом (ACL). Каждый файл хранит список пользователей и их прав — [Иван: Read], [Мария: Read+Write]. Просто, понятно, работает для малой команды из 30–50 сотрудников. Новому сотруднику разделили документ через систему управления доступом — и он уже читает отчет.

Преимущество дискреционной модели управления доступом в низкой сложности администрирования на старте. Не нужен администратор безопасности для настройки доступа к каждому файлу. Минус становится очевидным при разрастании компании. Каждый владелец ресурса принимает свои решения: один разделит документ с коллегой, другой забудет убрать разрешения уволенного сотрудника, третий не знает, что документ открыт. В организации из 500 человек матрицы доступа становятся хаотичными. Аудит невозможен, риски несанкционированного доступа растут. Защита информации здесь зависит от дисциплины каждого.

Дискреционная модель DAC применяется в файловых системах Windows (NTFS), Unix/Linux и облачных сервисах. Использование DAC без контроля назначенных прав может повысить риск утечки финансовых данных.

Мандатная модель управления доступом (MAC)

Мандатная модель работает ровно противоположно. Администратор централизованно устанавливает уровни защиты для информации и уровни допуска для пользователей. Документ помечается «Конфиденциально», сотрудник получает допуск «Уровень 2». Если уровень допуска равен или выше уровня защиты документа — доступ разрешен. Если ниже — система запирает дверь без компромиссов.

Правила мандатной модели не зависят от владельца и не меняются пользователями. Любой владелец не может сказать «хочу дать доступ другу». Правила управления доступом установил администратор — все подчиняются. На этапе проектирования требуется серьезная подготовка: описать классификацию всех данных организации, определить уровни защиты, назначить каждому пользователю уровень допуска с обоснованием.

MAC используется в государственных системах, банках и оборонных компаниях. Пример: военные ведомства классифицируют документы как «Открыто», «Конфиденциально», «Совершенно секретно». Сотрудник с допуском «Конфиденциально» не прочитает документ уровня «Совершенно секретно» — даже если администратор попробует разрешить доступ, система заблокирует его на уровне ядра. Контроль доступа здесь полностью централизованный, что усложняет управление системой, но гарантирует защиту информации. На практике мандатная модель требует постоянного аудита разрешений и соответствия требованиям безопасности.

Ролевая модель управления доступом (RBAC)

Ролевая модель — самая популярная в корпоративном мире. Вместо назначения разрешений каждому пользователю вы создаете роли: «Бухгалтер», «Менеджер продаж», «IT-администратор». Каждой роли назначают набор прав доступа к объектам: файлам, приложениям, базам данных, сетевым ресурсам.

Как это работает? Компания создает учетные записи пользователей и группы безопасности — по одной на каждую роль. Группе «BuhgalterGroup» дают разрешения на папку «Бухгалтерия», на приложение «1С», на базу финансовых записей. Когда приходит новый бухгалтер, администратор добавляет пользователя в группу — и все разрешения применяются автоматически.

В Active Directory процесс конкретный: открываешь «Active Directory Users and Computers», находишь группу, добавляешь пользователя. Все назначения прав, предусмотренные этой ролью, срабатывают сразу. RBAC масштабируется до 1000–2000 сотрудников и 50–100 ролей без потери контроля доступа. Гибче, чем DAC, но проще, чем MAC. Бизнес легко понимает концепцию: «создайте роль менеджера с такими-то разрешениями».

Ролевая модель управления доступом широко применяется в корпоративных системах. Почему? Работает, просто объяснить заинтересованным лицам, требует разумных затрат на администрирование. Но если структура компании часто меняется либо ролей становится 150+, управление разрешениями затрудняется. Права начинают пересекаться, появляются избыточные разрешения, аудит усложняется.

Атрибутная модель управления доступом (ABAC)

Атрибутная модель — самая гибкая. Вместо ролей используются атрибуты (свойства, параметры). Атрибуты субъектов (пользователей и процессов): должность, отдел, уровень допуска, IP-адрес в сети, время дня, тип устройства. Атрибуты объектов (ресурсов): классификация документа, его владелец, тип информации, уровень критичности.

ABAC работает на правилах с условиями. Пример: «Менеджер продаж отдела Москва может читать таблицу 'Сделки' с 9:00 до 17:00, только с внутреннего IP, только с корпоративного устройства». Один набор правил покрывает целый класс пользователей и сценариев. Новый менеджер не требует отдельной настройки — его атрибуты автоматически подходят под существующие разрешения.

Облачные платформы (AWS, Azure, Google Cloud) применяют ABAC как основную архитектуру управления доступом. Это позволяет масштабировать разрешения к тысячам объектов без ручного перечисления каждого разрешения. На практике ABAC требует тщательного планирования атрибутов на этапе проектирования. Если политики часто меняются, правила становятся запутанными — управлять системой сложнее. Но в стабильных окружениях атрибутная модель разграничения доступа обеспечивает максимум гибкости и защиты информации одновременно.

Компоненты управления доступом

Все четыре модели включают одинаковые базовые компоненты разграничения доступа:

Субъекты — источники запросов доступа: пользователи с учетными записями, процессы и приложения, компьютеры в сети. Субъект отправляет запрос доступа к ресурсу.

Объекты — ресурсы, к которым требуется контроль доступа: файлы и папки, приложения, базы данных, принтеры, веб-сервисы. Каждый объект охраняется механизмом разработки разрешений.

Права доступа — действия, которые может совершить субъект: Read (чтение), Write (запись), Delete (удаление), Execute (выполнение), Modify (изменение). Специальные разрешения включают Change Owner и Change Permissions.

Механизмы проверки — компоненты системы, которые решают: разрешить или запретить доступ. Они проверяют матрицы разрешений, политики и выносят решение в миллисекундах.

Выбор модели для разных организаций

Выбор модели управления доступом зависит от размера компании, требований к защите информации и сложности инфраструктуры бизнеса.

До 100 сотрудников: используйте RBAC с простой структурой ролей (10–15). DAC может работать в микростартапах (5–20 человек), но растет неуправляемо быстро. На практике даже малые компании выигрывают от ролевой модели разграничения доступа.

500–2000 сотрудников: нужна полноценная RBAC с хорошо определенной иерархией ролей и регулярным аудитом назначения. На критичных участках (финансы, персональные данные сотрудников и клиентов) добавляйте элементы MAC или дополнительные правила ABAC.

5000+ сотрудников: комбинируйте RBAC (основа управления) + ABAC (чувствительные системы) + элементы MAC (государственные требования). На этом масштабе без архитектуры управления доступом не обойтись.

На практике чистая модель встречается редко. В большинстве корпоративных систем используется комбинация управления доступом. Стандартный подход: основной контроль через RBAC (проверено, работает), дополнительные правила ABAC для чувствительных участков, небольшие элементы DAC, где это уместно (когда сотрудники делятся документами внутри отдела).

Junior-специалист начинает с RBAC в Active Directory. Mid-level архитектор выбирает между RBAC и RBAC+ABAC. Senior выстраивает архитектуру управления доступом, которая эффективна на 5+ лет. Главное в выборе — балансировать между защитой информации, простотой администрирования и гибкостью бизнеса для того, чтобы система управления доступом работала как для компании, так и для IT-команды.