Bezpieczniejsze testy systemów informatycznych dzięki wykorzystaniu anonimizacji

Dobrej jakości testy wymagają dobrych danych – najlepiej odzwierciedlających dane rzeczywiste. Bardzo często wykorzystywana w tym celu jest kopia danych produkcyjnych. Takie dedykowane środowisko testowe używane jest do reprodukowania zgłoszeń, debugowania problemów z danymi i realizowania testów obciążeniowych. Pomijając już to, że taka praktyka jest najczęściej niezgodna z RODO, to o ile środowisko produkcyjne jest monitorowane i audytowane niczym forteca, a dostęp do niego mają nieliczne osoby, to środowiska nieprodukcyjne są traktowane już zdecydowanie mniej restrykcyjnie. Grono osób mających do nich dostęp (nie licząc użytkowników) jest też zdecydowanie większe. Wiele poważnych wycieków danych osobowych to nie były włamania do fortecy, a wykorzystanie właśnie tych tzw. “niebronionych osad”.

W obszarze danych testowych najczęściej występują dwie skrajności – dane osobowe przetwarzane są przez testerów i deweloperów w kopiach baz produkcyjnych, lub czekamy pół roku na odświeżenie testowych środowisk sztucznymi danymi, najczęściej kiepsko przygotowanymi. Rozwiązaniem tego problemu może być wdrożenie anonimizacji, jednak okazuje się, że nie jest to łatwe zadanie.

Wyzwania związane z projektowaniem procesu anonimizacyjnego

Proste maskowanie danych może sprawdzać się w prostych przypadkach, jednak szybko można zauważyć, że nie jest to wystarczające dla zastosowań, z którymi zazwyczaj stykamy się na co dzień. Z drugiej strony, przeglądając istniejące rozwiązania zauważyliśmy, że nie spełniają naszych potrzeb – najczęściej nie wspierają mechanizmów pozwalających zachować spójność danych pomiędzy różnymi bazami danych. Trudno też znaleźć rozwiązanie wspierające automatyzację procesu anonimizacyjnego. Najbardziej popularne narzędzia nie pozwalają na definiowanie własnych generatorów nie tylko dotyczących pojedynczego wiersza, ale także uwzględniających rozkład danych. Implementując samemu rozwiązanie spełniające te założenia szybko można natknąć się na przeszkody:

• Proste maskowanie danych prowadzi do występowania błędów aplikacyjnych z powodu potencjalnego naruszenia oczekiwanych przez aplikację formatów danych, np.: PESEL o wartości 8501XXXXX11 będzie powodować błędy walidacyjne. Takie podejście bardzo szybko prowadzi również do występowania duplikatów danych.
• Wykorzystanie natywnych mechanizmów (np. Dynamic Data Masking w SQL Server) może być wystarczające do przeglądania danych bezpośrednio na bazie danych, jednak nie umożliwia zestawienia zanonimizowanej kopii środowiska produkcyjnego w bezpieczny sposób. W tego typu rozwiązaniach dane, mimo że prezentowane jako zamaskowane, wciąż występują w bazie danych w formie surowej.
• Rozwiązanie oparte na skryptach SQL okazuje się niewystarczające. Proste, bezkontekstowe generatory (przy liczbie kluczy rzędu kilkaset tysięcy i więcej) będą coraz częściej wpadać w konflikt z wygenerowanymi już wcześniej danymi, powodując naruszenia unikalności. Rozwiązywanie tego problemu poprzez lookupy skutkować będzie znaczną degradacją wydajności anonimizacji. Wprowadzenie dodatkowych struktur bazodanowych w celu przechowywania wygenerowanych tożsamości będzie natomiast kłopotliwe w utrzymaniu. W przypadku anonimizowania wielu schematów, w tym również na różnych serwerach bazodanowych, to podejście szybko staje się skrajnie nieefektywne, a w przypadku różnych silników bazodanowych wręcz nieużywalne. Skrypty zaczynają być złożone i skomplikowane, przez co wymagają coraz więcej czasu na utrzymywanie ich przy działaniu.
• Zmiany struktury bazodanowej (np. nowa wersja aplikacji, która dodała lub zmodyfikowała tabele i kolumny) będą potencjalnie skutkować deaktualizacją procesu anonimizacyjnego.

Złoty środek

Istnieje jednak złoty środek – zapewnienie swobodnego dostępu do wysokiej jakości danych odzwierciedlających charakterystykę danych produkcyjnych, przy jednoczesnym zapewnieniu bezpieczeństwa rozwiązania i zgodności z regulacjami prawnymi. Ten złoty środek to Nocturno – narzędzie do anonimizacji danych, który zaprojektowaliśmy wspólnie z zespołem. Pracując nad tym rozwiązaniem postanowiliśmy zadbać o:

• Zachowanie pełnej spójności danych – nie tylko w obrębie schematu czy bazy danych, lecz wszystkich źródeł danych w obrębie organizacji (bazy danych różnych dostawców, LDAP, źródła plikowe, itd.)
• Odzwierciedlenie charakterystyki rzeczywistych danych
• Pełne wsparcie dla automatyzacji
• Łatwość tworzenia procesu anonimizacyjnego
• Pełne bezpieczeństwo rozwiązania – brak możliwości odwrócenia anonimizacji
• Konfigurowalność i rozszerzalność – szeroki, wbudowany zbiór algorytmów i generatorów, z możliwością napisania customowych komponentów
• Umożliwienie wersjonowania procesu anonimizacyjnego danego systemu wraz z wersją anonimizowanego systemu (GIT, SVN itd.)

Co zyskujemy wdrażając dobrej jakości anonimizację?

Wdrażając anonimizację jesteśmy w stanie znacząco zmniejszyć liczbę osób posiadających dostęp do danych osobowych do absolutnego minimum. Dzięki dobrej jakości zanonimizowanych danych, wykorzystywanie ich w celach wytwórczych oprogramowania jest transparentne i zgodne z RODO. Proces oparty o Nocturno jest łatwo konfigurowalny i utrzymywalny przez deweloperów – może być równolegle rozwijany w tym samym codebase co aplikacja.

Nocturno wspiera dwa główne scenariusze wdrożeniowe:

• Uruchomienie przez Administratora  anonimizacji wskazanej instancji bazy danych (anonimizacja na życzenie)
• Automatyczny proces tworzenia zanonimizowanej kopii produkcyjnej bazy danych – przygotowanie zanonimizowanego backupu gotowego do wykorzystywania na środowiskach testowych i przez deweloperów

Rys. miejsce Nocturno w automatycznym procesie dostarczania zanonimizowanych kopii baz danych

Więcej na temat Nocturno znajdziecie pod tym linkiem: https://wizards.io/nocturno/. W przypadku pytań na temat procesu anonimizacji, zachęcam do kontaktu.

Marcin Gorgoń, Senior Software Engineer