14.5. Prowadzenie e-dokumentacji i ochrona danych osobowych (RODO): Szyfrowanie, kopie zapasowe i logowanie zdarzeń (audit trail)

3. Szyfrowanie, kopie zapasowe i logowanie zdarzeń (audit trail)

Cel i priorytety

Celem tego rozdziału jest opisanie praktycznych zasad zapewniających poufność, integralność i dostępność elektronicznej dokumentacji medycznej poprzez: 1) bezpieczne szyfrowanie danych w tranzycie i w spoczynku, 2) spójne i bezpieczne mechanizmy tworzenia oraz przechowywania kopii zapasowych, 3) wiarygodne i nieusuwalne logowanie zdarzeń (audit trail) umożliwiające śledzenie dostępu i działań na danych. Wszystkie rozwiązania muszą być zgodne z RODO i lokalnymi regulacjami medycznymi, a jednocześnie możliwe do praktycznego wykonania w warunkach gabinetu lub małej sieci placówek.

1. Szyfrowanie — zasady ogólne

Szyfrowanie musi obejmować dwie sfery:
- transmisję danych (dane „w tranzycie”) — zabezpieczenie kanałów komunikacji pomiędzy przeglądarką/klientem a serwerem oraz pomiędzy serwerami;
- przechowywanie danych (dane „w spoczynku”) — szyfrowanie baz danych, systemów plików, kopii zapasowych i nośników przenośnych.
Stosować wyłącznie zweryfikowane, współczesne protokoły i biblioteki kryptograficzne. Unikać własnych implementacji szyfrowania. W praktyce oznacza to korzystanie z aktualnych wersji TLS dla połączeń oraz sprawdzonych bibliotek dla szyfrowania na serwerze.
Separacja ról: szyfrowanie danych i zarządzanie kluczami muszą być rozdzielone operacyjnie — osoby administrujące serwerami nie powinny mieć pełnego dostępu do kluczy szyfrujących.

2. Szyfrowanie podczas transmisji (TLS)

Wymusić szyfrowanie wszystkich kanałów komunikacji (HTTPS/TLS) — nie dopuszczać transmisji nieszyfrowanej ani protokołów zastępczych.
Certyfikaty powinny pochodzić z zaufanego urzędu certyfikacji; stosować automatyczne odnawianie certyfikatów (np. ACME) i monitorować daty wygaśnięć.
Konfiguracja protokołu: wyłączyć stare wersje protokołów i słabe szyfry; stosować najnowsze bezpieczne zestawy kryptograficzne (konfiguracja serwera zgodna z praktykami branżowymi).
Dodatkowe zabezpieczenia: HSTS, ochrona przed downgrade, wymuszony TLS dla API i wewnętrznych usług.

3. Szyfrowanie danych w spoczynku

Szyfrowanie na poziomie dysku — umożliwia ochronę w przypadku fizycznego wyjęcia nośnika; używać szyfrowania warstwy blokowej (pełny dysk) na serwerach i stacjach roboczych z hasłami/kluczami zarządzanymi centralnie.
Szyfrowanie na poziomie aplikacji lub bazy danych — tam, gdzie wymagane jest dodatkowe zabezpieczenie pól wrażliwych (np. zdjęcia intymne, szczegóły medyczne). Szyfrowanie pól aplikacyjnych umożliwia kontrolę dostępu na poziomie biznesowym.
Zarządzanie kluczami — klucze symetryczne powinny być przechowywane w bezpiecznym magazynie kluczy (KMS) lub HSM; dostęp do nich powinien być audytowany i ograniczony. Dobre praktyki to rotacja kluczy w ustalonych interwałach i wersjonowanie.
Separacja kluczy — klucz użytkownika (symetryczny) szyfruje plik; klucz główny (master key) szyfruje klucz użytkownika — upraszcza rotację i ogranicza ekspozycję danych.

4. Kopie zapasowe — zasady bezpieczeństwa i integralności

