Централизованная авторизация¶
Требования этого документа применяются к проверке прав пользователя, сервиса и
другого субъекта после успешной аутентификации. Уровни обязательности
определены в корневом README.md.
В этом документе Casbin Server выполняет роль Policy Decision Point (PDP), а интеграция Casbin SDK в backend — роль Policy Enforcement Point (PEP).
SEC-AUTHZ-001. Централизованное решение через Casbin Server¶
Уровень: SHOULD
Применяется к: проектам с защищёнными операциями
Решение о доступе следует централизованно получать от Casbin Server.
Обязательные правила интеграции при его выборе определены в SEC-AUTHZ-012.
Собственная реализация policy engine, разрозненные таблицы ролей в сервисах и копирование Casbin policy между сервисами не должны использоваться как основной механизм авторизации.
Обоснование¶
Единый PDP обеспечивает одинаковую интерпретацию policy и централизованное управление правами для нескольких сервисов.
Проверка¶
- review архитектуры AuthZ и зависимостей backend;
- integration-тест вызова Casbin Server через SDK;
- поиск локальных реализаций policy evaluation.
Исключения¶
Локальный Casbin enforcer или другой механизм допускается по утверждённому ADR при требованиях автономности, задержки или доступности, которые нельзя выполнить через Casbin Server.
SEC-AUTHZ-002. Авторизация на backend-границе¶
Уровень: MUST
Применяется к: каждой защищённой backend-операции
Backend должен вызвать PEP после аутентификации и до выполнения защищённого действия или раскрытия данных. Для подготовки ABAC-контекста допускается минимальное внутреннее чтение объекта без передачи результата вызывающей стороне. Проверка должна выполняться для фактических subject, object, action и tenant/domain операции.
Проверка во frontend, API Gateway или другом внешнем слое может дополнять, но не заменяет проверку в сервисе, владеющем операцией или данными.
Обоснование¶
Только владеющий ресурсом сервис располагает полным предметным контекстом и не может доверять решению контролируемого клиентом слоя.
Проверка¶
- code review handlers и use cases;
- integration-тест обхода frontend и API Gateway;
- негативный тест доступа к другому объекту и tenant.
Исключения¶
Публичная операция должна быть явно объявлена публичной в контракте API.
SEC-AUTHZ-003. Стандартный запрос авторизации¶
Уровень: MUST
Применяется к: запросу backend в Casbin
Корпоративный запрос авторизации должен содержать:
subject— стабильный идентификатор пользователя или сервиса;object— стабильный тип и идентификатор защищаемого ресурса;action— стабильное предметное действие;domain— tenant или другая область policy, если система многодоменная;- утверждённые контекстные атрибуты, необходимые модели ABAC.
Имена object и action должны описывать предметный контракт, а не HTTP route, название handler или положение кнопки. Отсутствующий обязательный атрибут не должен заменяться пустым или фиктивным значением.
Обоснование¶
Единая модель запроса отделяет policy от транспорта и внутреннего устройства сервиса.
Проверка¶
- contract-тест запроса Casbin;
- review каталога object и action;
- тест отсутствующего subject, object, action и domain.
Исключения¶
Упрощённая модель без domain допускается для системы без tenant и других
изолированных областей policy.
SEC-AUTHZ-004. Доверенный источник subject и контекста¶
Уровень: MUST
Применяется к: формированию запроса авторизации
subject должен извлекаться только из проверенного access token или доверенной
service identity. Tenant, роли и атрибуты не должны приниматься из
пользовательского payload без проверки по доверенному источнику.
Атрибут ресурса должен загружаться сервисом-владельцем либо поступать из подписанного доверенного контекста. Клиент не должен выбирать policy model, роль или domain проверки.
Обоснование¶
Casbin корректно вычисляет решение только для подлинных входных атрибутов; подмена контекста равносильна обходу policy.
Проверка¶
- data-flow review источников атрибутов;
- security-тест подмены subject, role, tenant и владельца объекта;
- integration-тест service identity.
Исключения¶
Пользовательское значение может участвовать в policy только после серверной валидации и привязки к доверенному объекту.
SEC-AUTHZ-005. Запрет по умолчанию¶
Уровень: MUST
Применяется к: Casbin model, policy и обработке ответа
Отсутствие подходящего разрешающего policy должно приводить к deny.
Неизвестный object, action, subject, domain, ошибочный ответ и невозможность
интерпретировать решение должны приводить к отказу в доступе.
Backend должен разрешать операцию только после явного положительного решения для полного запроса авторизации.
Обоснование¶
Deny-by-default предотвращает появление доступа при неполной policy, рассинхронизации версий или ошибке интеграции.
Проверка¶
- unit-тест policy effect;
- негативные contract-тесты неизвестных значений;
- тест некорректного ответа Casbin Server.
Исключения¶
Не допускаются для защищённых операций.
SEC-AUTHZ-006. Версионирование модели и policy¶
Уровень: MUST
Применяется к: Casbin model и управляемым policy
Casbin model, схема запроса, начальные policy и миграции должны версионироваться в GitLab. Развёрнутая версия модели должна однозначно сопоставляться с Git commit.
Динамические изменения ролей и policy должны выполняться только через утверждённый Management API, иметь автора, основание, время и версию. Прямое изменение хранилища Casbin Server запрещено.
Обоснование¶
Версионирование и управляемые изменения позволяют воспроизвести решение о доступе и выполнить аудит.
Проверка¶
- review файлов модели и миграций;
- сопоставление версии Casbin Server с Git commit;
- проверка запрета прямого доступа к policy storage;
- аудит вызовов Management API.
Исключения¶
Не допускаются для production policy.
SEC-AUTHZ-007. Разделение проверки и управления¶
Уровень: MUST
Применяется к: Casbin Server и его клиентам
Обычный backend должен иметь право только запрашивать решение AuthZ. Право читать полный набор policy, изменять model, роли и policy должно предоставляться отдельным административным identity по принципу минимальных привилегий.
Management API не должен быть доступен из публичной сети и пользовательского frontend.
Обоснование¶
Компрометация прикладного сервиса не должна предоставлять возможность изменить правила, по которым этот сервис получает доступ.
Проверка¶
- review service identities, scopes и network policy;
- тест запрета Management API для backend identity;
- проверка недоступности Management API извне.
Исключения¶
Сервис управления доступом может изменять policy, если это является его явно определённой ответственностью.
SEC-AUTHZ-008. Поведение при недоступности Casbin Server¶
Уровень: MUST
Применяется к: удалённой проверке AuthZ
Вызов Casbin Server должен иметь конечный timeout. Timeout, сетевая ошибка и
невалидный ответ должны приводить к отказу в защищённой операции и не должны
интерпретироваться как allow.
Проект должен определить, различает ли его внешний контракт отказ в доступе и техническую недоступность PDP, не раскрывая внутренние детали клиенту.
Обоснование¶
Fail-open превращает отказ инфраструктуры авторизации в обход контроля доступа.
Проверка¶
- integration-тест timeout, разрыва соединения и невалидного ответа;
- contract-тест внешней ошибки;
- проверка отсутствия fallback
allow.
Исключения¶
Автономный режим требует утверждённого ADR и локального Casbin enforcer с ограниченной по времени, подписанной и версионированной копией policy.
SEC-AUTHZ-009. Кэширование решений¶
Уровень: MUST
Применяется к: клиентскому cache решений Casbin
Ключ cache должен включать все входы решения: subject, object, action, domain, контекстные атрибуты и версию policy. TTL должен иметь конечное документированное значение.
Изменение критичных прав, блокировка subject и обновление policy должны
инвалидировать связанные разрешающие решения либо иметь определённое
максимальное время их действия. Решения для критичных операций не должны
использовать устаревший allow.
Обоснование¶
Неполный ключ или устаревшее разрешение предоставляет доступ другому контексту или после отзыва права.
Проверка¶
- unit-тест ключа cache;
- integration-тест обновления и отзыва policy;
- проверка TTL и поведения после смены версии policy.
Исключения¶
Проект может полностью отключить cache решений.
SEC-AUTHZ-010. Наблюдаемость решений¶
Уровень: MUST
Применяется к: каждому запросу авторизации
Backend должен регистрировать latency, технический результат обращения к PDP и
итог allow или deny без записи полного policy и чувствительных атрибутов.
Метрики должны позволять обнаруживать рост deny, ошибок и timeout.
Изменения policy и критичные решения должны создавать аудит-события по
OBS-AUD-001. Диагностические записи должны коррелироваться с текущими
trace_id и span_id по OBS-LOG-004.
Обоснование¶
Наблюдаемость позволяет отличить ожидаемый запрет от ошибки policy, SDK или Casbin Server.
Проверка¶
- integration-тест логов, метрик, трассы и аудита;
- проверка отсутствия полного policy и чувствительных атрибутов;
- тест alerts на ошибки и timeout PDP.
Исключения¶
Отдельное решение allow может не иметь диагностической записи, если
агрегированные метрики и трассировка сохраняют требуемую наблюдаемость.
SEC-AUTHZ-011. Тестирование policy¶
Уровень: MUST
Применяется к: Casbin model и каждому изменению policy
Набор тестов должен содержать разрешающие и запрещающие сценарии для каждой роли, action, типа object и domain. Должны проверяться наследование ролей, конфликтующие правила, неизвестные значения и границы tenant.
Изменение model или policy не должно публиковаться без успешного contract-теста с той версией Casbin Server и SDK, которая используется проектом.
Обоснование¶
Policy является исполняемой логикой безопасности и требует проверки позитивных и негативных решений до публикации.
Проверка¶
- таблица решений и автоматизированные policy-тесты;
- integration-тест Casbin Server и SDK;
- mutation или контролируемое изменение разрешающего policy.
Исключения¶
Не допускаются для production policy.
SEC-AUTHZ-012. Интеграция через Casbin SDK¶
Уровень: MUST
Применяется к: backend, использующему Casbin Server
Backend должен использовать официальный или утверждённый Casbin SDK, совместимый с языком проекта и версией API Casbin Server. Прикладной код не должен самостоятельно реализовывать протокол Casbin Server или вычисление Casbin policy.
Вызов SDK должен быть изолирован за локальным интерфейсом PEP, который принимает
корпоративный запрос из SEC-AUTHZ-003 и возвращает типизированный результат
allow, deny или error.
Обоснование¶
Единая интеграционная граница исключает различия транспортной реализации между
сервисами и не смешивает техническую ошибку с решением deny.
Проверка¶
- review зависимости и версии Casbin SDK;
- contract-тест локального интерфейса PEP;
- integration-тест совместимости SDK с Casbin Server;
- поиск прямых вызовов транспортного API из бизнес-кода.
Исключения¶
Отсутствие поддерживаемого SDK требует утверждённого ADR и отдельного версионируемого adapter с contract-тестами протокола.