RBAC

RBAC, или Role-Based Access Control, — модель управления доступом, в которой Permissions назначаются не отдельным пользователям напрямую, а Roles, соответствующим их функциям в организации или системе.

Пользователь получает одну или несколько ролей, а вместе с ними — заранее определенный набор прав. Например, Role «Бухгалтер» может разрешать просмотр и создание документов, а Role «Главный бухгалтер» дополнительно — утверждение отдельных операций и доступ к отчетности.

RBAC широко используется в корпоративных приложениях, IAM, базах данных, облачных платформах, операционных системах, Kubernetes, ERP, CRM и других системах, где необходимо управлять доступом большого количества пользователей.

Главная идея RBAC — назначать права в соответствии с рабочей функцией пользователя, а не настраивать каждое разрешение вручную для каждого сотрудника.

Что такое RBAC простыми словами

Без RBAC администратор может выдавать Permissions каждому человеку отдельно:

Ivan → read invoices, create invoices
Anna → read invoices, create invoices
Olga → read invoices, create invoices

При большом количестве сотрудников такой подход быстро становится неудобным.

RBAC добавляет промежуточный уровень:

Ivan → Accountant
Anna → Accountant
Olga → Accountant

Accountant → read invoices, create invoices

Теперь изменение Permissions для Role автоматически влияет на всех пользователей, которым она назначена.

Расшифровка RBAC

RBAC расшифровывается как Role-Based Access Control — управление доступом на основе ролей.

Role в данном контексте представляет набор Permissions, соответствующий определенной должности, функции или технической ответственности.

Основные элементы RBAC

Типичная модель включает:

• User;
• Role;
• Permission;
• Resource;
• Session.

User

User — человек или технический субъект, которому необходимо работать с системой.

Например:

user: ivan.petrov

Role

Role объединяет набор разрешений.

Например:

role: accountant

Permission

Permission определяет разрешенное действие над Resource.

Например:

invoice.read
invoice.create
invoice.export

Resource

Resource — объект, к которому применяется контроль доступа.

Это может быть:

• Document;
• Database;
• Server;
• API;
• Cloud Resource;
• Application Function.

Как работает RBAC

Базовую модель можно представить так:

User
↓ assigned to
Role
↓ contains
Permissions
↓ applied to
Resources

При запросе система проверяет, имеет ли хотя бы одна активная Role пользователя необходимое Permission.

Пример RBAC

В CRM существуют три Roles:

Сотруднику назначается Role, соответствующая его обязанностям.

Почему RBAC удобнее прямой выдачи прав

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

RBAC создает понятную связь:

Job function → Role → Permissions

Это упрощает аудит и изменение доступа.

RBAC и принцип Least Privilege

Least Privilege означает предоставление минимально необходимого набора прав.

Хорошо спроектированная Role должна включать только Permissions, необходимые для выполнения определенной функции.

Например, бухгалтеру для работы с приложением не требуется Administrator Access к операционной системе.

Избыточные роли

Если Role содержит слишком много Permissions, она нарушает Least Privilege.

Проблема особенно опасна для Roles вроде:

SuperUser
GlobalAdmin
FullAccess

Такие Roles следует назначать только при реальной необходимости.

RBAC и IAM

RBAC является одной из наиболее распространенных моделей Authorization внутри IAM.

IAM управляет Identities и жизненным циклом Accounts, а RBAC помогает определить, какие Permissions получает конкретная Identity.

Authentication и RBAC

Authentication подтверждает, кто пользователь.

RBAC применяется после этого и отвечает на вопрос, что ему разрешено.

Authentication → Who are you?
RBAC → What can you do?

RBAC и Authorization

RBAC — один из способов реализации Authorization.

Существуют и другие модели, например ABAC и Policy-Based Access Control.

RBAC и ABAC

ABAC принимает решения на основании Attributes, а RBAC — на основании Roles.

Пример ABAC вместо RBAC

RBAC может выглядеть так:

Role = Accountant → allow

ABAC может учитывать больше условий:

Department = Finance
AND country = Germany
AND device = managed
→ allow

RBAC и Conditional Access

Современные системы часто комбинируют модели.

Role определяет базовые Permissions, а Conditional Access добавляет дополнительные условия.

