Эталонная архитектура DRM и защиты контента

TL;DR

Эталонная архитектура защиты контента – это единая сквозная картина того, как стриминговая платформа удерживает премиальное видео от копирования: от момента шифрования файла до момента, когда утёкшую копию находят и удаляют. У неё одна организующая идея – граница защиты, которая отделяет секреты (ключи, сервер лицензий, модуль расшифровки внутри устройства) от всего, что идёт открыто (зашифрованные сегменты на публичной сети), – и четыре слоя вокруг неё: зашифровать видео один раз схемой cbcs из Common Encryption (ISO/IEC 23001-7), выдать каждому устройству лицензию Widevine, PlayReady или FairPlay через стандартную передачу ключей (DASH-IF CPIX), воспроизвести через браузерный Encrypted Media Extensions (W3C EME) и следить за утечками форензической меткой и антипиратскими операциями. Ошибки, которые топят реальные платформы, – архитектурные, а не криптографические: зашифровать так, что ломаются устройства Apple, дать ключу попасть в плеер, пропустить проверку прав или принять DRM за стену, а не за цикл. Эта статья собирает весь Блок 4 в один пригодный к сборке чертёж – с таблицей компонентов, числовым примером и явно нарисованной границей защиты.

Почему это важно

Каждая другая статья этого блока объясняет одну часть защиты контента; эта – там, где части становятся системой, которую можно реально построить и заложить в бюджет. Если вы основатель медиапроекта, продакт-менеджер или стриминговый инженер, который вот-вот закажет платформу с лицензионным студийным контентом или правами на live, правообладатель задаст вам точный вопрос – «покажите вашу архитектуру защиты контента», – и расплывчатый ответ проваливает сделку. Архитектура решает и реальные деньги: ошибётесь со схемой шифрования – переэнкодите весь каталог; поставите слой лицензий не туда – не масштабируетесь к премьере; пропустите метку – студия не даст вам 4K. Это и есть эталонный чертёж, который отвечает правообладателю, оценивает стоимость и показывает вашим инженерам, где именно живёт каждый секрет и какой стандарт управляет каждым переходом.

Вся картина защищённого видео в одном виде

Сначала форма, потом части. Платформа защищённого видео – это обычный стриминговый конвейер (принять источник, собрать лестницу качества, упаковать сегменты, протолкнуть через сеть доставки контента, воспроизвести) с системой защиты, вшитой в него в четырёх точках. Проще всего удержать всё в голове, проследив один видеофайл от студии до экрана и заметив, где защита к нему прикасается.

Источник приходит и кодируется в лестницу кодирования – набор версий качества от низкого к высокому битрейту, который позволяет плееру выбрать то, что вытягивает сеть, описано в Лестница кодирования: основы. Эти версии заворачиваются в небольшие сегменты в едином контейнере CMAF (ISO/IEC 23000-19), чтобы один набор файлов обслуживал любое устройство, – шаг упаковки из Упаковка: CMAF, HLS и DASH из одного мезонина. На этапе упаковки защита появляется впервые: упаковщик шифрует каждый сегмент контент-ключом, полученным от сервиса ключей. Зашифрованные сегменты ложатся на origin, расходятся по CDN и доходят до плеера полностью в открытом виде – их может скачать кто угодно, и без ключа это шум.

Ключ – это вся суть, и он доставляется отдельно. Когда плеер хочет начать, он запрашивает лицензию – короткое подписанное сообщение, несущее контент-ключ, обёрнутый так, что распаковать его может только доверенный компонент внутри именно этого устройства. Запрос идёт через браузерный стандарт EME, попадает на ворота вашей платформы для проверки прав зрителя и получает ответ от сервера лицензий DRM. Устройство расшифровывает внутри защищённого модуля, проигрывает видео и – если вы включили это – форензическая метка вшивает невидимый идентификатор зрителя в картинку, чтобы утечку позже можно было отследить. Диаграмма ниже – весь этот путь на одном холсте; каждый следующий раздел приближает одну его полосу.

Нажмите, чтобы увеличить

Одна идея, организующая всё: граница защиты

Если запомнить из этой статьи одно понятие – пусть это будет граница защиты. Это воображаемая линия, отделяющая то, что должно остаться секретным, от того, чему позволено идти открыто, и почти любое решение о защите – на самом деле вопрос о том, по какую сторону этой линии что-то находится.

