Política de criptografia ao abrigo do Artigo 21(2)(h)
Cifrar o tráfego não é o mesmo que ter uma política de criptografia. O Artigo 21(2)(h) da NIS 2 pede a política. O §9 do CIR diz o que tem de constar dela: escolhas de algoritmos, robustez de chaves, agilidade criptográfica e um ciclo de vida de gestão de chaves de doze pontos.
A versão curta
A criptografia na NIS 2 não é o controlo técnico. É a política escrita que decide qual a criptografia que usa, onde, e como as chaves são geridas. O Artigo 21(2)(h) é uma linha. O §9 do CIR transforma essa linha num documento real com secções concretas.
A política tem de fazer três coisas. Ligar a robustez da criptografia à classificação dos seus ativos. Nomear os algoritmos, tamanhos de chave e protocolos aprovados, com uma abordagem de agilidade criptográfica para que possam ser substituídos à medida que o estado da arte avança. E cobrir todo o ciclo de vida de gestão de chaves (o CIR nomeia doze passos distintos, da geração à destruição).
A Alemanha passa o mesmo dever para o § 30(2)(8) BSIG. A âncora técnica do BSI é a série TR-02102 (TR-02102-1 para algoritmos e comprimentos de chave, TR-02102-2/-3/-4 para TLS, IPsec, SSH). Esta página percorre a diretiva, o detalhe do CIR e a transposição alemã por essa ordem.
Artigo 21(2)(h) da Diretiva NIS 2 (2022/2555)
Políticas e procedimentos relativos à utilização de criptografia e, quando adequado, de cifragem.
Ponto (h) na lista das dez medidas de cibersegurança que todas as entidades essenciais e importantes têm de implementar. O 'quando adequado' aplica-se à cifragem (a aplicação), não ao facto de ter a política (que é obrigatória).
CIR (UE) 2024/2690, Anexo §9
As entidades relevantes devem estabelecer, implementar e aplicar uma política e procedimentos de criptografia, a fim de assegurar uma utilização adequada e eficaz da criptografia para proteger a confidencialidade, a autenticidade e a integridade dos dados, em consonância com a classificação de ativos e de valor da entidade e os resultados da avaliação de risco.
Por ser um regulamento (e não uma diretiva), é lei da UE diretamente vinculativa para os setores do seu Anexo (DNS, TLDs, cloud, centros de dados, MSPs, serviços de confiança e outros). O §9.2 especifica as três secções que a política deve conter, o §9.3 estabelece um dever de revisão periódica tendo em mente a agilidade criptográfica.
§30(2)(8) BSIG (Alemanha)
Conceitos e procedimentos para a utilização de criptografia e, quando adequado, de cifragem.
A Alemanha copia o texto da UE quase palavra por palavra. A referência técnica do BSI é a TR-02102 (a série que nomeia algoritmos aprovados, comprimentos de chave e configurações de protocolo). O módulo CON.1 (Krypto-Konzept) do IT-Grundschutz dá o padrão de implementação.
Ligar a robustez da criptografia à classificação dos ativos
Para cada classe de dados ou ativo (confidencialidade, autenticidade, integridade, por nível de sensibilidade), a política nomeia o tipo, a robustez e a qualidade das medidas criptográficas usadas. A ligação ao inventário de ativos e à avaliação de risco do §2.1 é explícita. Dados de maior valor recebem criptografia mais forte. A regra tem de ser escrita, não improvisada.
Algoritmos aprovados, robustez de chaves, agilidade criptográfica
A política lista os protocolos, algoritmos, robustez de chaves e procedimentos de gestão de chaves que permite, e exclui os que não permite. O CIR nomeia isto explicitamente como 'uma abordagem de agilidade criptográfica quando adequado': os algoritmos têm de ser substituíveis à medida que o estado da arte avança. Novo algoritmo, novo tamanho de chave, nova versão de protocolo: a política apoia a substituição, não reescritas.
Ciclo de vida de gestão de chaves de doze pontos
O §9.2(c) do CIR nomeia doze passos concretos de gestão de chaves: (i) geração, (ii) emissão de certificados para chaves públicas, (iii) distribuição e ativação, (iv) armazenamento e acesso autorizado, (v) alteração ou atualização, (vi) tratamento de chaves comprometidas, (vii) revogação, (viii) recuperação de chaves perdidas ou danificadas, (ix) cópia de segurança e arquivo, (x) destruição, (xi) registo e auditoria, (xii) datas de ativação e desativação. Todos os doze na política.
A classificação dos ativos determina a profundidade da criptografia (proporcionalidade do Art. 21(1))
Não usa AES-256 com chaves protegidas por HSM para tudo. Ajusta a criptografia ao valor e à exposição do ativo. Base de dados de clientes com dados pessoais, registos financeiros, código-fonte: nível alto. Modelos internos e atas de reunião: nível baixo. O Artigo 21(1) diz que as medidas têm de ser 'adequadas ao risco em causa'. O §9.2(a) do CIR integra essa ligação na política.
Agilidade criptográfica: rever e substituir (§9.3 do CIR)
O §9.3 do CIR diz que revê a política em intervalos planeados e a atualiza 'quando adequado, tendo em conta o estado da arte em criptografia'. Isso é agilidade criptográfica em duas palavras. O SHA-1 era aceitável, depois deixou de o ser. O RSA-1024 era aceitável, depois deixou de o ser. O pós-quântico aproxima-se do RSA e do ECC ao longo da próxima década. A política tem de apoiar a substituição, não apenas descrever o que usa hoje.
BSI / §30(2)(8) BSIG / TR-02102
A Alemanha transpõe o Artigo 21(2)(h) através do § 30(2)(8) BSIG. A âncora técnica é a série TR-02102 do BSI: TR-02102-1 para algoritmos criptográficos e comprimentos de chave, TR-02102-2 para TLS, -3 para IPsec, -4 para SSH. O módulo CON.1 (Krypto-Konzept) do IT-Grundschutz é o bloco de construção que operacionaliza uma política. Os auditores esperam que cite a TR-02102 ou que explique por que razão a sua escolha é pelo menos tão forte.
Orientação Técnica de Implementação da ENISA
A Orientação Técnica de Implementação da ENISA para o CIR cobre o §9 e mapeia-o na ISO/IEC 27001:2022 (A.8.24 Utilização de criptografia), no NIST CSF 2.0, na ETSI EN 319 401 e na CEN/TS 18026. Se já opera ISO 27001, os controlos estão em grande parte presentes. A NIS 2 continua a querer a política estruturada da forma como o §9.2 a lista.
Leis nacionais de transposição
Cada Estado-Membro tem a sua própria transposição (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). O dever é o mesmo porque a diretiva define um padrão único para toda a UE. A referência técnica nacional difere: a ANSSI em França publica o RGS, orientações alinhadas com a ENISA são reutilizadas nos Países Baixos. A estrutura da política não muda.
Temos TLS em todo o lado, por isso está feito.
A cifragem em trânsito é uma fatia da política. O §9.2(c) do CIR quer todo o ciclo de vida de gestão de chaves por escrito: como as chaves são geradas, onde residem, como são rodadas, o que acontece quando uma é comprometida, quem as pode recuperar, quando são destruídas. Se esses doze pontos não estão em papel, a política não está terminada, por muito TLS que tenha implementado.
Usamos aquilo que o nosso fornecedor entrega.
A entidade continua responsável. O § 30 BSIG e o Artigo 21 não transferem o dever para o fornecedor. Se o seu fornecedor de SaaS usa AES-128 e você classificou esses dados como de alta confidencialidade, esse é um problema seu, a corrigir na política ou no contrato. A política tem de nomear o que aceita, não apenas o que apareceu na configuração predefinida.
A gestão de chaves é problema das TI.
A gestão de chaves é governação. A política é aprovada pelo órgão de direção (Art. 20 mais o padrão de aprovação pelo órgão de direção que percorre o Artigo 21). Quando uma chave é comprometida, a resposta corre pelo processo de incidentes ao abrigo do Artigo 23. Quando é concedido acesso a uma chave de alto valor, fica registado. As TI gerem os controlos. A direção é dona da política.
O que vemos no Mittelstand alemão: a cifragem em trânsito está normalmente bem (TLS, VPN, S/MIME ou SMTP-TLS para correio). A cifragem em repouso é irregular mas recuperável. A verdadeira lacuna é a documentação da gestão de chaves. Quem tem as chaves-mestras da VPN? Onde estão as cópias de segurança das chaves de KMS da cloud? O que acontece ao certificado de cifragem de quem sai? A maioria das equipas sabe as respostas. As respostas é que não estão escritas.
Abordagem em dois passos que se aguenta numa auditoria. Primeiro, escreva a política: níveis de ativos, algoritmos aprovados (cite a TR-02102 ou a TIG da ENISA), ciclo de vida de gestão de chaves a cobrir todos os doze pontos do §9.2(c), aprovação pelo órgão de direção. Depois mapeie a política nos sistemas que já opera (KMS de cloud, autoridade de certificação, VPN, correio, cifragem de ficheiros). A maioria dos controlos existe. A lista de verificação do §9.2(c) é o artefacto que os auditores pedem.
Fornecemos um modelo de política de criptografia estruturado segundo o §9.2(a), (b) e (c) do CIR. Parte do modelo, nomeia os seus níveis de ativos, escolhe algoritmos de uma lista alinhada com a TR-02102, e percorre o ciclo de vida de chaves de doze pontos. O resultado é um documento assinado que mapeia diretamente nos subpontos do CIR que um auditor vai referenciar.
O inventário de chaves no módulo CRY lista as chaves por finalidade (TLS, assinatura, cifragem, código), por sistema, por responsável, por data de ativação e desativação. O §9.2(c)(xi) (registo) e o §9.2(c)(xii) (datas de ativação/desativação) tornam-se uma tabela, não um exercício de memória. Reveja a política anualmente. A plataforma agenda a revisão do §9.3 e acompanha a aprovação.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 21(2)(h). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §9. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(8) com a redação dada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Série BSI TR-02102 (Mecanismos Criptográficos: Recomendações e Comprimentos de Chave). bsi.bund.de/dok/tr-02102
- IT-Grundschutz Kompendium, módulo CON.1 (Krypto-Konzept). bsi.bund.de/grundschutz
- Orientação Técnica de Implementação da ENISA para o CIR (UE) 2024/2690, mapeamento para a ISO/IEC 27001:2022 A.8.24