O que é segurança de e-mail? Melhores práticas para 2023

A segurança de e-mail refere-se a várias medidas de segurança cibernética para proteger o acesso e o conteúdo de uma conta ou serviço de e-mail.

A segurança de e-mail adequada pode proteger informações confidenciais em comunicações por e-mail, evitar ataques de phishing, spear phishing e falsificação de e-mail e proteger contra acesso não autorizado, perda ou comprometimento de um ou mais endereços de e-mail.

Por que a segurança de e-mail é importante?

A segurança de e-mail é importante porque o e-mail malicioso é um meio popular para espalhar ransomware, spyware, worms, diferentes tipos de malware, ataques de engenharia social como phishing ou spear phishing e-mails e outras ameaças cibernéticas.

O e-mail também é um vetor de ataque comum para invasores que desejam entrar em uma rede corporativa para roubar dados confidenciais, como informações de identificação pessoal (PII), informações de saúde protegidas (PHI) ou propriedade intelectual (espionagem industrial).

Isso pode ajudar na conformidade com regulamentos como GDPR, LGPD, Lei SHIELD, CCPA, CPS 234, evitando violações de dados.

O e-mail seguro é necessário para contas de e-mail individuais e comerciais, e há várias medidas que as organizações devem tomar para aprimorar a segurança do e-mail que descrevemos abaixo.

Qual é a base da segurança de e-mail?

O e-mail consiste em três componentes:

O envelope: preocupado com a forma como o e-mail é roteado, por exemplo, o caminho necessário para chegar à sua caixa de entrada
O(s) cabeçalho(s): contém informações sobre o remetente, o destinatário e vários detalhes de autenticação.
O corpo da mensagem: o conteúdo da mensagem, por exemplo, o que você lê e responde.

Os métodos de autenticação (SPF, DKIM e DMARC) permitem a prevenção de falsificação de e-mail (pessoas que fingem ser seu domínio) e a verificação do remetente, em grande parte dependem de registros DNS e adicionam ou verificam as informações fornecidas no:

Do cabeçalho: essa é a identidade do autor do e-mail, normalmente o que seu cliente de e-mail mostra quando você recebe um e-mail. Em última análise, você quer ter certeza de que o domínio mostrado é realmente quem enviou o e-mail. Isso só é possível quando você usa todos os métodos de autenticação descritos posteriormente neste artigo.
Cabeçalho Return-Path: A identidade do serviço de e-mail de envio: Esse valor é obtido do comando MAIL FROM enviado no início de uma transação SMTP pela máquina que envia o e-mail. Os servidores de e-mail e outros agentes de transferência de mensagens usam SMTP para enviar e receber mensagens de e-mail. Sistemas proprietários, como Microsoft Exchange e IBM Notes, e sistemas de webmail, como Outlook.com, Gmail e Yahoo! Mail, podem usar protocolos não padrão internamente, mas todos usam SMTP ao enviar ou receber e-mails de fora de seus próprios sistemas. O domínio no cabeçalho não precisa ser o mesmo que o domínio De e geralmente será diferente, por exemplo, se o e-mail for encaminhado por meio de uma lista de e-mails antes de chegar ao seu destino.

O que é o SPF (Sender Policy Framework)?

O SPF (Sender Policy Framework) é um método de autenticação de e-mail projetado para detectar a falsificação do endereço do remetente (cabeçalho Return-Path) durante a entrega de um e-mail.

O SPF permite que o servidor de e-mail de recebimento verifique durante a entrega de e-mail se um e-mail que afirma vir de um domínio específico foi enviado por um endereço IP autorizado pelo proprietário desse domínio.

Como implementar o SPF

Para implementar o SPF, você precisa adicionar um registro TXT DNS que liste todos os endereços IP autorizados a enviar e-mails em nome do seu domínio.

Cada domínio pode ter no máximo um registro SPF, definido como um tipo de registro TXT ou SPF.

