Partilhar via

Email autenticação no Microsoft 365

Sugestão

Sabia que pode experimentar as funcionalidades do Microsoft Defender para Office 365 Plano 2 gratuitamente? Utilize a avaliação de Defender para Office 365 de 90 dias no hub de avaliações do portal Microsoft Defender. Saiba mais sobre quem pode inscrever-se e os termos de avaliação em Experimentar Microsoft Defender para Office 365.

Enquanto organização do Microsoft 365 com caixas de correio no Exchange Online ou uma organização autónoma Proteção do Exchange Online (EOP) sem Exchange Online caixas de correio, é importante proteger a integridade das mensagens de e-mail dos remetentes nos seus domínios. Os destinatários devem sentir-se confiantes de que as mensagens de remetentes no seu domínio são realmente provenientes de remetentes no seu domínio.

Email autenticação (também conhecida como validação de e-mail) é um grupo de normas para identificar e impedir a entrega de mensagens de e-mail de remetentes falsificados (também conhecidos como spoofing). Os remetentes falsificados são frequentemente utilizados em e-mails empresariais comprometidos (BEC), phishing e outros ataques de e-mail. Estas normas incluem:

  • Sender Policy Framework (SPF): especifica os servidores de e-mail de origem que estão autorizados a enviar correio para o domínio.
  • DomainKeys Identified Mail (DKIM): utiliza um domínio para assinar digitalmente elementos importantes da mensagem para garantir que a mensagem não foi alterada em trânsito.
  • Autenticação de Mensagens baseada em domínio, Relatórios e Conformidade (DMARC): especifica a ação para mensagens que falham nas verificações de SPF ou DKIM para remetentes no domínio e especifica para onde enviar os resultados DMARC (relatórios).
  • Cadeia De Receção Autenticada (ARC): preserva as informações de autenticação de e-mail originais por serviços conhecidos que modificam mensagens em trânsito. O servidor de e-mail de destino pode utilizar estas informações para autenticar mensagens que, de outra forma, falhariam com o DMARC.

É importante perceber que estas normas são blocos modulares interdependentes que funcionam em conjunto para fornecer a melhor proteção de e-mail possível contra ataques de spoofing e phishing. Qualquer coisa menos do que todos os métodos de autenticação de e-mail resulta numa proteção inferior ao padrão.

Para configurar a autenticação de e-mail para e-mails enviados por organizações do Microsoft 365 com caixas de correio em organizações Exchange Online ou Proteção do Exchange Online autónomas (EOP) sem Exchange Online caixas de correio, consulte os seguintes artigos:

Para evitar falhas de autenticação de e-mail devido a serviços que modificam o correio de entrada enviado para a sua organização do Microsoft 365, consulte Configurar sealers ARC fidedignos.

O resto deste artigo explica:

Sugestão

Como complemento deste artigo, consulte o nosso guia de configuração de Microsoft Defender para Office 365 para rever as melhores práticas e proteger contra ameaças de e-mail, ligação e colaboração. As funcionalidades incluem Ligações Seguras, Anexos Seguros e muito mais. Para uma experiência personalizada com base no seu ambiente, pode aceder ao guia de configuração automatizada Microsoft Defender para Office 365 no centro de administração do Microsoft 365.

Por que motivo o e-mail da Internet precisa de autenticação

Por predefinição, o e-mail do Protocolo SMTP (Simple Mail Transfer Protocol) na Internet não faz qualquer esforço para validar que o remetente da mensagem é quem afirma ser.

Uma mensagem de e-mail SMTP padrão consiste num envelope de mensagens e conteúdos de mensagens:

  • O envelope da mensagem contém informações para transmitir e receber a mensagem entre servidores SMTP. O envelope da mensagem é descrito em RFC 5321. Os destinatários nunca veem o envelope da mensagem porque é gerado durante o processo de transmissão de mensagens.
  • O conteúdo da mensagem contém campos de cabeçalho de mensagem (coletivamente denominados cabeçalho da mensagem) e o corpo da mensagem. O cabeçalho da mensagem é descrito em RFC 5322.

Devido a esta estrutura, uma mensagem tem vários valores de remetente:

  • O endereço MAIL FROM (também conhecido como endereço 5321.MailFrom , remetente P1 ou remetente de envelope) é o endereço de e-mail utilizado na transmissão da mensagem entre os servidores de e-mail SMTP. Normalmente, este endereço é registado no campo de cabeçalho Return-Path no cabeçalho da mensagem (embora o servidor de e-mail de origem possa designar um endereço de e-mail Return-Path diferente). Este endereço de e-mail é utilizado em relatórios de entrega sem fins lucrativos (também conhecidos como NDRs ou mensagens de devolução).
  • O endereço De (também conhecido como endereço 5322.From ou remetente P2) é o endereço de e-mail no campo De cabeçalho e é o endereço de e-mail do remetente que é apresentado nos clientes de e-mail.

O exemplo seguinte mostra a transcrição simplificada de uma transmissão de mensagens válida entre dois servidores de e-mail SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

Neste exemplo:

  • O servidor de e-mail de origem identifica-se como woodgrovebank.com ao servidor de e-mail de destino tailspintoys.com no comando HELO.
  • O destinatário da mensagem é astobes@tailspintoys.com.
  • O endereço MAIL FROM no envelope de mensagem (utilizado para transmitir a mensagem entre servidores de e-mail SMTP) é dubious@proseware.com.
  • O endereço De apresentado no cliente de e-mail do destinatário é security@woodgrovebank.com.

Embora esta mensagem seja válida de acordo com o SMTP, o domínio do endereço MAIL FROM (proseware.com) não corresponde ao domínio no endereço De (woodgrovebank.com). Esta mensagem é um exemplo clássico de spoofing, em que é provável que a intenção engane o destinatário ao mascarar a verdadeira origem da mensagem a utilizar num ataque de phishing.

Claramente, o e-mail SMTP precisa de ajuda para verificar se os remetentes de mensagens são quem afirmam ser!

Como o SPF, o DKIM e o DMARC funcionam em conjunto para autenticar remetentes de mensagens de e-mail

Esta secção descreve o motivo pelo qual precisa de SPF, DKIM e DMARC para domínios na Internet.

  • SPF: Conforme explicado em Configurar o SPF para identificar origens de e-mail válidas para o seu domínio do Microsoft 365, o SPF utiliza um registo TXT no DNS para identificar origens de correio válidas do domínio MAIL FROM e o que fazer se o servidor de e-mail de destino receber correio de uma origem indefinida ("falha difícil" para rejeitar a mensagem; "falha suave" para aceitar e marcar a mensagem).

    Problemas do SPF:

    • O SPF valida origens para remetentes apenas no domínio MAIL FROM. O SPF não considera o domínio no endereço De ou no alinhamento entre os domínios MAIL FROM e From:

      • Um atacante pode enviar e-mails que passem na autenticação SPF (um falso negativo) ao seguir estes passos:
        • Registe um domínio (por exemplo, proseware.com) e configure o SPF para o domínio.
        • Envie um e-mail a partir de uma origem válida para o domínio registado, com os endereços de e-mail De num domínio diferente (por exemplo, woodgrovebank.com).
      • Um serviço de e-mail legítimo que envia correio em nome de outros domínios pode controlar o endereço MAIL FROM. Os outros domínios e o domínio MAIL FROM não correspondem, pelo que as mensagens não podem passar na autenticação SPF (um falso positivo).

    • O SPF quebra após as mensagens encontrarem o reencaminhamento de e-mail baseado no servidor que redireciona ou reencaminha mensagens.

      • O reencaminhamento de e-mail baseado no servidor altera a origem da mensagem do servidor original para o servidor de reencaminhamento.
      • O servidor de reencaminhamento não está autorizado a enviar correio a partir do domínio MAIL FROM original, pelo que a mensagem não pode passar na autenticação SPF (um falso positivo).

    • Cada domínio e quaisquer subdomínios requerem os seus próprios registos SPF individuais. Os subdomínios não herdam o registo SPF do domínio principal. Este comportamento torna-se problemático se quiser permitir e-mails de subdomínios definidos e utilizados, mas impedir o e-mail de subdomínios não definidos e não utilizados.

  • DKIM: conforme explicado em Configurar o DKIM para assinar correio a partir do seu domínio do Microsoft 365, o DKIM utiliza um domínio para assinar digitalmente elementos importantes da mensagem (incluindo o endereço De) e armazena a assinatura no cabeçalho da mensagem. O servidor de destino verifica se os elementos assinados da mensagem não foram alterados.

    Como o DKIM ajuda o SPF: o DKIM pode validar mensagens que falham no SPF. Por exemplo:

    • Mensagens de um serviço de alojamento de e-mail onde o mesmo endereço MAIL FROM é utilizado para correio de outros domínios.
    • Mensagens que encontram o reencaminhamento de e-mail baseado no servidor.

    Uma vez que a assinatura DKIM no cabeçalho da mensagem não é afetada ou alterada nestes cenários, estas mensagens são capazes de transmitir DKIM.

    Problemas de DKIM: o domínio que o DKIM utiliza para assinar uma mensagem não precisa de corresponder ao domínio no endereço De apresentado nos clientes de e-mail.

    Tal como o SPF, um atacante pode enviar e-mails que transmitem a autenticação DKIM (um falso negativo) ao seguir estes passos:

    • Registe um domínio (por exemplo, proseware.com) e configure o DKIM para o domínio.
    • Envie um e-mail com os endereços de e-mail De num domínio diferente (por exemplo, woodgrovebank.com).

  • DMARC: conforme explicado em Configurar dMARC para validar o domínio de endereço De para remetentes no Microsoft 365, dMARC utiliza SPF e DKIM para verificar o alinhamento entre os domínios nos endereços MAIL FROM e From. DMARC também especifica a ação que o sistema de e-mail de destino deve tomar em mensagens que falham DMARC e identifica para onde enviar resultados DMARC (passe e falhe).

    Como o DMARC ajuda o SPF e o DKIM: conforme descrito anteriormente, o SPF não tenta corresponder ao domínio no domínio MAIL FROM e nos endereços De. O DKIM não se importa se o domínio que assinou a mensagem corresponde ao domínio no endereço De.

    A DMARC resolve estas deficiências ao utilizar SPF e DKIM para confirmar que os domínios nos endereços MAIL FROM e From correspondem.

    Problemas de DMARC: serviços legítimos que modificam mensagens em trânsito antes da interrupção da entrega SPF, DKIM e, portanto, verificações DMARC.

  • ARC: Conforme explicado em Configurar sealers ARC fidedignos, os serviços legítimos que modificam mensagens em trânsito podem utilizar o ARC para preservar as informações de autenticação de e-mail originais das mensagens modificadas.

    Como o ARC ajuda o DMARC: o sistema de e-mail de destino pode identificar o serviço como um selador ARC fidedigno. Em seguida, o ARC pode utilizar as informações de autenticação de e-mail preservadas para validar a mensagem.

Autenticação de e-mail de entrada para correio enviado para o Microsoft 365

Devido a questões de phishing e à adoção menos completa de políticas de autenticação de e-mail fortes por remetentes de e-mail na Internet, o Microsoft 365 utiliza a autenticação implícita de e-mail para verificar o e-mail de entrada. A autenticação implícita de e-mail expande as verificações normais de SPF, DKIM e DMARC através de sinais de outras origens para avaliar o e-mail de entrada. Estas origens incluem:

  • Reputação do remetente.
  • Histórico do remetente.
  • Histórico de destinatários.
  • Análise comportamental.
  • Outras técnicas avançadas.

Para ver o anúncio original da Microsoft sobre a autenticação implícita, consulte A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365 (Um Mar de Phish Part 2 – Anti-spoofing Avançado no Microsoft 365).

Ao utilizar estes outros sinais, as mensagens que, de outra forma, falhariam nas verificações de autenticação de e-mail tradicionais podem passar a autenticação implícita e ser permitidas no Microsoft 365.

Autenticação composta

Os resultados das verificações de autenticação implícita do Microsoft 365 são combinados e armazenados num único valor denominado autenticação composta ou compauth abreviada. O compauth valor é carimbado no cabeçalho Authentication-Results nos cabeçalhos da mensagem. O cabeçalho Authentication-Results utiliza a seguinte sintaxe:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Estes valores são explicados no cabeçalho da mensagem Authentication-results.

Os administradores e utilizadores podem examinar os cabeçalhos das mensagens para descobrir como o Microsoft 365 identificou o remetente como um remetente falsificado suspeito ou legítimo.

Sugestão

É importante compreender que uma falha de autenticação composta não resulta diretamente no bloqueio de uma mensagem. O nosso sistema utiliza uma estratégia de avaliação holística que considera a natureza suspeita geral de uma mensagem juntamente com os resultados da autenticação composta. Este método foi concebido para mitigar o risco de bloquear incorretamente e-mails legítimos de domínios que podem não cumprir estritamente os protocolos de autenticação de e-mail. Esta abordagem equilibrada ajuda a distinguir e-mails genuinamente maliciosos de remetentes de mensagens que simplesmente não cumprem as práticas padrão de autenticação de e-mail.

