Secure test data management a kontroll elvesztése nélkül

Egy sikertelen tesztfuttatás bosszantó. Egy sikeres tesztfuttatás valódi ügyféladatokkal egy nem kellően védett környezetben lényegesen drágábbnak bizonyulhat. A secure test data management nem egyetlen eszközzel oldja meg ezt az ellentmondást, hanem egyértelmű szabályokkal az adatokra, hozzáférésekre, tesztkörnyezetekre, és bizonyítékokra vonatkozóan. Azoknak a csapatoknak, amelyek automatizáltan tesztelnek web- vagy Windows-alkalmazásokat, ez tehát a minőségi munka része - nem csupán a megfelelőségé.

Miért válnak a tesztadatok biztonsági problémává

A produkciós adatok csábítóak a tesztek számára, mert valós szélsőséges eseteket tartalmaznak: hiányos címeket, szokatlan rendeléskombinációkat, történeti árszabályokat, vagy hibás bevitelt. De pontosan ezek az adatok tartalmaznak gyakran neveket, elérhetőségi adatokat, szerződéses információkat, személyzeti számokat, banki adatokat, vagy belső üzleti logikát.

A kockázat ritkán egyetlen durva hibából ered. Rendszerint fokozatosan növekszik: egy adatbázis-exportot hoznak létre egy teszthez, megosztott könyvtárba helyezik, majd később átmásolják egy másik környezetbe. Egy külső szolgáltatás képernyőképeket kap hibaelemzéshez. Egy tesztfiók kiterjedt jogosultságokat tart meg, mert egy takarítás megzavarhatná a következő futtatást. Néhány hónap után már senki sem tudja megbízhatóan, mely adatok hol vannak.

Kis- és középvállalkozásoknál a probléma gyakran a szűkös kapacitások miatt éleződik ki. A csapat egy kiadási határidőt szeretne tartani, nem pedig saját adatvédelmi projektet üzemeltetni. A felelősség mindazonáltal fennmarad. Aki adatokat használ minőségbiztosításra, annak nyomon kell tudnia követni, mely adatokat dolgozzák fel, ki fér hozzájuk, és mikor távolítják el újra.

A secure test data management a tesztesetet megelőzően kezdődik

A döntő kérdés nem az: "Hogyan védjük a tesztadat-állományt?" Hanem: "Milyen információra van ténylegesen szüksége ennek a tesztnek?" Sok regressziós teszt egyáltalán nem igényel valódi személyes hivatkozást. Egy szállítási folyamatnak például ellenőriznie kell, hogy a szállítási címeket, súlyokat, zónákat, címkéket, és állapotváltozásokat helyesen dolgozzák-e fel. Ehhez elegendők a szintetikus ügyfelek, a hihető törzsadatok, és a tudatosan meghatározott szélsőséges esetek.

Ez a megkülönböztetés gyakorlati adatosztályozáshoz vezet. Nem minden tesztkörnyezetnek van szüksége ugyanolyan adatmélységre. Egység- és integrációs tesztekhez gyakran teljesen mesterséges adathalmazok is elegendők. Végponttól végpontig tesztekhez álnevesített másolatok lehetnek célszerűek, ha a valós adatminták szakmailag relevánsak. A produkcióhoz hasonló adatoknak kivételnek kellene lenniük - dokumentált céllal, korlátozott hozzáféréssel, és rögzített élettartammal.

Fontos ehhez a helyettesítő adatok minősége. A véletlenszerű, kitalált adatok keveset segítenek, ha nem tükröznek reális függőségeket. Egy raktári alkalmazás tesztadathalmazának például tartalmaznia kell cikkváltozatokat, raktárhelyeket, zárolt készleteket, részszállításokat, és visszaküldéseket koherens kombinációban. A jó tesztadatok nem csak személyes információkat védenek. Olyan hibákat találnak meg, amelyek üres táblázatokkal és a "Kovács János" mintaügyféllel soha nem válnának láthatóvá.

Szintetizálni, maszkolni, vagy minimalizálni?