Внутри границы живут секреты: контент-ключи, которые отпирают видео, сервис управления ключами, который их хранит, сервер лицензий, который раздаёт их по правилам, и – в дальнем конце – модуль расшифровки контента (CDM), доверенный кусок ПО или аппаратуры внутри устройства зрителя, единственное место, где ключ вообще распаковывается, а видео вообще расшифровывается. Снаружи границы живёт всё публичное: зашифрованные сегменты на CDN, манифест с их перечнем, интерфейс плеера и сеть между ними. Зашифрованные сегменты спроектированы свободно копироваться, потому что без ключа изнутри границы они расшифровываются в ничто.

Эта линия и делает архитектуру безопасной в эксплуатации на масштабе. Вы можете положить зашифрованный каталог на самый дешёвый и широкий CDN в мире и не переживать об утечке, потому что ценность не в сегментах – она в ключах, которые никогда не едут вместе с ними. Понимание границы заодно говорит, чего DRM не защищает, и это стоит сказать прямо, потому что это самое частое заблуждение: защита останавливает копирование и расшифровку байтов, но не камеру, наведённую на экран, – потому что как только картинка стала светом, уходящим с дисплея, она за последней точкой, до которой дотягивается граница. Этот зазор – «аналоговая дыра» – и есть причина существования меток и причина того, что честная архитектура не обещает остановить пиратство начисто. Мы вернёмся к обоим. Сначала – нарисованная граница.

Нажмите, чтобы увеличить

Слой 1 – Зашифровать один раз, и правильно

Фундамент всей архитектуры – одно правило, которое спасает от самой дорогой ошибки в области: зашифровать каталог один раз и так, чтобы его прочитало любое устройство. Ошибиться здесь – значит переэнкодить всё позже, поэтому это первое решение и самое трудно обратимое.

Стандарт, делающий «зашифровать один раз» возможным, – это Common Encryption, определённый в ISO/IEC 23001-7 и подробно разобранный в CENC, CTR и CBCS: общее шифрование. Common Encryption позволяет одному зашифрованному набору файлов отпираться любой из трёх главных систем защиты, так что вы не делаете отдельную зашифрованную копию для Google, Microsoft и Apple. Но стандарт определяет больше одного рецепта шифрования, и выбор между ними – там, где платформы спотыкаются. Третья редакция (ISO/IEC 23001-7:2023) задаёт четыре схемы; на практике ходят только две. Схема cenc использует шифр AES в режиме счётчика (AES-CTR). Схема cbcs использует AES в режиме сцепления блоков с шаблонным шифрованием – она скремблирует повторяющуюся долю каждого блока видео, а не весь блок. Они дают разные зашифрованные байты, так что устройство читает только тот рецепт, который понимает его система.

Вот правило, решающее схему: Apple FairPlay принимает только cbcs. Современные Widevine и PlayReady принимают обе. Поэтому вся индустрия сошлась на одном ответе – шифровать один раз через cbcs, упаковав в CMAF, и всё, от iPhone до телевизора Samsung и браузера Chrome, проигрывает одни и те же файлы. Выбрать старую схему cenc (AES-CTR) – классическая ошибка: она работает в ваших тестах на Android и Windows, уезжает в прод, а потом каждое устройство Apple показывает чёрный экран, потому что FairPlay не может её прочитать. Лечится это не настройкой – это переэнкод каталога. Выбирайте cbcs в первый же день.

Контент-ключ, которым пользуется упаковщик, берётся не из самого упаковщика; он запрашивается у сервиса ключей, и это подводит нас к слою, который больше всего определяет, действительно ли ваша архитектура безопасна.

Слой 2 – Управление ключами: где живут секреты

Шифрование сильно ровно настолько, насколько секретны ключи, поэтому слой управления ключами – сердце границы защиты. Его организуют два факта: ключи создаются и хранятся в одном доверенном месте и доходят до упаковщика и сервера лицензий через стандартную передачу – а не копированием вручную.

