Protegendo seu aplicativo

Importante: Observe que o seu ID do aplicativo é o seu Chave de API.

Siga estas práticas recomendadas para manter a segurança do seu aplicativo.

A Vonage reconhece que a segurança é um fator essencial para qualquer empresa interessada em integrar comunicações em tempo real ao seu site, aplicativo ou serviço. A plataforma da Vonage é confiável e segura, permitindo que você desenvolva Applications que atendam às necessidades de segurança da sua empresa, do seu setor ou dos seus clientes.

Perguntas frequentes sobre segurança

O tráfego de voz e vídeo é criptografado durante a sessão do WebRTC?

Sim, todo o tráfego de mídia é criptografado, independentemente do dispositivo que você usar (web ou celular) ou da configuração de sessão escolhida (P2P ou multipartidária). Isso significa que você está seguro ao usar a solução da Vonage, mesmo que a utilize em um ponto de acesso público aberto.

Além disso, em aplicativos da web, a publicação só é compatível com páginas HTTPS.

Isso se baseia em uma solução proprietária?

Não, não acreditamos em soluções proprietárias quando se trata de segurança. O Vonage baseia-se inteiramente em padrões comprovados, elaborados por especialistas do setor e utilizados há anos em produtos comerciais. Os protocolos principais que garantem a segurança do WebRTC do Vonage são o SRTP, para criptografia do tráfego de mídia, e o DTLS-SRTP, para negociação de chaves, ambos definidos pela IETF.

Quais são os algoritmos de criptografia e a força das chaves que estão sendo utilizadas?

Os terminais compatíveis com WebRTC da Vonage utilizam a cifra AES com chaves de 128 bits para criptografar áudio e vídeo, e o HMAC-SHA1 para verificar a integridade dos dados.

A criptografia AES-256 está disponível nos clientes compatíveis como uma recurso adicional.

Quais chaves estão sendo usadas para a criptografia?

Os terminais geram chaves aleatórias no início da sessão e, além disso, elas são alteradas periodicamente durante a conversa para torná-la ainda mais segura.

Isso requer alguma interação com o usuário?

Não, tudo acontece nos bastidores, sem qualquer interação com o usuário.

Isso exige alguma alteração nos meus aplicativos baseados no Vonage?

Não, a API da Vonage não muda. A API da Vonage não expõe esses detalhes de baixo nível aos desenvolvedores.

Isso afeta a largura de banda e a qualidade da videoconferência?

Sim, mas é muito baixo. Ele aumenta o tamanho de cada pacote de áudio e vídeo em 8 bytes, mas isso representa menos de 1% da taxa de bits típica de uma sessão. Quanto ao atraso, a estrutura de criptografia SRTP foi projetada especificamente para aplicações em tempo real, e o impacto é totalmente imperceptível.

Isso afeta o consumo da CPU ou da bateria?

Sim, mas o custo da codificação e decodificação de áudio e vídeo é significativamente maior do que o custo da criptografia e descriptografia.

Melhores práticas de segurança

Quer você seja novo na plataforma da Vonage ou já tenha anos de experiência, aqui está um conjunto útil de práticas recomendadas que você pode adotar ao desenvolver com a Vonage para ajudá-lo a criar um aplicativo seguro.

Servir conteúdo usando URLs HTTPS

Em aplicativos da web, a publicação de vídeos só é compatível com páginas HTTPS.

Informações pessoais

Mantenha a chave e o segredo da API em sigilo e protegidos

Importante: Observe que o seu ID do aplicativo é o seu Chave de API.

A chave e o segredo da API são usados para criar tokens que concedem acesso a sessões, recuperam metadados do arquivo e alteram as credenciais de armazenamento do arquivo, além de outras operações administrativas na sua Account.

Para evitar comprometer suas credenciais, você deve sempre manter seu segredo da API em sigilo. Algumas medidas importantes que você pode tomar:

  • Nunca salve o segredo da API em nenhum repositório público de código-fonte.
  • Nunca salve o segredo da API em nenhuma biblioteca do lado do cliente, nem mesmo em SDKs móveis compilados.
  • Utilize apenas URLs HTTPS para fazer chamadas REST aos servidores da Vonage.

Gerar um ID de sessão exclusivo por chamada e um token por participante

