ugrás a tartalomhoz

GDPR?

T.G · Feb. 14. (Sze), 13.16
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
 
1

2. egész jó

Pepita · Feb. 14. (Sze), 16.22
Én fontosnak érzem, annál is inkább, mert törvény (lesz belőle), de arról pl semmi infóm nincs, hogy mennyire fogják (tudni) ellenőrizni.
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.
12

Belenéztem a MS-os linkbe, de

inf3rno · Feb. 15. (Cs), 17.25
Belenéztem a MS-os linkbe, de nem tűnik annyira durvának, amiket írnak. Amúgy ez az egy helyen tárolás honnan jött? Backup-ot csak csináltok róla, akkor meg az már két hely...
13

Nem backup

Pepita · Feb. 15. (Cs), 18.03
Tegyük fel, hogy van egy központi portálod, ahol van felhasználó kezelés és személyes adatok is. (mindegy, hogy mit csinálnak ott.)
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".
15

Ez olyan DDD-sen hangzik, ott

inf3rno · Feb. 15. (Cs), 19.35
Ez olyan DDD-sen hangzik, ott szokták duplikálni az adatot, mert két kicsit eltérő domain van. Pl a security-s résznél, ahol reggelnek User az entity a webshop-oknál meg már Customer. Ja amúgy ez a best practice jelenleg. Szvsz. valami olyasmivel tudnátok megoldani, mint amit a facebook csinál a 3rd party appoknál. Amikor először belépnek a webshopba, akkor feljön egy ablak, hogy engedélyezi az email cím, név, stb. adatok átadását a webshopnak. Aztán amíg nem okézza le, addig nem léphet tovább. Technikailag ezt ők valami oauth-hoz hasonló rendszerrel oldják meg, szóval a beléptetés gyakorlatilag a főoldalon megy, az app meg csak annyit lát az adatokból, amennyit a felhasználó engedélyez neki. Én ilyen irányba mennék el, ha ez szempont, nézz utána az OAuth2-nek. link
17

Megfogtál :)

Pepita · Feb. 15. (Cs), 21.39
Bárhogy is erőltetem a fáradt agyam, most nagyon nem ugrik be, mi az a DDD. :-D (<- ez utóbbi itt egy kettőspont, egy vonal, és egyetlen dé)

Ez az OAuth2 gyakorlatilag ugyanaz / ugyanolyan, mint a guglis OAuth 2.0? Mert utóbbihoz volt már szerencsém.
20

Ja, ugyanaz. A DDD

inf3rno · Feb. 17. (Szo), 01.31
Ja, ugyanaz.

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.
2

Szia T.G.! Mi orvosi

tisch.david · Feb. 14. (Sze), 17.07
Szia T.G.!

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
5

Én úgy tudom orvosi témában

inf3rno · Feb. 14. (Sze), 20.37
Én úgy tudom orvosi témában loggolni kell, hogy ki mikor fért hozzá milyen adathoz. Szóval ha egy orvos beleolvas egy páciens adatlapjába, akkor annak nyoma kell, hogy legyen. Azt hiszem attribute based access control kapcsán is olvastam, hogy mennyire jó az a megközelítés orvosi témában, de már nem tudom, hogy az ezer közül melyik cikk volt az. Nagyjából itt ki is merül a tudásom, de egyébként érdekes témakör, majd később végigolvasom.
3

Süti engedély visszavonása?

T.G · Feb. 14. (Sze), 19.47
Sziasztok! Köszönöm a fenti kettőt! És remélem jön még további okosság! :)

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?
4

Itt szerintem van hiba

Pepita · Feb. 14. (Sze), 20.32
Eddig ez szűken volt szabályozva, az új rendelet azonban sokkal szélesebb körre terjeszti ki. Mostantól gyakorlatilag minden, ami alapján az illető beazonosítható személyes adatnak számít: név, cím, email, telefon, IP, cookie ID vagy bármilyen más online azonosító
A kiemelt rész szerintem tévedés, mert az IP, süti, hasonlók leginkább a klienst képes valamennyire beazonosítani, de nem a konkrét személyt, aki a gép előtt ül.
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. :)
Amíg az nincs leokézva, addig valóban nem használtok sütit
De. Csak a szövegben az van (kijelentő módban!), hogy "használunk sütit, és ha nézegetsz minket, akkor ezzel beleegyeztél PONT". Csak a "leokézta" sütit nem kapja meg addig, amíg "meg nem értette".
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.
És van-e lehetőség ezt visszavonni?
Jelenleg én nem tudok ilyen oldalról, hogy lenne, olyan biztosan nincs, amelyik fejlesztésében részt is veszek / vettem.
Vagy nincs is kint? :)
Sajnos ilyen is van.. (Nem nekem, de láttam ilyet sokat)

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. :)

