Segunda-feira de manhã em consultórios e farmácias alemãs
Desde segunda-feira, 12 de outubro, muitos consultórios médicos, farmácias e clínicas na Alemanha têm dificuldade em aceder à Telematikinfrastruktur, a rede nacional de saúde, e a Gematik comunica perturbações para os prestadores cujos conectores são da Secunet ou da RISE. Os serviços que falham ou só funcionam em parte são a verificação dos dados do segurado (VSDM), a mensagem segura (KIM), as receitas eletrónicas, o processo clínico eletrónico e as baixas eletrónicas.
Os conectores da CGM não são afetados, diz a Gematik, porque a CGM não usa a função em causa. A causa é a mudança programada da chave raiz de DNS.
A Gematik espera que todos os conectores Secunet e RISE no terreno sejam afetados durante a semana se não houver correção, e as unidades sem conector próprio podem ser atingidas se se ligarem através de um conector de centro de dados. A Gematik ainda não consegue dizer quantos conectores estão afetados.
Um calendário público durante 21 meses
A mudança de chave esteve no calendário público durante 21 meses, e o primeiro dia útil depois trouxe mesmo assim uma falha.
| Data | Acontecimento |
|---|---|
| 11 de janeiro de 2025 | A nova chave raiz KSK-2024 (etiqueta de chave 38696) é publicada no conjunto DNSKEY da raiz |
| 11 de agosto de 2026 | A ICANN publica orientações sobre o que esperar durante a mudança |
| 6 de outubro de 2026 | A Cloudflare avisa que os resolvedores validadores têm de confiar na nova chave |
| 11 de outubro de 2026 | A KSK-2024 começa a assinar o conjunto DNSKEY da raiz e a KSK-2017 (etiqueta 20326) deixa de o fazer |
| 12 de outubro de 2026 | A Gematik comunica perturbações nos conectores Secunet e RISE |
| 13 de outubro de 2026 | A heise atualiza a sua notícia com as respostas da Gematik |
As orientações da ICANN pediam aos operadores de resolvedores validadores de DNSSEC, aos fabricantes de software DNS e a quem tem âncoras de confiança configuradas à mão que confirmassem que os seus sistemas estavam prontos antes de 11 de outubro. A Cloudflare acrescentou que um resolvedor validador que não confie na nova chave pode tornar inacessíveis sites saudáveis, e que a raiz só tinha mudado uma vez antes a sua chave de assinatura de chaves.
Porque sobrevivem os túneis existentes e falham os novos
Aos conectores afetados falta, ao que parece, a nova âncora de confiança raiz da internet, pelo que não conseguem resolver os endereços dos serviços de acesso VPN da Arvato e da T-Systems nem construir um novo túnel para a rede de saúde.
Os túneis que já estão ativos não precisam de novas consultas de nomes, por isso continuam a funcionar. Os registos DNSKEY da raiz também ficam 48 horas em cache, o que esconde a falha até que um reinício ou uma religação encontre a cache vazia ou expirada. É por isso que a heise refere que os operadores afetados não devem reiniciar os conectores.
A Gematik descreve uma solução provisória que o prestador de serviços no local tem de aplicar à mão, e o seu guia para conectores Secunet recomenda juntar a nova âncora de confiança mesmo aos conectores que ainda funcionam. Para a RISE ainda não há um guia à parte, e a RISE anunciou a partir de 8 de outubro o firmware 6.2.3 com o que chamou uma correção importante, embora não se saiba se resolve esta falha. Continua por esclarecer porque é que os conectores não adotaram a chave nova: a especificação exige atualizações automáticas RFC 5011 para a âncora própria da rede de saúde, mas não é claro que a âncora da internet as receba.
O precedente de maio de 2020
No fim de maio de 2020, cerca de 80.000 dos aproximadamente 130.000 consultórios e clínicas ligados não conseguiram aceder a alguns serviços da rede de saúde, e os conectores afetados eram da T-Systems, da RISE e da Secunet.
A Gematik culpou primeiro uma entrada errada na sua lista de estado dos serviços de confiança. A revista c't ligou mais tarde a falha a uma nova âncora de confiança raiz DNSSEC definida em maio de 2020, combinada com um erro de administração. A meio de junho de 2020 a sincronização dos dados mestres continuava perturbada em mais de 40.000 consultórios, e a recuperação exigiu atualizações no local por prestadores de serviços, porque a manutenção remota muitas vezes não estava autorizada.
O que perguntar aos fornecedores antes da próxima mudança de raiz
Comece por todo o dispositivo que constrói túneis VPN ou valida DNS por conta própria, como gateways, conectores médicos e equipamentos embebidos. Peça a cada fornecedor que confirme por escrito como atualiza a sua âncora de confiança, por RFC 5011 ou à mão, e se já tem a KSK-2024.
Teste um reinício ou uma religação numa janela de manutenção só depois dessa confirmação e tenha pronta a solução manual do fornecedor. A Cloudflare oferece um teste de preparação baseado na RFC 8509 para o resolvedor que o seu navegador usa, e diz que a maioria dos operadores de sites não precisa de agir.
Ponha as mudanças de chave raiz e as expirações de certificados no mesmo calendário de alterações das versões de software. Esta falha tinha data, uma chave pública e um guia publicado, e o defeito só apareceu depois de a data passar.
Leia a seguir: Yandex Cloud aconselhou clientes a alojar noutro lado | Três prazos de suporte do Windows em 30 dias