Доверенное место – это сервис управления ключами (KMS): закалённая система, единственная работа которой – генерировать, хранить и выдавать контент-ключи при строгом контроле доступа. Когда тайтл упаковывается, упаковщик не изобретает ключ; он запрашивает его у сервиса ключей. Стандарт, определяющий этот запрос – формат, в котором ключи и метаданные защиты движутся между сервисом ключей и упаковщиком, – это формат DASH-IF Content Protection Information Exchange, или CPIX. CPIX – это XML-документ, несущий контент-ключи и сигнализацию для каждой системы, которая нужна упаковщику, и он сам может быть зашифрован и подписан, так что ключи защищены и в пути. Для всех членов DASH-IF это тот самый стандарт обмена ключами между упаковщиком и DRM-решением. AWS построил поверх него широко принятый API – SPEKE (Secure Packager and Encoder Key Exchange), – который использует структуру CPIX для доставки ключей в упаковщики AWS Elemental; называть оба полезно, потому что вы встретите CPIX как концепцию и SPEKE как одну из частых реализаций.

Вторая половина управления ключами – правило, определяющее границу: контент-ключ никогда не раскрывается плееру, странице или сети в открытом виде – только доверенному модулю внутри устройства и только обёрнутым. Когда сервер лицензий отвечает на запрос, он не шлёт голый ключ. Он шлёт ключ, зашифрованный так, что распаковать его может только модуль расшифровки контента именно этого устройства, внутри своей защищённой среды, где ваш код его никогда не видит. Поэтому стриминговая платформа может быть целиком клиентской по воспроизведению и при этом оставаться безопасной: единственный важный секрет обрабатывает компонент, который вы не контролируете и не можете прочитать, – по замыслу. Архитектура, которая хоть раз логирует контент-ключ, кладёт его в манифест или прогоняет через JavaScript приложения, продырявила собственную границу, и никакая защищённость CDN это не компенсирует.

Нажмите, чтобы увеличить

Слой 3 – Слой лицензий: multi-DRM, entitlement-гейт и proxy

С зашифрованными сегментами и безопасными ключами архитектуре нужно ответить на один runtime-вопрос, который случается при каждом воспроизведении: должен ли этот зритель получить ключ прямо сейчас, и в каком виде? Это слой лицензий, и у него три части, которые новички часто сваливают в одну.

Первая часть – multi-DRM сервер лицензий, выдающий лицензии для всех трёх систем. Ни одна система защиты не покрывает все устройства – Widevine на Android и Chrome, PlayReady на Windows, Xbox и большинстве телевизоров, FairPlay на Apple, – поэтому реальная платформа должна говорить на всех трёх, реальность устройств изложена в Три системы DRM: Widevine, PlayReady, FairPlay и сшита в один процесс в Multi-DRM: один workflow, все устройства. У каждой системы свой диалект запроса – у Widevine license request, у PlayReady challenge, у FairPlay обмен SPC/CKC, – но форма одинакова: устройство просит, сервер проверяет, сервер возвращает обёрнутый ключ. Благодаря фундаменту cbcs из Слоя 1 все три обслуживаются из одних и тех же зашифрованных файлов; multi-DRM – это много лицензий, а не много энкодов.

Вторая часть – entitlement-гейт, и архитектурно это самый важный блок на всей диаграмме, потому что именно тут бизнес-правила встречаются с защитой. Работа сервера лицензий – криптографическая; работа entitlement-сервиса – ответить «можно ли этому аккаунту смотреть этот тайтл, на этом устройстве, прямо сейчас?»: не истекла ли подписка, открыто ли окно аренды, не превышен ли лимит одновременных потоков, доступен ли тайтл в этой стране? Это тот же entitlement-сервис, который управляет биллингом и доступом, описанный в Биллинг подписок и entitlement, и кардинальное правило архитектуры в том, что запрос лицензии должен пройти проверку прав ещё до того, как ключ будет выдан. Платформа, выдающая лицензии без entitlement-гейта, имеет DRM, который защищает файл от чужих, но не от собственных истёкших подписчиков.

Третья часть – license proxy: ваш тонкий сервис между плеером и сервером лицензий DRM. Плеер общается с вашим proxy; ваш proxy аутентифицирует сессию, зовёт entitlement-сервис и только тогда пересылает запрос на сервер лицензий (часто сторонний multi-DRM сервис) и ретранслирует ответ. Proxy – это то, что позволяет держать логику прав и учётные данные на вашей стороне, пользуясь управляемым сервером лицензий, и это естественное место, чтобы навесить правила из Политика лицензий: аренда, офлайн, контроль вывода и права – сколько действует ключ, разрешено ли офлайн-воспроизведение и какая защита вывода требуется.

