Anonimizacja i maskowanie danych po kopii systemu produkcyjnego

Piątek po południu. Administrator SAP kończy odświeżanie systemu testowego po kopii z produkcji. W poniedziałek rano zespół projektowy ma zacząć testy. Dostęp dostają konsultanci, testerzy i deweloperzy ABAP. Część z nich potrzebuje szerokich uprawnień, bo trzeba szybko sprawdzić proces end-to-end. W systemie są jednak nie tylko dane „do testów”. Są też dane klientów, dostawców, rabaty, numery kont, informacje kadrowe i adresy e-mail użytkowników. Produkcja została skopiowana. Ryzyko też.

To nie jest opis konkretnego incydentu. To sytuacja, którą zna wiele działów IT.

System testowy musi być dostępny. Musi pozwolić testerom, konsultantom i deweloperom sprawdzać procesy na danych i wolumenach zbliżonych do rzeczywistych. Bez tego trudno rzetelnie przetestować nowe funkcje, poprawki, raporty, interfejsy czy scenariusze migracyjne.

Ale testowy nie znaczy neutralny. I nie znaczy: bezpieczny z definicji.

W środowisku testowym mogą znaleźć się dane, których w systemie produkcyjnym nie widzi każdy użytkownik: imiona i nazwiska pracowników, numery identyfikacyjne (NIP/ PESEL), adresy fizyczne i e-mail, wynagrodzenia, dane klientów i dostawców, numery rachunków bankowych, warunki cenowe, rabaty, wolumeny sprzedaży, specyfikacje materiałowe, loginy i hasła produkcyjne użytkowników SAP.

Jeżeli taki system jest szerzej dostępny niż produkcja, rośnie powierzchnia ryzyka. Czasem wystarczy błąd, zbyt szerokie uprawnienia, plik wyeksportowany „na chwilę” albo dostęp nadany osobie, która miała tylko przetestować fragment procesu.

System produkcyjny jest zwykle mocno strzeżony. Dostęp jest ograniczony, role są lepiej kontrolowane, a każda zmiana przechodzi przez ścisłe procedury. Błąd na produkcji może zatrzymać proces biznesowy.

System testowy działa inaczej. Ma umożliwiać pracę projektową. Ma być elastyczny. Czasem trzeba nadać użytkownikowi szersze uprawnienia, żeby nie blokować testów. Czasem do systemu wchodzi konsultant zewnętrzny. Czasem tester z innego zespołu. Czasem deweloper ABAP, który musi sprawdzić rozszerzenie na danych zapisanych w tabelach SAP.

To bywa uzasadnione operacyjnie. Ale rodzi pytanie: czy osoba z takim dostępem naprawdę powinna widzieć pełne dane produkcyjne?

Zazwyczaj nie.

Dlatego zabezpieczanie systemu testowego nie powinno polegać wyłącznie na zarządzaniu uprawnieniami. Uprawnienia są ważne. Nie rozwiązują jednak całego problemu. Drugą warstwą ochrony jest praca na danych, które zostały wcześniej zanonimizowane, zamaskowane albo selektywnie usunięte.

Anonimizacja danych testowych często kojarzy się z RODO. Słusznie, ale imiona, nazwiska, adresy, numery pracownicze, wynagrodzenia, dane kontaktowe, dane klientów i dostawców to tylko część tego zagadnienia.

Mamy też informacje, które nie zawsze są danymi osobowymi, a mimo to mają dużą wartość biznesową. Rabaty udzielone klientom. Rabaty wynegocjowane z dostawcami. Kanały sprzedaży. Dane materiałowe. Specyfikacje produkcyjne. Wybrane dane kontrolingowe, na przykład dane rentowności modułu CO-PA.

Dla działu IT to konkretne obiekty i pola tabel, które po kopii z produkcji mogą pojawić się w teście. Każdy obszar danych może wymagać innego podejścia. Nie wszystko trzeba kasować. Nie wszystko trzeba anonimizować w ten sam sposób. Najpierw trzeba ustalić, co jest naprawdę wrażliwe. Potem zdecydować, co powinno zostać usunięte, co zamaskowane, a co może pozostać bez zmian.

