Hogyan nyerhetné vissza a BKK a bizalmamat?

Az elmúlt két hétben alig telt el nap anélkül, hogy ne derült volna ki valami újabb “érdekesség” a BKK új, online, elektronikus jegyértékesítési rendszerével kapcsolatban. Sokan, sokféleképpen elmondták már, hogy a rendszer fejlesztői milyen szakmai és kommunikációs hibákat követtek el, azt azonban egyetlen cikkben sem láttam vitatni, hogy elektronikus jegyértékesítési rendszerre szükség van.

Az elkövetett “bakik” azonban jelentősen megingatták a felhasználói bizalmat mind a szolgáltatóban, mind pedig az elkészült rendszerben, ami elég érdekes patthelyzethez vezetett: mind a szolgáltatónak, mind pedig a felhasználóknak érdekük lenne használni egy ilyen rendszert, de nem ezt.

Adott tehát a feladat, ki kell mászni erről a mélypontról, mindannyiunk érdekében. Te hogyan tennéd? Ha te lennél a BKK-nál az a most frissen kinevezett, új vezető, akinek sikerre kell vinnie az elektronikus jegyértékesítési rendszert, te mit csinálnál? Utasként, felhasználóként, mit várnál el a BKK-tól, hogy bátran használni merd a rendszert? Informatikusként, szoftverfejlesztőként, IT biztonsági szakemberként mi kellene neked ahhoz, hogy megbízz egy új rendszerben?

Eljátszottam a gondolattal, hogy ha én kerülnék ilyen kihívás elé, én milyen irányba vinném a projektet. Tettem mindezt úgy, hogy a mostani rendszerről a sajtóban megjelenteken kívül semmit sem tudok: nem ismerem a követelményeket, az anyagi kereteket, a jogi korlátokat, az integrációs igényeket, ezért ezeket figyelembe se tudtam venni. Minden döntésnek vannak hátrányai, az egyszerűség kedvéért itt csak az előnyökre térek ki.

További károk megelőzése

Felbontanám a szerződést a T-Systems-szel, és az erről szóló dokumentumokat nyilvánossá tenném. Miért? A mostani rendszer fabatkát sem ér, és a fejlesztő cég elveszítette szavahihetőségét: nincs az a felhasználó, aki szívesen használná, vagy aki elhinné, hogy a fejlesztő “megerősítette”, és most már biztonságos. Egy új, tiszta lappal induló projektben ez csak ballaszt.

Megsemmisíteném a jelenlegi adatbázist, méghozzá egy IT biztonsági cég felügyeletével, akiknek az igazolását nyilvánossá tenném. Miért? Egyrészt nincs rá szükség egy tiszta lappal induló új rendszernél, másrészt nagyjából 1 napnyi felhasználási adat van benne, amit simán hagynék veszni, de leginkább azért, hogy elejét vegyem azoknak a vádaknak, hogy továbbra is innen szivárog ki személyes adat. Meg aztán úgyis van róla backup a dark weben 🙂

Közreműködő IT biztonsági cégként egy olyat választanék, aki nem mamut és akit a hazai szakma elismer. Legalább három IT biztonsági konferencia van hazánkban minden évben, bőven lehet választani a felvonuló cégek közül.

Új alapok

Az új rendszert kezdettől fogva a Kerckhoff elvet követve fejleszteném. Miért? A Kerckhoff elv szerint a rendszer csak akkor lehet biztonságos, ha egy támadó a titkosítási kulcson kívül a rendszer összes paraméterét ismerheti. És miért ne ismerhetné bárki, hiszen ez egy közpénzből fejlesztett, nagyon érzékeny személyes adatokat kezelő, közérdekű rendszer.

Nyilvánossá tenném a forráskódot és minden dokumentációt. Miért? Egyrészt mert ebben az országban nagyon sokan tudnának értékesen hozzátenni a projekthez, másrészt mert a transzparencia hatalmas erő. Kockázatos, de bátor tett lenne, ha a fejlesztőcsapat kiállna, és azt mondaná: íme, erre költöttük a pénzeteket. Mi hiszünk abban, hogy ez így jó, de tessék, nézzétek meg minden részletét, és szóljatok hozzá, kíváncsiak vagyunk a véleményetekre. Fontos, hogy a nyílt forráskód, nem jelenti a demokratikus döntéshozatalt. A szakmai döntésekért valakiknek vállalniuk kell a felelősséget, nem lehet azt mondani, hogy a “tömeg megszavazta”. Viszont hiszek abban, hogy a jótanácsot meghallgatni illik, de megfogadni nem feltétlenül kell.

Egy szakmai műhelyre bíznám a fejlesztést, nem egy multira. Miért? Még ha feltételezzük is, hogy ugyanaz a szakmai kompetencia megvan mindkét esetben, a motiváció lényegesen eltérő a két esetben. Nagyon sokat számít, hogy a projekt résztvevői pontosan mit akarnak elérni: egy jól működő, általuk is használt, a felhasználók elégedettségére törekvő rendszert akarnak készíteni, vagy más az elsődleges cél.

