A criptografia geralmente é um assunto de segurança, mas também é importante para a privacidade. O objetivo da criptografia é impedir que outras pessoas leiam as informações criptografadas, mas impedir que outras pessoas leiam suas informações é uma maneira de mantê-las privadas. Muitas vezes, um usuário tem limitações de quanto ele pode fazer isso, mas com sua assistência como provedor do serviço que está usando, a criptografia pode ajudar a manter os dados dele.
Há três maneiras relevantes de aplicar a criptografia para ajudar na privacidade do usuário: criptografia em trânsito, criptografia em repouso e criptografia de ponta a ponta:
- A criptografia em trânsito mantém os dados criptografados entre o usuário e seu site, ou seja, HTTPS. Você provavelmente já configurou o HTTPS nos seus sites, mas tem certeza de que todos os dados em trânsito para eles são criptografados? É para isso que servem o redirecionamento e o HSTS. Eles são descritos abaixo e precisam fazer parte da configuração de HTTPS.
- A criptografia em repouso é a criptografia dos dados armazenados nos seus servidores. Isso protege contra vazamentos de dados e é uma parte importante da sua postura de segurança.
- A criptografia de ponta a ponta é a criptografia dos dados no cliente antes que eles cheguem ao servidor. Isso protege os dados do usuário até mesmo de você: é possível armazenar os dados dos seus usuários, mas não lê-los. Isso é difícil de implementar e não é adequado para todos os tipos de aplicativo, mas é uma grande ajuda para a privacidade do usuário, porque ninguém pode ver os dados além de si mesmo.
HTTPS
A primeira mudança é disponibilizar seu serviço da Web por HTTPS. É muito provável que você já tenha feito isso, mas se não for, é uma etapa importante. HTTPS é HTTP, o protocolo que um navegador usa para solicitar páginas da Web de um servidor, mas criptografado com SSL. Isso significa que um invasor externo não pode ler ou interferir em uma solicitação HTTPS entre o remetente (seu usuário) e o destinatário (você), porque ela é criptografada e não pode ler ou modificar essa solicitação. Isso é criptografia em trânsito: durante a transferência dos dados do usuário para você ou de você para o usuário. A criptografia HTTPS em trânsito também impede que o ISP do usuário, ou o provedor do Wi-Fi usado, leia os dados enviados a você como parte da relação com seu serviço. Isso também pode afetar os recursos do seu serviço: muitos usos de APIs JavaScript existentes exigem que o site seja disponibilizado por HTTPS. O MDN tem uma lista mais abrangente, mas as APIs gerenciadas por trás de um contexto seguro incluem service workers, notificações push, compartilhamento na Web e criptografia da Web, além de algumas APIs de dispositivos.
Para exibir seu site por HTTPS, é necessário um certificado SSL. Eles podem ser criados sem custo financeiro com a Let's Encrypt ou, geralmente, pelo seu serviço de hospedagem, se você estiver usando um. Também é possível usar um serviço de terceiros que "proxime" seu serviço da Web e pode fornecer HTTPS, além de serviços de armazenamento em cache e CDN. Há vários exemplos desses serviços, como o Cloudflare e o Fastly. A escolha exata entre esses serviços depende da sua infraestrutura atual. No passado, a implementação do HTTPS era trabalhosa ou cara, e é por isso que ele tendia a ser usado apenas em páginas de pagamento ou origens particularmente seguras. No entanto, certificados disponíveis sem custo financeiro, melhorias nos padrões e a maior proliferação de navegadores removeram todos esses obstáculos.
O que fazer
- Ative o HTTPS nos seus servidores para tudo (seja qual for o método escolhido).
- Considere usar um proxy na frente dos servidores, como o Cloudflare (httpsiseasy.com/ explica o processo).
- Let's Encrypt, orientará você no processo de criação do seu próprio certificado SSL da Let's Encrypt.
- Também é possível usar o OpenSSL diretamente para criar seu próprio certificado e tê-lo assinado pela autoridade certificadora (CA) de sua escolha. A seção Ativar HTTPS explica como fazer isso em detalhes.
A abordagem escolhida depende das compensações de negócios. Ter um terceiro gerenciando a conexão SSL para você é o mais fácil de configurar e traz outros benefícios, como balanceamento de carga, armazenamento em cache e análises. Mas isso também aparece com uma entrega óbvia de algum controle a esses terceiros, além de uma dependência inevitável dos serviços que oferece (e possível pagamento, dependendo dos serviços que você usa e dos seus níveis de tráfego).
A geração de certificados e a assinatura deles por uma AC era a forma de realizar o processo SSL. No entanto, o uso do Let's Encrypt pode ser mais fácil se tiver suporte do seu provedor ou se a equipe do servidor for tecnicamente capacitado para isso. Além disso, o uso é sem custo financeiro. Também é comum que seu provedor ofereça o SSL como um serviço se você estiver usando algo em um nível superior à hospedagem na nuvem. Por isso, vale a pena verificar.
Por que
A segurança faz parte da sua história de privacidade: conseguir demonstrar que você mantém os dados do usuário seguros contra interferências ajuda a criar confiança. Se você não usa HTTPS, seus sites também são sinalizados como "não seguros" pelos navegadores (isso é há algum tempo). As APIs JavaScript existentes geralmente estão disponíveis apenas para páginas HTTPS ("origens seguras"). Isso também protege os usuários contra o uso da Web pelo ISP. Essa certamente é uma prática recomendada. Há pouca ou nenhuma razão para não usar HTTPS em sites atualmente.
Como os navegadores apresentam uma página HTTP (não segura)
Redirecionar para HTTPS
Caso seu site esteja disponível em URLs http: e https:, redirecione todos os acessos a URLs http para https. Isso acontece pelos motivos acima e também garante que seu site não apareça em whynohttps.com se tornar famoso. Como fazer isso depende muito da sua infraestrutura. Se você estiver hospedado na AWS, será possível usar um balanceador de carga clássico ou de aplicativo. O Google Cloud é semelhante. No Azure, é possível criar uma porta frontal, no Node com Express verifique a request.secure, capturar todas as portas 80 e retornar 301 e, no Apache, usar uma RewriteRule. Se você estiver usando um serviço de hospedagem, é provável que eles processem automaticamente o redirecionamento para URLs HTTPS por você, como Netlify, Firebase e GitHub Pages, entre muitos outros.
HSTS
HSTS é a abreviação de "HTTP Strict-Transport-Security" e é uma forma de impedir que um navegador use HTTPS para seu serviço por mais tempo. Quando estiver satisfeito com a migração para HTTPS, ou se já tiver feito isso, adicione um cabeçalho de resposta HTTP Strict-Transport-Security às respostas de saída. Um navegador que já acessou seu site antes vai registrar a visualização desse cabeçalho e, desse momento em diante, vai acessar automaticamente o site como HTTPS, mesmo que você solicite HTTP. Isso evita o redirecionamento como mostrado acima: é como se o navegador "upgrade" silenciosamente todas as solicitações do seu serviço para usar HTTPS.
Da mesma forma, é possível veicular um cabeçalho Upgrade-Insecure-Requests junto com suas páginas. Isso faz algo diferente de, mas está relacionado ao Strict-Transport-Security. Se você adicionar Upgrade-Insecure-Requests: 1, as solicitações desta página para outros recursos (imagens, scripts) serão solicitadas como https, mesmo que o link seja http. No entanto, o navegador não solicitará novamente a página em si como https e não se lembrará da próxima vez. Na prática, a solicitação de upgrade não segura é útil quando você converte um site existente com muitos links para HTTPS e é difícil converter os URLs de link no conteúdo, mas é melhor alterar o conteúdo sempre que possível.
O HSTS é principalmente um recurso de segurança: ele "bloqueia" seu site em HTTPS para os usuários que já acessaram o site antes. No entanto, como mostrado acima, o HTTPS é bom para a privacidade e o HSTS é bom para o HTTPS. Da mesma forma, as solicitações não seguras de upgrade não são necessárias se você estiver atualizando todo o conteúdo, mas é uma abordagem útil com o uso de "cintos e chaves" para aumentar a defesa e garantir que o site sempre seja HTTPS.
O que fazer
Adicione o cabeçalho HSTS às respostas enviadas:
Strict-Transport-Security: max-age=300; includeSubDomains
O parâmetro max-age determina por quanto tempo, em segundos, o navegador deve se lembrar e aplicar o upgrade de HTTPS. Aqui, definimos como 300 segundos, ou seja, cinco minutos. O valor seria de 6.3072.000, o que equivale a dois anos, é o valor recomendado pela hstspreload.org, mas é muito difícil de recuperar se houver problemas. Portanto, é recomendável definir esse valor com um número baixo no início (300), testar para confirmar se não há nada de errado e aumentar o número em etapas.
Adicione os cabeçalhos Upgrade-Insecure-Requests às respostas enviadas:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Criptografia de ponta a ponta
Uma boa maneira de manter a privacidade dos dados do usuário é não mostrá-los a ninguém além do usuário, incluindo você. Isso ajuda muito com sua postura de confiança: se você não tem os dados dos usuários, fica claro que não é possível fazer nada com eles que eles não gostariam de usar. Uma maneira de fazer isso é não deixar que os dados do usuário saiam do dispositivo, armazenando tudo no lado do cliente. Essa abordagem funciona, mas há limitações para um aplicativo puro do lado do cliente: o armazenamento de dados do navegador pode ser limitado em tamanho e, em alguns navegadores, pode ser apagado com pouco ou nenhum aviso. Também é difícil ou impossível acessar os dados em dois dispositivos, como um laptop e um smartphone. Por esse motivo, pode ser útil enviar dados ao servidor como normalmente, mas criptografá-los com uma chave conhecida somente pelo usuário, para que o servidor não possa acessá-los (porque não pode descriptografá-los), mas pode armazená-los.
Como funciona?
Essa abordagem é usada com frequência por aplicativos de mensagens, em que é chamada de "criptografia de ponta a ponta" ou "e2e". Dessa forma, duas pessoas que conhecem as chaves umas das outras podem criptografar e descriptografar as mensagens de um para o outro e enviá-las pelo provedor de mensagens, mas o provedor (que não tem essas chaves) não pode ler as mensagens. A maioria dos aplicativos não é de mensagens, mas é possível combinar as duas abordagens (um armazenamento de dados exclusivo do lado do cliente e a criptografia de dados com uma chave conhecida pelo cliente) para armazenar dados no local, mas também enviá-los criptografados para o servidor. É importante notar que essa abordagem tem limitações: isso não é possível para todos os serviços e, em particular, não pode ser usado se você, como provedor de serviços, precisa de acesso ao que o usuário está armazenando. Conforme descrito na parte 2 desta série, é melhor obedecer ao princípio de minimização de dados e, se possível, evite coletar dados. Se o usuário precisar de armazenamento de dados, mas você não precisar de acesso a esses dados para fornecer o serviço, a criptografia de ponta a ponta será uma alternativa útil. Se você oferece serviços que exigem a visualização do que o usuário armazena para fornecer o serviço, a criptografia de ponta a ponta não é adequada. Caso contrário, o JavaScript do lado do cliente do serviço da Web poderá criptografar todos os dados enviados ao servidor e descriptografar todos os dados recebidos.
Exemplo: Excalidraw
O Excalidraw faz isso e explica como em uma postagem do blog. Ele é um app
de desenho vetorial que armazena desenhos no servidor e são criptografados com uma chave escolhida aleatoriamente. Parte do motivo pelo qual
o Excalidraw pode implementar essa criptografia de ponta a ponta com relativamente pouco código é que as bibliotecas criptográficas agora são integradas
ao navegador com window.crypto, que é um conjunto
de APIs JavaScript com suporte em todos os navegadores modernos. A criptografia é difícil, e a implementação
dos algoritmos traz muitos casos extremos. Fazer o trabalho pesado do navegador torna a criptografia mais acessível para
os desenvolvedores da Web e, portanto, facilita a implementação de privacidade com dados criptografados. Como o Excalidraw descreve, a chave de criptografia permanece no lado do cliente porque faz parte do fragmento do URL: quando um navegador visita um URL https://example.com/path?param=1#fraghere, o caminho do URL (/path) e os parâmetros (param=1) são transmitidos para o servidor (example.com), mas o fragmento (fraghere) não é. O servidor nunca o vê. Isso significa que, mesmo se os dados
criptografados passarem pelo servidor, a chave de criptografia não vai e, portanto, a privacidade é preservada porque os dados são criptografados de ponta a ponta.
Limitações
Essa abordagem de criptografia de dados do usuário não é infalível. Ela contribui para a postura de confiança dos usuários, mas não pode substituir totalmente. Seus usuários ainda precisarão confiar no seu serviço, porque é possível, a qualquer momento, trocar o JavaScript do lado do cliente por algum JavaScript semelhante que não criptografa de forma impenetrável os dados. Além disso, embora seja possível como um usuário detectar se um site que você está usando fez isso, é extremamente difícil fazer isso. Na prática, seus usuários ainda precisam confiar que um serviço malicioso não é deliberadamente lido e não é confiável porque você não confia que um serviço é confiável e não é confiável porque
Também é importante lembrar que um dos objetivos da criptografia de ponta a ponta é impedir que você, proprietário do site, possa ler os dados. Isso é bom para a privacidade, mas também significa que, se houver problemas, você não poderá ajudar. Em essência, um serviço que usa criptografia de ponta a ponta coloca o usuário no comando das chaves de criptografia. Isso pode não ser óbvio ou explícito, mas alguém precisa ter a chave, e se os dados forem mantidos privados para você, então essa pessoa não é você. Se elas forem perdidas, não haverá nada que você possa fazer para ajudar, e provavelmente todos os dados criptografados com essas chaves também poderão ser perdidos. Há um equilíbrio entre privacidade e usabilidade: manter os dados privados de todos usando criptografia, mas também evitar forçar os usuários a serem especialistas em criptologia que gerenciam as próprias chaves de maneira segura.
Criptografia em repouso
Além de criptografar os dados em trânsito dos seus usuários, também é importante criptografar os dados que você armazenou no servidor. Isso ajuda a proteger contra violações de dados, porque qualquer pessoa que tenha acesso não autorizado aos seus dados armazenados terá dados criptografados, que não terão as chaves para descriptografar. Há duas abordagens diferentes e complementares para criptografar dados em repouso: criptografia que você adiciona e criptografia adicionada pelo seu provedor de armazenamento em nuvem (se você estiver usando um provedor de armazenamento em nuvem). A criptografia do provedor de armazenamento não oferece muita proteção contra violações de dados pelo seu software, porque a criptografia do provedor de armazenamento geralmente é transparente para você, como usuário do serviço, mas ajuda contra violações que ocorrem na infraestrutura do provedor. Em geral, ele é simples de ativar e, por isso, vale a pena considerar isso. Esse campo muda rapidamente e sua equipe de segurança (ou engenheiros de segurança da sua equipe) são os melhores para aconselhar sobre isso, mas todos os provedores de armazenamento em nuvem oferecem criptografia em repouso para o armazenamento em blocos Amazon S3 configurando, Azure Storage e Google Cloud Storage por padrão, e para armazenamento de dados de banco de dados AWS RDS, SQL do Azure, entre outros. Verifique isso com seu provedor de armazenamento em nuvem, se estiver usando um. Lidar com criptografia de dados em repouso para proteger os dados do usuário contra violações de dados é mais difícil, porque a logística de gerenciar com segurança as chaves de criptografia e disponibilizá-las para o código sem disponibilizá-las aos invasores é um desafio. Este não é o melhor lugar para aconselhar sobre problemas de segurança nesse nível. Converse com seus engenheiros experientes em segurança ou com uma equipe dedicada sobre isso ou com agências de segurança externas.