Видеоуроки тренера скачали и перепродали: своя площадка с контролем доступа

MAATRIX

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

Почему видео с файлообменника обязательно скачают и перепродадут

Типичная схема продажи курса выглядит так: клиент платит, вы вручную или через бота отправляете ссылку на облачное хранилище или файлообменник, ссылка открывает страницу с кнопкой «Скачать». Дальше происходит ровно то, для чего эта кнопка и создана — файл скачивается на диск. С этого момента у вас нет вообще никакого контроля: файл можно залить на торрент-трекер, выложить в закрытый Telegram-канал за донат, продать через доску объявлений дешевле вашей цены — просто потому что у продавца нет затрат на производство, только на хостинг файла.

Проблема не в конкретном сервисе, которым вы пользуетесь. Проблема в самой модели «ссылка = файл». Даже если сервис требует авторизации для просмотра страницы, сама кнопка скачивания отдаёт статичный файл, который дальше живёт без какой-либо связи с вашей системой продаж. Вы можете закрыть одну расшаренную ссылку — но копия уже скачана, и закрытие ссылки на оригинал никак не остановит её дальнейшее распространение.

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

Что реально меняет собственный сервер

Смысл переноса курса на свою инфраструктуру не в том, чтобы сделать пиратство невозможным — это нереалистичное обещание, которое не выполняет никто на рынке. Смысл в том, чтобы поднять порог усилий с «один клик — скачал файл» до «нужно осознанно записывать видеопоток», и одновременно вернуть себе рычаги: возможность увидеть, кто и как смотрит уроки, отозвать доступ у конкретного человека, не трогая остальных, и не зависеть от политики стороннего сервиса, который в любой момент может поменять правила хранения или тарифы.

На практике это означает три вещи одновременно:

• Видео отдаётся потоком (streaming), а не файлом. Плеер на странице курса запрашивает у сервера кусочки видео по мере просмотра — как это делает YouTube или Netflix, — а не единый файл, который можно сохранить одним кликом.
• Каждый запрос куска видео проверяется. Сервер сверяет, что у того, кто запрашивает поток, есть действующий доступ — активная подписка, оплаченный курс, не истёкшая ссылка.
• Доступ привязан к аккаунту клиента, а не к анонимной ссылке. Вы в любой момент видите список тех, кому выдан доступ, и можете отозвать его у одного человека без последствий для остальных.

Ниже — как каждый из этих пунктов выглядит технически, без магии и без обещаний стопроцентной защиты.

Потоковая выдача без скачиваемой ссылки: как это устроено

Базовый строительный блок — формат HLS (HTTP Live Streaming): видео нарезается на короткие сегменты по несколько секунд, плеер в браузере (обычно через библиотеку hls.js или встроенную поддержку в Safari) подгружает их один за другим и играет как непрерывный поток. У зрителя в браузере нет момента, когда весь ролик целиком лежит в одном файле — только текущие несколько сегментов в буфере.

Нарезка исходника на сегменты делается ffmpeg:

ffmpeg -i urok-01.mp4 \
  -codec: copy \
  -start_number 0 \
  -hls_time 6 \
  -hls_list_size 0 \
  -f hls urok-01/playlist.m3u8

Получаете плейлист playlist.m3u8 и набор сегментов .ts. Сама по себе нарезка на HLS уже неудобна для «скачал и пересобрал файл» — понадобится специальный инструмент, который склеит сегменты обратно, а не штатная кнопка браузера «Сохранить видео». Но это ещё не контроль доступа — плейлист и сегменты в такой конфигурации отдаются как обычные статичные файлы, и если ссылка на них известна, её можно передать кому угодно.

Контроль доступа добавляется на уровне веб-сервера, который отдаёт эти сегменты. Рабочий вариант — модуль secure_link в nginx: он генерирует для каждой ссылки подпись с ограниченным временем жизни, и без правильной подписи сервер отвечает 403.

location /hls/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri секретная-строка";

    if ($secure_link = "") { return 403; }
    if ($secure_link = "0") { return 410; }

    root /var/www/video;
}

Ваш бэкенд при открытии страницы урока сам вычисляет md5 и expires и вставляет их в ссылку на плейлист — например, со сроком жизни 15-30 минут. Через полчаса ссылка на сегменты перестаёт работать, даже если её кто-то успел скопировать и переслать: пересланная ссылка просто отдаст 403 у получателя, если он откроет её позже окна действия подписи.

Альтернатива тому же принципу — раздача из S3-совместимого хранилища (например, MinIO) через presigned URL с коротким TTL: бэкенд запрашивает у хранилища временную подписанную ссылку на объект, отдаёт её плееру, а через несколько минут ссылка протухает. Разница с nginx secure_link в основном в том, где живёт логика подписи — в вашем веб-сервере или в хранилище; для небольшого курса проще нанести на nginx, для растущего каталога уроков удобнее выделенное хранилище. Если решите собирать связку на MinIO, у нас есть отдельный разбор установки MinIO на VPS.

Привязка доступа к оплате: кто и на каком устройстве смотрит

Потоковая выдача с подписанными ссылками закрывает вопрос «файл нельзя просто скачать». Отдельная задача — не выдавать подписанную ссылку тому, кто не платил. Здесь нужен слой аутентификации между клиентом и генерацией ссылки на HLS-плейлист.