Você pode gerar um registro SPF usando o Assistente SPF.

Qual é o formato de um registro SPF?

Os registros SPF são definidos como um simples pedaço de texto. Aqui está o registro da UpGuard como exemplo:

v=spf1 include:_spf.google.com include:mail.zendesk.com include:228391.spf01.hubspotemail.net ~all

Os registros SPF sempre começam com o elemento v=. Isso indica a versão do SPF usada. No momento da redação deste artigo, isso deve ser sempre spf1, pois essa é a versão mais comum do SPF compreendida pelas trocas de e-mail.

Um ou mais termos seguirão o indicador de versão. Eles definem as regras para as quais os hosts têm permissão para enviar e-mails do domínio ou fornecem informações adicionais para processar o registro SPF. Os termos são compostos de mecanismos e modificadores.

Como funcionam os mecanismos SPF?

Os mecanismos a seguir definem quais endereços IP têm permissão para enviar e-mails do domínio:

um
Mx
ip4
ip6
Existe

Um servidor de e-mail comparará o endereço IP do remetente com os endereços IP definidos nos mecanismos. Se o endereço IP corresponder a um dos mecanismos no registro SPF, ele seguirá a regra de manipulação resultante. A regra de tratamento padrão é neutra.

O mecanismo de inclusão permite que você autorize hosts fora de suas administrações especificando seus registros SPF.

O mecanismo all corresponde a qualquer endereço e geralmente é listado como o último mecanismo para definir como lidar com qualquer IP do remetente que não esteja incluído nos mecanismos anteriores.

Todos os mecanismos podem especificar qualificadores de como lidar com uma correspondência:

+: passe
-: falha
~: falha suave
?: neutro

Portanto, aplicando isso ao registro SPF do UpGuard, podemos ver que o UpGuard está usando a versão spf1, permite que _spf.google.com, mail.zendesk.com e 228391.spf01.hubspotemail.net enviem e-mails em nosso nome e, para quaisquer outras situações, ele falha suavemente.

Como funcionam os modificadores SPF?

Os modificadores são pares de nome/valor, separados por um sinal =, que fornecem informações adicionais.

O modificador de redirecionamento é usado quando você tem vários domínios e deseja aplicar o mesmo conteúdo SPF neles. Os redirecionamentos só devem ser usados quando você controla os dois domínios, caso contrário, uma inclusão é usada.

O modificador exp é usado para fornecer uma explicação no caso de um qualificador - (fail).

Quais são os resultados da verificação do FPS?

Estes são os possíveis resultados de uma verificação SPF, consulte RFC 7208 seção 8 para obter mais detalhes:

Nenhum: não existe nenhum registro SPF.
Neutro: O registro SPF foi encontrado sem nenhuma afirmação positiva ou negativa sobre o remetente, o resultado é equivalente a Nenhum.
Aprovado: o remetente está autorizado a enviar e-mails em nome do domínio.
Falha: O remetente não está autorizado e o servidor de e-mail pode optar por rejeitar o e-mail.
Falha suave: o remetente não está autorizado, mas o servidor de e-mail não deve rejeitar o e-mail com base apenas nesse resultado.

Por que o SPF não é suficiente para autenticar um e-mail?

O SPF sozinho só pode autenticar a origem da mensagem (Return-Path), mas não o autor original.

Não há nada que impeça um invasor de configurar sua própria caixa de correio e domínio, com um registro SPF que autoriza o endereço IP do invasor a enviar e-mails em nome desse domínio.

Qualquer e-mail enviado passaria nas verificações do SPF e eles ainda poderiam falsificar o cabeçalho From, que está fora do escopo do SPF.

Somente em combinação com DMARC e DKIM o SPF pode ser usado para evitar falsificação de e-mail, uma técnica frequentemente usada em campanhas de phishing e spear phishing.

O que é DomainKeys Identified Mail (DKIM)?