Role = Administrator
+
MFA passed
+
Managed device
→ allow admin console

RBAC и Zero Trust

Zero Trust использует Least Privilege и явную проверку каждого Access Request.

RBAC помогает определить базовые права пользователя, но для полноценного Zero Trust желательно учитывать также Device, Risk и контекст.

Role Assignment

Role Assignment — назначение роли пользователю.

Оно может выполняться:

• вручную Administrator;
• автоматически из HR System;
• на основании Group;
• через Access Request;
• через JIT Workflow.

Автоматическое назначение ролей

Например, HR System сообщает:

Department = Finance
Position = Accountant

IAM автоматически назначает:

Role = Finance Accountant

Это уменьшает ручную работу IT.

Role Mapping

Role Mapping связывает данные из одной системы с Roles в другой.

Например, Group в корпоративном Directory может соответствовать Role в SaaS Application.

Group и Role

Group и Role часто используются вместе, но концептуально отличаются.

Group объединяет пользователей, а Role описывает Permissions.

User → Group → Role → Permissions

Некоторые продукты объединяют эти понятия в одной сущности.

Role Hierarchy

Roles могут иметь иерархию.

Например:

Employee
↓
Accountant
↓
Senior Accountant
↓
Finance Administrator

Более высокая Role может наследовать Permissions нижестоящей.

Преимущества Role Hierarchy

Иерархия уменьшает дублирование одинаковых Permissions между Roles.

Однако слишком сложное наследование делает Access Model трудной для понимания.

Role Inheritance

При наследовании Role получает Permissions другой Role.

Например, Senior Accountant наследует базовые права Accountant и получает дополнительные возможности.

Опасность сложного наследования

Если Role наследует несколько других Roles, Administrator может не сразу понимать фактический набор Permissions.

Поэтому важны инструменты Effective Permissions и регулярный Audit.

Effective Permissions

Effective Permissions — итоговый набор прав пользователя после учета всех Roles, Groups и Policies.

Это именно тот Access, который необходимо анализировать при расследовании и Access Review.

Multiple Roles

Пользователь может иметь несколько Roles одновременно.

User Ivan
↓
Accountant
Report Viewer
Project Manager

Итоговый набор прав обычно формируется на основе всех назначений.

Role Explosion

Role Explosion возникает, когда организация создает слишком много очень узких Roles.

Например:

Accountant Moscow Read
Accountant Moscow Write
Accountant Berlin Read
Accountant Berlin Write
Accountant Senior Moscow
...

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

Почему возникает Role Explosion

Причины:

• попытка учесть каждое исключение новой Role;
• слишком детальное разделение Departments;
• отсутствие ABAC;
• плохая первоначальная Role Design;
• накопление Legacy Roles.

Как уменьшить Role Explosion

Можно:

• выделить базовые Roles;
• использовать Composite Roles;
• перенести контекстные условия в ABAC;
• удалять неиспользуемые Roles;
• проводить Role Mining.

Role Mining

Role Mining — анализ существующих Permissions пользователей с целью выявить типовые наборы и построить на их основе Roles.

Это полезно при миграции от хаотичной индивидуальной выдачи доступа к RBAC.

Top-down Role Design

При Top-down подходе Roles создаются на основании бизнес-функций и организационной структуры.

Job description
↓
Business role
↓
Permissions

Bottom-up Role Design

При Bottom-up подходе анализируются уже существующие права пользователей и ищутся повторяющиеся наборы.

На практике часто используется сочетание обоих методов.

Business Role

Business Role соответствует рабочей функции.

Например:

• Accountant;
• Sales Manager;
• HR Specialist;
• System Administrator.

Technical Role

Technical Role представляет набор Permissions конкретного приложения.

Например:

CRM_REPORT_EXPORT
DB_READ_FINANCE
CLOUD_STORAGE_VIEWER

Business Role может включать несколько Technical Roles.

Composite Role

Composite Role объединяет другие Roles.

Например:

Business role: Accountant
↓
ERP user
Finance report viewer
Document system user

Так можно управлять доступом сразу к нескольким системам.

Role Owner

У каждой важной Role должен быть Owner, который понимает ее бизнес-назначение.

Security или IT не всегда могут самостоятельно определить, какие Permissions нужны бухгалтеру или менеджеру по закупкам.

