Anomizowanie bazy danych przy backupie

W kodzie robię tak, mniej więcej, backup bazy danych https://stackoverflow.com/a/13504743/6811048. Teraz przez RODO klient chce by mieć możliwość przy backupie anonimizowanie bazy danych. W tym momencie ręcznie trzeba po backupie wywoływać skrypty.

Do obsługi bazy danych mam SQLProvider który jest singletonem. Nie mam pomysłu inneg niż update na bazie danych, ale to nie przejdzie bo wtedy w apce są złe dane. Zastanawiam się czy taką anonimizację mozna w jakiś łatwy sposób dopisać? Może ma ktoś jakiś pomysł? Myślałem jeszcze by dopisać jakis servis który po zrobieniu backupa otworzy bazkę i zrobi ten update, ale przy dużych bazach może to być problematyczne. Co o tym myślicie?

Prostszej opcji niż nadpisanie onOpen w SQLiteOpenHelper i otworzenie nowego pliku nie widzę. Ma to jednak wadę, że ktoś może przerwać proces anonimizacji. Dlatego należałoby to robić w locie, jeżeli ma to być zrobione w 100% bezpiecznie. A że zajmie to czas w przypadku dużych baz, to coż... nie można mieć ciastka i go zjeść.

Co do samego wymagania, to niespecjalnie rozumiem, co RODO ma tu do rzeczy. Baza, wnioskuję, jest trzymana tylko i wyłącznie lokalnie i nie jest nigdzie wysyłana, więc nic zewnętrznie nie jest przetwarzane. Druga rzecz, której nie rozumiem, to po co komuś tego typu backup. Przecież potem nie możesz już go sensownie użyć w aplikacji. Myślę, że więcej wysiłku bym włożył w rozmowę z klientem i wyjaśnienie mu, że jest to nieprzydatne i bezsensowne.

@Michał Sikora może klienci wysyłają ją gdzieś tam, skoro teraz uzywają skrytpów do anonimizacji. Dobra nie widze innej opcji jak zewnętrzna apka która to zrobi.

Ale to jakaś wewnętrzna aplikacja, że potem klient jeszcze wysyła backup gdzieś wewnątrz systemu? Bo jeżeli ktoś zrobi kopię bazy danych z mojej aplikacji i potem wyśle ją w eter np. do Dropboxa to już nie jest mój problem. Ja tych danych nie przetwarzam.

Dregorio napisał(a):

Dobra nie widze innej opcji jak zewnętrzna apka która to zrobi.

Tzn? Najpierw robisz backup w postaci kopii bazy i dopiero potem coś całkowicie zewnętrznego ma ją jeszcze zanonimizować? Już średnio skuteczne jest anonimizowanie po fakcie z własnej aplikacji.

@Michał Sikora W innym wypadku oni przekopiują bazę na kompa i wykonają ręcznie skrypty odnośnie anonimizacji. Więc lepiej już chyba by robiło im się to automatycznie i nie popsuli/nie zapomnieli jakiegoś skryptu odpalić, albo złej wersji.

No tak, ale czemu anonimizację ma robić zewnętrzna aplikacja a nie ta sama, która robi kopię?

@Michał Sikora No właśnie chciałbym by robiła to wewnętrzna. O to pytam od początku

No to Twoje rozwiązanie z serwisem byłoby ok, ale nie byłoby w 100% skuteczne. Z zewnętrzną aplikacją byłby jeszcze o tyle problem, że ciążko by było dbać o synchronizację struktur baz danych. 100% pewności da tylko anonimizowanie w locie. Najprościej byłoby z poziomu Javy, bo jeżeli chciałbyś anonimizować np. poprzez SHA2 w zapytaniach, to w SQLite musiałbyś dodać callback z poziomu C/C++. Mógłbyś teoretycznie usunąć niepotrzebne kolumny, albo wygwiazdkować je w prostych zapytaniach, ale tutaj robi się problem z utrzymaniem struktury kopii bazy danych - klucze, pola unikalne, itd.

Jeżeli jest akceptowalne, że anonimizacja może się nie powieść za każdym razem, to wykonałbym ją po fakcie utworzenia pliku. Jeżeli nie, no to trzeba się bawić w robienie tego w locie.

Dlatego wolałbym pogadać o tym dogłębniej z klientem. Implementowanie tego, to dużo, niepotrzebnej roboty moim zdaniem.