Compartilhar via


Visão geral de segurança

O Microsoft eCDN é um serviço compatível com M365. Isso significa que ele segue todos os mesmos padrões de segurança mantidos por qualquer outro serviço M365.

Este documento destaca vários artigos específicos à segurança, pois se aplica à entrega de streaming de vídeo.

O Microsoft eCDN é uma solução híbrida, o que significa que o Microsoft eCDN é empregado em combinação com um servidor HTTP tradicional, ao mesmo tempo em que aproveita a infraestrutura de segurança existente (tokens, chaves, cookies etc.) que já está em vigor.

Em termos de comunicação, há dois canais de comunicação main:

  1. Entre pares; os pares estão conectados uns aos outros por meio do canal de dados WebRTC, que é um túnel seguro que usa o protocolo SCTP sobre criptografia DTLS.

  2. Entre cada visualizador e o back-end do Microsoft eCDN por meio de uma conexão WebSocket segura que usa criptografia TLS.

Ambos os canais usam protocolos de segurança de rede padrão do setor para que nem os dados enviados entre dois visualizadores, nem os metadados enviados entre cada visualizador e o back-end do serviço possam ser comprometidos.

Além do acima, o serviço tem recursos de segurança adicionais que podem ser habilitados, com base em requisitos individuais, que são explicados abaixo.

Autenticação do visualizador

Normalmente, qualquer visualizador pode se conectar ao back-end do Microsoft eCDN e participar da rede P2P. Isso é aceitável na maioria dos casos de uso, mas alguns clientes podem preferir limitar quais espectadores podem se conectar ao serviço.

Nesses casos, o back-end pode autenticar os visualizadores diretamente, além de quaisquer mecanismos de autenticação que já possam existir no lado do provedor de conteúdo. Os mecanismos de autenticação que a Microsoft eCDN tem em vigor impedem que os espectadores não autorizados acessem o conteúdo e os metadados existentes na rede ponto a ponto.

Lista de permissões de domínio

A maneira mais rápida e fácil de impedir que a maioria dos espectadores indesejados participe do emparelhamento é permitindo explicitamente a lista de domínios específicos dos quais os espectadores podem se conectar ao back-end do serviço. Isso significa que os espectadores que tentam se conectar ao serviço de outros domínios não permitidos são bloqueados.

Guia passo a passo:

  1. Acesse a página de configuração plataformas de terceiros no console de gerenciamento.

  2. Adicione seus domínios (os em que os scripts de serviço são carregados) na caixa "Lista de Permissões do Site", conforme mostrado abaixo.

  3. Isso é tudo. Qualquer visualizador que tentar se conectar ao serviço com sua ID de locatário de um domínio não listado será bloqueado.

A interface do usuário de lista de permissões de terceiros.

Lista de permissões de usuário final-IP

Outro meio pelo qual os administradores podem impedir que os espectadores indesejados participem do emparelhamento é permitindo apenas o acesso ao serviço de uma lista predefinida de IPs públicos. Isso é semelhante ao recurso "lista de permissões de domínio" acima, mas desta vez permitimos listar os IPs públicos dos espectadores.

Guia passo a passo:

  1. Acesse a página configuração de segurança no console de gerenciamento.

  2. Adicione os IPs públicos desejados ou intervalos de IP na caixa "Lista de Permissões de IP dos Usuários Finais" em um dos formatos com suporte, conforme mostrado abaixo.

  3. Isso é tudo. Qualquer visualizador que tente se conectar ao serviço com sua ID de locatário com um IP não permitido está bloqueado.

Formatos com suporte:

  1. IP único – insira cada IP em uma nova linha ou adicione-os um por um, clicando no botão "Adicionar IPs" após cada um deles. Exemplo: 1.1.1.1

  2. CIDR – Insira um CIDR, que representa o intervalo de IP que você deseja permitir. Exemplo: 1.1.1.1/24

Todos os formatos, exceto JSON (que devem ser adicionados por conta própria) podem ser misturados e combinados separando-os com uma nova linha.

IU da lista de permissões de IP.

Proteção de conteúdo

A maioria das plataformas tem várias maneiras de proteger fluxos impedindo o acesso a espectadores indesejados. O Microsoft eCDN reconhece isso e, portanto, não altera nenhum mecanismo de proteção de conteúdo existente.

Como ocorreria sem o Microsoft eCDN, cada usuário precisa se autenticar no servidor e, somente se autenticado com êxito, o servidor enviará o arquivo de manifesto para o visualizador, que por sua vez começa a solicitar segmentos para reproduzir o fluxo.

A seguir está uma lista dos esquemas de proteção mais comuns:

Autenticação no início da sessão

Nesse caso, cada sessão começa com o servidor solicitando ao visualizador suas credenciais. Se essas credenciais forem válidas, o servidor enviará o arquivo de manifesto para o visualizador e o player de vídeo começará a solicitar segmentos e manifestos adicionais do servidor HTTP. O Microsoft eCDN não se insere nesse processo de validação e o visualizador deve passar pelos mesmos portões de autenticação se o Microsoft eCDN está ou não implantado. Somente os espectadores autorizados a watch um fluxo específico podem participar do compartilhamento P2P para esse fluxo, e eles só compartilham enquanto estão realmente assistindo ao fluxo.

Tokenização de URI de manifesto

O Microsoft eCDN também adere a todos os mecanismos de tokenização de URI existentes que existem no nível do manifesto.

Com o Microsoft eCDN, todas as solicitações de manifesto são enviadas diretamente para o servidor HTTP, portanto, a validação ocorre com o back-end da plataforma da mesma maneira.

Tokenização com tempo de URI

Nesse caso, a URL do manifesto tem um token adicional, que codifica detalhes sobre o agente de usuário do visualizador (endereço IP, hora de expiração etc.). Um usuário mal-intencionado pode distribuir a URL do manifesto para visualizadores não autorizados, mas esses visualizadores não poderão acessar o fluxo, pois a URL do manifesto é tokenizada e o servidor HTTP rejeita qualquer tentativa de validação - seja por causa do endereço IP ou de outras incompatibilidades do agente de usuário ou por causa da expiração do tempo. Com o Microsoft eCDN, todas as solicitações de manifesto são enviadas diretamente para o servidor HTTP para que a validação não possa ser comprometida.

Criptografia

Com a criptografia de conteúdo, os usuários precisam passar pela autenticação existente no local e acessar a chave de descriptografia. O Microsoft eCDN não tem acesso à chave de descriptografia e não altera a forma como é distribuído e protegido. O Microsoft eCDN é agnóstico para os diferentes esquemas de proteção de conteúdo e padrões de suporte, como o AES-128.

Por exemplo, dado um fluxo HLS protegido com criptografia AES-128, os espectadores não autorizados não poderão watch o fluxo porque não terão acesso à chave de descriptografia.

A chave pode ser enviada ao usuário final de várias maneiras – por exemplo, por meio do manifesto, empacotada com a página ou até mesmo solicitada dinamicamente com código personalizado.

O Microsoft eCDN não se insere nesse processo e a chave é entregue ao player de vídeo usando o mesmo mecanismo, independentemente de o Microsoft eCDN ser implantado ou não.

DRM

O caso de uso drm se assemelha ao caso de uso de criptografia - a única diferença é que a licença e as chaves são distribuídas pelo mecanismo DRM em vez de pela emissora. Aqui também, o Microsoft eCDN não interfere na distribuição da licença ou das chaves e, portanto, não as compromete.