Access Control for Media App - это кейс про построение отдельного authorization контура, где ключевые цели: predictable decision latency, explainability и безопасность по умолчанию. На интервью важно показать архитектуру PDP/PEP, стратегию revocation и контроль рисков privilege escalation.
Источник
Acing the System Design Interview
Глава 16: Design Access Control for Media App с фокусом на policy model и enforcement loop.
Где применяется этот паттерн
- Netflix / Spotify: разграничение доступа к контенту по региону, подписке и правам.
- YouTube Studio: роли для creator-команд и granular rights на действия с медиа.
- B2B media SaaS: tenant isolation и audit trail для enterprise клиентов.
- Internal platform tools: policy-driven доступ сервисов и операторов к sensitive операциям.
Функциональные требования
Core Authorization API
POST /authorize- decision allow/deny + reasonPOST /explain- объяснение применённых policy правилPOST /revoke- экстренный revoke access/token scopeGET /audit- поиск history по decision_id
Policy функции
- RBAC как baseline + ABAC/ReBAC для контекстных/графовых сценариев
- Versioned policy rollout с безопасной инвалидацией decision cache
- Deny-by-default и fail-closed для критичных media операций
- Полный audit trail: кто, что, когда и по какому правилу получил доступ
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Decision latency (p95) | < 20ms | Authorization не должен быть bottleneck API path |
| Availability | 99.99% | Падение authz контура блокирует критичные user actions |
| Revocation lag | < 5 сек | Быстрое отключение скомпрометированных прав |
| Audit integrity | Immutable log | Forensics и compliance расследования |
| Tenant isolation | Strict boundary | Защита от cross-tenant утечек и privilege escalation |
High-Level Architecture
Теория
ACL/RBAC/ABAC/ReBAC
Модели контроля доступа и их практическое применение в распределённых системах.
High-Level Architecture
PEP/PDP + policy store + audit/revocation loopСхема разделяет decision path, policy control plane и аудит/revocation контур.
Контур авторизации отделяет hot decision path от policy control plane и поддерживает explainability, auditability и быстрый revoke при компрометации аккаунтов.
Write/Read Paths
Write/Read Paths
Как policy-изменения пишутся в control plane и как читается hot decision path.
Write path: policy/revocation изменения проходят в versioned store, затем выполняется cache invalidation и публикуются audit события.
Policy Change
admin/update request
Security/admin сервис отправляет update policy, role grants, revoke-события.
Policy Store
versioned write
Изменение фиксируется как новая policy_version c валидаторами rollout-правил.
Invalidate Cache
PEP/PDP sync
Распространяется invalidation в decision cache и edge enforcement точки.
Audit Stream
immutable events
События policy update и revoke записываются в immutable audit log/SIEM.
Enforcement Ready
new rules active
PEP/PDP работают на новой версии policy и применяют обновлённые решения.
Policy Change
admin/update request
Security/admin сервис отправляет update policy, role grants, revoke-события.
Policy Store
versioned write
Изменение фиксируется как новая policy_version c валидаторами rollout-правил.
Invalidate Cache
PEP/PDP sync
Распространяется invalidation в decision cache и edge enforcement точки.
Audit Stream
immutable events
События policy update и revoke записываются в immutable audit log/SIEM.
Enforcement Ready
new rules active
PEP/PDP работают на новой версии policy и применяют обновлённые решения.
Write path checkpoints
- •Каждое изменение policy должно иметь версию и автора (auditability by default).
- •Cache invalidation обязателен до завершения rollout, иначе появляются stale allow решения.
- •Revocation должен распространяться быстро и блокировать скомпрометированные сессии.
Консистентность policy и отказоустойчивость
Глубже
Identification, Authentication, Authorization
Границы authn/authz, token lifecycle и практические security-паттерны.
Version-aware decision model
Решение должно всегда быть привязано к версии политики и контексту запроса:
decision = evaluate(subject, resource, action, context, policy_version) cache_key = request_hash + policy_version
- Policy version - защищает от stale decision cache
- Reason code - обязателен для explainability и support
- Deterministic evaluation - для воспроизводимости в audit
Safety controls
- Fail-closed: критичные операции блокируются при недоступности PDP.
- Emergency revoke: мгновенный invalidate active sessions/tokens.
- Anomaly detection: алерты на всплеск denied/allow паттернов.
- Policy rollout guards: canary и авто-rollback при росте отказов.
Риски и типовые ошибки
- Authn/Authz mix-up: размытие границ ведёт к уязвимым bypass-сценариям.
- Stale cache: долгоживущий decision cache после policy update.
- No explain path: команда поддержки не может обосновать denied решение.
- Weak revoke flow: задержка отзыва прав у скомпрометированного аккаунта.
- Unlogged decisions: отсутствие forensic trail для security-инцидентов.
Что важно проговорить на интервью
- Какая policy модель выбрана и почему для конкретного media домена (RBAC/ABAC/ReBAC mix).
- Как обеспечивается консистентность decision cache при обновлении политик.
- Как устроены fail-closed/fail-open сценарии для разных классов операций.
- Какие security SLI мониторятся: decision latency, denied spike, revocation lag, audit coverage.