Az információ védelme

Mindenkinek mást jelent az IT-biztonság. Valaki védi az információit, valaki nem. Egyesek a Facebookra teszik ki a személyes adataikat, mások nem. De ha IT-biztonságról van szó, érdemes pár dolgot szabályozni, hogy ne történjen velünk a cikkben szereplő két esethez hasonló.

Két évvel ezelőtt olvastam egy cikket, amely felkeltette az érdeklődésemet az IT-biztonsági téma iránt. A programozástechnikai dolgok mostanság már nem hoznak úgy lázba, mint tíz évvel ezelőtt, így természetesen az emberi oldala fogott meg a területnek. Azóta sokat olvastam cikkeket, jó néhányszor beszélgettem szakértőkkel, és egyre jobban elmerültem a témában. Hadd osszak meg pár történetet az elmúlt két évből.

Az első cikk, amely motivált, részletesen tárgyalt egy olyan behatolást, amelynek végrehajtása minimális technikai tudást igényelt. A hangsúly az emberi hiszékenységen, érdektelenségen és figyelmetlenségen volt. A folyamat végén a támadó olyan adatokhoz jutott hozzá, amelyek használatával több tízezer dolláros veszteséget okozott a vállalatnak.

A cikk végén az alábbi kérdések fogalmazódtak meg bennem:

• A környezetemben található (heverő) információkból egy idegen támadó mit tudna összerakni?
• Tudnék-e hasonló módon információkhoz hozzájutni?
• Hogyan lehet védekezni az emberi erőforrás oldalon?

A második kérdést már másnap kipipálhattam. Egy megbeszélésem volt, amelyre egyik kollégámmal voltam hivatott elmenni. A recepcióban ülő hölgynek kedvesen bediktálhattam volna a hamis nevemet (nevünket), mivel semmit nem kért tőlünk. (Persze természetes, hogy egy kis cégnél nem kell arcképes igazolvánnyal azonosítani magunkat.) Bementünk az egyik tárgyalóba, amely egyben a szerverszoba is volt. Az amúgy sem nagy szoba sarkában zümmögött egy gép, amin a rendszergazda neve és telefonszáma volt egy darabka papírfecnire felírva. A tárgyalás egyébként semmilyen sikert nem hozott, habár beszélgettünk a tesztelés szinte összes aspektusáról. De a végén nem lett belőle üzlet.

A megbeszélés második felében a biztonságra terelődött a szó, és kaptam a lehetőségen, elmondtam pár dolgot a nemrégiben olvasott cikkből. Odáig jutottunk, hogy megjegyeztem, nem itt kellene tárolni a rendszergazda elérhetőségét, mire az volt a válasz, hogy úgysem megy vele semmire az ember.

Kértem a partnerünket, engedje meg, hogy felhívjam a rendszergazdájukat. Kezdőként olyan izgalomban voltam, mint kisgyerekek iskolakezdés előtt, de azért tárcsáztam a számát. Mint új munkavállaló (fejlesztő) mutatkoztam be, és rövid beszélgetés után megkértem adjon e-mail címet és hozzáféréseket a rendszerekhez. Miért pont én hívom? Mert a főnök most megbeszélésen van, és nekem adta ki a feladatot, hogy intézzük el.

A tervezés hiányosságán múlott, hogy nem sikerült. A rendszergazda megígérte, hogy még a mai nap folyamán elkészíti a kért dolgokat, csak adjam meg a privát e-mail címet, hogy majd elküldhesse a bejelentkezéshez és az e-mailbeállításokhoz szükséges adatokat. Mivel ennyire már nem készültem, saját e-mail fiókot meg nem akartam megadni, ezért bontottam a vonalat és ennyi. Kevesen múlt csak a siker. Mégis annyira látványos volt, hogy egy ilyen piti kis cselnek bedől egy IT-szakember, hogy döbbenten néztünk egymásra. Partnerem is, de én is.

A tárgyalás végül folytatódott egy másik időpontban, amikor is egy biztonsági szakértőt is magunkkal vittünk, és mosolyogva láttam, hogy a szerverről eltűnt a rendszergazda elérhetősége.

Kinek mit jelent az IT-biztonság?

Hétköznapi emberként, átlagos felhasználóként az IT-biztonság nem jelent mást, mint hogy alkalomadtán számítógépeinket vírusok támadják meg, amelyeket időről-időre le kell irtanunk. Kis kellemetlenség, de pár órás munkával ismét használatba vehetjük gépünket.