Wydaje się, że najprostszym rozwiązaniem jest usunięcie danych wrażliwych z systemu testowego.

Czasem to dobre rozwiązanie. Jeżeli dane nie są potrzebne do testów, można je skasować. Problem zaczyna się wtedy, gdy usuniemy za dużo. Proces przestaje działać. Raport nie ma czego pokazać. Test integracyjny kończy się błędem, bo brakuje powiązanych rekordów. Środowisko jest bezpieczniejsze, ale mniej użyteczne.

Dlatego samo usuwanie danych często nie wystarcza.

Lepsze podejście polega na połączeniu kilku technik. Część danych można usunąć. Część zamaskować. Część zanonimizować. Część zastąpić wartościami ze słownika. Część uprościć albo zagregować.

Przykład: imię i nazwisko można podmienić na inne imię i nazwisko. Nazwę firmy można zastąpić inną nazwą ze słownika. Numer rachunku bankowego można zmienić na pseudo-IBAN, który spełnia wymogi formalne, ale nie jest rzeczywistym kontem. Numer podatkowy można zastąpić wartością technicznie poprawną, ale niepowiązaną z realnym podmiotem. Pełną datę można uprościć, zostawiając rok i techniczną datę, na przykład 1 stycznia, jeśli pole wymaga pełnego formatu.

Można też stosować maski typu „Imię 0001” i „Nazwisko 0001”, zakłócać wybrane wartości, agregować rekordy albo wykonywać podmiany losowe. Cel jest jeden: dane mają przestać wskazywać na rzeczywiste osoby, firmy, konta, rabaty czy specyfikacje, ale nadal pozwalać sprawdzić proces.

Dobrze zaprojektowane maskowanie danych nie polega na przypadkowym zamazaniu pól. To praca na strukturze systemu.

Jeżeli anonimizujemy dane partnera biznesowego, nie wystarczy zmienić jednej nazwy w jednym miejscu. Business partner może występować w wielu tabelach i dokumentach. Ma powiązania ze sprzedażą, finansami, logistyką i raportowaniem. Podmiana musi być spójna.

W systemie testowym zamiast rzeczywistego kontrahenta może pojawić się inny numer wewnętrzny partnera, inna nazwa firmy, inny adres, inne konto bankowe i inne wartości w polach wrażliwych. Rekord nadal istnieje. Proces nadal może działać. Użytkownik testowy nie widzi jednak danych realnego partnera biznesowego.

Podobnie jest z danymi finansowymi, kadrowymi czy sprzedażowymi. Jeśli firma testuje raporty, JPK, KSeF, procesy sprzedażowe lub finansowe, dane muszą zachować odpowiednią strukturę. Nie zawsze muszą być prawdziwe. Muszą być logiczne z punktu widzenia testu.

To jest cienka granica. Jeżeli zmienimy za dużo albo w złym miejscu, test przestaje być wiarygodny. Jeżeli zmienimy za mało, dane nadal będą zbyt blisko produkcji.

Dlatego zakres anonimizacji trzeba ustalać świadomie. Najbardziej krytyczne dane warto zanonimizować albo usunąć. Dla danych średnio krytycznych można wybrać określony zakres. Danych niekrytycznych nie trzeba zmieniać tylko dlatego, że technicznie jest to możliwe.

All for One Test Data Anonymizer to narzędzie do anonimizacji oraz selektywnego usuwania wrażliwych danych pochodzących z systemów produkcyjnych w testowych systemach SAP. Produkt pomaga chronić dane krytyczne biznesowo oraz ograniczać ryzyka związane z RODO w zakresie danych osobowych.

Scenariusz jest prosty. Najpierw powstaje kopia systemu produkcyjnego. Następnie w systemie testowym instalowany jest All for One Test Data Anonymizer. Rozwiązanie jest konfigurowane pod ustalony zakres danych i reguł. Po uruchomieniu procesu system testowy zawiera dane zanonimizowane, zamaskowane albo selektywnie usunięte.

