Aprimorando o fluxo de emails com o MTA-STS

O suporte para o padrão SMTP MTA Strict Transport Security (MTA-STS) foi adicionado ao Exchange Online. O padrão foi desenvolvido para garantir que o TLS seja sempre usado para conexões entre servidores de email. Ele também fornece uma maneira de enviar servidores para validar se o servidor de recebimento possui um certificado confiável. Se o TLS não for oferecido ou o certificado não for válido, o remetente se recusará a entregar as mensagens. Essas novas verificações melhoram a segurança geral do SMTP e protegem contra ataques man-in-the-middle.

O MTA-STS pode ser dividido em dois cenários: proteção de Entrada e de Saída. A proteção de entrada abrange a proteção de domínios alojados no Exchange Online com MTA-STS. A proteção de saída abrange as validações MTA-STS executadas pelo Exchange Online ao enviar e-mails para domínios protegidos por MTA-STS.

Proteção de Saída

Todas as mensagens enviadas de saída do Exchange Online para destinatários protegidos por MTA-STS estão a ser validadas com estas verificações de segurança adicionais definidas pela norma MTA-STS. Não há nada que os administradores precisem de fazer para o aplicar. Nossa implementação de saída respeita os desejos dos proprietários de domínio do destinatário por meio de sua política MTA-STS. O MTA-STS faz parte da infraestrutura de segurança do Exchange Online e, por conseguinte, está sempre ativado (como outras funcionalidades principais do SMTP).

O MTA-STS de saída pode impedir a entrega de e-mails consoante os resultados da validação MTA-STS relativamente ao domínio de destino. Se o domínio não for seguro e a política MTA-STS estiver definida como Impor, um NDR poderá ser devolvido ao remetente com um dos seguintes códigos de erro:

Proteção de Entrada

Os proprietários de domínio podem tomar medidas para proteger os emails enviados para seus domínios com o MTA-STS, se o registro MX apontar para o Exchange Online. Se o seu registo MX apontar para um serviço intermediário de terceiros, terá de saber se os requisitos de MTA-STS são cumpridos por eles e, em seguida, seguir as instruções.

Assim que o MTA-STS estiver configurado para o seu domínio, quaisquer mensagens enviadas de remetentes que suportem o MTA-STS realizarão as validações estabelecidas pelo padrão para garantir uma conexão segura. Se você estiver recebendo um email de um remetente que não oferece suporte ao MTA-STS, o email ainda será entregue sem a proteção extra. Da mesma forma, não há interrupção nas mensagens se você ainda não estiver usando o MTA-STS, mas o remetente o suportar. O único cenário em que as mensagens não são entregues é quando ambos os lados estão usando o MTA-STS e a validação do MTA-STS falha.

Como adotar o MTA-STS

O MTA-STS permite que um domínio declare suporte para TLS e comunique o registro MX e o certificado de destino esperado. Também indica o que um servidor de envio tem de fazer se houver um problema. Esta comunicação é efetuada através de uma combinação de um registo TXT de DNS e de um ficheiro de política publicado como uma página Web HTTPS. A política protegida por HTTPS apresenta outra proteção de segurança que os invasores devem superar.

O registro TXT do MTA-STS de um domínio indica suporte ao MTA-STS para um remetente, após o qual a política do MTA-STS baseada em HTTPS do domínio é recuperada pelo remetente. O registo TXT deve conter v=STSv1; até o STSv2 ser suportado e o ID da política. O ID TEM de ser exclusivo para o proprietário e a política do domínio, como uma alteração nos sinais de ID aos remetentes de que precisam para obter novamente a política. O ID não tem de ser globalmente exclusivo, não se preocupe com os IDs de política de outros proprietários de domínios. Após qualquer atualização da política MTA-STS, tem de atualizar o ID ou os remetentes continuarão a utilizar políticas em cache para o seu domínio até que a max_age da política em cache expire.

Um padrão repetível para definir um ID exclusivo é utilizar a hora UTC como tal:
id=<yyyymmddhh0000>Z;

O seguinte registo TXT é um exemplo que declara suporte para MTA-STS, o ID foi definido às 8:00 de 1 de janeiro de 2022 hora UTC:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

A política MTA-STS de um domínio precisa estar localizada em uma URL predefinida e hospedada pela infraestrutura da Web do domínio. A sintaxe do URL é https://mta-sts.<domain name>/.well-known/mta-sts.txt. Por exemplo, a política da Microsoft.com pode ser encontrada em: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Qualquer cliente cujos registos MX apontem diretamente para o Exchange Online pode especificar na sua própria política os mesmos valores apresentados no https://mta-sts.microsoft.com/.well-known/mta-sts.txt. As informações exclusivas necessárias na política são o registo MX que aponta para o Exchange Online (*.mail.protection.outlook.com) e o mesmo certificado é partilhado por todos os clientes do Exchange Online. O Exchange Online só permite que uma organização receba e-mails para um determinado domínio para que a utilização de um caráter universal não enfraqueca a segurança; no entanto, isso pode não ser o caso de outros serviços de e-mail. É possível publicar a política no modo de teste para garantir que é válida antes de a alterar para o modo de imposição . Existem ferramentas de validação de terceiros que podem verificar sua configuração.

Estas políticas não são algo que o Exchange Online possa alojar em nome dos clientes; Por isso, os clientes têm de configurar a política de STS do seu domínio com os serviços que preferem. Os serviços do Azure podem ser facilmente utilizados para o alojamento de políticas e existe uma orientação de configuração mais adiante neste artigo. A política precisa ser protegida por HTTPS com um certificado para o subdomínio mta-sts.<domain name>.

Assim que o registo TXT de DNS for criado e o ficheiro de política estiver disponível no URL HTTPS necessário, o domínio será protegido por MTA-STS. Os detalhes sobre o MTA-STS estão disponíveis no RFC 8461.

Configurar o MTA-STS de Entrada com os Serviços do Azure

Existem dois recursos do Azure que podem ser utilizados para alojar a política MTA-STS: Aplicação Web Estática do Azure e Funções do Azure. Embora este artigo descreva como implementar a política com ambos os recursos, o método recomendado é a Aplicação Web Estática do Azure , uma vez que foi concebido para alojar páginas estáticas, como a política sts, e o Azure simplifica a configuração ao fornecer um certificado TLS para a página Web MTA-STS fora da caixa, sem que seja necessária mais configuração. Se não conseguir utilizar a Aplicação Web Estática do Azure, também pode alojar a sua política como código sem servidor com as Funções do Azure. Esta abordagem não é o método preferencial porque as Funções do Azure são uma funcionalidade concebida para outros cenários e não emitem automaticamente um certificado TLS, ao contrário das Aplicações Web Estáticas do Azure. Assim, a utilização das Funções do Azure para MTA-STS requer que emita o seu próprio "mta-sts. [o seu domínio]" certificado e vinculá-lo à função.

Independentemente da abordagem que tomou, recomendamos que valide se a política foi configurada corretamente e se o tempo de resposta é aceitável – o tempo limite por orientação de RFC é de 60 segundos.

Estes fluxos de configuração destinam-se a fornecer apenas informações técnicas sobre as funcionalidades do Azure que podem ser utilizadas para alojar a política MTA-STS e não fornecem informações sobre os custos ou os custos das funcionalidades do Azure. Se quiser saber os custos das funcionalidades do Azure, utilize a Calculadora de Preços do Azure.

Opção 1 (RECOMENDADO): Aplicação Web Estática do Azure

1. Crie uma organização do Azure DevOps ou utilize uma organização que já exista. Neste exemplo, será utilizada uma organização denominada "ContosoCorporation" para alojar a política MTA-STS.

   

2. Em Ficheiros > de Repositório, clone o seu repositório em qualquer IDE que preferir. Neste exemplo, o repositório será clonado no Visual Studio.

   

3. Depois de clonar o repositório, crie o caminho home\.well-known\da pasta . Em seguida, crie os seguintes ficheiros:

   • Ficheiro 1: home.well-known\mta-sts.txt

     Observação

     Esta configuração permite que apenas o Exchange Online receba mensagens em nome do seu domínio. Se estiver a utilizar vários fornecedores de e-mail, também terá de referenciar anfitriões MX para os domínios desses outros fornecedores. Os carateres universais ou "*" não podem ser utilizados como prefixo MX em todos os cenários MTA-STS; as definições abaixo são específicas apenas do Exchange Online e NÃO devem ser utilizadas como orientação geral para configurar o MTA-STS.

     1. Introduza o seguinte texto no mta-sts.txt ficheiro:

        version: STSv1
        mode: testing
        mx: *.mail.protection.outlook.com
        max_age: 604800
        

        Observação

        Recomenda-se que o modo de política seja inicialmente definido como teste. Em seguida, no final da configuração e depois de validar que a política está a funcionar conforme esperado, atualize o mta-sts.txt ficheiro de forma a que o modo seja forçado.

        O ficheiro só tem de conter o conteúdo, conforme mostrado na seguinte captura de ecrã:

        

   • Ficheiro 2: home\index.html

     1. Crie um index.html ficheiro e introduza o seguinte código no mesmo:

        <!DOCTYPE html>
        <html lang="en">
        
        <head>
        <meta charset="UTF-8">
        <title>MTA-STS</title>
        </head>
        
        <body>
        <h1>MTA-STS Static Website index</h1>
        </body>
        
        </html>
        

        O ficheiro só tem de conter o conteúdo, conforme mostrado na seguinte captura de ecrã:

        

        Assim que o caminho e os ficheiros da pasta forem criados, não se esqueça de consolidar as alterações e enviá-las para o ramo principal.

4. Crie uma nova Aplicação Web Estática do Azure com a seguinte configuração:

   • Nome: MTA-STS-StaticWebApp
   • Tipo de plano: Standard
   • Detalhes da Implementação: Azure DevOps
   • Organização: ContosoCorporation
   • Projeto: MTA-STS_Project
   • Repositório: MTA-STS_Project
   • Ramo: principal
   • Criar Predefinições: Angular
   • Localização da Aplicação: /home

   

5. Assim que a criação da Aplicação Web Estática estiver concluída e o recurso for aprovisionado, aceda a Descrição Geral > Gerir token de implementação e, em seguida, copie o token como será utilizado no passo seguinte.

6. Aceda a Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project e execute as seguintes subtarefas:

   1. Aceda a Variáveis > Nova Variável e escreva o seguinte:

      1. Nome: token
      2. Valor: (cole o token que copiou anteriormente, no Passo 5)

   2. Assim que a variável for guardada, regresse a Rever o YAML do pipeline e cole o seguinte yml, guarde-o e execute-o:

      trigger:
      - main
      
      pool:
      vmImage: ubuntu-latest
      
      steps:
      - checkout: self
      submodules: true
      - task: AzureStaticWebApp@0
      inputs:
       app_location: '/home'
       azure_static_web_apps_api_token: $(token)
      

      No Azure DevOps, durante a implementação, se ocorrer o erro Nenhum paralelismo alojado foi comprado ou concedido, solicite através deste formulário ou implemente uma configuração através de Tarefas paralelas de Definições da Organização Tarefas paralelas >> da Microsoft Hosted > Change > Paid Parallel de modo a que sejam permitidas "Tarefas paralelas pagas".

7. Assim que a tarefa for concluída com êxito, pode validar a implementação através do portal do Azure ao aceder ao Browser de Ambiente > da Aplicação > Web Estática do Azure. Tem de ver o index.html conteúdo do ficheiro.

8. Adicione o seu domínio intuitivo no Azure Static Web App Custom domains Add( Adicionar domínios personalizados > da Aplicação > Web Estática do Azure). Terá de criar um registo CNAME através do seu fornecedor de DNS (por exemplo, a GoDaddy) para validar se a zona lhe pertence. Quando a validação estiver concluída, o Azure emitirá um certificado e vinculará-o automaticamente à Aplicação Web Estática.

9. Valide se a política MTA-STS é publicada através de: https://mta-sts.[o seu domínio]/.bem conhecido/mta-sts.txt.

10. Crie o registo DNS TXT MTA-STS através do seu fornecedor de DNS. O formato é:

    Hostname: _mta-sts.<domain name>
    TTL: 3600 (recommended)
    Type: TXT
    Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
    

    Observação

    Pode encontrar um registo TXT MTA-STS de exemplo em Como Adotar MTA-STS.

11. Assim que o registo TXT estiver disponível no DNS, valide a configuração MTA-STS. Assim que a configuração tiver sido validada com êxito, atualize o mta-sts.txt ficheiro para que o modo de política seja imposta e, em seguida, atualize o ID da política no registo TXT.

Opção 2: Função do Azure

1. Crie uma nova Aplicação de Funções do Azure com a seguinte configuração:

   • Nome da Aplicação de Funções: [Como a sua escolha]
   • Publicar: Código
   • Pilha de runtime: .NET
   • Versão: 6
   • Sistema Operativo: Windows
   • Tipo de Plano: [À sua escolha]

   

2. Adicione o seu domínio personalizado à Aplicação de Funções. Terá de criar um registo CNAME para validar se o domínio lhe pertence.

   

3. Vincular o seu "mta-sts. [o seu domínio]" para a Aplicação de Funções.

   

4. No Ficheiro de Aplicação, adicione a seguinte extensão à host.json da Aplicação de Funções para eliminar o routePrefix. Esta adição é necessária para remover a /api do URL da função.

   "extensions": {
     "http": {
       "routePrefix": ""
     }
   }
   

   

5. Na Aplicação de Funções, aceda a Funções > Criar e configurar os seguintes parâmetros:

   Observação

   Embora este exemplo descreva o desenvolvimento da função através do portal, pode utilizar o VS Code ou qualquer outra ferramenta que prefira.

   • Ambiente de desenvolvimento: [À sua escolha; este exemplo utilizará "Desenvolver no Portal"]
   • Selecionar um modelo: acionador HTTP
   • Nova Função: [À sua escolha]
   • Nível de autorização: Anónimo

   

6. Assim que a função for criada, abra Código + Teste e desenvolva em C# uma resposta HTTP assíncrona simples que será a sua política MTA-STS. O exemplo seguinte indica que o Exchange Online deverá receber e-mails:

   Observação

   Recomenda-se que o modo de política seja inicialmente definido como teste. Em seguida, no final da configuração e depois de validar que a política está a funcionar conforme esperado, atualize o mta-sts.txt ficheiro de forma a que o modo seja forçado.

   

7. Em HTTP de Integração > (req), edite o acionador para os seguintes valores:

   • Modelo de Rota: .well-known/mta-sts.txt
   • Métodos HTTP selecionados: GET

   

8. Confirme que a política MTA-STS é publicada através de: https://mta-sts.[o seu domínio]/.bem conhecido/mta-sts.txt.

9. Crie o registo DNS TXT MTA-STS através do seu fornecedor de DNS no seguinte formato:

   Hostname: _mta-sts.<domain name>
   TTL: 3600 (recommended)
   Type: TXT
   Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
   

   Observação

   Pode encontrar um registo TXT MTA-STS de exemplo em Como Adotar MTA-STS.

10. Assim que o registo TXT estiver disponível no DNS, valide a configuração MTA-STS. Assim que a configuração tiver sido validada com êxito, atualize o mta-sts.txt ficheiro de modo a que o modo de política seja imposta e, em seguida, atualize o ID da política no registo TXT.