Rozszerzenie GDPR - retencja danych

Rozszerzenie do Store Builder oraz Multi-Vendor domyka lukę w zgodności z RODO, o której łatwo zapomnieć. Wbudowany moduł GDPR w CS-Cart anonimizuje dane wyłącznie zarejestrowanych klientów, tymczasem zamówienia składane przez gości, bez zakładania konta, zawierają komplet danych osobowych: imię, nazwisko, adres, telefon i adres e-mail. Nasz dodatek przejmuje te zamówienia, pozwala je zanonimizować pojedynczo albo grupami, a przede wszystkim wprowadza politykę retencji, która sama pilnuje, by dane starsze niż ustalony okres znikały bez udziału obsługi. Na tym jednak nie poprzestaje. Dane klientów wypływają ze sklepu rzadko przez włamanie, a znacznie częściej przez zwykłą codzienną pracę: przez listę zamówień otwartą po numer przesyłki, przez eksport całej bazy do arkusza i przez kopię sklepu zgraną na komputer programisty. Dodatek maskuje dane osobowe na ekranach panelu, zapisuje w dzienniku każde sięgnięcie po nie i przygotowuje bezpieczną kopię bazy do pracy poza serwerem.

Najważniejsze funkcje

- Anonimizacja zamówień gości pojedynczo albo grupami z listy, z zachowaniem pozycji i kwot dla księgowości.

- Automatyczna polityka retencji w zadaniu cron, z konfigurowalnym okresem, wykluczaniem statusów i trybem testowym włączonym domyślnie.

- Maskowanie danych osobowych na ekranach panelu, z odsłonięciem pełnych wartości na jedno świadome kliknięcie i śladem w historii.

- Dziennik dostępu z alertem, gdy jedna osoba przegląda albo eksportuje nietypowo dużo danych, oraz gdy ktoś wyłącza sam dodatek.

- Szyfrowane archiwum zamówień w miejsce bezpowrotnej anonimizacji, z zachowaniem możliwości odtworzenia dokumentu sprzedaży dla urzędu albo sądu.

- Anonimizacja kopii bazy do pracy programisty, uruchamiana z konsoli i chroniona czterema niezależnymi bramkami.

- Czyszczenie obejmujące komplet miejsc, w których sklep trzyma dane klienta: adres dostawy zapisany w strukturze zamówienia, tekst wpisany w opcji produktu, pliki wgrane przez klienta, bony podarunkowe i komentarze przesyłek.

- Odnotowywanie odczytów zamówień przez interfejs programistyczny, dzięki czemu widać także dane pobierane przez integracje, a nie tylko oglądane w panelu.

Zanim przejdziemy do ekranów, warto rozdzielić trzy rzeczy, które dodatek robi niezależnie od siebie. Pierwsza sprząta dane w sklepie i działa bez udziału człowieka. Druga zasłania dane na ekranie, nie ruszając bazy. Trzecia czyści kopię bazy poza sklepem, na potrzeby pracy programisty. Zakresy tych narzędzi nie pokrywają się i mylenie ich prowadzi do najczęstszych nieporozumień:

Ilustracja 1: trzy mechanizmy dodatku i zasięg każdego z nich

Wszystko zaczyna się od jednego ustawienia. W zakładce Retencja danych podajesz, po ilu latach od ostatniej aktywności klienta jego dane mają zostać zanonimizowane, a obok zaznaczasz statusy zamówień wyłączone z tej reguły. Na zrzucie okres wynosi sześć lat, co odpowiada typowemu wymaganiu przechowywania dokumentacji podatkowej, a z listy statusów wybrano trzy: Otwarte, Oczekuje na dostawę i Oczekuje na kontakt. To drugie pole jest ważniejsze, niż wygląda, bo zamówienie z otwartym zwrotem albo trwającą reklamacją zachowa komplet danych tak długo, jak długo sprawa się nie zakończy, nawet jeżeli formalnie przekroczyło już okres retencji:

Zrzut ekranu 1: okres retencji i statusy wyłączone z automatycznej anonimizacji

Automatyczne sprzątanie jest celowo wąskie. Obejmuje zamówienia złożone bez zakładania konta oraz konta klientów, a wszystko poza tymi dwoma obszarami zostaje nietknięte. Zamówienie kwalifikuje się dopiero wtedy, gdy jest starsze niż ustawiony próg i jednocześnie jego status nie znajduje się na liście wykluczeń:

