Jak zaudytować aplikację Flutter i Firebase z danymi pacjentów: checklista

Opublikowano 2026-10-11

To lista, którą przechodzę, gdy przeglądam aplikację Flutter na Firebase przetwarzającą dane pacjentów lub dane o zdrowiu, przed startem albo przed pilotażem w szpitalu. Jest napisana dla programisty, który tę aplikację zbudował. Przejdź ją z otwartym repozytorium i konsolą Firebase. Każdy punkt to pytanie, na które odpowiadasz tak, nie albo „nie wiem”, a „nie wiem” też jest ustaleniem.

Za większością punktów stoi pomysł z mojego kursu Zabezpieczanie aplikacji Flutter + Firebase dla danych medycznych: aplikacja widzi wyłącznie spseudonimizowane rekordy, a klucz pseudonimizacji, trzymany poza aplikacją, jest jedynym sposobem powiązania rekordu z pacjentem. Dane, które da się powiązać przez osobno trzymany klucz, nadal są danymi osobowymi w rozumieniu RODO, więc klucz chronisz tak samo jak rekordy.

1. Reguły bezpieczeństwa Firestore i Cloud Storage

Reguły domyślnie odmawiają dostępu. Nigdzie nie ma allow read, write: if true ani reguły, która dla danych pacjentów sprawdza tylko request.auth != null.
Pacjent czyta i zapisuje wyłącznie dokumenty powiązane z własnym pseudonimem. Reguła porównuje pole dokumentu z wartością z tokenu, a nie z czymś, co klient przysłał w żądaniu.
Dostęp personelu idzie przez role w custom claims, a pielęgniarka czyta tylko przypisanych do niej pacjentów.
Zapisy walidują schemat: wymagane pola, typy, brak dodatkowych pól, żadnego pola, którym do Firestore wjechałoby nazwisko albo PESEL.
Reguły Storage trzymają się tego samego modelu co Firestore dla plików takich jak eksport EKG czy zdjęcia.
Reguły mają zestaw testów uruchamiany na Firebase Emulator Suite, a wydanie na produkcję obejmuje jego uruchomienie.
Nikt nie wdraża reguł ręcznie z laptopa. Są w repozytorium i przechodzą przegląd jak kod.

2. Uwierzytelnianie

Włączone są tylko te metody logowania, które miały być włączone. Logowanie anonimowe jest wyłączone, chyba że aplikacja go potrzebuje, a reguły to uwzględniają.
Pacjentów od personelu odróżniają custom claims ustawiane po stronie serwera, nigdy pole, które klient może zapisać.
Claims ustawia Cloud Function albo narzędzie administracyjne, które samo sprawdza, kto je wywołuje.
Ochrona przed enumeracją adresów e-mail jest włączona. Dla kont personelu ustawiona jest polityka haseł i uwierzytelnianie wieloskładnikowe.
Sesje i tokeny odświeżania są unieważniane, gdy pracownik odchodzi albo ginie urządzenie, i jest spisany sposób, jak to zrobić.

3. App Check

App Check jest włączony dla Firestore, Storage, Functions i każdego innego API Firebase, które aplikacja wywołuje.
Włączone jest egzekwowanie, nie tylko monitorowanie, po sprawdzeniu, że prawdziwa aplikacja przechodzi.
Tokeny debugowania istnieją tylko w buildach debug i nie są w repozytorium.

4. Cloud Functions i IAM

Każda funkcja działa na własnym koncie usługi z najmniejszymi potrzebnymi uprawnieniami, a nie na domyślnym koncie App Engine z rolą Editor.
Funkcje callable weryfikują token i claims wywołującego. Funkcje HTTP, które mają zostać prywatne, nie są otwarte dla allUsers.
Sekrety leżą w Secret Manager albo w sekretach funkcji, nie w zmiennych środowiskowych w repozytorium i nie w aplikacji Flutter.
Lista osób z rolą Owner lub Editor w projekcie jest krótka, imienna i przeglądana. Klucze kont usługi w plikach JSON nie istnieją albo każdy ma uzasadnienie.
Krok reidentyfikacji, w którym pseudonim jest wiązany z pacjentem, to jedna funkcja albo jedna usługa poza projektem Firebase, która loguje każde użycie.

5. Lokalizacja danych i regiony UE

Baza Firestore, bucket Storage i funkcje są w regionach UE. Region ustawia się raz i nie da się go później zmienić, więc sprawdź to teraz.
Usługa klucza pseudonimizacji też działa w UE.
Każda usługa spoza Firebase, która dostaje dane, na przykład dostawca poczty albo narzędzie do śledzenia błędów, jest spisana z regionem i rolą w rozumieniu RODO.

