O que é segurança de CDN?

A segurança de CDN abrange controles que protegem o conteúdo entregue pela borda e suas origens. Medidas comuns incluem TLS, requisições assinadas, regras de acesso, limites de taxa e mitigação de ataques de negação de serviço.

Uma CDN fica entre os espectadores e a origem, então tem dois lados a proteger. Do lado dos espectadores, ela encerra a conexão TLS, pode absorver ou limitar a taxa de tráfego abusivo e pode exigir que cada requisição comprove autorização, geralmente com uma URL assinada ou um cookie assinado que contém um prazo de validade e é verificado na borda. O Amazon CloudFront valida primeiro a assinatura e a política e só então consulta seu cache de borda ou encaminha a requisição; o Google Cloud CDN rejeita uma requisição com assinatura inválida sem enviá-la ao backend. Validar uma assinatura presente não é o mesmo que exigir uma: o CloudFront exige requisições assinadas apenas para arquivos abrangidos por um comportamento de cache que tenha um signatário, e o Cloud CDN não bloqueia uma requisição que não contenha assinatura alguma, então, nesse caso, a origem precisa recusá-la. Como a própria CDN verifica a assinatura, o uso de assinaturas não precisa fragmentar o cache: o Cloud CDN afirma que todas as requisições assinadas válidas para a mesma URL base compartilham uma entrada de cache e que requisições assinadas e não assinadas nunca compartilham uma entrada. Separadamente, quando uma requisição contém um cabeçalho Authorization, um cache compartilhado não deve reutilizar a resposta, a menos que ela permita explicitamente essa reutilização com public, s-maxage ou must-revalidate (RFC 9111). Do lado da origem, a CDN é apenas mais um cliente HTTP: a origem aceita requisições diretas, a menos que seu acesso seja restrito à CDN, e a conexão entre as duas só é criptografada se isso estiver configurado. A assinatura controla quem pode obter uma resposta da borda. Ela não criptografa a mídia.

Uma URL assinada identifica o espectador? Não. Ela é uma credencial bearer: a documentação do Cloud CDN do Google diz que qualquer pessoa que conheça a URL pode usá-la até que ela expire ou que a chave de assinatura seja rotacionada e, por isso, recomenda prazos de validade curtos e a distribuição de URLs assinadas somente por HTTPS. O Amazon CloudFront também pode restringir uma política personalizada a um endereço ou intervalo de IPs. Um prazo de validade curto tem um custo, porque a validade é verificada a cada requisição: o CloudFront documenta que um download já em andamento é concluído, mas um download retomado após a expiração falha, assim como qualquer requisição posterior de intervalo de bytes. Portanto, com um prazo de validade menor que a sessão de reprodução, a próxima requisição após a expiração é recusada, a menos que a aplicação já tenha emitido uma nova credencial com validade posterior.
URLs assinadas ou cookies assinados para HLS e DASH? Uma playlist ou um manifesto aponta para muitas URLs de segmentos, e cada requisição precisa ser autorizada, então uma assinatura na URL da playlist não autoriza, por si só, as requisições dos segmentos. Tanto o CloudFront quanto o Cloud CDN recomendam cookies assinados quando o acesso abrange vários arquivos, e ambos citam vídeo HLS como exemplo; no Cloud CDN, o cookie autoriza todas as URLs sob um prefixo até expirar, então os manifestos não precisam ser reescritos para cada espectador, e o acesso pode ser renovado em segundo plano com prazos de validade curtos. Assinar a URL de cada segmento para cada espectador é possível, mas, nas palavras do Google, trabalhoso. As URLs assinadas continuam sendo a opção para arquivos individuais e para clientes que não oferecem suporte a cookies. Nas duas CDNs, uma URL assinada tem precedência quando uma requisição contém ambos.
Por que uma URL assinada gerada corretamente retorna 403? Uma causa documentada é que a requisição já não corresponde ao que foi assinado. O CloudFront retorna 403 quando uma string de consulta é adicionada a uma URL após a assinatura, e o Cloud CDN exige seus parâmetros de assinatura em uma ordem fixa, sem alterações entre maiúsculas e minúsculas. Quando a URL inteira é assinada, tudo que um player, proxy ou origem precisar na string de consulta deve estar na URL antes do cálculo da assinatura. Credenciais com escopo definido por prefixo são diferentes: as assinaturas de prefixo de URL e os cookies assinados do Cloud CDN não abrangem parâmetros de consulta, então parâmetros adicionais são aceitos, mas não ficam protegidos contra alterações. No CloudFront, o recurso especificado na política personalizada de um cookie assinado é a URL incluindo sua string de consulta, e um curinga nesse recurso pode corresponder a uma string de consulta adicionada. A rotação de chaves é outra causa documentada: o Cloud CDN deixa de aceitar uma URL quando sua chave de assinatura é excluída, e o procedimento do CloudFront adiciona a nova chave pública, passa a usá-la nas assinaturas e remove a chave antiga somente depois que todas as URLs ou todos os cookies assinados com ela tiverem expirado.
Verificar assinaturas na borda é suficiente se a origem estiver acessível publicamente? Não. A documentação do CloudFront diz que restringir a origem não é obrigatório para que as URLs assinadas funcionem, mas recomenda essa restrição, porque, sem ela, alguém pode contornar o CloudFront usando a própria URL da origem; o Cloud CDN diz o mesmo sobre buckets de armazenamento. Para um bucket, isso significa remover o acesso público de leitura e concedê-lo somente à CDN: por meio de um controle de acesso à origem no CloudFront ou à conta de serviço do Cloud CDN no Cloud Storage. Restringir um bucket não esvazia o cache: o Cloud CDN atende a uma requisição não assinada usando uma entrada de cache já existente, e uma entrada normalmente permanece até expirar ou ser removida pelo cache. Por isso, assim que a origem passar a recusar requisições não assinadas, invalide tudo que foi armazenado em cache enquanto o bucket era público. Para outras origens, os métodos variam em robustez: a Cloudflare classifica um cabeçalho secreto de requisição ou uma lista de permissões de intervalos de IP da CDN como moderadamente seguros, e TLS mútuo (Authenticated Origin Pulls) ou um túnel como muito seguros. HTTPS para os espectadores também não cobre o trecho até a origem. No modo Flexible da Cloudflare, que se aplica a conexões HTTPS dos espectadores na porta padrão 443, a Cloudflare se conecta à origem por HTTP sem criptografia, e o CloudFront tem uma configuração de protocolo separada para cada origem, então um cabeçalho com segredo compartilhado só fica protegido quando esse trecho também é criptografado.