Ilustracja 2: zasięg automatycznego sprzątania i warunki kwalifikacji zamówienia

Druga zakładka odpowiada za to, co widzi obsługa na co dzień. Przełącznik Maskuj dane osobowe włącza skracanie wartości na ekranach panelu, a lista poniżej rozstrzyga, których pól to dotyczy: adresu poczty, telefonu, nazwiska, adresu oraz danych płatności. Osobne pole wskazuje grupy administratorów objęte maskowaniem, dzięki czemu dział obsługi może pracować na innych zasadach niż księgowość. Pusty wybór oznacza tu wszystkich, więc domyślne ustawienie chroni dane najszerzej, jak się da:

Zrzut ekranu 2: zakres maskowania danych i grupy administratorów

Zakładka audytu ustala, kiedy sklep ma zareagować na nietypowy odczyt. Próg alertu podaje się w rekordach, a okno czasowe w minutach: na zrzucie jest to dwieście rekordów w ciągu piętnastu minut, czyli wyraźnie powyżej normalnego dnia pracy obsługi. Eksporty mają własny próg liczony w sztukach, ponieważ wielokrotny drobny eksport jest typowym sposobem obejścia progu liczonego objętością. Poniżej ustawia się okres przechowywania dziennika oraz adres, na który mają iść powiadomienia pocztą:

Zrzut ekranu 3: progi alertów, okno czasowe i adres odbiorcy powiadomień

Automatyzacja mieści się w trzech przełącznikach. Pierwsze dwa rozstrzygają, czy cykliczne zadanie ma obejmować zamówienia gości, konta zarejestrowanych klientów, czy jedno i drugie. Trzeci to tryb testowy, domyślnie włączony: przelot odnajduje wtedy kandydatów, policzy ich i zapisze w historii, ale nie zmienia ani jednego wiersza w bazie. Dzięki temu pierwsze spotkanie z retencją kończy się raportem, a nie niespodzianką, a decyzję o realnym uruchomieniu podejmuje się dopiero po obejrzeniu liczb:

Zrzut ekranu 4: zakres automatycznej anonimizacji i tryb testowy

Zanim zobaczysz zamaskowaną listę, warto odróżnić dwie sytuacje, które na ekranie wyglądają niemal tak samo. Maskowanie zakrywa dane wyłącznie w widoku, a w bazie leżą one nienaruszone i wracają po wyłączeniu ustawienia. Anonimizacja nadpisuje wartości w bazie i nie cofa jej żadne ustawienie:

Ilustracja 3: maskowanie w panelu w zestawieniu z anonimizacją danych

Tak wygląda lista zamówień przy włączonym maskowaniu i to jest ekran, przy którym w ciągu dnia przewija się najwięcej osób. W kolumnie klienta widnieje imię z nazwiskiem skróconym do inicjału, w kolumnie telefonu zostają trzy ostatnie cyfry. Zamówienia od 110 wzwyż wyglądają inaczej, bo przeszły już przez retencję: w miejscu danych stoją wartości zastępcze. Numer zamówienia, status, data i kwota pozostają nienaruszone, więc obsługa dalej rozpoznaje zamówienie i wykonuje swoją pracę, tylko bez kompletu danych osobowych na ekranie:

Zrzut ekranu 5: lista zamówień z zamaskowanymi danymi osobowymi

To samo maskowanie obejmuje listę klientów. Nazwisko skraca się do inicjału, adres poczty do trzech pierwszych znaków przed małpą, a numer telefonu do końcówki. Kolumny operacyjne, czyli liczba zamówień, ich wartość i status konta, zostają w pełni czytelne, bo bez nich lista przestałaby być użyteczna. Widać tu również, że ochrona nie zależy od tego, czy klient kiedykolwiek coś kupił:

Zrzut ekranu 6: lista klientów z zamaskowanymi danymi kontaktowymi

Zasłona nie jest barierą absolutną i nie taki jest jej cel. Obsługa czasem musi zobaczyć pełny adres, więc dodatek daje osobne żądanie podglądu, a każde jego użycie zostawia wpis w dzienniku. Podgląd zachowuje się różnie w zależności od tego, w jakim stanie są dane:

Ilustracja 4: podgląd pełnych danych i ślad, który po sobie zostawia