Почему Role Owner важен

Owner должен подтверждать:

• назначение Role;
• состав Permissions;
• кому ее можно выдавать;
• нужна ли Role дальше.

Access Request

Если пользователю требуется дополнительная Role, он может отправить запрос.

User request
↓
Manager approval
↓
Role owner approval
↓
Role assigned

Так появляется прозрачный Audit Trail.

Temporary Role

Некоторые права нужны временно.

Role можно назначить на срок:

Start: Monday
End: Friday

После окончания периода назначение автоматически удаляется.

RBAC и JIT

Just-in-Time Access хорошо сочетается с RBAC.

Пользователь временно получает Administrative Role только на время выполнения задачи.

RBAC и PAM

PAM контролирует Privileged Access, а RBAC определяет, какие административные функции доступны.

Например, один Administrator получает Role для Linux Servers, другой — только для Database.

Separation of Duties

Segregation of Duties ограничивает сочетание конфликтующих Roles.

Например, сотрудник не должен одновременно иметь возможность создавать нового поставщика и самостоятельно утверждать платеж этому поставщику.

SoD Conflict

Система Governance может обнаружить конфликт:

Role A = Vendor Creator
Role B = Payment Approver
User has A + B
↓
SoD conflict

Назначение может быть запрещено или потребовать дополнительного Approval.

RBAC и финансовые системы

Разделение полномочий особенно важно в бухгалтерии, казначействе и закупках.

RBAC позволяет формально закрепить разные этапы бизнес-процесса за разными пользователями.

RBAC в 1С

В системах 1С роли и права используются для ограничения доступных пользователю объектов и операций.

Например, пользователю можно разрешить работу с определенными документами и отчетами, но запретить административные функции.

Конкретная модель зависит от конфигурации и архитектуры системы.

RBAC в CRM

В CRM Role может определять:

• видимость клиентов;
• редактирование сделок;
• экспорт данных;
• просмотр отчетов;
• администрирование пользователей.

RBAC в Database

Database Roles позволяют объединять SQL Permissions.

report_reader → SELECT
report_writer → SELECT + INSERT
admin → administrative permissions

Application и Analysts не должны автоматически получать DBA Rights.

RBAC в PostgreSQL и других СУБД

Многие реляционные Database Systems имеют механизм Roles или пользователей с группировкой Permissions.

Названия и возможности отличаются, но принцип остается тем же: права централизованно связываются с определенной Identity или Role.

RBAC в Kubernetes

Kubernetes использует RBAC для Authorization запросов к API.

Модель включает Roles, ClusterRoles и Bindings.

Subject
↓ RoleBinding
Role
↓ permissions
Kubernetes API resources

Role в Kubernetes

Role обычно описывает Permissions внутри определенного Namespace.

Например, разрешает читать Pods.

ClusterRole

ClusterRole может использоваться для Permissions на уровне Cluster или повторно применяться в разных Namespaces.

Особенно осторожно следует относиться к широким административным ClusterRoles.

RoleBinding

RoleBinding связывает User, Group или Service Account с Role в определенном Scope.

ClusterRoleBinding

ClusterRoleBinding может предоставить ClusterRole на уровне всего Cluster.

Ошибочное назначение широкого Cluster Admin является серьезным Security Risk.

RBAC и Service Accounts

Roles назначаются не только людям.

Application Service или Kubernetes Workload также может иметь Role.

Она должна содержать минимальные Machine Permissions.

RBAC в Cloud

Cloud Platforms широко используют Roles для доступа к:

• Virtual Machines;
• Storage;
• Databases;
• Logs;
• Networking;
• Security Configuration.

Cloud Role

Вместо постоянного Administrator Account пользователь получает определенную Role.

Developer → application-deployer
Analyst → data-reader
Security team → audit-reader

RBAC и Cloud Least Privilege

Одна из распространенных ошибок — назначать полный Administrator Access для ускорения работы.

При компрометации такой Identity злоумышленник получает слишком большой Blast Radius.

RBAC и API

Backend может проверять Role после Authentication пользователя.

GET /reports
Role = analyst → allow

DELETE /users
Role = analyst → deny

Однако Role должна проверяться на доверенной Server-side стороне.

Нельзя проверять Role только во Frontend

