Security

RBAC и ACL

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

Что такое RBAC и ACL

Это две модели управления доступом, отвечающие на один вопрос — «кому что разрешено» — но с разных сторон.

ACL расшифровывается как Access Control List, список контроля доступа. Он привязан к объекту и перечисляет, кто и что может с ним делать: «на файл /data/report.csv: Иванов — чтение, Петров — чтение и запись».

RBAC — Role-Based Access Control, ролевая модель. Права привязаны к роли, а пользователю выдаётся роль: «роль analyst может читать отчёты; Иванов — analyst».

ACL RBAC
Права висят на Объекте Роли
Ответ на вопрос Кто имеет доступ к этому файлу? Что может этот пользователь?
Масштабирование Плохо: N пользователей × M объектов Хорошо: роли переиспользуются
Гранулярность Высокая, вплоть до объекта Ниже, на уровне групп прав
Приход нового сотрудника Правка прав на каждом объекте Выдать роль
Типичное применение Файловая система, сетевые ACL Корпоративные системы, Kubernetes

На практике их не противопоставляют, а сочетают: RBAC задаёт основу, ACL точечно уточняет исключения. Ошибка — строить всё на ACL: через год никто не сможет ответить, почему у подрядчика есть доступ к бухгалтерской папке.

Соседние модели

  • DAC (Discretionary) — владелец объекта сам раздаёт права. Классический chmod в Linux.
  • MAC (Mandatory) — права задаёт система по меткам секретности, владелец не может их изменить. SELinux, режимы гостайны.
  • ABAC (Attribute-Based) — решение считается из атрибутов: «отдел = финансы И время рабочее И устройство корпоративное». Гибче RBAC, сложнее в отладке; вычисляется в PDP.

ACL в Linux и в сети

# POSIX ACL — права тоньше, чем владелец/группа/остальные
setfacl -m u:deploy:rx /opt/app
getfacl /opt/app

# сетевой ACL — то же понятие на уровне пакетов
iptables -A INPUT -s 203.0.113.0/24 -p tcp --dport 5432 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j DROP

Security groups в облаке и правила iptables — это тот же ACL, только объект здесь не файл, а сетевой порт.

RBAC в Kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { namespace: prod, name: pod-reader }
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { namespace: prod, name: dev-can-read-pods }
subjects: [{ kind: User, name: ivanov, apiGroup: rbac.authorization.k8s.io }]
roleRef: { kind: Role, name: pod-reader, apiGroup: rbac.authorization.k8s.io }

Role действует в namespace, ClusterRole — во всём кластере. Выдача cluster-admin «чтобы не разбираться» — самая частая дыра в кластерах.

Что такое имперсонация

Имперсонация (impersonation) — выполнение действий от имени другого пользователя. Легитимный механизм: админ проверяет, что видит клиент, сервис действует от имени пользователя, техподдержка воспроизводит баг. 

sudo -u www-data ls /var/www          # Linux
kubectl get pods --as=ivanov -n prod  # Kubernetes: проверить чужие права

Правило простое: имперсонация обязана логироваться с двумя субъектами — кто вошёл и от чьего имени действовал. Если в логе остаётся только «ivanov удалил запись», а сделал это админ через имперсонацию, вы потеряли и аудит, и возможность разобрать инцидент. Само право имперсонации — привилегия уровня root, выдаётся единицам.

Принципы, которые важнее модели

  • Минимальные привилегии. Права ровно под задачу, а не «на всякий случай».
  • Разделение обязанностей. Тот, кто выдаёт доступ, не должен им пользоваться.
  • Регулярный пересмотр. Права накапливаются: человек меняет отделы, а старые роли остаются. Без ревью через два года у половины сотрудников доступ ко всему.
  • Отзыв при увольнении — через IAM, а не вручную по системам.

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

Готовы запустить GPU-задачу?

Запустить GPU-сервер