A política de criptografia DORA segundo o Artigo 6 do RTS

O Artigo 6 do Regulamento Delegado (UE) 2024/1774 da Comissão, que contém as normas técnicas de regulamentação (RTS) sobre gestão de riscos de TIC no âmbito da DORA, exige que a entidade financeira tenha uma política de criptografia e controles criptográficos, e essa política deve conter disposições para atualizar ou alterar a tecnologia criptográfica com base na evolução da criptoanálise. O texto não cita nenhum algoritmo e não fixa nenhum prazo pós-quântico. A seguir, separamos a exigência literal da nossa visão sobre como redigir o documento e comprovar seu cumprimento. TIC significa tecnologia da informação e comunicação. Este conteúdo é informativo e não constitui aconselhamento jurídico.

O que o Artigo 6 exige literalmente

O RTS é vinculante para as entidades financeiras em seu escopo, e o Artigo 6 é o seu artigo sobre criptografia. Ele pede uma política documentada de criptografia e controles criptográficos, adotada como parte das políticas de segurança de TIC e construída a partir dos resultados da classificação de dados e da avaliação de riscos de TIC. A política trata da proteção dos dados nos estados em que a entidade efetivamente os possui: em repouso, em trânsito e, quando relevante e tecnicamente viável, em uso. Quando a criptografia de dados em uso não for viável, espera-se que a entidade processe os dados em um ambiente protegido ou aplique outras medidas, registrando essa escolha. O artigo remete às melhores práticas e a normas reconhecidas, e não a uma lista fixa de algoritmos. E traz a cláusula mais importante para o trabalho pós-quântico: a política deve incluir disposições para atualizar ou alterar a tecnologia criptográfica à medida que a criptoanálise evolui. O texto oficial está no EUR-Lex, e nosso resumo datado está na página do RTS da DORA. Sempre confira a numeração dos parágrafos no texto consolidado antes de citá-la em uma resposta de auditoria.

O Artigo 7 é a disposição complementar: gestão de chaves criptográficas ao longo de todo o ciclo de vida (geração, renovação, armazenamento, arquivamento, recuperação, destruição) e um registro de certificados e de dispositivos que armazenam certificados, pelo menos para os ativos de TIC que suportam funções críticas ou importantes. Leia os dois artigos em conjunto. A maior parte das evidências que um avaliador solicita com base no Artigo 6 está nos inventários e registros que o Artigo 7 obriga você a manter.

O que o Artigo 6 não diz

Ele não cita o ML-KEM (mecanismo de encapsulamento de chaves baseado em reticulados modulares, padronizado pelo NIST como FIPS 203 em 13/08/2024), não menciona a troca de chaves híbrida e não define nenhuma data de migração. Esses sinais vêm de outros documentos, cada um com seu próprio status. O NIST IR 8547 é um rascunho público inicial (12/11/2024, ainda em rascunho) que propõe descontinuar algoritmos vulneráveis à computação quântica com segurança de 112 bits após 2030 e proibir todos os algoritmos de chave pública vulneráveis à computação quântica após 2035. O Roteiro de Implementação Coordenada da UE v1.1 (publicado em 23/06/2025) é uma orientação coordenada para os Estados-Membros, e não um regulamento vinculante para as empresas: ele estabelece primeiros passos, incluindo um inventário criptográfico e roteiros nacionais até o fim de 2026, a migração dos casos de uso de alto risco até o fim de 2030 e dos de risco médio até o fim de 2035. O Artigo 21(2)(h) da NIS2 exige, separadamente, políticas e procedimentos sobre o uso de criptografia e, quando apropriado, de cifragem. As entidades sujeitas a ambos devem redigir uma única política e mapeá-la duas vezes, em vez de manter dois documentos.

Uma estrutura seção por seção