Zasada 3-2-1: co najmniej trzy kopie danych, na dwóch różnych nośnikach, jedna poza siedzibą (off-site). To minimalne paradygmaty zabezpieczenia przed utratą.
Szyfrowanie kopii zapasowych: kopie muszą być szyfrowane przy tworzeniu i podczas transportu. Klucze szyfrujące kopii powinny być inne niż klucze produkcyjne i przechowywane w KMS/HSM.
Oddzielenie kopii: kopie offline (air-gapped) lub w trybie tylko-do-odczytu (WORM) zabezpieczają przed złośliwym usunięciem/zaszyfrowaniem przez ransomware.
Wersjonowanie i retencja: polityka wersjonowania (ile wersji, jak długo) zależna od wymagań prawnych i klinicznych. Przykład: wersje codzienne przez 30 dni, tygodniowe przez 6 miesięcy, roczne przez 5 lat (dostosować do lokalnych wymogów medycznych).
Testy odtwarzania: regularne, dokumentowane testy przywracania (co najmniej kwartalnie dla krytycznych systemów) potwierdzają integralność kopii i procesów. Testy muszą obejmować pełne odtworzenie fragmentu bazy i weryfikację spójności danych (hashy).
Szyfrowanie metadanych: wrażliwe metadane (np. powiązania pacjent → zdjęcie) również powinny być chronione.
Szyfrowane nośniki przenośne: pendrive, dyski zewnętrzne używane do kopii – tylko szyfrowane sprzętowo i z pełną kontrolą łańcucha przyjęcia/zwrotu.

5. Przechowywanie kluczy i zarządzanie nimi

Centralny menedżer kluczy (KMS) lub HSM: klucze master przechowywać w urządzeniach spełniających normy bezpieczeństwa; operacje kryptograficzne wykonywać w HSM, minimalizując wywozy kluczy na serwery aplikacyjne.
Rotacja kluczy: planowana rotacja (np. co 12 miesięcy) z możliwością szybkiej rotacji w razie incydentu. Przy rotacji zapewnić możliwość odszyfrowania starszych backupów (wersjonowanie kluczy).
Dostęp do kluczy: polityka least privilege, oddzielne uprawnienia do tworzenia, rotacji i usuwania kluczy. Wszystkie operacje audytowane.
Backup kluczy: klucze master muszą mieć zabezpieczone, szyfrowane kopie zapasowe, przechowywane w oddzielnej lokalizacji (zgodnie z zasadą 3-2-1).

6. Logowanie zdarzeń (audit trail) — co logować i jak

Co logować — każda akcja, która wpływa na dane pacjenta lub system: logowania i wylogowania, odczyty pełnych rekordów, modyfikacje danych, tworzenie/edycja/usuwanie epizodów, eksporty danych, generowanie i wysyłka dokumentów, dostęp do zdjęć, użycie mechanizmu break-glass, tworzenie/odtwarzanie kopii zapasowych, zmiany uprawnień i zmian w konfiguracji systemu.
Szczegółowe elementy logu: identyfikator użytkownika, rola, identyfikator sesji, czas zdarzenia w formacie ISO 8601 z zapisanym offsetem strefy czasowej (np. Europe/Warsaw), adres IP i lokalizacja sieciowa (jeśli dostępna), operacja, obiekt działania (np. ID epizodu), rezultat operacji (sukces/porażka), ewentualne powody/komentarze.
Integralność logów: logi powinny być zapisywane w sposób nieusuwalny (write-once) lub w systemie, gdzie każde usunięcie/zmiana wymaga audytowanego procesu. Stosować kryptograficzne zabezpieczenia logów: okresowe skróty/hashe (np. HMAC) zapisywane w osobnym rejestrze, by wykryć manipulację.
Oddzielny kanał logów: logi audytowe powinny być przesyłane do dedykowanego, separowanego systemu logów/SIEM (Security Information and Event Management) — nawet jeśli to prosty serwer logów, nie powinien być na tym samym hoście co aplikacja.
Retention i dostęp: okres przechowywania logów musi uwzględnić wymogi prawne i audytowe; dostęp do logów audytowych tylko dla uprawnionych ról (audytorzy, administrator bezpieczeństwa), a każde ich przeglądanie powinno być samodzielnie logowane.
Alertowanie i korelacja zdarzeń: definiować reguły alarmowe (np. wielokrotne błędne logowania, dostęp do dużej liczby kart w krótkim czasie, użycie break-glass) i procesy reagowania (kto otrzymuje alert, SLA reakcji).

