Configurar a encriptação de email SPX na Sophos Firewall

Com o Secure PDF Exchange, ou SPX, a Sophos Firewall converte um email de saída e os respetivos anexos num ficheiro PDF protegido por palavra-passe. O destinatário não precisa de um cliente de encriptação próprio. Consoante o modelo selecionado, recebe uma palavra-passe de utilização única, usa uma palavra-passe guardada ou regista uma pessoalmente.

Para um funcionamento fiável, quatro elementos têm de trabalhar em conjunto: um modelo SPX, um acionador inequívoco, um canal seguro para a palavra-passe e, se necessário, o SPX Reply Portal. Depois são testados um fluxo positivo e outro negativo. A simples entrega de um PDF não prova que a política correta tenha sido acionada nem que o registo da palavra-passe e a resposta segura funcionem.

SPX em oito passos

1. Verificar a licença Email Protection, o fluxo de correio MTA, o suporte do modelo, o certificado do portal e o caminho SMTP TLS separado.
2. Decidir se a encriptação é acionada por um domínio protegido, uma correspondência de Data Control ou pelo remetente.
3. Criar um modelo próprio em Email > Encryption > SPX templates > Add.
4. Escolher conscientemente o tipo de palavra-passe, a encriptação PDF, a notificação e o Reply Portal.
5. Proteger o FQDN, as redes permitidas e a porta em Email > Encryption > SPX portal settings.
6. Em MTA mode, configurar a política SMTP route and scan e atribuir o modelo; um Default SPX template não substitui esta política.
7. Testar o PDF, o canal da palavra-passe, o registo e a resposta com um destinatário externo.
8. Executar um teste negativo sem acionador SPX e documentar Mail logs, os registos MTA e a reversão.

⚠️ Um campo Allowed networks vazio no SPX Portal não significa «sem acesso», mas regressa a Any. A Sophos também recomenda uma porta dedicada para o Reply Portal. Por isso, o FQDN do portal, o certificado, as origens permitidas e o canal da palavra-passe têm de estar definidos antes do teste em produção.

Quando o SPX é adequado

O SPX é útil quando destinatários externos devem receber conteúdo confidencial como PDF protegido sem instalar um cliente de encriptação. Pode ser usado tanto em MTA mode como em Legacy mode. Este procedimento utiliza MTA mode porque permite ligar de forma clara o domínio, Data Control e o encaminhamento na política SMTP. Configurar o Mail Protection em Legacy mode explica a alternativa transparente.

O SPX não é encriptação de transporte entre servidores de correio nem encriptação ponto a ponto entre dois clientes de email. A firewall processa o texto não encriptado, gera o PDF e controla a palavra-passe ou o registo. O PDF pode depois continuar a existir fora da firewall em caixas de correio, arquivos ou transferências. O âmbito dos destinatários, a retenção e a entrega da palavra-passe fazem, portanto, parte do desenho de segurança.

A encriptação de transporte SMTP é controlada separadamente em Email > General settings > SMTP TLS configuration. Require TLS negotiation impõe TLS aos hosts remotos ou redes selecionados; se o SFOS não conseguir estabelecer a ligação TLS, descarta o email destinado a esse destino. Em contrapartida, Skip TLS negotiation força uma ligação SMTP não encriptada. O TLS certificate selecionado nesse local protege o caminho SMTP e não é o certificado dos portais SPX. Por isso, o SPX e o SMTP TLS são planeados separadamente e depois validados em conjunto no fluxo externo.

Os pré-requisitos são:

• uma licença Email Protection válida;
• um fluxo de correio de saída já testado através da Sophos Firewall;
• um destinatário externo de teste documentado;
• um FQDN de confiança e um certificado correspondente para os portais SPX utilizados;
• um canal seguro separado para palavras-passe quando não são registadas pelo destinatário;
• uma via de recuperação que permita remover novamente as atribuições de modelo e política.

Segundo a ajuda atual da Sophos, o SPX não está disponível nos XGS 87/87w. Além disso, o MTA mode completo não está disponível nos XGS 88/88w. Configurar o Mail Protection em MTA mode explica o fluxo de correio, a licença, o relay e os limites de modelo.