DomainKeys Identified Mail (DKIM) é um método de autenticação de e-mail projetado para detectar endereços de remetente falsificados em e-mails.

O DKIM permite que o destinatário verifique se um e-mail alegadamente proveniente de um domínio específico foi autorizado pelo proprietário desse domínio.

Isso é conseguido afixando uma assinatura digital, vinculada a um nome de domínio em cada mensagem de e-mail enviada.

O sistema do destinatário pode então verificar o e-mail procurando a chave pública do remetente, que é publicada no DNS.

Uma assinatura válida também garante que algumas partes do e-mail (como anexos de e-mail) não foram modificadas desde que a assinatura foi afixada. As assinaturas DKIM geralmente não são visíveis para os usuários finais e são afixadas ou verificadas pela infraestrutura, e não pelo autor e destinatários da mensagem.

Como implementar o DKIM

Assim como o SPF, a implementação do DKIM exige que você atualize seu DNS. É um pouco mais complicado do que o FPS, pois você precisa:

Escolha um seletor DKIM: um seletor pode ser o que você quiser, como uma palavra, um número ou uma sequência de letras e números. Especificado como um atributo para uma assinatura DKIM e é registrado no campo de cabeçalho DKIM-Signature. Como os seletores DKIM fornecem nomes de consulta DNS diferentes, o sistema usa os seletores como um componente de nome adicional para validação. Os seletores permitem várias chaves DKIM em um nome de domínio, o que pode fornecer controles diferentes entre departamentos, intervalos de datas ou terceiros que atuam em nome do seu domínio. Dois serviços ou produtos não devem usar o mesmo seletor.
Gerar um par de chaves pública-privada:Você pode gerar um registro DKIM aqui.
Publique o seletor e a chave pública: como registro TXT ou CNAME apontando para o DNS do seu provedor.
Anexar o token a cada e-mail enviado

Dito isso, os registros DKIM geralmente são fornecidos a você pela organização que está enviando seu e-mail, por exemplo, SendGrid, Postmark ou Google Apps.

Qual é o formato de um registro DKIM?

Os registros DKIM são definidos como um pedaço de texto. Aqui está o registro DKIM do UpGuard para o seletor s=google e a chave pública associada como exemplo:

Como funciona o DKIM?

O DKIM funciona afixando uma assinatura no e-mail como um cabeçalho, por exemplo:

Assinatura DKIM: v=1; a=rsa-sha256; c=relaxado/relaxado;

d=upguard.com; s=google;

h=mime-version:references:in-reply-to:from:date:message-id:subject:to;

bh=ewH2APsHZpkiGwY6K2zF2Es1X6R5cM87=; b=QoetI61NcfEB9ukMtPM8GPC26HcMWHK

A assinatura inclui o domínio responsável pela criação da assinatura, upguard.com (d=upguard.com) neste caso, bem como o seletor, google (s=google).

A assinatura foi criada usando a chave privada associada ao registro DKIM e à chave pública mostrada acima e é conhecida apenas pelo proprietário do domínio.

Qualquer pessoa pode validar que esta assinatura foi criada pela chave privada DKIM do seletor do Google da UpGuard usando a chave pública armazenada em nosso registro DNS TXT.

Qual é o benefício do DKIM?

Quando uma assinatura DKIM válida é afixada a um e-mail, o destinatário pode ter certeza de que a assinatura DKIM foi criada pelo proprietário desse domínio.

Por que o DKIM não é suficiente para autenticar um e-mail?

Uma assinatura DKIM válida apenas verifica se a assinatura DKIM foi criada pelo proprietário desse domínio. Isso não significa necessariamente que o domínio From seja o mesmo.

Um invasor pode facilmente criar uma assinatura DKIM válida para um domínio que ele controla enquanto ainda falsifica o domínio De.

Assim, como o SPF, o DKIM sozinho nem sempre é suficiente para autenticar o domínio no cabeçalho From.