Слой 4 – Клиент: EME, CDM и реальность уровней стойкости

Архитектура заканчивается внутри устройства зрителя, где два стандарта и один аппаратный факт решают, что реально проиграется. Этот слой основатели недооценивают, потому что тут чистая диаграмма встречается с грязной реальностью тысяч моделей устройств.

В браузере плеер достаёт систему защиты через Encrypted Media Extensions (EME), рекомендацию W3C (2017) – стандартный JavaScript-интерфейс между веб-плеером и модулем расшифровки устройства, разобранный в Encrypted Media Extensions и браузерный DRM-стек. EME сам ничего не расшифровывает; это проводка, позволяющая плееру передать зашифрованные данные и сообщения лицензий модулю расшифровки контента (CDM) – доверенному чёрному ящику (Widevine в Chrome, PlayReady в Edge, FairPlay в Safari), который и делает распаковку и расшифровку вне досягаемости вашего кода. EME работает вместе с Media Source Extensions (MSE), сопутствующим стандартом W3C, который позволяет плееру подавать адаптивные сегменты в видеоэлемент. Вместе они – причина того, что DRM-защищённый адаптивный стриминг вообще работает в браузере без плагина.

Аппаратный факт – это уровни стойкости, и он напрямую управляет качеством картинки. Каждая система защиты определяет сильный, аппаратный уровень и слабый, программный. Аппаратный уровень Widevine – L1 (расшифровка происходит внутри аппаратной доверенной среды исполнения, защищённой зоны в чипе); программный – L3. Эквиваленты PlayReady – SL3000 (аппаратный) и SL2000 (программный). FairPlay опирается на аппаратный Secure Enclave от Apple. Следствие – правило, которое удивляет каждого впервые владеющего платформой: правообладатели привязывают максимальное разрешение к уровню стойкости. Студии, лицензирующие 4K Ultra HD, обычно требуют аппаратный уровень – Widevine L1, PlayReady SL3000 или FairPlay на аппаратуре Apple – и отдельный стандарт защиты вывода, HDCP 2.2 или новее, на соединении с дисплеем. Устройство только с программным DRM (Widevine L3, PlayReady SL2000) этими же правилами обычно ограничено стандартным разрешением. Поэтому ваша архитектура должна читать уровень стойкости устройства в момент лицензии и выдавать лицензию с лимитом разрешения, соответствующим тому, что разрешил правообладатель, – entitlement-гейт и политика лицензий делают свою работу. Карта ниже – та, которую обязана удовлетворять любая платформа.

Нажмите, чтобы увеличить

Один датированный, важный нюанс уместен здесь, потому что это ровно та движущаяся часть, которую архитектура обязана планировать. В июне 2026 Microsoft выпустил PlayReady 4.8 с новым списком отзыва сертификатов устройств по новому адресу – в ответ на утечку 2025 года ключей устройств, защищающих 4K, – и поскольку клиент PlayReady вморожен в прошивку каждого телевизора на год модели, почти вся работа по миграции ложится на ваш сервер лицензий, а не на телевизоры. Полный датированный плейбук – в Миграция PlayReady на Samsung в 2026; архитектурный урок в том, что слой лицензий надо строить так, чтобы обновлять отзыв и политику без зависимости от устройств, которые вы не можете обновить.

Слой 5 – Атрибуция и операции: превратить стену в цикл

Четыре слоя выше – это стена: они удерживают честные устройства честными и не дают копировать зашифрованные байты. Но упорный нарушитель всё ещё может снять расшифрованную картинку – зазор «камера на экран», который граница не закрывает, – поэтому полная архитектура добавляет ещё два слоя, которые исходят из того, что какая-то утечка случится, и планируют её отследить и среагировать.

Первый – форензическая метка, вшивающая невидимый идентификатор зрителя в видео, чтобы утёкшую копию можно было отследить до аккаунта или сессии, из которой она вышла, объяснено в Форензические водяные знаки: отследить утечку. Она не предотвращает утечку; она делает утечку атрибутируемой, что и сдерживает инсайдеров, и удовлетворяет студии, которые требуют этого для премиального контента и раннего окна. Архитектурно она сидит на краю доставки или рядом, штампуя поток каждой сессии, и производит улики, которые потребляет финальный слой.

Второй – антипиратские операции, рабочий цикл мониторинга открытого интернета на ваш контент, извлечения метки для идентификации источника и действий по удалению или обрезанию утечки, разобранный в Антипиратские операции: мониторинг и takedown. Это слой, который переосмысляет всю архитектуру из стены в цикл: предотвращение (шифрование и DRM) и атрибуция (метка) ставятся один раз, но операции идут непрерывно – мониторинг, идентификация, решение, действие – и именно это превращает кучу технологии защиты в реальное принуждение. Честная формулировка для любого правообладателя: цикл не устраняет пиратство; он повышает цену для пирата, защищает окно высокой ценности и закрывает договорные обязательства, идущие с лицензионным каталогом.

Нажмите, чтобы увеличить

Числовой пример: цена ошибки в Слое 1 и расчёт слоя лицензий

Два числа делают архитектуру конкретной. Первое оценивает самую частую ошибку; второе считает единственный сервис, который не должен упасть во время премьеры. Пройдём оба с показанной арифметикой.

Экономия от «шифровать один раз». Допустим, у вас каталог в 10 000 часов, закодированный в лестницу из шести ступеней, и средний зашифрованный размер по лестнице выходит около 3 ГБ на час контента. Наивная вера, что «multi-DRM означает три зашифрованные копии – одну для Widevine, одну для PlayReady, одну для FairPlay», подразумевает, что вы храните три полных зашифрованных каталога:

наивно хранение = 10 000 ч × 3 ГБ/ч × 3 копии = 90 000 ГБ = 90 ТБ

Реальность, поскольку Слой 1 шифрует один раз через cbcs и все три системы лицензируют из одних файлов, – единственный зашифрованный каталог:

верно хранение  = 10 000 ч × 3 ГБ/ч × 1 копия = 30 000 ГБ = 30 ТБ
сэкономлено     = 90 ТБ − 30 ТБ = 60 ТБ хранимых, реплицируемых, раздаваемых через CDN данных

Экономия – это не только две трети хранилища; это две трети данных, которые вы толкаете на origin и платите CDN за раздачу, и каждый байт этого повторяется. Архитектурное решение в Слое 1 и создаёт экономию – а платформа, выбравшая cenc и позже обнаружившая FairPlay, и есть та, что платит за переэнкод всех 10 000 часов.

Расчёт сервера лицензий под премьеру. Слой лицензий отвечает на один запрос за одно воспроизведение, поэтому считайте его под худшую одновременность, а не под среднюю. Скажем, популярная live-премьера гонит 200 000 зрителей нажать play в окне двух минут. Каждый старт – один запрос лицензии:

запросы = 200 000 стартов ÷ 120 секунд ≈ 1 667 запросов лицензий/сек (пик)

Этот пик – а не дневной итог – и должны обслужить ваш license proxy и entitlement-сервис, не добавляя секунд к старту, потому что запрос лицензии стоит прямо на пути между нажатием play и появлением видео. Урок архитектурный: entitlement-гейт и proxy должны масштабироваться горизонтально и кэшировать решения о правах, иначе слой защиты становится тем, что портит премьеру, которую он должен был защитить. Сторона доставки того же всплеска разобрана в Доставка живых событий и всплеск премьеры; сторона защиты – это арифметика запросов лицензий.

Архитектура как таблица компонентов

У эталонной архитектуры должно быть из чего собирать, поэтому вот вся система защиты как список деталей. Последний столбец читайте первым: что стоит держать и эксплуатировать самому, а что можно спокойно купить как управляемый сервис. Паттерн по всему разделу держится – владейте частями, несущими вашу бизнес-логику и политику ваших секретов; покупайте товарную криптомашинерию.

Build vs buy слоя защиты

