Jump to content

Przystosowanie Presty do RODO?


Jacekalex

Recommended Posts

Cześć

 

Jak przystosować Prestę 1.6 do RODO?

Mam na myśli zapisywanie danych klientów w bazie w formie zaszyfrowanej kluczem asymetrycznym RSA czy DSA.

Dodatkowo bezproblemowe usuwanie klientów i zamówień z poziomu admina.

 

Z takim szyfrowaniem i deszyfrowaniem danych w PHP (algorytm RSA) nie ma żadnego problemu:

https://gist.github.com/ppoffice/c66a30382eb52d35a6bff05a35d12132

kłopot natomiast jest z API Presty, trzeba by chyba wyłączyć domyślny sposób zapisywania danych wrażliwych,

i zamienić wbudowaną funkcję Presty na własną wtyczkę, która realizuje to zadanie.

Dodatkowo trzeba by dodać też podobny moduł w Adminie, żeby odszyfrowywał dane.

 

Pozdro

Link to comment
Share on other sites

24 maja wchodzi w życie dyrektywa EU.

Quote

do 25 maja 2018 r. procedury stosowane w firmach muszą być zgodne z nowym rozporządzeniem. 

Sznurek:  https://www.pwc.pl/pl/artykuly/2017/biznes-od-nowa.html

 

I koniecznie wymagane pewnie nie jest, w razie czego można zapłacić w granicach 20 mln Ojro kary, jeśli dane wyciekną do netu.

Jak znam język PHP, to udany atak SQL-injection może dotyczyć każdego skryptu, Prestashop nie ma tu żadnego immunitetu. 

 

Do szyfrowania wolę RSA czy DSA bo w takim szyfrowaniu używa się dwóch kluczy, jeden do szyfrowania, drugi do odszyfrowania.

https://pl.wikipedia.org/wiki/RSA_(kryptografia)

https://pl.wikipedia.org/wiki/Digital_Signature_Algorithm

 

Pozdro

Link to comment
Share on other sites

Ograniczenie w Polsce dotyczy obowiązku zgłaszania samego faktu przetwarzania danych osobowych,

nie dotyczy natomiast problemu wycieku danych i opublikowania ich w internecie.

Oczywiście zawsze można udawać głupiego, ale faktyczne grzywny są zdefiniowane w dyrektywie UE,

a ta ma rolę nadrzędną nad polską ustawą.

Link to comment
Share on other sites

No to będzie ciekawie, bo w zasadzie jeżeli taki adres IP jest także czymś co podlega pod dane osobowe to nie ma żadnej szansy na to by zabezpieczyć się w 100% na wyciek czegoś takiego, w sensie... nie tylko PrestaShop to zbiera, przecież zbierają to logi serwera, zbiera to GA, zbiera wiele innych jednostek, zakładam jednak, że nie odpowiadamy tylko za siebie jak to zazwyczaj bywa... :)

Link to comment
Share on other sites

Adres IP to akurat kiepski przykład, bo zawsze jest publiczny, taka jego uroda.

Zwłaszcza, ze przy Ipv4 99% ludziów ma adresy dynamiczne, a Ipv6 zawiera adres MAC  interfejsu, i z tego powodu zarówno Apple jak i Microsoft wprowadziły losowy MAC w swoich systemach.

I dziwi mnie Twoja troska o logi, żeby zobaczyć logi z moich serwerów musiałbyś w każdym wskoczyć na roota, a to nie jest taka prosta sprawa, pomimo zamknięcia projektu Grsec.

Natomiast na pewno daną osobową jest adres email, który musi być widoczny w adminie do zwykłego powiadamiania o statusie zamówienia.

Dlatego kombinuję z kluczem publicznym po stronie sklepu, i kluczem prywatnym po stronie admina.

Admina od sklepu można na kilka sposobów, ja osobiście lubię osobnego virtualhosta (zabezpieczonego certyfikatem PKCS#12) i osobnego demona php do admina sklepu.

Także klucz prywatny byłby nieźle chroniony na okoliczność dowolnych podatności w PHP.

 

PS.

RSA i DSA już są staruszkami, trzeba pamiętać o algorytmie ECDSA i innymi z kryptografii eliptycznej, które powoli stają się standardem.

Edited by Jacekalex (see edit history)
Link to comment
Share on other sites

Szanuje za pomysły. Mam jednak wrażenie, że większe skupienie w firmach, które prowadzą sklepy, a nie mogą sobie pozwolić na duże koszta obsługi informatycznej będzie na zabezpieczeniu dostępów, nie szyfrowaniu danych.

Piszesz o osobnym kluczu dla admina, a co na froncie? Generalnie widzę tutaj sporo wyzwań, tak jak napisałeś, API, wymiana danych z różnymi integratorami, które są napisane "obok" PrestaShop etc.

Link to comment
Share on other sites

Na froncie klucz publiczny, potrafi zaszyfrować, ale nic nie potrafi odszyfrować.

Panel admina ma klucz prywatny i publiczny, może szyfrować i odszyfrować.

Wyjaśnienie kluczy (z obrazkami):

 https://pl.wikipedia.org/wiki/Kryptografia_klucza_publicznego

i zastosowanie w SSL/TLS:

 https://pl.wikipedia.org/wiki/Transport_Layer_Security#Algorytmy_szyfrowania

To jest możliwa opcja.

 

Inna jest taka, że admina w ogóle nie ma na serwerze, jest w biurze na kopii presty, a między bazami na serwerze i w biurze jest replikacja? Mariadb-galera i jedziesz...;)

To też jest wykonalne.

 