Kiedy pełne dane są rzeczywiście potrzebne, pozycja w menu wiersza otwiera je w osobnym oknie. Każde pole ma własny przycisk kopiowania do schowka, więc obsługa nie przepisuje niczego ręcznie. U góry okna stoi nota, że podgląd został zapisany w historii operacji razem z kontem administratora i godziną, a zaraz pod nią wyjaśnienie, że wartości odtworzono z zaszyfrowanego archiwum, ponieważ to zamówienie przeszło już przez retencję. Sklep pokazuje więc pełne dane osoby, której dane osobowe zniknęły z tabeli zamówień, i nie traci przy tym śladu, kto po nie sięgnął:

Zrzut ekranu 7: kontrolowane odsłonięcie pełnych danych osobowych

Pojedyncze zamówienie obsługujesz w miejscu, które znasz najlepiej. W menu akcji szczegółów zamówienia, obok rdzeniowych pozycji drukowania i edycji, pojawiają się dwie nowe: Anonimizuj oraz Pokaż dane osobowe. Pierwsza widnieje tylko tam, gdzie ma sens, czyli przy zamówieniu gościa, które nie zostało jeszcze przetworzone. Zamówienie zarejestrowanego klienta trafia natomiast do rdzeniowego mechanizmu RODO, więc dwa narzędzia nigdy nie wchodzą sobie w drogę:

Zrzut ekranu 8: pozycje dodatku w menu akcji zamówienia

Za chwilę zobaczysz zamówienie po operacji, dlatego wcześniej warto wiedzieć, że dodatek oferuje dwie drogi postępowania ze starymi danymi. Pierwsza nadpisuje dane bezpowrotnie. Druga przenosi je do zaszyfrowanego archiwum, z którego da się je odtworzyć, dopóki istnieje plik klucza:

Ilustracja 5: anonimizacja i archiwum jako dwie drogi tego samego sprzątania

Po wykonaniu operacji to samo zamówienie wygląda zupełnie inaczej. W sekcji danych klienta imię i nazwisko zastąpiły gwiazdki, adres poczty przybrał neutralną postać z przedrostkiem, a numer telefonu został wyzerowany. Pozycje zamówienia, kwoty i podatki po lewej stronie zostały nietknięte, więc dokument nadal domyka się w księgowości i w raportach sprzedaży. Tego stanu nie da się cofnąć, dlatego dodatek pilnuje go trzema zabezpieczeniami naraz: trybem testowym, wykluczonymi statusami i pytaniem o potwierdzenie:

Zrzut ekranu 9: zamówienie po anonimizacji, dane zastąpione, kwoty nienaruszone

Przy porządkach po latach pojedyncze zamówienia to za mało. Po zaznaczeniu wierszy na liście pasek u góry pokazuje liczbę wybranych pozycji, a menu Akcje zawiera pozycję Anonimizuj zaznaczone obok rdzeniowych operacji eksportu i usuwania. Jedno polecenie obejmuje wtedy cały zaznaczony zestaw, a przed wykonaniem sklep prosi o potwierdzenie, bo operacja jest nieodwracalna. Ta sama możliwość działa na liście klientów:

Zrzut ekranu 10: anonimizacja wielu zaznaczonych zamówień jednym poleceniem

Ekran zarządzania RODO otwiera się tym, co wymaga reakcji człowieka. Wyróżniona sekcja alertów pokazuje, że administrator przekroczył próg odczytu danych w oknie czasowym, razem z datą, kontem i liczbą odczytanych rekordów. Niżej stoją dwa liczniki kandydatów do anonimizacji, każdy z przyciskiem prowadzącym prosto na właściwą listę, a pod nimi przycisk ręcznego uruchomienia całego przelotu, bez czekania na harmonogram serwera:

Zrzut ekranu 11: alert o masowym odczycie i statystyki retencji

Niżej na tym samym ekranie leży historia operacji, czyli materiał na wypadek kontroli. Każdy wiersz mówi, kiedy operacja się odbyła, jakiej encji dotyczyła, jaka to była akcja i co ją wywołało. Widać tu cały repertuar dodatku obok siebie: anonimizację zamówienia, przeniesienie do archiwum, wyczyszczenie kolumn źródłowych, podgląd pełnych danych oraz alert o masowym odczycie. Numer zamówienia jest odnośnikiem, więc z historii przechodzi się wprost do dokumentu, którego wpis dotyczy:

Zrzut ekranu 12: historia operacji na danych osobowych

