Titkosítás
Sziasztok!
Van egy php-s program ami pár éve volt tervezve/fejlesztve és szeretnék GDPR kompatibilissé tenni, mert hiába minimalizálták a személyes adatok bekérését, nem elég.
Tényállás :)
A helyzet az hogy a cégen belüli (partneri és személyzeti) adatokat tárolják ebben a programban (napi kereshetőség/felhasználás végett), de vannak magánszemélyek és cégek is, na most a magánszemély adatai azok (jobban) szentek ugyebár.
A kérdés:
Az igény az hogy az adatbázist olyan módon kell titkosítani hogy ellopása esetén (persze annak megnehezítése szintén terítéken van) minél nehezebben lehessen felhasználni bármire.
Nyilván a jelszavak hash-eltek (itt "megelégszünk" a password_hash függvénnyel default beállítással, de lehet még ezen lesz csavarás)
Az igazi kérdés az hogy a felismerhető és olvasható mezők (pl: email, text mezők amikben 300-500 karakteres személyes megjegyzések vannak, vagy csak simán a lakcím mezők) titkosítására elég-e a AES_ENCRYPT() függvény használata?
Illetve itt jönne még a személyes kérdésem: ezekben a mezőkben a keresés (ha már titkosítva vannak) nem lesz dög lassú? :)
Valaki megjárta már ezt az utat (akár GDPR specifikusan) vagy ismer olyan leírást/leírásokat amit akár Szent Grálnak lehet tekinteni a témába?
Előre is köszönöm a segítséget!
■ Van egy php-s program ami pár éve volt tervezve/fejlesztve és szeretnék GDPR kompatibilissé tenni, mert hiába minimalizálták a személyes adatok bekérését, nem elég.
Tényállás :)
A helyzet az hogy a cégen belüli (partneri és személyzeti) adatokat tárolják ebben a programban (napi kereshetőség/felhasználás végett), de vannak magánszemélyek és cégek is, na most a magánszemély adatai azok (jobban) szentek ugyebár.
A kérdés:
Az igény az hogy az adatbázist olyan módon kell titkosítani hogy ellopása esetén (persze annak megnehezítése szintén terítéken van) minél nehezebben lehessen felhasználni bármire.
Nyilván a jelszavak hash-eltek (itt "megelégszünk" a password_hash függvénnyel default beállítással, de lehet még ezen lesz csavarás)
Az igazi kérdés az hogy a felismerhető és olvasható mezők (pl: email, text mezők amikben 300-500 karakteres személyes megjegyzések vannak, vagy csak simán a lakcím mezők) titkosítására elég-e a AES_ENCRYPT() függvény használata?
Illetve itt jönne még a személyes kérdésem: ezekben a mezőkben a keresés (ha már titkosítva vannak) nem lesz dög lassú? :)
Valaki megjárta már ezt az utat (akár GDPR specifikusan) vagy ismer olyan leírást/leírásokat amit akár Szent Grálnak lehet tekinteni a témába?
Előre is köszönöm a segítséget!
Szia! A GDPR nem teszi
A GDPR nem teszi kötelezővé az elemi adatok titkos tárolását. A GDPR arról szól, hogy ha nem természetes személyes természetes személyek adatait kezelik, akkor az csak megfelelő tájékoztatás után, kifejezett jóváhagyással, jól körülhatárol és méltányolható célból, módon és ideig történhet, csak a legszükségesebb adatkörre szorítkozva, és ezekhez az adatokhoz senki másnak nem szabad hozzáférést adni az adat eredeti tulajdonosának hozzájárulása nélkül. Biztosítani kell az adatkezelés elleni tiltakozás és az adatkezelés megszüntetése kérésének lehetőségét, nyilvántartást kell vezetni az adatkezelési/feldolgozási tevékenységekről, és megfelelő oktatással biztosítani kell, hogy minden olyan személy, aki az adatokhoz hozzáfér, azt jogosan és célhoz kötötten tehesse csak meg, a fenti szemléletet betartva.
Konyha nyelven kb. ennyiről szól a GDPR.
Ha emellett a kor technikai megoldásait alkalmazva minden észszerű biztonsági intézkedést megtesztek a gép és az adatok fizikai védelme érdekében (riasztó, kulcsra zárt szerver szoba, jelszóval védett felhasználói fiók, esetleg titkosított adatpartíció, stb.), akkor megfeleltek a GDPR-nak.
Üdv:
Dávid
NAIH
Igen ezek ok, de pont a hangsúly az ésszerűn van és mivel van beépített függvény így annak a "beépítése" (ha jó lett volna) akkor elég ésszerű lenne, merthogy igazából ha gond van akkor a NAIH részéről az első kérdés az lenne hogy miért nem voltak titkosítva az adatok (amúgy meg álláfoglalásként is elhangzott ez részükről hogy ha már tárolni kell akkor alap a titkosítás).
Nem utolsó sorban, tényleg én mint magánszemély (vagy cég) is jobban örülnék ha titkosítva tárolják az adataim mert ellophatatlan online adat nincs, akkor már legalább legyen nehezen törhető.
Köszönöm
Ahogy nézem az AES_ENCRYPT
Egyébként nem tudod felindexelni titkosítva, úgyhogy nem lesz kereshető, hacsak nem úgy keresed, hogy minden egyes mezőt kikódolsz hozzá, ami nem lesz gyors...
Jobban jársz, ha Dávid tanácsát követed, és nem lősz túl a célon.
Ajánlás
De akkor mi lenne erre a jó, megoldás (és most bármilyen megoldás érdekelne) mert nyilván nem olyan titkosításra/megoldásra gondoltam amit a google is megirigyelne, hanem ami legalább minimálisan is, de nem celartext-ként tárol.
Természetesen ha nincs elengedem a témát, de az ötlet maga szerintem már nem kellene hogy probléma legyen úgy hogy évente több milliárd e-mail címet (és ki tudja még hogy mit) szereznek adatbázisokból.
Itt jön a kérdésem hogy ilyenkor legalább az e-mail címeket miért nem titkosítva tárolják?
Köszönöm
Ha ez a default ECB-n van,
Ezen felül gondolom egy kulcsot akarsz használni az egész adatbázisban, amihez jó lenne ha felhasználónként külön random init vector lenne, vagy akár mezőnként.
Ha keresni akarod, akkor ki kell kódolni az összeset, ami problémás pl email címes belépésnél, ha az email címet is titkosítani akarod. Esetleg lehetne azt is hashelni még egy mezőbe ugyanúgy, ahogy a jelszót, úgy gyorsabban rá tudnál keresni beléptetésnél.
A kulcs random 128 bit, azt írja a dokumentáció, hogy hexadecimálisan szövegként érdemes átadni a mysql-nek a php-ből, aztán unhex-el binárisra lehet alakítani. A tárolása már érdekesebb, ami biztos, hogy nem szabad a kóddal együtt verziózni, és hogy nem lehet benne az adatbázisban. Olvass utána a témának, aztán meglátod neked milyen megoldás jön be a legjobban. Esetleg érdemes lehet arra is kidolgozni valami forgatókönyvet, hogy hogyan változtatjátok meg a kulcsot, ha arra szükség van, pl kitudódik a régi kulcs. Ahhoz ki kell kódolni minden adatot, aztán újra lekódolni egy új kulccsal.
Szerintem ez így rendben lenne, de én sem értek hozzá csak minimálisan.
Addig
Azt hiszem pgsql-nél egy
Kulcs tárolása
Felhasználónkénti kulcs csak
LUKS nem jó e célra? (Úgy
A titkosított diszkhez/image-hez több jelszót, kulcsfile-t is hozzá lehet rendelni.
Na de
Amennyire a többi is. :) De
De én inf3rno saját problémájára írtam, mint lehetőséget, mert azzal lehet olyat, hogy több különböző jelszó tudja "nyitni" a titkosított diszket.
LUKS helyett inkább a ZFS
Hogy a kedves felhasználók ne
De mind1.
Ui: sejtem, hogy miről beszélsz, de e célra valami olyasmit tudnék elképzelni amit írtam: titkosított image file, erre szerintem a luks a legegyszerűbb, oda úgysem kell raid, az legyen a fizikai adathordozón.
Hogy a kedves felhasználók ne
Kétlem, hogy az ilyen megkötések működnének, ha valaki mondjuk pendrive-ról bebootol és mountolja a titkosított meghajtót. De aztán persze lehet, hogy hülye vagyok a témához, és neked van igazad. :D Amit tudok, hogy Windows-nál gond nélkül bebootolok, és megnézem, hogy milyen fájlok vannak bármelyik meghajtón. Ha ez megtörténne és a meghajtótitkosítás kulcsa is megvan valakinek, akkor is van még egy réteg titkosítás a felhasználók személyes dolgain, amit csak ők tudnak feloldani a jelszavukkal. Ez azért jelent némi nehézséget, mert feltűnő, ha a jelszavak megszerzése miatt megpróbálják módosítani a szerveren futó kódot, ha backupról van szó, akkor meg erre esélyük sincsen. Persze elismerem, hogy ez se egy olyan forgatókönyv, ami úgy általában megesik, azért mondtam, hogy erősen túllőttem a célon...
Végig olvastad amit írtam?
Mondom: értem, mit akarsz (nagyjából), ehhez linuxon titkosított konténerfájlokkal szórakoznék, nem külön fájlrendszerrel. (csak kicsit felületesnek tűnt a fogalmazásod, erre próbltam némi ironikus mellébeszéléssel célozni)
Ja ok. Ezek szerint az
Na de a KDF
jaaaaaajdebonyolúúúúúlt :(
Felesleges ezen agyalnod,
- SQL injection - ma már alap kivédeni, de ha mégis valahogy sikerül megcsinálniuk, akkor sincs meg a kulcs, mert PHP-ben tárolod. Ma már annyira nem jellemző.
- PHP injection - elég súlyos sebezhetőség kell hozzá, pl eval használata user inputra, de ha mégis képesek rá, akkor megszerzik a kulcsot is, nem csak az adatbázist, úgyhogy bukó, tökmindegy mit csinálsz. Ritka.
- Az üzemeltető lopja el a kódot és az adatbázist - szintén bukó. Ritka.
- Valaki lenyúlja az adatbázis backupját - ha a PHP kódban van a kulcs, és nincs együtt tárolva a backup-al, akkor nem tud mit kezdeni a titkosított adatokkal. Előfordulhat.
Ez alapján nem látom túl sok értelmét titkosítani az adatokat. Jobb inkább az SQL injection-re és a PHP eval injection-re figyelni, illetve a backup-ot olyan helyre tenni, ahol nem fér hozzá bárki. Persze lehet, hogy van valami ésszerű forgatókönyv, hogy hogyan lopják el nagy valószínűséggel a teljes adatbázisodat. Hallgatlak.
-
Ajjaj
1. nem érted / értitek, hogy mire irányul a GDPR, mi az alapvető célja
2. még nálam is kevesebb tapasztalatod van biztonság és titkosítás terén, és nincs melletted biztonsági szakértő (megj.: valójában nem mondanám kevésnek, amennyit én foglalkozom napi szinten a témával és mondhatni értek is hozzá, de számomra biztonságérzetet ad, ha egy "csinos" célösszegért megbízott etikus hacker rendszeresen megpróbálja megtörni a rendszert, amit fejlesztek (előző munkahelyem), vagy van a cégnél "hivatásos" IT biztonsági csapat (jelenleg), akik ugyanezt munkaköri kötelességként végzik, és komoly dokumentációkat "publikálnak" róla).
1-et Dávid elég jól leírta "konyhanyelven", annyit tennék hozzá, hogy az alapvető cél az, hogy megakadályozzák / korlátok közé szorítsák az adathalászatot. Itt megjegyzem, hogy pl a CIB bank (ez itt az antireklám helye!) a PSD2 előírásait "meglovagolva" csak és kizárólag úgy biztosít a lakossági ügyfelei számára netbankos szolgáltatást, ha azok legalább egy alkalommal hozzájárulnak a saját telefonjuk teljes contact-listájának és híváslistájának a CIB szerverére törénő szinkronizálásához (és a többség úgy is felejti az engedélyeket..). Ez lesz a következő NAIH-os ügyem.. :)
Nálunk (ITM / EMMI alá tartozó hivatal, pármillió magyar ember személyes adataival) az alapvető irányelvek alkalmazásfejlesztés terén:
- Személyes adat a hivatal összes szerverén és eszközén egyetlen(!) helyen és példányban tárolható
- Az egyes alkalmazások - jogosultság függvényében - ettől a központi rendszertől kérhetnek le személyes adatokat
- A hivatal összes szerverének / tárolókapacitásának (beleértve még a pandrive-okat is) titkosítottnak kell lennie
- Ha egy alkalmazásnak szüksége van személyes adat alapú keresésre (pl email cím alapján megtalálni természetes személyt), akkor vagy a központi rendszert használja keresésre, vagy ha ez nem megfelelő, akkor saját db-ben, szinkronizált, de hash-elt adatokkal dolgozhat (pl az ember neve stb titkosítva lekerül egy szinkron db-be, gyors és listázható eredményt ad, viszont csak teljes egyezésre lehet keresni, töredékre nem)
- Minden egyes (új) alkalmazásnak a legalapvetőbb "üzleti logikája" az, hogy "ki kit láthat". Tehát nincs olyan, hogy "tudok egy email címet, kapok egy egész embert". Olyan van, hogy adott logika szerint én láthatok az x millióból összesen 10000 embert, rákeresek a példa##kukac##example.com email címre, és az alkalmazás kiadja számomra azokat a találatokat, akik benne vannak ebben a 10000-ben...
Bár az eddigiek alapján gyanítom, hogy nem ezt vártad, viszont a Dávid pár mondatának a megértése sem megy, akkor nem tudom, hogy mi lehetne számodra használható.
Szerintem elsődlegesen a rendelet célját kell megérteni, utána érdemes a technikai megoldásokon gondolkodni.
Apropó, adatkezelési hozzájárulás, tájékoztatás, hozzájárulás visszavonása funkciók léteznek? Milyenek?
Ha nincs / nem jó, akkor azért fog rövid úton büntetni a NAIH, nem a "titkosítás" miatt.
Fentieket figyelembe véve (és azt, hogy rég lejárt a határidő), ezeket a (nem túl tetszetős) javaslatokat tudom tenni:
A.: Nagyon gyorsan fizikálisan törölni az összes személyes adatot, a rendszer működését megszüntetni, letagadni, hogy valaha is létezett (főleg akkor, ha az eddigi személyes adatok konkrét tevőleges hozzájárulás nélkül kerültek be).
B.: Megkérni a NAIH-ot egy ellenőrzésre (ez már pénzbe is kerül, de ha ti kéritek, remélhetőleg bünti nem lesz elsőre belőle)
C.: Nem csinálni semmit és remélni, hogy nem lesz baj (ebben az esetben ne tudjak konkrétumot a rendszerről, mert amibe beleakadok, és "nem tetszik", bizony kellően a NAIH figyelmébe ajánlom. :-D)
Még egy elég fontos dolog, sokan nem vagy rosszul értik:
adatkezelés !== adattárolás
Ezen nagyon sok megfelelni akaró cég elbukik.
Az adatkezelés az adat megjelenítése is! És baromira nem csak azt tudod megjeleníteni, ami nálad van tárolva!
A másik gyakori téveszme: adattárolás / rögzítés nem csak az adatbázisodra vonatkozik, hanem az összes email-fiókodra (többnyire fájl alapú, és ebben is szerepelnek nevek - email címek), de még a Manyika néni kockás füzete is ugyanilyen adatrögzítés!
Szóval nagyon meg kell gondolni, hogy mit, hol és hogyan tárolsz, mert az Ügyfélnek joga van kérni az összes személyes adatának törlését, és amennyiben ezt nem korlátozza más törvény (pl a kiállított számlát 5 évig eredeti adatokkal kell megőrizni), azt záros időn belül végre kell hajtani, még a Manyika néni kockás füzetében is.
Stílus
PoLP
Nem akarok spekulálni, de milyen esetet képzelünk el, ahol az egyes mezők titkosítása több védelmet jelent, mint a mezőszintű (vagy táblaszintű) jogosultságok? Feltételezek egy webshopot és egy hozzá tartozó admin felületet, ezek konfiguráción kívül (ami egy harmadik helyről kerül ki mindkét helyre) semmiben sem kell osztozzanak. Ha valaki saját kódot futtat a publikus felületeden, annak nem lesz meg a usernév/jelszó páros amivel olvasni képes személyes adatokat. (Az admin felületet kiszolgáló szerverhez - fizikai vagy VPS - tűzfallal letiltható hozzáférés a külvilágból).
A vas fizikai lopása ellen teljes lemez-titkosítást tudsz használni, ez standard mostanság. (Újraindítás után be kell majd gépelned a kódot).
És ami mindennél fontosabb: telepíts minden frissítést.
Akkor van értelme, ha a
E2E
Nem mondtam, hogy ilyet
Nem csap a villám kétszer
Szerintem simán jó lehet
Már majdnem új téma
Igazából nekem az tetszik rengeteg szolgáltatónál ha elfelejted a feloldó kulcsod (mint a merevlemeztitkosításnál), akkor maximum adatvesztésed van, de még a "gyártó/szolgáltató" sem fér hozzá olvasható formában az adatokhoz (és most feltételezzük hogy tényleg így van :) ).
Na engem ez érdekel a legjobban, hogy ha már valami tárolva van valahol és már mindent megtettünk, akkor ezzel még csavarjuk meg a bizalmat a felhasználóban hogy igazából maga a fejlesztő/üzemeltető sem fér hozzá az olvasható adatokhoz.
Ez csak olyan rendszernél
Igen, elvileg ez lenne a cél nagyon leegyszerűsítve
Nem is értem hogy ez hogyan működik másoknál, mert ugye egy jelszóval belépek és úgy hozzáférek az adataimhoz, de gondolom hogy nem a jelszavam a feloldólkulcs mivel ha változtatok akkor az összes titkosított adaton végig kellene mennie és "áttitkosítani". Legenerálnak egy feloldókulcsot és csak azt titkosítják a jelszavammal? Najó de belépés után mi történik? Csak nem tárolják sessionben a feloldókulcsot, mert az ugyanúgy problémás. Ezek hogy működnek? :)
Legenerálnak egy
Ja nagyjából így megy.
Minden kéréssel újra elküldik a jelszót. Nincs session meg belépés. A kliensen esetleg lehet imitálni.
Najó de
A böngészőben vagy az erre