Как работает контроль доступа (RBAC, принцип наименьших привилегий)?

Question

Accepted Answer

**Контроль доступа** определяет, что могут делать аутентифицированные пользователи — через модели, такие как **RBAC** (Role-Based Access Control, контроль доступа на основе ролей) и принципы, такие как **принцип наименьших привилегий**. Правильный контроль доступа критически важен, поскольку нарушенный контроль доступа — это уязвимость #1 по версии OWASP.

## Модели контроля доступа

```text
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
  → user → role(s) (admin, editor, viewer) → permissions → access decisions
  → manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
  fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
```

## Принцип наименьших привилегий

```text
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
  → limits the BLAST RADIUS if an account/component is compromised
  → applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
```

## Безопасная реализация контроля доступа

```text
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
  the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
  others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
```

## Почему это важно

Понимание контроля доступа важно, потому что он **определяет, что могут делать пользователи, и критичен для безопасности** — нарушенный контроль доступа является уязвимостью #1 по версии OWASP — поэтому это ценные и практически критические знания в области безопасности.

Контроль доступа определяет, что разрешено делать аутентифицированным пользователям, и правильная реализация является обязательной.

Понимание **моделей** — **RBAC** (назначение пользователям ролей, имеющих разрешения — управляемо и распространено), **ABAC** (решения на основе атрибутов для гибкого, тонкого управления) и ACL (списки разрешений для каждого ресурса) — предоставляет фреймворки для структурирования разрешений, при этом RBAC является наиболее распространённой для понимания.

Понимание **принципа наименьших привилегий** — предоставления **минимального необходимого доступа**, что **ограничивает радиус поражения при компрометации учётной записи или компонента** — это фундаментальный принцип безопасности, применяемый широко (пользователи, сервисы, учётные записи баз данных, API ключи), и один из наиболее важных концепций безопасности.

Критически важно понимание того, как **безопасно реализовать контроль доступа**, что решает уязвимость #1: **принудительная авторизация на сервере для каждого защищённого действия** (никогда не доверять клиенту или полагаться на скрытый пользовательский интерфейс — частая ошибка), **проверка авторизации для конкретного ресурса** (предотвращение IDOR, когда пользователи получают доступ к данным других, изменяя ID — частая ошибка нарушенного контроля доступа), **отказ по умолчанию**, проверка при каждом запросе и **тестирование контроля доступа** (частый пробел, поскольку пропущенные проверки авторизации легко не заметить).

Поскольку контроль доступа определяет, что могут делать пользователи, и нарушенный контроль доступа является главной уязвимостью (распространённой и серьёзной), и поскольку понимание моделей (RBAC), принципа наименьших привилегий и безопасной реализации (принудительное применение на сервере, проверки для конкретного ресурса, отказ по умолчанию) критично для безопасности, понимание контроля доступа является ценным и практически критическим знанием в области безопасности — решающим уязвимость #1, фундаментальным для управления тем, что могут делать пользователи, и необходимым для избежания ошибок нарушенного контроля доступа (таких как IDOR и пропущенные проверки авторизации), которые находятся среди наиболее распространённых и серьёзных уязвимостей.