Dziennik dostępu mierzy dwie różne rzeczy dwiema różnymi jednostkami i to rozróżnienie jest celowe. Zwykłe przeglądanie liczone jest w rekordach obejrzanych w oknie czasowym, natomiast eksport liczony jest w uruchomieniach, ponieważ objętości pliku system sklepu nie ujawnia:

Ilustracja 6: dwie miarki progów alertu i kanały powiadomień

Ostatnia sekcja odpowiada na pytanie, które podczas kontroli pada najczęściej: kto miał dostęp do danych i kiedy. Dziennik notuje każde wejście na listę zamówień, listę klientów i w szczegóły zamówienia, a przy każdym zapisuje liczbę rekordów, które administrator faktycznie zobaczył. W kolumnie zdarzenia widać również odsłonięcia zamaskowanych wartości i eksporty danych. Adres IP stoi obok konta, natomiast identyfikator sesji nie jest zapisywany jawnie, ponieważ jest poświadczeniem uwierzytelniającym:

Zrzut ekranu 13: dziennik dostępu do danych osobowych

Na końcu zakładki retencji leży ustawienie, które rozstrzyga los danych po upływie okresu przechowywania. Pierwszy tryb nadpisuje je bez możliwości powrotu i pozostaje wartością domyślną. Drugi przenosi je do zaszyfrowanego archiwum dodatku, a dopiero potem czyści kolumny w tabeli zamówień. Poniżej podaje się ścieżkę pliku klucza, który musi leżeć poza katalogiem sklepu, a sklep sam potwierdza jego stan komunikatem o gotowości i dostępnych wersjach. Bez klucza tryb archiwum odmawia pracy, zamiast po cichu przejść na nadpisywanie:

Zrzut ekranu 14: wybór trybu retencji i stan klucza szyfrującego archiwum

Tryb archiwum opiera się na jednym pliku klucza, który leży poza katalogiem sklepu. Dopóki klucz istnieje, dane wracają w komplecie. Po jego utracie archiwum staje się nieczytelne na zawsze, więc pod względem skutku dorównuje zwykłej anonimizacji. Sama operacja jest zabezpieczona kolejnością kroków, w której zamówienie czyszczone jest dopiero po udanym odczycie kopii:

Ilustracja 7: rola pliku klucza i kolejność kroków chroniąca dane

Na koniec narzędzie, którego nie uruchomisz z panelu. Czyszczenie kopii bazy służy pracy programisty na realnych danych zamienionych na atrapy i jako jedyne w dodatku działa hurtowo. Właśnie dlatego wymaga czterech niezależnych warunków naraz, a brak któregokolwiek zatrzymuje operację:

Ilustracja 8: cztery warunki wymagane do wyczyszczenia kopii bazy

Jak działa każda z funkcji

Anonimizacja pojedynczego zamówienia gościa. W menu akcji szczegółów zamówienia pojawia się pozycja Anonimizuj, widoczna wyłącznie przy zamówieniu złożonym bez rejestracji i jeszcze nieprzetworzonym. Kliknięcie zastępuje imię, nazwisko, oba adresy, numery telefonów i adres poczty wartościami zastępczymi zbudowanymi według schematu, którego używa sam CS-Cart. Pozycje zamówienia, kwoty i podatki zostają nietknięte, więc dokument nadal domyka się w księgowości. Zamówienie zarejestrowanego klienta trafia tam, gdzie trafiało dotąd, czyli do rdzeniowego mechanizmu RODO.

Operacje masowe. Z listy zamówień da się zaznaczyć wiele pozycji naraz i zanonimizować je jednym poleceniem z menu akcji, bez otwierania każdej z osobna. Ta sama możliwość działa na liście klientów. Przy koncie zarejestrowanym dodatek sięga po klasy rdzenia odpowiedzialne za anonimizację, więc obejmuje dokładnie te same tabele i pola, które objąłby sam sklep, wraz z profilami adresowymi i zgodami. Kiedy operacja idzie z harmonogramu, czyli bez zalogowanego administratora, dodatek przechodzi na własną ścieżkę zapisu, ponieważ mechanizm rdzenia wymaga aktywnej sesji panelu.

