Poniedziałkowy ranek w niemieckich gabinetach i aptekach
Od poniedziałku 12 października wiele gabinetów lekarskich, aptek i klinik w Niemczech ma kłopoty z dostępem do Telematikinfrastruktur, krajowej sieci zdrowia, a Gematik zgłasza zakłócenia u dostawców, których konektory pochodzą od Secunet lub RISE. Usługi, które nie działają lub działają tylko częściowo, to weryfikacja danych ubezpieczonego (VSDM), bezpieczna wymiana wiadomości (KIM), e-recepty, elektroniczna dokumentacja pacjenta i elektroniczne zwolnienia lekarskie.
Konektory CGM nie są dotknięte, mówi Gematik, bo CGM nie używa danej funkcji. Przyczyną jest zaplanowana zmiana klucza głównego DNS.
Gematik spodziewa się, że w ciągu tygodnia dotknięte będą wszystkie konektory Secunet i RISE w terenie, jeśli nie pojawi się poprawka, a placówki bez własnego konektora mogą zostać trafione, jeśli łączą się przez konektor w centrum danych. Gematik nie umie jeszcze powiedzieć, ile konektorów jest dotkniętych.
Kalendarz, który był publiczny przez 21 miesięcy
Zmiana klucza widniała w publicznym kalendarzu przez 21 miesięcy, a pierwszy dzień roboczy po niej i tak przyniósł awarię.
| Data | Zdarzenie |
|---|---|
| 11 stycznia 2025 | Nowy klucz główny KSK-2024 (tag klucza 38696) zostaje opublikowany w zestawie DNSKEY strefy głównej |
| 11 sierpnia 2026 | ICANN publikuje wskazówki, czego się spodziewać podczas zmiany |
| 6 października 2026 | Cloudflare ostrzega, że walidujące resolvery muszą ufać nowemu kluczowi |
| 11 października 2026 | KSK-2024 zaczyna podpisywać zestaw DNSKEY strefy głównej, a KSK-2017 (tag klucza 20326) przestaje |
| 12 października 2026 | Gematik zgłasza zakłócenia w konektorach Secunet i RISE |
| 13 października 2026 | heise uzupełnia swój tekst o odpowiedzi Gematik |
Wskazówki ICANN prosiły operatorów resolverów walidujących DNSSEC, dostawców oprogramowania DNS i wszystkich z ręcznie skonfigurowanymi kotwicami zaufania o potwierdzenie, że ich systemy są gotowe przed 11 października. Cloudflare dodał, że resolver walidujący, który nie ufa nowemu kluczowi, może sprawić, że zdrowe strony staną się niedostępne, oraz że strefa główna zmieniała wcześniej swój klucz podpisujący klucze tylko raz.
Dlaczego istniejące tunele przetrwały, a nowe zawodzą
Dotkniętym konektorom najwyraźniej brakuje nowej kotwicy zaufania strefy głównej internetu, więc nie potrafią rozwiązać adresów usług dostępu VPN firm Arvato i T-Systems i nie mogą zbudować nowego tunelu do sieci zdrowia.
Tunele, które już działają, nie potrzebują nowych zapytań o nazwy, więc nadal działają. Rekordy DNSKEY strefy głównej zostają ponadto w pamięci podręcznej przez 48 godzin, co ukrywa usterkę, dopóki restart lub ponowne połączenie nie natrafi na pustą albo wygasłą pamięć podręczną. Dlatego heise podaje, że dotknięci operatorzy nie powinni restartować konektorów.
Gematik opisuje rozwiązanie zastępcze, które usługodawca na miejscu musi wprowadzić ręcznie, a jego instrukcja dla konektorów Secunet zaleca dodanie nowej kotwicy zaufania także do konektorów, które jeszcze działają. Dla RISE nie ma jeszcze osobnej instrukcji, a RISE zapowiedział od 8 października firmware 6.2.3 z tym, co nazwał ważną poprawką, choć nie wiadomo, czy usuwa ona tę usterkę. Dlaczego konektory nie przejęły nowego klucza, nadal nie jest jasne: specyfikacja wymaga automatycznych aktualizacji RFC 5011 dla własnej kotwicy sieci zdrowia, ale nie jest pewne, że kotwica internetowa je dostaje.
Precedens z maja 2020
Pod koniec maja 2020 około 80 000 z około 130 000 podłączonych gabinetów i klinik nie mogło dotrzeć do niektórych usług sieci zdrowia, a dotknięte konektory pochodziły od T-Systems, RISE i Secunet.
Gematik najpierw winił błędny wpis na swojej liście statusu usług zaufania. Magazyn c't powiązał później awarię z nową kotwicą zaufania DNSSEC strefy głównej ustawioną w maju 2020, w połączeniu z błędem administracyjnym. W połowie czerwca 2020 synchronizacja danych podstawowych nadal była zakłócona w ponad 40 000 gabinetów, a naprawa wymagała aktualizacji na miejscu przez usługodawców, bo zdalna konserwacja często nie była zatwierdzona.
O co zapytać dostawców przed kolejną zmianą klucza głównego
Zacznij od każdego urządzenia, które buduje tunele VPN lub samo waliduje DNS, jak bramy, konektory medyczne i urządzenia wbudowane. Poproś każdego dostawcę o pisemne potwierdzenie, jak jego kotwica zaufania się aktualizuje, przez RFC 5011 czy ręcznie, i czy zna już KSK-2024.
Przetestuj restart lub ponowne połączenie w oknie serwisowym dopiero po tym potwierdzeniu i miej pod ręką ręczne obejście od dostawcy. Cloudflare oferuje test gotowości oparty na RFC 8509 dla resolvera używanego przez Twoją przeglądarkę i mówi, że większość operatorów stron nie musi nic robić.
Wpisz zmiany klucza głównego i wygasanie certyfikatów do tego samego kalendarza zmian co wydania oprogramowania. Ta awaria miała datę, publiczny klucz i opublikowany poradnik, a usterka ujawniła się dopiero po upływie daty.
Czytaj dalej: Yandex Cloud radził klientom hostować gdzie indziej | Trzy terminy wsparcia Windows w ciągu 30 dni



