Definir o escopo do gateway de saída
Este guia usa a documentação de implantação geral do AsyncOS 16.0 para Cisco Secure Email Cloud Gateway, cujo capítulo sobre autenticação de e-mail é datado de 3 de outubro de 2024. É um plano de aceitação e configuração limitado à versão, não uma reivindicação sobre a versão mais recente ou um locatário inspecionado. O fluxo de trabalho de assinatura documentado cria uma chave, associa um perfil de domínio, publica material de verificação DNS e permite a assinatura na política de saída. O caminho da GUI descrito é Mail Policies, Mail Flow Policies, RELAYED, depois DomainKeys/ DKIM Signing, seguido de submit e commit. A verificação de entrada é separada da assinatura de saída. Uma incompatibilidade de perfil pode deixar uma mensagem sem assinatura. Guia de autenticação de e-mail Cisco
Esse fluxo de trabalho limitado fornece um ponto de partida arquitetônico. Não fornece ao inquilino seletor, chave privada, inventário de IP de saída ou aprovado SPF autorização. O restante deste artigo é um método de revisão original para conectar o fluxo de trabalho documentado às evidências do protocolo. Antes de implementá-lo, o administrador responsável deve confirmar a versão real do gateway, os controles suportados, alterar a autoridade e a rota da mensagem. Nenhum gateway foi acessado e nenhuma chave, política ou mensagem foi criada aqui.
Comece com um contrato de rota
Anote a origem da mensagem e qual sistema faz a conexão SMTP de saída final. Inclua qualquer retransmissão de aplicativo, sistema de caixa de correio upstream, gateway, retransmissão downstream e saída voltada para o destinatário. O objetivo é localizar o ponto onde a assinatura e a autorização SPF devem ser avaliadas, e não coletar todos os endereços de rede internos. Mantenha a configuração confidencial no registro de alterações controladas da organização, em vez de incorporá-la em um artigo amplamente compartilhado.
Para cada rota, registre o domínio De visível esperado, SMTP CORREIO DE domínio e pretendido DKIM domínio de assinatura. Estas são identidades diferentes, mesmo quando uma organização as faz deliberadamente parecer semelhantes. SPF avalia a identidade SMTP relevante e o endereço de conexão. DKIM verifica uma assinatura associada ao seu domínio de assinatura. DMARC relaciona identificadores autenticados qualificados ao domínio visível do autor. A presença de um gateway em uma rota não é uma identidade autenticada em si. RFC 7208 , seções 2.3–2.4 RFC 6376 , seção 3.5 RFC 9989 , seção 4.4
O contrato de rota deve incluir exceções: avisos automatizados, remetentes delegados, aplicações com cabeçalhos incomuns e e-mails que contornam o gateway pretendido. Não aceite uma configuração baseada apenas em uma mensagem conveniente da equipe. Decida quais rotas distintas exigem evidências e quais estão explicitamente fora da implantação. Isso produz um limite revisável em vez de uma declaração não suportada de que todos os emails corporativos são autenticados.
Separe a publicação da chave da aceitação da assinatura
Uma implantação DKIM tem pelo menos duas responsabilidades distintas. O signatário protege e usa a chave privada, enquanto DNS torna o material de verificação correspondente detectável. A assinatura fornece um seletor e um domínio de assinatura que identificam o local da chave. A publicação de um valor TXT de aparência plausível não estabelece que o gateway possui a chave correspondente ou assina a rota pretendida. Por outro lado, permitir a assinatura não prova que o registro público esteja disponível para os destinatários. RFC 6376 , seções 3.5 e 3.6.2.2
Use um registro de alteração que vincule o domínio de assinatura aprovado, o seletor, a impressão digital de chave pública ou o identificador não secreto equivalente, o proprietário DNS e a política pretendida à mesma implantação. Nunca cole chaves privadas na planilha. Obtenha os requisitos atuais de criptografia e gerenciamento de chaves da implementação suportada e da política de segurança organizacional, em vez de copiar os mínimos históricos de um guia antigo. Este manuscrito não fornece deliberadamente nenhum material de chave reutilizável ou comando de geração de chave.
Revise o proprietário exato DNS independentemente da exibição do editor. Um rótulo de seletor relativo pode ser expandido por uma interface DNS , enquanto um nome completo pode exigir tratamento diferente. Preserve o nome totalmente qualificado pretendido e o conteúdo TXT lógico antes da publicação. Várias strings dentro de uma Registro TXT não são a mesma coisa que vários registros de recursos concorrentes. Uma divisão de exibição ou aspas devem ser investigadas no contexto, em vez de tratadas automaticamente como corrupção. RFC 1035 , seções 3.3.14 e 5.1
Revise SPF no limite de saída real
Não invente uma inclusão SPF para toda a Cisco com base no nome do produto. A autorização relevante depende da infraestrutura de saída real e do domínio do envelope. O operador responsável deve obter informações de saída aprovadas atuais, reconciliá-las com os remetentes legítimos existentes e revisar a política completa resultante. Um gateway hospedado, uma plataforma de caixa de correio upstream e um aplicativo podem representar diferentes necessidades de autorização, mesmo quando todos são gerenciados pela mesma equipe.
SPF deve ser publicado como TXT no domínio aplicável. Múltiplo aplicável Registros SPF produzir um erro em vez de combinar em uma lista de permissões maior. O orçamento de avaliação também se aplica aos termos de consulta de DNS avaliados recursivamente, e não apenas ao número de strings de inclusão visíveis na política de nível superior. Revise o comportamento de dependência antes de adicionar outro serviço e preserve um plano de reversão que não remova silenciosamente os remetentes existentes. RFC 7208 , seções 3.1–3.3 e 4.6.4
Um resultado SPF aprovado para um domínio de envelope controlado pelo provedor não está necessariamente alinhado com o domínio De visível da organização. Quando uma rota depende de DKIM alinhado, mantenha essa escolha explicitamente. DMARC exige um resultado SPF ou DKIM qualificado e alinhado, mas um projeto ou fornecedor pode impor pré-requisitos adicionais. Não transforme os caminhos alternativos do protocolo em permissão para ignorar os requisitos da implementação. RFC 9989 , seção 4.4
Crie uma sequência de evidências em vez de uma captura de tela de sucesso
A sequência de aceitação proposta possui pontos de verificação separados para intenção de configuração, DNS publicado e mensagens reais recebidas. Primeiro, confirme se a configuração do inquilino suportada corresponde ao contrato de rota aprovado. Em segundo lugar, retenha as observações DNS autorizadas com nome do proprietário, tipo, valor lógico e tempo de observação. Terceiro, avalie uma mensagem aprovada recebida fora do sistema de envio, registrando os identificadores relevantes e os resultados da autenticação sem publicar correspondência privada.
Quando as evidências discordam, diagnostique a camada antes de mudar a política. Uma mensagem não assinada é um problema diferente de uma mensagem assinada cuja chave de verificação não pode ser encontrada. Uma assinatura válida, mas desalinhada, difere de uma assinatura invalidada pela modificação da mensagem. Uma observação DNS de um cache antigo difere de um registro autoritativo incorreto. Essas distinções evitam que uma equipe enfraqueça DMARC para ocultar um problema de assinatura ou roteamento não resolvido. Verificação DKIM e DMARC alinhamento são avaliações relacionadas, mas separadas. RFC 6376 , seções 3.5–3.6 RFC 9989 , seção 4.4
Diagnóstico ficcional: um percurso que falta no plano
Em uma empresa fictícia, North Quay Parts, a equipe de mensagens prepara assinaturas para correspondência comum. Um aplicativo de contas ainda usa um caminho de retransmissão aprovado diferente. Um revisor vê um resultado bem-sucedido para uma mensagem da equipe e propõe marcar todo o domínio como concluído. Nenhuma empresa, teste ou resultado real é representado por este cenário.
A revisão pára na incompatibilidade de escopo. A rota da aplicação é adicionada ao inventário, seu envelope e identidades de autor são documentados e sua responsabilidade de assinatura é atribuída. A equipe não adivinha que o aplicativo atravessa a mesma política de gateway. Também evita a substituição SPF por um exemplo de serviço único ou a alteração DMARC apenas para obter um indicador verde. A aceitação permanece pendente até que cada rota dentro do escopo tenha evidências autorizadas adequadas.
Planilha de aceitação de implantação em branco
- Produto Gateway, versão e data da documentação aplicável: ____.
- Proprietário da configuração, proprietário DNS e aprovador da versão: ____.
- Categoria da mensagem e rota aprovada até a saída final: ____.
- Domínios de assinatura esperados de, MAIL FROM e DKIM : ____.
- Associação de política/perfil suportada e exceções não resolvidas: ____.
- Referência do seletor e do registro de verificação pública, excluindo segredos: ____.
- Remetentes SPF existentes, autorização proposta e revisão de dependência: ____.
- Proprietário pretendido DNS , evidências oficiais atuais e tempo de observação: ____.
- Evidência real de mensagem recebida aprovada e avaliação de alinhamento: ____.
- Condições de reversão, discrepâncias não resolvidas e decisão de aprovação: ____.
A planilha não está preenchida e nenhuma etapa operacional foi executada. Evidências originais de implementação, revisão humana, aplicabilidade da fonte atual, rotas de produção, verificações visuais/acessibilidade e liberação do proprietário permanecem em aberto. A aceitação da autenticação ainda não garantiria a entrega, a segurança da mensagem ou a legitimidade de uma solicitação comercial. RFC 9989 , seção 2.4