Automatyczna polityka retencji. Cykliczne zadanie odnajduje zamówienia gości i konta klientów, które przekroczyły okres przechowywania, i anonimizuje je bez udziału obsługi. Zamówienia gości są grupowane po adresie poczty, a próg liczy się od NAJNOWSZEGO zamówienia danego adresu, więc klient wracający co dwa lata nigdy nie straci danych w połowie relacji. Konto zarejestrowane kwalifikuje się wtedy, gdy jego ostatnie zamówienie jest starsze niż próg albo gdy klient nie zamówił nigdy. Zadanie uruchamia się poleceniem z harmonogramu serwera albo adresem otwieranym w panelu, a oba warianty są gotowe do skopiowania wprost z ustawień. Konto, które nie złożyło ani jednego zamówienia, jest mierzone własną historią, czyli datą rejestracji i ostatniego logowania, więc świeżo założone konto bez zakupów nie trafi pod anonimizację. Pierwsze uruchomienie w sklepie z wieloletnią historią rozkłada się na kilka przelotów, bo wielkość jednego wsadu jest ograniczona, a reszta kandydatów wraca przy następnym uruchomieniu; przelot nie pozwala też uruchomić się drugi raz, dopóki poprzedni trwa, więc kliknięcie przycisku w panelu w trakcie nocnego zadania niczego nie dubluje.

Okres retencji i wykluczone statusy. Okres podaje się w latach i domyślnie wynosi sześć, co odpowiada typowemu wymaganiu przechowywania dokumentacji podatkowej. Obok stoi lista statusów wyłączonych z reguły. Zamówienie z otwartym zwrotem albo trwającą reklamacją zachowuje komplet danych tak długo, jak długo sprawa się nie zakończy, nawet jeżeli formalnie przekroczyło już okres retencji. Wykluczenie działa w obie strony, więc takie zamówienie nie zostanie też objęte operacją masową.

Tryb testowy. Domyślnie włączony i pomyślany tak, żeby pierwsze spotkanie z retencją kończyło się raportem, a nie niespodzianką. Przelot w tym trybie odnajduje kandydatów, policzy ich i zapisze w historii, ale nie zmienia ani jednego wiersza w bazie. Dzięki temu da się sprawdzić na produkcji, ilu klientów i ilu zamówień dotknie polityka, zanim zapadnie decyzja o jej uruchomieniu.

Maskowanie danych w panelu. Na liście zamówień, w szczegółach zamówienia i na liście klientów dane osobowe pokazują się w postaci skróconej: adres poczty do trzech pierwszych znaków, telefon do trzech ostatnich cyfr, nazwisko do inicjału, ulica i kod pocztowy do początku. Miasto i kraj zostają jawne, bo bez nich lista przestaje być użyteczna w codziennej pracy, a same w sobie nikogo nie identyfikują. Maskowanie działa na warstwie widoku i nie dotyka bazy, więc nie ma mowy o tym, żeby zamaskowana wartość gdziekolwiek się zapisała. Zakres pól i grupy administratorów objętych maskowaniem ustawia się osobno, więc dział obsługi może pracować inaczej niż dział księgowości. Jest też jeden nastawiany wyjątek: zamówienia z ostatnich kilku dni mogą pokazywać pełne dane, żeby osoba pakująca paczki nie musiała odsłaniać każdego z osobna. Wyjątek liczy się od daty złożenia zamówienia, wychodzi z niego samo po upływie ustawionej liczby dni i domyślnie jest wyłączony, bo świadomie osłabia ochronę. Dane płatności zostają zamaskowane także w jego oknie.

Kontrolowane odsłonięcie pełnych danych. Maskowanie nie może blokować pracy, bo czasem trzeba zadzwonić do klienta albo poprawić adres przesyłki. Pozycja w menu wiersza otwiera więc okno z pełnymi wartościami i przyciskami kopiowania do schowka. Pełne dane nie siedzą w kodzie strony listy, tylko pobiera je dopiero świadome kliknięcie, a całość chroni osobne uprawnienie. Każde otwarcie zostawia wpis w historii razem z kontem administratora i znacznikiem czasu, więc wiadomo, kto i kiedy sięgnął po dane konkretnej osoby.

Dziennik dostępu do danych osobowych. Dodatek zapisuje każde wejście na listę zamówień, listę klientów i w szczegóły zamówienia, a razem z nim liczbę rekordów, które administrator faktycznie zobaczył. Do dziennika trafiają również odsłonięcia zamaskowanych wartości oraz eksporty zamówień i klientów. Wpis zawiera konto, czas, adres IP i miejsce w panelu, natomiast identyfikator sesji zapisywany jest wyłącznie w postaci skrótu, ponieważ jest poświadczeniem uwierzytelniającym. Zapis jest odporny na awarię: błąd bazy nie przerywa ani wyświetlenia listy, ani eksportu.

