Práticas recomendadas de segurança da Web

Práticas recomendadas para segurança na Web

O Cloud CDN e o Cloud Load Balancing podem ajudar no atendimento às práticas recomendadas de segurança da Web, seja na disponibilização de conteúdo de instâncias do Compute Engine ou de um bucket do Cloud Storage ou de uma origem externa localizada fora do Google Cloud.

Definir cabeçalhos de segurança

A especificação HTTP tem vários cabeçalhos que controlam o seguinte:

  • Comportamento do cliente
  • Como o conteúdo é incorporado
  • Como o conteúdo é disponibilizado em vários domínios
  • Se o TLS (HTTPS) sempre será usado nas conexões com esse domínio.

Esses controles normalmente são representados como cabeçalhos de resposta HTTP, que podem ser definidos para cada back-end (origem, em termos de CDN) como cabeçalhos de resposta personalizados para a implantação do balanceador de carga de aplicativo externo e do Cloud CDN.

Se você estiver usando o Cloud Storage e disponibilizando conteúdo da Web no bucket, use o Cloud CDN na frente do bucket de armazenamento para definir cabeçalhos de segurança da Web e armazenar em cache conteúdo em alta.

Os cabeçalhos de segurança da Web mais úteis são definidos na tabela a seguir.

Nome do cabeçalho Descrição Exemplo de uso
Strict-Transport-Security (HSTS) Garante que os domínios tenham certificados SSL (TLS) válidos antes da definição desse cabeçalho.

Informa aos clientes que eles precisam se conectar ao seu domínio diretamente por HTTPS (SSL/TLS), evitando a necessidade do redirecionamento de HTTP para HTTPS, que é mais lento e apresenta o risco de ataques do tipo "person-in-the-middle".

A configuração desse cabeçalho é irreversível. Depois de armazenar esse cabeçalho em cache, clientes de navegadores mais recentes não tentam conexões não HTTPS e os usuários não conseguem acessar domínios para os quais tenham recebido esse cabeçalho, mesmo que o SSL esteja desativado. Esse comportamento impede que um invasor faça downgrade do protocolo seguro para o HTTP desprotegido, conhecido como ataque de downgrade.

Ao disponibilizar o cabeçalho Strict-Transport-Security, tenha cuidado ao adicionar a diretiva includeSubdomains ou preload. Essas diretivas exigem que qualquer subdomínio use HTTPS, incluindo sites internos no mesmo domínio. Por exemplo, support.example.com quando exibido por example.com.

Exija que os clientes se conectem diretamente por HTTPS em todas as conexões futuras, armazenando em cache esta diretiva por até dois anos:

Strict-Transport-Security: max-age=3104000

X-Frame-Options Indica se um navegador pode renderizar uma página em um <frame>, <iframe>, <embed> ou <object>. Isso ajuda a evitar ataques de click-jacking, ao não permitir que seu conteúdo seja incorporado a outros sites. Negar todo o iframing do seu site: X-Frame-Options: DENY

Permitir que apenas seu site tenha um iframe (incorporado): X-Frame-Options: SAMEORIGIN

Content-Security-Policy Para avaliar a Política de Segurança de Conteúdo do seu site, use a ferramenta CSP Evaluator do Google. Não permita scripts in-line e só carregue scripts por HTTPS: Content-Security-Policy: default-src https:

Tenha cuidado ao introduzir novos cabeçalhos de segurança em sites atuais, porque eles podem corromper scripts de terceiros, conteúdo incorporado (por exemplo, em iframes) ou outros aspectos dos seus sites. Antes de fazer alterações no tráfego de produção, recomendamos criar uma segunda instância do bucket de back-end ou do serviço de back-end e testar.

Leia mais sobre cabeçalhos e práticas recomendadas de segurança da Web em web.dev e também no site infosec do Mozilla.

TLS e gerenciamento de certificados

Os certificados gerenciados têm as seguintes características:

  • São fornecidos sem custo
  • Podem ser facilmente implantados nos balanceadores de carga.
  • Renovação automática
  • São distribuídos globalmente em todos os locais de borda do Google

O TLS fornece autenticidade ao validar que os dados não foram modificados em trânsito. Os certificados TLS fornecem confidencialidade ao garantir que uma pessoa bisbilhoteira não possa determinar o que está sendo trocado entre usuários e servidores. Isso é importante para a privacidade e a segurança do usuário.

Com os certificados SSL, você pode se beneficiar de protocolos de transporte modernos, como o HTTP/2 e o protocolo QUIC do Google, que exigem SSL (TLS). Esses protocolos melhoram diretamente o desempenho do conteúdo da Web, o envio de mídia (como streaming de vídeo) e a confiabilidade em redes congestionadas.

OGoogle Cloud é compatível com protocolos TLS modernos (como TLS 1.3) em todos os serviços do Cloud Load Balancing e do Cloud CDN.

Você pode usar políticas de SSL para atualizar a versão mínima do TLS. Recomendamos atualizar a versão para o TLS v1.2 se você não precisar de compatibilidade com clientes mais antigos, como dispositivos incorporados, ou ainda mais antigos (mais de 10 anos), sem navegador. Globalmente, TLS v1.0 e TLS v1.1 representam menos de 0,5% das conexões em todo o Google Cloud. Se for preciso identificar ou associar clientes específicos a versões desatualizadas do TLS, use a variável {tls_version} em um cabeçalho da solicitação. É possível registrar essas informações.

A seguir