Практическая схема для небольшой школы или курса на одного тренера:

1. Клиент регистрируется и оплачивает курс — платёж проходит через вашу систему (эквайринг, приём криптовалюты или ручное подтверждение), после оплаты создаётся запись «доступ к курсу X открыт для пользователя Y».
2. При входе в личный кабинет клиент получает сессионный токен (JWT или обычная серверная сессия — для небольшого проекта хватает второго, без лишней сложности).
3. При открытии страницы конкретного урока бэкенд проверяет, есть ли у пользователя из сессии активный доступ к этому курсу, и только после этого генерирует подписанную ссылку на плейлист урока с TTL в 15-30 минут.
4. Каждое повторное открытие урока — это новый запрос к бэкенду и новая проверка, а не переиспользование старой ссылки.

Проверка на бэкенде на псевдокоде (логика одинаковая что на PHP, что на Node.js, что на Python):

def get_lesson_url(user, lesson_id):
    if not user.has_access(lesson_id.course_id):
        raise Forbidden("Нет доступа к курсу")
    expires = int(time.time()) + 900  # 15 минут
    signature = md5(f"{expires}{lesson_id.path}{SECRET}".encode()).hexdigest()
    return f"/hls/{lesson_id.path}/playlist.m3u8?md5={signature}&expires={expires}"

Это уже даёт вам то, чего в принципе не может дать анонимная ссылка на файлообменник: список конкретных людей с доступом, возможность отозвать доступ у одного клиента (истёк платёж, оспорен возврат, замечена подозрительная активность) без последствий для остальных, и журнал того, кто и когда запрашивал уроки — при желании его можно вести в обычной таблице событий в базе.

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

Что такое контроль, а что — иллюзия защиты

Здесь важно быть честным с самим собой, потому что легко потратить недели на технические меры, которые дают ложное чувство безопасности.

Что действительно работает:

• Подписанные ссылки с коротким TTL убирают самый массовый канал утечки — пересылку прямой ссылки на скачивание.
• Привязка к аккаунту с возможностью отзыва решает проблему «один клиент расшарил доступ на весь курс сразу нескольким людям» — вы можете это заметить (например, по одновременным запросам с разных IP-адресов с одного аккаунта) и отреагировать точечно.
• Ограничение числа одновременных активных сессий на аккаунт — рабочая практика: если с одного логина одновременно смотрят с трёх разных IP, это повод разобраться, а не автоматически банить (у клиента может быть телефон и ноутбук одновременно).

Что не работает как «защита», хотя часто продаётся именно так:

• Водяной знак с именем/email клиента на видео не мешает скачать и распространить файл, но делает распространение прослеживаемым и репутационно неудобным для нарушителя — это скорее сдерживающий фактор, чем барьер.
• Запрет правой кнопки мыши и «защита от копирования» в браузере — это удобство для случайного пользователя, а не барьер: любой, кто хочет записать видеопоток целиком, сделает это средствами записи экрана в обход любых JS-ограничений.
• Полноценный DRM (Widevine/FairPlay с аппаратным ограничением воспроизведения) в теории закрывает и запись экрана на некоторых устройствах, но это тяжёлая и дорогая инфраструктура с лицензированием у поставщиков DRM — для курса на одного тренера это почти всегда несоразмерные усилия по сравнению с выгодой; сегмент рынка, где это оправдано, — это студии с большими бюджетами и потоковые сервисы, а не индивидуальный тренер.

Разумная цель — не «никто никогда не украдёт видео», а «случайная утечка через пересланную ссылку исключена, а осознанная кража требует от нарушителя заметных усилий и оставляет следы». Это честная и достижимая планка.

Сколько это стоит и что нужно из железа

Для курса на условные 20-50 уроков с несколькими сотнями активных клиентов одновременно вам не нужен отдельный дата-центр — обычный VPS с nginx и приличным каналом закрывает задачу, если видео не в 4K и одновременных зрителей немного. Если аудитория растёт и уроков становится действительно много, разумно развести роли: одна машина отдаёт HLS-сегменты и держит нагрузку от плеера, вторая — бэкенд с личным кабинетом, оплатой и логикой доступа, третья (или отдельное хранилище) — исходники и архив видео до нарезки.

Ключевое отличие такой схемы от аренды готовой площадки для курсов — вы платите за вычислительные ресурсы и трафик, а не за количество активных учеников или объём хранилища по тарифной сетке стороннего сервиса. При росте курса стоимость растёт вместе с реальным потреблением ресурсов, а не скачками по тарифным планам поставщика. Точную цифру трафика на конкретный курс заранее не даст никто — она зависит от длины уроков, качества видео и числа одновременных зрителей, поэтому первый месяц лучше отслеживать реальное потребление и подбирать конфигурацию по факту, а не по прикидке на бумаге.

Если параллельно с видео вы проводите живые созвоны или разборы с группой, для этого пригодится собственный сервер видеосвязи — мы отдельно писали про настройку сервера под стриминговую платформу и про то, во сколько обходится собственный видеохостинг в разных сценариях нагрузки — эти цифры зависят от конкретного объёма контента и трафика, поэтому там речь именно об ориентирах, а не о готовом прайсе.

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

Частые вопросы