Alerty o nietypowym dostępie. Gdy dorobek jednego administratora w ruchomym oknie czasowym przekroczy ustawiony próg, dodatek zgłasza to trzema kanałami naraz: wpisem w historii operacji, wpisem w dzienniku diagnostycznym i wiadomością pocztową, o ile jej wysyłka została włączona. Eksporty mają własny próg liczony w sztukach, ponieważ wielokrotny drobny eksport jest typowym sposobem obejścia progu liczonego objętością. Na jedno okno przypada najwyżej jeden alert dla danego administratora, więc powiadomienia nie zamieniają się w lawinę. Osobnym zdarzeniem jest wyłączenie samego dodatku: zapisuje się w chwili, gdy dodatek jeszcze działa, i nie podlega ograniczeniu częstotliwości, ponieważ każde jego wystąpienie ma znaczenie.

Szyfrowane archiwum zamówień. Ustawienie trybu retencji rozstrzyga, co dzieje się z danymi po upływie okresu przechowywania. Domyślnie zostają nadpisane bez możliwości powrotu. Drugi tryb przenosi je najpierw do zaszyfrowanej tabeli dodatku, a dopiero potem czyści kolumny w tabeli zamówień, dzięki czemu zrzut bazy przestaje zawierać materiał osobowy, a sklep zachowuje możliwość odtworzenia oryginału na żądanie uprawnionej osoby. Archiwum chroni szyfr AES-256-GCM, a klucz leży w pliku poza katalogiem sklepu i powstaje osobną, świadomie uruchamianą komendą. Kolumny źródłowe znikają wyłącznie po sprawdzeniu, że zaszyfrowana kopia istnieje, daje się odczytać i zgadza się co do znaku z wartościami, które mają zniknąć. Podgląd danych rozpoznaje zamówienie trzymane w archiwum i pokazuje wartości odszyfrowane, a gdy archiwum jest nieczytelne, mówi o tym wprost zamiast zwracać przypadkową treść.

Anonimizacja kopii bazy do pracy programisty. Kopia sklepu na komputerze programisty to najczęściej pomijana droga wycieku: dane klientów leżą wtedy poza serwerem, poza kopiami zapasowymi i poza rejestrem czynności przetwarzania. Narzędzie uruchamiane z linii poleceń zamienia taką kopię w materiał techniczny, na którym nadal da się pracować, ale który nie zawiera niczyjego nazwiska, adresu ani telefonu. Obszarów jest trzydzieści pięć i obejmują nie tylko konta oraz zamówienia, ale też opinie, wpisy na forum, zapisy na newsletter, bony podarunkowe, komentarze przesyłek, dane firm i dostawców. Osobno czyszczone są dane logowania do serwera pocztowego, parametry bramek płatniczych i transakcje płatnicze, więc żaden test na kopii nie wyśle wiadomości do prawdziwego klienta ani nie dotknie prawdziwej płatności. Uruchomienie bez parametrów wypisuje wyłącznie raport, a realne czyszczenie wymaga jawnego potwierdzenia z nazwą bazy i adresem instalacji, chronionego czterema niezależnymi bramkami.

Dane osobowe poza kolumnami zamówienia. Zamówienie w CS-Cart nie mieści się w jednej tabeli i to jest najczęstsza przyczyna złudnego poczucia zgodności. Obok widocznych pól sklep zapisuje adres dostawy w postaci struktury wysyłkowej, tekst wpisany przez klienta w opcji produktu, czyli dedykację na grawerze albo treść nadruku, pliki wgrane do takiej opcji, dane nadawcy i odbiorcy bonu podarunkowego oraz komentarze do przesyłek. Żadnego z tych miejsc wbudowany moduł RODO nie czyści przy zamówieniu gościa, więc zamówienie wyglądające w panelu na zanonimizowane potrafiło nadal nieść pełne imię i adres. Nasz dodatek obejmuje je wszystkie, na każdej drodze czyszczenia danych, a pliki wgrane przez klienta kasuje również z dysku sklepu. Ostrożność jest przy tym wbudowana w zakres: wartości opcji wybieranych z listy zostają nietknięte, bo niosą modyfikator ceny pozycji, bon możliwy do zrealizowania zostaje nietknięty niezależnie od wieku zamówienia, a adres samego sklepu, zapisany w tej samej strukturze co adres klienta, idzie dalej na fakturę i list przewozowy. Sklepy, które anonimizowały dane wcześniejszymi wersjami dodatku, mają do dyspozycji tryb linii poleceń domykający tę zaległość, a uruchomiony bez potwierdzenia wyłącznie pokazuje jej skalę.

