Tutorial completo: como proteger vídeos autorais com DRM e dificultar pirataria em uma plataforma

Autor/compilação: Pablo Murad — 2026
Objetivo: explicar, de forma prática e educativa, como proteger cursos em vídeo autorais usando DRM, criptografia, controle de acesso, marca d'água e boas práticas operacionais.

1. Verdade dura: DRM não impede 100% da pirataria

Antes de falar de ferramenta, é preciso corrigir uma expectativa comum: não existe vídeo online impossível de piratear.

Se o aluno consegue assistir, em algum momento o conteúdo precisa ser decodificado no dispositivo dele. Um invasor muito determinado pode tentar capturar tela, gravar HDMI, usar dispositivo comprometido, câmera externa, navegador modificado ou contas laranja.

O objetivo real não é “tornar impossível”. O objetivo real é:

1. Impedir download direto do arquivo original.
2. Evitar que links de vídeo sejam compartilhados livremente.
3. Criptografar os segmentos do vídeo.
4. Entregar chaves de reprodução apenas para usuários autorizados.
5. Amarrar sessão, usuário, curso, dispositivo e validade.
6. Aplicar marca d'água visível e/ou invisível.
7. Detectar vazamentos e identificar a origem provável.
8. Reduzir drasticamente a escala da pirataria casual.

DRM bom não é uma parede mágica. É uma cerca elétrica, câmera, controle de portão, registro de entrada e equipe olhando o monitor.

2. Conceitos básicos

2.1 O que é DRM?

DRM significa Digital Rights Management, ou gerenciamento de direitos digitais. No contexto de vídeo, DRM é um conjunto de tecnologias para:

• criptografar o conteúdo;
• controlar quem pode assistir;
• definir regras de reprodução;
• limitar dispositivos;
• impedir ou dificultar downloads simples;
• restringir saída de vídeo em alguns cenários;
• exigir uma licença temporária para cada reprodução.

Os três sistemas mais relevantes no mercado são:

Na prática, uma plataforma séria costuma usar multi-DRM, ou seja, Widevine + FairPlay + PlayReady, dependendo do navegador/dispositivo do aluno.

2.2 DRM é diferente de link privado

Muita gente confunde:

• link privado;
• token temporário;
• URL assinada;
• vídeo “não listado”;
• bloqueio por login;
• DRM real.

Essas coisas ajudam, mas não são DRM completo.

Um vídeo protegido apenas por URL assinada pode impedir acesso público, mas se o arquivo .mp4 ou o manifesto HLS/DASH for obtido dentro da validade, ainda pode ser baixado ou copiado com ferramentas simples, dependendo da configuração.

DRM real envolve criptografia do conteúdo + licença + CDM do navegador/dispositivo.

2.3 DRM não substitui autenticação

DRM não sabe, sozinho, se o usuário pagou o curso. Quem sabe isso é a sua plataforma.

Fluxo correto:

1. Usuário faz login.
2. Plataforma verifica se ele comprou ou tem acesso ao curso.
3. Plataforma gera uma sessão de playback.
4. Player pede manifesto de vídeo.
5. Player pede licença DRM.
6. Backend valida novamente usuário, curso, sessão e dispositivo.
7. Servidor de licença libera a chave apenas se tudo estiver correto.

3. Arquitetura recomendada

Uma arquitetura robusta de proteção de vídeo possui estes componentes:

Upload do vídeo original
        ↓
Armazenamento privado do master
        ↓
Transcodificação em múltiplas qualidades
        ↓
Empacotamento HLS/DASH
        ↓
Criptografia DRM
        ↓
Armazenamento dos segmentos criptografados
        ↓
CDN com acesso controlado
        ↓
Player web/mobile com suporte a DRM
        ↓
Backend da plataforma valida aluno e gera token
        ↓
Servidor multi-DRM entrega licença temporária
        ↓
Aluno assiste
        ↓
Logs, marca d'água, detecção de abuso e revogação

Componentes necessários

4. Níveis de proteção possíveis

Nem toda plataforma precisa começar com a arquitetura mais cara. Dá para evoluir por camadas.

Nível 0 — errado: vídeo MP4 público

Exemplo ruim:

<video src="https://cdn.exemplo.com/aula1.mp4" controls></video>

Problemas:

• qualquer pessoa pode inspecionar a página;
• o link do .mp4 pode ser copiado;
• ferramentas comuns conseguem baixar;
• não há controle fino por usuário;
• não há expiração real;
• não há rastreabilidade.

Não use isso para cursos pagos.

Nível 1 — básico: storage privado + URL assinada

Aqui o vídeo não fica público. O backend gera uma URL temporária para usuários autorizados.

Exemplo conceitual:

/video/aula-1.m3u8?token=abc123&exp=1760000000

Vantagens:

• impede acesso público direto;
• links expiram;
• reduz compartilhamento casual;
• implementação relativamente simples.

Limitações:

• não é DRM completo;
• usuário técnico ainda pode tentar baixar segmentos dentro da janela de validade;
• se o token for longo demais, aumenta o risco;
• não protege bem contra captura.

Use como camada mínima, nunca como única proteção para conteúdo de alto valor.

Nível 2 — intermediário: HLS/DASH criptografado com AES-128 ou SAMPLE-AES