6. Szyfrowanie i pseudonimizacja

Firestore przechowuje wyłącznie spseudonimizowane rekordy: pseudonim zamiast nazwiska, daty urodzenia, PESEL, telefonu czy adresu.
Klucz pseudonimizacji leży poza projektem Firebase, dostęp do niego jest ograniczony, a każde użycie jest logowane.
Pola, które muszą być zapisane, ale nie mogą być czytelne dla backendu, są szyfrowane na urządzeniu, a klucz urządzenia leży w keystore platformy, nie w shared preferences.
Aplikacja nie loguje, nie cache'uje i nie wysyła do analityki niczego, co pozwoliłoby zidentyfikować pacjenta.
Spisany model zagrożeń, jedna strona, mówi, czego dowie się atakujący z pełnym dostępem do odczytu Firestore. Jeśli w odpowiedzi jest nazwisko, model nie jest skończony.

7. Logi i ślad audytowy

Odczyty i zapisy rekordów pacjentów przez personel są logowane z informacją kto, co i kiedy, a logu nie mogą edytować osoby, których dotyczy.
Logi zawierają pseudonimy, nie nazwiska, i nie zawierają treści żądań z danymi o zdrowiu.
Retencja logów jest ustawiona i zgodna z tym, co mówi polityka prywatności.
Ktoś czyta logi. Jest alert na nietypowy dostęp, na przykład jedno konto czytające wielu pacjentów.

8. Kopie zapasowe i retencja

Firestore ma zaplanowane kopie zapasowe albo włączone odtwarzanie do punktu w czasie, a przywrócenie było przećwiczone co najmniej raz.
Kopie są w UE i ma do nich dostęp mniej osób niż do bazy produkcyjnej.
Okresy retencji są zdefiniowane dla każdego typu danych i jest zadanie albo procedura, która usuwa dane po ich upływie.
Żądanie pacjenta o usunięcie danych ma procedurę obejmującą Firestore, Storage, kopie w ramach ich retencji i usługę klucza.

9. Zewnętrzne SDK

Każde SDK z pubspec.yaml, które łączy się z siecią, jest spisane z tym, co wysyła i dokąd.
SDK analityki, raportowania błędów i reklam nie dostają danych o zdrowiu, pseudonimów ani identyfikatorów, których nie zamierzałeś udostępnić. Sprawdź ustawienia automatycznego zbierania, nie tylko własne wywołania.
Powiadomienia push nie niosą danych o zdrowiu w treści. Powiadomienie każe pacjentowi otworzyć aplikację, a aplikacja pobiera treść.
Każdy podmiot zewnętrzny przetwarzający dane osobowe ma umowę powierzenia i figuruje w rejestrze czynności przetwarzania.

10. Podstawy RODO

Podstawa prawna przetwarzania danych o zdrowiu jest spisana, razem z przesłanką z art. 9.
Jest rejestr czynności przetwarzania z danymi, celami, odbiorcami, regionami i retencją.
Zdecydowałeś, czy potrzebna jest ocena skutków dla ochrony danych (DPIA), i spisałeś dlaczego. Dla aplikacji przetwarzającej dane o zdrowiu na dużą skalę zakładaj, że tak.
Polityka prywatności zgadza się z tym, co aplikacja robi, łącznie z podmiotami z punktu 9.
Pacjent może dostać kopię swoich danych i poprosić o ich usunięcie, i obie rzeczy działają od początku do końca.
Jeśli wymieniasz rekordy z systemem szpitalnym przez HL7 FHIR, tożsamość pacjenta zostaje po stronie szpitala, a Twoja aplikacja dalej posługuje się pseudonimem.

Co zrobić z wynikiem

Odpowiedzi „nie” i „nie wiem” uporządkuj według tego, co atakujący z dostępem do odczytu Firestore dostałby z każdej z nich, i w tej kolejności poprawiaj. Punkty 1, 6 i 4 zwykle idą pierwsze.

Jeśli chcesz, żeby zrobił to ktoś, kto nie widział wcześniej kodu, z pisemnym raportem i rozmową: audyt bezpieczeństwa i RODO aplikacji medycznej (Flutter, Firebase), stały pakiet 12 h za 2 580 PLN netto, raport w ciągu 7 dni roboczych. To przegląd tych samych obszarów co ta checklista, bez zmian w kodzie, nie test penetracyjny, nie certyfikacja i nie opinia prawna.