A seletor monitor pode informar que os dados de verificação foram alterados ou desapareceram. Ele não pode estabelecer que um serviço ainda está enviando, que sua chave privada corresponde à chave publicada, ou que suas mensagens chegam com mensagens alinhadas. DKIM. Crie verificações separadas para configuração publicada e comportamento de mensagem observado.
Comece com rotas de envio conhecidas
Crie um inventário a partir da configuração do remetente autorizado e das mensagens recebidas pelo representante. Para cada registro de rota, o proprietário da empresa, domínio d, seletor, proprietário DNS , TXT esperado ou CNAME acordo, última hora de assinatura observada e estado do ciclo de vida. Não presuma que adivinhar seletores comuns descubra todos os signatários. DKIM fornece o seletor em cada assinatura, em vez de definir um serviço completo de enumeração DNS .
Para uma assinatura usando s=invoice2 d=brand.example, inspecione invoice2._domainkey.brand.example em RFC 6376 §3.6.2.1. Siga um CNAME esperado para seus dados de verificação. Armazene um carimbo de data/hora de observação e uma impressão digital de chave pública para que uma alteração possa ser comparada com uma rotação aprovada. Nunca colete chaves privadas no sistema de monitoramento.
Separe as descobertas do monitor
Uma resposta ausente, tempo limite DNS , chave revogada e chave alterada são eventos diferentes. RFC 6376 §6.1.2 distingue a falha na consulta de chave de uma chave ausente, e um valor p vazio representa a revogação sob RFC 6376 §3.6.1. Registre os detalhes da resposta em vez de traduzir cada erro em uma interrupção genérica.
Uma chave atual ainda precisa de verificações de sintaxe e algoritmo. RFC 8301 §3.1 proíbe assinatura e verificação rsa-sha1; RFC 8301 §3.2 atualiza requisitos de tamanho RSA: os assinantes devem usar pelo menos 1.024 bits e pelo menos 2.048. O suporte ao produto e a política criptográfica organizacional atual podem ser mais rígidas. Uma alteração de impressão digital por si só não pode dizer se uma rotação foi autorizada.
Adicione um loop de evidências ao vivo
Envie mensagens controladas através de cada rota de produção importante para uma caixa de correio cuja mensagem bruta e resultado de autenticação confiável você possa inspecionar. Registre os d e s observados, o resultado da verificação e alinhamento com De. Exercite as variantes de mensagens que o processamento downstream pode afetar, como HTML e anexos.
Monitor ilustrativo: DNS continua servindo a fatura2, mas uma nova mensagem não contém DKIM-Signature. A verificação de publicação é aprovada enquanto a verificação de assinatura falha. Noutro caso, a assinatura existe, mas a sua hash de corpo falha após uma alteração no rodapé do gateway. Nenhum dos incidentes é resolvido declarando o registro DNS íntegro. Estes são casos de teste sintéticos, não incidentes de serviço medidos.
Os testes sintéticos também têm limites. Uma investigação diária não prova todas as mensagens entre as investigações passadas. Combine-o com relatórios de destinatários e evidências de incidentes, reconhecendo ao mesmo tempo a cobertura e o atraso dos relatórios.
Encaminhar alertas acionáveis
Anexe alertas a uma rota e a um proprietário. Suprima apenas uma janela de manutenção explicitamente aprovada, preserve o histórico de eventos e confirme o novo signatário com novas mensagens após a rotação. Escale alterações importantes inesperadas como possíveis eventos de segurança sem declarar comprometimento apenas por uma alteração.
Retire deliberadamente as linhas de inventário obsoletas. Uma chave pública antiga pode permanecer para verificação de mensagens atrasadas mesmo quando a nova assinatura for interrompida. Distinguir esse estado planejado de uma delegação abandonada. O painel deve informar o que foi observado, quando e por qual método, para que a integridade DNS nunca se disfarce como prova de assinatura ao vivo.
Reproduzir a decisão de alerta
Use quatro sondas sintéticas para manter as camadas de alerta separadas. Uma assinatura com d=brand.example e s=invoice2 é mapeada para invoice2._domainkey.brand.example . Se a sua chave pública estiver presente, mas o resultado do receptor fornecido for uma falha no hash do corpo, emita um alerta de verificação de mensagem. Se a chave estiver ausente, acione um alerta de ausência de chave. Se o registro esperado estiver presente, mas a mensagem não tiver assinatura, gere um alerta de falta de assinatura. Uma chave atual mais um resultado aprovado fornecido não gera nenhum alerta apenas para essa investigação.
Essas quatro decisões são um modelo de decisão ilustrativo com estados DNS inventados e resultados fornecidos pelo receptor. Nenhuma consulta DNS ao vivo, teste de assinatura ou verificação criptográfica foi realizada para esta revisão. Para comissionar o monitor, substitua-os por respostas públicas desatualizadas e mensagens brutas que transportam resultados do seu limite de recepção confiável. Preserve essas evidências vinculadas antes de descrever uma rota como verificada operacionalmente.
Evidências necessárias para a próxima decisão
Para um alerta body-hash, preserve o resultado fornecido e investigue a representação do corpo, configurações de c/l, valor bh e comportamento de implementação; uma incompatibilidade por si só não prova um conteúdo modificado pelo gateway. Marcar uma rota sem sonda recente como não observada, mesmo que sua chave esteja presente. Registre separadamente se o alinhamento foi verificado, pois a passagem DKIM sozinha não é uma passagem alinhada.