O vídeo é quebrado em segmentos e criptografado. O player precisa obter uma chave para reproduzir.

Vantagens:

• melhor do que MP4 aberto;
• dificulta download casual;
• funciona com HLS;
• pode ser combinado com URLs assinadas.

Limitações:

• se a chave for exposta de forma fraca, a proteção cai;
• não tem o mesmo nível de proteção de Widevine/FairPlay/PlayReady;
• não aplica políticas avançadas de licença.

Bom para conteúdo de médio valor, mas ainda abaixo de uma solução multi-DRM.

Nível 3 — recomendado: multi-DRM profissional

Este é o padrão mais adequado para uma plataforma que vende cursos autorais e quer proteger receita.

Use:

• Widevine para Chrome/Android/Edge/Firefox compatíveis;
• FairPlay Streaming para Safari/iOS/iPadOS/macOS/tvOS;
• PlayReady para Windows, Edge, TVs, consoles e outros dispositivos compatíveis.

Vantagens:

• chaves não são entregues como arquivo simples;
• reprodução depende do CDM do navegador/dispositivo;
• permite licença com expiração;
• permite limitar qualidade conforme segurança do dispositivo;
• permite políticas como HDCP/output protection;
• dificulta muito o download casual.

Limitações:

• implementação mais complexa;
• normalmente exige provedor DRM;
• pode ter custo por licença/reprodução;
• precisa de player compatível;
• precisa tratar diferenças entre navegadores.

5. Escolha estratégica: construir ou contratar?

Opção A — usar plataforma/serviço de vídeo pronto

Serviços de vídeo profissionais podem oferecer upload, encoding, CDN, player, tokens e às vezes DRM/watermarking.

Exemplos de categorias:

• serviços de streaming gerenciado;
• plataformas OTT;
• provedores de vídeo com DRM;
• serviços de encoding + CDN + player;
• soluções com APIs para educação online.

Vantagens:

• implementação mais rápida;
• menos infraestrutura para manter;
• suporte a múltiplos dispositivos;
• menor risco de erro criptográfico;
• geralmente já há player pronto.

Desvantagens:

• custo mensal/por tráfego/por minuto;
• dependência do fornecedor;
• menos controle técnico;
• migração futura pode ser trabalhosa.

Recomendação brutalmente honesta: se a equipe é pequena, não tente inventar um Netflix caseiro logo no começo. Use um fornecedor de vídeo/DRM confiável e integre via API. O custo de errar segurança de vídeo costuma ser maior que o custo do fornecedor.

Opção B — montar pipeline próprio com provedor DRM

Você mantém sua plataforma, seu backend e seu fluxo, mas usa um fornecedor multi-DRM para licenças.

Arquitetura típica:

Backend da plataforma
        ↓
Serviço de encoding/packaging
        ↓
Provedor multi-DRM
        ↓
Storage/CDN
        ↓
Player DRM

Ferramentas comuns nesse tipo de cenário:

• FFmpeg para pré-processamento;
• Shaka Packager ou Bento4 para empacotamento;
• AWS MediaConvert/MediaPackage, Bitmovin, Harmonic, Ateme ou similares;
• provedores DRM como EZDRM, BuyDRM, Irdeto, castLabs, Axinom, DRMToday ou equivalentes;
• players como Shaka Player, Bitmovin Player, THEOplayer, Video.js com plugins adequados, JW Player Enterprise ou soluções nativas mobile.

Vantagens:

• mais controle;
• escalável;
• arquitetura profissional;
• permite trocar partes do pipeline.

Desvantagens:

• exige equipe técnica mais madura;
• integração multi-DRM dá trabalho;
• erros de CORS, certificados, tokens e manifests são comuns;
• suporte a Apple FairPlay costuma ser a parte mais chata.

Opção C — tudo próprio

Criar seu próprio servidor de licença DRM do zero é uma péssima ideia para quase todo mundo.

Motivos:

• DRM envolve contratos, certificados, SDKs, conformidade e ecossistemas fechados;
• Widevine/FairPlay/PlayReady não são simplesmente “bibliotecas livres” que você liga e pronto;
• falhas de implementação podem expor chaves;
• manter compatibilidade com navegadores e dispositivos vira um inferno operacional.

Recomendação: não faça DRM próprio. Faça backend próprio, regras próprias, autenticação própria e integração com provedor DRM.

6. Formatos de entrega: HLS e DASH

6.1 HLS

HLS significa HTTP Live Streaming. É o formato historicamente mais usado no ecossistema Apple, mas também funciona em vários ambientes.

Arquivos típicos:

master.m3u8
720p.m3u8
1080p.m3u8
segmento_0001.ts ou segmento_0001.m4s
segmento_0002.ts ou segmento_0002.m4s

Para DRM Apple, usa-se FairPlay Streaming com HLS.

6.2 MPEG-DASH

DASH é muito usado com Widevine e PlayReady.

Arquivos típicos:

manifest.mpd
segmento_0001.m4s
segmento_0002.m4s

6.3 CMAF

CMAF permite uma abordagem moderna com segmentos fragmentados .m4s, facilitando reutilizar os mesmos segmentos em HLS e DASH em certos fluxos.

Na prática, uma arquitetura moderna costuma gerar:

• DASH + Widevine/PlayReady;
• HLS + FairPlay;
• segmentos CMAF quando possível.