Odczyty przez interfejs programistyczny. Sklep zwykle wie, kto ma konto w panelu, ale rzadko pamięta, ile systemów zewnętrznych pobiera jego zamówienia i od kiedy. Klucz wydany kiedyś firmie kurierskiej albo hurtowni daje dostęp do tych samych danych co panel, tylko bez jednego kliknięcia w interfejsie. Dziennik dostępu odnotowuje więc również odczyty zamówień przez interfejs REST, jako osobny rodzaj zdarzenia i z firmą odczytaną z uwierzytelnienia integracji, więc w wersji wielosprzedawcowej wpis trafia do właściwego sprzedawcy. Zapisywane są wyłącznie odczyty, a zamówienie tworzone tą samą drogą nie jest liczone jako dostęp do danych. Zdarzenia tego rodzaju jako jedyne nie podlegają progowi alertu, ponieważ integracja pobierająca dane co kilka minut przekracza każdy sensowny próg z definicji, a alert odzywający się codziennie bez powodu przestaje być czytany.

Kontrola skutku operacji. Anonimizacja konta klienta może się nie powieść po cichu, bo wartości zastępcze powstają losowo, a sklep odrzuca zapis, gdy trafi na adres zajęty przez inne konto. Dodatek sprawdza więc skutek każdego zapisu, zanim uzna konto za przetworzone: kontrolowany jest zarówno wiersz konta, jak i wszystkie należące do niego adresy oraz wartości pól własnych. Konto, które kontroli nie przeszło, zostaje bez znacznika, trafia do historii z opisem tego, co zdążyło się już nadpisać, i wraca przy kolejnym przelocie. Osobno wstrzymywana jest anonimizacja konta, którego zamówienia nie trafiły wcześniej do zaszyfrowanego archiwum, ponieważ zamówienie z pełnymi danymi i konto, po którym nie da się go rozpoznać, to stan najgorszy z możliwych. Przelot, w którym cokolwiek się nie udało, kończy się statusem błędu, więc harmonogram serwera zgłasza go zamiast uznać za wykonany.

Historia operacji i rozliczalność. Każda operacja na danych osobowych zostawia wpis z datą, typem encji, wykonaną akcją i źródłem wywołania, gotowy do okazania podczas kontroli. Adres poczty trafia tam wyłącznie jako skrót, nigdy zwykłym tekstem, ponieważ rejestr operacji na danych osobowych sam nie może być kolejnym miejscem ich przechowywania. W wersji wielosprzedawcowej historia jest rozdzielona między sprzedawców: każdy widzi wpisy dotyczące własnych zamówień i własnych klientów, a komplet pozostaje po stronie operatora platformy. Firma zapisana przy wpisie należy do encji, której wpis dotyczy, a nie do panelu, w którym operacja została wykonana, więc podgląd danych wykonany przez operatora zostaje widoczny także dla sprzedawcy i rozliczalność działa w obie strony.

Rozszerzenie RODO zamyka najczęściej pomijaną lukę w zgodności sklepu z przepisami o ochronie danych, czyli dane osobowe w zamówieniach gości, a przy okazji porządkuje to, co dzieje się z danymi wewnątrz panelu. Ręczna anonimizacja pojedynczych zamówień, operacje masowe i w pełni automatyczna polityka retencji stanowią jego pierwszą warstwę, maskowanie danych, dziennik dostępu i alerty drugą, a szyfrowane archiwum trzecią, dzięki której sklep godzi obowiązek usuwania danych z obowiązkiem przechowywania dokumentów sprzedaży. Tryb testowy i wykluczanie statusów chronią przed przypadkową utratą danych, całość działa obok wbudowanego modułu GDPR i nie wymaga modyfikacji plików systemowych, a pełna historia operacji daje spokój na wypadek kontroli.

Zapraszamy do kontaktu i zakupu!