Nie jest to jednorazowa ręczna operacja na tabelach. Po skonfigurowaniu rozwiązania proces można wykorzystać ponownie przy kolejnych odświeżeniach systemu testowego. W wielu firmach taki cykl powtarza się regularnie, więc chodzi nie o „jedno sprzątanie” danych, ale o powtarzalny proces.

Po wdrożeniu i pierwszym uruchomieniu kolejną anonimizację wykonują zazwyczaj administratorzy SAP po stronie klienta. Rozwiązanie jest instalowane w systemie SAP za pomocą zleceń transportowych ABAP. Zakres anonimizacji jest definiowany podczas warsztatów, następnie konfigurowany i weryfikowany w ramach testu.

Pierwszym krokiem anonimizacji danych jest ustalenie zakresu. Warto zacząć od danych najbardziej krytycznych.

Potem definiuje się reguły. Mogą dotyczyć selekcji danych, mapowania wartości, sposobu podmiany pól albo usunięcia określonego zakresu informacji. W narzędziu wykorzystywane są techniczne obiekty anonimizacji przypisane do modułów. Obejmują tabele, powiązania między nimi i przygotowane mechanizmy transformacji danych. Co ważne, narzędzie posiada zestaw prekonfigurowanych obiektów anonimizacji danych, co znacznie skraca i upraszcza wdrożenie. Raz ustaloną konfigurację zapisuje się do ponownego wykorzystania.

Nie zawsze warto zaczynać od pełnej anonimizacji całego systemu.

Rozsądniejszym punktem startu może być wybrany obszar (Proof of Concept): dane partnerów biznesowych, dane pracowników, dane finansowe i rabatowe albo ten fragment procesu, w którym do systemu testowego dostęp mają osoby spoza organizacji.

Takie podejście pozwala szybko zanonimizować najbardziej wrażliwe dane i spokojnie zastanowić się nad rozszerzeniem zakresu anonimizacji, maskowania bądź usuwania danych w przyszłości.

Efektem wdrożenia jest środowisko, w którym dane zostały zanonimizowane, zamaskowane albo selektywnie usunięte zgodnie z ustalonym zakresem.

Korzyść jest konkretna: mniejsze ryzyko pracy na rzeczywistych danych poza produkcją – ograniczanie ryzyka związanego z RODO i wyciekiem danych krytycznych dla firmy.

Jeśli w firmie są obawy, czy dane biznesowe są wystarczająco chronione w środowisku testowym SAP, warto zadać sobie kilka prostych pytań:

• Czy system testowy SAP powstaje jako kopia produkcji?
• Czy trafiają do niego dane klientów, dostawców, pracowników albo użytkowników SAP?
• Czy w testach uczestniczą osoby spoza organizacji?
• Czy w środowisku testowym zdarzają się szerokie uprawnienia, choćby czasowo?
• Czy testujemy procesy na danych finansowych, kadrowych, sprzedażowych lub rabatowych?

Jeżeli odpowiedź na kilka z tych pytań brzmi „tak”, anonimizacja danych testowych jest konieczna do bezpiecznej pracy z testowym systemem SAP.

Rozmowę o anonimizacji danych testowych SAP najlepiej zacząć od zdefiniowania zakresu. Tu pomocne mogą być predefiniowane gotowe obszary anonimizacji dostarczane przez All for One. W kolejnym kroku warto się zastanowić, czy istnieją dane, które nie są na liście „gotowych” obszarów, a powinny zostać usunięte, zamaskowane lub zanonimizowane. Na podstawie zakresu można szybko wycenić projekt z użyciem narzędzia All for One Test Data Anonymizer. Dobrym pomysłem jest rozpoczęcie od PoC dla najbardziej krytycznego obszaru.

Standardowy harmonogram wdrożenia to 1-2 miesiące – od warsztatów potwierdzających zakres do pierwszego uruchomienia.

Krzysztof Siwiec, Dyrektor Digital Transformation Center