A plataforma de marketing de um banco pode passar DMARC consistentemente enquanto um pequeno serviço de código de autenticação falha. A porcentagem agregada oculta a incapacidade do cliente de fazer login. Faça um inventário das notificações críticas por finalidade e consequência operacional antes de usar a integridade geral do correio para avaliar a prontidão.
Distinguir três promessas de serviço
Uma mensagem de código de autenticação tem um ciclo de vida de expiração e nova tentativa controlado pelo serviço de identidade. Um alerta de fraude pode precisar de atenção oportuna por meio de um fluxo de trabalho de contato aprovado. Um aviso de conta pode ser menos imediato, mas ainda assim conter informações importantes. Para cada um, documente o gatilho, o proprietário do aplicativo, o momento esperado, o caminho de acesso alternativo e a equipe de escalonamento.
Não transforme esse inventário em um endosso de e-mail como fator de autenticação para uma determinada transação bancária. A adequação dos códigos de e-mail depende do projeto de segurança aprovado pela instituição e dos requisitos aplicáveis. DMARC protege uma avaliação de identidade de domínio; não pode tornar aceitável um processo de recuperação fraco ou uma escolha de factores inseguros.
Inspecione a rota que realmente emite o código
Registre o domínio De, identidade do envelope, DKIM signatário, seletor, locatário do aplicativo e ambiente para o serviço de identidade. Verifique se as configurações de teste, preparação e produção estão claramente separadas. Um teste bem-sucedido por meio de uma caixa de correio de desenvolvedor não diz nada sobre o trabalhador de notificação de produção se ele usar outro provedor.
Para alertas de fraude, registre o remetente que cria o alerta e o canal pelo qual os clientes devem verificá-lo de forma independente. Evite ensinar os clientes a confiar em uma mensagem apenas porque ela parece ser de marca ou autenticada. Os avisos de conta podem usar um processador em lote com comportamento diferente de assinatura e nova tentativa; inclua-o explicitamente em vez de herdar o resultado do serviço de código.
Meça a latência sem reivindicar mais do que os relógios mostram
Capture o tempo de disparo, o tempo de envio do provedor, a aceitação remota quando disponível e o tempo de observação da caixa de correio controlada. Registre fusos horários e incerteza do relógio. Compare estas etapas com as metas de serviço aprovadas pela própria instituição; nenhum limite de tempo de entrega universal é fornecido aqui. Os intervalos de relatórios agregados não podem medir o tempo de chegada de um código específico.
Use códigos sintéticos que não podem ser autenticados em nenhuma conta real. Nunca colete códigos utilizáveis em capturas de tela ou diagnósticos amplamente acessíveis. Teste o comportamento de códigos expirados, entregas atrasadas e solicitações repetidas em um ambiente de não produção aprovado. Um código atrasado pode ser autenticado perfeitamente na camada de e-mail e falhar corretamente na camada de aplicativo porque expirou.
Atribuir recuperação antes de endurecer a política
O proprietário da identidade deve definir como um usuário recupera o acesso quando o email falha, enquanto as operações fraudulentas devem definir como os clientes podem verificar alertas por meio de um caminho confiável. A equipe de correio diagnostica a identidade do remetente e as evidências do destinatário. Evite a supressão automática de uma notificação crítica de segurança simplesmente para melhorar a porcentagem de autenticação.
Exija um teste representativo para cada rota crítica e um proprietário nomeado para qualquer lacuna. No mapa local abaixo, o signatário do aviso de conta está desalinhado, enquanto o código e os signatários de fraude correspondem exatamente. Este é um contraste de treinamento, não uma medida bancária. Verifique novamente após failover do provedor, alterações na plataforma de identidade, rotação do seletor e alterações no tempo de vida do código ou no comportamento de nova tentativa. Separe a autoridade de reversão documentada da capacidade técnica de alterar DNS .
Trabalhe através de três registros de rota escritos
Esses exemplos de domínios reservados, seletores, funções e premissas DKIM de passagem são fictícios. Nenhuma mensagem assinada, chave, verificação criptográfica, pesquisa DNS , transação SMTP ou teste de serviço ao vivo é fornecida ou executada para esses casos. Nenhum código de teste ou amostra externa é necessário para inspecionar o raciocínio abaixo.
- código de autenticação: visível do domínio codes.bank.example ; DKIM d=codes.bank.example; seletor demo1; assuma a aprovação DKIM apenas para este caso escrito. SPF CORREIO DE identidade e resultado desconhecido; outras assinaturas desconhecidas; descoberta e entrega de políticas reais desconhecidas. Proprietário proposto: Proprietário do serviço de identidade. Próxima ação: Obtenha uma amostra autorizada e um resultado de receptor confiável para esse locatário exato.
- alerta de fraude: visível do domínio fraud.bank.example ; DKIM d=fraud.bank.example; seletor demo2; assuma a aprovação DKIM apenas para este caso escrito. SPF MAIL FROM identidade e resultado desconhecido; outras assinaturas desconhecidas; descoberta e entrega de políticas reais desconhecidas. Proprietário proposto: Proprietário de operações fraudulentas. Próxima ação: Confirme esta rota separada e seu evento de negócios em vez de herdar o resultado da primeira rota.
- aviso de conta: visível no domínio accounts.bank.example ; DKIM d=provider.example.net; seletor demo3; assuma a aprovação DKIM apenas para este caso escrito. SPF MAIL FROM identidade e resultado desconhecido; outras assinaturas desconhecidas; descoberta e entrega de políticas reais desconhecidas. Proprietário proposto: proprietário dos serviços da conta. Próxima ação: Solicite ao fornecedor verificado o caminho de assinatura alinhado com suporte deste locatário; não amplie a autorização para toda a sua rede.
Para as duas primeiras assinaturas estipuladas, d= é exatamente igual ao domínio From, de modo que o identificador satisfaz tanto o estrito quanto o relaxado. alinhamento. Dado o resultado DKIM bem-sucedido estipulado, existe um caminho de autenticação alinhado para essas mensagens hipotéticas. O terceiro signatário não está deliberadamente relacionado ao domínio do autor e não pode fornecer esse caminho alinhado. Não chame a terceira mensagem de falha DMARC : SPF alinhado ou outra passagem alinhada Assinatura DKIM ainda poderia satisfazer o mecanismo, e essas entradas são desconhecidas. Não infira a implantação real ou o posicionamento da caixa de entrada de nenhuma linha.
Uma assinatura criptográfica autentica a responsabilidade de um domínio de assinatura, não a veracidade ou autorização de cada instrução. Alterações nos bytes canônicos cobertos podem invalidar uma assinatura; nem toda edição visível altera necessariamente a entrada assinada. A autenticação e a aceitação no nível do aplicativo permanecem separadas.
Leia um cronograma de expiração hipotético
Para o caso não funcional OTP-01, assuma relógios sincronizados: acionamento 10:00:00 GST, envio do provedor 10:00:01 , aceitação SMTP remota 10:00:03 , expiração do aplicativo aprovado 10:01:00 e observação da caixa de correio controlada 10:01:10 . Esta chegada inventada ocorre 70 segundos após o acionamento e 10 segundos após a expiração presumida. Mesmo uma passagem DKIM alinhada estipulada não pode estender a vida útil do código. O proprietário da identidade investiga a latência e o caminho de recuperação aprovado; a aplicação deve aplicar suas regras de validade configuradas. A aceitação remota não é observação de caixa de correio ou leitura humana. Nenhuma latência operacional, validade de código ou acesso do cliente foi medida. Os registros reais precisam de compensações de relógio e incerteza antes de comparar os estágios.
Aplicar os padrões sem reivindicar conformidade
RFC 9989 Seções 4.4 e 5.3.5 apoiar o alinhamento e a distinção do mecanismo. Sua Seção 7.4 alerta sobre a interoperabilidade de correio indireto: domínios que usam p=reject deve usar DKIM válido, não apenas SPF , e o uso de listas de discussão de uso geral precisa de cuidados especiais. Um inventário de rotas não é em si uma permissão para impor a rejeição. RFC 6376 Seções 3.4–3.7 e 6.1 descrever entradas assinadas e verificação. RFC 9990 Seção 3.1 fornece contexto de relatório, não prova de chegada por destinatário. RFC 5321 Seção 4.2.5 distingue a responsabilidade de aceitação do servidor dos resultados de entrega posteriores. As opções de fluxo de trabalho do setor aqui são recomendações editoriais; o âmbito legal, a adequação dos factores e a autorização local necessitam da sua própria análise responsável.