Definir o acionador e a prioridade

O SPX pode ser acionado de três formas. Se forem configurados vários métodos, a Sophos Firewall aplica esta ordem em MTA mode:

1. Domínio protegido: O modelo SPX selecionado em Domains and routing target aplica-se às mensagens de saída do domínio protegido correspondente.
2. Data control list: Apenas se não existir um modelo SPX ao nível do domínio, uma correspondência de Data Control pode aplicar o modelo selecionado para a lista.
3. Acionador do remetente: Só quando nem o domínio nem Data Control fornecem um modelo é aplicado o método do remetente configurado em Default SPX template.

Uma atribuição ao domínio é ampla e só é adequada quando todas as mensagens de saída correspondentes devem realmente ser encriptadas. Data Control é apropriado para tipos de conteúdo definidos, mas tem de ser testado com exemplos positivos e negativos reais para detetar falsos positivos. O acionador do remetente deixa a decisão ao remetente, mas exige um procedimento de cliente de email claramente documentado.

Antes da configuração é definido exatamente um acionador principal para cada fluxo de correio. Um segundo método não pode sobrepor-se silenciosamente a outro.

Criar o modelo SPX

O exemplo utiliza o modelo Finance-SPX-Recipient. O nome é um valor de documentação e deve ser adaptado à finalidade e à organização.

Podem ser utilizados modelos separados com textos adequados e logótipos de empresa para diferentes domínios de clientes. Não é apenas uma questão de apresentação: as instruções do destinatário têm de corresponder ao modelo de palavra-passe e ao domínio realmente atribuído.

1. Abrir Email > Encryption > SPX templates.
2. Selecionar Add.
3. Introduzir um nome, por exemplo Finance-SPX-Recipient. O SFOS não permite apóstrofos, barras, vírgulas, barras invertidas ou aspas no nome.
4. Definir o nome da organização para as notificações.
5. Selecionar Encryption standard e PDF page size de acordo com os requisitos internos.
6. Em Password type, selecionar o modelo de palavra-passe planeado.
7. Rever o assunto, o corpo da mensagem e as instruções para o destinatário e adaptá-los se necessário.
8. Para este procedimento MTA, ativar Enable SPX reply portal, tal como exige a ajuda do modelo. Antes do teste, proteger o acesso ao portal conforme descrito abaixo.
9. Ativar Include original body into reply apenas se a mensagem original puder ser incluída na resposta.
10. Guardar o modelo.

Escolher conscientemente o modelo de palavra-passe

A Sophos Firewall oferece quatro modelos:

• Specified by sender: O remetente define a palavra-passe. A firewall remove-a antes do envio e não a guarda. A palavra-passe tem de chegar ao destinatário por um canal seguro separado.
• Generate one-time password for every email: A firewall gera uma nova palavra-passe para cada mensagem e envia-a ao remetente. Este entrega-a separadamente ao destinatário. A palavra-passe não é guardada.
• Generated and stored for recipient: A firewall gera uma palavra-passe específica do destinatário, envia-a ao remetente e volta a utilizá-la até expirar.
• Specified by recipient: Um destinatário ainda não registado recebe um link de registo, define a própria palavra-passe e utiliza-a até expirar para outras mensagens SPX da organização.

Com Specified by recipient, a primeira mensagem encriptada só é enviada depois do registo da palavra-passe; receber o link de registo não significa, portanto, que o PDF SPX tenha sido entregue.

Numa relação contínua com um parceiro, Specified by recipient é frequentemente o procedimento mais fácil de compreender. Uma palavra-passe de utilização única pode ser mais adequada para um único envio especialmente sensível. Diferentes modelos de palavras-passe guardadas não devem ser misturados sem planeamento para o mesmo destinatário, porque este teria de identificar a palavra-passe correspondente a cada mensagem.