Nálatok mi a helyzet?
Nálam az, hogy munkahelyen nem én döntöm el, hogy mit fogunk tenni, csak javaslatot teszek rá, az egyetlen hobby projektemben pedig most agyalhatok rendesen, hogy hogy oldjam meg, mert session-ös...
7

Cookie?

T.G · Feb. 15. (Cs), 09.09
Bevallom ez a sütis dolog nekem már a legelején is értelmetlen volt. :) Ám, ha úgy van, ahogy mondod, hogy csak figyelmeztetni kell, és leokézás nélkül is használhatok sütit, akkor pontosan mi haszna van a visszavonásnak? Mert akkor csak azt vonom vissza, hogy szeretném továbbra is látni a süti figyelmeztetést. Nem tudom, hogy mi volt a jogalkotók szándéka, de ennek így sok értelme nincsen. A fenti leírásban azt tartom a legfurcsábbnak, hogy szerintük a Google Analytics-et használóknak nincs teendőjük. Az én sütim aztán semmit nem tud szerencsétlen juzerről, miközben a Google olyan pontos felhasználói profilt épít ki, hogy lassan jobban ismeri a felhasználót mint a saját anyja. Ám arról nem kell figyelmeztetni a juzer-t, hogy ez is olyan honlap, ahol a Google is követ téged?! Na mindegy, ez egy másik fórumtéma... :)
9

Különböző dolgok!

Pepita · Feb. 15. (Cs), 11.36
akkor pontosan mi haszna van a visszavonásnak?
Múlt és jelen (jövő).
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

szerintük a Google Analytics-et használóknak nincs teendőjük
Azt elég valószínűnek tartom, hogy a süti az süti, tök mindegy, hogy gugli tette oda vagy te.
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.
8

Nincs hiba... :(

T.G · Feb. 15. (Cs), 09.09
És, akkor még egy link: https://7blog.hu/gdpr/

A GDPR szerint a süti-azonosítók alkalmasak a természetes személyek azonosítására, így kiterjed rájuk a GDPR hatálya.


Illetve.

A süti-sávról, azaz a „cookie-k”-ról ezért egyértelmű és pontos tájékoztatást kell adni az oldal adatvédelmi tájékoztatójában, és a felhasználónak kifejezetten és egyértelműen hozzá is kell járulnia ahhoz, hogy az oldal cookie-kat használjon. Sőt, lehetőséget kell adni neki arra is, hogy megváltoztassa döntését, azaz egy ponton úgy döntsön, a továbbiakban nem járul hozzá a cookie-k alkalmazásához.


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...

Célszerű a weboldal készítését megelőzően a készítővel olyan szerződést kötni, amely tartalmazza, hogy a készítő vállalja a felelősséget a weboldal GDPR-megfelelésére.
10

Nyilván

Pepita · Feb. 15. (Cs), 11.45
Nyilván, mint eddig is annyiszor, a jogalkotóknak fogalmuk sincs arról, hogy jelenleg mi hogy műxik a weboldalakon... :(

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.
11

Valószínűleg nem a webshopra,

inf3rno · Feb. 15. (Cs), 11.55
Valószínűleg nem a webshopra, hanem a fb, google szintű cégekre hegyezték ezt ki, mert a legtöbbje abból él, hogy információkat gyűjt az emberekről. Technikailag nem tudom hogy lesz megvalósítható a dolog, de egyelőre még az sem derült ki, hogy mit kellene megvalósítani, szóval a hogyan még nagyon messze van.
14

Törvény hatálya

Pepita · Feb. 15. (Cs), 18.07
Szerinted hoz olyan törvényt az EU, amit a fb és gugli be kell, hogy tartson, másra pedig nem vonatkozik?
Érdekes lenne! :-D
16

Nem azt mondtam, hogy másra

inf3rno · Feb. 15. (Cs), 19.43
Nem azt mondtam, hogy másra nem vonatkozik, hanem azt, hogy nem azért hozták, hogy a kis oldalakat szivassák vele, az csak mellékhatás. Egyébként nekünk jó, mert egy csomó jelenlegi oldalt át kell írni majd, hogy megfeleljen a törvénynek, úgyhogy munka az lesz elég. :-)
18

"csak"

Pepita · Feb. 15. (Cs), 21.45
Az a "csak mellékhatás" szerintem elég erős kicsinyítőképző, az oldalak többsége alól kirántják a session-t (is)...

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.
19

Ez az előnye a vállalkozói

inf3rno · Feb. 17. (Szo), 01.21
Ez az előnye a vállalkozói létnek, hogy nem kell mindent elvállalni. Te meg egy idő után majd belejössz :D
21

Nem - nem :)