Configure esses controles quando a mídia precisar chegar somente a espectadores autorizados ou quando o tráfego abusivo precisar ser bloqueado antes de chegar à origem. As falhas apontam em direções opostas: uma assinatura que expirou ou já não corresponde à requisição bloqueia espectadores legítimos, enquanto uma origem que ainda responde a requisições diretas, ou um caminho da CDN que atende a requisições sem assinatura, permite que qualquer pessoa ignore as verificações. Antes de colocar em produção, solicite arquivos protegidos sem assinatura tanto pela CDN quanto pelo próprio hostname da origem, incluindo arquivos que a CDN armazenou em cache enquanto ainda eram públicos; todas essas requisições devem ser recusadas.

O Smart CDN da Transloadit oferece suporte a URLs assinadas. Seu backend calcula uma assinatura HMAC-SHA256 com o Auth Secret a partir do nome do Workspace, do nome do Template, do caminho do arquivo e dos parâmetros de consulta ordenados, e a acrescenta como sig ao lado de um prazo de validade exp. Como os parâmetros de transformação fazem parte da string assinada, uma URL assinada cujos parâmetros sejam alterados depois já não corresponde à sua assinatura. Isso só bloqueia requisições alteradas se requisições não assinadas forem recusadas, e as páginas vinculadas não descrevem como uma requisição não assinada ao mesmo Template é tratada, então teste isso no seu próprio Workspace antes de depender das assinaturas. O prazo de validade também limita por quanto tempo um resultado recém-gerado pode permanecer em cache, então um exp mais curto torna o acesso mais restrito, ao custo da reutilização do cache.

exp é informado em milissegundos desde a época Unix; a documentação o descreve como opcional, mas recomenda fortemente defini-lo. As assinaturas precisam ser geradas no servidor porque usam o Auth Secret, e a Auth Key precisa estar habilitada para uso com o Smart CDN. A Transloadit descreve o Smart CDN como uma camada de transformação e entrega que não substitui a política de autorização da sua aplicação: decidir qual espectador recebe uma URL assinada continua sendo responsabilidade do seu código.

Explore os recursos de entrega da Transloadit

O que é segurança de CDN?

Como funciona a segurança de CDN

Informações essenciais

Quando a segurança de CDN é importante

Como a Transloadit ajuda com a segurança de CDN

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional