Наследование прав и политик

1) Зачем экосистеме наследование

• Скорость масштабирования: новые узлы/продукты получают стандартизованные политики «из коробки».
• Единообразие и комплаенс: верхнеуровневые guardrails автоматически действуют на дочерние ресурсы.
• Прозрачность и аудит: предсказуемый порядок применения, минимизация исключений.

2) Базовая онтология доступа

2.1 Иерархические уровни

1. Организация/Экосистема → глобальные политики безопасности/данных/RG.
2. Тенант/Партнер → квоты, юрисдикции, границы данных, SLO-ограничения.
3. Домен (контент, платежи, KYC, аффилиаты, аналитика, события) → профиль доступа и сетевые периметры.
4. Сервис/Приложение → API/топики/хранилища.
5. Ресурс → таблица/топик/эндпоинт/секрет/стрим.

2.2 Модели авторизации

RBAC (роли): быстро, прозрачно, хорошо наследуется (роль → набор разрешений).
ABAC (атрибуты): гибкость (гео, юрисдикция, риск-скор, время).
ReBAC (отношения): доступ «к ресурсам, связанным с моими сущностями» (оператор ↔ кампания ↔ данные).
Практика: гибрид RBAC+ABAC, ReBAC — для графов владения/кампаний.

3) Политики, скоупы и приоритеты

3.1 Типы политик

Allow/Deny: явное разрешение/запрет.
Guardrails: обязательные ограничения (PII out-of-scope, лимиты экспорта, time-based).
Quotas/Rate: лимиты rps/txn/stream/event по тенанту/каналу/региону.
Contextual: условия по гео/ASN/устройству/времени/верификации/риск-скорингу.
Delegation: делегирование части прав со стесненным скоупом/TTL.

3.2 Наследование и порядок применения

Deny-first: запрет сильнее разрешения.
Precedence: `Guardrails (root) > Deny (parent) > Allow (parent) > Deny (child) > Allow (child)`.
Shadowing: дочерний Allow не отменяет родительский Guardrail/Deny.
Override по исключениям: только письменно оформленные «justified exceptions» с TTL и автоснятием.

3.3 Скоупы

Org/Tenant: глобальные правила и квоты.
Environment: prod/stage/sandbox — жесткость растет к prod.
Jurisdiction: локализация данных, RG-ограничения.
Data Class: `Public/Internal/Confidential/PII-Sensitive/Financial`.
Operation: read/write/admin/export/impersonate.

4) Деревья политик (Policy Trees)

4.1 Структура

/org
/tenants/{tenantId}
/domains/{payments    kyc    content    affiliates    analytics    events}
/services/{api    broker    db    storage    sfu}
/resources/{endpoint    topic    table    bucket    secret}

На каждом узле: список политик (allow/deny/guardrail/quota/context). Наследование сверху вниз, локальные политики добавляют ограничения, но не снимают глобальные запреты.

4.2 Примеры

Guardrail org-level: «PII нельзя выводить в вебхуки за пределы белого списка стран».
Tenant-level: «KYC-операторы из стран X запрещены; экспорт отчетов только агрегаты».
Domain payments: «Write только через сервис-аккаунт с mTLS и ключом ≤ 24ч».
Service api: «POST /deposits только с `Idempotency-Key`».
Resource topic: «Чтение `kyc_status` только службам с ролью `KYC.moderation` и ABAC `verified=true`».

5) Делегирование и временные права

Just-in-Time (JIT) Access: выдача на время выполнения (TTL, single-use).
Break-Glass: экстренный доступ с немедленным аудитом и последующим разбором.
Scoped Tokens: минимальный набор `scopes` (read:topic/kyc; write:api/deposit) + audience/issuer.
Chain-of-Trust: межсервисные токены с привязкой к устройству/ASN/подсети.
Impersonation: только через прокси-сервис с журналом и лимитами.

6) Наследование в доменах

6.1 Платежи (PSP/APM)

Родительский guardrail: «все вызовы — через mTLS + JWS, таймаут ≤ N, ретраи с джиттером; чарджбек-хук обязательный».
Дочерний сервис может добавлять квоты/капсы на APM/регион. Deny на прямые вызовы в обход оркестратора.

6.2 KYC/AML

Родительский Deny: «сырой документ нельзя писать в аналитику».
Дочерний Allow: «передавать только hash/вердикт/категории риска».

6.3 Контент/стриминг

Org guardrail: «минимальный битрейт и latency-SLO».
Tenant-override: «снижение качества в роуминге, но не ниже SLO».
Resource: доступ к конкретному live-столу — только сегментам с RG-OK.

6.4 События/EDA

Root: схемы/версии in-registry, exactly-once по бизнес-смыслу.
Domain: ключи партиций, дедуп-политика.
Service: кто может писать/читать топик; quotas/lag-budget.

7) Приватность и Zero Trust

PII-минимизация и токенизация по умолчанию, политика «нельзя де-токенизировать вне сейф-зон».
Сегментация сетей: vendor-VPC, egress-allow-list, межзонные политики меша.
mTLS/JWS/HMAC для S2S и вебхуков, короткоживущие ключи (JWKS/rotation).
SoD (Segregation of Duties): роли чтения ≠ роли администрирования ≠ роли выпуска ключей.
Юрисдикции: наследуемые правила локализации, запрет трансграничного экспорта ПДн без DPA/DPIA.

8) Наблюдаемость и аудит наследования

Policy Evaluation Trace: журнал «какая политика где сработала» с `traceId`.
Diff-лог: кто/когда изменил дерево политик; WORM-хранилище.
Conformance-тесты: регулярные прогоны сценариев доступа (allow/deny; export; impersonation).
Алерты: срабатывания deny/guardrail, превышение квот, попытки обхода.

9) Конфликты и их разрешение

Определить класс: коллизия Allow/Deny, нарушение guardrail, пересечение ABAC-условий.
Применить порядок precedence (см. §3.2).
Классифицировать исключение: временное (TTL), постоянное (правило), ошибочное (rollback).
Внести артефакты: RFC/CR-заявка, ссылка на риск-оценку, автопроверки в CI.

10) Анти-паттерны

Ручные выданные права без TTL («навсегда»).
Allow-по-умолчанию и «молчаливые» исключения.
Наследование без видимых guardrails — дочерние ветки перекрывают безопасные правила.
Смешение ролей (админ=аналитик=оператор) — нет SoD.
Экспорт сырых ПДн в сторонние сервисы, «временные» вебхуки без подписи.
Отключенный аудит при break-glass.
Плавающие версии схем: разъезжается аналитика/EDA, deny не срабатывает на новые поля.

11) Чек-лист проектирования дерева политик

1. Классифицируйте данные (Public/Internal/Confidential/PII/Financial).
2. Определите уровни иерархии и владельцев узлов (RACI).
3. Задайте guardrails на корне (Zero Trust, PII, RG, юрисдикции).
4. Сформируйте роли RBAC и атрибуты ABAC; включите SoD.
5. Опишите скоупы (org/tenant/env/jurisdiction/data class/operation).
6. Включите делегирование/TTL и break-glass с аудиторским шлейфом.
7. Пропишите precedence и конфликтологию (deny-first, override-процесс).
8. Настройте наблюдаемость: evaluation-trace, diff-лог, алерты.
9. Запустите conformance-набор и регулярные ревью исключений.
10. Документируйте: портал политик, примеры, песочницы, симуляторы.

12) Метрики зрелости

Coverage: доля ресурсов, покрытых наследуемыми политиками и конформанс-тестами.
Drift: число локальных исключений/100 ресурсов; средний TTL исключения.
SoD Score: доля пользователей с разделением обязанностей.
PII Exposure: число экспортов за пределы сейф-зон (целевое = 0).
Auditability: % запросов с evaluation-trace; MTTR по конфликтам доступа.
Change Velocity: время CR по политике с учетом наследования.

13) Примеры шаблонов (схематично)

• Deny: `export:PII` if `destination.country ∉ whitelist`
• Require: `mTLS && JWS` for `webhook:`
• Quota: `read:event: ≤ X rps per tenant`

• Allow: `write:api/deposit` if `verified && risk_score < T && geo ∈ allowed`
• Deny: `direct:psp/`

• Allow: `read` for role `KYC.moderation` where `jurisdiction == resource.jurisdiction`
• Deny: `write` except service `kyc-orchestrator`

14) Дорожная карта эволюции

v1 (Foundation): дерево политик, guardrails на корне, RBAC, deny-first, аудит изменений.
v2 (Integration): ABAC, делегирование/TTL, conformance-набор, evaluation-trace.
v3 (Automation): авто-скоупинг по юрисдикции/данным, policy-as-code, автопроверки в CI/CD, автокарантин нарушений.
v4 (Networked Governance): межпартнерская федерация политик, кросс-тенант делегирование с криптоподписью, предиктивные подсказки (риск-скор) для выдачи прав.

Краткое резюме

Наследование прав и политик — это каркас безопасной и быстрой экосистемы. Постройте policy-tree с guardrails на корне, применяйте deny-first и precedence, комбинируйте RBAC+ABAC+ReBAC, используйте делегирование с TTL и строгий аудит. Автоматизируйте проверки и управление исключениями — и у вас получится масштабируемая, комплаентная и предсказуемая модель доступа для всей сети участников.