Práticas recomendadas de segurança na Web

Práticas recomendadas para a segurança na Web

O Cloud CDN e o Cloud Load Balancing podem ajudar a cumprir as práticas recomendadas de segurança Web, quer esteja a publicar conteúdo a partir de instâncias do Compute Engine, de um contentor do Cloud Storage ou de uma origem externa localizada fora do Google Cloud.

Defina 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 é publicado em vários domínios
  • Se deve usar sempre TLS (HTTPS) ao estabelecer ligação a esse domínio

Normalmente, estes controlos são representados como cabeçalhos de resposta HTTP, que pode definir para cada back-end (origem, em termos de RFC) como cabeçalhos de resposta personalizados para a implementação do balanceador de carga de aplicações externo e do Cloud CDN.

Se estiver a usar o Cloud Storage e a publicar conteúdo Web a partir do seu contentor, pode usar o Cloud CDN antes do contentor de armazenamento para definir cabeçalhos de segurança Web e colocar em cache conteúdo popular.

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

Nome do cabeçalho Descrição Exemplo de utilização
Strict-Transport-Security (HSTS) Garante que os seus domínios têm certificados SSL (TLS) válidos antes de definir este cabeçalho.

Informa os clientes de que têm de estabelecer ligação ao seu domínio diretamente através de HTTPS (SSL/TLS), evitando a necessidade de redirecionar de HTTP para HTTPS, o que é mais lento e introduz o risco de um ataque man-in-the-middle.

A definição deste cabeçalho é efetivamente irreversível. Após colocar este cabeçalho em cache, os clientes de navegador modernos não tentam estabelecer ligações não HTTPS, e os utilizadores não podem aceder a nenhum domínio para o qual receberam este cabeçalho, mesmo que o SSL esteja inativo. Este comportamento impede que um atacante faça o downgrade do protocolo seguro para o HTTP não protegido (conhecido como um ataque de downgrade).

Quando publicar o cabeçalho Strict-Transport-Security, tenha cuidado ao adicionar as diretivas includeSubdomains ou preload. Estas diretivas exigem que qualquer subdomínio use HTTPS, incluindo quaisquer sites internos no mesmo domínio. Por exemplo, support.example.com quando publicado a partir de example.com.

Exigir que os clientes se liguem diretamente através de HTTPS para todas as ligações futuras, colocando esta diretiva em cache durante um período máximo de dois anos:

Strict-Transport-Security: max-age=3104000

X-Frame-Options Indique se um navegador pode renderizar uma página num elemento <frame>, <iframe>, <embed> ou <object>. Isto ajuda a evitar ataques de roubo de cliques, não permitindo que o seu conteúdo seja incorporado noutros sites. Recuse todos os iFrames do seu site: X-Frame-Options: DENY

Permitir que apenas o seu site se apresente em iFrame (incorporação): X-Frame-Options: SAMEORIGIN

Content-Security-Policy Para avaliar a Política de Segurança de Conteúdos do seu site, pode usar a ferramenta CSP Evaluator da Google. Não permita scripts inline e carregue apenas scripts através de HTTPS: Content-Security-Policy: default-src https:

Tenha cuidado ao introduzir novos cabeçalhos de segurança em Websites existentes, uma vez que podem danificar scripts de terceiros, conteúdo incorporado (por exemplo, em iFrames) ou outros aspetos dos seus sites. Antes de fazer alterações ao tráfego de produção, recomendamos que crie uma segunda instância do serviço ou contentor do back-end e faça testes.

Pode ler mais acerca dos cabeçalhos de segurança Web e das práticas recomendadas em web.dev, bem como no site de infosec da Mozilla.

TLS e gestão de certificados

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

  • São fornecidos sem custos
  • Pode ser facilmente implementado nos seus equilibradores de carga
  • Renovar automaticamente
  • São distribuídos globalmente a todas as localizações periféricas da Google

O TLS oferece autenticidade ao validar que os dados não foram modificados em trânsito. Os certificados TLS garantem a confidencialidade, certificando-se de que um intruso não consegue determinar o que está a ser trocado entre os utilizadores e os servidores. Isto é importante para a privacidade e a segurança do utilizador.

Com os certificados SSL, pode beneficiar de protocolos de transporte modernos, como o HTTP/2 e o protocolo QUIC da Google, que requerem SSL (TLS). Estes protocolos melhoram diretamente o desempenho do conteúdo Web, a entrega de multimédia (como streaming de vídeo) e a fiabilidade em redes congestionadas.

Google Cloud Suporta protocolos TLS modernos (como o TLS 1.3) nos serviços Cloud Load Balancing e Cloud CDN.

Pode usar políticas de SSL para aumentar a versão mínima do TLS. Recomendamos que atualize a versão para TLS v1.2 se não precisar de suportar clientes mais antigos, como dispositivos incorporados ou clientes não baseados em navegador mais antigos (com mais de 10 anos). A nível global, o TLS v1.0 e o TLS v1.1 representam menos de 0,5% das ligações em todos os Google Cloud. Se precisar de identificar ou associar clientes específicos a versões desatualizadas do TLS, pode usar a variável {tls_version} num cabeçalho de pedido. Em seguida, pode registar estas informações.

O que se segue?