Sophos Email: configurar TLS e Secure Message com segurança

Uma Secure Message policy define como o Sophos Email protege as mensagens e o que acontece quando não é possível utilizar o método escolhido. Para a maioria das ligações TLS, Preferred TLS 1.3 é o ponto de partida mais robusto: o Sophos tenta TLS 1.3 e muda para TLS 1.2 quando necessário. Imponha Required TLS 1.3 ou Required TLS 1.2 apenas a parceiros cujo sistema de envio ou receção cumpra comprovadamente esse requisito exato.

Caminho rápido: primeiro, ative TLS 1.3 e as cifras necessárias no seu servidor ou serviço de correio e teste o fluxo de correio para o Sophos. Em My Products > Email Security > Policies, crie uma policy Secure Message, defina o âmbito interno e, se necessário, o externo, escolha a direção e o método em Settings e coloque um pequeno grupo-piloto em Policy is enforced. Para mensagens enviadas, decida antecipadamente se uma falha TLS pode permitir a entrega sem encriptação ou se deve ser tratada por Fallback to push encrypt the entire message. Em seguida, verifique em Message History a versão TLS e o estado da entrega para cada parceiro e direção.

Aviso: O TLS tem de estar ativo no seu servidor ou serviço de correio antes de configurar qualquer método Secure Message. Em particular, o gateway de correio tem de suportar TLS 1.3 antes de selecionar Required TLS 1.3. Caso contrário, a ligação ao Sophos pode falhar e interromper tanto o correio recebido como o enviado.

Registar os pré-requisitos e o rollback antes da alteração

Este guia aplica-se ao Sophos Email no Sophos Fusion (anteriormente Sophos Central), não ao Mail Protection executado numa Sophos Firewall. Não é possível configurar Secure Message Policies em EMS mode.

Antes da alteração, registe:

o nome, âmbito, ordem, direção e estado de aplicação atuais da policy, bem como qualquer hora de desativação configurada;
os utilizadores, grupos ou domínios internos e os endereços ou domínios externos abrangidos;
as versões TLS e cifras do seu servidor de correio e dos parceiros do piloto;
se o parceiro apresenta um certificado para o respetivo domínio destinatário;
a decisão de fallback aprovada para cada parceiro de comunicação;
remetentes e destinatários de teste, Message-IDs, janela de alteração e responsáveis por ambas as plataformas de correio.

O Sophos recomenda TLS 1.3. A cadeia de cifras documentada é exatamente TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 e TLS 1.1 deixaram de ser suportados para entrega de correio recebido ou enviado em 1 de janeiro de 2024. Por isso, o seu servidor não pode estar limitado a essas versões antigas.

Para o rollback, guarde capturas de ecrã ou dados exportados da policy anterior. Pode voltar a definir uma policy-piloto nova ou clonada como Policy Bypassed e restaurar a ordem anterior. Não elimine uma policy funcional antes de concluir todos os testes.

Escolher conscientemente o método e o comportamento em caso de falha

TLS: encriptação do transporte no cliente de correio habitual

Secure using TLS protege a ligação SMTP durante o transporte; remetentes e destinatários continuam a utilizar o cliente de correio habitual. Isto não significa que, após a entrega na caixa de correio, a mensagem permaneça num contentor encriptado.

Os níveis TLS têm consequências diferentes:

Preferred TLS 1.3 tenta TLS 1.3 e utiliza TLS 1.2 se o parceiro não suportar TLS 1.3. O Sophos recomenda esta opção mais flexível porque é menos provável que interrompa a troca de mensagens.
Required TLS 1.3 aceita apenas TLS 1.3. Se o parceiro não o suportar, a mensagem não é trocada através de outra versão TLS.
Required TLS 1.2 aceita apenas TLS 1.2. Neste modo, TLS 1.3 não substitui a versão selecionada; esta é imposta.

Sem esta imposição, o Sophos tenta utilizar TLS por predefinição sempre que seja possível estabelecer uma ligação TLS. Este comportamento oportunista favorece a compatibilidade, mas não garante que todos os parceiros sejam alcançados com encriptação. Se uma determinada versão ou verificação de certificado for um requisito contratual, atribua a esse parceiro uma policy Required com âmbito muito restrito e execute um teste de falha documentado.

Para ligações enviadas com Required TLS 1.3 ou Required TLS 1.2, também pode ativar Verify certificate. O Sophos verifica então se o certificado foi emitido para o domínio destinatário. Se a verificação falhar, a mensagem não é entregue. Por isso, inclua no âmbito externo o domínio destinatário real e verifique que host e certificado são apresentados pelo respetivo percurso MX; um domínio de parceiro com nome semelhante não serve como substituto.