Frontend может скрыть кнопку Administrator, но пользователь способен изменить Browser Code или самостоятельно вызвать API.

Authorization должна выполняться Backend.

RBAC и JWT

JWT может содержать Role Claim.

Например:

{
 "sub": "user-125",
 "roles": ["accountant"]
}

API может использовать эту информацию только после полной проверки Token.

Устаревшая Role в JWT

Если Role пользователя изменилась, старый Token может продолжать содержать прежнее значение до Expiration.

Поэтому Session и Token Lifetime должны учитывать требования к быстрому отзыву доступа.

RBAC и OAuth

OAuth чаще использует Scopes для описания делегированного API Access, а RBAC — Roles пользователя.

Application может учитывать и Scope, и Role одновременно.

Role и Scope

RBAC и SSO

SSO отвечает за единый Login, а Roles определяют права внутри подключенных Applications.

Identity Provider может передавать Role или Group Attributes приложению при Federation.

RBAC и SCIM

SCIM может автоматически синхронизировать Groups и Users с SaaS Application.

Эти Groups затем сопоставляются с Application Roles.

RBAC и DLP

RBAC решает, может ли User получить доступ к Data, а DLP — можно ли после этого передать их наружу.

RBAC → read customer database allowed
DLP → external upload blocked

Эти механизмы дополняют друг друга.

RBAC и EDR

EDR не является системой управления Roles, но Administrative Access к EDR Console должен быть ограничен RBAC.

Например, Analyst может расследовать Alert, но не иметь права отключать Endpoint Protection.

RBAC в SIEM

SIEM содержит чувствительные Logs и Security Data.

Roles могут разделять:

• SOC Analyst;
• Detection Engineer;
• Administrator;
• Auditor.

RBAC в SOC

Даже внутри SOC не каждому сотруднику нужны одинаковые Permissions.

L1 Analyst может просматривать Alerts, а изменение Detection Rules доступно только Detection Engineer.

RBAC и Zero Trust

RBAC является базовым механизмом Least Privilege, но статичная Role не учитывает текущий Risk.

Поэтому Zero Trust часто дополняет RBAC контекстом:

Role = Finance
AND device = compliant
AND MFA = passed
→ allow

Недостаток чистого RBAC

Role «Finance» может быть назначена пользователю постоянно.

Но система может захотеть запретить доступ с личного Device или необычной Location.

Для этого требуется дополнительная Policy Logic.

Default Deny

Безопасная Access Model обычно строится так, что отсутствие явно выданного Permission означает запрет.

No matching permission → deny

Это надежнее модели, где все разрешено, кроме явно запрещенного.

Deny Rules

Некоторые системы поддерживают явные Deny Rules.

При их использовании важно четко понимать порядок вычисления Effective Permissions, поскольку он отличается между платформами.

Role Review

Roles необходимо регулярно пересматривать.

Если Business Process изменился, старый набор Permissions может стать избыточным.

Access Review

При Access Review руководитель или Data Owner подтверждает, действительно ли конкретному пользователю нужна назначенная Role.

Role Recertification

Recertification проверяет как состав Roles, так и назначения пользователей.

Особенно важно регулярно пересматривать Privileged Roles.

Orphan Role

Orphan Role — Role без понятного Owner или бизнес-назначения.

Такие Roles часто остаются после старых Projects и создают Security Debt.

Unused Role

Если Role никому не назначена и больше не нужна, ее полезно удалить или архивировать.

Это упрощает Access Model.

Privilege Creep

Privilege Creep происходит, когда сотрудник постепенно накапливает Roles при переходах между должностями.

Sales role
+
Finance role
+
Project admin role

Если старые назначения не отзываются, Access становится чрезмерным.

Joiner-Mover-Leaver

RBAC должен быть связан с жизненным циклом сотрудника.

При приеме назначается базовая Role, при переводе старые Roles пересматриваются, а при увольнении доступ полностью отзывается.

RBAC и HR System

HR Data могут использоваться для автоматического Role Assignment:

Department = Sales
Position = Manager
↓
Sales Manager Role

Но автоматическое правило должно учитывать исключения и контроль качества HR Data.

Ошибочная HR-информация

Если Department указан неправильно, автоматизация может выдать неправильную Role.