Com Specified by sender, a palavra-passe é introduzida no assunto segundo o padrão [secure:<password>]<subject text>. Depois, o remetente tem de entregar a palavra-passe separadamente. Para o Microsoft Outlook, a Sophos disponibiliza um Outlook Add-in em Authentication > Client downloads.

Depois de verificar a instalação, selecionar Encrypt no Outlook para a mensagem a encriptar. A simples instalação do suplemento não aciona a encriptação.

Instalar o Outlook Add-in de forma controlada

Os utilizadores sem acesso ao WebAdmin abrem Download client no User Portal e selecionam Download Sophos Outlook Add-in. O arquivo descarregado é extraído para uma pasta temporária; para a instalação interativa, executa-se aí setup.exe. O download administrativo em Authentication > Client downloads constitui uma via de acesso distinta.

Verificar o nome do ficheiro MSI antes da distribuição: A ajuda do User Portal para SFOS 22 e 23 indica SophosOutlookAddInSetup.msi; em contrapartida, a descrição da instalação SPX indica SophosOutlookAddInSetupUTM.msi, como no exemplo existente abaixo. Não está confirmado que estes nomes sejam intercambiáveis. É necessário verificar o nome real do ficheiro MSI no pacote extraído. O exemplo seguinte só se aplica se o ficheiro se chamar efetivamente SophosOutlookAddInSetupUTM.msi. Num pacote com SophosOutlookAddInSetup.msi, utiliza-se exatamente esse nome existente como argumento de /i; os parâmetros documentados /qr /i e T=1 EC=3 C=1 I=1 permanecem inalterados. Se faltar o MSI esperado ou não for possível identificar inequivocamente o pacote, interrompe-se a distribuição e esclarece-se a identificação do pacote, em vez de mudar o nome de um ficheiro ou presumir o suporte de plataformas modernas.

Para uma instalação interativa, executar setup.exe a partir do pacote descarregado da firewall ativa. A Sophos documenta este comando para uma implementação sem intervenção:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

A lista pública de compatibilidade está claramente desatualizada: A ajuda do SFOS documenta os seguintes pré-requisitos históricos para a instalação sem intervenção do SPX Outlook Add-in: Windows XP, Windows Vista, Windows 7 ou Windows 8, em todos os casos nas versões de 32 bits e de 64 bits; Microsoft Outlook 2007 SP3, 2010 ou 2013, também em todos os casos nas versões de 32 bits e de 64 bits; Microsoft .NET Framework 4 Client Profile e Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. Daqui não se pode deduzir o suporte das Microsoft 365 Apps atuais nem de versões modernas do Windows. Por isso, antes de uma distribuição alargada, verificam-se num dispositivo piloto o pacote efetivamente descarregado, as versões do Windows e do Outlook e as respetivas arquiteturas de 32 ou 64 bits, um acionador SPX positivo e outro negativo, bem como a desinstalação. Os parâmetros MSI não explicados não são alterados com base em suposições.

A ajuda atual da Sophos utiliza duas grafias diferentes do cabeçalho para outros clientes de email: X-Sophos-SPXEncrypt: yes na página do modelo e X-Sophos-SPX-Encrypt: yes na página geral Encryption. Esta divergência não é tratada como uma receita para copiar e colar. Antes de uma implementação em produção, é necessário verificar qual a grafia que funciona no build SFOS utilizado. Sempre que possível, uma política, Data Control ou o Sophos Outlook Add-in constitui um acionador mais rastreável.

Conceber a notificação sem criar outra fuga de dados

As variáveis disponíveis para as notificações incluem:

• %ENVELOPE_TO%: destinatário da palavra-passe.
• %PASSWORD%: palavra-passe para abrir o PDF SPX.
• %ORGANIZATION_NAME%: nome da organização introduzido no modelo.
• %SENDER%: remetente do email.
• %REG_LINK%: link para registar a palavra-passe.

São suportados formatação HTML simples e links. O texto tem de explicar quem enviou a mensagem, como obter a palavra-passe de forma segura e durante quanto tempo são possíveis o registo ou a resposta. Credenciais ou conteúdo confidencial do email não devem ser repetidos numa notificação desprotegida.