A estrutura abaixo é a nossa interpretação, e não um modelo publicado por um regulador. Ela foi organizada para que cada seção responda a uma pergunta que um avaliador provavelmente fará, e para que a parte volátil (os algoritmos) fique em um anexo que você possa versionar sem reabrir a política inteira.

1. Finalidade, escopo e governança. Quais entidades, sistemas e terceiros estão abrangidos, quem aprova a política, quem é o responsável por ela, periodicidade de revisão.
2. Definições e papéis. Custodiante de chaves, arquiteto de criptografia, responsável pelo ativo, responsável pelo certificado. Defina cada sigla uma única vez.
3. Vínculo com a classificação de dados. Para cada nível de classificação, a proteção exigida em cada estado dos dados. É isso que torna a política baseada em risco, e não genérica.
4. Algoritmos, tamanhos de chave e protocolos aprovados (Anexo A). Uma tabela versionada com três colunas: preferencial, aceitável, proibido. Cite a norma que fundamenta cada item.
5. Dados em repouso. Discos, bancos de dados, armazenamento de objetos, backups, arquivos, endpoints. Indique o mecanismo e quem verifica a cobertura.
6. Dados em trânsito. Versão mínima de TLS, conjuntos de cifras e grupos de troca de chaves aprovados, tráfego interno serviço a serviço, transferência de arquivos, e-mail, administração remota.
7. Dados em uso. Onde se aplica e, onde não se aplica, o ambiente protegido ou as outras medidas adotadas em substituição, com a justificativa registrada.
8. Chaves e certificados. Remeta ao Artigo 7: regras de ciclo de vida, uso de módulos de segurança de hardware e de serviços de gestão de chaves, períodos de rotação, o registro de certificados e seus alertas de expiração.
9. Inventário criptográfico e fornecedores. Como o inventário é construído e atualizado, e o que você exige dos prestadores terceiros de serviços de TIC.
10. Alteração da tecnologia criptográfica (Anexo B). A cláusula de agilidade, descrita na próxima seção.
11. Exceções e legado. Um registro de exceções por prazo determinado, cada uma com um controle compensatório, um responsável e uma data de término.
12. Evidências e relatórios. Qual artefato comprova qual cláusula, quem o produz e com que frequência.

A disposição de alteração: a agilidade criptográfica por escrito

Uma cláusula que diz que a entidade acompanhará a evolução criptográfica não é evidência. Uma cláusula que um avaliador consegue testar indica o gatilho, o responsável, o inventário sobre o qual atua e o tempo necessário para agir. Cinco elementos bastam.

• Fontes de gatilho. Documentos e fontes nomeados que você acompanha: normas e rascunhos do NIST, a TR-02102-1 do BSI (uma diretriz técnica cuja versão de 01/2026 recomenda o acordo de chaves pós-quântico híbrido e recomenda o acordo de chaves clássico isolado apenas até o fim de 2031, ou até o fim de 2030 para necessidades de proteção muito elevadas), publicações da ANSSI (suas recomendações pós-quânticas ainda não são obrigações regulatórias fora do seu escopo regulado), avisos de fim de suporte de fornecedores e resultados criptoanalíticos publicados.
• Um responsável pela decisão. Um único papel com autoridade para alterar o Anexo A, um comitê que aprova a alteração e um registro com a data, a justificativa e o documento de origem.
• Um inventário com responsáveis. Não é possível alterar o que não se consegue listar. Uma lista de materiais criptográficos (CBOM) é uma forma prática de produzir esse inventário, e essa é a nossa interpretação, não uma exigência do texto.
• Classes de ativos com datas-alvo. Agrupe os ativos por exposição e pelo tempo durante o qual seus dados precisam permanecer confidenciais, e então atribua uma data-alvo a cada grupo, em vez de uma única data para todo o parque.
• Uma regra de implantação segura. Novos algoritmos são habilitados em paralelo a uma alternativa clássica, testados em homologação e só então promovidos.

