Контроль доступа в медиасервисе начинается не с проверки токена, а с ответа на вопрос, можно ли этому пользователю открыть конкретный объект здесь и сейчас: с его подпиской, регионом, устройством и ролью.
Глава разбирает, как хранить и вычислять права, как связывать политику с краткоживущими ссылками и кэшами, и как отзывать доступ без длинного окна некорректных решений.
В интервью и инженерных обсуждениях этот кейс полезен тем, что быстро выводит разговор на границы PDP и PEP, задержку на горячем пути и то, как система объясняет и журналирует каждое решение.
Права доступа
Главный вопрос здесь не в токене как таковом, а в том, как быстро и однозначно вычислить право пользователя на конкретный объект с учётом подписки, региона и роли.
Версии политик
Политики меняются чаще, чем кажется, поэтому система должна уметь выпускать новые правила без длинного окна устаревших решений в кэше.
Отзыв прав
Скомпрометированный доступ нельзя отключать вручную по одному узлу: нужен короткий и надёжный путь распространения отзыва по всему контуру.
Журнал аудита
Для поддержки, расследований и соответствия требованиям важно уметь восстановить не только итоговое решение, но и правило, версию политики и контекст запроса.
Контроль доступа в медиасервисе - это задача про отдельный контур принятия решений, который должен быстро проверять , сохранять вердикта и удерживать предсказуемую на горячем пути чтения. На интервью важно показать, как разделены роли PDP и PEP, как распространяется отзыв прав и как система избегает ошибочных решений при всплесках нагрузки и сбоях.
Источник
Acing the System Design Interview
Глава 16: Design Access Control for Media App с фокусом на модели правил, точках применения и надёжности контура доступа.
Где этот паттерн критичен
- Netflix / Spotify: разграничение доступа к контенту по региону, подписке и правам.
- YouTube Studio: роли для команд авторов и разные права на публикацию, удаление и управление медиаматериалами.
- B2B media SaaS: и для корпоративных клиентов.
- Внутренние платформенные инструменты: доступ операторов и сервисов к чувствительным операциям по явно заданным правилам.
Функциональные требования
Основной API контроля доступа
POST /authorize- решение о доступе и код причиныPOST /explain- объяснение применённых правилPOST /revoke- срочный отзыв прав или области токенаGET /audit- поиск истории поdecision_id
Функции политик и правил
- RBAC как базовый слой, ABAC и ReBAC - для контекста запроса и графа владения
- Версионирование политик и безопасный выпуск изменений
- Запрет по умолчанию для чувствительных операций
- Полная история: кто, что, когда и по какому правилу получил доступ
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Задержка принятия решения (p95) | < 20ms | Проверка доступа не должна становиться узким местом API |
| Доступность | 99.99% | Сбой контура доступа блокирует критичные пользовательские действия |
| Задержка отзыва прав | < 5 сек | Быстрое отключение скомпрометированного доступа |
| Целостность журнала аудита | Неизменяемый журнал | Разбор инцидентов и регуляторные проверки |
| Изоляция арендаторов | Жёсткая граница | Защита от межарендаторных утечек и неверного наследования прав |
Основной компромисс здесь - удерживать пользовательскую задержку низкой, но не допускать окон, в которых система продолжает опираться на устаревшие правила доступа.
Архитектура высокого уровня
Теория
ACL/RBAC/ABAC/ReBAC
Модели контроля доступа и их практическое применение в распределённых системах.
Архитектура высокого уровня
контур принятия решения, политики, атрибуты, аудит и отзыв правСхема отделяет контур принятия решения от обновления политик и контура аудита и отзыва прав.
Контур контроля доступа отделяет путь принятия решения от , где живут публикация политик, версии правил и служебные операции. В медиасценариях система часто дополнительно выдаёт для краткоживущего доступа к объекту, но корректность такого доступа всё равно зависит от точной и синхронизации между PDP и PEP.
Путь записи и путь чтения
Путь записи и путь чтения
Как обновления правил попадают в контур управления и как обслуживается горячий путь принятия решения.
Изменения политик и сигналы отзыва прав записываются в версионированное хранилище, после чего система синхронизирует кэш решений и фиксирует события в журнале аудита.
Изменение политики
Этап 1запрос от администратора
Сервис безопасности или администратор меняет роли, правила доступа и события отзыва.
Хранилище политик
Этап 2версионированная запись
Изменение фиксируется как новая версия политики и проходит проверки перед выпуском.
Инвалидация кэша
Этап 3синхронизация PEP и PDP
Система сбрасывает устаревшие решения в кэше и обновляет точки применения правил.
Поток аудита
Этап 4неизменяемые события
События обновления и отзыва записываются в журнал аудита и попадают в SIEM.
Новые правила активны
Этап 5готово к применению
PEP и PDP работают на новой версии политики и принимают решения по обновлённым правилам.
Ключевые точки пути записи
- •Каждое изменение политики должно иметь версию и автора.
- •Кэш решений нужно синхронно инвалидировать до завершения выпуска новых правил.
- •Отзыв прав должен быстро доходить до активных сессий и edge-точек.
Согласованность политик и отказоустойчивость
Глубже
Identification, Authentication, Authorization
Границы между аутентификацией и авторизацией, жизненный цикл токенов и практические паттерны безопасности.
Самая неприятная ошибка здесь - разрешить доступ после того, как право уже должно быть отключено. Поэтому система обязана быстро распространять , явно различать режимы и , а изменения правил выпускать через .
Модель решений с учётом версии
Решение должно всегда быть привязано к версии политики и контексту запроса:
decision = evaluate(subject, resource, action, context, policy_version) cache_key = request_hash + policy_version
- Версия политики - защищает кэш решений от устаревания.
- Код причины - нужен, чтобы поддержка и расследования понимали, почему доступ был выдан или отклонён.
- Детерминированная проверка - позволяет воспроизводить решение в расследованиях и разборе инцидентов.
Защитные механизмы
- Блокировка критичных операций: при недоступности PDP чувствительные действия не должны проходить по инерции.
- Экстренный отзыв прав: активные сессии и токены нужно отключать без длинного окна рассинхронизации.
- Поиск аномалий: всплески отказов и необычные шаблоны доступа должны быстро попадать в алерты.
- Защита выпуска правил: канареечный запуск и автоматический откат нужны, чтобы новая политика не ломала выдачу доступа.
Риски и типовые ошибки
- Смешение аутентификации и авторизации: размытые границы быстро приводят к обходу проверок.
- Устаревший кэш решений: после обновления правил система продолжает жить на старых вердиктах.
- Необъяснимые отказы: команда поддержки не может быстро показать, почему доступ был запрещён.
- Медленный отзыв прав: у скомпрометированного аккаунта остаётся слишком длинное окно доступа.
- Скрытая проблема в модели прав: возникает из-за неверной комбинации ролей, арендаторов и контекстных правил.
Что важно проговорить на интервью
- Почему для этого домена выбран именно такой набор RBAC, ABAC и ReBAC.
- Как система избавляется от устаревших решений после изменения политик.
- Где допустим более мягкий режим отказа, а где доступ нужно блокировать немедленно.
- Какие показатели и журналы помогают объяснить отказ и расследовать инцидент.
Связанные главы
- Identification, authentication, authorization - Границы между аутентификацией и авторизацией, жизненный цикл токенов и базовые практики identity-контура.
- ACL/RBAC/ABAC/ReBAC - Как выбирать модель контроля доступа для ролей, контекста запроса и графа владения.
- API Security Patterns - Применение правил на уровне шлюза и сервисов, защита API-поверхности и снижение риска обхода проверок.
- Zero Trust - Подход минимальных полномочий, постоянная проверка контекста и сегментация доверия в распределённых системах.
- SRE Book - Надёжность, защитные ограничения и операционные практики для критичных сервисов контроля доступа.
- Payment System - Параллели по журналу аудита, безопасному поведению при сбоях и отзыву чувствительных прав.