7. Pipeline técnico de proteção

Etapa 1 — upload do vídeo original

O vídeo original deve ir para um storage privado, nunca para uma pasta pública.

Boas práticas:

• aceitar upload via painel administrativo;
• armazenar o master em bucket privado;
• bloquear listagem pública;
• separar bucket de origem e bucket de distribuição;
• manter logs de acesso;
• aplicar versionamento se possível;
• restringir acesso por IAM/permissões.

Exemplo de estrutura:

storage-private/
  masters/
    curso-123/
      aula-001/original.mp4

storage-protected/
  packaged/
    curso-123/
      aula-001/
        dash/manifest.mpd
        hls/master.m3u8
        segments/...

Etapa 2 — transcodificação

O vídeo deve ser convertido para múltiplas qualidades.

Exemplo de perfis:

Use bitrate adaptativo para melhorar experiência e reduzir custo de banda.

Exemplo conceitual com FFmpeg:

ffmpeg -i original.mp4 \
  -map 0:v:0 -map 0:a:0 \
  -c:v libx264 -preset slow -profile:v main -level 4.0 \
  -b:v:0 5000k -s:v:0 1920x1080 \
  -c:a aac -b:a 128k \
  saida-1080p.mp4

Em produção, prefira automatizar isso com uma fila de jobs.

Etapa 3 — empacotamento HLS/DASH

O empacotamento divide o vídeo em segmentos e gera manifests.

Ferramentas possíveis:

• Shaka Packager;
• Bento4;
• FFmpeg para casos simples;
• AWS MediaPackage;
• Bitmovin Encoding;
• serviços equivalentes.

Exemplo conceitual com Shaka Packager:

packager \
  in=video_1080p.mp4,stream=video,output=video_1080p_encrypted.mp4 \
  in=audio.mp4,stream=audio,output=audio_encrypted.mp4 \
  --enable_raw_key_encryption \
  --keys label=:key_id=SEU_KEY_ID:key=SEU_KEY \
  --mpd_output manifest.mpd \
  --hls_master_playlist_output master.m3u8

Atenção: este exemplo é didático. Em produção, as chaves devem vir de um KMS/provedor DRM, nunca ficar hardcoded em script.

Etapa 4 — criptografia

A criptografia deve acontecer antes da distribuição.

Modelos comuns:

1. AES-128 HLS simples

   • mais simples;
   • proteção limitada;
   • chave precisa ser muito bem protegida.

2. CENC/CMAF com Widevine/PlayReady

   • usado em DASH e alguns fluxos CMAF;
   • bom para multi-DRM.

3. SAMPLE-AES/FairPlay

   • usado no ecossistema Apple com HLS/FPS.

Para plataforma comercial, o caminho recomendado é:

CMAF/DASH + Widevine + PlayReady
HLS + FairPlay

Etapa 5 — integração com servidor de licença DRM

Quando o aluno aperta play, o player não recebe a chave diretamente. Ele solicita uma licença DRM.

Fluxo:

1. Player carrega manifesto.
2. Player detecta DRM necessário.
3. Player chama license_url.
4. Backend/provedor DRM recebe requisição.
5. Backend valida token da plataforma.
6. Se autorizado, licença é emitida.
7. CDM do navegador/dispositivo descriptografa e reproduz.

Exemplo de informações que devem ser validadas antes da licença:

• usuário está logado;
• usuário tem acesso ao curso;
• compra/assinatura está ativa;
• sessão não expirou;
• token não foi adulterado;
• IP ou país não violam regra da plataforma;
• limite de dispositivos não foi excedido;
• limite de sessões simultâneas não foi excedido;
• aula pertence ao curso comprado;
• conta não está bloqueada por abuso.

8. Player com suporte a DRM

Você precisa de um player capaz de falar com EME/CDM no navegador.

Opções comuns:

Exemplo conceitual com Shaka Player

<video id="video" controls autoplay></video>
<script src="https://cdn.jsdelivr.net/npm/shaka-player/dist/shaka-player.compiled.js"></script>
<script>
async function initPlayer() {
  const video = document.getElementById('video');
  const player = new shaka.Player(video);

  player.configure({
    drm: {
      servers: {
        'com.widevine.alpha': 'https://drm.exemplo.com/widevine',
        'com.microsoft.playready': 'https://drm.exemplo.com/playready'
      }
    }
  });

  await player.load('https://cdn.exemplo.com/cursos/123/aulas/1/manifest.mpd');
}

initPlayer().catch(console.error);
</script>

Em produção, você normalmente adicionará headers/tokens:

player.getNetworkingEngine().registerRequestFilter((type, request) => {
  request.headers['Authorization'] = 'Bearer TOKEN_DA_SESSAO';
});

9. Controle de acesso no backend

O backend da plataforma precisa ser o porteiro de verdade.

9.1 Nunca confie apenas no frontend

Errado:

if (usuarioComprouCurso) {
  mostrarPlayer();
}

Isso só esconde interface. Não protege conteúdo.

Correto:

Frontend pede acesso → Backend valida → Backend gera token curto → Player usa token → Servidor de licença valida token

9.2 Token de playback

Crie um token específico para reprodução, diferente do token normal de login.

Campos recomendados:

{
  "sub": "usuario_123",
  "course_id": "curso_456",
  "lesson_id": "aula_789",
  "session_id": "sessao_abc",
  "device_id": "device_xyz",
  "iat": 1760000000,
  "exp": 1760000900,
  "ip_hash": "hash_opcional",
  "nonce": "valor_aleatorio"
}

Tempo de vida recomendado:

• token de manifesto: 1 a 10 minutos;
• token de licença: 1 a 5 minutos;
• sessão de playback: renovável enquanto o usuário estiver ativo;
• URL CDN: curta, preferencialmente minutos, não horas.

9.3 Regras importantes

Implemente pelo menos:

• limite de sessões simultâneas por usuário;
• limite de dispositivos autorizados;
• revogação de sessão;
• expiração curta de tokens;
• rotação de tokens;
• checagem de assinatura JWT/HMAC;
• rate limit por usuário/IP;
• bloqueio de contas com comportamento suspeito;
• logs detalhados de playback.

10. URL assinada e CDN

Mesmo com DRM, não deixe manifestos e segmentos totalmente públicos sem controle.

Use:

• URL assinada;
• cookie assinado;
• token de CDN;
• origem privada;
• CDN acessando storage por identidade própria;
• bloqueio de hotlink;
• expiração curta;
• CORS restrito.

Exemplo conceitual:

https://cdn.exemplo.com/aulas/123/master.m3u8?Expires=1760000000&Signature=XYZ&Key-Pair-Id=ABC

Erros comuns

• URL assinada com validade de 24 horas ou mais;
• manifest público e só segmentos privados;
• segmentos públicos e só manifest privado;
• bucket com listagem pública;
• CORS liberado para * sem necessidade;
• permitir download direto do master original;
• deixar .mp4 original acessível no mesmo domínio.

11. Marca d'água visível

Marca d'água visível é uma das medidas mais baratas e úteis contra vazamento casual.

Exemplo:

pablo@email.com • ID 12345 • 22/06/2026 15:31

Boas práticas:

• mostrar email ou ID do aluno;
• alternar posição ao longo do vídeo;
• variar opacidade;
• aparecer em momentos aleatórios;
• não ficar sempre no canto;
• não ser fácil de cortar;
• usar também no fullscreen;
• renderizar por cima do player, mas sabendo que overlay pode ser removido por usuário técnico.

Exemplo CSS/HTML:

<div class="video-wrapper">
  <video id="video" controls></video>
  <div class="watermark">usuario@email.com • Sessão 9F3A</div>
</div>

.video-wrapper {
  position: relative;
}

.watermark {
  position: absolute;
  top: 12%;
  left: 8%;
  color: rgba(255,255,255,0.45);
  font-size: 14px;
  pointer-events: none;
  text-shadow: 0 1px 2px rgba(0,0,0,0.7);
  z-index: 10;
}

Movimento da marca d'água

const watermark = document.querySelector('.watermark');
const positions = [
  { top: '10%', left: '8%' },
  { top: '20%', left: '60%' },
  { top: '70%', left: '15%' },
  { top: '55%', left: '50%' }
];

let index = 0;
setInterval(() => {
  const pos = positions[index % positions.length];
  watermark.style.top = pos.top;
  watermark.style.left = pos.left;
  index++;
}, 30000);

Isso não é inviolável, mas assusta o aluno comum que pensaria em gravar e compartilhar.

12. Marca d'água forense invisível

Marca d'água forense é mais séria. Ela embute informações no próprio vídeo, de forma imperceptível, para identificar a origem do vazamento.

Pode identificar:

• usuário;
• sessão;
• dispositivo;
• horário;
• curso;
• lote de distribuição.

Modelos:

12.1 Watermark por usuário no encoding

Cada usuário recebe uma versão personalizada.

Vantagens:

• forte rastreabilidade;
• difícil negar autoria do vazamento.

Desvantagens:

• caro;
• pesado;
• exige processamento por usuário;
• aumenta storage.

12.2 Watermark A/B server-side

O vídeo é dividido em segmentos com variantes A e B. A sequência entregue ao usuário codifica uma identidade.

Exemplo conceitual:

Usuário 1: A B A A B B A
Usuário 2: B A B A A B B

Vantagens:

• mais escalável;
• não precisa gerar vídeo inteiro por usuário;
• usado em arquiteturas profissionais.

Desvantagens:

• implementação complexa;
• normalmente exige fornecedor especializado;
• precisa de sistema de detecção.

12.3 Watermark client-side

Aplicada no player ou app.

Vantagens:

• mais simples;
• pode ser combinada com marca visível.

Desvantagens:

• mais fácil de adulterar;
• não é tão robusta quanto server-side.

Recomendação: para cursos de alto valor, use pelo menos marca visível dinâmica. Para cursos premium, mentorias caras, certificações ou conteúdo sensível, avalie watermarking forense profissional.

13. Prevenção de compartilhamento de conta

A pirataria nem sempre começa com hacker. Muitas vezes começa com:

• “manda teu login aí”;
• grupo de rateio;
• conta compartilhada em Telegram;
• aluno revendendo acesso.

Medidas recomendadas:

13.1 Limite de dispositivos

Exemplo:

• máximo de 2 ou 3 dispositivos por conta;
• troca de dispositivo limitada por período;
• painel para o aluno remover dispositivo antigo;
• bloqueio automático se houver troca excessiva.

13.2 Limite de sessões simultâneas

Exemplo:

• 1 reprodução simultânea por conta;
• ou 2, se o produto permitir;
• derrubar sessão antiga quando uma nova inicia;
• registrar IP, user-agent e device fingerprint moderado.

13.3 Detecção de anomalias

Sinais de abuso:

• muitos IPs em pouco tempo;
• muitos países diferentes;
• muitos dispositivos;
• reprodução 24h por dia;
• login em datacenter/VPN/proxy;
• múltiplas aulas tocando simultaneamente;
• padrões incompatíveis com uso humano.

13.4 Resposta gradual

Não bloqueie tudo automaticamente sem cuidado. Use gradação:

1. aviso;
2. exigir reautenticação;
3. bloquear nova sessão;
4. solicitar troca de senha;
5. congelar conta;
6. revisão manual;
7. banimento se confirmado.

14. Políticas de licença DRM

Ao emitir uma licença DRM, defina regras.

Políticas úteis:

Exemplo de regra sensata:

- Licença válida por 5 minutos.
- Renovação permitida enquanto sessão estiver ativa.
- Sem licença persistente/offline por padrão.
- Full HD apenas em dispositivos com segurança adequada.
- Bloquear reprodução se conta exceder sessões simultâneas.

15. CORS, headers e segurança HTTP

Configure headers corretamente.

15.1 CORS

Evite liberar tudo:

Access-Control-Allow-Origin: *

Prefira:

Access-Control-Allow-Origin: https://www.sua-plataforma.com
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type

Se houver múltiplos domínios oficiais, mantenha allowlist.

15.2 Headers úteis

Content-Security-Policy: default-src 'self'; media-src https://cdn.exemplo.com; connect-src 'self' https://drm.exemplo.com https://cdn.exemplo.com;
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

15.3 Não dependa de bloqueio de botão direito

Bloquear botão direito, DevTools ou copiar link é teatro de segurança. Pode incomodar usuário honesto e não segura usuário técnico.

Pode até usar como fricção leve, mas não venda isso internamente como proteção real.

16. Proteção contra download direto

Medidas práticas:

• nunca expor .mp4 original;
• usar HLS/DASH segmentado;
• criptografar segmentos;
• usar DRM para conteúdo valioso;
• assinar manifestos e segmentos;
• encurtar validade dos tokens;
• bloquear hotlink;
• limitar taxa por usuário;
• detectar download sequencial rápido de segmentos;
• bloquear IPs com comportamento de scraper;
• invalidar tokens usados fora do padrão esperado.

Detecção simples de scraping

Sinais:

- usuário baixa segmentos muito mais rápido que tempo real;
- acessa todos os segmentos sem eventos de player;
- não envia heartbeat;
- usa user-agent estranho;
- troca IP no meio da sessão;
- faz muitas requisições 403/404 tentando descobrir paths.

Ações:

- invalidar sessão;
- exigir novo login;
- reduzir validade de tokens;
- bloquear IP temporariamente;
- registrar incidente;
- marcar usuário para revisão.

17. Heartbeat de reprodução

O player deve enviar eventos periódicos ao backend.

Exemplo:

POST /api/playback/heartbeat
{
  "session_id": "abc",
  "lesson_id": "aula_1",
  "current_time": 432,
  "duration": 1800,
  "quality": "720p",
  "paused": false,
  "timestamp": 1760000000
}

Use heartbeat para:

• saber se a sessão ainda existe;
• detectar múltiplas sessões;
• encerrar sessão abandonada;
• medir progresso real;
• detectar comportamento automatizado;
• renovar tokens de forma segura.

Intervalo sugerido:

• a cada 15 a 60 segundos;
• mais curto para conteúdo premium;
• mais longo para reduzir carga.

18. Logs obrigatórios

Registre:

• usuário;
• curso;
• aula;
• sessão;
• IP;
• user-agent;
• device_id;
• horário de início;
• horário de fim;
• eventos de play/pause/seek;
• qualidade reproduzida;
• erros DRM;
• license requests;
• tokens emitidos;
• tentativas negadas;
• país/cidade aproximada, se juridicamente permitido;
• CDN request logs.

Sem log, você não investiga nada. Sem investigação, DRM vira enfeite caro.

19. Privacidade e LGPD

Cuidado: proteção antipirataria envolve dados de usuário.

Você deve:

• informar no termo de uso que há controle antifraude;
• explicar uso de IP, dispositivo e logs;
• não coletar mais do que precisa;
• proteger logs contra vazamento;
• definir retenção de dados;
• permitir atendimento a solicitações legais do usuário;
• revisar com advogado se a operação for grande.

Não transforme antipirataria em vigilância desnecessária.

20. Implementação prática por fases

Fase 1 — proteção mínima aceitável

Implemente:

• storage privado;
• HLS em vez de MP4 aberto;
• URLs assinadas curtas;
• login obrigatório;
• checagem de compra no backend;
• marca d'água visível dinâmica;
• limite de sessões simultâneas;
• logs de playback;
• bloqueio de hotlink;
• CDN com origem privada.

Essa fase já elimina muita pirataria amadora.

Fase 2 — proteção profissional