Os exemplos seguintes focam-se apenas nos resultados da autenticação de e-mail (o valor e o compauth motivo). Outras tecnologias de proteção do Microsoft 365 podem identificar mensagens que passam a autenticação de e-mail como falsificadas ou identificar mensagens que falham na autenticação de e-mail como legítimas.

  • Cenário: o domínio no registo SPF ou na assinatura DKIM não corresponde ao domínio no endereço De.

  • Resultado: a mensagem pode falhar a autenticação composta. Apesar da falha de autenticação composta, a mensagem ainda poderá ser permitida se outras avaliações não indicarem uma natureza suspeita:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Cenário: o domínio fabrikam.com não tem registos SPF, DKIM ou DMARC.

  • Resultado: as mensagens de remetentes no domínio fabrikam.com podem falhar a autenticação composta:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio fabrikam.com tem um registo SPF e nenhum registo DKIM. Os domínios nos endereços MAIL FROM e From correspondem.

  • Resultado: a mensagem pode passar a autenticação composta, porque o domínio que passou no SPF corresponde ao domínio no endereço De:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio fabrikam.com tem um registo DKIM sem um registo SPF. O domínio que o DKIM assinou a mensagem corresponde ao domínio no endereço De.

  • Resultado: a mensagem pode passar a autenticação composta, porque o domínio na assinatura DKIM corresponde ao domínio no endereço De:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Cenário: o domínio no registo SPF ou na assinatura DKIM não corresponde ao domínio no endereço De.

  • Resultado: A mensagem pode falhar a autenticação composta:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Como evitar falhas de autenticação de e-mail ao enviar correio para o Microsoft 365

Sugestão

Os clientes do Microsoft 365 podem utilizar os seguintes métodos para permitir mensagens de remetentes identificados como spoofing ou falhas de autenticação:

  • Configurar registos SPF, DKIM e DMARC para os seus domínios: utilize as informações de configuração fornecidas pela sua entidade de registo de domínios ou pelo serviço de alojamento DNS. Também existem empresas de terceiros dedicadas a ajudar a configurar registos de autenticação de e-mail.

    Muitas empresas não publicam registos SPF porque não conhecem todas as origens de e-mail das mensagens no respetivo domínio.

    1. Comece por publicar um registo SPF que contenha todas as origens de e-mail que conhece (especialmente onde está localizado o tráfego empresarial) e utilize o valor da regra de imposição "soft fail" (~all). Por exemplo:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Se criar este registo SPF, o Microsoft 365 trata o e-mail de entrada da sua infraestrutura empresarial como autenticado, mas o e-mail de origens não identificadas ainda poderá ser marcado como spoof se falhar a autenticação composta. No entanto, este comportamento continua a ser uma melhoria de todos os e-mails de remetentes no domínio que estão a ser marcados como spoof pelo Microsoft 365. Normalmente, o sistema de e-mail de destino aceita mensagens de remetentes no domínio de origens não identificadas quando o SPF está configurado com uma regra de imposição de falha recuperável.

    2. Descubra e inclua mais origens de e-mail para as suas mensagens. Por exemplo:

      • Servidores de e-mail no local.
      • Email enviados a partir de um fornecedor de software como serviço (SaaS).
      • Email enviados a partir de um serviço de alojamento na cloud (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, etc.).

      Depois de identificar todas as origens de e-mail do seu domínio, pode atualizar o registo SPF para utilizar o valor da regra de imposição "falha grave" (-all).

    3. Configure o DKIM para assinar digitalmente mensagens.

    4. Configure o DMARC para validar se os domínios nos endereços MAIL FROM e From correspondem, para especificar o que fazer com mensagens que falham verificações DMARC (rejeitar ou colocar em quarentena) e identificar os serviços de relatórios para monitorizar os resultados DMARC.

    5. Se utilizar remetentes em massa para enviar e-mails em seu nome, verifique se o domínio no endereço De corresponde ao domínio que transmite SPF ou DMARC.

  • Aloja o e-mail de um domínio ou fornece uma infraestrutura de alojamento que pode enviar e-mails:

    • Certifique-se de que os seus clientes têm documentação que explica como configurar o SPF para os respetivos domínios.
    • Considere a assinatura DKIM de correio de saída DKIM, mesmo que o cliente não configure explicitamente o DKIM no respetivo domínio (inicie sessão com um domínio predefinido). Pode até assinar novamente o e-mail com assinaturas DKIM (com o domínio da empresa e o domínio do cliente se/quando estiver disponível).

    A entrega à Microsoft não é garantida, mesmo que autentique o e-mail com origem na sua plataforma. No entanto, a autenticação de e-mail garante que a Microsoft não e-mail de lixo automaticamente a partir dos seus domínios de cliente é simplesmente porque não é autenticado.