A DKIM a chave privada é a autoridade para criar assinaturas que podem ser verificadas no registro público correspondente. Proteger apenas o registro DNS não protege essa autoridade. Faça um inventário dos sistemas de assinatura, das contas que podem usá-los e de todas as cópias operacionais do segredo antes de decidir se a chave é controlada.
Identifique a custódia em vez de assumi-la
Comece com o provedor real ou software de assinatura. Um serviço gerenciado pode gerar e reter chaves; um assinante auto-operado pode ler um arquivo, armazenamento secreto ou interface suportada por hardware. Esses modelos possuem diferentes controles de acesso e recuperação. Não prometa proteção de hardware, não exportabilidade ou rotação gerenciada pelo cliente, a menos que o produto escolhido documente e implemente isso.
RFC 6376 §8.3 explica a consequência do comprometimento da chave privada: um intruso pode criar mensagens assinadas pelo domínio que publica a chave pública correspondente. Ele também descreve o valor de um servidor de e-mail de saída controlado que autentica os remetentes e aplica controles de envio. As etapas específicas de armazenamento e revisão abaixo são recomendações operacionais, e não requisitos universais do protocolo DKIM .
Construa um mapa de custódia que exponha cópias ocultas
Para cada seletor, registre o domínio de assinatura, o proprietário do serviço, o custodiante da chave, os nós de assinatura ativos, o caminho de implantação e o mecanismo de recuperação compatível. Rastreie a referência ou o identificador do segredo, não o segredo em si. Revise repositórios de configuração, etapas de construção de contêineres, arquivos de implantação temporários, backups e pacotes de diagnóstico para cópias não intencionais por meio do processo de tratamento de segredos aprovado pela organização.
Um exemplo sintético é um cluster de faturação com dois nós de assinatura e um trabalho de implantação. A chave DNS é pública e esperada. A chave privada destina-se a alcançar apenas os dois nós, mas um pipeline de construção antigo também a incorpora em uma imagem acessível a projetos não relacionados. Proteger as permissões atuais do arquivo do nó não removeria a exposição mais antiga. Investigue o caminho de distribuição e trate um segredo potencialmente exposto de acordo com o processo do incidente.
Nunca cole uma chave privada em um campo DNS público, ticket, chat ou verificador DKIM público. Quando o apoio precisar de evidências, forneça ao selecionador público informações e resultados de diagnóstico adequadamente controlados. As mensagens brutas também podem conter conteúdo confidencial; minimize o que é compartilhado e use canais aprovados.
Reduza quem pode assinar e quem pode recuperar segredos
Use os controles de privilégio mínimo suportados pela plataforma para administração e acesso em tempo de execução. Uma conta que pode solicitar assinaturas pode ser poderosa mesmo que não consiga exportar a chave. Revise quem pode alterar identidades de envio permitidas, enviar e-mails, alternar chaves, implantar configurações de signatários e recuperar backups.
Serviços separados com diferentes proprietários ou níveis de confiança onde a arquitetura suporta chaves e seletores independentes. Copiar uma chave em cada aplicativo torna o escopo de um incidente mais difícil e a desativação mais perturbadora. A alta disponibilidade pode exigir legitimamente uma identidade de assinatura compartilhada, mas isso deve ser um projeto explícito com distribuição controlada, em vez de uma consequência acidental de um arquivo de configuração copiado.
Teste a recuperação sem distribuir o segredo
Pergunte se uma interrupção é recuperada restaurando uma chave protegida, gerando uma substituição ou usando o caminho de recuperação gerenciado do provedor. Teste o procedimento suportado em um ambiente controlado. Registre o tempo de recuperação, as dependências DNS e se o e-mail na fila ainda usa o seletor antigo. Não crie cópias de backup desprotegidas adicionais apenas para facilitar o detalhamento.
Revise os logs e acesse os eventos disponíveis na plataforma de assinatura e no sistema de gerenciamento de segredos. A questão útil é se uma alteração ou utilização não autorizada pode ser detectada e investigada, e não se existe um painel específico. Documente as lacunas de registro em vez de inventar uma trilha de auditoria.
Termine com um registro de ciclo de vida acionável
Mantenha o mapa de custódia ao lado dos procedimentos de rotação e compromisso. Remova o acesso obsoleto quando funcionários ou fornecedores saírem e verifique novamente a distribuição após alterações na infraestrutura. Durante uma suspeita de exposição, coordene a contenção do acesso, uma substituição limpa e as consequências da verificação da retirada da chave antiga. Um arquivo atual protegido é apenas uma parte de um ciclo de vida de assinatura controlada.
Use uma planilha de decisão de custódia
Para cada identidade de assinatura, registre estes campos não secretos:
- Uso: quais contas de serviço podem enviar ou solicitar assinaturas e quais identidades elas podem usar.
- Recuperação: quais funções podem exportar ou restaurar a chave privada e onde residem as cópias aprovadas.
- Mudança: quem pode alterar a configuração do signatário, as identidades permitidas ou os artefatos de implantação.
- Recuperação: se o caminho suportado restaura uma chave protegida ou gera uma substituição, com dependências DNS e correio enfileirado.
- Evidência: registros de acesso/assinatura disponíveis, quaisquer lacunas de cobertura e o proprietário responsável pela revisão.
Se um artefato de construção antigo contiver uma chave exposta, proteger apenas o nó ativo será insuficiente: analise a exposição antiga e decida pela substituição limpa de acordo com os procedimentos de incidente. Esta planilha é uma orientação editorial de segurança e não uma afirmação de que uma plataforma específica fornece esses controles.
Leitura relacionada
Revogar uma chave DKIM e distinguir a revogação de um registro DNS ausente · Comprimento da chave DKIM e algoritmos: verifique o suporte atual do receptor.