GDPR?
Sziasztok! Érdeklődni szeretnék, hogy ki mennyire érzi fontosnak ezt a témát? Mennyire foglalkoztok a GDPR-rel? A jogi módosításokon kívül ki-mit csinál? Illetve tudtok olyan leírásokat, amelyek emberi nyelven leírják a feladatokat?
https://www.adatvedelmirendelet.hu/a-rendelet-szovege/
https://www.microsoft.com/hu-hu/rethink-IT-security/GDPR/default.aspx
■ https://www.adatvedelmirendelet.hu/a-rendelet-szovege/
https://www.microsoft.com/hu-hu/rethink-IT-security/GDPR/default.aspx
2. egész jó
Az egyébként eddig is így volt, hogy ha a user konkrétan azt kéri, hogy töröld az összes személyes adatát, akkor azt meg kell tenned (fizikálisan).
Nálunk fontos irányelv, hogy a több rendszerben is szereplő azonos személyeknek a jövőben fizikailag egyetlen helyen legyen tárolva minden személyes adata. Az még kérdéses, ez hogy fog sikerülni, mindenesetre már most érdekes problémákat okoz. :)
Az is érdekes, hogy mi a személyes adat és mi nem. Amennyire jelenleg én tudom: minden olyan adat személyes adat, amivel a konkrét személy azonosítható. Tehát még a TAJ szám és az adószám is. :) Hiába nem hordoz önmagában érdemi információt.
Személyes adaton belül (mi) megkülönböztetünk érzékeny és nem érzékeny személyes adatot. Életkor, születési hely - idő, email, ilyesmik érzékenyek, mert: önmagukban is jelentős információt hordoznak, a személy esetleg titkolni szeretné, felhasználható akár a személy kárára is. Ezeknek a megjelenítésével is vigyázni kell, hogy ki láthatja.
Egyelőre nem tudok fogyasztható leírásról, de reményeim szerint fogok kapni, ha nem lesz titkos, akkor megosztom. :)
Egyébként engem nagyon érdekel a téma, viszont a törvények értelmezésére nálunk megvannak a külön emberek, úgyhogy nem biztos, hogy nagyon tájékozott leszek a jogi oldalon...
SZERK: a Microsoftos linken egész jól összefoglalták a lényeget szerintem.
Belenéztem a MS-os linkbe, de
Nem backup
Aztán van pl 10 db különböző webshopod. Ezekben csak olyanok tudnak vásárolni, akik a központi portálon regisztráltak és nem automatikusan mindegyikben, csak ahova "beengeded" őket.
És minden webshopban duplikálod a felhasználók adatait a központról, és adatot változtatni csak a központban lehet (az pedig automatikusan szinkronizál, ahova kell).
Na kb ez a helyzet jelenleg, csak még kissé bonyolultabb. :)
De ilyenkor ugye meg kéne mondani a usernek, hogy a központi portál db-jében is megvannak az adatai, meg az xy webshop db-ben is.
A backup tudtommal nem minősül plusz helynek, mert az nem egy üzemeltetett db szerver, csak fájlok, "biztos helyen".
Ez olyan DDD-sen hangzik, ott
Megfogtál :)
Ez az OAuth2 gyakorlatilag ugyanaz / ugyanolyan, mint a guglis OAuth 2.0? Mert utóbbihoz volt már szerencsém.
Ja, ugyanaz. A DDD
A DDD gyakorlatilag annyi, hogy domain modeled van, ami lazán csatolt a megjelenítéshez és az adat tároláshoz is. A kezdeti szakaszban gyakorlatilag csak azon dolgozol, hogy lemodellezd a folyamatokat, szervezeti egységeket, stb, amiket a cég használ és részben vagy egészben automatizálni akar. Általában nagy projekteknél szokták használni, és nagyjából hasonlóan, mint ahogy a cégben a szervezeti egységek vannak, feldarabolják az egészet külön appokra, külön domain-el, külön adatbázisokkal. Lehetnek átfedések, mint a fent említett felhasználó, vásárló, címzett, stb. ezeknek a tulajdonságait másolni szokták ahelyett, hogy ugyanazt az osztályt használnák. Ehheza másoláshoz kommunikálnak egymással az alkalmazások. Lehet event bus-al, lehet úgy is, hogy az új eseményekre csinálsz egy REST API-t, aztán a másik app azt pollozza, stb. Egyébként rohadtul túlbonyolítják az egészet sokszor, meg a magyarázatokat se konyhanyelven adják elő, aztán azért nehezen érthető az egész.
Szia T.G.! Mi orvosi
Mi orvosi szoftvert is fejlesztünk, úgyhogy nekünk komolyan kell majd foglalkozni ezzel, de érdemi információm még nekem sincs. Láttam a magyar nyelvű jogszabályt meg ezt a Microsoftos linket is megkaptam már. Valószínűleg nem lehet megúszni az első átolvasását sem. Pepitához hasonlóan én is azt ígérhetem, hogy ha lesz elképzelésem róla, hogy mi a teendő, akkor majd megírom.
Üdv:
Dávid
Én úgy tudom orvosi témában
Süti engedély visszavonása?
Egy újabb leírás: http://www.gazdagmami.hu/email-marketing/gdpr-mit-kell-tudnod-rola-online-vallalkozokent
Az érdekelne, hogy nálatok mennyire tölti be a Cookie Consent a valódi szerepét? Amíg az nincs leokézva, addig valóban nem használtok sütit, vagy ettől függetlenül használ az oldal sütit és ez a leokézás csak alibiből van kint? Vagy nincs is kint? :)
És van-e lehetőség ezt visszavonni? Én még sehol nem láttam, hogy ezt visszavonhatnám, pedig most nézegettem az oldalakat, de eddig még nem láttam ilyet...
Nálatok mi a helyzet?
Itt szerintem van hiba
Adatbiztonsági szempontból magának az adatnak van jelentősége, hogy ha azt az egyetlen adatot illetéktelen megszerzi, azáltal be tud-e azonosítani engem.
Tegyük fel, hogy megszerzed azt az IP-t, amiről ezt a választ írom. Mit tudsz meg rólam? Még annyit sem, hogy otthon vagyok-e, ahol kb 5 eszköz van ugyanazon a külső IP-n, vagy az irodában, ahol nem is tudom, hogy hányezer... :)
Cookie Consent
Szerintem ez megérne egy külön fórumtémát. :)
Amennyire én tudom, a jelenlegi törvényt ez lefedi.
Ettől még ez nem "alibi", mindössze addig kapja a figyelmeztetést, amíg tudomásul nem veszi.
A visszavonás egyébként elég érdekes lesz (ha lesz), mert a mai (magyar) weboldalak túlnyomó többsége használ session-t és a sessionid sütiben van. Márpedig ez a süti (jelenleg) már akkor is a kliensen van, amikor a legelső alertet kirakod neki róla.
A másik, hogy ilyen oldalakon mit csinálsz, ha visszavonja? Dobsz egy szép 403 / 404 - et?
Most kicsit beült a bogár a fülembe, azon is gondolkodom, hogy amíg nincs "okésüti", addig nem indítasz sessiont, ha nincs session, akkor pedig csak a teljes oldalt kitöltő "fogadd már el a sütiket lécccíííí" van, tartalom semmi.
Roppant felhasználóbarát...
Ha ez a visszavonósdi komoly lesz, illetve addig nem is lehet sütije, míg nem okézta, akkor azt hiszem megugrik az olvasottsága János - egyébként elég érdekes - cikkének. :)
Cookie?
Különböző dolgok!
Eddig csak figyelmeztetni kellett, ezután pedig addig nem használhatsz sütit, amíg meg nem engedik. Innentől lesz csak jelentősége a visszavonásnak.
Nekem idáig ez jött le, de büntetőjogi felelősséget nem vállalok. :-D
Viszont láttunk már csodákat, az is eléggé valószínű, hogy a guglit és / vagy f@szbúkot nem fogják hirtelen kitiltani az EU-ból...
Én biztos, hogy nem fogom ezt elkapkodni, mert számítok még jó pár cikkre a fenti szolgáltatók kapcsán, majd azután fog kiderülni, hogy mit is kell tenni.
Volt már pár ilyen (pl a személyes adatok törlése), amire ezek a "kisebb cégek" kimondták, hogy "nem tudják" pontosan úgy megvalósítani - és maradt minden a régiben.
Ha pedig nekik lehet júzer engedélye nélkül is sütijük, akkor nekem is.
Nincs hiba... :(
Illetve.
Számomra ez tényleg azt jelenti, hogy amíg nem okézta le a juzer, addig egyáltalán nem használhatok sütit.
És, az is látszódik, hogy szeretné mindenki majd másra tenni a felelőséget...
Nyilván
Azért azt megvárom, hogy mit lépnek erre a nagy szolgáltatók, mert mint fentebb is írtam, a meglévő weboldalak - webshopok többsége el fog tűnni süti ill. session nélkül, az üzemeltetőknek nem feltétlenül lesz annyi pénzük, hogy kb újra fejlesztessék le az egészet emiatt.
Amúgy szerintem nettó baromság, hogy egy
session_id = 'abc123'- ból "megmondjuk", hogy ő konkrétan a Teszt Elek Tápiószentmucsaröcsögéről.Ha valóban ez a terv, akkor ezt nagyon túltolták.
Valószínűleg nem a webshopra,
Törvény hatálya
Érdekes lenne! :-D
Nem azt mondtam, hogy másra
"csak"
Nem tudom, hogy lenne-e kedvem sorozatgyártásban session-mentesíteni kiscsillió Vér Pistike által "fejlesztett", "van egy olyan scriptem, csak nem működik a hülye" típusú oldalt "ócóé, mer Pistike is sokat kért"... :/
Mindenesetre a "nagyok" miatt én kivárok, hogy mi lesz a vége, legalábbis azokban, ami a saját döntésem.
Ez az előnye a vállalkozói
Nem - nem :)
Nekem pont munkavállalóként jön / jött össze jobban, hogy tarthassak egy minőségi minimumot, persze ehhez az kell, hogy ne egy Weblapgyáros Kft-nél dolgozz.
Egyébként kaptam némi infót, miszerint a süti csak egy helyen szerepel GDPR-ban:
Eszerint az IP ismerete kvázi ekvivalens a sütihasználattal; ha pedig a user IP-jét csak az ő hozzájárulásával ismerheti egy szoftver, akkor nem is tud hova response-t küldeni, tehát be van tiltva maga az internet. :-D
Úgy tűnik az ügyvédnő kissé túllőtt a célon.
Valahol igazad van, de az
Szerintem arról szól a GDPR, hogy ezeket az azonosításra alkalmas információkat nem lehet titkosítatlanul tárolni, illetve a felhasználó engedélye nélkül felhasználni vagy eladni harmadik félnek ahogy a google és facebook most teszi. Elvileg náluk annyi lesz a hatása, hogy bele kell egyezned, hogy reklám célra felhasználhatják az adatokat, amiket rólad gyűjtenek. Plusz szigorúbban kell védeniük ezeket az adatokat, hogy ne kerülhessenek illetéktelen kezekbe. Valószínűleg ez azzal fog járni, hogy az ad service-ek a titkosítás miatt jóval nagyobb terhelést fognak a szerverekre róni, ami megemeli a reklámfelületek árait. A kisebb cégekre, pl webshopokra ez szerintem annyi hatással lesz, hogy azoknál is titkosítani kell a teljes profil oldalt, session azonosítókat, IP logokat, stb. Ha igazam van ezzel kapcsolatban, akkor szerintem pozitív a hozadéka a dolognak, főleg ha azt vesszük, hogy nap mint nap kerülnek hackerek kezébe teljes adatbázisok titkosítatlan jelszavakkal.
Hogyan?
Titkosított adatbázisrekordokban? A kulcsnak ott kell lennie a memóriában vagy a fájlrendszerben. Például a munkamenet fájlban, amihez hozzáférése van a webszervernek, azaz elvileg van lehetőség az egyik munkamenetből átnyúlni egy másikba.
Amennyit teszel érte
Nyilván ez nem jelenti azt, hogy egy havi pármilliós forgalmú webshopnak védettebb adatbázist kell kellene üzemeltetnie, mint mondjuk a CIA. :)
Az szerintem teljesen elfogadható szint már, hogy nem elég egyedül a db-det megtörni és megszerezni belőle az adatokat, hanem ezen kívül hozzá kell jutni forráskódhoz / más egyébhez ahhoz, hogy meg is tudják fejteni, hogy mi van benne. Ahhoz már 2 sikeres támadás kell különböző helyeken.
De amit Lacinak is jeleztem: nem hiszem, hogy innentől ne szabadna név szerinti ABC-ben felsorolni pl egy felhasználói csoport tagjait, csak azért, mert a név személyes adat és titkosítva van a db-ben.
Ugyanakkor sql injection ellen védettnek kell lenned.
Nem erről szól
Ha belegondolsz, ott lövöd magad tökön a keresést illetően.
Pl nem tudsz valakit a neve alapján megtalálni (Uram bocsá', email címe vagy TAJ szám alapján sem), mert ez mind - mind személyes adat, titkosítva van a db-ben, onnantól nincs
LIKE '%akármi%'.Az nyilvánvaló, hogy gugli / fb a "fő célpont", de egyelőre úgy látszik, hogy ahány olvasat, annyi értelmezés, a határidő pedig itt van a nyakunkon.
Pl nem tudsz valakit a neve
Ez így egyáltalán nem igaz. Vannak olyan adatbázisok, amik eleve titkosítottak. Ha meg fapadosan csinálod, akkor kénytelen leszel magadnak csinálni egy titkosított index-et a kereséshez. Szerintem az előbbivel van értelme egyébként, szóval hogy az érzékeny adatokat egy külön titkosított adatbázisban tárolod, figyelsz injectionre, és úgy tervezed a rendszert, hogy ha nem muszáj ne lehessen admin account lopással se mindent listázni és exportálni.
Egyébként én úgy határoztam meg volna a törvényt, hogy le legyen írva, hogy felhasználó számtól, vagy a tárolt adatok mennyiségétől, minőségétől függően mik a kötelező lépések. Mert ha tényleg csak ennyi van, hogy meg kell tenni mindent az adatok védelmében, az megint egy gumi törvény, amit egyik cégnél így alkalmaznak, a másiknál meg máshogy, attól függően, hogy ki mennyit fizet.
Hogyan?
A postgresql-nél például ezt írják:
Nem baj
Mindez csak értelmezés kérdése, azt akarod-e érteni, ami az adott mondatban van, amire az írója gondolt, vagy inkább azt, amire Te gondolsz / próbálsz "beleinjektálni".
Attól, hogy leírod, hogy a
OFF
Ugyanúgy kell, mint a kiflihez is kell a liszt, csak itt Inf3rno a kenyérről írt, nem a kifliről...
Mostanában már mindenbe belekötsz, valami baj van?
Nem vagyok annyira tájékozott
Egyébként azt mondják, hogy biztonság terén nem az van, hogy csak beleszórod a titkosítást, aztjóvan, hanem forgatókönyvekre kell felkészülni. Általában ezek a titkosítási módszerek az ellen védenek, hogy az adatbázis szerverről közvetlenül adatot lehessen lopni akár a fájlok lemásolásával, akár hálózaton keresztüli közvetlen eléréssel. Az oszlopok titkosításánál akár még SQL injection-ös lopás ellen is védhetnek, ha éppen nincs megadva az oszlopot feloldó kulcs vagy az alkalmazás oldja fel a titkosítást, nem az adatbázis. Ezen felül szükség van plusz védelemre, hogy az alkalmazáson keresztül se lehessen megszerezni a kulcsot.
Szvsz. mindenképp egy csomó plusz munkával fog járni ez az egész, ha valaki komolyan gondolja, hogy megvédi az adatokat.
Van még valami:
Ez alapján azt gondolom, hogy a jelenlegi egyfajta "próbatörvény", és a későbbi tapasztalatok alapján fogják finomítani, sajnos akár országonként másképp.
"Forgatókönyvekről" én is hallottam, de egyelőre semmit sem tudok róluk pontosan. Gondolom nálunk lesz néha "látogatóban" adatvédelmi biztos vagy ki, aztán majd mondja az okosságokat. :)
Tulképp ha belegondolsz
Csak hogy valami konkrétabb példát mondjak. "A támadó megszerezte Pistike felhasználói nevét, de nem tudja a jelszót, így elkezdi egy jelszó adatbázisból próbálgatni a jelszavakat. A rendszer ezt érzékeli, és 100 jelszó után zárolja Pistike fiókját, és küld egy levelet Pistikének, amivel fel tudja oldani a zárolást, amennyiben be kíván lépni." vagy "A támadó megszerezte Pistike felhasználói nevét és jelszavát, és a: külföldi IP-vel, b: egy ismert proxy szerveren keresztül próbál belépni Pistike nevében. A rendszer érzékeli, hogy valószínűleg nem Pistikéről van szó, zárolja a fiókot, és sikeres jelszó használat esetében törli Pistike kompromittálódott jelszavát is." Én ilyesmikre gondolnék, és akkor ezek még csak sebezhetőségeket sem tartalmaznak, hanem csak biztonsági feature-öket.
Talán a legegyszerűbb, ami programozó által elkövetett webes hibára épül, ha a belépett felhasználó GET-el tud valamilyen műveletet végezni, pl törölni vagy létrehozni. Ez elég gyakori hiba. Pl "GET /articles/12345/delete". Ilyenkor a támadó weboldalát miközben nézegeti, aközben az összes cikket tudják ajax-al vagy iframe-ből törölni a háttérben. Amennyire én tudom ez ellen CORS header sem véd, az XSS header-ekben nem vagyok biztos.
Persze,
Szerintem erre az aránylag kisebb forgalmú webshopok jó példák, mert van belőlük sok és alacsony a büdzséjük. Nem hinném, hogy a meglévő MySql adatbázisuk helyett kettőt és / vagy mást használnának a jövőben, és azt sem, hogy másképp betiltják a működtetésüket.
Mert van ezek között számos, ami egyáltalán nem érzékeny adat (pl TAJ szám), és sok, ami érzékeny (életkor, lakcím, stb).
Egyébként nálunk úgy tűnik, a hivatalos hozzáállás az, hogy a május után élesedő új projektek feleljenek meg, hogy pontosan minek és hogyan, az még nem teljesen tisztázott.. :-D
Rakd össze, ahogy akarod. :)
Hát majd idővel úgyis
Félreértettem
GDPR készlet
Kb. egy hónapja vettünk egy GDPR felkészítő készletet (nuce?). Egy csomó doksi, XLS, PDF, stb. MAGYARUL! :)
Viszonylag egyszerű leírás a folyamatról, tájékoztatók, táblázatok, adatkezelési nyilatkozatok.
JA! NEM template meg tartalomjegyzék, hanem korrekt teljes anyagok.
Hogy ez nem ránk lett szabva? Nem. De nem is annyiba került mint a testreszabott, tanácsadós változat. Neveket kellett kicserélni, és ha már belenyúltunk itt-ott igazítottunk is rajta a saját folyamatainknak megfelelően (mentések, BCP, stb.).
Volt vele meló, de belső erőkkel (ami így is, úgy is kell!) viszonylag gyorsan elég "jól nézünk ki".
Még egy felhasználói tréning anyag is van benne... :)
Mondom: elég jól állt az IT már előtte is (végpontvédelem, tűzfalak, jogosultságkezelés, titkosítás, stb.), a dokumentálás/adminisztráció hiányzott, + a GDPR specifikus nyilvántartások. Ebben qrva sokat segített!
Van még meló persze (pl. incidenskezelés/72 óra, DLP, stb.), de már nem a start mezőn ácsorgunk... :)
Biztos van még ilyen, de nekünk ez a metodika bejött.
GDPR konf
Session cookie
Érdekes. Mi a helyzet azzal,
Miután többekkel volt vitám,
Most ott tartok, hogy a világ kicsit átesett a póniló túloldalára és gyakorlatilag már azzal törvényt sértek, ha megnyitom egy user profiladatait egy fórumon.
És a legtöbb fórum is törvénysértést követ el azzal, hogy nem biztosítja a "felejtés jogát", magyarán ha valaki kéri, akkor sem törlik a korábbi hozzászólásait, habár maguk a kommentek is személyes adatok(!!! OMFG! )
Most ott tartok, hogy gyakorlatilag egy dologhoz van jogom, ha nem akarok interakciót a netes felhasználókkal (mert pl. csak statisztikát készítenék kommentekből): hallgatni és nem csinálni semmit...
Jól látom?
nem.
Bíztam benne, hogy1.
1. Érzékelhető az irónia
2. Az is, hogy kicsit bővebb válaszra vártam, feltéve, hogy pár órája nem téged küldtelek el a halál faszára. ;)
(Ha te voltál, az meg csak igazolja, hogy a nick nem köthető személyhez :D)
Az előző kommentben foglalt állítások eredete (pl az, hogy egy komment is személyes adat lehet) az angol nyelvű GDPR, az europe.eu oldalról azt hiszem.
A többi tőlem.
Iróniamentesen:
Keresem, mi a személyes adat. Sorolják a példákat. Köztük olyan példák, hogy "szubjektív információ is lehet személyes adar, például egy komment".
Említettem másik topikban, hogy milyen programot akartam készíteni: fórum által biztosított API segítségével letölteni kommenteket és azokban keresni. A gond ott indul, hogy az API úgy válaszol, hogy minden komment mellett ott a szerző profilja is, rengeteg adattal
Te mondtad a GDPR-t, mint egy potenciális buktatót.
Én úgy emlékeztem, hogy nick, x oldalon lévő profil nem személyes adat, de kiderült, hogy a jogászok szerint az is annak számít. Írtad az anonimizálást. Itt pl az a gond vele, hogy a keteső funkciók egy részét ellehetetleníti, ha GDPR-nek megfelelő az anonimitás. És akkor még erre jött a példában szereplő, komment is lehet(?) személyes adat...
Ott azért még nem tartunk
Nem is az volt a lényeg, hogy
Ha problémás a dolog akkor nem csinálom.
Eleve a Terms of Service is olyan, hogy bele lehet magyarázni, hogy tilos amit csinálni akartam. Meg az ellenkezőjét is.
Keresek más játékot, aztán el van intézve. A flask-ben már eljutottam a helloworldig... :)
Aztán majd jövök a CSS és JS problémákkal.
Nézd volt pont ilyen példa,
Hogy érted, hogy jutok
A letöltés/adatbázis építés terén vagy a jogi vonatkozások terén?
Mert az előbbi az egy nagyon egyszerű, mondhatni primitív feladvány, gyakorlott programozónak úgy két órányi munka, ha doksit is kell olvasni. :)
(https://en.wikipedia.org/wiki/2012_LinkedIn_hack - erre gondoltál, ha jól sejtem)
A jogi vonatkozások terén.
Akkor még keresek, mert
Tavaly volt talán, de nincs