Akik kicsit is értenek az IT-szakmához, azok más aspektusát is észreveszik a biztonságnak. Nemcsak a vírusirtást látják már, hanem azokat a veszélyeket is, amelyek az alkalmazások sebezhetőségéből, rendszereink hibáiból adódhatnak. Nem bíznak meg minden programban feltétlenül. Nagyon helyesen is teszik. Viszont abban a tévhitben élnek, hogy a legfőbb sebezhetőségi pont a rendszerekben, alkalmazásokban van, így általában arra koncentrálnak, hogy a hálózatuk minél jobb hardveres és szoftveres védelemben részesüljön.

De hányan gondolnak az emberekre és az emberek hordozta információk sebezhetőségére? Elég kevesen! Még a legjobb szakemberek is vétenek olyan alapvető hibákat, amikor információt szolgáltatnak ki illetéktelen személyeknek.

Mint ahogy a fenti példában is láttuk, sokszor nem szándékos behatolásnak indul a történet, hanem véletlen események vezetik odáig a résztvevőket, hogy tényleges támadás történjen. A szervezet biztonsági fokát mindig a leggyengébb egység foka határozza meg.

Hiába találnak ki megfelelő bonyolultságú és hosszúságú jelszavakat a hálózati elérésekhez, ha azt valaki leírja egy papírdarabra és jól látható helyen hagyja. Bárki, a takarítóktól egészen az interjúra jelentkező emberekig elolvashatják a jelszavakat. Azt pedig előre nem láthatjuk, hogy ki és mikor fogja ezt rossz szándékkal felhasználni.

Időnként nem árt, ha végigmegyünk az irodában és körülnézünk, milyen információkat lehet begyűjteni az egyes munkatársak jegyzeteiből. Személy szerint sokszor tapasztalom, hogy olyan adatokat találok papírra leírva, amelyeket nem lenne szabad így tárolni.

Az én felfogásomban az a helyes működés, hogy a munkafolyamat szabályozott mederben folyik, mindig van felelőse az adott résznek, és mindenki megkapja azt az információt, mellyel akadálytalanul tud dolgozni. Se többet, se kevesebbet.

Nehogy azt higgyük, hogy elég csak a külsős behatolók ellen védekezni. Számos alkalommal belső ember használja ki a birtokába került adatokat. Az egyik legnagyszerűbb példa erre az alábbi eset, amelynek elég komoly következménye lett.

Amikor a fejlesztő megvadul

Adott egy fejlesztői csapat, akik elnyertek egy gazdasági szoftver fejlesztésére és üzemeltetésére vonatkozó megrendelést. A csapat fiatalos, lendületes, nagyon összetartó. Amikor elkezdődik a rendszer tervezése, az Ügyfelekkel nagyon jól megértik magukat. A kommunikációs csatornák néha akadoznak, folyamatok nem mindig léteznek, de mindenki megtesz mindent, hogy a szoftver időben elkészüljön.

A fejlesztés folyamata az Ügyfelek igényeinek felmérésével kezdődik, majd az architektúra kialakítása és a rendszer magjának megírása után elkezdődik a rengeteg funkció részletes specifikálása, fejlesztése, tesztelése.

A hollywoodi filmekhez hasonlóan itt is egy szerelmi szál bonyolít meg mindent. Az egyik fejlesztő az Ügyfél oldaláról egy fiatal, csinos hölgyet kap szakértőként. Hogy, hogy nem, de fejlesztőnk egyre több időt tölt az „Ügyfélnél” a problémás funkciók tervezésével, specifikálásával és a lefejlesztett funkciók tesztelésével.

Hogy irodán kívül mi történt és mi nem, az nem ránk tartozik. A történet szempontjából a száraz tény az, hogy fejlesztőnk hoppon marad, mivel a hölgy a fejlesztőnk egyik munkatársát választja. Barátunk próbálja kiheverni a csalódást, de nem sikerül neki. Mi mást tehetne ebben a szomorúságába? Megpróbálja megmérgezni ezt a jól működő, de számára elfogadhatatlan kapcsolatot. Valahogy bosszút kell állnia munkatársán!

Na de hogyan jön ide a szoftverbiztonság?