Последний столбец таблицы складывается в ясный дефолт. Покупайте криптомашинерию; владейте границей. Multi-DRM сервер лицензий, передача ключей CPIX/SPEKE и движок меток – товарные, критичные для безопасности и постоянно поддерживаемые против новых сертификатов и отзывов устройств; строить их самому – значит переизобретать работу профильных вендоров и брать на себя ответственность, когда утечка ключей устройства (как утечка ключей PlayReady в 2025) заставляет срочно реагировать. Напротив, license proxy, entitlement-сервис и политика, привязывающая разрешение к уровню стойкости, – это ваша бизнес-логика и правила ваших секретов; они должны жить на вашей стороне границы, потому что кодируют, кому что можно смотреть, и ни один вендор не возьмёт это на себя за вас. Прагматичная архитектура почти для любой платформы – управляемый multi-DRM сервис как сервер лицензий и хранилище ключей, обёрнутый вашим собственным proxy и entitlement-гейтом, с меткой, добавляемой, когда её требует правообладатель. Полное рассуждение, применённое ко всей платформе, а не только к защите, – в Build, buy или собрать: OTT build-vs-buy.

Частые ошибки

Провалы в защищённом видео почти никогда не сломанная криптография; они архитектурные, и каждый отображается в слой выше.

• Шифровать через cenc вместо cbcs. Проходит тесты на Android и Windows, потом каждое устройство Apple показывает чёрный экран, потому что FairPlay читает только cbcs. Лечится переэнкодом каталога – выбирайте cbcs в день один.
• Дать ключу попасть в плеер. Логировать контент-ключ, класть его в манифест или прогонять через JavaScript страницы – пробить границу защиты. Ключи идут только в модуль расшифровки устройства, обёрнутыми.
• Выдавать лицензии без entitlement-гейта. Тогда DRM защищает файл от чужих, но не от ваших же истёкших, превысивших лимит или вне-региона аккаунтов. Запрос лицензии должен сначала пройти проверку прав.
• Игнорировать уровни стойкости. Обещать 4K устройству с только-программным DRM – провалить студийное правило стойкости; лицензия должна читать уровень и ограничивать разрешение, с HDCP 2.2+ для премиума.
• Принять DRM за всю стратегию. Шифрование останавливает копирование байтов, а не камеру на экране. Премиальным и live-каталогам нужны метка и цикл операций, а не более высокая стена.
• Строить то, что надо купить. Самописный multi-DRM сервер лицензий означает вечно владеть чехардой сертификатов и отзывов устройств (например, PlayReady 4.8, 2026). Покупайте машинерию; владейте границей.

Где здесь Фора Софт

Это нужнее всего платформам с лицензионным студийным каталогом или live-правами на большую многоэкранную аудиторию, где архитектура защиты обязана удовлетворить требования стойкости правообладателя и масштабироваться к премьере, не добавляя секунд к старту. Фора Софт с 2005 года строит видеостриминг, OTT и Internet-TV, live-события, видеоконференции, e-learning, телемедицину и видеонаблюдение – более 250 проектов для 400+ клиентов за 20+ лет – и инженерия, которая тут важна, – это интеграция: выбрать cbcs/CMAF, чтобы один энкод обслуживал любое устройство, вшить передачу ключей CPIX/SPEKE в упаковщик, построить license proxy и entitlement-гейт, которые держат вашу логику доступа и политику секретов на вашей стороне границы, читать уровни стойкости устройств, чтобы привязать разрешение к правилам студии, и замкнуть цикл меткой и антипиратской операцией. Мы нейтральны к вендору в выборе multi-DRM, KMS или сервиса меток; результат – архитектура защиты контента, которая отвечает требованиям правообладателя и которую ваши платящие зрители никогда не чувствуют.

Ключевые выводы

• Граница защиты – секреты внутри, зашифрованные сегменты снаружи – единственная идея, организующая архитектуру.
• Шифруйте один раз через cbcs CENC (ISO/IEC 23001-7); выбор cenc ломает FairPlay и вынуждает переэнкод.
• Ключи движутся дважды: в упаковщик через CPIX/SPEKE и в CDM устройства обёрнутыми – никогда в плеер.
• Не сервер лицензий, а entitlement-гейт – самый важный блок; проверяйте права до выдачи ключа.
• Уровень стойкости задаёт разрешение: аппаратный DRM плюс HDCP 2.2+ для 4K, программный – потолок SD.
• Для премиум/live добавьте метку и цикл операций – защита это цикл, а не стена.

Что почитать дальше

• Multi-DRM: один workflow, все устройства – слой лицензий во всех деталях.
• CENC, CTR и CBCS: общее шифрование – фундамент «шифровать один раз».
• Эталонная архитектура OTT: полная картина – защита внутри всей платформы.