Így kezelje tesztadatait!

Az alkalmazások teszteléséhez olyan adatokra van szükség, amelyek megfelelnek a biztonsági, adatvédelmi és megfelelőségi előírásoknak, miközben hasonlítanak az élesben használt adatokra is. A feladat nem egyszerű. Megmutatjuk, hogyan lehet erről úgy gondoskodni, hogy az minden követelménynek megfeleljen és menedzselésük se okozzon problémát.

A tesztadatmenedzsment (Test Data Management – TDM) azt jelenti, hogy segítségével akár automatizált módon olyan adatokat állítanak elő az adott alkalmazás teszteléséhez, amelyek mind formátumban, mind viselkedésben megfelelnek az éles működés során használt adatoknak, viszont valós adatokat nem tartalmaznak. Így a rendszerek és az alkalmazások fejlesztői és tesztelői biztonságosan futtathatják le a szükséges teszteket a problémák felderítésére, mielőtt új szoftvereiket vagy az alkalmazások legújabb kiadásait éles üzembe helyeznék.

Az ilyen tesztadatok létrehozásánál azonban felmerül két jelentős akadály. Egyrészt gyakran sokkal tovább tart a biztonságos és az előírásoknak megfelelő tesztadatbázis előállítása, mint maga a tesztelés. Másrészt pedig, ha nem megfelelően kezelik a tesztadatokat, akkor olyan fontos előírásokat is megsérthetnek, mint például a GDPR, ami tetemes büntetéssel járhat.

Ilyen jellegű incidens miatt legutóbb a British Airways 1,4 millió eurós, a Ticketmaster pedig 22 millió eurós bírságot fizetett, mivel nem védték megfelelően a felhasználóik adatait. Ezek a példák is alátámasztják, hogy a terület kiemelten fontos, és megfelelő óvatossággal kell kezelni. Azonban egy megfelelő eszköz nélkül rendkívül nehézkes és időigényes a megfelelő tesztadatok előállítása, melyeknek a biztonsági előírásoknak is meg kell felelniük. Ráadásul a tesztelőknek akár naponta többször kell frissíteniük vagy új elemeket kell hozzáadniuk a tesztadatbázishoz.

Előfordul, hogy alkalmanként a teszteléshez az adatbázis-kezelők vagy az IT-üzemeltető csapat egyszerűen másolatot készít az éles adatokról. Azonban ha ezek nincsenek anonimizálva, akkor a tesztelés során való felhasználásukkal megsértik a biztonsági előírásokat. Az is megesik, hogy a tesztelők vagy adatbázis-adminisztrátorok szkriptekkel anonimizálják az adatbázisból származó adatokat, ez azonban megváltoztathatja az adatok formátumát és értékét. Így az alkalmazás már nem feltétlenül képes azokat értelmezni, és a tesztelő sem tudja, hogy az adatok valóban úgy néznek-e ki, mint ahogyan egyébként az éles üzemben megtalálható. Például, ha a személyi igazolványok számait nem megfelelően anonimizálják, akkor megváltozhat a formátumuk, betűk kerülnek a számok helyére és fordítva, és így már nem biztos, hogy használhatóak maradnak a tesztelendő szoftver számára.

A tesztadatok megfelelő előállítása ugyanakkor valamilyen szinten mindegyik érintett fél feladatai közé tartozik, beleértve az üzemeltetőket, adatbázis-kezelőket, fejlesztőket és tesztelőket. Ezért olyan megoldást kell találni rá, amely mindenkinek megfelelő, miközben biztonságos és hatékony is.

A Micro Focus szakértői szerint a megfelelő tesztadatok előállításához 3+1 lépés elvégzése szükséges:

1. Védendő adatok feltérképezése

A feltérképezés az a folyamat, amely során egy dedikált eszközt, például a Voltage Structured Data Managert (SDM) csatlakoztatjuk az adatbázishoz, amely átvizsgálja az elemeket és beazonosítja az érzékeny információkat, például neveket, címeket és egyéb személyes adatokat. A megoldás pontszámot is hozzá tud rendelni az egyes elemekhez, amely a kockázati szintet jelöli ahhoz mérten, hogy mennyire számít szenzitívnek az adott adat. Ezt a folyamatot az üzemeltető csapatnak célszerű végrehajtani, hogy azonosítsa a lehetséges veszélyeket, javítsa a rálátást az adatokra, és csökkentse a kézi ellenőrzéssel járó hibák esélyét.

2. Védelmi módszer megtervezése

A Voltage SDM tartalmaz egy Designer segédprogramot, amellyel létrehozhatók a szabályok az adatok másolására, átalakítására, maszkolására vagy anonimizálására a formátummegőrző titkosítás (Format-Preserving Encryption, FPE) segítségével.

Ezt a folyamatot olyan szakembernek érdemes elvégeznie, aki jól ismeri az adatstruktúrát és az adatok közötti kapcsolatot, így például egy fejlesztőnek. Ez a tudás elengedhetetlen ahhoz, hogy teljes lehessen a teszteléshez használt adatkészlet. Nem sokat ér például az ügyféladatok anonimizálása, ha nem tudjuk bemásolni az adott ügyfélhez tartozó rendeléseket az adatkészletbe.

3. Tesztelési adattár exportálása

Ezt a feladatot az üzemeltetők végezhetik. A folyamat magában foglalja az éles rendszerhez történő csatlakozást, az adatok átalakítását vagy anonimizálását, majd felöltését a tesztkörnyezetbe. Ez egy köztes adatbázis, amely elválasztja az éles adatokat a tesztelőktől. Ezzel biztonságos, az előírásoknak megfelelő adatok hozhatók létre, amelyek úgy néz néznek ki és úgy is működnek, mint az élesben használt adatok. Az adatfrissítés megismételhető olyan időközönként, amilyen gyakran szükség van rá a vállalatnál. Az adatok másolatát ráadásul adatelemzők is használhatják biztonságos elemzéshez vagy éppen különféle statisztikák előállításához, mivel a formátummegőrző titkosítás biztosítja a konzisztenciát.

4. Engedélyek elkülönítése (opcionális)

Az IT-üzemeltetési csapaton belül elkülöníthetők a felelősségek a biztonság és a megfelelőség terén. Így kiadhatók úgy az engedélyek, hogy csak bizonyos felhasználók tudják elvégezni a feltérképezést és ellenőrzést, és mások tudják létrehozni a tesztadatbázist. Ez egy plusz biztonsági szintet jelent arra az esetre, ha egy rosszindulatú alkalmazott vagy alvállalkozó szeretne visszaélni az adatokkal. A módszerre nem minden esetben van feltétlenül szükség, de hasznos lehet, ha kiemelten érzékeny adatokkal dolgozunk.

A Micro Focus eszköze egy olyan modult is tartalmaz, amelynek segítségével maguk a tesztelők végezhetik automatizáltan a tesztadatok frissítését naponta akár többször is biztonságos és az előírásoknak megfelelő módon anélkül, hogy az adatbázis adminisztrátorokat vagy az üzemeltetőket kellene bevonniuk. A fenti folyamatok során a tesztelők soha nem látják az élesben használt adatokat, ami szintén kiküszöböli a rosszindulatú belső felhasználókkal járó kockázatokat.

0