Reset repõe a notificação predefinida. Guardar previamente os textos personalizados; depois da reposição, verificar novamente o assunto, o corpo da mensagem e as instruções do destinatário.

Definir os períodos de validade e as notificações de erro

Os períodos e os destinatários dos erros são definidos em Email > Encryption > SPX configuration, não em SPX portal settings:

• Keep unused password for: Validade de uma palavra-passe guardada quando não é enviado nenhum email SPX a esse destinatário. Por exemplo, com três dias, a ajuda indica que expira à meia-noite no final do terceiro dia. É um período de inatividade, não uma duração universal de cada PDF.
• Allow secure reply for: Número de dias durante os quais o destinatário pode responder através do SPX Reply Portal; esta definição pertence ao procedimento MTA.
• Allow password registration for: Período após o qual o link de registo expira. É independente do período das palavras-passe guardadas.
• Send error notification to: Destinatários responsáveis pelas notificações de erro SPX. Os erros também constam do registo SMTP.

Escolher os períodos de acordo com as necessidades de resposta e as regras de segurança da organização. No piloto, testar separadamente o registo, a inatividade da palavra-passe e o prazo de resposta. A expiração na firewall não prova que um PDF já entregue tenha sido eliminado ou já não possa ser aberto.

Proteger os portais SPX

O registo de palavras-passe e o acesso ao portal são definidos em Email > Encryption > SPX portal settings:

1. Em Hostname, introduzir o FQDN através do qual os destinatários externos chegam realmente ao portal.
2. Em Allowed networks, definir apenas as redes de origem necessárias. Any só é adequado quando destinatários externos arbitrários têm de aceder ao portal e o risco é aceite conscientemente.
3. Documentar a porta. O Password Registration Portal utiliza por predefinição TCP 8094.
4. Utilizar uma porta dedicada para o SPX Reply Portal.

Se Allowed networks ficar vazio, o SFOS utiliza Any, porque o SPX Reply Portal está ativo por predefinição na zona WAN. Se o Reply Portal não for necessário, a Sophos documenta a utilização de um endereço privado de confiança não utilizado, por exemplo 169.254.0.1, como única rede permitida para o desativar. Este valor de documentação não pode corresponder a um endereço utilizado em produção.

O CAPTCHA está sempre ativo no SPX Portal e não pode ser desativado. Gerir conscientemente o CAPTCHA na Sophos Firewall explica os limites das definições CAPTCHA dos outros portais.

WebAdmin, User Portal, VPN Portal, Captive Portal e os dois portais SPX utilizam a mesma seleção central de certificado. Uma alteração pode, por isso, afetar vários serviços ao mesmo tempo. O certificado, os SAN, a via de recuperação e o URL real do portal devem ser planeados com Gerir certificados na Sophos Firewall. Um certificado Let’s Encrypt na Sophos Firewall pode ser adequado para um nome público.

A seleção encontra-se em Administration > Admin and user settings > Admin console and end-user interaction > Certificate. A identidade do certificado no SAN ou CN tem de corresponder ao FQDN do portal introduzido em Hostname, e a cadeia de CA completa tem de estar presente na firewall. Uma troca de certificado não é, portanto, uma alteração exclusiva do SPX: verificar também o WebAdmin e os outros portais depois da troca.

Ligar o modelo à política SMTP

Em MTA mode, o modelo SPX é selecionado na política SMTP route and scan correspondente em Email > Policies and exceptions.

Utilizar um domínio como acionador

Em Domains and routing target, o modelo é atribuído ao domínio protegido. Passa então a aplicar-se às mensagens de saída correspondentes. Uma atribuição ampla ao domínio é primeiro testada com um remetente piloto e um destinatário externo de teste.

Utilizar Data Control como acionador

Uma Data Control List não é uma regra de conteúdo formulada livremente. É construída a partir de Sophos Content Control Lists, ou CCLs, para padrões de dados definidos. Ao criá-la, filtrar as CCLs por Type e Region. No piloto incluem-se apenas os padrões realmente necessários, para que uma seleção demasiado ampla não acione desnecessariamente o envio SPX.