Não confundir Push Encryption ou Portal Encryption com TLS

Push Encryption está disponível apenas para mensagens enviadas. O Sophos converte o conteúdo da mensagem num ficheiro de documento protegido por palavra-passe; os anexos do Microsoft Office, ZIP e PDF utilizam a sua encriptação nativa, enquanto outros formatos podem ser disponibilizados como PDF. Na primeira utilização, o destinatário cria uma palavra-passe do Sophos Secure Message através da notificação. A ligação da notificação expira após 30 dias. A palavra-passe aplica-se apenas a mensagens da mesma região da mensagem original. Para a abertura pelo destinatário, a utilização da palavra-passe e as respostas seguras, consulte Operar a encriptação Portal e Push do Sophos Email.

Portal Encryption também está disponível apenas para mensagens enviadas e requer uma licença Sophos Email com o Portal Encryption Add-on. O destinatário lê e responde à mensagem no Sophos Secure Message e cria uma conta ao receber a primeira mensagem. A personalização visual, a administração de destinatários, a expiração e a recolha de mensagens fazem parte de um processo operacional separado do portal; este artigo apenas seleciona o método na policy.

Secure using S/MIME requer CAs, certificados de utilizador e destinatário e chaves privadas previamente configurados. O S/MIME pode assinar sem necessariamente encriptar. Por isso, o aprovisionamento, a confiança, a extração e a reposição de certificados pertencem a um processo S/MIME separado e não são substituídos por Verify certificate do TLS.

Para TLS de saída destinado a um parceiro sem suporte de TLS, o Sophos oferece Allow unencrypted delivery ou Fallback to push encrypt the entire message; o Sophos recomenda o fallback Push. Quando o fallback Push está configurado e a negociação TLS falha, o Sophos envia a mensagem com Push Encryption em vez de a colocar na fila para novas tentativas TLS. Selecione a entrega sem encriptação apenas quando a classificação dos dados o permitir expressamente. O fallback Push só é adequado se os destinatários puderem abrir documentos protegidos por palavra-passe e se o processo de registo inicial for aceitável. Se não existir um fallback aprovado nem uma negociação TLS funcional, não conte com um retorno silencioso a texto não encriptado.

Criar e limitar a Secure Message policy

Abra My Products > Email Security > Policies e clique em Add Policy.
Selecione Secure Message e depois Continue. Introduza um nome claro, por exemplo SM-Outbound-Partner-TLS13.
Em Internal, adicione utilizadores, grupos ou domínios. Basta uma correspondência em qualquer uma das listas. Passe o cursor sobre o nome de um utilizador para verificar o respetivo endereço de correio.
Para uma regra específica de parceiro, abra External e adicione o endereço de correio ou domínio exato, manualmente ou a partir de um ficheiro. Verifique se a lista está incluída ou excluída; a predefinição é Include all. A policy aplica-se quando uma entrada interna comunica com uma entrada externa.
Abra Settings, selecione Inbound ou Outbound e ative Secure inbound messages ou Secure outbound messages.
Em Select the method to secure messages, escolha o método aprovado. Para TLS, defina depois Preferred TLS 1.3, Required TLS 1.3 ou Required TLS 1.2.
Se necessário para um parceiro Required TLS de saída, ative Verify certificate. Defina explicitamente o fallback ou o comportamento de falha; não o deduza do nome da policy.
Para Push ou Portal Encryption, escolha o idioma das mensagens de notificação e registo enviadas aos destinatários.
Em Choose how to secure, decida se todas as mensagens devem ser protegidas ou se os utilizadores devem ativar a proteção através de uma etiqueta no assunto. A etiqueta fixa predefinida secure: ativa sempre a encriptação, mesmo quando estão definidos acionadores personalizados. Acionadores personalizados como secureTest: ou secureFull: têm de aparecer completos e exatamente no início do assunto; uma subcadeia não é suficiente.
Defina a policy-piloto como Policy is enforced, guarde-a e verifique a prioridade. Opcionalmente, pode definir uma data e hora para a desativar automaticamente.

Utilize Clone para vários âmbitos semelhantes. Um clone começa como Policy Bypassed, um clone da Base Policy não tem utilizadores, grupos ou domínios e, por predefinição, tem prioridade sobre a policy original. Verifique o âmbito, as definições e a ordem antes de selecionar Policy is enforced.

Os tenants migrados podem ter policies cujos nomes começam por Migrated. Estas contêm as antigas definições TLS e de encriptação de Global Settings, bem como os utilizadores e domínios protegidos no momento da migração. Podem ser editadas, renomeadas, combinadas ou eliminadas, mas apenas depois de comparar o âmbito, método, fallback e prioridade com o estado pretendido atual.