É necessário gerar um ID de sessão para iniciar uma chamada. Os tokens que permitem que os participantes entrem na chamada são exclusivos para cada ID de sessão. Os tokens têm prazo de validade, mas esse prazo pode ser maior do que a duração da sua chamada. Portanto, se você tiver reuniões consecutivas usando o mesmo ID de sessão, os usuários que entraram anteriormente ainda poderão se conectar à nova reunião.

Para evitar isso:

  • Gerar um ID de sessão exclusivo para cada nova reunião
  • Gere um token exclusivo para cada participante dessa reunião.

Veja esse assunto sobre como criar sessões. Consulte esse assunto sobre como gerar tokens.

Certifique-se de que o servidor que gera o token esteja atrás de um endpoint autenticado

É importante colocar o servidor que gera o token atrás de um endpoint autenticado, pois qualquer pessoa com acesso a esse servidor poderia acabar gerando novos tokens e fazer uso indevido do aplicativo.

Não utilize informações pessoais nos dados do token nem no campo “nome” do editor

Os dados do token é uma string que contém metadados que descrevem a conexão no SDK do servidor, e o nome do editor é definido ao criar um editor no Client SDK. Ambos os campos podem ser expostos a outros participantes da sessão e também podem ser visualizados por meio da ferramenta Inspector e dos registros internos da Vonage.

Isso significa que você nunca deve inserir informações confidenciais ou pessoais não criptografadas nesses campos.

Se você precisar associar a identidade do usuário a um stream, use identificadores no nível do aplicativo (como IDs de usuário) e resolva-os dentro do seu próprio aplicativo, em vez de incorporar dados pessoais nos campos da Video API.

Modo de retransmissão vs. modo de roteamento

Criptografia de ponta a ponta de mídia

Durante uma sessão roteada, os fluxos de mídia são temporariamente descriptografados enquanto permanecem nos servidores em nuvem da Video Platform e, em seguida, são imediatamente criptografados novamente antes de serem enviados pela internet ao cliente assinante — a menos que você utilize o criptografia de ponta a ponta recurso. Essa descriptografia é necessária para o gerenciamento de sessões em grupo, o controle de qualidade inteligente e recursos que exigem decodificação de mídia — como arquivamento, transmissões ao vivo, Experience Composer, Audio Connector e interconexão SIP (se utilizada). Com o uso de sessões roteadas, seus fluxos de mídia nunca são transmitidos sem criptografia na internet aberta.

Você pode usar criptografia de ponta a ponta para impedir que o Media Router tenha acesso à mídia em uma sessão roteada. Ao utilizar criptografia de ponta a ponta, recursos que exigem decodificação de mídia (como arquivamento, etc.) não são suportados.

Além disso, se sua aplicação exigir criptografia ininterrupta de ponta a ponta de todas as mídias, você pode optar por usar sessões retransmitidas. Esteja ciente de que não será possível utilizar recursos que exijam decodificação de mídia (como arquivamento, etc.), e que o desempenho não será tão bem gerenciado em redes com baixa largura de banda ou alta perda de pacotes, nem ao utilizar grupos.

Arquivamento

A Vonage oferece diversas maneiras de garantir a segurança de suas sessões arquivadas.

Diferentes níveis de segurança dos arquivos

Você pode proteger seus arquivos das seguintes maneiras:

  • Use a criptografia da Vonage — Com o arquivamento criptografado, os dados de vídeo e áudio em um arquivo são criptografados por meio de um certificado de chave pública fornecido por você à Vonage. Isso permite que você crie arquivos nos quais os dados nunca ficam armazenados em estado não criptografado. Entre os métodos disponíveis para proteger seus arquivos, esse oferece o mais alto nível de segurança. Esse recurso está disponível como um recurso adicional. Para obter mais informações, consulte o Criptografia da Vonage documentação.

Gerenciar a exclusão de arquivos

Um arquivo enviado com sucesso para o seu armazenamento será automaticamente excluído do servidor de arquivamento no momento do envio.

Caso o upload não seja bem-sucedido, o armazenamento é oferecido como opção alternativa padrão. Isso significa que o arquivo ficará armazenado por 72 horas no servidor.

Você receberá um aviso por e-mail sempre que um arquivo não for enviado para o seu armazenamento. Em seguida, você poderá usar a API REST para baixar o arquivo a partir da URL do arquivo.