1. Criar uma lista com um nome claro em Email > Data control list ou rever a lista existente.
2. Ativar Data protection na política SMTP route and scan e selecionar exatamente essa lista em Data control list.
3. Definir Data control list action como Accept with SPX e selecionar o SPX template previsto. Accept entrega sem SPX; Drop descarta a mensagem sem notificar o remetente.
4. Executar um teste positivo de conteúdo e um teste negativo semelhante.

Se já existir um modelo SPX em Domains and routing target, este tem prioridade sobre o modelo Data Control. Além disso, uma correspondência da Data Control List apenas prova o match de conteúdo configurado. O fluxo real de correio tem de confirmar se foi encriptada a mensagem correta.

Utilizar um acionador do remetente

Em Email > Encryption > SPX configuration, selecionar um Default SPX template. Este só se aplica à encriptação SPX acionada pelo remetente quando a política SMTP ainda não fornece um modelo ao nível do domínio ou de Data Control. None desativa este caminho predefinido.

Para MTA mode, a ajuda exige expressamente uma política SMTP route and scan configurada e a seleção do modelo em Domains and routing target ou Data control list. Indica example.com como domínio fictício se não se pretender especificar um domínio protegido. É um exemplo de documentação, não um domínio de correio de produção nem uma autorização geral de relay ou encaminhamento. A atribuição da política e os dois casos de teste também têm de estar corretos neste caso especial. A descrição geral do modelo predefinido não demonstra que o MTA possa funcionar sem política SMTP. None desativa apenas o caminho predefinido, não uma atribuição SPX numa política.

Automatizar o SPX através da XML API

Para alterações recorrentes, começa-se por registar o modo de correio, os modelos existentes e as respetivas atribuições a políticas ou como predefinição. As referências XML para SFOS 22 e 23 distinguem os objetos Legacy dos objetos MTA; nomes de campos iguais não tornam os respetivos payloads intercambiáveis. As informações seguintes explicam o contrato documentado, mas não constituem um pedido de escrita executável nem comprovam a realização de um teste em laboratório. A autorização das origens, a conta de serviço com privilégios mínimos, a verificação TLS, a operação explícita, o backup e a avaliação do estado XML em vez do estado HTTP são abordados em Limitar o acesso à XML API em segurança e verificar as respostas. Antes de efetuar uma escrita, confirmar o contrato completo do objeto em API help do build instalado; as contradições por esclarecer não devem ser contornadas com um payload baseado em suposições.

Configuração global: separar Legacy e MTA

Legacy: O exemplo documentado apresenta dois níveis de SPXConfiguration: um SPXConfiguration exterior, que contém outro SPXConfiguration. O elemento interior contém SPXGlobalTemplate com DefaultSPXTemplate; ao mesmo nível encontram-se HostName, AllowedNetworks com entradas Network repetíveis, Port, KeepUnusedPassFor, AllowPassRegistrationFor e SendNotifcationErrorTo. Não remover o nível duplo por presumir que se trata de um erro tipográfico nem utilizar o exemplo como esquema MTA genérico.

MTA: O objeto separado chama-se MTASPXConfiguration. O respetivo exemplo contém diretamente SPXGlobalTemplate com DefaultSPXTemplate, bem como o nome do host, a porta, os prazos das palavras-passe e a notificação de erro, sem os dois níveis aninhados de Legacy. Para ambos os contratos, a tabela de parâmetros indica Network, DefaultSPXTemplate e HostName como arrays opcionais de strings; isto não confirma a validade de uma estrutura de array construída arbitrariamente. O FQDN do portal e as origens permitidas são comparados com as verificações do portal e dos certificados descritas acima. O valor de exemplo MTA None em HostName não comprova um estado de desativação seguro.