Natomiast na pewno by się w preście przydała opcja, która jest obecnie dostępna w Magento2, czyli osobny adres URL admina, zarządzany przez ustawienia zaawansowane.

Można wtedy mieć np sklep na adresie:

https://zajebistysklep.pl 

i admina na adresie

https://admin.zajebistysklep.pl

W tej chwili da się to zrobić przez multisklep i redirect 301, ale to raczej obejście problemu a nie rozwiązanie systemowe.

Co ciekawe w Preście 1.4 takie rozwiązanie działało bez żadnego problemu, było tylko ostrzeżenie,

że  łączę się na inną domenę niż adres sklepu.

 

Pozdro

Edited by Jacekalex (see edit history)
Link to comment
Share on other sites

Zanim zaczniecie panikować proponuję poczytać rozporządzenie, zapoznać się z projektami polskich aktów prawnych ewentualnie poczytać jakieś sensowne opracowania prawne zamiast wierzyć reklamom szkoleń z w rodo w stylu zrobimy szkolenie i wystawimy certyfikat chociaż niewiele wiemy ale chcemy zarobić ;)

Najlepiej jak przedyskutujecie sprawę ze swoimi prawnikami firmowymi oraz swoimi ado i przyszłymi ido :)

 

On 3.03.2018 at 6:24 PM, Jacekalex said:

Ograniczenie w Polsce dotyczy obowiązku zgłaszania samego faktu przetwarzania danych osobowych

Kolega totalnie myli pojęcia ;-)

Link to comment
Share on other sites

Byłem na konferencji na ten temat i ogólnie wychodzi na to, że będzie to spędzało sen z powiek wszystkim developerem. Najgłupszy przykład: mamy backupy - Klient chce być zapomniany więc musimy we wszystkich backupach usunąć jego dane. Wysyłałeś coś kurierem tego Klienta? Poinformuj kuriera, że też ma usunąć. Wystawiłeś fakturę na portalu typu fakturownia? No to anonimizuj dane. Tragedia. Kompletnie nie wiem jak w ogóle się do tego odnieść. 

Podsumowując - prawnik od RODO prezentujący prezentację sam podsumował, że cały akt jest niespójny i że polscy wdrożeniowcy robią wszytko co mogą by ratować nas przed jego zawiłościami.

Szczerze - widzę to w następujący sposób. Tak jak i za starych czasów gdy od pani Grażynki z księgowości otrzymam maila w którym w odbiorach będzie 250 odbiorców i nikt z tym nic nie zrobi.

Uważam, że RODO po czasie stanie się mechanizmem zwalczania konkurencji.

  • Like 1
Link to comment
Share on other sites

1. Backupy to nie problem, zrzuty z bazy robione Mysqldumpem mam szyfrowane w locie przez gnupg kluczem publicznym.

Bez klucza prywatnego (którego w ogóle nie ma fizycznie na serwerze) nikt nie zajrzy do tych backupów, a wystarczy zniszczyć klucz prywatny,  i w ogóle będą tylko śmieciami.

2. Firma kurierska nie jest od gromadzenia danych tylko od doręczania przesyłek, i nie ma prawa trzymać danych odbiorców po dostarczeniu i pokwitowaniu przesyłki dłużej, niż wynika z uzasadnionego okresu reklamacji tej usługi.

Także nikogo powiadamiać specjalnie nie trzeba.


Jedne miejsce, gdzie można i trzeba trzymać dane klientów, to faktury które zgodnie z ustawą o rachunkowości musisz trzymać 5 lat.

Także w programie FK w biurze dla potrzeb skarbówki wszystkie dane mogą i muszą sobie siedzieć długo i szczęśliwie.

Martwi mnie wjazd do bazy danych przez atak SQL-injection, bo po prostu specyfika języka PHP powoduje, że nie istnieje taki skrypt CMS, który byłby zawsze i do końca odporny na taką okoliczność.

Dlatego dane klientów w bazie chciałbym mieć gruntownie kluczem publicznym RSA lub ECDSA  zaszyfrowane.

 

 

Quote

 

Uważam, że RODO po czasie stanie się mechanizmem zwalczania konkurencji.

 

 

 

 

 
Już jest, Ebay czy Amazon sobie poradzą, a cały problem z RODO  sprowadza się do pytania, ile możesz wydać  na prawników. :P
Edited by Jacekalex (see edit history)
Link to comment
Share on other sites

  • 2 months later...

Rodo to jeden wielki problem. My zrobiliśmy moduł do 1.6 z możliwością zgłaszania prośby o zapomnienie. Nie kasuje on zamówień bo według mnie na to są odrębne przepisy skarbowe, mówiące o tym że trzeba przechowywać dokumenty na jakiej podstawie została wystawiona faktura itp. Jednak kasuje konwersacje i klientem a jego dane zostają wykomentowane w systemie. A przede wszystkim klient (zgłaszający)  robi to samodzielnie i nie trzeba angażować admina :)

Zapraszam do testów. tu można pobrać moduł

https://strony.bialystok.pl/rodo/program-rodo.html

Czekam na info i konstruktywne uwagi 

Pozdrawiam 

 

Link to comment
Share on other sites

  • 1 month later...

Ja również chciałabym wiedzieć co ten moduł poza tym, że pojawia się tam dziwna tabelka do exportowania danych robi - bo ani zgod nie dodaje ani popupu nic kompletnie. Skąd ta tabelka ma się uzupełnić??? Aaaa widzę, że dodaje jeszcze link do kontaktu z tekstem "prośba o bycie zapomnianym"

Edited by feronek (see edit history)
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...