Pepita · Feb. 19. (H), 11.03
kb 13 évig volt saját cégem, és ez csak az egyik fele az igazságnak, hogy
nem kell mindent elvállalni
Mindjárt tegyük is hozzá a másik felét: bármikor szabad éhen halni.

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:
A természetes személyek összefüggésbe hozhatók az általuk használt készülékek, alkalmazások, eszközök és protokollok által rendelkezésre bocsátott online azonosítókkal, például IP-címekkel és cookie-azonosítókkal, valamint egyéb azonosítókkal, például rádiófrekvenciás azonosító címkékkel.

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.
22

Valahol igazad van, de az

inf3rno · Feb. 19. (H), 11.45
Valahol igazad van, de az éhenhalásnál az se jobb, ha Pistike munkáját tákolgatod olyan órabérért, ami kevesebb, mint amit szórólapozással lehet keresni.

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.
23

Hogyan?

Hidvégi Gábor · Feb. 19. (H), 13.10
Hogyan tárolod titkosítva ezeket az adatokat? Titkosított fájlrendszerben? A kiolvasáshoz szükséges kulcsnak valahol ott kell lennie a memóriában, úgyhogy ha lyukas az alkalmazásod, ehhez is hozzáférhetnek.

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.
25

Amennyit teszel érte

Pepita · Feb. 19. (H), 15.13
Nyilván egy jelszó jellegű adatot visszafejthetetlenül "titkosítva" mentesz el, ezen kívül igazából (amennyire én tudom) nincs meghatározva, hogy pontosan miket kell megtenni a cél érdekében, a lényeg ott van, hogy a "Pistike letöltött innen - onnan szkript" nem elég. Meg kell tenni minden épeszű és kifizethető lépést azért, hogy a személyes adatok ne kerülhessenek illetéktelen kezekbe.
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.
24

Nem erről szól

Pepita · Feb. 19. (H), 15.05
ezeket az azonosításra alkalmas információkat nem lehet titkosítatlanul tárolni
Én ilyenről nem tudok, hogy bármit kötelező lenne titkosítani illetve meghatároznák, hogy hogyan.
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.
26

Pl nem tudsz valakit a neve

inf3rno · Feb. 19. (H), 22.26
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%'.


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.
27

Hogyan?

Hidvégi Gábor · Feb. 20. (K), 09.10
Melyek azok az eleve titkosított adatbázisok? A titkosításhoz használt kulcsnak valahol ott kell lennie a memóriában ahhoz, hogy ehhez az adatbázishoz hozzáférj. Mivel keresni kell benne, ezért már van potenciális lehetőség az injektálásra.

A postgresql-nél például ezt írják:
The pgcrypto module allows certain fields to be stored encrypted. This is useful if only some of the data is sensitive. The client supplies the decryption key and the data is decrypted on the server and then sent to the client.


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
A nem érzékeny adatokat tartalmazó adatbázisnál nem kell figyelni az injektálásra?
29

Nem baj

Pepita · Feb. 20. (K), 10.30
A titkosításhoz használt kulcsnak valahol ott kell lennie a memóriában
Nem baj. Ha már egyszerre két dolgot kell megtörni ahhoz, hogy valós adathoz jusson a hacker, Te már eleget tettél. Nyilván akkor, ha ez a két dolog valóban független egymástól. Egyszer hozzáférést kell szerezzen a db szerveredhez, másodszor meg kell szereznie a kulcsot. Nyilván ezeket azért ne lehessen egyszerű http request-ekkel megszerezni.. :)

A nem érzékeny adatokat tartalmazó adatbázisnál nem kell figyelni az injektálásra?
Dehogynem. Attól, hogy leírod, hogy a kenyérsütéshez liszt is kell, még nem jelenti azt, hogy azt állítottad volna, hogy a kiflihez nem kell liszt, igaz?
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".
30

Attól, hogy leírod, hogy a

Hidvégi Gábor · Feb. 20. (K), 10.45
Attól, hogy leírod, hogy a kenyérsütéshez liszt is kell, még nem jelenti azt, hogy azt állítottad volna, hogy a kiflihez nem kell liszt, igaz?
A pékáruk készítéséhez liszt kell. Ezért az nem érv, hogy kenyérsütésnél valaki felsorolja, hogy lisztet fontos beletenni, mert ezzel semmi újat nem mond.

azt akarod-e érteni, ami az adott mondatban van, amire az írója gondolt
Nem tudom, hogy mire gondolt, csak azt látom, amit írt. Te tudod, hogy mire gondolt? Belelátsz a fejébe?
31

OFF

Pepita · Feb. 20. (K), 12.53
Gábor, ez itt megint parttalan, Te kérdeztél rá, hogy nem személyes adatnál szükségtelen-e injection ellen védekezni...
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?
34

Nem vagyok annyira tájékozott