7. Praktyczne mechanizmy wdrożenia i narzędzia

Hashing i sumy kontrolne: przy tworzeniu kopii i transferze plików tworzyć i przechowywać skróty (np. SHA-256) do walidacji integralności podczas odtwarzania.
Szyfrowanie plików backupu: stosować szyfrowanie symetryczne na poziomie archiwum (np. pliki backupu szyfruje się lokalnym kluczem, który jest szyfrowany kluczem master w HSM).
Mechanizmy WORM: tam, gdzie wymagane jest nieusuwalne przechowywanie (dokumenty medyczne, zgody), korzystać z rozwiązań WORM lub magazynów z opcją immutability.
Czas i synchronizacja: wszystkie serwery i urządzenia muszą używać synchronizacji czasu (NTP) z zaufanych źródeł; niespójność czasu utrudnia korelację logów i śledzenie incydentów. Ustal strefę czasową zapisu (np. UTC plus lokalny offset) i zapisuj offset w logach.

8. Procedury awaryjne i odzyskiwanie po incydencie

Plan odtwarzania: określić RTO (czas przywrócenia) i RPO (dopuszczalna utrata danych) dla krytycznych systemów; plan przywracania musi uwzględniać odtwarzanie bazy danych, usług aplikacyjnych i weryfikację integralności.
Procedura postępowania w przypadku naruszenia: natychmiastowe zabezpieczenie dostępu, analiza logów, izolacja zainfekowanych zasobów, rotacja kluczy, przywrócenie z kopii niezmodyfikowanej, powiadomienie odpowiednich organów (zgodnie z RODO).
Testy scenariuszy: symulacje incydentów (np. zaszyfrowanie serwera produkcyjnego) — przeprowadzać ćwiczenia DR (disaster recovery) i dokumentować wnioski.

Krótki przykład (scenariusz praktyczny)

Gabinet prowadzi usługę dokumentacji zdjęć skóry po zabiegach. Procedura: zdjęcie jest przesyłane z tabletu terapeuty do serwera aplikacji przez HTTPS (TLS). Aplikacja szyfruje plik zdjęcia symetrycznie przed zapisaniem na dysku (klucz sesyjny), natomiast klucz sesyjny jest zaszyfrowany przez klucz master przechowywany w KMS/HSM. Kopia zapasowa zdjęć tworzona jest codziennie o 02:00, szyfrowana innym kluczem backupowym i przesyłana do zewnętrznego magazynu off-site w trybie WORM. Każda operacja odczytu zdjęcia (kto, kiedy, z jakiego IP) jest zapisywana w logu audytowym; log wysyłany równolegle do separowanego serwera logów i zabezpieczany HMAC-em. Co kwartał wykonywany jest test odtworzenia 10 losowych zdjęć z kopii zapasowej i weryfikacja sum kontrolnych.

Krótkie ćwiczenie praktyczne (czas: 30–45 minut)

Cel ćwiczenia: zaprojektuj krótką politykę szyfrowania i backupu dla małego gabinetu (1–5 terapeutów).
Kroki:
a. Wypisz trzy krytyczne typy danych wymagające ochrony (np. zdjęcia, zgody, notatki kliniczne).
b. Dla każdego typu zdefiniuj: czy szyfrowanie w aplikacji, czy na poziomie dysku; gdzie będą przechowywane kopie; jaka będzie retencja (ile dni/miesięcy); gdzie będą przechowywane klucze.
c. Określ harmonogram tworzenia kopii (codziennie/tygodniowo), miejsce off-site (chmura/prywatny serwer), oraz kiedy wykonywany jest test odtworzenia.
d. Wypisz pięć zdarzeń, które powinny generować natychmiastowy alert w systemie logów (np. 10 nieudanych logowań z jednego IP w 5 minut).
Weryfikacja (10 min): porównaj swoją propozycję z założeniami w przykładzie i zaznacz co możesz wdrożyć natychmiast, a co wymaga inwestycji (np. HSM).

Wykonanie ćwiczenia daje praktyczny szkic polityki bezpieczeństwa, który można bezpośrednio przekształcić w wymagania techniczne dla dostawcy systemu e-dokumentacji lub do wdrożenia we własnej infrastrukturze.