A szintetikus adatok a legbiztonságosabb választás, ha a szakmai szabályok tisztán modellezhetők. Célzottan a tesztkövetelményekből jönnek létre, és nem tartalmaznak másolatot valós személyekről vagy tranzakciókról. A ráfordítás a karbantartásban rejlik: ha az adatmodell változik, vagy új folyamatszabályok kerülnek hozzáadásra, a generátoroknak és fixture-öknek együtt kell növekedniük.

A maszkolás akkor alkalmas, ha egy alkalmazás viselkedése erősen függ a produkciós struktúráktól. Ilyenkor az érzékeny mezőket lecserélik vagy módosítják, míg a kapcsolatok megmaradnak. A nevekből hihető, de fiktív nevek lesznek; az e-mail címekből kézbesíthetetlen teszt e-mail címek lesznek; a számlaszámokból helyes formátumú, de valós vonatkozás nélküli értékek lesznek. A maszkolás csak akkor tartható fenn, ha a közvetett következtetéseket is figyelembe veszik. Egy ritka helyszín, születési dátum, és szerződési jellemző kombinációja továbbra is azonosíthatóvá teheti a személyt.

Az adatminimalizálás gyakran az alábecsült harmadik út. Egy teljes export másolása helyett csak a szükséges szelet kerül biztosításra. Ez csökkenti a támadási felületet, a tárolási igényt, és a takarítási ráfordítást. Egy kedvezménylogika teszteléséhez senkinek sem kell egy egész évi ügyfél-előzmény.

A hozzáféréseknek és környezeteknek illeszkedniük kell a kockázathoz

Egy védett adathalmaz elveszíti értékét, ha szabadon elérhető tesztkörnyezetben található. A tesztrendszereknek ezért saját biztonsági határaikra van szükségük - elkülönített adatbázisok, saját szolgáltatásfiókok, egyértelműen meghatározott hálózati hozzáférések, és semmilyen néma kapcsolat a produkcióval.

A hozzáférési jogosultságoknak szerepkörökön kellene alapulniuk, nem megosztott fiókokon. A fejlesztőknek adott esetben más jogokra lehet szükségük, mint a QA-nak, a támogatásnak, vagy a külső szolgáltatóknak. Az adminisztrátori hozzáférés néha szükséges, de időben korlátozottnak, naplózottnak, és visszakövethető jóváhagyáshoz kötöttnek kell lennie. A tesztfiókokra is érvényesek az értelmes jelszószabályok, a többfaktoros hitelesítés, ahol elérhető, és a fiókzárolási folyamatok ismételt sikertelen kísérletek esetén.

Az automatizált tesztek egy további különleges esetet hoznak: bizonyítékokat állítanak elő. A képernyőképek, képernyőfelvételek, naplók, és hibaüzenetek érzékeny tartalmat tartalmazhatnak, még akkor is, ha az adatbázist maszkolták. Egy ügyfélmaszk képernyőképe, egy munkamenet-információt tartalmazó böngészőnyom, vagy egy API-adathasznos teherrel rendelkező napló ugyanabba a védelmi megfontolásba tartozik, mint a tesztadatbázis.

Ezért a tesztmellékleteknek megőrzési szabályokra van szükségük. Nem minden sikeres futtatást kell tartósan tárolni. Kritikus jóváhagyásokhoz hasznos lehet egy visszakövethető bizonyíték, például időbélyeggel, build-számmal, tesztverzióval, és eredménnyel. A sikertelen futtatásoknak gyakran hosszabb elemzési ablakra van szükségük. Ezt követően a mellékleteket automatikusan törölni kellene. Ami már nem létezik, azt nem lehet véletlenül megosztani vagy veszélyeztetni.

Automatizálás ellenőrizetlen adatszivárgás nélkül

A mesterséges intelligenciával támogatott tesztautomatizálás jelentősen felgyorsíthatja a teszteket, különösen kiterjedt web- és Windows-alkalmazások esetében. De megváltoztatja a biztonsági kérdést: hova kerülnek a képernyőképek, bevitelek, hibaleírások, és alkalmazásforgalom? Ki dolgozza fel őket? Meddig maradnak ott?