Arcokat tennék a projekt mellé. Miért? Az összes sikeres projekt, amit eddig láttam, részben annak köszönheti az eredményeit, hogy valaki vagy valakik a saját gyereküknek érezték. Akinek ott a neve, az arca, az elérhetősége és a felelőssége, az teljesen máshogy áll a projekthez, mint egy sokadik, névtelen alvállalkozó. És természetesen a felhasználói oldal is máshogy áll hozzájuk.

Iteratívvá tenném a fejlesztést. Miért? Ma már nagyon maradi megközelítés azt gondolni, hogy egy szoftver projekt az átadásakor készen van. Mindig jönnek visszajelzések, mindig találunk hibákat, mindig lehet javítani az alkalmazáson.

Continuous integration, continuous delivery és automatizált tesztelés. Miért? Egyszerűen nélkülözhetetlen az iteratív fejlesztéshez, pont.

Publikálnám a roadmapet. Miért? A roadmap mutatja, hogy mit szeretne még elérni a csapat, mi mindenre gondoltak még, és milyen irányba megy a fejlesztés. Bár minden roadmap változik, a felhasználói oldal számára mégis tervezhetőséget biztosít. Különösen, ha ez egy valóban élő dokumentum, aminek a változásait a fejlesztők el is magyarázzák (akár szóban, online meeting formájában).

Operations

A kódot felhő szolgáltatónál, serverless alapokon futtatnám. Miért? A felhő mellett számos érv van, ennél a projektnél talán az a legfontosabb, hogy ne csak jól skálázódó és biztonságos legyen, de egyszerűen és olcsón üzemeltethető is. Erre ma szerintem a serverless a legjobb megoldás.

Ops a BKK-nál. Miért? A rendszer a BKK ügyfeleinek személyes adatait kezeli, tehát a BKK-nak kell felelnie értük. Fontos az is, hogy a rendszer zavartalan működése a BKK számára a legfontosabb, ezért a közvetlen üzemeltetés a legpraktikusabb. Serverless környezetben a szolgáltató számos monitorozási lehetőséget és automatikus skálázást ad, miközben nagyon jól definiálható, hogy ki férhet hozzá a tárolt adatokhoz.

Biztonság

Federált authentikáció. Miért? A felhasználók azonosítása nem kis feladat, ha nem kell megcsinálni, azzal csak nyer a projekt. Arról nem is beszélve, hogy nem egyszerű jól megcsinálni, komoly felelősség. Ráadásul, ha figyelembe vesszük a projekt célközönségét is, akkor az is elképzelhető, hogy egy magyarország.hu + Google + Facebook hármas szinte mindenkit lefed.

Activity log a saját tevékenységeimről. Miért? A rendszerben megvan, hogy ki, mikor, milyen tranzakciókat hajtott végre. Annak a lehetősége, hogy a felhasználók a saját tevékenységeiket így visszakövethetik, számos félreértést eloszlat.

GDPR megfelelőség. Miért? Nem csak azért, mert 2018. májusától úgyis kötelező, hanem azért is, mert egyszerűen tisztává teszi a képet: mindenki láthatja, hogy a rendszer milyen adatokat tárol róla és kérheti azok törlését.

Security review, nyilvános dokumentációval. Miért? Szinte minden security review-n kiderül valami, amire a fejlesztők nem gondoltak, és amivel jobbá lehet tenni a rendszert.

Béta teszt időszak. Miért? Nehéz elsőre jót alkotni, kellenek a korai visszajelzések, az életszerű adatok. Ez a teszt lehet akár zártkörű, meghívásos is, még az is jobb, mint azonnal nekifutni a nagyközönségnek.

Bug bounty program. Miért? Erről az utóbbi időben sokat írtak, nem szeretném ragozni: tiszta és megéri.

Felkutatnám a más országokban létező elektronikus jegy megoldásokat. Miért? Nem lepődnék meg, ha az derülne ki, hogy a létező megoldások sem garantálják, hogy az elektronikus jegyek biztosan nem hamisíthatóak. Lehet, hogy az is elég, ha nagyobb munka hamisítani, mint megvenni.

Ráadás

Közzétenném az adatokat anonimizált formában. Miért? Ebben a rendszerben nagy mennyiségű adat gyűlik össze, a hasonló rendszerek kutatásával foglalkozó szakemberek számára ez nagyon hasznos és értékes adatforrás. Ennek az adatbázisnak az elemzésével a közlekedést meghatározó döntések születhetnek.

 

Nektek ez így elég lenne, ilyen körülmények között ti bíznátok egy új rendszerben? Mit hagytam ki?

 

.