O que é Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio (DMARC)?

O DMARC é um protocolo de autenticação de e-mail projetado para dar aos proprietários de domínio de e-mail a capacidade de proteger seu domínio contra uso não autorizado, por exemplo, falsificação de e-mail.

O objetivo e o resultado principal da implementação do DMARC é proteger um domínio de ser usado em ataques de comprometimento de e-mail comercial (BEC), e-mails de phishing, golpes de e-mail e outras ameaças de e-mail.

O DMARC fornece um mecanismo para:

Autenticar o domínio no cabeçalho De de um e-mail, com base nos resultados do SPF e do DKIM
Permitir que os proprietários de domínio definam uma política para lidar com e-mails com base no resultado dessa autenticação
Permitir que os proprietários de domínio obtenham relatórios de feedback dos destinatários de e-mail sobre os resultados das verificações do DMARC

Como implementar o DMARC

Assim como o SPF e o DKIM, a implementação do DMARC exige que você atualize seu DNS.

Depois que a entrada DNS do DMARC é publicada, qualquer servidor de e-mail de recebimento pode autenticar o e-mail recebido com base nas instruções publicadas pelo proprietário do domínio na entrada DNS. Se o e-mail passar na autenticação, ele será entregue e poderá ser confiável.

Se a verificação de e-mail falhar, o elemento p do registro DMARC é a parte mais importante do registro DMARC, pois informa ao servidor de e-mail de recebimento o que fazer, a saber:

Nenhum: o proprietário do domínio não solicita que nenhuma ação específica seja tomada em relação à entrega das mensagens. Isso é efetivamente o mesmo que não ter nenhum registro DMARC. Quaisquer políticas de filtragem de e-mail existentes não devem ser afetadas, por exemplo, SPF. Isso geralmente é usado por proprietários de domínio que desejam começar a coletar relatórios de feedback para determinar o impacto que o DMARC terá quando uma política mais rígida for aplicada.
Quarentena: o proprietário do domínio deseja que os destinatários de e-mail tenham e-mails que não passam na verificação do DMARC para serem tratados como suspeitos. Isso normalmente significa que o e-mail acabará em spam.
Rejeitar: o proprietário do domínio deseja que os destinatários de e-mail que não passam na verificação do DMARC rejeitem o e-mail.

Você pode gerar um registro DMARC aqui.

Qual é o formato de um registro DMARC?

A política DMARC, como SPF e DKIM, é armazenada em um registro TXT DNS no subdomínio _dmarc do domínio De, por exemplo, _dmarc.upguard.com.

Isso significa que a política será aplicada sempre que um e-mail for recebido com upguard.com como domínio De.

A política também se aplicará a emails recebidos de um subdomínio de upguard.com, a menos que o subdomínio defina sua própria política. Essa é uma melhoria em relação ao funcionamento da descoberta de políticas SPF, em que não há nenhum mecanismo para definir uma única política para todos os subdomínios.

Como funciona uma verificação DMARC?

O processo de execução de uma verificação DMARC é:

Extraia qualquer verificação SPF que produza um resultado de aprovação
Extraia todas as assinaturas DKIM válidas encontradas no e-mail
Compare o domínio usado para executar a verificação SPF (Return-Path) e o domínio DKIM (de acordo com a assinatura DKIM) com o domínio From
Se o domínio não corresponder ao domínio De, o resultado será descartado
Por padrão, os domínios organizacionais ou raiz são comparados
Se ficarmos com uma assinatura DKIM válida ou uma verificação SPF com um resultado de aprovação, e o domínio De corresponder, a verificação DMARC será satisfeita

O DMARC é suficiente para autenticar um e-mail?

Sim. O DMARC permite que você autentique um e-mail porque o DMARC alinha o domínio do SPF e os resultados do DKIM do domínio De e lhe dá confiança sobre a identidade do autor.

O que acontece quando há um conflito entre as políticas SPF e DMARC?

