Środowiska testowe w organizacji nie powinny być traktowane jako przestrzeń o domyślnie niskim poziomie zabezpieczeń. Warto pamiętać, że środowiska testowe a ochrona danych osobowych to kluczowe zagadnienie, ponieważ wykorzystywanie realnych informacji, w tym danych wrażliwych, niesie ze sobą poważne ryzyka potwierdzone decyzjami Prezesa UODO. Dowiedz się, o czym należy pamiętać, aby zapewnić najwyższy poziom cyberbezpieczeństwa podczas korzystania z infrastruktury testowej.
Dane testowe
Podczas pracy ze środowiskami testowymi kluczowe pytanie powinno dotyczyć rodzaju wykorzystywanych danych. W miarę możliwości zalecane jest korzystanie ze zbiorów niezawierających prawdziwych danych użytkowników – szczególnie pod kątem ochrony danych osobowych, aby nie dopuścić do naruszenia.
Zasadne jest pytanie o to, skąd wziąć potrzebne dane, które nie dotyczą prawdziwych użytkowników. Dobrze odpowiada na to zapis z opisu przedmiotu zamówienia testów Projektu P1 od e-Zdrowia – wykonawcy byli zobowiązani do wygenerowania nowych danych bądź anonimizacji już istniejących.
Rola zabezpieczeń technicznych dla środowiska testowego a ochrona danych
Przykładem realnego incydentu związanego z korzystaniem z prawdziwych danych osobowych może być sprawa opisana w decyzji Prezesa UODO ze stycznia 2022 roku (DKN.5130.2215.2020), gdzie rozwiązanie w fazie testowej wykorzystywało rzeczywiste dane klientów. W momencie wdrażania środowiska nie zastosowano wszystkich planowanych zabezpieczeń, zaś później stwierdzono nieuprawniony dostęp do bazy z danymi osobowymi. Zdarzenie dotyczyło ok. 120 tys. osób. Incydent jasno pokazuje, że środowiska testowe wymagają należytej ochrony oraz nie powinno się wykorzystywać w nich prawdziwych danych.
W lutym 2021 roku Prezes UODO wydał decyzję (DKN.5130.2024.2020) dotyczącą testowej migracji bazy danych w ramach platform szkoleniowych Krajowej Szkoły Sądownictwa i Prokuratury. Dane ponad 50 tys. osób były dostępne z poziomu internetu, co stanowiło naruszenie ochrony.
Warto przy tym podkreślić, że zgodnie z RODO (art. 32 ust. 1 lit. d) oraz decyzjami PUODO (DKN.5131.9.2024) stosowane środki ochrony danych muszą być testowane, mierzone i oceniane w sposób regularny, świadomie zaplanowany, zorganizowany i udokumentowany. Jednocześnie środowiska testowe powinny być elementem analizy ryzyka, podobnie jak produkcyjna infrastruktura.
W ramach środowisk testowych warto pamiętać o minimalizacji danych (art. 5 RODO) oraz konieczności wykazania podstawy przetwarzania (art. 6 RODO). Zdecydowanie warto opierać się na anonimizacji, zamiast korzystania z prawdziwych danych.
Przykład 1.
Środowisko testowe wymaga przetwarzania numerów PESEL. Zamiast korzystania z prawdziwych wartości, zaleca się użycie fikcyjnego zbioru danych – np. wygenerowanego za pomocą skryptu.
KSC a testowanie
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrożyła nowy obowiązek dla wielu podmiotów ważnych i kluczowych. W art. 8 ust. 1 pkt 2 lit b UoKSC wskazano konieczność zapewniania bezpieczeństwa w ramach procesu „nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego”, uwzględniając testowanie systemu informacyjnego.
Jednocześnie art. 8 ust. 3 UoKSC wyłącza podmioty ważne będące podmiotami publicznymi i wybrane podmioty z sektora szkolnictwa wyższego ze stosowania zasad opisanych w ust. 1 na rzecz spełniania wymagań opisanych w załączniku nr 4 do ustawy.
Praktyczne wdrożenie
W dokumencie „Praktyki zarządzania ryzykiem związanym z cyberbezpieczeństwem w łańcuchu dostaw dla systemów i organizacji” opublikowanym przez Ministerstwo Cyfryzacji, będącym tłumaczeniem standardu NIST SP 800-161, znalazła się jedna rekomendacja o konieczności analizowania wszelkich zmian w systemach w ramach środowisk testowych – szczególnie pod kątem bezpieczeństwa, prywatności, wad, usterek, zaniedbań, niekompatybilności czy złośliwego działania.
Centrum e-Zdrowia w ramach „Zaleceń dotyczących bezpieczeństwa zarządzanych aplikacji internetowych” z lipca 2025 roku rekomenduje wydzielenie środowisk dla rozwoju, testów i produkcji. W dokumentacji Ministerstwa Finansów odnośnie do KSeF 2.0 znajdziemy stwierdzenie, że środowisko testowe jest oddzielone od produkcyjnego zarówno technicznie, jak i logicznie.
W „Instrukcji wypełniania wniosku o dostęp do Systemu Rejestrów Państwowych (SRP)” wskazano kolejny ważny aspekt, dotyczący oddzielnych poświadczeń do systemów produkcyjnych i testowych (w tym przypadku certyfikatów).
Przykład 2.
Środowiska testowe są wykorzystywane również przez jednostki samorządu terytorialnego. W Szczegółowym Opisie Przedmiotu Zamówienia (Załącznik nr 7), dotyczącym projektu „Portalu e-mieszkańca” (I.271.9.2020) dla Urzędu Miasta i Gminy Białobrzegi wskazano jasną definicję środowiska testowego jako miejsca do „bezpiecznego uruchomienia zasobów produkcyjnych Zamawiającego” wraz z modelowaniem i testowaniem rozwiązań.
Faza II i Faza III realizacji zamówienia opierały się na wykorzystaniu środowisk testowych, m.in. na podstawie gotowego prototypu systemu. Po akceptacji UMiG miały rozpoczynać się prace nad startem środowiska produkcyjnego.
Anonimizacja i pseudonimizacja a fikcyjne dane
W ramach środowisk testowych ważne są trzy pojęcia: dane fikcyjne, anonimizacja oraz pseudonimizacja. Pierwsza kategoria dotyczy sztucznie wygenerowanych informacji, które nie odnoszą się (ani wcześniej nie odnosiły się) do żadnej osoby fizycznej. Wyrok TSUE z grudnia 2023 roku (C-683/21) podkreśla, że nie są to dane osobowe w rozumieniu art. 4 pkt 1 RODO.
Anonimizacja to proces polegający na nieodwracalnym przekształceniu prawdziwych danych osobowych w informacje niemożliwe do przypisania do konkretnej osoby fizycznej. Europejska Rada Ochrony Danych wskazuje trzy elementy pomagające stwierdzić poprawne zanonimizowanie danych, takie jak:
- brak wyodrębnienia rekordów,
- brak powiązań,
- brak wnioskowania.
Kluczowym aspektem anonimizacji jest zapewnienie, że dane faktycznie są nieodwracalnie zmienione, tzn. niemożliwe jest powiązanie z osobą fizyczną oraz jej tożsamość nie może być ustalona na bazie dostępnych informacji. Samo usunięcie informacji może okazać się niewystarczające, jeśli w zbiorze znajdują się inne charakterystyczne dane (np. opisy działań możliwych do zidentyfikowania w publicznie dostępnych rejestrach). Dopiero poprawna anonimizacja sprawia, że informacje przestają być danymi osobowymi.
Przykład 3. (na podstawie opracowania ICO – brytyjskiego odpowiednika UODO)
W 2006 roku Netflix opublikował zbiór danych zawierający oceny filmów około 500 tys. użytkowników platformy w ramach konkursu „Netflix Prize”. Firma myślała, że zbiór jest poprawnie zanonimizowany. Badacze mogli powiązać dane z recenzjami na portalu IMDb (służącego do oceny filmów), co ujawniło m.in. preferencje polityczne osób oraz inne wrażliwe informacje. Jest to przykład nieskutecznej anonimizacji pomimo usunięcia bezpośrednich identyfikatorów użytkowników, ponieważ można było je powiązać z publiczną aktywnością w internecie.
Pseudonimizacja polega na odwracalnej zamianie danych osobowych na inne wartości (np. ciągi znaków). Organizacja ma „klucz” pozwalający przypisać dany identyfikator do osoby – np. wartość „4539320” do Jana Kowalskiego. UODO podkreśla, że takie informacje wciąż pozostają danymi osobowymi.
Rekomendacje z zakresu cyberbezpieczeństwa
Środowiska testowe powinny podlegać odpowiednim zasadom z zakresu cyberbezpieczeństwa. Fakt, że (z założenia) nie znajdują się tam dane produkcyjne, nie oznacza, że nie powinniśmy monitorować takiego środowiska. W ramach zapewniania należytego poziomu cyberbezpieczeństwa powinniśmy stosować poniższe środki:
- odseparowanie od środowiska produkcyjnego;
- brak dostępu do internetu (jeśli nie jest wymagany);
- ograniczenie dostępu do osób, którym jest on niezbędny wraz z dwuetapowym uwierzytelnianiem;
- logowanie zdarzeń;
- regularne aktualizowanie.
Podsumowanie - środowiska testowe a ochrona danych i cyberbezpieczeństwo
Środowisko testowe powinno opierać się na fikcyjnych lub anonimizowanych danych (jeśli takie podejście jest możliwe). Decyzje UODO jednoznacznie pokazują, że konieczne jest również przyłożenie odpowiedniej wagi do zabezpieczeń technicznych i organizacyjnych.
Usunięcie numerów PESEL bądź nazwisk ze zbioru danych automatycznie nie oznacza, że można wykorzystywać go w ramach środowisk testowych – konieczne jest uwzględnienie szerszego kontekstu.
Zarówno JST, jak i MŚP powinny pamiętać, że luka w nieodseparowanym środowisku testowym może mieć realne skutki dla ochrony danych osobowych oraz ciągłości działania.
