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?

 

.

Advertisements

18 thoughts on “Hogyan nyerhetné vissza a BKK a bizalmamat?

  1. Kulik Péter

    Szerintem tök jól összefoglaltad szakmailag, hogy min kellene változtatni. Viszont, amit ebből a legtöbb projektet vezetőnek le kéne szűrnie elsődlegesen, hogy (bár anyagilag biztos megéri jó pár embernek egy ilyen projekt) ne úgy gondolkozzanak, hogy megvan a tényleges büdzsé (az eredeti összegből a lenyúlásokat levonva) + határidő, na akkor valamit dobjunk össze addig gyorsan, hanem pont fordítva.

    Találjuk ki mit kell megcsinálni, hogy lehet megcsinálni korrektül szakmailag (lehetőleg minél részletesebben), és az alapján legyen ráfordítási idő (+ erőforrások alapján határidő), és árajánlat készítve.

  2. LC

    Hogy lehet egy adatbázist nyilvánosan megsemmisíteni ? Elégeted a Kossuth-téren egy máglyán a pendrive-ot ? És az esetleg elkészült másik 1000 példányt ? És azt, amit szorgos kezű hekkerek már 3x lenyúltak a BKK-tól ?

    1. Kulik Péter

      ” 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 ”

      Olvastad a miértet is, vagy csak a vastag betűs mondatokat?

  3. sufzoli

    Még egy dolgot tennék hozzá, ami nem a szakmai, hanem az üzleti része: nyilvánossá tenni a pályázatot, az értékelést és a szerződést. Ez az ami több jól működő demokráciában a közbeszerzésnél, közpénzköltésnél alapból kötelező. Nálunk sajnos nem.

  4. jssj

    LC-nek igaza van: ha valami egyszer már kikerült, az kint is marad. Szakmailag kevés pontba tudnék belekötni, de ebbe a “Megsemmisíteném a jelenlegi adatbázist” például nagyon. Ilyen nincs, ez nem működik.

    Illetve, hogy “Nyilvánossá tenném a forráskódot és minden dokumentációt.” … erre igazából nem is találok szavakat, akkora marhaság. De megpróbálom legalább érzékeltetni néhány példával:

    – mondjuk az Air France jegyfoglalási rendszerét feldobnád githubra? Vajon miért nem?
    – mondjuk az OTP webes átutalási rendszerét feldobnád githubra? Vajon miért nem?
    – stb.

    1. György Balássy Szerző

      jssj: Teljesen igazad van, hogy ami egyszer kikerült az internetre, azt onnan eltávolítani nem is lehet, ezért is írtam, hogy “van róla backup a dark weben”. Nem is az a cél, hanem hogy az új projekt tiszta lappal induljon. Ami a nyílt forráskódot illeti: teljesen más eset, ha egy meglévő, esetleg legacy rendszerről beszélünk, vagy ha egy zöld mezős, most induló projektről van szó.

  5. Nádirigó

    Az adatok és kódok tárolására is lehet némi helyet találni a BKK szerverein csökkentve a felhőszolgáltatók által jelentett további kockázatot…

      1. charlie

        Nekem adatvédelmi aggályaim lennének, nem szívesen bíznék ilyen adatokat egy USA-be, vagy azokkal jó kapcsolatot ápoló céggel. Esetleg az OVH ami nem ilyen.

  6. b7a

    Nádirigó: “felhő, mint kockázat”? ez mostanában nem trendi mondás. 🙂 elvégre ugyanolyan nagyágyúk szolgáltatnak (“az a profiljuk, azaz értenek hozzá”, így szól a mondás), mint a t-systems…
    BGy: engem azért meglepett, mennyi valóságtól távol álló gondolatot sikerült összehozni (még ha bizonyos gondolatokkal egyet is tudok érteni), például az adatbázis megsemmisítése nagyon meredek (vetekszik a post paraméter átírásával). honnan fogjuk tudni, mire ment közpénz?

    1. György Balássy Szerző

      b7a: Én sem kétlem, hogy ebből a listából ma, Magyarországon, szinte semmi sem fog megvalósulni, ezért is írtam, hogy “eljátszottam a gondolattal”. Ebben a cikkben nem volt célom a most átadott és befuccsolt projekt vizsgálata. Miért meredek?

      1. b7a

        A törlés azért meredek, mert ez nem pusztán műszaki kísérleti belső projekt. Úgy tűnik, hogy személyes adatok kerültek ki, amiből kifolyólag hatósági eljárás is következhet, valamihez vissza kell tudni nyúlni alátámasztani/cáfolni. Ezenkívül pénzügyi tranzakciós adatokat is tartalmaz (akár legális, akár visszaélés), ami elég ritkán kukába való információ. A rendszer közpénzen készült, mint azóta kiderült, talán az eljárással sem volt minden rendben. Rengeteg olyan vonatkozás/indok van, ami miatt az adatbázis (+ alkalmazás) nem törölhető, legalábbis néhány évig biztosan nem.

        Felhő témához: biztonsági és rendelkezésre állási kockázat is van. Például nagyobb kockázat, mert nagyobb érdeklődés lehet a megtörésükre, többen férnek hozzá többféle módon. Az is nagyobb kockázat, hogy jó eséllyel bonyolultabb/összetettebb a rendszer. Mindenki hallott már felhős leállásról, adatvesztésről, adatszivárgásról, ezeket nem lehet szőnyeg alá söpörni. Ez a mostani nyilvános példa ráadásul remekül szemlélteti (a látott nem nyilvánosokról nem is beszélve), hogy a “nagyágyúk” csillogó-villogó molinói mögött is mekkora szemétdomb van/lehet. (ez persze nem jelenti azt, hogy egyéb cégeknél nincs szemétdomb, de látatlanban elég nehéz megmondani, mi a nagyobb kockázat)

      2. György Balássy Szerző

        b7a: Köszi a visszajelzést!
        Törlés: Igazad van a visszakereshetőséggel, elszámoltathatósággal kapcsolatban, ezek egyszerűen nem voltak szempontok ennél a cikknél.
        Felhő: Nem értek veled egyet abban, hogy a felső nagyobb biztonsági és rendelkezésre állási kockázat lenne, mint egy on-premise infrastruktúra.

      3. b7a

        Törlés nem volt szempont? Hát… én elég erősnek érzem a megsemmisítés szót és erre a műveletre szánt teljes fejezetet indoklással együtt. 🙂

        Felhő: nem fogalmazol pontosan. A felvetés az volt, hogy “pontosan milyen kockázatra gondolsz, ami a felhőszolgáltatók esetén nagyobb, mint a BKK szervereinél”. Felsoroltam néhányat, ezek miért nem növelik egy felhő kockázatát? (nagyobb vonzerő, több szereplő, nagyobb felület, komplexitás)

        A fejlesztésre leírod kvázi ugyanazt, amit én az üzemeltetésre felhő vonatkozásban: “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.” Ugyanúgy, ahogy a T-Systems-nél hatalmas hibák buktak ki, egy közvetlenül kevésbé érdekelt szolgáltatónál is lehetnek komoly problémák.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s