O SPF e o DMARC fornecem um mecanismo para decidir quando o e-mail deve ser rejeitado e nem sempre concordam.

Por exemplo, a verificação SPF pode produzir uma Falha, que direciona o destinatário a rejeitar o e-mail. Mas se houver uma assinatura DKIM válida para o domínio De, isso atenderá à verificação DMARC. Lembre-se, ele verifica se há uma assinatura DKIM válida ou um resultado de aprovação SPF.

Nessa situação, depende das políticas locais de proteção de e-mail.

A seção 6.7 do RFC 7489 afirma:

Um operador que deseja favorecer a política DMARC sobre a política SPF, por exemplo, desconsiderará a política SPF, uma vez que a promulgação de uma rejeição determinada pelo SPF impede a avaliação do DKIM; Caso contrário, o DKIM poderia ser aprovado, satisfazendo a avaliação do DMARC. Há uma compensação em fazer isso, ou seja, aceitação e processamento de todo o corpo da mensagem em troca da proteção aprimorada que o DMARC fornece.

Os destinatários de e-mail compatíveis com DMARC normalmente desconsideram qualquer diretiva de tratamento de e-mail descoberta como parte de um mecanismo de autenticação (por exemplo, ADSP (Author Domain Signing Practices), SPF) em que também é descoberto um registro DMARC que especifica uma política diferente de "nenhuma". Desviar-se dessa prática introduz inconsistência entre os operadores DMARC em termos de tratamento da mensagem. No entanto, tal desvio não é proscrito.

Para permitir que os proprietários de domínio recebam comentários do DMARC sem afetar o processamento de e-mail existente, as políticas descobertas de "p=nenhum" NÃO DEVEM modificar o processamento de disposição de e-mail existente.

Além disso, a seção 10.01 avisa que o uso de uma falha grave em um registro SPF (por exemplo, -all) pode fazer com que o e-mail seja rejeitado por alguns destinatários de e-mail antes que o processamento do DMARC aconteça.

Recomendações SPF, DKIM e DMARC

Recomendamos que todas as organizações implantem uma política DMARC eficaz (p=quarantine ou p=reject) em todos os domínios com suporte a implementações DKIM e SPF. A política deve ser aplicada a todos os subdomínios, ou seja, sp=none (esta é uma tag opcional para definir explicitamente a política para subdomínios) não deve ser usada. Isso protegerá os criminosos cibernéticos que fingem ser sua organização em e-mails enviados. Além disso, obedecer às políticas do DMARC protegerá contra e-mails recebidos.

Se sua organização não delegar o controle de subdomínios a partes não confiáveis, o modo de alinhamento relaxado padrão poderá ser usado para comparar domínios SPF e DKIM.

Além disso, a tag pct não deve ser definida como inferior a 100, ou seja, sua política DMARC deve ser aplicada a todos os e-mails.

A boa notícia é que existem muitos produtos SaaS projetados para ajudá-lo a migrar para uma política DMARC eficaz. Eles também ajudam a identificar problemas de configuração agregando, analisando e analisando relatórios de destinatários de e-mail.

Por fim, sua política de SPF não deve ser excessivamente permissiva. por exemplo, um Passe catch-all (+todos) não deve ser usado, nem o mecanismo ptr, consulte RFC 4408 seção 5.5.

Se uma política DMARC não for implantada ou estiver definida como p=none, use um Fail catch-all (-all) e publique um registro SPF para todos os domínios e subdomínios, mesmo que eles não sejam usados para emails legítimos.

No entanto, se você seguiu nossas recomendações acima, ou seja, você tem uma política DMARC implantada com p=quarantine ou p=rejeit, você pode usar um catch-all de falha suave (~all).

Isso ajuda a evitar a situação em que os destinatários de e-mail rejeitam e-mails com base no resultado do SPF antes de verificar o DMARC (consulte a Seção 10.1 do RFC 7489).

