Otwarte standardy komunikacji między systemami teleinformatycznymi
0.1.0 - draft
Otwarte standardy komunikacji między systemami teleinformatycznymi
0.1.0 - draft
Wytyczne zawarte w dalszej części dokumentu są zbiorem minimalnych proponowanych wymagań dla organizacji i realizacji wymiany informacji między systemami teleinformatycznymi zdrowia za pomocą interfejsów API.
Standardem wymiany informacji jest HL7 FHIR.
Interfejsy wymiany informacji są zbudowane jako Restful API.
Wymiana Informacji Chronionych powinna być oparta na paradygmacie Zero Trust – każdy podmiot żądający dostępu do Informacji Chronionych musi być traktowany każdorazowo (dla każdego kolejnego żądania) jako niezaufany bez względu na poprzednie żądania, informacje przechowywane w buforach czy pamięci podręcznej, adresie IP etc.
Komunikacja musi być zabezpieczona protokołem TLS w wersji 1.3 lub nowszym zgodnie z IETF Best Practice 195 IETF Użyte szyfry i ich konfiguracja/tryby pracy nie mogą posiadać znanych, według aktualnego stanu wiedzy branżowej, podatności lub słabości.
Systemy udostępniające i korzystające z API powinny wykorzystywać DNSSEC do ochrony endpointów.
Wymagana jest staranna i właściwa weryfikacja certyfikatu TLS wraz z pełną ścieżką oraz atrybutami/rozszerzeniami certyfikatu, w szczególności w przypadku korzystania z mTLS. Weryfikacja certyfikatów musi być zgodna z RFC5280 i późniejszymi aktualizacjami. Strona nawiązująca połączenie musi weryfikować wywoływany system IT pod kątem zaufania – co najmniej musi weryfikować certyfikat TLS na okoliczność: nazwy (SAN lub SN), wystawcy (Issuing CA) i pełnego łańcucha zaufania, rozszerzeń oraz ograniczeń certyfikatu, daty ważności oraz statusu odwołania certyfikatu. Jakakolwiek nieprawidłowa lub nieskuteczna weryfikacja musi oznaczać przerwanie komunikacji, rejestrowanie w dziennikach i powiadomienie właściwych zespołów reagowania.
Strona nawiązująca połączenie musi się jednoznacznie uwierzytelniać w silny sposób odporny na znane ataki, w tym w szczególności ataki powtórzeniowe. Uwierzytelnianie statycznym materiałem uwierzytelniającym jak zestaw nazwa_użytkownika+hasło lub sekret/statyczny klucz API jest nie wystarczająca.
Proponowane dopuszczalne mechanizmy uwierzytelniania to dynamicznie zmienny token OAuth2 z konfigurowalnym czasem ważności (np. 1 h) lub uwierzytelnianie klienta certyfikatem TLS (mTLS). W przypadku użycia certyfikatu klienta musi on być weryfikowany zgodnie z warunkami dla certyfikatu serwera (strony nasłuchującej) opisanymi powyżej.
Użycie adresu IP jako mechanizmu uwierzytelniania jest niedopuszczalne. Adres IP może być użyty tylko jako dodatkowy atrybut w procesie uwierzytelniania lub ograniczania dostępu co jest zalecane.
W przypadku gdy dostęp do Informacji Chronionych jest inicjowany przez użytkownika będącego osobą fizyczną (pacjent lub pracownik medyczny), jeżeli to możliwe do uwierzytelniania powinien być użyty token i identyfikator użytkownika końcowego zamiast uwierzytelniania aplikacji.
Jeżeli to możliwe uwierzytelniany powinien być zarówno użytkownik (za pomocą tokena/poświadczenia osoby) jak i pośrednicząca aplikacja.
Użycie adresu IP jako mechanizmu kontroli dostępu jest niedopuszczalne. Adres IP może być użyty tylko jako dodatkowy atrybut w procesie kontroli dostępu (autoryzacji) co jest zalecane.
Jeżeli to zasadne osoba, której dotyczy żądanie dostępu do Informacji Chronionych, powinna explicite wyrazić taką zgodę przed uzyskaniem dostępu do danych jej dotyczących a wyrażenie zgody powinno być weryfikowane.
Dostęp do Informacji Chronionych musi być oparty o koncepcję minimalnych wymaganych uprawnień i dostępów. Kontrola dostępu powinna być w miarę możliwości realizowana u źródła informacji – w systemie API, a nie systemie żądającym dostępu.
Autoryzacja dostępu powinna być przeprowadzana dla każdego żądania niezależnie uwzględniając kontekst żądania, podmiot (osobę lub aplikację oraz jego rodzaj i rolę) inicjującą żądanie, obiekt, którego dotyczy żądanie (osoba/pacjent), zakres żądanych danych i szczegółowe atrybuty.
Profile i role używane w kontroli dostępu powinny być standaryzowane i muszą być dokumentowane.
Uprawnienia dostępu oraz informacje uwierzytelniające muszą być przedmiotem regularnych i dokumentowanych przeglądów oraz weryfikacji zasadności.
W toku weryfikacji dostępu należy uwzględnić informacje zagnieżdżone (nested records) lub powiązane i odpowiednio stosować niezależną kontrolę dostępu do takich informacji.
Mechanizm kontroli dostępu nie powinien ujawniać żadnych informacji pozwalających na wnioskowanie odnośnie żądanych informacji w przypadku odmowy dostępu w szczególności nie należy podawać powodu odmowy dostępu (Nie znaleziono / Brak Dostępu / Zabronione / Nie uwierzytelniono).
Rozwiązanie zarówno po stronie API udostępniającej informacje jak i po stronie systemu żądającego dostępu („konsumującego” Informacje Chronione) musi zapewniać pełną rozliczalność komunikacji oraz przepływu żądań i odpowiedzi.
Zważywszy, że dzienniki mogą zawierać identyfikatory osób oraz zakres danych medycznych powinny być zbierane, przechowywane i przetwarzane w sposób zapewniający ochronę wynikającą z obowiązków prawnych oraz w sposób zapewniający ich spójność i poufność. W szczególności poufność musi być zapewniona dla dzienników zawierających parametry stanowiące informacje prawnie chronione, przykładowo żądania GET z identyfikatorem osoby.
Logi lub inne informacje przekazywane do systemów monitoringu czy zespołów reagowania na incydenty muszą być pozbawiane zbędnych informacji (lub atrybutów) lub zanonimizowane jeżeli nie jest to niezbędne do realizacji ich zadań.
Dzienniki (logi) powinny zawierać co najmniej: informacje o wiarygodnej i dokładnej dacie zdarzenia, adresie IP komunikacji, podmiocie nawiązującym komunikację, treści żądania dostępu z dokładnym określeniem zakresu danych/zapytania, celu zapytania, informacji o danych udostępnionych/zmodyfikowanych. Należy rejestrować także identyfikator użytkownika inicjującego żądanie przekazywany przez system żądający dostępu.
W przypadku gdy uwierzytelnianie opiera się o poświadczenia systemu IT lub aplikacji żądającej dostępu, jeżeli to możliwe powinien być rejestrowany jednoznaczny identyfikator osoby inicjującej dostęp do Informacji Chronionych.
Zakres informacji powinien pozwalać na pełną rozliczalność żądań i zrealizowanych operacji.
Zakres informacji przechowywany w dziennikach powinien pozwalać na profilowanie zapytań i wyszukiwanie nadużyć – przykładowo rejestrowane powinny być ilość / wolumen zwróconych danych w celu wykrywania nadmiernego pobierania danych itp.
Zakres informacji zbieranych w dziennikach musi pozwalać na rzetelne informowanie (dzisiaj lub w przyszłości) osób, których dane były przedmiotem dostępu.
Strona / System udostępniający interfejs API musi posiadać mechanizmy zapobiegające pobieraniu danych w nadmierny sposób. Powinno to być realizowane na różnych warstwach równocześnie, np. kształtowanie ruchu sieciowego lub wykrywanie wzorców ruchu sieciowego oraz jednocześnie na poziomie aplikacji przez ograniczanie interfejsów / metod API do zwracających ograniczony zakres danych (przykładowo: dane jednego pacjenta, przy wyszukiwaniu tylko 10 pierwszych znalezionych).
Interfejs API musi pozwalać na limitowanie zapytań w oparciu o identyfikator klienta lub systemu żądającego dostępu oraz na podstawie adresu IP.
Zapytania kierowane do API, nawet od uwierzytelnionych podmiotów, muszą być weryfikowane na poprawność składniową i zakres zapytań. Zapytanie nie spełniające wymagań muszą być odrzucane a taki fakt rejestrowany w dziennikach i objęty odpowiednią reakcją.
Zwrócone odpowiedzi API muszą być weryfikowane na poprawność składniową, zakres i format zwróconych informacji. Odpowiedź nie spełniająca wymagań musi być odrzucana a taki fakt rejestrowany w dziennikach i objęty odpowiednią reakcją.
Interfejsy API powinny być budowane w sposób pozwalający na stosowanie systemów i mechanizmów ochrony i monitorowania zapytań jak np. WAF czy API Gateway.