A biztonságtudatos csapatok számára az önállóan üzemeltetett végrehajtás gyakran a jobb architektúra. Egy olyan rendszer, mint a COCO, saját vagy egyértelműen körülhatárolt infrastruktúrán belül futhat, tesztlépéseket hajthat végre, bizonyítékokat tárolhat, és érthető kiértékeléseket generálhat. Ez nem minden helyzetben kötelező. Egy nyilvános marketingoldalhoz, tisztán szintetikus űrlapértékekkel, egy külső szolgáltatás elfogadható lehet. Belső szakmai alkalmazásoknál, ügyfélportáloknál, vagy személyes folyamatokat kezelő szoftvereknél azonban a helyi kontroll konkrét előny.

Az önhosztolás nem szabadjegy. Az üzemeltetés frissítéseket, biztonsági mentési koncepciókat, hozzáférési naplókat, és felelős szervet igényel. Cserébe az adatszuverenitás ott marad, ahol lennie kell. A helyes megközelítés a védelmi igénytől, a meglévő üzemeltetési képességektől, és a tesztelt alkalmazás típusától függ - nem egy adott tesztelőeszköz körüli aktuális hype-tól.

Így válnak a szabályok működőképes folyamattá

Egy gyakorlati folyamatnak nem kell blokkolnia a kiadást. Kezdje egy adattérképpel: mely tesztkörnyezetek léteznek, milyen típusú adatok találhatók ott, és mely rendszerek generálnak további mellékleteket? Ez a felmérés általában már felfedi a régi exportokat, elfeledett staging rendszereket, és tisztázatlan felelősségeket.

Ezt követően kifizetődő egy egyszerű döntési mátrix tesztosztályonként. Ez meghatározza, hogy elegendőek-e a szintetikus adatok, szükséges-e maszkolás, vagy egyértelműen indokolt produkciós kivonatra van-e szükség. Ezt kiegészítik tulajdonosok, törlési határidők, és hozzáférési szerepkörök. Ennek nem kell túlterhelt szabálykönyvnek lennie. Egy rövid, ténylegesen betartott irányelv jobb, mint egy biztonsági dokumentum, amelyet senki sem talál meg egy incidens során.

Technikailag az adatok rendelkezésre bocsátása és a takarítás a tesztfolyamatba tartozik. Egy futtatás reprodukálhatóan létrehozza a szükséges adathalmazokat, egyedi jelöléseket használ, majd ezt követően ismét eltávolítja azokat. Ez megakadályozza, hogy a tesztkörnyezetek megteljenek maradék adatokkal, és az eredmények minden sprinttel egyre kevésbé legyenek megbízhatóak. Kritikus folyamatok esetén a csapatoknak emellett ellenőrizniük kell, hogy az adathozzáféréseket és a tesztbizonyítékokat auditálható módon kell-e naplózni.

Biztonság, amely gyorsabbá teszi a tesztelést

A secure test data management-et gyakran további ellenőrzési tehernek tekintik. Rosszul megvalósítva valóban az is lehet. Jól megvalósítva azonban megbízható, ismételhető kiindulási feltételeket teremt. A csapatok kevesebb időt vesztegetnek egy használható adat-export keresésére, elkerülik a meg nem tisztított régi adatok miatt tönkrement teszteket, és jobban meg tudják indokolni a jóváhagyásokat.

A legésszerűbb első lépés ritkán egy nagy platformprojekt. Vegye azt a tesztfolyamatot a legmagasabb kockázattal vagy a legnagyobb súrlódással - például egy belső rendelési alkalmazás jóváhagyását -, és tegye ott láthatóvá az adatforrást, a hozzáféréseket, a mellékleteket, és a törlést. Ebből a konkrét munkából olyan biztonsági rutin növekszik ki, amely nem teszi nehézkesebbé a teszteket, hanem hitelesebbé.