Após o download, você pode optar por excluir imediatamente o arquivo compactado para evitar que ele permaneça no armazenamento durante o restante do período de fallback.

Para evitar esse armazenamento de reserva, faça login na sua Account da Video API, selecione o projeto e configure a opção para desativar o recurso de armazenamento de arquivo como alternativa.

Veja o Documentação da API para obter mais informações sobre como excluir um arquivo.

Observação: O armazenamento de reserva só pode ser desativado se você tiver configurado um armazenamento de arquivo personalizado. Consulte a documentação sobre como configurar o armazenamento de arquivo em S3 e Azure.

Controlar quem pode iniciar o arquivamento

Só é possível arquivar uma sessão usando a API REST. Para controlar quem pode iniciar o arquivamento, você pode definir programaticamente qual visualização do aplicativo inclui a opção de iniciar o arquivamento. Os usuários não autorizados terão uma visualização limitada, sem a opção de arquivar.

Além de autenticar seus próprios usuários, você também deve considerar uma estratégia de autorização. Depois de saber quem é o usuário (autenticação) e de ter certeza de que ele está, de fato, autorizado a iniciar um arquivamento (autorização), você reduz o risco de que algum usuário não autorizado provoque a gravação de arquivamentos.

Garantir um conjunto mínimo de privilégios

O conjunto mínimo de permissões necessárias para enviar arquivos para o nosso armazenamento é abordado em esse assunto.

Os parceiros não devem conceder nenhuma permissão adicional às credenciais que armazenam na Vonage.

Alertas e controles

Limitar o número máximo de usuários em uma sessão

Para ter mais controle sobre o número de pessoas em uma sessão, seu aplicativo deve limitar o número máximo de usuários por sessão. Isso pode ser útil se você estiver tentando restringir o uso.

Exibir o número de assinantes

Você também pode configurar uma contagem de assinantes para ser exibida em seu aplicativo. Essa é uma maneira útil de saber quando uma conexão está assinando, mas não publicando.

Configurar permissões de moderador para forçar a desconexão

A plataforma Vonage oferece a possibilidade de remover um usuário de uma sessão. Por exemplo, em caso de violação dos termos de serviço, é possível permitir que o moderador da sessão remova o participante infrator por meio de desconexão forçada ou cancelamento forçado da publicação. Consulte esse assunto para mais informações.

Atribua permissões exclusivas para assinantes àqueles que não precisam publicar

Em alguns casos, talvez você queira limitar o número de pessoas que podem publicar em uma sessão. Isso é feito ao não conceder permissões de publicação a todos os participantes.

Veja esse assunto para gerar tokens com as funções corretas.

Restrição do tráfego aos servidores regionais

Você pode usar o Zonas de mídia regionais recurso para encaminhar todos os fluxos de mídia para servidores de mídia dentro de uma região geográfica especificada.

Além de restringir o tráfego de mídia, você pode usar o Proxy da UE recurso para restringir não relacionado à mídia tráfego para utilizar servidores dentro da União Europeia.

Importante: Observe que o seu ID do aplicativo é o seu Chave de API.

Camada de Segurança e Transporte

Criptografia TLS

A Video API da Vonage agora oferece suporte ao TLS 1.3 e ao TLS 1.2 para todas as comunicações da API, proporcionando maior segurança e desempenho para suas sessões de vídeo. Essa atualização garante a compatibilidade com os padrões modernos de criptografia e protege seus dados em trânsito.

Principais benefícios:

  • Segurança aprimorada: Algoritmos criptográficos mais robustos e maior sigilo prospectivo com o TLS 1.3
  • Melhor desempenho: Latência de conexão reduzida graças a um processo de handshake simplificado
  • Negociação automática: Os clientes utilizam automaticamente a versão mais alta do TLS compatível

Todas as conexões com pontos de extremidade da API são protegidas por TLS por padrão. Não são necessárias alterações no código, pois os SDKs e clientes HTTP modernos preferem automaticamente a versão mais alta de TLS compatível (TLS 1.3 ou 1.2). No entanto, é recomendável usar sempre as versões mais recentes dos SDKs para se beneficiar das melhorias mais recentes em segurança e desempenho.