Поэтому Source of Truth также является частью Security Architecture.

RBAC и подрядчики

Contractor желательно выдавать отдельные Roles с ограниченным Scope и Expiration.

Не стоит назначать внешнему специалисту ту же постоянную Role, что внутреннему Administrator.

Временные проекты

Project Role можно автоматически удалять после завершения Project.

Это предотвращает накопление доступа.

RBAC и Multi-tenant Systems

В SaaS недостаточно проверить только Role.

Нужно учитывать Tenant.

Role = Admin
Tenant = Company A

User не должен получать Administrator Access к Company B.

Role без Object-level Authorization

Одна из типичных ошибок:

User has role = manager
→ allow any customer record

Но Manager может иметь право только на клиентов своего Department.

Поэтому RBAC иногда дополняется Object-level Policy.

Broken Access Control

Неправильная проверка Roles и Objects может привести к Broken Access Control.

Например, обычный User меняет ID документа в URL и получает чужие данные.

Наличие RBAC само по себе не предотвращает такую ошибку.

RBAC и микросервисы

В Microservices Architecture важно единообразно передавать и проверять Access Context.

Если Service A проверил Role, это не всегда означает, что Service B может полностью доверять любому входящему Request.

Centralized Policy и Distributed Enforcement

Policies могут описываться централизованно, а применяться в API Gateway и отдельных Services.

Важно обеспечить единообразие правил.

RBAC и Service Mesh

Service Mesh может управлять Machine-to-Machine Authorization на основании Service Identity.

Это похоже на RBAC, но субъектами становятся Workloads, а не только пользователи.

Machine RBAC

Например:

Role = reporting-service
Permission = read analytics database

Service не получает Write Access, если он ему не нужен.

RBAC и Terraform

Cloud Roles и Permissions можно описывать через Infrastructure as Code.

Это дает Version Control и Code Review изменений доступа.

Access as Code

Role Definitions могут храниться как конфигурация:

role: report-reader
permissions:
read_reports

Изменения проходят Review до Deployment.

Преимущество Version Control

Можно увидеть:

• кто изменил Role;
• когда;
• какое Permission добавлено;
• кто одобрил изменение.

RBAC и аудит

Audit должен отвечать на вопросы:

Логирование изменений Roles

Особенно важно фиксировать:

• создание Role;
• добавление Permission;
• назначение пользователя;
• назначение Privileged Role;
• удаление Role;
• изменение Owner.

RBAC и SIEM

Role Changes можно отправлять в SIEM.

Неожиданное назначение Global Admin ночью может стать High Severity Alert.

RBAC и SOC

SOC использует Role Context при расследовании.

Одинаковое действие имеет разный риск для обычного User и Privileged Administrator.

Компрометация Role Administrator

Account, способный самостоятельно назначать Roles, является критичным.

Его необходимо защищать MFA, PAM и строгим Audit.

Role Administrator и Separation of Duties

Желательно, чтобы один человек не мог одновременно создать высокую Role, назначить ее себе и скрыть изменение без Audit.

RBAC и Compliance

RBAC помогает реализовать принцип разделения обязанностей и контролируемого доступа.

Но сам факт наличия Roles не означает автоматического соответствия требованиям стандарта или законодательства.

Типичные ошибки RBAC

1. Создавать одну Role Full Access для большинства сотрудников.
2. Назначать Permissions пользователям напрямую в обход Roles.
3. Не удалять старые Roles после перевода.
4. Создавать слишком много узких Roles.
5. Не назначать Role Owners.
6. Не проводить Access Reviews.
7. Использовать Frontend как единственную точку проверки Role.
8. Не учитывать Tenant и Object-level Access.
9. Не контролировать Privileged Role Assignments.
10. Не логировать изменения.

Прямые Permissions пользователям

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

Через несколько лет становится невозможно объяснить фактический Access.

Как внедрить RBAC

Шаг 1. Инвентаризировать Permissions

Определите, какие действия вообще доступны в системе.

Шаг 2. Определить рабочие функции

Сопоставьте Permissions с реальными Job Functions.

Шаг 3. Создать базовые Roles

Не пытайтесь сразу описать каждое исключение.

Шаг 4. Назначить Role Owners

Business Owner должен подтвердить состав Role.