Os parâmetros obrigatórios são KeepUnusedPassFor (número de dias documentado como string, predefinição 30), AllowPassRegistrationFor (número inteiro de dias, predefinição 10), Port (inteiro, predefinição 8094, intervalo de 1025 a 65535) e SendNotifcationErrorTo. A grafia SendNotifcationErrorTo permanece inalterada apesar da letra em falta. Os tokens permitidos são SenderOnly e Nobody; contudo, o exemplo Legacy e a indicação da predefinição apresentam Sender Only. Não normalizar silenciosamente esta divergência nem deduzir, apenas a partir da indicação apresentada, que qualquer dos dois valores é um valor XML testado. Se o contrato do build utilizado não estiver esclarecido, interromper a tarefa de escrita.

Apenas a tabela MTA inclui adicionalmente AllowSecureReplyfor como campo obrigatório para o prazo de resposta (número de dias em formato string, predefinição 30). É precisamente este campo que falta no exemplo MTA. Por isso, o exemplo não comprova integralmente que um pedido esteja pronto para produção; não omitir o prazo de resposta sem verificação nem inventar uma grafia com maiúsculas e minúsculas diferentes. O modelo global, a inatividade da palavra-passe, o registo e o prazo de resposta continuam a ser decisões separadas; nenhuma substitui a atribuição na política SMTP.

Para Update SPX Configuration no contrato Legacy, estão documentadas as seguintes correspondências de estado XML:

Em contrapartida, o contrato MTA da mesma operação indica 200 com Operation Successful. e 500 com Operation Fail.. Não apresentar o código Legacy 541 como uma resposta MTA documentada nesse contrato. Para a correspondência Legacy 541, verificar primeiro a utilização real das portas e a porta do portal guardada, em vez de repetir a tarefa sem alterações ou modificar o SMTP TLS.

Modelos: proteger a identidade, os valores e a notificação

Para Legacy está documentado SPXTemplates e, para MTA, MTASPXTemplates. Name é a identidade única obrigatória do modelo, com um máximo de 255 caracteres, e é comparado exatamente com o objeto existente antes de uma atualização ou eliminação. Description e OrganizationName são strings opcionais; para OrganizationName aplica-se igualmente o máximo de 255. Um novo texto de descrição não justifica voltar a criar cegamente um objeto com o mesmo nome.

Ambos os contratos exigem PDFEncryption, PageSize e PasswordType. Os valores exatos de seleção são:

• PDFEncryption: AES/128 ou AES/256.
• PageSize: A/4, Letter ou Legal. A indicação da predefinição A4 não é o token de seleção documentado A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient ou SpecifiedByRecipient. A indicação da predefinição Specified by sender não constitui uma recomendação de token XML.

NotificationSubject, NotificationBody e InstructionsForRecipient são strings opcionais. Segundo o contrato, os dois campos de notificação só se aplicam aos modelos de palavras-passe geradas ou registadas pelo destinatário, não a SpecifiedBySender. Apenas o modelo MTA acrescenta SPXReplyPortal e IncludeOriginalBodyIntoReply: ambos opcionais, com a predefinição Disabled e os valores permitidos Disabled ou Enable. O exemplo Enable/Disabled é uma notação de seleção, não um valor único a enviar. Não confundir a obrigatoriedade do Reply Portal no procedimento da interface gráfica MTA descrito acima com o campo opcional da API e a respetiva predefinição.

Os textos das notificações são localizados, mas os marcadores técnicos são mantidos inalterados. Os exemplos da API apresentam adicionalmente %CURRENT_RECIPIENT% e, no assunto, %%ENVELOPE_TO%% ou %%ORGANIZATION_NAME%%; não os converter automaticamente nas variáveis delimitadas por um único sinal de percentagem de cada lado indicadas acima. Antes de uma alteração, guardar uma cópia do modelo efetivamente armazenado e verificar a resolução das variáveis com uma nova mensagem de teste. O HTML padrão, as instruções históricas sobre leitores de PDF e as palavras-passe de exemplo da referência não constituem um modelo obrigatório para notificações próprias. O HTML, as aspas e as quebras de linha têm de ser serializados de forma controlada e verificados depois de guardar. Também não adotar o |n visível no exemplo MTA como método universal de escape sem confirmação específica para o build.

As correspondências documentadas coincidem para os modelos Legacy e MTA:

Os identificadores Message.* continuam a ser chaves de mensagem não resolvidas da referência, não textos comprovados em tempo de execução. Para 502, verificar a identidade exata e o conteúdo existente, sem mudar automaticamente de Add para Update. Para Update-541, investigar as atribuições reais de Spam/Data Control e SPX, sem deduzir do símbolo um mecanismo universal de conflito. Para Delete-504, esclarecer primeiro as referências nas políticas e na configuração global; a ordem de reversão descrita abaixo continua a ser obrigatória. Antes de cada nova tentativa, comparar a resposta com o estado efetivamente guardado e verificar o objeto de destino mesmo após 200. Só um novo email de teste positivo e outro negativo, juntamente com os testes de palavra-passe e de resposta, permitem validar o efeito operacional.

Validar o fluxo de correio encriptado

Registar a hora do teste, o remetente, o destinatário, o assunto e o acionador esperado. Depois testar, pelo menos, estes casos:

1. Teste positivo: Uma mensagem de saída aciona exatamente o modelo SPX previsto.
2. Teste da palavra-passe: O destinatário recebe a palavra-passe ou o link de registo através do canal planeado e consegue abrir o PDF.
3. Teste de conteúdo: O assunto, o corpo e os anexos aparecem no PDF como esperado e são legíveis.
4. Teste de resposta: Se estiver ativo, o link de resposta conduz ao FQDN esperado e uma resposta de teste chega ao remetente original.
5. Teste negativo: Uma mensagem semelhante sem acionador não é enviada como PDF SPX.
6. Teste de expiração: O registo, a palavra-passe guardada e o período de resposta comportam-se de forma previsível após a validade definida.
7. Teste de certificado: O browser e o destinatário externo recebem uma cadeia de certificados completa e de confiança para o FQDN do portal utilizado.

Iniciar a correlação em Email > Mail logs. Em Reason, SPX encryption identifica as mensagens encriptadas com SPX e SPX failure as mensagens SPX não entregues; em Result, filtrar adicionalmente, por exemplo, por Delivered, Dropped ou Quarantined. Comparar remetente, destinatário, assunto e intervalo de tempo com a nota de teste. Para erros detalhados, continuar no Log Viewer e nos ficheiros MTA smtpd_main.log, smtpd_error.log e smtpd_panic.log. Serviços e registos da Sophos Firewall explica o acesso e outros ficheiros de registo.

SPX failure não é outro nome para a quarentena SMTP. Uma mensagem só aparece em Email > SMTP quarantine quando uma ação Spam, Malware, Unscannable, DKIM ou outra ação de política a coloca realmente em quarentena. Durante o teste, não libertar simplesmente a mensagem antes de documentar o motivo e a política acionada; caso contrário, um erro de análise ou política pode ser confundido com um erro SPX.

Em HA, os registos encontram-se no nó que processou o tráfego. Depois de um failover controlado, testar separadamente um novo email SPX, o registo da palavra-passe e a resposta. Não se presume que uma sessão existente do portal ou um processo de registo em curso continuem sem interrupção. Os fundamentos são explicados em Clusters HA da Sophos Firewall.

Delimitar erros de forma sistemática

A mensagem não é encriptada

Verificar a direção, o domínio protegido, a política SMTP route and scan realmente utilizada e a prioridade dos acionadores. Para Data Control, verificar também Data protection, a Data control list selecionada, Data control list action: Accept with SPX e o respetivo SPX template. Para um acionador do remetente tem de existir um modelo predefinido, que não pode ser sobreposto por um modelo de domínio ou Data Control. As duas grafias documentadas do cabeçalho não são motivo para implementar ambas sem testes em produção.

Mail logs mostra SPX failure

Em Email > Mail logs, delimitar a linha afetada por hora, remetente, destinatário e assunto, e confirmar Reason: SPX failure. Correlacionar o erro apresentado com smtpd_main.log, smtpd_error.log e, para erros graves de processo, smtpd_panic.log no mesmo horário. Só então alterar o modelo de palavra-passe, o template, a entrega ou o caminho do portal. Se Result for Quarantined, investigar em Email > SMTP quarantine a análise ou ação de política acionada.