A fejlesztés olyan iramban halad, hogy a csapatnak „nincs ideje” a fejlesztési folyamat biztonsági kérdéseivel foglalkozni, ők gőzerővel dolgoznak a funkcionalitáson. Annyira, hogy az adatbázis admin jelszavát is csak egy rövid ideig tudja a rendszergazda titokban tartani. Aztán mivel annyi kérés folyik be hozzá, hogy már nem képes feldolgozni azokat, először csak egy embernek, majd egyre többnek adja meg a jelszót, hadd csinálják meg maguk, amit akarnak a fejlesztői-tesztelői környezetekben.

Csak amikor az éles rendszerre akarják kitenni a fejlesztést, ott is el kell végezniük azokat a táblamódosításokat, beállításokat, amiket a fejlesztői környezeten megcsináltak. Úgyhogy legyen szíves, kedves rendszergazda, de adja már meg az éles rendszer jelszavát is. Köszönjük!

A rendszergazda azért érzi ennek a nagy szabadságnak a veszélyét, így próbál ellene tenni, de a fejlesztési folyamat kaotikussága miatt egy személyben nem tud mit csinálni. Jelszót változtat, új felhasználókat hoz létre megfelelő jogosultsággal, de valahogy mindig kikerül a keze alól az irányítás.

De ha már a veszélyérzet nem múlik, valamit csak kezdeni kellene a problémával. Megoldás lehet a rendszer folyamatos mentése. Ha napi szinten ment, akkor azért olyan nagy bajt nem lehet csinálni, amit ne lehetne kellően orvosolni. Így is tesz, beállítja a napi mentést, amit DVD-re hetente kiír. A DVD-k már ott sorakoznak a szerver mellett, amikor egyik reggel jön a hír, hogy valószínűleg történhetett valami hiba, mert nincsenek adatok az éles rendszerben.

Mire jó a log?

Természetesen van log, megnézhetjük, mi történt. Az látszik, hogy a hölgy választottjának gépéről beléptek adminként az éles adatbázisba, és kiderült: még mindig jól működik a DELETE parancs. Semmi gond, szól az embereknek (fejlesztőknek, vezetőknek), hogy mi történt és visszaállítja a mentést a DVD-ről.

A fejlesztőt jól leszidják, hogy máskor ilyet ne csináljon és kész.

Eltelt két hét, amikor az Ügyfelek jelzik, hogy a bevitt adatok rosszak az alkalmazásban. A rendszergazda ismét kideríti, hogy ugyanaz a személy nyúlt hozzá a táblákhoz, mint a múltkor. Rendszeresen naponta apró módosításokat hajtott csak végre, de pont elég volt ahhoz, hogy több ezer rossz adat kerüljön fel a rendszerbe.

Szétválogatni az adatokat iszonyat munka lenne, ezért a mellett döntenek, hogy a két héttel ezelőtti mentést veszik elő, és újra beviszik az adatokat az alkalmazásba.

Az egyenleg számokban (- költség; + bevétel):

• A vezetőség mindkét fejlesztőt kirúgja, az egyiket azért, mert sejtik, hogy ő a bűnös, de bizonyítani nem tudják, a másikat azért, mert bizonyíték van bőven (-2 fő vagyis -1 200 000 Ft / hó munkabér)
• A rendszergazda visszaállítja a 2 héttel ezelőtti állapotot (-4 300 000.- Ft munkabért feleslegesen fizettek az elmúlt 2 hétben)
• Mindenki gőzerővel nekiáll, hogy a következő 2 hétvégén ismételten bevigye az adatbázisba a már egyszer ott lévő adatokat (-1 200 000 Ft túlórás munkabér)
• Az ügyfél az éles rendszer üzemeltetését átveszi saját kézbe, ami miatt a cég
• elvesztette az üzemeltetési feladatokat (-10 000 000 Ft /  év / Ügyfél)
  • elterjed a hír a többi Ügyfél között is (-10 000 000 Ft / év / Ügyfél)
  • Plusz rendszergazdát kell felvenni, és szigorítani kell a fejlesztési folyamaton (- 600 000 Ft / hó munkabér)

Nem túl szép a végösszeg. De szabályozott fejlesztési folyamatokkal és kijelölt felelősökkel ez talán elkerülhető lehetett volna. Folyamatosan törődnünk kell az információk védelmével, akár a fejlesztés közben vagyunk, akár azután. Mindig figyeljünk rá, hogy illetéktelenek ne juthassanak egyszerűen belső adatokhoz. Egyrészt figyelnünk kell a folyamataink megfelelő szabályozására, másrészt a munkatársainkat oktatni kell az IT-biztonságra.

Szerző: Pongrácz János