Jacekalex Posted March 3, 2018 Share Posted March 3, 2018 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 More sharing options...
Krystian Podemski Posted March 3, 2018 Share Posted March 3, 2018 Czy jest to na pewno wymagane? Czy w ogóle Polska ustawa i prace nad RODO zostały zakończone? Link to comment Share on other sites More sharing options...
Jacekalex Posted March 3, 2018 Author Share Posted March 3, 2018 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 More sharing options...
Krystian Podemski Posted March 3, 2018 Share Posted March 3, 2018 Polecam poczytać coś bardziej aktualnego bo z moich informacji wynika, że RODO w Polsce będzie mocno ograniczone dla firm zatrudniających < 250 osób. Link to comment Share on other sites More sharing options...
Jacekalex Posted March 3, 2018 Author Share Posted March 3, 2018 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 More sharing options...
Krystian Podemski Posted March 3, 2018 Share Posted March 3, 2018 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 More sharing options...
Jacekalex Posted March 3, 2018 Author Share Posted March 3, 2018 (edited) 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 March 3, 2018 by Jacekalex (see edit history) Link to comment Share on other sites More sharing options...
Krystian Podemski Posted March 3, 2018 Share Posted March 3, 2018 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 More sharing options...
Jacekalex Posted March 3, 2018 Author Share Posted March 3, 2018 (edited) 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 March 3, 2018 by Jacekalex (see edit history) Link to comment Share on other sites More sharing options...
Piotr K. Posted March 5, 2018 Share Posted March 5, 2018 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 More sharing options...
hakeryk2 Posted March 6, 2018 Share Posted March 6, 2018 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. 1 Link to comment Share on other sites More sharing options...
Jacekalex Posted March 10, 2018 Author Share Posted March 10, 2018 (edited) 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. Edited March 10, 2018 by Jacekalex (see edit history) Link to comment Share on other sites More sharing options...
Rutcom2015 Posted May 18, 2018 Share Posted May 18, 2018 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 More sharing options...
Piotr K. Posted May 18, 2018 Share Posted May 18, 2018 Jeśli ktoś złożył zamówienie to moim zdaniem nie powinno się kasować jego danych przez kilka lat. Link to comment Share on other sites More sharing options...
zoso Posted May 24, 2018 Share Posted May 24, 2018 (edited) On 18.05.2018 at 9:51 AM, Rutcom2015 said: Zapraszam do testów. tu można pobrać moduł https://strony.bialystok.pl/rodo/program-rodo.html Czekam na info i konstruktywne uwagi A jak on działa ? Coś bliżej ? Bo po instalacji nic nie można z nim zrobić ... Edited May 24, 2018 by zoso (see edit history) Link to comment Share on other sites More sharing options...
feronek Posted July 14, 2018 Share Posted July 14, 2018 (edited) 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 July 14, 2018 by feronek (see edit history) Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now