Шаг 5. Перенести пользователей

Замените хаотические прямые Permissions на Role Assignments.

Шаг 6. Настроить Approval

Особенно для чувствительных Roles.

Шаг 7. Проводить Access Reviews

Регулярно удаляйте ненужные назначения.

Шаг 8. Мониторить изменения

Privileged Role Events должны поступать в Audit и SIEM.

Как проектировать хорошие Roles

Role должна:

• иметь понятное бизнес-название;
• иметь Owner;
• содержать минимальные Permissions;
• не дублировать другую Role без необходимости;
• иметь понятный Scope;
• регулярно пересматриваться.

Плохое название Role

Название вроде:

ROLE_0017_NEW_FINAL

не объясняет бизнес-назначение.

Лучше:

Finance Invoice Approver

Role Description

У Role желательно иметь описание:

Purpose: approve supplier invoices
Owner: Head of Finance
Scope: Germany entity
Risk: High

Это значительно облегчает Governance.

Role Lifecycle

Roles, как и User Accounts, имеют жизненный цикл:

Design
↓
Approval
↓
Use
↓
Review
↓
Modification or retirement

Неиспользуемые Roles необходимо выводить из эксплуатации.

Метрики RBAC

RBAC Maturity

Развитие Access Model можно представить так:

Direct permissions
↓
Basic roles
↓
Business roles
↓
Automated provisioning
↓
Access reviews
↓
RBAC + contextual policies

Практический пример

В компании 120 сотрудников используют систему документооборота.

Раньше Administrator вручную назначал Permissions каждому человеку.

Через несколько лет сотрудники накопили множество непонятных прав.

Компания вводит RBAC и определяет четыре основные Roles:

Employee
Department Manager
Finance Approver
System Administrator

Для каждой Role определяется минимальный набор Permissions.

Обычный Employee может создавать и читать собственные документы. Department Manager дополнительно утверждает документы своего подразделения. Finance Approver получает доступ к финансовым операциям, а System Administrator — к технической настройке.

HR System автоматически назначает базовую Role при приеме сотрудника.

При переводе в другой Department старые назначения пересматриваются.

Finance Approver проходит квартальный Access Review, а System Administrator выдается только через PAM на ограниченное время.

В результате количество индивидуальных Permissions снижается, а компания может объяснить, почему конкретный User имеет доступ к определенной функции.

RBAC для бизнеса

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

Он снижает стоимость администрирования, ускоряет Onboarding и делает Access более прозрачным для Audit.

Однако чрезмерно сложная Role Model сама может стать проблемой. Поэтому RBAC требует Governance: понятных Owners, регулярных Reviews и контроля Role Explosion.

Преимущества RBAC

• упрощает выдачу Permissions;
• поддерживает Least Privilege;
• ускоряет Onboarding;
• облегчает Deprovisioning;
• упрощает Audit;
• поддерживает Separation of Duties;
• хорошо масштабируется для типовых рабочих функций.

Ограничения RBAC

• статичные Roles плохо учитывают Context;
• возможен Role Explosion;
• Roles могут накапливать лишние Permissions;
• нужны регулярные Access Reviews;
• не всегда удобно описывать Object-level Access;
• не заменяет Authentication;
• не устраняет ошибки Authorization в приложении.

Когда использовать RBAC

RBAC подходит, когда в организации существуют стабильные рабочие функции и большое количество пользователей с похожими наборами Permissions.

Если Access сильно зависит от Location, Device, времени, Attributes или конкретного объекта, RBAC часто дополняют ABAC и другими Policy-based механизмами.

Связанные термины

Краткий итог

RBAC — Role-Based Access Control, модель управления доступом, при которой Permissions объединяются в Roles, а пользователям назначаются уже готовые наборы прав.

RBAC упрощает администрирование, поддерживает Least Privilege и позволяет связать Access с реальными рабочими функциями. Вместо сотен индивидуальных настроек компания управляет ограниченным набором понятных Roles.

При этом RBAC требует регулярного Governance. Необходимо контролировать Role Explosion, Privilege Creep, прямые Permissions и Privileged Roles. В современных Zero Trust и IAM Architecture RBAC часто дополняется ABAC, Conditional Access, PAM и другими контекстными механизмами управления доступом.