Por que criptografar e-mails não é tão simples quanto parece

Views: 169
0 0
Read Time:4 Minute, 12 Second

A qualidade das comunicações protegidas importa – e muito. Se o material enviado for altamente confidencial e a legislação e/ou política exigir alta segurança, a criptografia oportunista pode não ser suficiente. Para as organizações, decidir qual solução de criptografia de e-mail usar geralmente não é tão simples e, de modo geral, não há uma única resposta correta.

Aqui discutiremos as diferentes opções e se uma combinação de métodos de criptografia pode ser a resposta.

Por que as organizações precisam de criptografia

A criptografia de uma mensagem de e-mail garante que terceiros não autorizados não possam lê-la. Para qualquer parte sem a devida autorização, a mensagem parecerá indecifrável.

Para as organizações, a confidencialidade da mensagem é crucial para impedir que informações potencialmente confidenciais cheguem a olhares indiscretos. Além disso, eles devem ser capazes de confirmar a integridade da mensagem e a identidade do remetente – sem isso, mensagens falsificadas podem ser enviadas.

A base da comunicação confidencial por e-mail é que tanto o remetente quanto o destinatário protegeram seus respectivos sistemas locais, fortalecendo o sistema operacional do host, empregando segurança do cliente, EDR, XDR e assim por diante.

Diferentes opções têm diferentes benefícios e desafios

Métodos de criptografia oportunistas de melhor esforço , como Outlook Message Encryption ( OME ) e várias soluções de terceiros (gateways de criptografia de e-mail, plug-ins e similares) têm o benefício de serem fáceis de usar. Eles também podem ser integrados de forma transparente a programas de e-mail (como o Outlook Message Encryption) e facilitam o contato com novas pessoas, sem a necessidade de troca prévia de chaves – caso a mensagem seja enviada para um usuário que não execute o mesmo sistema , um portal para abrir a mensagem normalmente é colocado à vista.

Além disso, eles geralmente podem ser integrados ao servidor de e-mail de saída com regras para aplicar a criptografia automaticamente, dependendo de regras definidas, como criptografia automatizada para determinados anexos, por exemplo.

Existe, no entanto, a possibilidade de uma parte não autorizada descriptografar a mensagem se ela obtiver acesso a ela primeiro. Isso representa uma ameaça real, pois a própria comunicação por e-mail não tem garantia de ser criptografada devido ao processo de entrega de e-mail depender de STARTTLS e esquemas de criptografia oportunistas semelhantes. Isso pode ser mitigado adicionando 2FA , como via código PIN SMS, que pode ajudar a melhorar a segurança (claro, o número do celular do destinatário deve ser conhecido ao enviar). E, em muitas situações, é importante também identificar de forma confiável a identidade do remetente: afinal, se qualquer um pode enviar mensagens, como diferenciar um remetente genuíno de um impostor?

Métodos de criptografia completa , como S/MIME e PGP/GPG, permitem total confidencialidade, onde apenas o destinatário pode descriptografar a mensagem de e-mail devido à possibilidade de verificar a identidade do remetente. No entanto, vários problemas surgem ao usar esse método. Há uma necessidade de gerenciamento de chaves onde as chaves precisam ser distribuídas, trocadas e mantidas atualizadas. Também há suporte limitado, pois o destinatário geralmente precisa usar a mesma solução que o remetente.

Normalmente, apenas um determinado subconjunto de contatos usa essa solução, levando à necessidade de usar várias soluções, dependendo do(s) destinatário(s). Isso também requer um esforço extra para determinar qual solução pode ser usada para o destinatário específico e se a solução é segura o suficiente para o material que está sendo enviado. Isso pode levar a uma interface de usuário complicada com opções diferentes e confusas, como “assinar apenas” ou “assinar e criptografar”. Torna-se muito fácil acabar escolhendo a opção errada, ou pior, esquecendo de usar a criptografia (já que geralmente deve ser selecionada especificamente).

Recentemente, o Google começou a oferecer a opção de usar S/MIME com o Gmail como “E2EE” ou “criptografia do lado do cliente”. Esta opção está atualmente em teste beta e disponível apenas para públicos limitados. No entanto, isso é um desenvolvimento significativo, pois pode resultar em uma adoção mais ampla da criptografia S/MIME, especialmente se estiver disponível para camadas gratuitas do Gmail.

O modelo de ameaça decide

Qual é a melhor solução? S/MIME ou PGP/GPG podem parecer soluções atraentes, mas os desafios no gerenciamento de chaves e a dificuldade em treinar pessoas para usá-los podem levar a uma adoção insatisfatória. Algumas soluções menos seguras podem ser usadas para a maioria das comunicações, enquanto as soluções mais seguras, como S/MIME ou GPG/PGP, podem ser usadas para outros destinatários.

Os usuários que precisam usar as soluções mais seguras devem ser instruídos sobre como identificar quando o método mais seguro é necessário e como usar a solução adequadamente (como gerenciamento de chaves e prática de envio e recebimento de e-mails criptografados). Em última análise, as demandas da organização específica e os casos de uso determinam as soluções que podem ser necessárias.

FONTE: HELPNET SECURITY

POSTS RELACIONADOS