Interação com Data Control

Uma ação de encriptação de saída numa policy Data Control substitui o método de encriptação selecionado na Secure Message policy. Se uma mensagem utilizar inesperadamente Push ou Portal em vez de TLS, verifique a Secure Message policy e as regras Data Control correspondentes. Verifique o âmbito e a ordem separadamente, porque as famílias de policies desempenham tarefas diferentes.

Validar com destinatários representativos

Para a aceitação, envie mensagens controladas e não confidenciais para, pelo menos, um destinatário dentro do âmbito da policy e um destinatário de comparação fora dele. Um plano de teste TLS específico de um parceiro inclui:

um parceiro que suporte a versão TLS selecionada e, com Verify certificate ativo, apresente um certificado correspondente;
um parceiro que suporte TLS 1.2, mas não TLS 1.3, para testar Preferred TLS 1.3;
um teste negativo aprovado em que o requisito TLS ou de certificado não seja satisfeito;
no caso de um fallback Push configurado, um destinatário que conclua a notificação, criação da palavra-passe e abertura da mensagem;
no caso de etiquetas no assunto, uma mensagem com o acionador exato, uma com um acionador incompleto e uma sem acionador.

Em Message History, abra Filter à esquerda, selecione a categoria Secure message e filtre pela versão TLS. Abra o assunto. Em Message Details, ao passar o cursor sobre as reticências de três pontos em Status, verá se a ligação foi protegida com TLS e que versão TLS foi autenticada. Se o Sophos não tiver conseguido verificar a assinatura da CA emissora, SMTP Text indica que a entrega TLS não era fidedigna.

Um registo de aceitação bem-sucedido inclui o nome e a prioridade da policy, os valores dos âmbitos interno e externo, Message-ID, data e hora, destinatário, método selecionado, versão TLS observada, resultado do certificado, fallback e resultado final no destinatário. Uma entrada em Message History, por si só, não prova que o destinatário conseguiu ler a mensagem.

Investigar falhas TLS, fila e certificados

Se o Sophos Email não conseguir estabelecer uma ligação TLS obrigatória e nenhum fallback configurado processar a mensagem, esta não é enviada. O Sophos coloca-a na fila para novas tentativas de entrega durante até sete dias e depois elimina-a. Cada tentativa de envio relacionada com TLS cria uma entrada no histórico com o formato Processing: Check TLS; após a falha final, o registo indica que a mensagem foi eliminada devido à TLS policy. Este não é um mecanismo adequado para testar durante sete dias, em produção, uma definição Required incorreta.

Verifique pela seguinte ordem:

A Secure Message policy esperada está definida como Policy is enforced, com os âmbitos interno e externo corretos e a prioridade pretendida?
Uma ação Data Control substitui o método ou a etiqueta fixa secure: ativa a encriptação?
O seu servidor de correio e o parceiro suportam a versão selecionada? TLS 1.0 e TLS 1.1 não são opções de fallback.
O TLS e as cifras necessárias estão ativos, em particular a cadeia documentada TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
Com Verify certificate, o certificado apresentado corresponde ao domínio destinatário real e o Sophos consegue verificar a CA emissora?
Message History, Processing: Check TLS e SMTP Text indicam um erro de versão, confiança ou negociação?

Se a causa continuar por esclarecer, reúna o nome, âmbito e prioridade da policy, Message-ID, data e hora, direção, domínio destinatário, versão TLS esperada e observada, bem como os textos relevantes do histórico e SMTP para o Sophos Email Support. Não inclua chaves privadas, palavras-passe nem conteúdo confidencial da mensagem no pedido de suporte.

Executar o rollback com segurança

Se o fluxo de correio tiver um comportamento inesperado, volte primeiro a colocar a nova policy em Policy Bypassed ou utilize a hora de desativação preparada e restaure a prioridade anterior. Volte a testar em ambas as direções e confirme o percurso anterior em Message History e junto do destinatário. Não flexibilize simultaneamente a versão TLS, a verificação do certificado e o âmbito, pois isso ocultaria a causa.

Um fallback temporário para Preferred TLS 1.3, Push Encryption ou entrega sem encriptação só é permitido se o responsável pelos dados e o responsável pela alteração aprovarem explicitamente essa opção. Se o texto não encriptado for proibido, é mais seguro reter a mensagem enquanto o parceiro corrige a versão TLS, as cifras ou a cadeia de certificados. Expanda o âmbito ou limpe uma policy Migrated antiga apenas depois de testes-piloto e negativos bem-sucedidos.