Adicione:

• multi-DRM;
• Widevine;
• FairPlay;
• PlayReady;
• player DRM;
• licença curta e renovável;
• integração com provedor DRM;
• limitação de dispositivos;
• detecção de anomalias;
• painel administrativo de sessões;
• revogação de acesso em tempo real.

Essa é a fase recomendada para cursos autorais pagos com valor comercial relevante.

Fase 3 — proteção avançada

Adicione:

• watermarking forense invisível;
• A/B watermarking server-side;
• monitoramento de vazamentos em sites, Telegram, fóruns e redes;
• automação de takedown;
• equipe ou rotina de revisão de abuso;
• classificação de risco por usuário;
• integração com antifraude de pagamento;
• políticas de HDCP/output protection para vídeos premium.

Essa fase é para conteúdo caro, assinatura grande ou risco alto de revenda ilegal.

21. Exemplo de arquitetura em produção

[Admin envia vídeo]
        ↓
[Backend cria job]
        ↓
[Storage privado: master]
        ↓
[Encoder gera 240p/480p/720p/1080p]
        ↓
[Packager gera DASH/HLS]
        ↓
[DRM provider gera keys/KIDs]
        ↓
[Segmentos criptografados vão para storage protegido]
        ↓
[CDN entrega apenas com token]
        ↓
[Aluno logado clica play]
        ↓
[Backend valida compra]
        ↓
[Backend cria playback_session]
        ↓
[Frontend carrega player]
        ↓
[Player solicita manifesto assinado]
        ↓
[Player solicita licença DRM]
        ↓
[License proxy valida token com backend]
        ↓
[DRM provider emite licença]
        ↓
[Player reproduz]
        ↓
[Heartbeat + logs + watermark]

22. Modelo de banco de dados para controle

Tabela video_assets

CREATE TABLE video_assets (
  id BIGINT PRIMARY KEY,
  course_id BIGINT NOT NULL,
  lesson_id BIGINT NOT NULL,
  original_path TEXT NOT NULL,
  status VARCHAR(30) NOT NULL,
  duration_seconds INT,
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
);

Tabela video_renditions

CREATE TABLE video_renditions (
  id BIGINT PRIMARY KEY,
  asset_id BIGINT NOT NULL,
  resolution VARCHAR(20) NOT NULL,
  bitrate INT NOT NULL,
  manifest_url TEXT,
  drm_key_id VARCHAR(255),
  created_at TIMESTAMP NOT NULL
);

Tabela playback_sessions

CREATE TABLE playback_sessions (
  id VARCHAR(64) PRIMARY KEY,
  user_id BIGINT NOT NULL,
  course_id BIGINT NOT NULL,
  lesson_id BIGINT NOT NULL,
  device_id VARCHAR(255),
  ip_hash VARCHAR(255),
  user_agent_hash VARCHAR(255),
  status VARCHAR(30) NOT NULL,
  started_at TIMESTAMP NOT NULL,
  last_seen_at TIMESTAMP,
  expires_at TIMESTAMP NOT NULL
);

Tabela device_authorizations

CREATE TABLE device_authorizations (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  device_id VARCHAR(255) NOT NULL,
  device_name VARCHAR(255),
  first_seen_at TIMESTAMP NOT NULL,
  last_seen_at TIMESTAMP NOT NULL,
  revoked_at TIMESTAMP NULL
);

Tabela playback_events

CREATE TABLE playback_events (
  id BIGINT PRIMARY KEY,
  session_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(50) NOT NULL,
  playback_time_seconds INT,
  quality VARCHAR(20),
  ip_hash VARCHAR(255),
  created_at TIMESTAMP NOT NULL
);

23. Endpoint de autorização de reprodução

Exemplo conceitual:

POST /api/playback/start
Authorization: Bearer TOKEN_LOGIN
Content-Type: application/json

{
  "course_id": 123,
  "lesson_id": 456,
  "device_id": "abc-device"
}

Resposta:

{
  "session_id": "sess_123",
  "manifest_url": "https://cdn.exemplo.com/.../manifest.mpd?token=...",
  "drm": {
    "widevine_license_url": "https://api.exemplo.com/drm/widevine?token=...",
    "playready_license_url": "https://api.exemplo.com/drm/playready?token=...",
    "fairplay_license_url": "https://api.exemplo.com/drm/fairplay?token=...",
    "fairplay_certificate_url": "https://api.exemplo.com/drm/fairplay/cert"
  },
  "watermark": {
    "text": "usuario@email.com • SESS sess_123",
    "mode": "dynamic"
  },
  "expires_in": 300
}

24. License proxy

Em vez de deixar o player chamar diretamente o provedor DRM sem validação da plataforma, use um license proxy.

Fluxo:

Player → /api/drm/widevine → Backend valida → Provedor DRM → Backend → Player

Validações no proxy:

• token de playback válido;
• sessão ativa;
• curso autorizado;
• limite de sessão respeitado;
• usuário não bloqueado;
• device autorizado;
• origem permitida;
• IP não suspeito;
• aula correta.

Pseudocódigo:

function handleLicenseRequest(request):
    token = extractToken(request)
    claims = verifyToken(token)

    if claims.expired:
        deny(401)

    session = findPlaybackSession(claims.session_id)

    if session.status != "active":
        deny(403)

    if not userHasAccess(session.user_id, session.course_id):
        deny(403)

    if exceedsConcurrentLimit(session.user_id):
        deny(403)

    if deviceIsRevoked(session.device_id):
        deny(403)

    drmResponse = forwardToDrmProvider(request.body, claims)
    logLicenseRequest(session)
    return drmResponse

25. FairPlay: atenção especial

FairPlay costuma exigir etapas específicas:

• certificado FairPlay;
• Application Secret Key, dependendo do fluxo;
• processamento de SPC e CKC;
• player compatível;
• HLS configurado corretamente;
• domínio e CORS ajustados;
• teste em Safari/iOS real.

Não assuma que “funcionou no Chrome” significa que funcionará no iPhone.

Teste separadamente:

• Chrome desktop;
• Edge desktop;
• Firefox, se suportado no seu player/DRM;
• Safari macOS;
• Safari iOS;
• Android Chrome;
• app Android, se houver;
• app iOS, se houver;
• Smart TV, se for alvo.

26. HDCP e proteção de saída

HDCP é proteção contra cópia na saída HDMI/DisplayPort.

Você pode configurar políticas para exigir HDCP em determinados conteúdos ou qualidades.

Exemplo de política:

- 480p: sem exigência forte.
- 720p: permitir na maioria dos dispositivos.
- 1080p: exigir ambiente mais seguro.
- 4K: exigir HDCP forte.

Para cursos comuns, talvez isso seja exagero. Para conteúdo muito caro ou licenciado, pode fazer sentido.

Cuidado: políticas rígidas demais geram suporte e reclamação de aluno legítimo.

27. Offline playback

Se a plataforma não precisa de modo offline, não habilite licença persistente.

Offline aumenta complexidade e risco:

• licença fica armazenada no dispositivo;
• precisa controlar expiração;
• precisa revogar quando assinatura termina;
• precisa lidar com app nativo;
• não funciona bem só com web.

Recomendação:

Cursos web pagos → sem offline no começo.
App mobile maduro → avaliar offline com licença expirada em poucos dias.

28. Aplicativos mobile

Se houver app:

Android

Use:

• ExoPlayer/AndroidX Media3;
• Widevine;
• token de sessão;
• device binding;
• root detection moderada;
• bloqueio de screenshots se fizer sentido.

iOS

Use:

• AVPlayer;
• FairPlay Streaming;
• certificado FPS;
• controle de licença;
• bloqueio de captura onde permitido;
• tratamento de AirPlay conforme política.

Atenção: apps aumentam controle, mas também aumentam custo de manutenção.

29. Medidas jurídicas e operacionais

Tecnologia sozinha não resolve.

Tenha:

• termo de uso proibindo compartilhamento, gravação e redistribuição;
• política de cancelamento de conta por abuso;
• registro de autoria dos cursos;
• contratos com professores/autores;
• procedimento de takedown;
• modelo de notificação extrajudicial;
• coleta de evidências de vazamento;
• rotina de busca por cópias.

Checklist de evidência em caso de vazamento

Guardar:

• URL do vazamento;
• print com data/hora;
• arquivo baixado, se juridicamente adequado;
• hash do arquivo;
• comparação com original;
• marca d'água encontrada;
• usuário/sessão provável;
• logs da sessão;
• IPs envolvidos;
• histórico de acesso.

30. Monitoramento de vazamentos

Locais comuns:

• Telegram;
• grupos de WhatsApp;
• fóruns;
• sites de download;
• marketplaces suspeitos;
• redes sociais;
• plataformas de vídeo abertas;
• armazenamento público compartilhado.

Buscas úteis:

"nome do curso" download
"nome do professor" curso completo
"nome da aula" "m3u8"
"nome da plataforma" "drive"
"nome do curso" telegram

Também vale criar alertas e monitoramento recorrente.

31. O que não vale a pena vender como proteção séria

Estas medidas podem ser fricção, mas não proteção real:

• bloquear botão direito;
• esconder URL com JavaScript ofuscado;
• impedir F12;
• player sem botão de download;
• vídeo “não listado”;
• colocar arquivo MP4 com nome aleatório;
• robots.txt;
• aviso visual sem controle técnico;
• confiar só no frontend.

Use se quiser, mas não se engane. Segurança de verdade fica no backend, criptografia, licença, token curto, logging e resposta operacional.

32. Stack recomendada para começar

Caminho pragmático

Para uma plataforma de cursos, o caminho mais racional é:

1. Contratar serviço de vídeo ou provedor multi-DRM.
2. Usar storage privado e CDN.
3. Integrar player DRM no frontend.
4. Criar backend de autorização de playback.
5. Aplicar watermark visível dinâmica.
6. Registrar logs e limitar sessões.
7. Evoluir para watermark forense quando houver escala ou risco.

Stack exemplo

Frontend:
- React/Vue/Blade/etc.
- Shaka Player ou player comercial

Backend:
- Laravel, Node.js, Django, FastAPI ou similar
- JWT curto para playback
- endpoints de sessão e heartbeat

Vídeo:
- Encoder/packager gerenciado ou Shaka Packager
- HLS/DASH
- Widevine/FairPlay/PlayReady via provedor DRM

Infra:
- Storage privado
- CDN com URL/cookie assinado
- Logs centralizados
- Monitoramento

