Baza danych i pliki są szyfrowane w spoczynku przez dostawcę infrastruktury. Niezależnie od tego Heltio szyfruje po swojej stronie cztery najbardziej wrażliwe pola, żeby sam odczyt bazy nie wystarczył do ich odtworzenia.
Co jest szyfrowane dodatkowo
| Co | Gdzie |
|---|---|
| PESEL pacjenta | karta pacjenta |
| Treść notatki klinicznej | notatka kliniczna |
| Transkrypcja nagrania wizyty | sesja asystenta AI |
| Szkic notatki wygenerowany z nagrania | sesja asystenta AI |
Poza tą listą szyfrowane są jeszcze certyfikaty placówki do integracji z P1 — trzymane w osobnych kolumnach, z odciskiem palca i datą wygaśnięcia widocznymi w kreatorze.
Nie są szyfrowane dodatkowo: numer dokumentu cudzoziemca, numery rachunków bankowych, metadane załączników ani adresy pacjentów. Poprzednia wersja tej strony wymieniała je jako objęte.
Jak to działa
Każda wartość dostaje własny, jednorazowy klucz. Tym kluczem szyfrujemy treść algorytmem AES-256-GCM, który przy okazji wykrywa naruszenie danych. Sam klucz jednorazowy jest następnie zaszyfrowany kluczem głównym i podróżuje razem z zaszyfrowaną treścią w jednym ciągu znaków — nie ma osobnej tabeli kluczy.
W ciągu tym zapisany jest też odcisk klucza głównego, którym go zamknięto. Dzięki temu wymiana klucza głównego jest wykrywalna, a stary klucz może przez pewien czas służyć wyłącznie do odczytu, podczas gdy nowe zapisy idą już nowym.
Szyfrowanie i odszyfrowanie dzieje się w warstwie dostępu do bazy, nie w poszczególnych miejscach kodu. Konsekwencja jest podwójna: żaden nowy ekran nie zapomni zaszyfrować, ale każdy skrypt pisany z pominięciem tej warstwy zapisze dane jawnie. Skrypty, które piszą do tych pól, są wymienione imiennie w kodzie i pilnowane osobnym testem.
Zaszyfrowanego numeru PESEL nie da się wyszukać przez porównanie. Obok trzymamy więc jego jednokierunkowy skrót, liczony z dodatkowym sekretem aplikacji — wystarcza do wyszukania i do dopasowania kartotek, a sam z siebie nie pozwala odtworzyć numeru.
Gdzie leżą dane
Baza danych i pliki: Frankfurt. Klucze: zmienna środowiskowa aplikacji działającej w UE. Poczta: dostawca w UE. SMS: dostawca w Polsce. Praca offline w aplikacji mobilnej: dostawca w UE. Tłumaczenia: Niemcy. Pełna lista wraz z rozbieżnościami: Podmioty przetwarzające i umowy powierzenia.
Ruch do serwera aplikacji idzie po HTTPS. Serwer odpowiada nagłówkami wymuszającymi połączenie szyfrowane przez dwa lata, zakazującymi osadzania w ramce i odgadywania typu treści.
Jak rozdzielone są placówki
Rozdział danych placówek jest realizowany w warstwie aplikacji, nie w bazie: w migracjach nie ma reguł bezpieczeństwa na poziomie wiersza. Zamiast tego każde zapytanie o dane pacjenta musi zawierać identyfikator placówki, członkostwo jest sprawdzane przed procedurą, a nad całością stoi reguła lintera i zestaw zapadek uruchamianych przy każdej zmianie kodu — liczba miejsc bez filtru może tylko maleć.
Kopie zapasowe
Kopie zapasowe robi osobna, niezależna usługa. Jej stan pilnuje strażnik działający w głównym procesie aplikacji — celowo na zewnątrz usługi kopiującej, bo martwa usługa nie zgłosi własnej śmierci. Alarm idzie, gdy kopia nigdy nie powstała, gdy ostatni przebieg zakończył się błędem albo gdy ostatnia poprawna kopia jest starsza niż trzydzieści godzin.
Czego nie ma
- Zewnętrznego testu penetracyjnego z opublikowanym streszczeniem. Poprzednia wersja tej strony powoływała się na taki raport i na wykonawcę; dokument nie istnieje.
- Załączników PDF do tej strony. Wszystkie odnośniki do plików w katalogu
/legal/prowadziły donikąd — żaden z tych plików nigdy nie został dodany.