Por que começar pela troca de chaves: o tráfego gravado é protegido apenas pela troca de chaves que estabeleceu a sessão, portanto o tráfego capturado hoje pode ser decifrado mais tarde se essa troca for vulnerável à computação quântica. Assinaturas e certificados podem migrar depois, porque uma assinatura verificada hoje não se torna falsificável retroativamente. Essa é a razão objetiva pela qual a troca de chaves híbrida, por exemplo X25519MLKEM768 (codepoint IANA 0x11EC), é o primeiro passo concreto para uma entidade financeira. Os grupos Kyber pré-padrão, como X25519Kyber768Draft00 (0x6399), estão obsoletos e devem constar como proibidos no Anexo A. O OpenSSL 3.5 ou posterior é necessário para os grupos ML-KEM no OpenSSL.

Section 10. Changing cryptographic technology

10.1 Annex A (approved algorithms) is reviewed at least every 12 months and on any
     of these triggers: a new or withdrawn standard, an update to a national
     technical guideline we track, a published cryptanalytic result, a supplier
     end-of-support notice, or a change in the classification of data we protect.
10.2 The CISO owns Annex A. Changes are approved by the ICT risk committee and
     recorded with a date, a rationale and the source document.
10.3 Each asset class in Annex B has a named owner and a target date for migration
     to the algorithms marked preferred in Annex A.
10.4 Where an asset cannot meet its target date, the owner records a time-limited
     exception with a compensating control and an end date.
10.5 A new algorithm is deployed with a classical fallback, validated in staging,
     and promoted only after a documented interoperability test.

Da exigência à evidência

A coluna da esquerda parafraseia a exigência. A coluna do meio é a nossa interpretação das evidências que a atendem, e não uma lista publicada por qualquer autoridade.

Verifique a afirmação sobre dados em trânsito antes do avaliador

As declarações da política sobre dados em trânsito são as mais fáceis de verificar e as mais fáceis de errar, porque um balanceador de carga, uma rede de distribuição de conteúdo ou um host virtual legado pode contradizer silenciosamente a baseline. Comece por uma verificação somente leitura, com OpenSSL 3.5 ou posterior:

openssl s_client -connect www.example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"

Execute-a em todos os hostnames públicos do seu registro, não apenas no site principal. Se o seu ambiente também estiver no escopo do PCI DSS, o mesmo inventário alimenta o requisito 12.3.3, obrigatório desde 31/03/2025, que exige conjuntos de cifras e protocolos documentados e revisados pelo menos a cada 12 meses, conforme descrito em nossa nota sobre o inventário criptográfico do PCI DSS. Um inventário, dois mapeamentos.

Quatro armadilhas

• Escrever prazos na política como se o RTS os tivesse fixado. Cite cronogramas externos como gatilhos de revisão e explique seu status, já que orientações e rascunhos não são obrigações.
• Uma política sem inventário por trás. A disposição de alteração é inverificável sem uma lista dos ativos, de sua criptografia e de seus responsáveis.
• Tratar uma varredura externa como atestado. Uma varredura descreve a configuração visível externamente de um determinado endpoint em um determinado momento. Ela não é uma certificação nem um atestado de conformidade.
• Congelar a lista de algoritmos no corpo da política. Mantenha-a em um anexo com número de versão próprio, para que uma mudança na criptoanálise não exija um ciclo completo de aprovação da política.

Próximo passo

Comece pelas evidências que você pode reunir hoje: liste seus endpoints públicos, registre qual troca de chaves cada um negocia e anexe esse resultado à seção de dados em trânsito da sua política. Você pode analisar seu domínio com o PQC Status gratuitamente para ver as versões de TLS, os conjuntos de cifras, o suporte a ML-KEM híbrido e a cadeia de certificados que um observador externo vê, e depois usar as lacunas encontradas para definir datas-alvo por classe de ativos no Anexo B. Repita a análise após cada alteração, para que o log de gatilhos tenha evidências datadas do antes e do depois.