inf3rno · Feb. 20. (K), 15.03
Nem vagyok annyira tájékozott a témában. Egyébként változó, ahogy nézem PgSQL-nél csak bizonyos oszlopokat lehet lekódolni, aztán a kliens adja a kulcsot ezekhez az oszlopokhoz és a szerver oldja fel a titkosítást. link A MySQL-nél van titkosítás a teljes adatbázisra, viszont nekem úgy tűnik, hogy csak az enterprise edition-nél. link Amit feldob a google, mint ingyenes megoldást az a ZeroDB. link

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.
36

Van még valami:

Pepita · Feb. 21. (Sze), 10.24
az új rendszer szerint - ha jól tudom - nem kell majd magát az adatkezelést külön bejelenteni - papírozni (gondolom eddig se sokan tették), viszont a bármiféle incidenst igen, a sikertelen törést is, ha az egyértelműen adatlopásra irányult.

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. :)
37

Tulképp ha belegondolsz

inf3rno · Feb. 21. (Sze), 12.12
Tulképp ha belegondolsz tesztelésnél is vannak forgatókönyvek amikre tesztelsz, pl "Béla berakja a kosárba az új ütvefúróját, ilyenkor frissülni kell a kosárba rakott termékek számának és össz értékének". Itt is ugyanígy vannak forgatókönyvek, amikre tesztet kell írni, pl "A támadó xy módszerrel próbál admin jogosultságot szerezni, ilyenkor a rendszer z lépéssel kivédi ezt, loggolja a támadást és értesíti email-ben vagy sms-ben az üzemeltetőt." Én valami ilyesmi automatikus tesztekre gondolnék, amiket lehetne írni a biztonság ellenőrzésére. Viszont ehhez ismerni kell a támadási módokat. Magát a támadást szerintem nem is kell végigvinni, elég ha odáig jutunk, hogy kiderül, hogy egy ponton SQL injektálható a rendszer. Ehhez mondjuk az összes szóba jöhető pontot be kell járni. Azt hiszem ilyesmi célokra vannak automatizált eszközök. Egyébként van ismerősöm, aki ilyen auditokat csinál, de mélyebben én sem vagyok otthon a témában. Amúgy a forgatókönyv kezdődhet úgy is, hogy "egy dühös elbocsátott alkalmazott". Ránézésre sok cikk ebben a témában hibás, mert nem tesztel egy adott sebezhetőségre, csak azt mondja, hogy hogyan kell védekezni ellene. Ez így nem jó, mert bármikor elfelejthetsz egy beállítást ugyanúgy, ahogy kódnál bármikor elírhatsz valamit. Az utóbbinál a tesztek jelzik, hogy nincs rendesen megvalósítva a feature. Bár jóval melósabb, de én ezt a megközelítést javaslom legalább olyan szintig, hogy egy-egy sebezhetőségre tesztelsz.

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.
28

Persze,

Pepita · Feb. 20. (K), 10.21
de azért maradjunk egy kicsit a Földön is, legalábbis ami a meglévő oldalakat / rendszereket illeti.
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.

é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
Én meg úgy, hogy mennyiségtől nem függ, de konkretizálva a személyes adatok is, hogy melyik személyes adatot pontosan hogyan kell / lehet kezelni.
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).

az megint egy gumi törvény
Szerintem is, ezért is várom meg saját projektnél, hogy mi lesz a folyomány, jelenleg ahány vélemény, annyi féle.
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. :)
33

Hát majd idővel úgyis

inf3rno · Feb. 20. (K), 14.29
Hát majd idővel úgyis kiderül. Mondjuk elég szar, ha lefejlesztesz valamit, aztán utána kitalálják, hogy nulláról írd újra, mert csak.
35

Félreértettem

Hidvégi Gábor · Feb. 20. (K), 15.12
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
Ezt a mondatodat félreértettem, ezért az előző hozzászólásomban feltett kérdésnek nincs értelme.
6

GDPR készlet

JKov · Feb. 14. (Sze), 20.53
Mi kb. 34-35-en vagyunk, alapvetően B2B tanácsadási üzlet és a folyamataink egyszerűek (l.m. "faék"). Viszonylag kevés személyes adat kerül be hozzánk, viszonylag kevés rendszerbe (konkrétan Exchange, számlázó, CRM, +nem-strukturált Word/XLS/JPG/PDF/... adatok).
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.
32

GDPR konf

BlaZe · Feb. 20. (K), 14.05
Ha valaki szeret konferenciázni, itt van egy a témában :) Nem egy kifli ára... ;)
38

Session cookie

T.G · Már. 1. (Cs), 09.19
Van néhány kivétel, így a session esetén nem kell engedélyt kérni: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
39

Érdekes. Mi a helyzet azzal,

inf3rno · Már. 1. (Cs), 17.03
Érdekes. Mi a helyzet azzal, amikor js tárolja a credentialt és header-ben küldi?