RBAC: когда теория сталкивается с продакшеном

Если вы когда-либо видели, как администраторы вручную добавляют права пользователям через SQL-запросы, или как в логах появляются записи о несанкционированном доступе из-за неправильно настроенных разрешений, — вам знакома проблема. RBAC (Role-Based Access Control) должен решать эти вопросы, но на практике часто становится источником новых. Почему так происходит и как этого избежать?

Проблема: RBAC как "черный ящик"

В документации RBAC выглядит просто: пользователь → роль → права. Но в реальном проекте всё гораздо сложнее:

  1. Роли растут как снежный ком — изначально 5 ролей превращаются в 50, потому что "нужно ещё одно исключение для отдела X".
  2. Конфликты между бизнес-требованиями и тех-реализацией — менеджеры требуют гибкости, а инженеры — стабильности.
  3. Отсутствие инструментов для аудита — даже если RBAC настроен, никто не проверяет, кто и когда получил те или иные права.

В итоге система управления доступом становится не прозрачной, а хаотичной. И виноват в этом не RBAC как концепция, а её неправильная реализация.

Практика: как RBAC работает в продакшене

RBAC в продакшене — это не только набор ролей, но и система, которая должна:

  • Масштабироваться — добавлять новых пользователей и роли без простоя.
  • Логироваться — фиксировать все изменения в правах для аудита.
  • Интегрироваться — работать с существующими системами аутентификации (LDAP, OAuth, SAML).
  • Быть обратимым — позволять откатывать изменения в случае ошибки.

Пример: RBAC в Kubernetes с OPA/Gatekeeper

Один из самых надёжных способов внедрить RBAC на практике — использовать Open Policy Agent (OPA) вместе с Gatekeeper в Kubernetes. Это позволяет задавать политики в виде файлов YAML или Rego и автоматически блокировать несоответствующие ресурсы.

Пример политики (Gatekeeper Constraint):

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-rbac-annotations
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "rbac.role"
        allowedValues: ["admin", "developer", "viewer"]

Как это работает:

  1. Все новые namespaces должны иметь метку rbac.role.
  2. Gatekeeper проверяет это автоматически и блокирует создание namespace без правильной метки.
  3. Политика хранится в репозитории и может быть проаудирована.

Преимущества: ✅ Автоматизация проверок. ✅ Централизованное управление политиками. ✅ Возможность тестирования изменений в staging до применения в продакшене.

Примеры: RBAC в разных системах

1. RBAC в PostgreSQL (pg_roles)

Если вы используете PostgreSQL, RBAC там реализован через роли (roles). Но часто инженеры забывают о том, что роли могут наследовать права друг друга, что приводит к неожиданным багам.

Пример конфигурации:

-- Создаём роль для аналитиков
CREATE ROLE analyst NOINHERIT;

-- Даём доступ только к определённым таблицам
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO analyst;

-- Запрещаем создавать новые объекты
REVOKE CREATE ON SCHEMA analytics FROM analyst;

-- Проверяем права
\dn+ analytics.* analyst

Что часто ломается:

  • Наследование прав — если роль analyst наследует права от superuser, то все ограничения сбрасываются.
  • Отсутствие аудита — PostgreSQL не ведёт лог изменений ролей по умолчанию (нужно настраивать pgAudit).

2. RBAC в GitHub Actions (workflow permissions)

Даже в CI/CD RBAC важен. Например, в GitHub Actions можно ограничить права токенов, чтобы они не могли случайно push’ить в main-ветку.

Пример workflow с ограниченными правами:

name: CI Pipeline
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test
    permissions:
      contents: read  # Только чтение репозитория
      issues: write  # Можно создавать/issues, но не push’ить

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

  • Использование GITHUB_TOKEN с правами write — если не ограничить, бот сможет закоммитить изменения.
  • Отсутствие разделения ролей — один сервис-аккаунт с правами на всё.

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

  1. "Одна роль на всех"

    • Проблема: Все пользователи получают роль admin, потому что "проще".
    • Последствие: Утечка данных, невозможность отследить, кто что сделал.

  2. Роли не привязаны к бизнес-процессам

    • Проблема: Роли создаются по техническим признакам ("может читать API"), а не по задачам ("менеджер проекта X").
    • Последствие: Конфликты между отделами, потому что права не соответствуют реальным нуждам.

  3. Отсутствие процесса изменения ролей

    • Проблема: Никто не контролирует, кто и когда получил новые права.
    • Последствие: "Роль для тестирования" остаётся в продакшене годами.

  4. RBAC как "дополнение" к системе

    • Проблема: RBAC внедряется после того, как система уже сложилась.
    • Последствие: Приходится переписывать логику или вводить костыли.

  5. Недооценка производительности

    • Проблема: Сложные запросы для проверки прав тормозят систему.
    • Последствие: Лаги в интерфейсе, особенно при большом количестве пользователей.

Как избежать проблем: checklist для инженера

Шаг Описание Инструмент/Пример
1. Аудит текущих прав Проверьте, кто и какие права уже имеет. aws iam list-users, kubectl get roles --all-namespaces
2. Определение бизнес-ролей Не технические роли, а привязанные к задачам. "Менеджер проекта" → доступ к таск-трекеру + бюджету.
3. Автоматизация проверок Не доверяйте ручной настройке. Gatekeeper, OPA, Terraform Sentinel.
4. Логирование изменений Все изменения в правах должны фиксироваться. AWS CloudTrail, PostgreSQL pgAudit.
5. Тестирование в staging Проверьте RBAC-политики до внедрения в продакшен. Chaos Engineering для проверки отказов.
6. Обучение команды Если инженеры не понимают RBAC, они будут его обходить. Документация с примерами, тренинги.

Вывод: RBAC — это не разовая настройка, а процесс

RBAC не работает "из коробки". Это система, которая требует постоянного внимания:

  1. Начинайте с минимального набора ролей — лучше добавить позже, чем переделывать всё.
  2. Автоматизируйте всё, что можно — ручная настройка прав приводит к ошибкам.
  3. Не забывайте про аудит — если вы не можете ответить на вопрос "кто получил доступ к X?", RBAC не работает.
  4. Тестируйте изменения — даже небольшие правки могут сломать систему.
  5. Документируйте — если следующий инженер не поймёт, как работает RBAC, он начнёт вносить изменения "на лету".

Практический совет: Начните с одного сервиса или системы (например, Kubernetes или PostgreSQL) и постепенно расширяйте RBAC на остальные компоненты. Так вы избежите "большого взрыва" при внедрении и сможете быстро исправить ошибки.

RBAC — это не просто безопасность, это инструмент для контроля над системой. Если вы относитесь к нему как к набору правил, а не как к живой части инфраструктуры, он превратится в головную боль. А если подойти к этому серьёзно — он станет вашим союзником в борьбе с хаосом.