Segurança:
- Rate limit
- CORS restrito
- CSP
- device/session control
- watermark dinâmica

33. Checklist final de implementação

Obrigatório

• Vídeo original em storage privado.
• Nenhum .mp4 público.
• HLS/DASH segmentado.
• CDN com origem privada.
• URL ou cookie assinado.
• Login obrigatório.
• Backend validando acesso ao curso.
• Token de playback curto.
• Logs de reprodução.
• Limite de sessões simultâneas.
• Marca d'água visível dinâmica.
• Termo de uso proibindo redistribuição.

Recomendado

• Multi-DRM.
• Widevine.
• FairPlay.
• PlayReady.
• License proxy.
• Limite de dispositivos.
• Heartbeat de player.
• Detecção de comportamento suspeito.
• Revogação de sessão.
• CORS restrito.
• CSP ajustado.

Avançado

• Watermark forense invisível.
• A/B watermarking.
• Monitoramento de vazamentos.
• Takedown automatizado.
• Classificação de risco por usuário.
• HDCP/output protection.
• Política de qualidade por nível de segurança.

34. Ordem prática de execução

1. Mapear o catálogo de vídeos

   • quantidade de aulas;
   • duração total;
   • resolução;
   • tamanho dos arquivos;
   • valor comercial dos cursos.

2. Definir nível de proteção

   • básico, intermediário ou multi-DRM.

3. Escolher fornecedor ou stack

   • vídeo gerenciado;
   • provedor multi-DRM;
   • CDN;
   • player.

4. Criar pipeline de ingestão

   • upload;
   • fila;
   • encoding;
   • packaging;
   • criptografia;
   • publicação protegida.

5. Criar backend de playback

   • autorização;
   • sessão;
   • token;
   • heartbeat;
   • logs.

6. Integrar player

   • detectar navegador;
   • carregar manifesto correto;
   • configurar license servers;
   • adicionar headers;
   • tratar erros.

7. Adicionar marca d'água

   • visível dinâmica no começo;
   • forense depois, se necessário.

8. Testar dispositivos

   • Chrome;
   • Edge;
   • Safari;
   • iOS;
   • Android;
   • redes lentas;
   • múltiplas sessões;
   • token expirado;
   • usuário sem acesso;
   • conta bloqueada.

9. Lançar com monitoramento

   • dashboards;
   • alertas;
   • logs de erro DRM;
   • suporte ao aluno.

10. Melhorar continuamente

• revisar vazamentos;
• ajustar limites;
• analisar reclamações;
• endurecer regras onde houver abuso real.

35. Erros que mais causam pirataria

1. Deixar MP4 público.
2. Usar link assinado com validade longa.
3. Não criptografar segmentos.
4. Não validar licença no backend.
5. Não limitar sessões simultâneas.
6. Não aplicar watermark.
7. Não registrar logs.
8. Não ter termo de uso claro.
9. Confiar em bloqueio de DevTools.
10. Achar que DRM resolve tudo sozinho.

36. Resumo executivo

Para proteger cursos em vídeo autorais em uma plataforma, a estratégia correta é usar camadas:

Autenticação forte
+ autorização por curso/aula
+ storage privado
+ HLS/DASH segmentado
+ CDN com token curto
+ multi-DRM
+ license proxy
+ limite de sessões/dispositivos
+ watermark visível
+ watermark forense para conteúdo premium
+ logs e resposta operacional
+ medidas jurídicas

A solução ideal não é “um plugin mágico de DRM”. É uma arquitetura.

Se o orçamento for limitado, comece com storage privado, HLS, URL assinada curta, watermark visível, limite de sessões e logs. Se o conteúdo já gera receita relevante, vá direto para multi-DRM com fornecedor especializado.

37. Referências técnicas úteis

• Google Widevine — documentação oficial: https://developers.google.com/widevine/drm/overview
• Apple FairPlay Streaming — documentação oficial: https://developer.apple.com/streaming/fps/
• Microsoft PlayReady — documentação oficial: https://learn.microsoft.com/en-us/playready/
• W3C Encrypted Media Extensions: https://www.w3.org/TR/encrypted-media-2/
• Shaka Packager: https://github.com/shaka-project/shaka-packager
• AWS MediaPackage — content encryption and DRM: https://docs.aws.amazon.com/mediapackage/latest/ug/using-encryption.html
• Cloudflare Stream — signed URLs/tokens: https://developers.cloudflare.com/stream/viewing-videos/securing-your-stream/
• NAGRAVISION forensic watermarking: https://nagra.vision/security-solutions/forensic-watermarking/
• Irdeto — forensic watermarking at scale: https://irdeto.com/blog/modern-forensic-watermarking-at-scale

38. Conclusão sem enrolação

Se a plataforma pretende vender cursos autorais de forma séria, o mínimo aceitável é não expor MP4 público, usar entrega segmentada, tokens curtos, controle de sessão, marca d'água e logs.

O caminho profissional é multi-DRM com Widevine, FairPlay e PlayReady, integrado a um backend que valida acesso antes de cada licença.

E o ponto mais importante: DRM dificulta cópia técnica; watermark e logs dificultam impunidade; processo jurídico dificulta revenda. Só a combinação dos três cria uma defesa decente.