O link de registo ou o portal não está acessível

Verificar o FQDN, a resolução DNS pública, a porta, o certificado, Allowed networks e a validade do link. Um valor Allowed Networks vazio é tratado como Any e, portanto, não é um estado de desativação seguro. Se o cliente chegar a outro host ou portal, o URL, NAT ou a atribuição de certificado não correspondem ao caminho planeado.

Não é possível abrir o PDF

Começar por comparar o tipo de palavra-passe com a mensagem específica. Uma palavra-passe de utilização única só se aplica a esse email. Com palavras-passe guardadas ou registadas, a causa pode ser a expiração ou vários modelos de palavra-passe. Depois de um SPX Password Reset, o remetente tem de voltar a transmitir a nova palavra-passe ao destinatário de forma segura.

Para uma reposição específica, introduzir em Email > Encryption > SPX password reset o endereço de email do destinatário afetado e verificá-lo antes de iniciar a operação. Coordenar a reposição e a entrega segura da nova palavra-passe com remetente e destinatário; depois, abrir uma nova mensagem SPX de teste. Isto não garante que os PDF antigos possam ser abertos com a nova palavra-passe.

A resposta segura não chega

Verificar Enable SPX reply portal no modelo, o período de resposta, o FQDN do portal, a porta, o certificado e as origens permitidas. Em seguida, verificar Mail logs e os registos MTA para a resposta específica. Abrir o PDF com sucesso não prova que o canal de retorno funciona.

A validação DKIM falha depois do SPX

O SPX altera o corpo e os anexos. Se uma mensagem for assinada antes desta alteração, a assinatura pode tornar-se inválida no destinatário. Definir se o servidor de correio interno, a Sophos Firewall ou um gateway posterior assina depois de todas as alterações planeadas. A cadeia de processamento e um teste externo devem ser validados em conjunto.

Reverter em segurança

1. Remover primeiro a atribuição SPX específica de Domains and routing target. Para um acionador Data Control, repor Data control list action na política SMTP de Accept with SPX para a ação anterior documentada.
2. Se for utilizado, definir Default SPX template como None.
3. Executar um teste negativo de saída e confirmar que não é gerado nenhum PDF SPX novo.
4. Retirar o Reply e Registration Portal apenas se nenhuma outra política SPX ativa depender deles.
5. Repor os acessos públicos temporários de porta, DNS ou portal no estado anterior documentado. Reverter requisitos SMTP TLS alterados separadamente apenas com base no respetivo estado anterior registado.
6. Eliminar o modelo apenas quando nenhuma política ou processo operacional ativo fizer referência ao mesmo.
7. Guardar Mail logs e os registos MTA do último teste encriptado e do primeiro não encriptado.

Criar um backup atual da Sophos Firewall antes de alterar caminhos de correio e portais de produção. O SPX pode continuar a funcionar em ambientes air gap, mas as dependências externas de DNS, certificados e portal têm de permanecer acessíveis separadamente. Os limites do produto são explicados em Funcionalidades SFOS sem acesso à Internet.

Checklist operacional

• A licença, o modelo, o fluxo de correio MTA e o destinatário externo foram verificados.
• O acionador e a respetiva prioridade estão documentados.
• O tipo de palavra-passe e o canal de entrega seguro são adequados ao caso de utilização.
• O FQDN do portal, o certificado central dos portais, a porta e Allowed Networks têm um âmbito restrito; o SMTP TLS está documentado separadamente.
• A atribuição de domínio, Data Control ou predefinida é inequívoca.
• Os testes positivo, negativo, de palavra-passe, PDF e resposta foram bem-sucedidos.
• Os filtros SPX encryption e SPX failure de Mail logs e os registos MTA podem ser correlacionados com a mensagem de teste; as ações de quarentena são distinguidas.
• O failover HA e os registos locais de cada nó estão incluídos no procedimento operacional.
• O responsável, os prazos de expiração, a data de revisão e a reversão estão documentados.

FAQ