Модели авторизации: RBAC, MAC и DAC
Сравните ролевую, мандатную и дискреционную модели управления доступом и узнайте, когда каждая из них подходит для корпоративных и государственных систем.
«Модели авторизации: RBAC, MAC и DAC» — бесплатный урок Cloud & IT Cert Prep на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cloud & IT Cert Prep, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Обзор моделей управления доступом
Модели управления доступом определяют правила и политики, регулирующие, какие субъекты (пользователи, процессы) могут получать доступ к каким объектам (файлам, системам, данным). Выбранная модель определяет, кто может предоставлять доступ, как назначаются разрешения и как обеспечивается их соблюдение. Экзамен Security+ охватывает четыре основные модели: дискреционное управление доступом (DAC), мандатное управление доступом (MAC), управление доступом на основе ролей (RBAC) и управление доступом на основе правил. Для проектирования эффективных систем авторизации необходимо понимать особенности каждой модели и подходящие случаи её применения.
Дискреционное управление доступом (DAC)
В модели дискреционного управления доступом (DAC) владелец ресурса сам решает, кто может получать доступ к его ресурсам, и может предоставлять или отзывать доступ у других пользователей. «Дискреционный» означает, что решения принимают владельцы: система обеспечивает выполнение этих решений, но не диктует их. Эта модель используется в большинстве персональных компьютерных сред (разрешения на файлы Windows NTFS, разрешения на файлы Linux/Unix). Ограничение безопасности DAC заключается в том, что каждый владелец ресурса должен принимать правильные решения о доступе: пользователь, получивший доступ к файлу, может предоставить его другим без участия администратора, что потенциально позволяет распространить конфиденциальные данные за пределы предполагаемой аудитории.
# DAC example: Linux file permissions (owner controls access)
# Create a file and check default permissions
touch confidential_data.txt
ls -la confidential_data.txt
# -rw-rw-r-- 1 alice users (owner=alice, can read/write; group can read/write; others read)
# Owner (Alice) discretionarily removes all access for others
chmod 600 confidential_data.txt
# -rw------- 1 alice users (only Alice can read/write)
# Alice grants read to a specific user via ACL
setfacl -m u:bob:r confidential_data.txtРиски DAC: проблема запутавшегося заместителя
DAC несёт два inherentных риска для безопасности. Транзитивный доступ: пользователь A предоставляет доступ пользователю B, пользователь B предоставляет доступ пользователю C — исходный владелец может даже не знать, что C получил доступ к его ресурсу. Проблема запутавшегося заместителя: привилегированная программа, действующая от имени пользователя с меньшими привилегиями, может непреднамеренно использовать свои привилегии способом, недоступным этому пользователю напрямую. В средах DAC одна скомпрометированная учётная запись потенциально открывает доступ ко всем ресурсам, к которым был допущен этот пользователь; кроме того, до обнаружения компрометации она может предоставить доступ другим лицам. DAC удобна, но создаёт сложности для строгого ограничения распространения информации.
Мандатное управление доступом (MAC)
В модели мандатного управления доступом (MAC) операционная система обеспечивает соблюдение политик доступа на основе меток безопасности, назначенных как субъектам (пользователям), так и объектам (данным). Пользователи не могут переопределять или изменять эти политики — изменить их может только системный администратор или политика безопасности. MAC используется в государственных и военных средах с секретной информацией, где данные необходимо строго разделять по категориям. Пользователь с допуском «Секретно» не может получить доступ к данным с меткой «Совершенно секретно», даже если владелец данных хотел бы предоставить ему такой доступ. Модели Белла—ЛаПадулы (запрещено чтение вверх, запрещена запись вниз) и Биба (запрещена запись вверх, запрещено чтение вниз) являются формальными реализациями MAC.
# SELinux is a MAC implementation for Linux
# Check SELinux mode and policy
getenforce # Enforcing / Permissive / Disabled
sestatus # Detailed SELinux status
# View SELinux security context labels on files
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd
# Security context: user:role:type:level
# A process can only access files where its type has explicit permission
sudo ausearch -m avc -ts recent # View MAC policy denialsМодели MAC Белла—ЛаПадулы и Биба
Две формальные модели MAC выражают цели безопасности в виде математических правил. LaPadula Белла—ЛаПадулы focuses на конфиденциальности: субъекты не могут читать данные выше своего уровня классификации (запрещено чтение вверх) и не могут записывать данные на более низкий уровень классификации (запрещена запись вниз). Это предотвращает попадание конфиденциальной информации к неавторизованным пользователям. Biba focuses на целостности: субъекты не могут записывать данные на более высокий уровень целостности (запрещена запись вверх) и не могут читать данные с более низкого уровня целостности (запрещено чтение вниз). Biba предотвращает загрязнение данных с высокой целостностью входными данными с низкой целостностью. Реальные системы MAC (например, SELinux) объединяют элементы обеих моделей.
Управление доступом на основе ролей (RBAC)
Управление доступом на основе ролей (RBAC) назначает разрешения ролям, а не отдельным пользователям напрямую, а затем назначает пользователей этим ролям. Это решает проблему управления индивидуальными разрешениями в больших масштабах. Распространённые роли в корпоративных средах: администратор, аудитор, разработчик, менеджер_по_персоналу, финансовый_аналитик. Когда новый сотрудник приступает к работе, его добавляют в подходящую роль, и он сразу получает все необходимые этой роли разрешения. При переходе сотрудника на другую должность его роль меняется, а разрешения корректируются автоматически. RBAC — преобладающая модель в корпоративных системах IAM.
# RBAC example (database permissions)
# Create roles and assign permissions
CREATE ROLE readonly_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_analyst;
CREATE ROLE data_engineer;
GRANT SELECT, INSERT, UPDATE ON customer_data TO data_engineer;
# Assign users to roles
GRANT readonly_analyst TO alice;
GRANT data_engineer TO bob;
# When Alice is promoted: revoke old role, grant new one
REVOKE readonly_analyst FROM alice;
GRANT data_engineer TO alice;Преимущества RBAC: масштабируемость и разделение обязанностей
Главное преимущество RBAC — масштабируемость администрирования. Изменение разрешений роли мгновенно затрагивает всех пользователей этой роли — не нужно обновлять записи отдельных пользователей в сотнях систем. RBAC естественным образом поддерживает разделение обязанностей, не позволяя одной роли иметь конфликтующие разрешения (например, разрешение одновременно создавать и утверждать финансовые операции). RBAC также упрощает соблюдение требований: аудиторы могут проверять роли и их разрешения, а не проводить аудит тысяч отдельных назначений пользователей. Ограничение — разрастание ролей: организации иногда создают слишком много узких ролей, что усложняет управление и сводит на нет преимущество масштабируемости.
Управление доступом на основе правил
Управление доступом на основе правил (не следует путать с RBAC) предоставляет или запрещает доступ на основе набора условных правил, а не только идентичности или роли. Классический пример — правила межсетевого экрана: «Allow TCP from 192.168.1.0/24 to any on port 443. Deny all other traffic». Доступ проверяется по правилам по порядку, пока не будет найдено совпадение. Управление на основе правил часто сочетается с другими моделями: MAC использует метки безопасности как правила, а управление доступом на основе атрибутов (ABAC) расширяет логику правил, одновременно оценивая несколько атрибутов (подразделение пользователя, тип устройства, время суток, классификация ресурса) для принятия детализированных решений.
# Rule-based access control: iptables firewall rules
# Rules are evaluated in order; first match wins
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow specific source IP to SSH
iptables -A INPUT -s 10.0.0.100 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Default deny all other inbound
iptables -A INPUT -j DROPУправление доступом на основе атрибутов (ABAC)
ABAC (управление доступом на основе атрибутов) — наиболее гибкая и детализированная модель управления доступом. При принятии решений о доступе одновременно оцениваются несколько атрибутов: атрибуты субъекта (подразделение пользователя, уровень допуска, местоположение), атрибуты объекта (классификация данных, подразделение владельца, метка хранения), атрибуты среды (время суток, тип устройства, расположение сети) и атрибуты действия (чтение, запись, удаление). Политика может выглядеть так: «Allow access if user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18». ABAC позволяет принимать решения в рамках политики нулевого доверия и реализуется такими продуктами, как XACML, и облачными механизмами политик IAM.
Выбор подходящей модели
Подходящая модель управления доступом зависит от требований безопасности и организационного контекста. DAC: подходит для персональных компьютеров и небольших команд, где удобство важнее строгого контроля. MAC: необходима в государственных и военных средах с секретной информацией, требующих строгого разделения данных по категориям. RBAC: идеальна для организаций, где критически важна масштабируемость администрирования и роли чётко соответствуют должностным обязанностям. ABAC: подходит для облачных сред и архитектур нулевого доверия, где нужны контекстно-зависимые детализированные политики. На практике большинство организаций использует сочетание моделей: RBAC как основу и ABAC для контекстно-зависимых решений о доступе.
Списки контроля доступа (ACL)
Независимо от модели управления доступом, списки контроля доступа (ACL) являются самым распространённым механизмом технической реализации. ACL, связанный с ресурсом, указывает, какие субъекты могут выполнять какие действия. ACL файловой системы (Windows NTFS, Linux POSIX ACL) управляют доступом к файлам и каталогам. Сетевые ACL управляют потоком трафика на уровне маршрутизатора или облачной сети. ACL базы данных управляют доступом на уровне таблиц и строк. ACL могут реализовать любую из рассмотренных моделей: ACL файла реализует DAC, когда им управляет владелец; ACL системы безопасности реализует MAC, когда записи определяются метками; ACL приложения реализует RBAC, когда в записях указаны роли.
# Windows NTFS ACL example using icacls
# View current ACL on a folder
icacls 'C:\Sensitive\HR_Data'
# BUILTIN\Administrators:(OI)(CI)(F) <- Full control
# CONTOSO\HR_Team:(OI)(CI)(RX) <- Read and Execute
# Grant specific permissions to HR Managers group
icacls 'C:\Sensitive\HR_Data' /grant 'CONTOSO\HR_Managers:(OI)(CI)(M)'
# (OI)=Object Inherit, (CI)=Container Inherit, (M)=Modify
# Remove access for a former contractor
icacls 'C:\Sensitive\HR_Data' /remove 'CONTOSO\contractors'Быстрая проверка
Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.
Итоги урока
В этом уроке Вы узнали, что DAC позволяет владельцам ресурсов управлять доступом (это гибко, но рискованно); MAC использует принудительно применяемые системой метки безопасности (модель строгая и применяется в средах с секретной информацией); RBAC назначает разрешения ролям, обеспечивая масштабируемость в крупных организациях; а ABAC оценивает множество атрибутов для детализированных решений в рамках модели нулевого доверия. Далее мы рассмотрим федеративную идентификацию: SAML, OAuth и OpenID Connect.
Часто задаваемые вопросы
Урок «Модели авторизации: RBAC, MAC и DAC» бесплатный?
Да — полный текст урока «Модели авторизации: RBAC, MAC и DAC» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cloud & IT Cert Prep, подпишись на CoddyKit PRO. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Чему я научусь в уроке «Модели авторизации: RBAC, MAC и DAC»?
Сравните ролевую, мандатную и дискреционную модели управления доступом и узнайте, когда каждая из них подходит для корпоративных и государственных систем. Ты практикуешь Cloud & IT Cert Prep с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Cloud & IT Cert Prep?
Предыдущий опыт не требуется. Cloud & IT Cert Prep на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.
Сколько времени занимает урок «Модели авторизации: RBAC, MAC и DAC»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Cloud & IT Cert Prep?
Да. Каждый урок Cloud & IT Cert Prep включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Политики паролей и многофакторная аутентификация
- Биометрия и аутентификация по токенам
- Модели авторизации: RBAC, MAC и DAC
- Федеративная идентификация: SAML, OAuth и OpenID Connect