Проектирование RBAC-политик

Введение

Внедрить RBAC технически — просто: CREATE ROLE, GRANT, REVOKE. Спроектировать правильную RBAC-модель — сложно. Плохо спроектированная модель ведёт к role explosion, over-privileged пользователям и compliance-нарушениям. В этом уроке мы спроектируем production RBAC-политику для FinSecure Bank с нуля.

Сценарий: аудит FinSecure

Сценарий: FinSecure Bank (ФинСекьюр Банк)

Внутренний аудит безопасности выявил критическую проблему: 47% пользователей имеют избыточные привилегии (over-privileged access). Конкретные находки:

• 8 аналитиков имеют запись в production-таблицы (нужен только SELECT)
• 3 инженера имеют admin-доступ к Oracle core banking (нужен только staging)
• 12 пользователей имеют роли, созданные “временно” 2 года назад, но никогда не отозванные
• Существует 34 пользовательских роли, из которых 19 дублируют друг друга

Data Council поручил команде безопасности разработать новую RBAC-модель с нуля.

Шаг 1: инвентаризация ресурсов

Первый шаг — каталогизация всех ресурсов, к которым нужен доступ:

Шаг 2: определение ролей по функциям

Роли определяются по функциям, а не по отделам или проектам:

-- Базовые роли (leaf roles)
CREATE ROLE fs_viewer NOLOGIN;       -- только чтение агрегатов
CREATE ROLE fs_analyst NOLOGIN;      -- чтение + аналитика
CREATE ROLE fs_engineer NOLOGIN;     -- чтение + запись staging
CREATE ROLE fs_steward NOLOGIN;      -- чтение + маскированные PII
CREATE ROLE fs_auditor NOLOGIN;      -- только audit log
CREATE ROLE fs_dba NOLOGIN;          -- администрирование БД

-- Иерархия
GRANT fs_viewer TO fs_analyst;       -- analyst включает viewer
GRANT fs_viewer TO fs_engineer;      -- engineer включает viewer

Шаг 3: матрица разрешений

Шаг 4: документирование политики

Шаг 5: валидация и тестирование

Автоматическая валидация политики

def validate_rbac_policy(roles, permissions, constraints):
    """Валидация RBAC-политики на типичные проблемы."""
    issues = []

    # Проверка 1: Role explosion (больше 2x пользователей)
    if len(roles) > len(set(r['function'] for r in roles)) * 2:
        issues.append("WARNING: Potential role explosion detected")

    # Проверка 2: Over-privileged roles
    for role in roles:
        if role.get('all_schemas_access'):
            issues.append(f"CRITICAL: {role['name']} has ALL SCHEMAS access")

    # Проверка 3: Separation of duties violations
    for constraint in constraints.get('incompatible_roles', []):
        role_a, role_b = constraint
        for user in get_users():
            if has_role(user, role_a) and has_role(user, role_b):
                issues.append(
                    f"VIOLATION: {user} has incompatible roles "
                    f"{role_a} and {role_b}"
                )

    # Проверка 4: Stale roles (не использовались > 90 дней)
    for role in roles:
        if role.get('last_used_days_ago', 0) > 90:
            issues.append(
                f"STALE: {role['name']} not used in "
                f"{role['last_used_days_ago']} days"
            )

    return issues

Предотвращение role explosion

Role explosion — ситуация, когда количество ролей растёт неконтролируемо. Признаки:

В FinSecure до аудита было 34 роли для 30 пользователей — типичный role explosion. После редизайна: 6 базовых ролей + 2 составные = 8 ролей. Сокращение на 76%.

Итоги

• Проектирование RBAC начинается с инвентаризации ресурсов и определения ролей по функциям
• Матрица разрешений визуализирует связь ролей и ресурсов — базовый артефакт policy review
• Документирование политики включает: принцип least privilege, separation of duties, ротацию, логирование
• Валидация автоматизирует проверку: role explosion, over-privileged, stale roles, SoD violations
• Role explosion — основная проблема RBAC; предотвращается мониторингом метрик и периодической консолидацией
• FinSecure сократила 34 роли до 8 после аудита, обнаружившего 47% over-privileged пользователей

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