DORA Artigo 7: gestão de chaves e o registro de certificados

O Artigo 7 do Regulamento Delegado (EU) 2024/1774 da Comissão, que estabelece as normas técnicas de regulamentação (RTS) do DORA sobre gestão de riscos de TIC, exige duas coisas: gestão de chaves criptográficas ao longo de todo o ciclo de vida das chaves e um registro de certificados dos ativos de TIC que suportam funções críticas ou importantes. O registro é um artefato de conformidade, mas também é a lista operacional de que você vai precisar no dia em que migrar a troca de chaves e as assinaturas para algoritmos pós-quânticos. Este guia apresenta os campos a registrar, os comandos somente leitura que descobrem certificados e a forma como o registro se conecta ao inventário criptográfico mais amplo exigido pelo Artigo 6 do DORA. Trata-se de informação, não de aconselhamento jurídico.

O que o Artigo 7 pede, literalmente

O texto das RTS é curto e específico. As entidades financeiras devem ter políticas e procedimentos de gestão de chaves criptográficas que abranjam geração, renovação, armazenamento, backup, arquivamento, recuperação, transmissão, desativação, revogação e destruição de chaves. Separadamente, devem manter um registro dos certificados e dos dispositivos que armazenam certificados para os ativos de TIC que suportam funções críticas ou importantes, e gerenciar a renovação dos certificados para que a expiração não interrompa essas funções. O texto oficial está no EUR-Lex: Regulamento Delegado (EU) 2024/1774 da Comissão.

Três consequências decorrem diretamente dessa redação, antes de qualquer interpretação.

• O escopo é definido pelas funções, não pela infraestrutura. O critério é o suporte a uma função crítica ou importante, portanto o registro segue a sua própria classificação de funções, e não um perímetro de rede.
• Os dispositivos estão no escopo, não apenas os arquivos. Dispositivos que armazenam certificados incluem módulos de segurança de hardware (HSMs), smartcards, trusted platform modules e keystores de appliances, então inventarie o suporte tanto quanto a credencial.
• A renovação é um controle de disponibilidade. Um certificado expirado em um gateway de pagamento é um incidente de TIC, e é por isso que o Artigo 7 associa o registro à gestão de renovações.

O que o Artigo 7 não diz é igualmente importante. Ele não menciona algoritmos pós-quânticos, não fixa uma data de migração e não exige um formato de arquivo específico. É o Artigo 6 que exige disposições para atualizar ou alterar a tecnologia criptográfica conforme a evolução da criptoanálise, e é ali que entra a agilidade criptográfica. Nossa leitura, apresentada como interpretação: um registro que documenta o algoritmo e o tamanho de chave de cada certificado transforma o Artigo 6 de uma intenção escrita em algo executável, porque você consegue listar em minutos todos os ativos que ainda dependem de assinaturas RSA ou ECDSA.

Campos a registrar para cada certificado

Mantenha o registro legível por máquina (uma linha por certificado, exportada das suas fontes em vez de digitada à mão). As colunas abaixo cobrem as obrigações do Artigo 7 e trazem os dados de que uma migração pós-quântica precisa.

Dois campos compensam o esforço de incluí-los, mesmo que nenhum texto os exija: a superfície de implantação (qual balanceador de carga, ingress, broker ou par de TLS mútuo apresenta o certificado) e um indicador de prontidão pós-quântica por ativo, definido a partir de medição e não de intenção.

Ciclo de vida das chaves: o que documentar sobre as chaves, não sobre os certificados

Um certificado é um objeto público com data de expiração. A obrigação de ciclo de vida das chaves abrange material que você nunca deve exportar, então o registro documenta fatos sobre a chave, e não a chave em si. Para cada chave, ou para cada classe de chaves quando houver milhares, registre: método de geração e fonte de entropia, algoritmo e parâmetros aprovados, limite de armazenamento (software, HSM, keystore na nuvem com seu nível de proteção), quem detém direitos de administração e de recuperação, arranjos de backup e custódia, duração de arquivamento das chaves que ainda precisam verificar assinaturas antigas, critérios de desativação, procedimento de destruição e respectiva evidência, e o playbook de comprometimento com seu responsável pela decisão.

Separe três categorias, porque os caminhos de migração são diferentes. As chaves de acordo de chaves protegem a confidencialidade em trânsito, e o tráfego gravado pode ser decifrado mais tarde se o acordo de chaves for quebrado, razão pela qual o harvest now, decrypt later faz da troca de chaves a primeira coisa a migrar. As chaves de assinatura autenticam, e uma assinatura forjada em 2035 não consegue quebrar retroativamente uma sessão de hoje, então os certificados podem migrar depois da troca de chaves. As chaves de assinatura de longa duração são a exceção: chaves de assinatura de firmware e de software que precisam continuar confiáveis por uma década merecem atenção agora, e o NIST padronizou assinaturas baseadas em hash com estado exatamente para esse caso na SP 800-208 (LMS e XMSS, consulte a SP 800-208).

Descoberta: como alimentar o registro

Nenhuma fonte única contém todos os certificados. Combine pelo menos quatro e trate cada uma como parcial.

1. Consulte as autoridades certificadoras

