Főoldal

"Mérnököt a mérnöktől"

A Schönherz Bázis összeköti az állást kereső és állást kínáló mérnököket.

CV küldés

Küldj önéletrajzot! Gyorsan, egyszerűen.
Megjegyzésbe írd be a pozíció nevét.
CV küldés

Iratkozz fel hírlevelünkre!

Kövess minket!

Kövess minket!

Hírek

Strukturálatlan adatok vs. személyes információk
Strukturálatlan adatok vs. személyes információk

Manapság a csapból is a GDPR folyik, mindennap emlékeztetve arra, hogy mennyi személyes információ is van szétszóródva rólunk az adatbázisokban. De ezúttal átállunk a másik oldalra és nem a felhasználóként vizsgáljuk meg a dolgot; lássuk mire kell és mire érdemes odafigyelnünk. 


A relációs adatbázisaink ellenőrzési folyamata tipikusan az adatbázissémák előszedésének, és a struktúrák átvizsgálásának folyamatából áll, hogy biztosan ne létezhessen észrevétlen oszlop, mely személyes jellegű adatokat – rövidítve PI -  szállíthat. Bizonyosodjunk meg róla, hogy megfelelő eszközeink vannak ezek megkeresésére és kiiktatására, vagy ami még jobb, az ezeket létrehozó forrás megtalálására.

De 2018-at írunk, és az egyetlen ismert dolog, ami megnehezíti a személyes információk lekövetésének folyamatát az adatbázisokban, az a strukturálatlan adatok használata, mint a JSON dokumentumokban.


A strukturálatlan dimenzió


Képzeljünk el például egy vevőnyilvántartó alkalmazást, mely naplózza a vásárló minden interakcióját az üzlettel. Az adatbázis ellenőrzésének első menete az egyértelmű információkkal fog kezdődni: nevek, címek, telefonszámok.

De ha strukturálatlan adatok nyomát lehet felfedezni, akkor még hosszú út áll előttünk. Ez nem csak a NoSQL, JSON dokumentumokat is tároló adatbázisokra vonatkozik. Strukturálatlan adatokat tárolhatunk még relációs adatbázisokban tömbökben, hashelve, vagy éppen akár JSON mezőkben is; ezek mind részei egy modern relációs adatbázisnak.

A strukturálatlan adatokkal az a probléma, hogy az erősségük és rugalmasságuk egyben azt is jelenti, hogy a személyes adatok bárhol lehetnek a dokumentumban vagy bejegyzésben. És ez nem csak attól függ, hogy mostanában hogyan használtuk az adatokat.


A JSON tárolókban vagy adattípusokban, relációs tárolókban tartott dokumentumok tükrözik az összes, a rendszer teljes élettartama alatt őket ért változtatást. Például, a fentebb említett vevőnyilvántartó rendszerünk egyszer rögzíthette a bejövő hívások telefonszámát és idejét a vásárló fiókjához csatolt JSON dokumentumban. És bár az alkalmazás ezen funkcióját azóta nem használjuk, az egyes felhasználók dokumentumaiban még mindig léteznek ezek az adatok. (Mellékes megjegyzés, ez egy tökéletes emlékeztető arra, hogy tisztítsuk az adathalmazainkat, amikor kiszedünk funkciókat az alkalmazásainkból.)

Gyakran az ilyen elveszett adatok környezete sincs egyértelműen felcímkézve, szóval a JSON dokumentumok kulcsainak ellenőrzése nem lenne elég, hogy ezeket megtaláljuk. Valószínűleg adattípus-specifikusan kell majd ezekre az értékekre keresni, és így lehet majd őket megtalálni.


A többi személyes adat

Ezen kívül találhatunk még személyes információkat csatolmányokban is. Figyeljünk oda a képfájlokra, mert ezek nehezen feldolgozhatóak, de hordozhatnak PI-t, ha tartalmaznak védett információkat.

És ha a JSON dokumentumok és csatolmányok még mindig nem elegek, vegyünk számításba egy Redis adatbázist perzisztens cache-ként használva a felhasználói adatoknak. Ezzel az eshetőséggel a tároló összes értékét át kell kutatni, ha azt gondoljuk, hogy odakerülhetett a cache folyamat részeként.

De emellett lehet, hogy váratlan helyeken is keresnünk kell, hogy megtaláljuk az összes személyes adatot; például a kulcs/érték hozzárendelésekben a kulcsok is hordozhatnak személyes adatokat. Ami egyszer felhasználónév volt az adatok hozzárendelésére, email címmé vált, amikor a fejlesztők finomították az emberek interakcióját a rendszerrel. Így most vannak email címek az adatbázis kulcsaiban. Ily módon keletkezik a beágyazott PI.

Ez az egész a szöveges mezőkben és JSON dokumentumokban folytatott rendkívül komplex keresésekre összpontosít. Komplex, és valószínűsíthetően index nélküli keresésekre. És ezek olyan típusú kérdések, melyek igazán megzavarhatják a production adatbázisokat.


A visszaállított backup lényege


Ennek egy ideális megoldása lenne, ha egy duplikált adatbázisszerverünk lenne, amin a PI ellenőrzést futtatjuk, és ahol az összes PI incidenst számon lehet tartani, melyet a komplex keresések megtalálnak, anélkül, hogy fölös terhet rónánk a production adatbázisra. Természetesen a legtöbb ember nem állít be tökéletesen párhuzamos adatbázis klónt; ennek egy másik módja, hogy csinálunk egy friss backupot, és azt állítjuk vissza az adatbázis új példányába.

A compose felhasználói hasznát vehetik a visszaállított mentéseinknek új deployment készítésénél, feltöltve az adataikkal egy kiválasztott ütemezett vagy igény szerinti backupból. Ez szinte azonnal automatikusan felkerül és futni fog, és máris végezhetjük a PI ellenőrzést, megtalálhatjuk a problémás adatokat és kidolgozhatunk egy tervet a production adatbázis frissítésére. És amikor végeztünk, törölhetjük is az új deploymentet, és csak azt a pár órát vagy napot kell kifizetnünk, ameddig létezett.


Tanulandó leckék


Bár a strukturálatlan adatok használata egy áldás lehet bizonyos felhasználók számára és egy új alkalmazás gyors fejlesztése során, ugyanakkor felelősséggel is jár. Visszamenőleg tudnod kell, mik a személyes adatok az alkalmazásodban és a strukturálatlan mezőkben, hogy utána jelenteni tudj róla.

Előre tekintve pedig tudnunk kell, hogy számolunk a személyes adatok használatával vagy jelenlétével az adatbázisainkban és a folyamatok során. Egy könnyen kettőzhető adatbázis fenntartása csak egy taktika, melyet alkalmazhatunk, hogy biztosak lehessünk benne, ez mind nem megy a teljesítmény rovására.


(Forrás)


Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minõségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen.
Gyere, nézz szét aktuális állásaink között!