Uma falha suave é boa porque um resultado SPF de aprovação é necessário para passar no DMARC e, portanto, a diferença entre uma falha e uma falha suave não é importante.

O benefício dessa abordagem é que você só precisa publicar registros SPF em subdomínios que são usados pela organização para enviar e-mails legítimos, desde que o domínio pai aplique uma política DMARC e os destinatários de e-mail a verifiquem.

Isso ocorre porque os subdomínios sem registros SPF não produziriam o resultado de aprovação necessário para passar nas verificações DMARC e, portanto, não seriam expostos à falsificação de e-mail.

Não se esqueça do DNSSEC

O DNSSEC fornece uma maneira de proteger contra falsificação de DNS e é uma parte frequentemente negligenciada da segurança de e-mail. A falsificação de DNS é um tipo de ataque cibernético em que um invasor redireciona um endereço DNS válido para o IP de um servidor malicioso.

Como SPF, DKIM e DMARC dependem de registros TXT DNS, a falsificação de DNS prejudica a segurança que eles fornecem.

Controles adicionais de segurança de e-mail

Há uma variedade de soluções adicionais de segurança de e-mail que você pode empregar para melhorar sua segurança de e-mail além de SPF, DKIM, DMARC e DNSSEC, como:

Criptografia de e-mail: criptografar ou disfarçar o conteúdo de mensagens de e-mail ou anexos de e-mail para proteger informações potencialmente confidenciais de serem lidas por qualquer pessoa que não seja os destinatários pretendidos. Isso também pode ajudar na prevenção contra perda de dados (DLP).
Um antivírus: o software antivírus geralmente tem proteção avançada contra ameaças em tempo real que pode detectar assinaturas conhecidas de vírus e malware
Um gateway de e-mail seguro (SEG): um dispositivo ou software hospedado na nuvem ou no local usado para monitorar e-mails enviados e recebidos.
Anti-spam: refere-se a qualquer software, hardware ou processo usado para combater a proliferação de spam ou impedir que o spam entre em um sistema. Por exemplo, o e-mail opt-in é um processo anti-spam comum.
Senhas fortes: exija que os funcionários usem senhas fortes e exijam alterações de senha periodicamente. Consulte nossa senha de lista de verificação segura para obter mais informações.
Treinamento de conscientização sobre segurança cibernética: as equipes de segurança devem investir no treinamento de sua equipe, pois muitos ataques cibernéticos são espalhados por meio de anexos de e-mail maliciosos. Anexos de e-mail em sandbox, como arquivos do Microsoft Office ou Office 365, também podem ajudar.

Leia nossa lista de verificação de segurança de e-mail para obter mais controles.

Perguntas frequentes sobre segurança de e-mail

O que é segurança de e-mail?

A segurança de e-mail refere-se a um sistema de soluções projetado para manter as contas de e-mail protegidas contra comprometimento.

Quais são os diferentes tipos de segurança de e-mail?

As estratégias para aumentar a segurança do e-mail incluem:

Implementando um SPF (Sender Policy Framework).
Implementando o DKIM
Usando uma solução antivírus
Aplicando políticas de criptografia de e-mail

Quais são os riscos de segurança associados ao uso de e-mails?

O principal risco de segurança são os ataques de phishing. Durante um ataque de phishing, os cibercriminosos enviam e-mails fraudulentos infectados com links ou anexos maliciosos. Quando um alvo interage com um e-mail de phishing, ele entra em um funil projetado para roubar credenciais confidenciais ou iniciar a instalação de malware.

Quais são as boas práticas de segurança de e-mail?

As melhores práticas de e-mail incluem:

Nunca interagir com e-mails suspeitos
Relatar instantaneamente e-mails suspeitos às equipes de segurança
Sempre confirme a legitimidade dos e-mails de colegas entrando em contato diretamente com eles (seja escrevendo um novo e-mail ou por meio de canais de comunicação internos dedicados da empresa).