Os bancos de dados das ACs internas e as suas contas em ACs públicas listam tudo o que emitiram. A emissão pública também fica visível nos logs de Certificate Transparency, que são a forma mais rápida de encontrar certificados emitidos para os seus domínios por equipes cuja existência você desconhecia.

2. Varra o que está de fato escutando

Verificações somente leitura em um host mostram o certificado em produção, que às vezes não é o certificado que você acha que implantou. Teste primeiro em um ambiente que não seja de produção e confirme a sua autorização de varredura.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Percorra os sistemas de arquivos e os keystores

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Consulte as plataformas que gerenciam certificados por você

Secrets do Kubernetes e recursos do cert-manager, gerenciadores de certificados na nuvem, cofres de chaves na nuvem e partições de HSM, service meshes que emitem certificados de TLS mútuo de curta duração, gateways de API, brokers de mensagens, configuração TLS de bancos de dados, concentradores de VPN e serviços de assinatura de código. Os certificados de curta duração de service mesh costumam ser mais bem registrados como uma linha de política (emissor, algoritmo, duração, mecanismo de rotação) do que como milhões de linhas individuais; indique isso explicitamente no registro para que um revisor veja que a escolha foi deliberada.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

No primeiro dia, a automação importa mais do que a completude. As instruções federais dos EUA no âmbito do OMB M-26-15 pedem um inventário criptográfico automatizado e atualizado continuamente, e esse princípio se aplica bem em outros contextos: um registro atualizado por uma tarefa agendada sobrevive, uma planilha atualizada por boa vontade não.

Vinculando o registro ao inventário criptográfico

O registro de certificados é uma camada de um inventário maior. Mantenha-os vinculados em vez de fundidos: o registro de certificados responde quais credenciais existem e quando expiram, enquanto o inventário criptográfico responde quais algoritmos o seu software e os seus protocolos realmente usam, incluindo acordo de chaves, criptografia simétrica em repouso, hashing e bibliotecas. Uma lista de materiais de criptografia (CBOM) é uma forma prática de expressar a camada de software, conforme descrito em o que é um CBOM; essa é a nossa interpretação de boas práticas, não um requisito do DORA.

Os mesmos artefatos atendem a vários frameworks, o que justifica construí-los uma única vez.

Quanto às datas, mantenha as distinções precisas. O requisito 12.3.3 do PCI DSS v4.0.1 é obrigatório desde 31 de março de 2025. O Roteiro de Implementação Coordenada da UE v1.1, publicado em 23 de junho de 2025, é uma orientação coordenada para os Estados-Membros e não um regulamento vinculante para as empresas: ele situa os inventários criptográficos e os roteiros nacionais até o final de 2026, a migração dos casos de uso de alto risco até o final de 2030 e a dos de risco médio até o final de 2035. O NIST IR 8547 continua sendo um rascunho público inicial; ele propõe descontinuar algoritmos vulneráveis à computação quântica com segurança de 112 bits após 2030 e proibir algoritmos de chave pública vulneráveis à computação quântica após 2035, e deve ser citado como rascunho. O conjunto completo de marcos datados está na nossa central de regulamentações.

Armadilhas comuns

• Registrar apenas os certificados web públicos. O TLS mútuo entre serviços internos, clientes de banco de dados, brokers de mensagens, assinatura de código e identidade de dispositivos costuma superar em número os certificados públicos.
• Omitir a localização da chave privada. Sem ela, você não consegue responder à única pergunta que importa durante um comprometimento: onde está a chave e quem pode acessá-la.
• Tratar a expiração como o único evento do ciclo de vida. Uma revogação que nunca foi exercitada é um controle não testado.
• Deixar o escopo mudar silenciosamente. Quando uma função é reclassificada como crítica ou importante, seus certificados entram no escopo. Execute novamente a regra de escopo de forma agendada e guarde o resultado datado.
• Confundir a migração de certificados com a migração da troca de chaves. O acordo de chaves híbrido protege o tráfego gravado hoje e já pode ser implantado; os certificados pós-quânticos dependem do suporte das ACs e dos clientes. Comece pela troca de chaves, conforme explicado em agilidade criptográfica.
• Manter algoritmos pré-padronização obsoletos. Os grupos TLS do rascunho Kyber foram substituídos pelos grupos ML-KEM padronizados; o grupo híbrido a procurar é o X25519MLKEM768.

Próximo passo: meça antes de documentar

Um registro construído a partir de intenções envelhece mal, então preencha as colunas de algoritmo e de prontidão a partir de medições. Para cada ativo acessível externamente que suporta uma função crítica ou importante, analise seu domínio com o PQC Status para ler as versões de TLS negociadas, os grupos de acordo de chaves oferecidos, as cipher suites e a cadeia de certificados, e depois cole esses valores diretamente no registro. A análise descreve apenas a configuração TLS visível externamente: ela não é uma certificação nem um atestado de conformidade, e a nossa página de metodologia explica exatamente o que ela prova e o que não prova. Depois de registrar a superfície externa, repita os comandos de descoberta acima nos listeners internos, atribua um responsável a cada linha e agende a exportação para que o registro se atualize sozinho.