IT biztonsági koncepció

Informatikai biztonsági koncepció (IT biztonságról közérthetően) Szerző: 2012. Horváth Zsolt április 10. Informatikai biztonsági koncepció Tartalom Előszó....................................................................................................................................................... 4 Informatikai biztonság fejlesztési kérdései ............................................................................................. 5 A biztonság, mint gátló tényező .......................................................................................................... 6 Egyenszilárdság hiánya, hamis biztonságérzet.................................................................................... 6 Hibás célok meghatározása ................................................................................................................. 6 Védendő értékek meghatározásának kérdései ....................................................................................... 7 Fenyegetések és kezelésük...................................................................................................................... 8 Adatvesztés ......................................................................................................................................... 9 Emberi mulasztás ................................................................................................................................ 9 Belső fenyegetések.............................................................................................................................. 9 Külső fenyegetések............................................................................................................................ 10 Sérülékenységek .................................................................................................................................... 12 A védelem területei ............................................................................................................................... 14 Bizalmasság ....................................................................................................................................... 14 Sértetlenség....................................................................................................................................... 14 Rendelkezésre állás ........................................................................................................................... 14 Védelmi eljárások .................................................................................................................................. 14 Kockázatok meghatározása ............................................................................................................... 16 Kockázatok kezelése .......................................................................................................................... 19 Szabályzat alapú eljárások, védelmi intézkedések ............................................................................ 20 Informatikai Biztonsági Politika ..................................................................................................... 24 Informatikai Biztonsági Szabályzat ................................................................................................ 24 Üzemeltetési eljárásrendek ........................................................................................................... 30 Felhasználói Szabályzat ................................................................................................................. 31 Katasztrófa elhárítási Terv (DRP) ................................................................................................... 32 Üzletmenet folytonossági Terv (BCP) ............................................................................................ 35 Védelmi technológiák ........................................................................................................................ 38 Adatmentés ................................................................................................................................... 38 Operációs rendszerek védelme ..................................................................................................... 41 Alkalmazások védelme .................................................................................................................. 46 Fejlesztési eljárások ........................................................................... Error! Bookmark not defined. Rendelkezésre állás biztosítása, riasztások kezelése..................................................................... 47 Hitelesítés ...................................................................................................................................... 49 IT biztonságról közérthetően Oldal 2 Informatikai biztonsági koncepció Jogosultságkezelés......................................................................................................................... 53 Titkosítás, hitelesítés ..................................................................................................................... 55 VPN ................................................................................................................................................ 58 Határvédelem ................................................................................................................................ 60 Ártó kódok elleni védelem ............................................................................................................ 65 Tartalomszűrési eljárások .............................................................................................................. 70 Naplókezelés, naplóelemzés ......................................................................................................... 73 Betörés detektálás......................................................................................................................... 75 Összefoglalás ......................................................................................................................................... 76 IT biztonságról közérthetően Oldal 3 Informatikai biztonsági koncepció Előszó „2007 februárjában ismeretlenek támadást intéztek a 13-ból 6 root DNS szerver ellen. A támadás eredményeként az USA-ban két root névszerver rövid időre elérhetetlenné is vált. Az amerikai védelmi minisztérium támadás utáni nyilatkozata szerint a jövőben minden hasonló incidenst háborús agressziónak fognak nyilvánítani és valódi fegyverekkel válaszolnak.” „Egy cégvezető, mikor felhívták a figyelmét, hogy az elektronikus adatainak mentése nem megoldott, lezseren csak annyit válaszolt: Számlázni számlatömbbel és tollal is lehet. Két hónap múlva, egy diszk hiba eltörölte a céges adatbázist. Számlatömb volt. Csak az ügyfél adatok, számlázási információk, megrendelések, szállítási mennyiségek, gyártási rajzok, határidők és árlisták hiányoztak.” A fenti két eseményből is látszik, hogy abban a korban élünk, mikor elektronikus kommunikáció és adattárolás nélkül a világunk jelenlegi formájában nem működtethető. Ennek előnyeiről és hátrányairól lehet vitatkozni pro és kontra, attól a tény még tény marad. Ezért az információ védelme soha nem látott prioritással rendelkezik. Jelen tanulmány keretein belül az adat- és információvédelem olyan nagyléptékű szempontjai kerülnek tárgyalásra, melyek mentén egy informatikai rendszerre vonatkozó védelmi eljárások és technológiák felépíthetőek. Az adat- és információkezelés és -védelem, valamint a védelmi mechanizmusok alapelveit több szabvány és ajánlás is kidolgozta (Pl.: ISO:27001, COBIT). A megvalósítandó technológiai megoldások részleteit azonban általában gyártó specifikus anyagok tárgyalják. A dokumentum az üzemeltetési, rendszerintegrátori feladatokhoz kapcsolódó egyes védelmi megoldások aktuális technológiai szempontrendszerét összegzi a teljesség igénye nélkül. A technológiák és megoldások ismertetése során arra törekedtem, hogy ne az egyes gyártók konkrét termékei kerüljenek ismertetésre, hanem a marketing anyagok helyett az alkalmazási szempontrendszerek kerüljenek előtérbe. A fejezetek felépítése egységes. Minden esetben:      a probléma felvetése, a feladat meghatározása, a szempontok kifejtése, az alkalmazott technológiák ismertetése, a bevezetés és működés kérdései kerülnek kifejtésre. IT biztonságról közérthetően Oldal 4 Informatikai biztonsági koncepció Az írás olyan felső- és középvezetőknek szól, akik annak ellenére, hogy nem informatikai szakemberek, munkájuk során rendszeresen kénytelenek döntéseket hozni informatikai kérdésekben beszerzési, fejlesztési, karbantartási területeken, illetve üzemben-tartási kérdésekben. Éppen ezért az egyes területek taglalásakor lehetőleg igyekeztem kerülni a szaknyelvet és az informatikára jellemző rövidítések használatát. Helyette a problémák és megoldási lehetőségek általános megvilágítására, értelmezésére törekedtem, olvasmányosabb formában. Az írásban igyekeztem visszaadni azt a feloldhatatlannak tűnő szemléletbeli különbséget, ami egy szakember és egy laikus közötti párbeszédet gyakran tévútra visz. Nevezetesen, hogy egy laikus egy adott technikai problémára egy konkrét megoldást vár, míg egy szakember egy komplex esetben több, első látásra ugyan olyan jónak tűnő alternatíva között kockázati, bizonytalansági tételekkel számol, és ezek összevetése alapján hoz döntést, mely minden esetben tartalmaz valamilyen kompromisszumot. Informatikai biztonság fejlesztési kérdései Az ISO/IEC:27001:20061 szabványban leírtak szerint az információbiztonság jelentése az információ bizalmasságának, sértetlenségének és rendelkezésre állásának megőrzése; továbbá egyéb tulajdonságok, mint a hitelesség, a számonkérhetőség, a letagadhatatlanság és a megbízhatóság, szintén ide tartozhatnak. [ISO/IEC 17799:2005] Elvben tehát, amennyiben ezek az elvek és értékek bármilyen mértékben csorbulnak, úgy abban a környezetben az informatikai biztonság szintje kívánni valókat hagy maga után, az adatok és az elektronikus kommunikáció biztonsága egy, vagy több szempont alapján is csorbul. Valójában ezek a problémák kivétel nélkül minden informatikai rendszerben megtalálható. Nincs olyan informatikai környezet a világon, amelyik az információbiztonság bármely felsorolt alapelvének 100%-ban eleget tudna tenni. Egy ismert karate mester szavai szerint: „Minden harcosnál van jobb. De nem mindegy, hogy mennyi.” Az adatvédelem egyre magasabb és magasabb szintre emelése természetesen örvendetes jelenség. Megfelelő szemlélet és előzetes tervezés nélkül azonban a különböző biztonsági projektek viszonylag hamar inkább a szervezet kárára, mint hasznára lesznek. Ez tipikusan az alábbi módokon szokott bekövetkezni: 1 (ISO/IEC:27001:2006 Az információbiztonság irányítási rendszerei) IT biztonságról közérthetően Oldal 5 Informatikai biztonsági koncepció A biztonság, mint gátló tényező Alapprobléma, hogy a biztonsági szint növekedése egyre jobban megnehezíti az adatokkal történő hatékony munkavégzést: 1. Az eszközök fizikai megközelítése nehezítve van (zárak, kapuk). 2. Jelszavakat, pin kódokat kell beírni, megjegyezni, kezelni, egyéb biztonsági eszközöket hurcolni magunkkal. 3. A számítógépek indulása, működése lassabb a telepített biztonsági alkalmazások erőforrásigénye miatt. 4. A munkavégzés során ellenőrzéseket, visszacsatolásokat kell végezni kizárólag azért, hogy a tevékenységünk nyomon követhető, ellenőrizhető legyen. A fenti korlátozások és tevékenységek át nem gondolt kiterjesztése és bevezetése jelentősen képes rombolni a munkavégzés hatékonyságát a különböző fizikai vagy logikai korlátozások bevezetésével, illetve morálisan. Ez nem azt jelenti, hogy a fenti megoldások feleslegesek, de bevezetésüket átgondolt módon, csak az adott folyamatok elemzése után érdemes elvégezni. Egyenszilárdság hiánya, hamis biztonságérzet A másik tipikus hiba, mely a tervezés hiányából fakad, hogy bizonyos területek aránytalanul nagy hangsúlyt kapnak a fejlesztések terén, míg mások háttérben maradnak. Ilyenkor a cégvezetők, adatgazdák hajlamosak a fejlesztett terület (és a fejlesztési invesztíció mértéke) ismeretében hamis biztonságérzetbe esni, és a további területekkel kevésbé foglalkozni. Tipikus példa szokott lenni erre egy-egy IPS beruházás, mely után a cég vezetése elégedetten hátradől, noha sem a belső jogosultság kialakítása, sem a mentési struktúra nem állják meg a helyüket, és a hálózati behatolás detektáló rendszer hiányosságainál sokkal komolyabb mértékben veszélyeztetik a szervezet adatait. Hibás célok meghatározása Ha előzetesen nem kerül felmérésre és kiértékelésre, hogy mi is az, amire vigyáznunk kell, úgy könnyen előfordul, hogy nagy erőkkel biztosítjuk viszonylag csekély értékkel bíró adatok és informatikai környezetek védelmét, míg a valóban fontos területek parlagon maradnak. Ezzel szorosan összefüggő szempont, hogy ha a védendő értékek valódi értékeire tekintet nélkül végzünk biztonsági fejlesztéseket, előfordulhat, hogy a védelem bevezetése és fenntartása aránytalanul magasabb költségszinttel jár, mint amekkorát egyáltalán a védendő értékek képviselnek. Egy tipikus, megtörtént példa erre, mikor egy cég informatikai rendszeréről jelentős védelmi beruházások után derült ki, hogy a központi ERP rendszerük fejlesztői úgy írták meg az alkalmazást, hogy adatbázis adminisztrátori (sa) jogokkal, és jelszó nélkül fér hozzá a IT biztonságról közérthetően Oldal 6 Informatikai biztonsági koncepció központi adatbázisukhoz, ráadásul több helyen „belegyógyították” ezt a forráskódba. Ezek után, a fejlesztők tanácsára az egész rendszert elérhetővé tették egy alig védett, publikus FTP szerverről. Védendő értékek meghatározásának kérdései Az előző példákból is látható, hogy a védendő értékeink meghatározása nélkül nehéz elképzelni hatékony biztonsági rendszert, tekintet nélkül arra, hogy személyeket, objektumokat, vagy adatokat szeretnénk védeni. Ebből a szempontból a személyi testőröknek egyszerűbb a feladata, ott a védendő értéket viszonylag könnyen azonosítani lehet, hosszabb előzetes vizsgálatok nélkül is. Minél nagyobb, bonyolultabb azonban egy informatikai rendszer, annál nagyobb kihívás ezeknek az értékeknek az azonosítása és pontos behatárolása. Ugyanis a védelem nem kifejezetten az adatra kell, hogy vonatkozzon, hanem az adat által hordozott információ tartalomra. Az információnak pedig meg van az a rossz szokása, hogy gyakran „átadásra kerül”. A védendő adataink egy komplex rendszerben és nem egy, jól körülhatárolt helyen találhatók, ahová aztán a támadók nagy erővel betörnek, ellopják, amit kell, és angolosan távoznak, hanem állandóan, dinamikusan változik, mind a fizikai helyét, mind a formáját, mind a környezetét illetően. Ez az állandó migráció egy kisvállalat egy-szerveres környezetében is jól megfigyelhető. A védendő adatok a központi szerver fájlmegosztásain, illetve a cég vállalatirányítási rendszerének adatbázisában találhatóak. De ezekkel munkavégzés folyik, melynek során az információ emailekben kerül elküldésre és tárolásra, alternatív mentésekkel megjelenik a munkaállomások helyi könyvtárainak bugyraiban, az adatbázisok tartalmából Excel táblázatok készülnek, melyet a dolgozók, vezetők különböző adathordozókon hurcolnak magukkal, mert otthon be kell fejezniük a határidős munkákat, vagy prezentálni kell egy ügyfélnek belőlük. Ennek fényében el lehet képzelni, hogy mi történik az információval egy valóban komoly informatikai struktúrában, ahol az egyes alkalmazások, elosztott környezetek folyamatosan dolgoznak az egymás által generált adatokkal, folyamatos és több, teljesen eltérő csatornán, párhuzamosan zajlik az alkalmazások közötti kommunikáció, melyet a felhasználói interakciók is megfejelnek. Ezzel természetesen nincs vége, mivel a rendszerek állandó változásban vannak, fejlődnek, új verziók települnek, frissítések jönnek-mennek, eseti üzemeltetési feladatok fordulnak elő óránkénti rendszerességgel, melyek sok esetben pont ezeket az információs csatornákat módosítják, újakat nyitnak, vagy irányítják át más területre. A védendő értékek pontos meghatározását leginkább az nehezíti, hogy egy informatikai rendszer soha nem statikus, hanem az élő szervezetekkel analóg módon állandó változásban van. Nem csak az adatok mennyisége, hanem maga rendszer komponensei is állandóan IT biztonságról közérthetően Oldal 7 Informatikai biztonsági koncepció változnak, ami természetesen visszahat a működésükre és a felhasználók munkafolyamataira is. Biztonsági auditok során rendszeresen elhangzó felkiáltások az üzemeltetők részéről: Ez tényleg így van, a tavalyi átálláskor úgy maradt! Ennek történeti okai vannak.. A fenti mondatokkal hangsúlyozottan NEM azt szeretném sugallni, hogy az üzemeltetők általában trehány, lusta népség, akik nem értik a dolgukat. Sokkal inkább arra szeretném felhívni a figyelmet, hogy hallatlanul bonyolult és szerteágazó, ezzel együtt állandóan és dinamikusan változó, komplex rendszerek felügyelete a munkájuk. Ez az információ a számítástechnikában kevésbé jártasaknak általában egyáltalán nem ismert, sajnos még vezetői szinten sem. A rendszerek működésének és működtetésének kérdése alapjában határozza meg az adott környezet biztonsági szintjét, melyre a későbbiek folyamán részletesen is ki fogok térni. Összefoglalva a fejezet tanulságait, a védendő értékeink behatárolásakor nem elég csak az egyes rendszerekben tárolt adatok fizikai és logikai helyét meghatározni, hanem részletesen fel kell tárni az információ áramlásának módjait, irányait, és a vizsgálódást az így látótérbe került új környezetekben is el kell végezni. Az informatikában a védendő értékek alatt természetesen nem kizárólag az adatokat és információ tartalmukat lehet érteni, hanem az ezek tárolására, továbbítására szolgáló eszközöket és szoftvereket is. Ezek védelmére jelen dokumentumban részletesen nem térnék ki, legfőképpen azért, mert ez már jórészt az objektumvédelem területeit fedi le. Fenyegetések és kezelésük A közelmúltban egy biztosítási ügynökkel beszélgettem, aki természetesen biztosítást akart eladni nekem, és ezt a koromra, nememre, munkámra, szokásaimra vonatkozó statisztikai adatokkal támasztotta alá. A változatos halálnemek boncolgatása közben állandó deja vu érzésem volt, melyet sokáig nem tudtam megérteni. Jóval később villant belém a felismerés, hogy én egy biztonsági audit során egészen hasonló módon tárom az ügyfelek elé az eredményeket és lehetséges következményeiket. Ő nyert, kötöttem biztosítást. A különböző médiában megjelent hírekkel ellentétben adatainkra (legyenek azok magán vagy céges adatok) elsődlegesen nem a gonosz, ismeretlen hacker csoportok jelentik a legfőbb veszélyt. Természetesen ettől függetlenül ezt sem kell egy vállvonással elintézni, mert tudomásul kell venni, hogy az internet ebből a szempontból pontosan megegyezik egy nagyváros utcahálózatával. Ha ott leteszem a pénztárcámat a járdára és elsétálok, valószínűleg valaki arra jár és elviszi. Ha publikussá teszem bizalmas adataimat, azt mások is el fogják olvasni, és mivel az informatika világában nem kőtáblákra, vagy sajtcetlikre írogatunk, rögtön le is fogják tudni másolni és másoknak is elküldeni, akik esetleg jobban érdeklődnek a dolgaink iránt. IT biztonságról közérthetően Oldal 8 Informatikai biztonsági koncepció Adatvesztés Visszatérve az elsődleges fenyegetésre, az nem más, mint mi magunk, a saját meggondolatlanságunk és természetesen az általunk használt eszközök korlátai. Kicsiben bemutatva, szerintem nincs ember, aki ne veszített volna adatot azért, mert egy dokumentumot nem mentett rendszeresen, vagy felülírt egy másikkal, esetleg véletlenül letörölt egy kupac szeméttel együtt. Az elektronikus adat egyik legfontosabb tulajdonsága, hogy könnyedén sokszorozható, másolható, ahogy az a korábbi sajtcetlis hasonlat alapján már kiderült, ugyanakkor nagyon sérülékeny. További nehezítés, hogy az adatok kezelésére, tárolására szolgáló eszközeink romlandóak. Mi sem tűnik logikusabbnak tehát, mint az, hogy az érzékeny adataimat rendszeresen, lehetőleg minél gyakrabban és minél inkább automatizált formában más fizikai helyre, más adathordozóra másolom, és ezzel adatmentést végzek. A megoldás egyszerűnek tűnik, de általában mégis ennek hiánya okozza a legtöbb, adatkezeléssel összekapcsolható kárt az informatikai rendszerekben. A problémát megfejeli, hogy a tároló eszközeink élettartama a kapacitásuk növekedésével egyenes arányban csökken. Városi legenda, de akár igaz is lehet, hogy a Pioneer 10 szonda első Szaturnusz felvételei érintetlenül pihennek a NASA raktárában valamilyen különleges szalagos adattárolón, mivel nincs már olyan eszköz, amivel meg lehetne nézni, hogy mi van rajtuk. Emberi mulasztás Az előző problémához nagyon közel áll a második, nevezetesen, hogy hogyan, milyen módon történhet az informatikai rendszereink működtetése, illetve mi tilos és szabad, valamint, mit kell megtenniük a felhasználóknak a munkavégzés folyamatai során. Ha konkrétan meg vannak határozva a feladatok, akkor viszonylag könnyen számon is kérhetőek. Ha ezeket a feladatokat olyan helyekről gyűjtöm össze, ahol ez már hosszú idő óta bevált gyakorlatként működik, esetleg publikált és elfogadott eljárásrenddé is vált, akkor túl nagyot nem hibázhatok. Tehát az emberi hibázás lehetőségét és az esetlegességből fakadó problémákat eljárásrendek bevezetése útján tudjuk csökkenteni. Természetesen a máshol bevált, esetleg ajánlásokban, szabványokban leírt eljárásokat is érdemes kritikával kezelni és a saját képünkre formálva átvenni, különben könnyen a klasszikus „Tíz-milliárd légy nem tévedhet!” csapdájába eshetünk, és olyan eljárást alkalmazunk, amely más méretű, kialakítású rendszerre lett tervezze. Belső fenyegetések Az adatlopások, visszaélések több mint 80%-át céges alkalmazott követi el. Még, ha külső fenyegetést tételezünk is fel, sokkal olcsóbb egy nem túl képzett belső embert egyszeri alkalommal lefizetni és zsarolhatóvá tenni, mint nagy tudású biztonsági szakértők csoportját megfizetni, akik tűzfalakon, jogosultsági szinteken és egyéb védelmi berendezéseken IT biztonságról közérthetően Oldal 9 Informatikai biztonsági koncepció keresztül távolról megszerzik a kérdéses információt, amihez egyébként a cég titkárnője, és további húsz ember naponta hozzáfér, dolgozik vele, másolja ide-oda jogszerűen. Másrészt minden munkahelyen, még a legtökéletesebbnek kikiáltottak között is, akadnak emberek, akik jogos, vagy jogtalan sérelmük miatt, esetleg pusztán nyereségvágyból megpróbálnak károkat okozni vagy adatokat eltulajdonítani. Nem is biztos, hogy tevékeny károkozásra kell gondolni, számtalan esetben találkoztam olyan helyzettel, hogy a korábban elbocsátott üzemeltető egyszerűen visszatartott (hivatalosan elfelejtett) bizonyos információkat, jelszavakat, ezzel gyakorlatilag hosszú időszakra ellehetetlenítve a szervezet informatikai működését. A rossz hír, hogy ezek ellen védekezni borzasztóan nehéz. Sajnos a technológia jelen állása szerint, megfelelő ismeretek birtokában a legkiforrottabb adatszivárgást gátló rendszer is megkerülhető, és az üzemeltetés során mindig előfordul, hogy kritikus információ, akár rövid időre, de egy kézben összpontosul. A jó hír, hogy az ilyen esetek által okozott kárt előzetes tervezéssel jelentős mértékben lehet csökkenteni, ami adott szituációban „élet, vagy halál” kérdése is lehet, vagyis a cég működésének folytonossága függhet az előrelátástól. Végezetül ismét egy példa a tervezés fontosságáról: Pénzügyi cég mentései két lépésben készültek. Éjjelente egy köztes szerverre, diszkre másolódtak, majd napközben titkosított formában szalagra íródtak, melyeket napi rendszerességgel külső telephelyre szállítottak. A köztes szerveren tárolt adatokhoz viszont minden üzemeltető (kb. 50 fő), ellenőrzés nélkül hozzáférhetett, a mentett fájlokat bármikor elmásolhatta, hazavihette, és a mentőszoftver letölthető demó verziójával akár a cég összes adatát, ügyfelét, szerződését megszerezhette. Külső fenyegetések Talán a legromantikusabb része az információ-védelemnek, mikor egy rendszert külső támadások ellen kell megvédeni. A legtöbb biztonságtechnikai megoldás ezt a területet célozza, gondoljunk csak a tűzfalakra, vírusirtókra, betörés detektálókra. Számtalan, és a gyártók által tökéletes megoldásnak, továbbá egyaránt piacvezetőnek és kvázi ipari szabványnak kikiáltott berendezésekkel bástyázhatjuk körül védendő rendszereinket. Ha a szokásos marketinges túlzásoktól eltekintünk, akkor is ki kell jelentenünk, hogy ezek a berendezések valóban hasznosak, és valóban jelentős hozzáadott értéket képviselve emelik egy rendszer általános biztonsági szintjét. Ma már nem képzelhető el egy internetre kapcsolt hálózat tűzfalak, gateway-ek és vírusvédelem nélkül. De itt is éppen úgy, mint a házépítésnél, az alapoknál kell kezdenünk az erősítést. Ez pedig a hálózat, az operációs rendszer és a jelszókezelés. Ameddig ezek a területek gyengék, nyitottak, sérülékenyek, addig nem érdemes ezekre épített biztonsági rendszerekben gondolkodni. IT biztonságról közérthetően Oldal 10 Informatikai biztonsági koncepció Az operációs rendszerek és jelszavak kérdése elég pontosan körülhatárolható, a hálózatok nyitottságának kérdése azonban ma egészen mást jelent, mint akár 5 évvel ezelőtt. A wireless kapcsolatok, okostelefonok, VPN kapcsolatok, felhő alapú szolgáltatások világát éljük, sok esetben egyszerűen értelmét vesztette a zárt biztonságos hálózat kifejezés, annyi módon és annyi formában lehet kapcsolódni ma egy hálózathoz. Sajnos ki kell jelenteni, hogy az adott területek biztonsági fejlesztései minden esetben az alkalmazott kommunikációs technológia után járnak; ezért, ha egy vállalati hálózat belső biztonságát kell szavatolni, sokszor a legegyszerűbb (és mindenképpen a legbiztonságosabb) mód ezeknek a szolgáltatásoknak a letiltása, kikapcsolása. Természetesen itt sem szabad végletekben gondolkodni és mindent elvetni, ugyanis ezek a technológiák remekül egyszerűsítik a hivatalos kommunikációt, adatáramlást és munkavégzést. Ezt minden rendszergazda meg tudja erősíteni, aki egy hétvégi hibát VPN-ről bejelentkezve 10 perc alatt megoldott már távolról, ahelyett, hogy órákat autózna miatta a helyszínre és vissza. Ha kizárjuk ezeket az előnyöket, ezzel bele is dugtuk a fejünket a homokba, és a technikai fejlődést jobban követő versenytársak a hatékonyabb munkavégzéssel el is húznak mellettünk. A hosszúra nyúlt bevezető után térjünk a külső fenyegetésekre. Az internet egyelőre az egyik legszabadabb hely világunkban. Ennek jó és rossz oldalát mindenki tapasztalta már, aki a fórumokat, blogokat és a hozzáfűzött kommenteket olvassa. Az információ birtoklása pedig hatalommá és készpénzre váltható haszonná vált, így ki is termelte azokat a bűnöző csoportokat, amelyek erre specializálódtak. A vírusírás 10-12 évvel ezelőtt diákcsíny volt, ma az adatlopás, pénzszerzés és a hatalomgyakorlás egyik legfontosabb eszköze. Az üzletben a különböző országok titkosszolgálatai is benne vannak, gondoljunk csak a Stuxnet vírus közelmúltbeli karrierjére, amelyet eredetileg állítólag az iráni atomerőmű építésének szabotálására fejlesztettek. Napjainkban, a felhalmozott információ, talán a legmeghatározóbb értékké vált egy vállalat életében. Ez az összegyűjtött tudáshalmaz az, amely biztosítja a változó piaci viszonyok mellett is az életben maradás lehetőségét. Ez az, amely markáns különbséget jelent az egyes konkurens vállalatok között, meghatározza a piaci helyzetüket és az ügyfélkapcsolataikat egyaránt. Például, egy gyógyszergyártó és -kutató cég számára az alapkutatások során már egyes molekulák, illetve képletek évekre determinálják a kutatások irányait, és ezek bizalmasságának sérülése komoly anyagi károkat okozhat a vállalat számára illetéktelen előnyökhöz juttatva a konkurenciát. Ezek az érzékeny információk, szinte kivétel nélkül elektronikus formában kerülnek tárolásra a vállalatok informatikai rendszerein. Az illegális adat-kereskedelem legfőbb céljai ma:  Pénzügyi tranzakciókhoz, bankszámlákhoz kapcsolódó információk, mind a pénzintézetek, mind az ügyfelek tekintetében. Oldal 11 IT biztonságról közérthetően Informatikai biztonsági koncepció   Vállalati informatikai rendszereken tárolt információk, leggyakrabban szabadalmak által védett technológiák. Titkosszolgálati információk. Sérülékenységek Éppen úgy, mint a hardver elemek esetében, a szoftverek sem az örökkévalóság számára íródnak. Egy fejlesztő cég, átlag félévente-évente ad ki valamilyen új verziót a termékéből, melyek gyakran több millió soros kódokat tartalmaznak. Ilyen volumenű munka nem képzelhető el hibák nélkül. Közismert, és hosszú, debuggolással töltött éjszakák tanulságán kikristályosodott szokása a komolyabb rendszerintegrátoroknak, hogy frissen kiadott, új verziójú szoftvereket nem telepítenek kritikus környezetekben. Előtte kisebb ügyfeleknél tesztelik a működést, de inkább megvárják az első javító csomag kiadását. A hibák kezelése, javításának folyamata be van építve a fejlesztő cégek működésébe, a javító csomagok kiadása, terjesztése, telepítése külön iparággá nőtte ki magát. Külön figyelmet érdemel a javítások telepítése a meglévő, működő alkalmazásaink üzemben tartásának kérdésével összhangban. Sajnos számtalanszor találkozni olyan működő és igen kritikus alkalmazásokkal, melyek alatt az operációs rendszer nem frissíthető, mert az alkalmazás fejlesztője ezt nem támogatja. Ez minden esetben tipikus patthelyzet, ami általában addig marad fenn, amíg az egész rendszer egyszer csak egy szerencsétlen pillanatban végleg meg nem áll, ezzel természetesen újabb váratlan problémákat okozva. Talán ebből is látszik, hogy a javítások telepítése kritikus kérdés a hálózatok működése során. Éppen ezért nem lehet azt megtenni, hogy az egész problémát a szőnyeg alá söpörve inkább nem telepítünk soha frissítéseket. Ugyanis ezek általában egy-egy biztonsági rést foltoznak be a rendszerünkön, melyek, amíg nyitva vannak, szabad bejárást biztosíthatnak az arra járóknak rendszereinkbe. Tudomásul kell venni, hogy a nem frissített rendszer nem nyújt védelmet, és a drága pénzért rátelepített biztonsági berendezések hatékony működését is jelentős mértékben rontja. Tipikus példa, hogy ha egy vírus egy operációs rendszer vagy alkalmazás sérülékenységét használja ki, a legtöbb vírusirtó mellett akadálytalanul képes megfertőzni a rendszert. Erre talán legjobb példa a 2011 márciusában történt RSA SecurID-k ellopása, mely azután amerikai védelmi szervezetek és kritikus ipari vállalatok elleni támadásokhoz is lehetőséget nyújtott. Ez a támadás egy ismert Adobe Flash sebezhetőség kihasználásával indult egy RSA felhasználó gépén és az utóbbi évek legnagyobb biztonsági botrányává dagadt. A régi vers igazsága újra bebizonyosodott: Egy szeg miatt a patkó elveszett. A patkó miatt a ló elveszett. A ló miatt a csata elveszett. A csata miatt az ország elveszett. Verd be jól azt a patkószeget! IT biztonságról közérthetően Oldal 12 Informatikai biztonsági koncepció Az operációs rendszerek biztonságának másik sarokköve a jogosultságok kezelése. A jogosultságok pontos kiosztásával tudjuk meghatározni, hogy ki, milyen adathoz, rendszerhez, erőforráshoz, vagy szolgáltatáshoz milyen módon férhet hozzá. Talán nincs is az informatikai biztonságnak még egy ennyire mindenre kiterjedő kérdése. Ez az eszköz ott van minden jelenleg használt operációs rendszerben és komolyabb alkalmazásban, továbbá standard eszközökkel megkerülhetetlen, csak élni kell tudni vele. Ennek ellenére a fel nem telepített sérülékenységek mellett ez a másik legnagyobb oka annak, hogy egy rendszer kompromittálódik. Számtalan rosszul beállított web-szerver mesélhetne erről. Tipikus hiba itt is a tervezés hiánya, illetve a nagyvonalú konfigurálás. Ha a kiosztott jogosultságok nem csak a szükséges minimumra korlátozódnak, onnantól kezdve a helyzet megegyezik azzal, mintha nyitott autót hagynánk gazdátlanul valamilyen elhagyott mellékutcában. A hozzáférések kérdésének másik sarokköve a jelszavak kezelése. Erről mindenkinek vannak jó és rossz tapasztalatai. A sebezhetőséget általában a gyenge, könnyen visszafejthető jelszavak adják, de ugyanilyen lényeges a jelszavak biztonságos kezelése és időszakonkénti változtatása. Persze ezt is ésszel kell bevezetni, ha megköveteljük a felhasználóktól, hogy kéthetente változtassák a bonyolult jelszavaikat, ne csodálkozzunk, ha a kinyomtatott „jelszónaptárt” találunk a faliújságon. A jelszavak kezelésének leggyakoribb problémája a jelszavak hálózati továbbításának kérdése. Tudomásul kell venni, hogyha egy alkalmazás hálózati bejelentkezést igényel és a felhasználónév/jelszó páros titkosítás nélkül halad át a hálózaton, akkor az lehet bármilyen bonyolult, szinte olyan, mintha nem is lenne. Sajnos, egyáltalán nem lehetetlen ezeknek az adatoknak a megszerzése egy hálózathoz kapcsolt harmadik gépről. Itt is alapszabály, hogy ha egy adat olvasható, akkor másolható, ha másolható, akkor fel is használható. A tipikus műszaki sérülékenységeket általában ezen területek mentén szokták felkutatni. A leginkább elterjedt és legtöbbször kihasznált sebezhetőség azonban az emberi tényező. A keresett információt legegyszerűbben úgy tudjuk megszerezni, ha megkérdezzük attól, aki tudja. Ez persze nem kifejezetten személyes, vagy telefonos beszélgetést igényel, jelenthet hamis emaileket, szemétben hagyott papírok elemzését, vagy akár fertőzött pendrive-ok becsempészését. Ennek kivédése komoly felhasználói tudatosságot igényel, melyet alapvetően a felhasználók oktatásával és megfelelő vállalati kultúra kialakításával lehet elérni. (A COBIT keretrendszer, mely egy széles körben elfogadott módszertant ad informatikai rendszerek irányításához un. érettségi modellt nyújt a vállalatok számára, mely alapján a vezetők tisztában lehetnek a cégük állapotával, fejlődési irányaival. Az egyes érettségi szintek fontos ismérve a megfelelő vállalati kultúra kialakítása.) IT biztonságról közérthetően Oldal 13 Informatikai biztonsági koncepció A védelem területei Az informatikai biztonság alapvetően az információ biztonságát hivatott növelni. Az információnak három biztonsági tulajdonsága van: 1. bizalmasság 2. sértetlenség 3. rendelkezésre állás Az információ védelmének tervezése, kialakítása, és fenntartása során alapvetően ezekre a tulajdonságokra kell koncentrálni. Bizalmasság Az információ bizalmasságának védelme során a feladatunk, hogy gondoskodjunk arról, hogy az információhoz csak az férhessen hozzá, akit erre feljogosítottak. Sértetlenség Az információ sértetlenségének védelme során a feladat, hogy gondoskodjunk arról, hogy az információ az eredeti állapotának feleljen meg. Az információt csak az arra jogosultak változtathatják meg, és azok véletlenül nem módosulhatnak. Ez a programokat is érinti, mivel az adatok sértetlenségét csak rendeltetésszerű feldolgozás és átvitel esetén lehet biztosítani. A sértetlenség fogalma alatt gyakran értik a teljességet, továbbá az ellentmondás mentességet és a korrektséget, együttesen: integritást. Az integritás ebben az összefüggésben azt jelenti, hogy az információ valamennyi része rendelkezésre áll, elérhető. Rendelkezésre állás Rendelkezésre állás alatt a védendő rendszer olyan állapotát értjük, amikor is az informatikai rendszer szolgáltatásai - amely szolgáltatások különbözők lehetnek - állandóan, illetve egy meghatározott időben rendelkezésre állnak, és a rendszer működőképessége sem átmenetileg, sem pedig tartósan nincs akadályozva. Védelmi eljárások A védelmi eljárások alapvetően két fő csoportba sorolhatóak:   Az emberi tevékenységre alapuló eljárásokra, Illetve a technológiákra alapuló megoldásokkal. Természetesen ez egy nagyon durva felosztás, és a két terület szinte minden szempontból összefügg egymással. De alapvetően akkor is megkülönböztetünk egy eljárásrendet, amit a felhasználóktól és az üzemeltetőktől megkövetelünk a mindennapi munkájuk során, illetve IT biztonságról közérthetően Oldal 14 Informatikai biztonsági koncepció egy olyan technológiai környezetet, melynek minden elemében meg kell felelnie az előre meghatározott igényeknek. A kulcsszó, illetve kifejezés ebben az esetben is az „előre meghatározott”. Ez egyaránt kell, hogy vonatkozzon a folyamatokra és eljárásrendekre és az alkalmazott technológiákkal szemben támasztott követelményekre. Életciklus modell A működési és védelmi eljárások, valamint technológiai megoldások esetében is előkerül a változó környezet problémája. Egy dinamikusan változó környezetbe statikusan beillesztett, „megkövesedett” eljárásrendek és a produktív környezet változásait nem követő biztonsági technológiák semmilyen hozzáadott értékkel nem bírnak. Ellenben a változó környezettel összhangban lévő szabályozás és technológia alapú védelem minden körülmények között fenntartja a védendő rendszer biztonsági szintjét. Az üzletmenet és biztonsági szint kialakítása és fenntartása ebből a szempontból a sízéshez hasonlítható: 1. Első lépés a rendszer felépítése, illetve a sífelszerelés kiválasztása, beállítása, tesztelése. 2. Majd következik az éles üzem, mikor a rendszerek működni kezdenek, a síző pedig elindul a lejtőn. Ennek során állandóan és dinamikusan kell reagálni a változatos viszonyokra és a megjelenő akadályokra, a helyzethez leginkább illő technikai elem kiválasztásával és alkalmazásával. Ha az üzemidő végén, illetve a pálya alján a rendszerek is és a síző is áll a lábán, akkor győztünk. Ezt az életciklus modell szemlélteti: Ábra: Életciklus modell IT biztonságról közérthetően Oldal 15 Informatikai biztonsági koncepció A modell célja, hogy az elkészített és működő rendszereket, kapcsolódó szabályzatokat és eljárásrendeket folyamatos ellenőrzésnek, auditnak vesse alá, továbbá reagálni tudjon a külső hatásokra, új technológiákra, igényekre, melyek eredményének kiértékelése, elemzése alapján a szükséges módosítások, fejlesztések meghatározhatók és végrehajthatók. A modell lényeges elemei a Kockázatok elemzése, a Tervezés, és az Oktatás, illetve a folyamatos megfigyelés eredményeinek visszacsatolása. Ezek nélkül elképzelhetetlen hatékony és megbízható informatikai biztonsági rendszer kialakítása és üzemeltetése. A modell által nyújtott szemlélet bármilyen biztonsági fejlesztés esetében alkalmazható, és valós védelem elérése érdekében szükséges is az alkalmazása. Kockázatok meghatározása Időszámításunk előtt 500 évvel élt kínai hadvezér és hadtudós Szun Ce egyik leghíresebb mondása szerint: „Ha ismered magad és ismered az ellenségedet, 100 csatában sem esik bántódásod. Ha ismered magad, de nem ismered az ellenséged egyenlők az esélyeitek. Ha nem ismered egyiket sem, biztos vesztes vagy.” Lehet, hogy furcsán hangzik, de egy biztonsági rendszer tervezésekor ugyanezeket az elveket kell szem előtt tartani. Ha informatikai biztonsági rendszert tervezünk, akkor az első lépésnek kell lenni a védendő értékek meghatározásának. Értelemszerűen így fogjuk tudni, hogy mit akarunk egyáltalán védeni. Második lépésben viszont a kockázatokat kell felmérni, súlyozni és lehetőleg kezelni. Különben fogalmunk sem lesz, hogy mi ellen kell egyáltalán védekeznünk, és mekkora energiát fektessünk a védekezésbe. Az elv az, hogy a feltárt és védendő értékeinkhez rendelt kockázatok kiértékelése után pontosan meg tudjuk mondani, hogy az egyes kockázatok milyen gyakorisággal fordulhatnak elő, és mekkora kárt tudnak okozni, ha mégis bekövetkeznek. Mivel már tisztában vagyunk a védendő értékeinkkel és azok valódi értékével, az eredményből egyértelműen megtudhatjuk, hogy mennyi energiát érdemes fektetnünk az egyes kockázatok elleni védekezésbe. Az elv jól hangzik, az eredmény kiszámítása azonban sajnos távolról sem olyan egyszerű, mint ahogy ezt elképzeljük. A kockázatok meghatározásának és elemzésének is több módja, módszertana van, természetesen mindegyik rendelkezik előnyökkel és hátrányokkal. IT biztonságról közérthetően Oldal 16 Informatikai biztonsági koncepció Kvantitatív kockázatelemzés Az amerikai szabvány alapján működő kvantitatív kockázatelemzési módszertan pontosan meghatározott értékekkel számol. A vagyontárgy értéke x Kitettségi mutató = Egyszeri bekövetkezési veszteség x Éves bekövetkezési valószínűség = Várható éves kár2 Ez azonban feltételezi, hogy a bemeneti értékek pontosan megadhatóak. Ha ezeket nem tudjuk egzaktan meghatározni, a számolt értékek nem fogják fedni a valóságot. A legnagyobb probléma, hogy a bemeneti értékek nagyon nehezen és viszonylagosan határozhatók meg. Ezt egy konkrét, megtörtént példával tudom legjobban szemléltetni: Audit során egy kritikus rendszer működéskieséséből fakadó károkat kell felmérni. Arra a kérdésre, hogy mekkora számszerűsíthető kárt okoz, ha a rendszer 1 órát áll, több különböző válasz is érkezett:    Adatgazda, az üzleti oldalról: A rendszer 1 óra állása nagyságrendileg 10 millió Ft. kiesést jelent az üzleti folyamatokban. Üzemeltetés vezetője: A rendszer 1 órás kiesése nem jelent problémát, de 3 órás kiesés már nem elfogadható. Üzemeltető: A múlt hónapban kétszer fél napot állt a szolgáltatás. Észre sem vette senki. A példa sajnos nem egyedi. Az informatikai kockázatok súlyozásának nehézsége pontosan ebből fakad. Kvalitatív kockázatelemzés Az ausztrál szabványon alapuló kvalitatív kockázatelemzési módszertan pontosan olyan esetekre lett kitalálva, mikor nem tudunk egyértelmű bemeneti értékekkel számolni. A számítás ebben az esetben is a védendő értéken és a bekövetkezési valószínűségen alapul, azonban az egyes értékek nem pontos (forintosított) számokkal, hanem kvalitatív skálákon kerülnek meghatározásra. Ez valójában ezt jelenti egy háromfokozatú skálán: Gyakorisági értékek: ritka, közepesen gyakori, nagyon gyakori. Kárérték: Alacsony, közepes, magas kár. Természetesen ezekhez a kifejezésekhez tól-ig idő-, és értékskálát rendelünk és ezeket egy mátrixba rendezzük, hogy megkapjuk a kockázati értékeket. Ez piciben így néz ki: 2 (Krasznay) IT biztonságról közérthetően Oldal 17 Informatikai biztonsági koncepció Kárérték Magas kár Közepes kár Alacsony kár Gyakoriság Nagyon gyakori Magas Kockázat Magas Kockázat Közepes Kockázat Közepesen gyakori Magas Kockázat Közepes Kockázat Alacsony Kockázat Ritka Ábra: Kockázati mátrix Magas Kockázat Alacsony Kockázat Alacsony Kockázat Az így kapott mátrix alapján szépen összerendeljük a feltárt kockázatokat a várható gyakorisági értékekkel és a fenyegetett elem értékével. Rögtön látjuk, hogy ha bekövetkezik egy kockázati esemény, az várhatóan mennyire fog nekünk fájni. Jól hangzik, de egy probléma még megoldásra vár: Honnan találjuk ki, hogy milyen kockázatok fenyegethetnek bennünket? Ez a kockázatelemzés igazi sava-borsa, ennek megállapításához kell tapasztalat, rendszerismeret, különböző konfigurációkkal, folyamatokkal és eljárásrendekkel való piszmogás. De ebben is van két fő csapásirány, amely jelentősen képes megkönnyíteni a dolgunkat, és mégis használható eredmény kerül a birtokunkba. Fenyegetések feltárásán alapuló kockázatfeltárás Ebben az esetben, hogy célt érjünk, gyakorlatilag fel kell tárni a rendszereket veszélyeztető összes fenyegetést és azok összes lehetséges következményét. Sajnos ez gyakorlatilag lehetetlen vállalkozás, mivel az egyes fenyegetések többféle káresetet is okozhatnak, melyek száma kellően komplex rendszerek esetében akár a végtelen felé is konvergálhat. Szabványokon alapuló kockázatfeltárás Az előző módszerrel ellentétben, ebben az esetben a védendő értékekre koncentrálunk és a biztonsági szabványoknak való megfelelést tekintjük a fő szempontnak. A vizsgálat fő iránya arra vonatkozik, hogy az adott rendszer működése, folyamatai és üzemeltetése megfelelneke az adott szabvány előírásainak. Természetesen itt sem szabad végletekben gondolkodni. A szabványoknak való megfelelés ellenőrzésén túl részletesen fel kell tárni a rendszerek beállításait, kapcsolatait és a IT biztonságról közérthetően Oldal 18 Informatikai biztonsági koncepció kapcsolatok típusait, gyengeségeit, továbbá meg kell vizsgálni a rendszer üzemeltetésével kapcsolatos folyamatokat. Csak így kaphatunk használható eredményt. A Kockázatelemzés precíz elkészítése különösen fontos, mivel a szabályzatrendszer több része is az itt feltárt eredményekre épít, tehát, ha az itt lefektetett megállapítások pontatlanok, az nagyon visszaüthet egy katasztrófa helyzetben vagy az üzletmenet sérülésekor. A leírt módszertanok természetesen messze nem a teljesség igényével kerültek ismertetésre, igyekeztem a lényeget kiemelni és könnyen érthető formába önteni. Az itt ismertetett kockázatelemzési módszereken túl sok egyéb, használható módszer is forgalomban van, továbbá az egyes iparágak mind-mind saját kockázatelemző módszertant használnak. Kockázatok kezelése Beszélnünk kell a kockázatok kezeléséről is, hiszen nem elég tudni, hogy mi fenyegethet bennünket, érdemes egy ütemtervet és stratégiát készíteni, hogy az adott kockázatokkal mit is fogunk kezdeni. Először is vegyük számba, hogy milyen lehetőségeink vannak a kockázatok kezelésére: 1. A kockázat figyelmen kívül hagyása: Kizárólag alacsony kárértékű, ritkán bekövetkező kockázatok esetében fordulhat elő, ha a védelmi intézkedések az okozott kárt meghaladó erőforrásokat igényelnek. 2. Az előfordulás valószínűségének csökkentése: A kockázatkezelés egyik leggyakoribb formája a bekövetkezési valószínűség alacsony szintre történő csökkentése. (Ne felejtsük el, hogy 100%-os védelem nem létezik.) 3. Kockázat következményeinek csökkentése (kárenyhítés): A kockázatkezelés másik leggyakoribb formája, melynek révén az okozott kár mértéke kerül csökkentésre. 4. Kockázat áthárítása harmadik félre: A kárenyhítés egy formája, melynek révén a kockázat csökkentését nem saját erőforrásból végezzük, hanem harmadik félre hárítjuk át. 5. Kockázat felvállalása: Kizárólag alacsony kárértékű, vagy nagyon ritkán bekövetkező kockázatok esetében fordulhat elő, ha a védelmi intézkedések az okozott kárt meghaladó erőforrásokat igényelnek. A lehetőségeink számbavétele után priorizálnunk kell a feltárt kockázatokat. Sajnos a rendelkezésre álló erőforrások (pénz, paripa, fegyver) végesek, és nem mindegy, hogy mire fordítjuk ezeket. Egy szélsőséges példával illusztrálva: Ha a kockázatelemzés megállapítja, hogy ég a háztető és fonnyadtak a virágaink, akkor rögtön tudjuk, hogy mire fogjuk a vizünket használni. Meg kell határoznunk a védelmi intézkedéseket, melyek három alapvető csoportba sorolhatóak: 1. Preventív: a megelőzésére irányuló cselekmények. 2. Detektív: a felderítésére irányuló cselekmények. IT biztonságról közérthetően Oldal 19 Informatikai biztonsági koncepció 3. Korrektív: az esemény bekövetkezése utáni elhárításra, helyreállításra irányuló cselekmények. Az intézkedések ilyen csoportosítása PreDeCo-elv néven is ismert. A konkrét védelmi intézkedések megfogalmazásához érdemes az alábbi alapelveket figyelembe venni: 1. A feltárt kockázat elleni védekezésre nem szabad többet költeni, mint amekkora kárt a nem kívánt kockázati esemény bekövetkezése okoz. 2. A védelmi megoldás teljes körű legyen. 3. Egyenszilárdságú megoldásra kell törekedni. 4. A védelmi folyamatoknak ellenőrizhetőknek kell lennie, valós biztonságot kell nyújtania az adott fenyegetéssel szemben. 5. A védelmi megoldás lehetőség szerint illeszkedjen a meglévő infrastruktúrába, illetve a meglévő folyamatokba. 6. A védelmi megoldás ne akassza meg az üzleti folyamatokat. 7. A védelmi megoldásoknak meg kell felelni a vonatkozó törvényi előírásoknak (ha vannak ilyenek). Szabályzat alapú eljárások, védelmi intézkedések Ha nem tudjuk előre lefektetni, hogy egy folyamatban kinek, mit, hol, hogyan, milyen szabályok mentén kell elvégezni, azt milyen visszacsatolásokon keresztül, ki, és hogyan ellenőrizheti, továbbá az eredményhez ki, milyen formában férhet hozzá, akkor az egész informatikai rendszer és az üzleti folyamatok is esetlegesen, ad-hoc módon fognak működni. Amíg minden működik, addig ez nem is biztos, hogy probléma, bár a spontán kialakult rendszerek esetében mindig felmerül a gyanú, hogy nem lehetne-e a folyamatokat hatékonyabban megtervezni, és kevesebb erőforrás igénybevételével elvégezni. Ennek látszólag ellentmond a legrégebb óta működő, legsikeresebb, spontán folyamat, az evolúció. Senki nem állíthatja azonban, hogy ott minden a legtökéletesebben működik. Aki nem hiszi, kérdezzen meg valakit, aki már túl van egy vakbélgyulladáson. Az informatikai szabályzatok ideális esetben pontosan ezekre az előző bekezdésben felvetett kérdésekre adják meg a válaszokat a legfelső szinttől kezdve, egészen a rendszerekkel kapcsolatos egyes tevékenységekig lebontva. Ha informatikai szabályzatokra gondolunk, általában száraz és unalmas írásművek jutnak eszünkbe, melyek köszönőviszonyban sincsenek a valósággal, és nincs más szerepük, mint az IT vezető fiókjában, vagy polcán kitölteni a rendelkezésre álló teret. Nem tudok leszámolni ezzel a képpel, az IT szabályzatok tényleg száraz és unalmas írásművek. Ráadásul, ha készítéskor nem vették messzemenőkig figyelembe a vállalat működési sajátosságait, vagy ha elavult és nem aktualizálják, akkor az egész elkészítés értelmetlen pénzkidobás volt. Ha azonban széleskörű vizsgálatok alapján, értelmes, a valóságot leíró eljárások kerültek bennük IT biztonságról közérthetően Oldal 20 Informatikai biztonsági koncepció kidolgozásra, akkor pontosan azt a célt szolgálja, mint egy kisdiák számára a sorvezető: megmutatja a munkavégzés kereteit, és visszacsatolást ad a hibákról. További előnye, hogy pontosan definiálja a feladatokat és felelősségeket, így egy kritikus helyzetben védelmet nyújt a munkáját pontosan elvégzőnek, nem lehet egymásra mutogatva elkenni a felelősséget. A szabályzatok elkészítésekor felmerül a kérdés, hogy miért van szükség több szabályzatra? Természetesen lehetőség van mindent egyetlen szabályzatban leírni, de a gyakorlat azt mutatja, hogy érdemes egymásra épülő, független szabályzatrendszert készíteni, mert minden szabályzat másnak és másról szól. Ráadásul az egyes részletek mindenki által publikussá tétele egyáltalán nem szolgálja a biztonságot, hiszen a részletes üzemeltetési eljárások semmiképpen nem tartoznak a felhasználókra, ugyanis olyan elemeket és információkat is tartalmazhatnak, melyek illetéktelen kezekben ártalmasak is lehetnek. A mentési rendszer, a vírusvédelem, a tűzfal típusa, továbbá a belső infrastruktúra részletes beállításai, melyek az egyes Üzemeltetési eljárásokban szerepelhetnek, szintén nem a felhasználókra tartoznak. A szabályzatok életciklusa Ahogy korábban szó volt róla, az informatikai környezetek egyáltalán nem tekinthetők statikus képződményeknek, hanem sokkal inkább organikusan fejlődő, állandóan változó, egymással kapcsolatban lévő rendszerek halmazának. Könnyen belátható tehát, hogy egy elkészített szabályzat mindössze egy pillanatképet ad a készítés idején meglévő állapotokról és folyamatokról. Az idő múlásával viszont a szabályzat folyamatosan veszít aktualitásából, a benne leírt folyamatok, eljárások érvényüket vesztik. Ennek a problémának a feloldására két lehetőség nyílik: 1. Rendszeres időközönként (kb. 2 évente) aktualizálni kell az elkészített statikus szabályzatrendszert. 2. A dokumentum alapú szabályzatrendszert egy erre a célra fejlesztett alkalmazással helyettesítjük, melybe az új elemeket folyamatosan át tudjuk vezetni, és bizonyos paraméterek megadása mellett a szoftver automatikusan képes az aktualizálásra. Természetesen ezzel a megoldással csak bizonyos komponensek frissíthetők, a teljes rendszerre nem alakítható ki. Általában a Kockázatelemzés, Katasztrófa elhárítási Terv, illetve Üzletmenet-folytonossági Terv kezelhető ilyen dinamikus formában. Mindkét megoldás több előnnyel és hátránnyal rendelkezik. Általában kisebb, illetve közepes infrastruktúrával rendelkező cégek számára az első megoldás az ideális, ugyanis a szoftveres karbantartás nyilvánvaló előnyei mellett állandó felügyeletet és szakértői kezelést igényel, különben nem éri el a célját. IT biztonságról közérthetően Oldal 21 Informatikai biztonsági koncepció Szabályzatok betartása és betartatása Semmit nem ér az a szabályozás, amit nem tartanak be azok, akiknek szól. Az előírt eljárások betartásának legegyszerűbb módja, hogy eleve betartható folyamatokat tervezünk és írunk elő a szabályzatban. Ezt nagyon könnyű így leírni, de annál nehezebb megvalósítani. Tény ugyanis, hogy az üzemeltetők feladatait az adott pillanatban(!) általában nehezíti és bonyolítja, ha a szabályzatokban leírt módon jár el. Közismert tény, hogy az igazán jó rendszergazda két legfontosabb jellemzője, hogy lusta és okos. Lusta, mert szívesebben veszi, ha a feladatai automatizáltan, maguktól végrehajtódnak, és okos, mert ezt meg is tudja valósítani. A szabályzatokban leírt eljárásrendek ezzel a mentalitással szemben, sokszor bürokratikus szellemiséget igényelnek. A dokumentálás és az ellenőrzési eljárások előnye ugyanis csak hosszútávon mutatkozik a rendszerek működésének átláthatóságában és legtöbb esetben a rendelkezésre állás növekedésében. A tapasztalatok alapján az üzemeltetőket abban az esetben lehet szívvel-lélekkel a szabályzatok mellé állítani, ha az alábbi feltételek teljesülnek: 1. Az üzemeltetőket aktívan be kell vonni az eljárásrendek kialakításába. 2. Az elkészült szabályzatok és eljárásrendek oktatásra kerülnek, és az oktató valódi, elmélyült üzemeltetési tapasztalatokkal rendelkezik (egy nyelvet beszélnek). 3. Az oktatás során megértik, hogy a szükséges bürokrácia közép- és hosszútávon a saját érdekük, mert hatékonyabbá teszi a munkájukat. IT biztonságról közérthetően Oldal 22 Informatikai biztonsági koncepció Az informatikai szabályzatok logikai rendszerét és egymásra épülését az alábbi ábra mutatja: Informatikai szabályzatrendszer Kockázatelemzés és kezelés Katasztrófa elhárítási Tervek Informatikai Üzemeltetési Politika Informatikai Biztonsági Politika Informatikai Fejlesztési Politika Üzletmenet folytonossági Tervek Informatikai Üzemeltetési Szabályzat Informatikai Biztonsági Szabályzat Informatikai Fejlesztési Szabályzat Üzemeltetési eljárásrendek Biztonsági eljárásrendek Fejlesztési eljárásrendek 1. ábra: Informatikai szabályzatrendszer Az ábra nem teljes körű, a legtöbb esetben külön szabályzat és eljárásrend készül a változáskezelésre. Nem a szabályzatokhoz tartozik, de meg kell említeni az Informatikai Stratégiát is, mely közép- és hosszútávon határozza meg a fejlesztési irányokat és elképzeléseket. Az eddig leírtak összefoglalásaként kijelenthetjük, hogy az informatikai folyamatok, tevékenységek szabályozása esetén:     ellenőrizhető, számon kérhető, szabványokra épülő, meghatározható kockázati és biztonsági szintet szavatoló eljárásrend kerül kialakításra. A további fejezetekben részletesen kifejtésre kerül, hogy mire szolgálnak az egyes szabályzatok. IT biztonságról közérthetően Oldal 23 Informatikai biztonsági koncepció Informatikai Biztonsági Politika A Politika tekinthető a szabályzatrendszer csúcsának, pont úgy, mint a jéghegy esetében a vízből kiálló rész. Ez a legrövidebb, legáltalánosabb, szinte csak elveket, a cél iránti elkötelezettséget megfogalmazó anyag. Terjedelme általában néhány oldal mindössze. Legfőbb célja, hogy az adott szervezet egésze nevében „hitet” tegyen a mellett, hogy elkötelezett a kérdéses területek egységes szabályozásának kialakítására. Alapvetően vezetői döntéseket és alapelveket megfogalmazó dokumentum. A részletekkel majd az alsóbb szintű szabályzatok, eljárásrendek foglalkoznak. Rögtön felmerülhet a kérdés, hogy miért is van erre szükség? Ezt egy rövid példával lehet a legjobban megmagyarázni: Orwell óta tudjuk, hogy minden állat egyenlő, de vannak egyenlőbbek. Ha ezt a desktop üzemeltetés nyelvére lefordítjuk, azt kapjuk, hogy mindig a főnöknek van a legjobb gépe, de mégis mindig azzal van a legtöbb baj. Ennek sajnos pontosan megfogható okai vannak, aminek megértéséhez Murphy idézetekre sincs szükség. Ez azért van így, az esetek legnagyobb részében, mert a főnök általában azt tehet a notebookján, amit akar (és sajnos otthon a kisfia is), a többiek esetében pedig szigorú jogosultsági szabályok vannak érvényben a telepítésre és konfigurálásra vonatkozóan. Természetesen nem állítható, hogy egy szépen megfogalmazott Biztonsági Politika tökéletesen megoldja ezt a helyzetet, de bizonyos esetekben visszatartó erővel bír a felső vezetés egyedi igényeit illetően. Ezt ideális esetben egy külön oktatás segítheti elő, kifejezetten a vezetőség részére. Informatikai Biztonsági Szabályzat Az Informatikai Biztonsági Szabályzat a szabályzatrendszer legtartalmasabb darabja. Több területet is átfog, és minden feldolgozott témakörben meghatározza és szabályozza azokat az eljárásokat, melyek mentén az adott területre vonatkozó feladatokat el kell végezni. Az IBSZ tehát, a politikához képest, egy alacsonyabb szintű, részletesebb szabályzat, amely olyan gyakorlati kérdésekre fókuszál, melyek már konkrét cselekvési mintákat határoznak meg. Feladata, hogy lefedje az összes olyan területet, mely valamilyen módon az informatikai biztonsághoz kapcsolódik és meghatározza az adott terület feladatainak elvégzésére vonatkozó peremfeltételeket. Nem kizárólag feladatok megfogalmazása, hanem a szervezeti struktúra felrajzolása is az IBSZ témakörei közé tartozik. Ezen belül, talán a legfontosabb terület az Informatikai Biztonsági Felügyelő szerepkörének meghatározása. Az Informatikai Biztonsági Felügyelő feladata, hogy az üzemeltetési feladatokat és folyamatokat ellenőrizze. A szervezeti struktúrában éppen ezért nem tartozhat az informatika alá, hanem csak és kizárólag a felsővezetők alá tagozódik be. Felülvizsgálati jogot kell számára biztosítani az ellenőrzések elvégzéséhez, részletes feladatait az alsóbb szintű szabályzatok definiálják. Az IBSZ az alábbi területeket fedi le: IT biztonságról közérthetően Oldal 24 Informatikai biztonsági koncepció Az Informatikai Biztonsági Szabályzat célja Az Informatikai Biztonsági Szabályzat hatálya Hivatkozások jogszabályok, előírások 1.1 1.2 1.3 Törvényi előírások Belső utasítások Hazai és nemzetközi ajánlások Az informatikai biztonság szabályozó elemei 1.4 1.5 Informatikai biztonsági dokumentációs rendszer Az Informatikai Biztonsági Szabályzat karbantartása Az informatikai biztonság a szervezeti felépítésben 1.6 1.7 Informatikai biztonsági szerepkörök Az informatika biztonságához kapcsolódó szerepkörök 1.7.1 Informatikai osztály vezetője 1.7.2 Műszaki Igazgatóság vezetője 1.7.3 Informatikai Biztonsági Felügyelő 1.7.4 Informatikai biztonsági megbízott 1.7.5 Biztonsági adminisztrátor 1.7.6 Rendszergazda 1.7.7 Jogosultsági-rendszer adminisztrátor 1.7.8 Felhasználó 1.8 1.9 1.10 1.11 Informatikai biztonsági szempontok a munkavállalók alkalmazása során Biztonsági osztályba sorolás Oktatás, képzés és a biztonságtudatosság fokozása Az informatikai biztonság érvényesítése 1.11.1 Informatikai biztonsági felülvizsgálatok rendje IT biztonságról közérthetően Oldal 25 Informatikai biztonsági koncepció 1.11.2 Biztonsági események kivizsgálása, felelősségre vonás 1.12 Kiszervezés (outsourcing) Fizikai és környezeti biztonság 1.13 1.14 Általános követelmények Biztonsági zónák 1.14.1 A géptermi zónára vonatkozó fizikai biztonsági követelmények 1.14.2 A géptermi zónára vonatkozó környezeti biztonsági követelmények 1.14.3 Informatikai eszközök objektumból, telephelyről történő kivitele Üzemeltetés és kommunikáció 1.15 Üzemeltetési eljárások és felelősségi körök 1.15.1 Rendszerdokumentációk és dokumentált üzemeltetési eljárások 1.15.2 Változáskezelés 1.15.3 Biztonsági események kezelése 1.15.3.1 1.15.3.2 1.15.3.3 1.15.3.4 1.15.3.5 Informatikai biztonsági események jelentése Informatikai biztonsági események kivizsgálása, bizonyítékok gyűjtése Informatikai biztonsági események nyilvántartása A biztonsági eseményekkel kapcsolatos egyéb eljárások Intézkedések a káresemények bekövetkeztekor 1.15.4 Feladat és felelősségi körök szétválasztása 1.15.5 Üzemeltetési, fejlesztési és teszt környezet szétválasztása 1.16 Programozott fenyegetés elleni védekezés 1.16.1 Vírusvédelemmel kapcsolatos védelmi intézkedések 1.16.2 A vírusvédelemi eszközök 1.17 Rendszerfelügyelet és napi teendők 1.17.1 Archiválás, mentés és munkamásolat készítése 1.18 Adathordozók kezelése és biztonsága Oldal 26 IT biztonságról közérthetően Informatikai biztonsági koncepció 1.18.1 A tároló helyiségekre vonatkozó előírások 1.18.2 Az adattárolási előírások 1.18.3 Az adathordozók használati rendje 1.18.4 Adathordozók biztonsága a szállítás során 1.18.5 Az adathordozók nyilvántartása 1.19 1.20 Üzemeltetői naplók Hálózatmenedzsment 1.20.1 Tűzfal és hálózati rendszerkörnyezet kialakítása 1.20.2 Tűzfal és hálózati rendszer üzemeltetése 1.21 Szoftver- és információcsere 1.21.1 A külső adatkapcsolatok szabályozása 1.21.1.1 1.21.1.2 1.21.1.3 1.21.1.4 Off-line adatkapcsolat Az on-line adatkapcsolat Modemes kapcsolat létesítése Adatforgalmi munkaállomás 1.21.2 E-mail és Internet biztonságos és etikus használatának szabályai 1.22 1.23 Nyilvánosan hozzáférhető rendszerek Egyéb üzemeltetéssel kapcsolatos eljárások nyomtatása, fénymásolása, a papír alapú adathordozók 1.23.1 Érzékeny adatok megsemmisítése Hozzáférés szabályozás 1.24 1.25 Hozzáférési szabályok kialakítása Felhasználói hozzáférések kezelése 1.25.1 Ideiglenes hozzáférési jogosultságok 1.26 Felhasználói felelősségek megállapítása 1.26.1 Felhasználói jelszavak gondozása IT biztonságról közérthetően Oldal 27 Informatikai biztonsági koncepció 1.26.2 Informatikai eszközök felügyelete 1.26.3 Munkaállomásokon tárolt adatok mentése 1.26.4 Hálózati hozzáférések kezelése 1.26.5 A kapcsolódási útvonal kikényszerítése (enforced path) 1.26.6 Osztott könyvtárak és fájlszerverek 1.27 1.28 1.29 Operációs rendszerhez való hozzáférés szabályozása Alkalmazói rendszerekhez való hozzáférés szabályozása Rendszerhozzáférések ellenőrzése, monitorozása 1.29.1 Események naplózása 1.29.1.1 1.29.1.2 1.29.1.3 Naplózási beállítások Naplóállományok megőrzése Rendszeridő szinkronizálás 1.29.2 Felhasználói tevékenységek felhasználói ellenőrzése 1.30 Távmunka és mobil eszközök használata 1.30.1 Távmunka 1.30.2 Mobil eszközök használata Rendszerfejlesztés és –karbantartás 1.31 1.32 1.33 Rendszertervezés és jóváhagyás Rendszerek biztonsági követelményei Alkalmazói rendszerek biztonsági követelményei 1.33.1 Az alkalmazásokhoz kapcsolódó védelmi szabályok 1.33.2 Az adatbeviteli előírások 1.33.3 Az adatfeldolgozási előírások 1.33.4 Az adatszolgáltatási előírások 1.33.5 Az adatok átadási rendje 1.34 Kriptográfiai eszközök használatának szabályai, ellenőrzése Oldal 28 IT biztonságról közérthetően Informatikai biztonsági koncepció 1.35 Rendszerállományok biztonsága 1.35.1 Üzemeltetési rendszerkörnyezet védelme 1.35.2 Tesztadatok és forráskód-könyvtárak védelme 1.35.2.1 1.35.2.2 1.36 Tesztadatok védelme Forráskód-könyvtárak védelme Fejlesztés és terméktámogatás biztonsága 1.36.1 Változásellenőrzési eljárások 1.36.2 Rejtett funkciók és „trójai” programok 1.36.3 Szoftverfejlesztési tevékenység kiszervezése Megbízható működés biztosítása 1.37 1.38 Megbízható működés biztosításának szempontjai Informatikai katasztrófa-elhárítási terv Törvényi megfelelőség 1.39 1.40 Törvényi és jogi követelményeknek való megfelelés A dokumentációs rendszer és a technológiai egyezés vizsgálata Mellékletek – Meghatározások Mindenképpen javasolt az IBSZ elkészítését valamilyen nemzetközi szabvány, vagy ajánlás által megfogalmazott szempontrendszer figyelembe vételével végezni. Így lehet biztosítani, hogy az egyes témakörök esetében meghatározott szabályok ne légből kapott kitalációk, hanem megalapozott állítások legyenek, melyek egymásra épülő követelményrendszert alkotnak. A szabványokban leírtakat azonban nem szabad szolgai módon, értelmezés nélkül átemelni és kötelező érvényűvé tenni, mert ha nem illeszthetőek a meglévő szervezeti és működési struktúrába, a szabályzat betarthatatlanná válik. Egy ilyen használhatatlan IBSZ nagyobb kárt képes okozni egy szervezet működésében, mintha semmilyen felsőbb szintű szabályozás nem történne: A betarthatatlan törvények minden társadalomban a korrupció, a kiskapuk keresésének melegágyai, ez „kicsiben”, vállalati méretekben éppen így történik. Az IBSZ általában általános érvényű, fejezetei a szervezeten belül mindenkire egyaránt érvényesek, nem csak a rendszergazdákra, hanem a felhasználókra is, de természetesen eltérő módon és eltérő szabályokkal. Éppen ezért fontos az IBSZ-t minél szélesebb körben publikálni és oktatni a szervezeten belül. Ezzel nagymértékben hozzá lehet járulni egy informatikai biztonsági szempontból fejlettebb vállalati kultúra kialakulásához. IT biztonságról közérthetően Oldal 29 Informatikai biztonsági koncepció Üzemeltetési eljárásrendek Az Üzemeltetési eljárásrendek egy-egy üzemeltetési terület feladatait, valamint az ehhez kapcsolódó egységes követelményeket határozzák meg az alábbi bontásban:   Rendszeres feladatok, melyeket az üzemeltetőknek meghatározott rendszerességgel (óránként, napi, heti, havi, éves, stb.) kell elvégezni. Eseti feladatok, melyeket valamilyen esemény bekövetkeztekor kell elvégezni. Az eseti feladatok általában az alábbi területeket kezelik: o Be/kijelentkezés o Konfiguráció módosítás o Leállítás, elindítás o Új elem létrehozása o Javító csomagok telepítése o Verzióváltás o Váratlan események kezelése o Hibakezelés, hibabehatárolás Az eljárás elején meg kell határozni a felelősségi köröket, mind a végrehajtás, mind az ellenőrzés és a folyamatok módosítása tekintetében. Fontos biztosítani, hogy az egyes feladatok elvégzése nyomon követhető és visszaellenőrizhető legyen. Továbbá hasznos, ha a hibák megoldásából saját tudásbázis épül, mely tartalmazza a hiba leírását, jellemzőit, valamint a megoldás módját. Ez jelentősen képes lerövidíteni a későbbi hibakeresés és problémamegoldás idejét. Az Üzemeltetési eljárásrendben definiált feladatok kidolgozása és mélysége változó. Általában két szinten kerül kidolgozásra: 1. A feladatokat nem kell teljes mélységükben és részletezettséggel leírni. A cél ebben az esetben, hogy az adott területen elvégzendő feladatok gyártófüggetlen módon kerüljenek definiálásra. Ebben az esetben az eljárásrendet akkor sem kell átdolgozni, ha a kérdéses területre más gyártó megoldása kerül, mivel az alapelvek nem változnak. Ez az eljárás nagyobb szabadságot biztosít az üzemeltetőknek, és természetesen nagyobb hozzáértést is feltételez. 2. Az ismert feladatokat teljes mélységben és részletezettséggel definiálni kell. Ebben az esetben a leírást a részletes beállításokkal, képernyőképekkel, vagy a kiadott parancsok, indított programok és scriptek pontos leírásával is el kell látni. Ez az eljárás elvileg lehetővé teszi, hogy az üzemeltető kiesése esetén bárki helyettesíteni tudja, de az egyes eljárásokban történt legkisebb változást is haladéktalanul át kell vezetni a dokumentumba, különben az használhatatlanná válik. Az Üzemeltetési eljárásrendek nem tartoznak másra, csak a végrehajtó, illetve az ellenőrző szervekre. Ezért publikálásuk a felhasználók körében ellenjavallt. Az eljárásrendek hozzáférhetőségét korlátozni kell, ugyanakkor természetesen minden érdekelt félnek IT biztonságról közérthetően Oldal 30 Informatikai biztonsági koncepció biztosítani kell az elérhetőséget. A korlátozás különösen fontos, ha a kialakítás a 2. részletesebb forgatókönyv szerint történt, mivel ebben az esetben az eljárásrendek nagyon sok olyan információt tartalmaznak, melyek illetéktelenek kezébe kerülve kárt okozhatnak a szervezetnek. Az informatikai biztonság témakörében általában az alábbi Üzemeltetési eljárásokat szokták elkészíteni:       Tűzfal üzemeltetési eljárásrend Vírusvédelmi-rendszer üzemeltetési eljárásrend Jelszókezelési eljárásrend Felhasználó kezelési eljárásrend Jogosultság kezelési eljárásrend Mentési, archiválási eljárásrend Ki kell emelni, hogy ezeknek a területeknek a karbantartása nem a Biztonsági Felügyelő feladata, hanem az üzemeltetésé. Viszont a feladatok elvégzésének eseti és rendszeres ellenőrzéséért a Biztonsági Felügyelő felel. Felhasználói Szabályzat A Felhasználói Szabályzat gyakorlatilag az IBSZ-ben megfogalmazottak alapján készített kivonat, mely kizárólag a felhasználókra vonatkozó információkat tartalmazza. Olyan etikai és biztonsági szabályok gyűjteménye, mely részletesen meghatározza egy felhasználó számára, hogy milyen tevékenységeket végezhet a vállalati informatikai rendszerben a munkavégzés mellett. A szabályzat kitér:            a jelszavak kezelésére és tárolására, a „tiszta asztal” és „tiszta képernyő” irányelvére, az elektronikus és papír alapú adatkezelés, mozgatás és tárolás, a nyomtatás, az emailezés, a böngészés, a telefonos kommunikáció, a mobil eszközök kezelése, a távmunka, a vírusvédelem, a hiba észlelés és bejelentés szabályaira. Javasolt a belépő felhasználók részére oktatást szervezni a Felhasználói Szabályzat tartalmából, melynek végén sok esetben vizsgát is kell tenniük, annak bizonyítására, hogy biztosan megértették a szabályzatban rögzített alapelveket. IT biztonságról közérthetően Oldal 31 Informatikai biztonsági koncepció A szabályzatnak tükröznie kell a vállalati kultúra szemléletét és irányelveit, melyet a felhasználóknak javasolt elsajátítaniuk. Az oktatás elősegíti az egységes vállalati adatkezelési szemlélet kialakítását és fejlesztését. A Felhasználói Szabályzat az egymásra épülő biztonsági szabályzatrendszer utolsó eleme. A rendszer egésze így minden szinten képes meghatározni a munkavégzők tevékenységét az informatikai rendszerrel és az adatokkal kapcsolatban. Katasztrófa elhárítási Terv (DRP) Váratlan, nagymértékű meghibásodások minden rendszer esetében előfordulhatnak. A problémákat nagyon sok esetben nem is a rendszerek működési hibája, hanem a környezet változása okozza. Semmilyen informatikai környezet esetében nem lehetünk biztosak abban, hogy képes ellenállni olyan környezeti katasztrófáknak, mint vihar, árvíz, tűz, robbanás, földrengés, vagy akár egy hosszú áramkimaradás. Ezekre a nem kívánt eseményekre azonban fel lehet és fel is kell készülni, éppen úgy, mint egy diszk, processzor, vagy központi hálózati aktív eszköz hibára. Ennek az előzetes felkészülésnek az eredménye a Katasztrófa Elhárítási Terv (amely valójában nem a katasztrófát, hanem az eredményeképpen okozott károkat hárítja el). Természetesen a tervezés mértékét itt is, mint minden esetben, össze kell mérni a védendő rendszer értékével. Könnyen belátható, hogy egy 10 fős iroda katasztrófavédelmére, nem kell az ország másik végébe telepített, nagy rendelkezésre állású (HA) backup site-ot létrehozni, elég a rendszeres és teljes körű adatmentésről gondoskodni, és a mentések eltérő helyszínen történő tárolását biztosítani. Sok olyan rendszer van azonban, ahol nem csak a kiszolgálók számára kell egy folyamatosan működő alternatív telephelyet biztosítani, hanem a munkavégzés alternatív helyszínét is ki kell jelölni, és az infrastruktúráról előre kell gondoskodni. Ez mindenképpen olyan kihívás, melyet nem lehet vészhelyzetben előzetes tervezés nélkül megvalósítani, és egy jelentősebb csőtörésnek, vagy egy sarki közlekedési baleset esetleges következményeinek nem szabad elérhetetlenné tenni vagy megsemmisíteni az informatikai szolgáltatásokat és adatokat. Az előzetes tervezés fontosságát és mértékét, valamint a technológia fejlődését jól példázza a WTC esete. Az épületek ellen 1993-ban már megkíséreltek egy terrormerényletet (autóbombát robbantottak az egyikben). A robbantás jelentős szerkezeti kárt nem okozott, de több ott dolgozó cég informatikai rendszerei sérültek vagy megsemmisültek. A legtöbb cég 1 éven belül tönkrement. A 2011-es WTC terrorcselekmény után mindkét épület elpusztult, de a jelentősebb informatikai szolgáltatások, már másnap (!) működtek, az adatok elérhetőek voltak alternatív telephelyen. A Katasztrófa Elhárítási Terv (Disaster Recovery Plan) feladata olyan technológiák és eljárásrendek bevezetése, melyek célja az informatikai rendszerek, adatok, erőforrások és szolgáltatások sérülése esetén történő kiesési idő lehető legnagyobb mértékben történő IT biztonságról közérthetően Oldal 32 Informatikai biztonsági koncepció lerövidítése vagy megszüntetése, valamint a helyreállítás gyors és zökkenőmentes megvalósítása. A Katasztrófa Elhárítási Terv tehát eszköz, illetve szolgáltatás alapú szemléletet igényel, közvetlen célja minden esetben egy vagy több informatikai rendszer működésének biztosítása. Nem szabad összekeverni a Katasztrófa Elhárítási Tervet a rendelkezésre állás növelésére szolgáló megoldások bevezetésével, mint például: RAID tömbök, clusterek építése, adatmentés megvalósítása, mivel ez túlmutat ezeken a megoldásokon. A Katasztrófa Elhárítási Terv jelentős mértékben épít a Kockázatelemzés eredményeire, hiszen az ott részletezett kockázatok ellen kell felkészülni a tervezés során. A kockázatok közül azoknak a kezelését végzi a Katasztrófa Elhárítási Terv, melyek a célzott informatikai infrastruktúra teljes megsemmisülésével, illetve a szolgáltatás hosszabb ideig történő leállásával fenyegetnek. Ebből kifolyólag a kockázatelemzések aktualizálásának minden esetben magával kell vonnia a Katasztrófa Elhárítási Tervek átgondolását és frissítését. A tervezés legfontosabb mérőszáma az elfogadható kiesési idő kell, hogy legyen, mely a Kockázatelemzésben kerül meghatározásra. Minden alternatívát e köré a szám köré kell építeni, és ez az érték befolyásolja a legnagyobb mértékben az ellenintézkedések várható költségeit is. Egy katasztrófa eseményre történő felkészülés és eljárás kidolgozása az alábbi lépésekből kell, hogy álljon: 1. Az első lépésként meg kell határozni azokat a kritériumokat, amelyek bekövetkezte egyértelművé teszi a katasztrófa helyzet életbelépését. 2. Természetesen a katasztrófa helyzet életbe léptetésének kimondására jogosult személyeket is meg kell határozni, és fel kell állítani egy Krízisbizottságot, akik ebben a helyzetben döntéseket hozhatnak. 3. Meg kell határozni egy belső értesítési láncot, és meg kell határozni azokat a külső kapcsolatokat, amelyeket be kell vonni az elhárítás folyamatába. 4. Továbbá meg kell határozni tájékoztató eljárást és pontos szövegezést, melyen keresztül az ügyfelek, partnerek értesítése megtörténik, amennyiben a nyújtott szolgáltatásokat nincs lehetőség teljes mértékben fenntartani. A tájékoztató üzenetekben szerepelnie kell a szolgáltatás csökkentés mértékének, illetve annak, hogy várhatóan mennyi ideig tart az eredeti állapot visszaállítása. 5. Fel kell építeni egy, vagy több intézkedési tervet és forgatókönyvet az adott esemény bekövetkeztére. Ezekben az intézkedési tervekben megfogalmazott eljárásoknak kell biztosítaniuk az informatikai eszközök, adatok, szolgáltatások rendelkezésre állását, amennyiben lehetséges, illetve a kiesési ablak csökkentését, amennyiben a kiesés megtörtént. 6. Amennyiben a szolgáltatás biztosítása érdekében át kell állni egy alternatív hardverre, és/vagy helyszínre, az átállás pontos lépéseit is itt kell meghatározni. 7. Pontosan definiálni kell az alternatív helyszíneken történő működést, nem csak az informatikai rendszerek, hanem a felhasználók vonatkozásában is. (Pl.: Meg kell IT biztonságról közérthetően Oldal 33 Informatikai biztonsági koncepció határozni, hogy a felhasználók közül kik fognak az alternatív helyszínen dolgozni, kik fognak távmunkával dolgozni, és kiknek nem lehet biztosítani a munkavégzést a katasztrófa helyzet ideje alatt.) 8. Meg kell határozni, hogy az alternatív működés minimálisan milyen szolgáltatási szintet képes biztosítani. 9. Meg kell határozni egy visszaállási eljárást, mely során definiálni kell a katasztrófa helyzet elhárítása utáni eredeti helyszín és szolgáltatási szint helyreállításának lépéseit. 10. Meg kell határozni egy visszaállási tájékoztató eljárást és pontos szövegezést, melyben tudatni lehet a külső partnerekkel a katasztrófa helyzet megszűntét, és az eredeti szolgáltatási szint helyreállítását. 11. Meg kell határozni azt a pontot, mikor a Krízisbizottság beszünteti működését. Természetesen ezeket a feladatokat nem elég gondolatban megtervezni, hanem rendszeresen le is kell tesztelni. A tesztek több szempontból is hasznosak:   Rámutatnak a tervezés esetleges hibáira vagy hiányosságaira. Gyakorlatot adnak a végrehajtó személyeknek, így egy esetleges éles helyzetben kevesebb idő alatt, „rutinszerűen” lehet a feladatokat elvégezni. Minden kritikus rendszer esetében szükséges Katasztrófa Elhárítási Tervet készíteni. A felkészülés folyamataként biztosítani kell olyan támogatások meglétét, melyek szükségesek lehetnek egy katasztrófa esemény bekövetkezte esetén (alternatív helyszín azonnali biztosítása, backup szerverterem és adatszinkronizáció megléte). Attól függően, hogy milyen rendelkezésre állásra van szükség (hideg/meleg backup site), fel kell építeni a szükséges infrastruktúrát az alternatív helyszínen és üzemeltetni kell. Ebből is látszik, hogy a katasztrófa elhárítás tervezése és megvalósítása jelentős beruházást igényel, nem csak a tervezéskor, illetve az átállás esetén, hanem folyamatosan, normál üzemidőben is. Azért is fontos az előzetes Kockázatelemzés minél pontosabb elkészítése, mert az ebben megfogalmazottak határozzák meg a szükséges beruházási költségeket. Egy Katasztrófa esemény folyamatát és elhárítását az alábbi ábra látványosan szemlélteti: IT biztonságról közérthetően Oldal 34 Informatikai biztonsági koncepció Ábra: DRP3 Az ábra legfontosabb üzenete, hogy a Teljes kiesési idő (MTPOD) és a Visszaállítási idő (RTO) nem egyeznek meg egymással. ezt a tervezés során mindenképpen figyelembe kell venni, különben a valóságostól eltérő értékekkel fogunk számolni. Üzletmenet folytonossági Terv (BCP) A korábban tárgyalt Katasztrófa Elhárítási Terv az informatikai rendszerek, szolgáltatások működésének fenntartásával foglalkozik, vagyis egy vagy több eszköz működésének lehetőleg minden körülmények között történő biztosítását célozza meg. Egy komplex üzleti folyamat azonban nem kizárólag a helyi informatika rendelkezésre állásától függ, hanem több egyéb ponton is sérülhet, amelyeknek semmi közük nincs egy katasztrófa elhárítási tervhez. Ráadásul az informatika sérülése, vagy akár egy katasztrófa helyzetben történő átállás minden valószínűség szerint meg fogja akasztani az üzleti folyamatokat. Szükség van tehát egy olyan, folyamatorientált eljárásrend kidolgozására, mely az adott üzleti folyamatot egészében vizsgálja, és megakadása, sérülése esetén képes reális alternatívát biztosítani. Erre a feladatra szolgál az Üzletmenet folytonossági Terv (Business Countinuity Planning). Első látásra szembetűnik, hogy jelentős a hasonlóság közte és a korábban tárgyalt Katasztrófa Elhárítási Terv között. A legfontosabb különbség közöttük, hogy a Katasztrófa Elhárítási Terv minden esetben eszköz vagy szolgáltatás alapú, addig az Üzletmenet folytonossági Terv mindig folyamat alapú megközelítéssel dolgozik. Ez nem csak ügyes 3 www.e-janco.com (DRP kép) IT biztonságról közérthetően Oldal 35 Informatikai biztonsági koncepció szócsavarás, noha kétségtelen, hogy van átfedés a két megközelítés között, hiszen a legtöbb üzleti folyamat valamilyen informatikai szolgáltatást vesz igénybe, melynek rendelkezésre állását már a Katasztrófa Elhárítási Terv biztosítja. Talán Verne: 80 nap alatt a Föld körül című könyvének főhőse érezte először hiányát egy jól felépített Üzletmenet folytonossági Tervnek, mikor minden tervezése ellenére azzal szembesült, hogy a térképen jelzett vasútvonalat még el sem készítették. Ő szerencsével és improvizációval megoldotta helyzetet, de egy vállalat életében egy ilyen törésre érdemes előzetesen felkészülni és alternatív útvonalakat kidolgozni. Ugyanis ezek a tervek pontosan arról szólnak, hogy az adott folyamat fenn akadása esetén milyen új utakon lehetne azt mégis csak folytatni. Az Üzletmenet folytonossági Terv is jelentős mértékben épít a Kockázatelemzés eredményeire, de nem annyira közvetlenül, mint a Katasztrófa Elhárítási Terv. Ebben az esetben ugyanis a működési folyamatokra gyakorolt hatások felmérésére kell támaszkodni. Ezt az Üzleti Hatáselemzés (Business Impact Analyzer) képes pontosan meghatározni. Az Üzleti Hatáselemzés célja az üzleti folyamatokat támogató erőforrások kiesése miatti megakadások által okozott anyagi károk felbecslése, hogy a védelmet költséghatékony módon tudjuk megvalósítani. Mivel az Üzleti Hatáselemzés a kritikus informatikai rendszerek vizsgálatát is magába foglalja, ezért tágabb értelemben a Kockázatelemzés is a BIA részét képezi. Egy Üzletmenet folytonossági Terv elkészítése során a lépések sok tekintetben megegyezőek a Katasztrófa Elhárítási Terv-nél részletezett eljárásrenddel. A legnagyobb különbség, hogy amennyiben egy krízishelyzet bekövetkezik, vagyis az adott üzleti folyamat egy bizonyos ponton megszakad, ezekre az esetekre alternatív forgatókönyvekkel kell készülni. A lényeg, hogy olyan kerülő utakat biztosítsunk, melyek lehetőséget nyújtanak arra, hogy a folyamat, ha csökkentett kapacitással is, de mégis tovább tudjon haladni. Természetesen az előkészületek során részletesen fel kell térképezni a kérdéses folyamat célját, és a részleteit. A BIA alapján meghatározásra került, hogy az üzlet mekkora kiesési időt visel el. Egy nagyon egyszerű esetben pl.: Ha egy cég a partnerének naponta, meghatározott időben emailben küldi a megrendeléseket, akkor az internet elérés meghibásodása esetén biztosítani kell fax-vonalat a megrendelések alternatív útvonalon történő küldésére. A terv kialakításának egyes lépései az alábbiak: 1. Meg kell határozni, hogy mi az az esemény, amelynek a bekövetkezése krízishelyzetet és az Üzletfolytonossági Terv életbelépését vonja maga után. 2. Ki kell jelölni egy Krízisbizottságot, akik a folyamatot levezénylik és meghozzák a kritikus döntéseket. 3. Meg kell határozni egy értesítési rendet. IT biztonságról közérthetően Oldal 36 Informatikai biztonsági koncepció 4. Meg kell határozni azokat a felkészülési feladatokat, melyek elvégzésével megtörténhetnek az előkészületek a krízishelyzetre. 5. Meg kell határozni egy tájékoztatási rendet és szövegezést az ügyfelek és partnerek felé. 6. El kell készíteni az alternatív forgatókönyveket a folyamat egyes elemeinek megszakadása esetére. 7. Meg kell határozni és elő kell készíteni az alternatív működéshez szükséges eszközigényt. (A korábbi példában a fax eszközt és az analóg telefonvonalat, valamint meg kell győződni róla, hogy ezek a fogadó oldalon is rendelkezésre állnak.) 8. Meg kell határozni az alternatív folyamat fenntartható idejét. 9. Meg kell határozni a helyreállítási rendet és annak konkrét feladatait, mind a saját, mind a támogató szervezetek részére. 10. Meg kell határozni a visszaállításhoz szükséges eszközigényt. 11. Meg kell határozni, hogy milyen feltételek teljesülése esetén állítható le a krízishelyzet és ki állíthatja le. 12. Meg kell határozni a tájékoztatási rendet a krízishelyzet leállításáról. A terveket oktatni kell a résztvevőknek és rendszeresen tesztelni, hogy éles helyzet bekövetkeztekor ne okozzon meglepetést. Minden olyan üzleti folyamatra el kell készíteni az Üzletmenet folytonossági Tervet, melyet az Üzleti hatáselemzés kritikusnak ítélt. Természetesen az üzleti folyamatok változásával a terveket is módosítani kell, különben értelmetlenné válik a tervezés, és krízishelyzetben nem marad más lehetőség, mint az improvizáció. Összefoglalásként, az IT biztonsági szabályzatrendszer csak akkor éri el célját, ha a szabályzatok: 1. 2. 3. 4. a valóságot írják le, betarthatóak, visszacsatolási, ellenőrzési rendszer is kiépítésre kerül, a szervezet minden szintjén elfogadásra kerülnek a felhasználók és üzemeltetők által (oktatás), 5. rendszeresen gondoskodnak az aktualizálásukról, 6. egymásra épülnek. IT biztonságról közérthetően Oldal 37 Informatikai biztonsági koncepció Védelmi technológiák Adatmentés Az adatmentés sok szempontból nem tartozik szorosan az informatikai biztonság témakörei közé, szigorúan véve inkább általános üzemeltetési feladatnak tekinthető. Ha azonban adatés információ biztonságról beszélünk, nem szabad elfelejteni az adatok rendelkezésre állásának biztosítását, melynek szerves része az adatmentés. Ahogy a fenyegetésekkel foglalkozó fejezetben már szó volt róla, az adatok elvesztése, sérülése valamilyen emberi hiba, meghibásodás, vagy külső tényező miatt ma az elsődleges veszélyforrás az informatikai rendszerekre. Éppen ezért az adatmentésnek kiemelkedő szerepet kell játszania egy üzemeltető életében a mindennapi nyugodt alvása érdekében. Ha Cromwell háborúskodás helyett rendszerüzemeltetéssel foglalkozott volna, híres mondása valahogy így hangozna: „Bízz Istenben, de mentsd az adataidat, amilyen gyakran csak lehet!” Az adatok mentése tulajdonképpen nem más, mint az éles és a működéshez szükséges adatok kimásolása a produktív környezetből, és rendszerezett, visszaállítható formában, biztonságos helyen, meghatározott ideig történő tárolása. Ez egyszerűen hangzik, de számos kérdést meg kell válaszolni ahhoz, hogy egy jól működő mentőrendszert építhessünk. Mindenekelőtt azonban egy klasszikus félreértést kell eloszlatni: A hibatűrő rendszerek építése nem helyettesíti az adatmentést! Életveszélyes dolog csak azért nem foglalkozni a mentéssel, mert clusterrel és RAID2-5 diszk tömbökkel rendelkeznek a kritikus rendszereink. Ezt a hibát általában a kisebb- közepes méretű infrastruktúrákban szokás elkövetni. Ha egy rendszerépítés során a rendelkezésre álló erőforrások korlátai miatt választani kell az adatmentés és a hibatűrő rendszerek között, mindig az adatmentésnek kell győznie. Akárhány diszk elromolhat egyszerre vagy közvetlenül egymás után, felhasználói hibákról, véletlen törlésekről pedig még nem is beszéltünk. Egy mentési rendszer építése előtt az első feladat minden esetben a mentendő adatok körének meghatározása. A helyes szemlélet ebben az esetben az, ha fordítva indulunk el, és nem azt vizsgáljuk, hogy milyen adatokat szeretnénk menteni, hanem azt, hogy milyen adatokra, információkra lesz szükség ahhoz, hogy a rendszert és a szolgáltatásait egyszer majd a lehető legrövidebb idő alatt, a semmiből helyre lehessen állítani. Ezt a „lehető legrövidebb időt” egyébként pontosan ismerjük a Katasztrófa Elhárítási Tervből. A mentendő adatok ebből a szempontból az alábbi kategóriákba sorolhatók: Üzleti adatok: Ide tartoznak tipikusan a fájlmegosztások adatai, az adatbázisok, és a központi elektronikus levelezés. Alkalmazások: Ide tartoznak azok a konfigurációs és egyéb állományok, amelyek a kritikus alkalmazások hibamentes működéséhez és egy másik környezetben történő IT biztonságról közérthetően Oldal 38 Informatikai biztonsági koncepció helyreállításához szükségesek. Ezek meghatározása legtöbb esetben az alkalmazás fejlesztőjének, illetve beszállítójának a feladata. Operációs rendszer és core adatok: Ide tartoznak azok az alap infrastrukturális adatok, melyek az alap rendszerek helyreállításához szükségesek. Tipikusan címtár adatok (Pl.: Active Directory), DNS, DHCP, WINS kiszolgálók konfigurációja és adatai, tűzfal és hálózati aktív eszközök konfigurációja, naplóállományok. Meg kell határozni a mentési időablakokat, vagyis, hogy mikor futhatnak le a mentések. Ez jellemzően éjjel szokott történni és az ablakok nagysága a mentendő adatok mennyiségétől, illetve a mentés lefutási sebességétől függ. Ez utóbbi értéket, nem csak az adatmennyiség, hanem számos egyéb komponens összessége határozza meg: 1. 2. 3. 4. A mentő szerver erőforrásai (CPU, memória). A hálózat sávszélessége. A mentendő szerverek erőforrásai és terheltsége. A választandó mentő eszköz beviteli sebessége. Meg kell határozni a mentési logikát, vagyis a mentések gyakoriságát, típusát, a mentő eszközök tárolási, cserélési, és felülírási rendjét. A mentések általános típusai az alábbiak:    Full mentés: minden kijelölt adatot teljes egészében mentünk. Differenciális mentés: Az utolsó full mentés óta keletkezett különbséget mentjük. Inkrementális mentés: Az előző mentés óta keletkezett különbséget mentjük. Nem szükséges minden adatot minden mentésbe beleforgatni, pl.: a ritkán változó konfigurációs állományokat sokszor elég csak hetente, havonta egyszer menteni. Ideális esetben napi rendszerességgel full mentést tudunk futtatni. Ha erre nincs lehetőség, mert a mentési ablak túl kicsi, tipikusan hétvégi full és hét közbeni differenciális, vagy inkrementális mentések történnek. A mentési médiák cserélése során szintén több lehetőséggel kell számolnunk: Ideális esetben a napi mentéseket eltesszük az örökkévalóságnak. Ez azonban jelentős mennyiségű mentési médiát igényel, ezért kevésbé költséghatékony. A médiákat hetente, kéthetente cseréljük és felülírjuk. Ez általában kisebb cégeknél bevált szokás. Hátránya, hogy maximum a két hétnél nem régebben eltüntetett adatokat lehet csak visszanyerni. Jó köztes módszer a GFS (Grandfather-Father-Son) módszer, mely szerint minden héten, minden hónapban az utolsó full mentést eltesszük, a többi médiát megfelelő séma alapján visszaforgatjuk a mentésekbe. A GFS logikát az alábbi ábra szemlélteti: IT biztonságról közérthetően Oldal 39 Informatikai biztonsági koncepció Ábra: GFS rotációs séma4 A mentések (adatmásolások) elvégzése általában két módon történhet: 1. A mentendő alkalmazás saját mentési megoldásával, saját eszközökkel, illetve az adott operációs rendszerbe épített mentő megoldással kerülnek az adatok mentésre. 2. Dedikált mentő szoftver kerül alkalmazásra. A második megoldás több lehetőséget biztosít a mentések optimalizálására. Ráadásul a gyártók az ismertebb alkalmazásokhoz, adatbázisokhoz általában külön illesztő programot (Agent) készítenek, melynek segítségével futásidőben lehetőség nyílik az adatok automatizált, ütemezett mentésére. A mentési médiák megválasztása is sok szempontból befolyásolja a mentéseket. Az elmúlt évtizedek bevált gyakorlata szerint valamilyen szalagos adattárolóra kerültek a mentések, szekvenciális módon (folyamatosan, egymás után írva az adatokat a szalagra), majd a szalagokat, vagy egy másolatukat biztos helyre szállították. A változás valójában csak a tároló médiák kapacitásában és az átvitel sebességében történt. A diszkek kapacitásnövekedése és 4 http://flylib.com (Mentési séma) IT biztonságról közérthetően Oldal 40 Informatikai biztonsági koncepció árcsökkenése, valamint a sávszélességek növekedése azonban több esetben valós alternatívává tette a diszkmentéseket (egy távoli gépre). Illetve sok esetben többlépcsős mentési eljárást alkalmaznak: 1. Gyors mentés egy köztes diszkterületre. 2. A mentett adatok szalagra írása, és elszállítása akár munkaidőben. Ezzel párhuzamosan egyre jobban előtérbe került a duplikált adattárolás problémája. Egy több éve használt fájlstruktúrában, illetve levelezésnél komoly probléma, hogy ugyanazok az adatok több helyen is változatlan formában megtalálhatók. Ezeket a napi mentéseknél ugyan úgy, többszörösen menteni kell jelentősen csökkentve a hasznos adatok számára fenntartható helyet és mentési kapacitást. A deduplikációs eljárások ennek a problémának a megoldására születtek. A mentések diszkre, adatbázisba történnek és a mentés folyamán a duplikáció folyamatosan ellenőrzésre kerül, tehát minden adat csak egyszer kerül mentésre. Ezzel jelentősen nő a mentések valós kapacitása. Természetesen a diszkre mentett adatbázist attól még külön érdemes rendszeresen szalagra másolni. Könnyű belátni, hogy a napi rendszerességgel futtatott mentések mellett is lesz egy olyan időablak, mikor egy bekövetkező meghibásodás végleges adatvesztést okoz. Ha a hiba este történik, akkor az előző napi mentéstől az egész aznap végzett munkák és adatok elvesznek. Ez a probléma tipikusan nagy adatbázisok esetébe kritikus. Ennek lecsökkentésére az adatbázisok esetében javasolt egy naponta többször (bizonyos helyeken 20 percenként) futtatott tranzakciós log mentés végezni. Ezek a mentések csak az esti mentésig kerülnek tárolásra, de biztosítani tudják, hogy az adatvesztési ablakunk ne legyen több a két tranzakciós log mentés közt eltelt időnél. Természetesen a fenti rövid összefoglaló nem adhat teljes képet egy komoly infrastruktúra mentési megoldásairól, sok fontos szempontot kell még figyelembe venni, melyek közül néhányat felsorolás szinten említek:      Munkaállomások mentése Virtuális kiszolgálók mentése Disaster recovery eljárások Szalagok címkézési eljárása és tárolása Elöregedett, mentett adatok és mentési hardverek migrációja Operációs rendszerek védelme 1521-ben Nándorfehérvár 66 napig állta a török sereg támadását. A vár kapitánya azonban végül átszökött a törökökhöz, és elárulta a várfal gyenge pontjait. A várvédők elbuktak. IT biztonságról közérthetően Oldal 41 Informatikai biztonsági koncepció Az operációs rendszerek védelme kulcsfontosságú az érzékeny adatok biztonsága szempontjából. Az operációs rendszer egy olyan hídfőállás, melynek elfoglalása után a támadó már viszonylag könnyen hozzá tud férni a céljához, akár valamilyen diszkrendszeren vagy háttértáron tárolt, akár hálózaton továbbított adatokról beszélünk. Ezért kiemelt fontosságú magának az operációs rendszernek a védelme. Ebből a szempontból teljesen mindegy, hogy az adott szervezet szempontjából külső vagy belső támadásról beszélünk, az operációs rendszer mindkét esetben kulcsfontosságú. A sérülékenységekről szóló fejezetben részletesen elemeztük a javító csomagok telepítésének fontosságát. Ez természetesen alapkövetelmény, mivel ezek hiányában szó szerint védhetetlen réseket hagyunk a biztonsági rendszerünkben. Számos egyéb lehetőség és eszköz is van azonban a kezünkben, mellyel megerősíthetjük rendszereinket. Ráadásul ezek legtöbbje tipikusan az egyes rendszerek, vagy hardverek részét képezik, így a legtöbb esetben bevezetésük különösebb beruházást nem is igényel. Természetesen a biztonság és a használhatóság közötti egyensúlyt itt is szem előtt kell tartani. (Tudjuk, hogy a tökéletesen biztonságos rendszer 500 méterrel a föld alatt egy páncélteremben elzárva található, és csak 12 faktoros autentikáció után férhető hozzá, de Tom Cruise-on kívül nincs ember, aki arról el tudna küldeni egy meeting requestet.) Nézzük a védelem területeit: Lopásvédelem: Tipikusan notebookok esetében jellemző ez az egér nélküli „drag and drop” módszer, vagyis valaki felkapja és viszi. Ebben az okozott kár három részből áll össze: 1. Az eszköz értéke, érdekes módon sok esetben ez a legkisebb. 2. Az adatok értéke, amennyiben illetéktelen kezekbe kerül. Ez akár az egész szervezet működését veszélyeztetheti. 3. A csak ott meglévő információ hiánya. Ez általában rövidebb megakadásokat okoz az üzleti folyamatokban. Lopások ellen fizikai védelmi megoldásokat javasolt alkalmazni, beléptetés, épületen belüli mozgás korlátozását, kártyás beléptető rendszer alkalmazását, továbbá hatékony megoldás a különböző notebook lock eszközök, amik gyakorlatilag a biciklizár laptopok számára fejlesztett megfelelői. Boot védelem: Ha meg akarjuk kerülni egy operációs rendszer biztonsági rendszerét, legegyszerűbb, ha külső médiáról (Pl.: Live CD, USB) boot-oljuk a rendszert, és erre felkapcsoljuk a fájlrendszert. Lehet nézegetni az állományokat anélkül, hogy jogosultsági korlátokba ütköznénk. A boot sorrend a BIOS-ban állítható, melyet szintén lehet jelszóval védeni. Hozzá kell tenni, hogy ezek a jelszavak megkerülhetők, ezért igazán hatékony védelmet nem jelentenek, de mindenképpen egy újabb akadályt IT biztonságról közérthetően Oldal 42 Informatikai biztonsági koncepció hozunk létre, ami lelassítja a támadót. A megkerüléshez legtöbb esetben fel kell nyitni a számítógépházat, ezt érdemes szintén zárva és/vagy lepecsételve tartani. Titkosítás: A lopás és boot védelem kiegészítő (és leghatékonyabb) adatvédelmi eszköze lehet a titkosítás. Ha a merevlemez el van titkosítva, a rajta lévő adatokhoz más nem férhet hozzá semmilyen módon. A titkosítással részletesebben is foglalkozunk a későbbiekben. Magára hagyott gépek védelme: Ha munkavégzés során őrizetlenül hagyjuk a gépünket, aki leül elé, a mi nevünkben tud tevékenykedni, meg tud személyesíteni, hozzáfér a saját adatainkhoz. Bármit tesz, azt a mi nevünkben teszi, minden naplóbejegyzés ezt fogja igazolni. Ez ellen egyszerű és hatékony módszer a jelszavas képernyővédő használata. Az adminisztrátor jog korlátozása: Ha egy felhasználó által futtatott program elindul egy gépen, annak a jogosultságai pontosan meg fognak egyezni a felhasználó jogosultságaival. Tehát, ha egy fertőzött weboldalról letölt egy ártó kódot, amelyet a vírusirtók nem észlelnek, az is olyan jogokkal fog elindulni, mind a helyi gépen, mind a helyi hálózaton keresztül. Ha ez a jog egyszerű felhasználói jog, akkor a kód kevésbé fér hozzá a rendszer számára kritikus területekhez, így kevésbé fertőzheti meg a gépet. Ha viszont ez a jog tartományi adminisztrátor, akkor egy jól megírt kód minden hálózati géphez hozzá fog férni. Talán az egyik legjobban megírt, közismert ártó kód a Conficker, több esetben is adminisztrátori gépekről indult el, és akár ezres nagyságrendben fertőzött meg vállalati gépeket. Nem véletlen, hogy az auditorok egyik kedvenc kérdése a rendszergazdák felé, hogy a mindennapi munka (levelezés, böngészés) során, milyen joggal rendelkezik és hogyan lép át adminisztrátori „üzemmódba”. Ide tartozó kérdés, hogy hány adminisztrátori joggal rendelkező felhasználó (valós, vagy szerviz felhasználó egyaránt) van a hálózaton, és valóban szükség van-e mindegyikre? Korlátozó policy-k bevezetése: A felhasználók egy tipikus irodai környezetben a munkavégzésükhöz igényeltnél sokkal több joggal rendelkeznek a gépükön. Ha összeszedjük egy tipikus irodai dolgozó tipikus feladatait, valami hasonló listát kell kapnunk: 1. 2. 3. 4. 5. 6. Hálózati meghajtók elérése, írása és olvasása. Nyomtatás. Szövegszerkesztő, táblázatkezelő, prezentáció készítő alkalmazások futtatása. PDF olvasás. Dedikált alkalmazások futtatása (számlázó, iktató, ERP, CRM, stb.). Böngésző futtatása (korlátozásokkal). IT biztonságról közérthetően Oldal 43 Informatikai biztonsági koncepció Ehhez képest egy átlagos felhasználó admin jogok nélkül is, gyakorlatilag az egész gép területén rendelkezik írási joggal, amiből például elég sok problémája szokott származni az üzemeltetőknek, különböző „eltűnt” dokumentumok előkerítése okán. De csatlakoztathatnak ismeretlen külső diszkeket, USB eszközöket, melyek egyrészt adatvédelmi szempontból aggályosak, másrészt tipikus forrásai egy céges vírusfertőzésnek. Továbbá számtalan alkalmazást futtathat, illetve telepíthet vagy másolhat a gépére (portable alkalmazások). Ezek közül több olyan is akad, melyek használata gondot jelenthet az adatbiztonság szempontjából: 1. Portable böngészők, melyekre a céges biztonsági szabályok nem érvényesülnek. 2. Távmenedzsment eszközök, melyek lehetőséget biztosítanak a gép távolról történő irányítására. 3. Hálózatmonitorozó eszközök, jelszótörők vagy akár komplett hálózati operációs rendszerek is futtathatók a gépen ilyen módon. 4. Játékok, vicces programok. A megoldás ezek ellen általában rendelkezésre áll, de idő és munkaigényes, ezért viszonylag kevés helyen vezetik be. Ez a felhasználói jogok korlátozása valamilyen központi szabályrendszer (Pl.: Active Directory Group Policy) alapján. Egy ilyen szabályrendszer bevezetése után valóban csak a szükséges dolgok válnak elérhetővé a felhasználók számára. Hozzá kell tenni, hogy egy ilyen szabályrendszer kialakítása és kikényszerítése nem elég, ezt karban is kell tartani, mivel egy komoly infrastruktúrában rendszeresen jelennek meg új igények, alkalmazások, melyeket át kell vezetni a szabályrendszerbe. Ráadásul felmerül egy további kérdés is ennek kapcsán: Egy mai irodai gép komoly erőműnek számít, sok olyan környezetet látni, ahol régebbi kiszolgálók és új kliensek futnak együtt és a kiszolgálók kapacitását sokszor eléri egy-egy kliens gépé. Ezt látva felmerül a kérdés, hogy minek ilyen erőforrásokat arra használni, hogy üresen ketyegjen a felhasználók alatt, akik csak egy-két irodai programot futtatnak rajta, még a helyi adattárolásuk is le van tiltva. A kérdésre a vékonykliens technológia adja meg a választ: A vékonykliensek nagyon egyszerű, kis számítógépek, melyek csak és kizárólag arra szolgálnak, hogy a felhasználók rajtuk keresztül egy központi szervert érjenek el, ahol dolgoznak, adatokat kezelnek, alkalmazásokat futtatnak. Helyi adattárolás, működés, helyi támadható operációs rendszer nincs, csak egy zsebkönyv méretű „buta” kis eszköz, melyre a monitort, egeret, billentyűt és persze a hálózati kábelt lehet csatlakoztatni. A felhasználóhoz csak egy képernyőkép jut el arról, amit éppen csinál a központi szerveren. Ennek a megoldásnak védelmi szempontból óriási előnye, hogy csak egy (néhány) központi kiszolgálót kell védeni, ahol a felhasználói munka valóban folyik, a kliensek összes nyűgjétől meg lehet szabadulni. A kiszolgálók részére természetesen komoly erőforrásokat és magas rendelkezésre állást kell biztosítani, hogy az összes felhasználót ki tudják szolgálni. A technológia persze nem újdonság, IT biztonságról közérthetően Oldal 44 Informatikai biztonsági koncepció ilyen terminál alapú megoldásokkal működtek az első számítógépek is 30-40 évvel ezelőtt. Természetesen vannak korlátozó tényezők (pl.: alkalmazások kompatibilitása), de megfelelő tervezéssel zártabb, biztonságosabb, energiatakarékosabb és egészében olcsóbb rendszereket lehet így kialakítani, mint a hagyományos vastagkliensalkalmazásszerver kombinációban. Biztonsági patchek használata: Különösen Linux alapú rendszerek esetében elterjedtek azok a programcsomagok, melyek az operációs rendszer jogosultság kezelését, illetve az alkalmazások működésének kontrollját hivatottak megerősíteni. A céljuk általában a valóban minimális jogosultsági szint deklarálása az egyes folyamatok számára. Néhány példa a teljesség igénye nélkül: Grsecurity, PaX, SELinux, RSBAC, AppArmor… Közös jellemzője ezeknek a megoldásoknak, hogy alapvető változtatásokat végeznek az operációs rendszer szívében, a rendszermagban (kernel). Egy működő rendszer esetében bevezetésüket mindig nagyfokú elővigyázatossággal kell elvégezni, az előzetes működési teszteket itt különösen fontos komolyan venni. Ellenkező esetben könnyen előfordulhat, hogy a rendszerünk ugyan biztonságosabb lesz, de a futtatott alkalmazás, mondjuk a cég vállalatirányítási rendszere, vagy egy egyedi webszolgáltatás soha többet nem fog rajta elindulni. Ezt sajnos a vállalatvezetés nem szokta honorálni, hiába védekezik a szerver üzemeltetője azzal a ténnyel, hogy az adott rendszer hibásan volt megírva és a fejlesztői kóklerek voltak. Jelszavas védelem: Jelszavak kezeléséről már volt szó a sebezhetőségek tárgyalása során, illetve előkerülnek a jogosultsági rendszereknél is. Az operációs rendszerek védelme során egy kevésbé közismert területről is említést kell tenni, ez a Service Account-ok védelme. Vannak olyan szolgáltatások, amelyeknek muszáj magas jogosultsággal futni, illetve egyedi jogokra is szükségük van a működésükhöz. Ezeket általában olyan speciális szerviz felhasználók nevében futtatják, legtöbbször automatizáltan, melyeket dedikáltan erre hoztak létre, és megadták nekik a szükséges jogokat. Könnyen belátható, hogy egy támadó számára egy ilyen szerviz felhasználó azonosítóinak megszerzése maga a paradicsom. Innentől kezdve szinte láthatatlanul bujkálhat ki és be a rendszerek között, szinte mindenhez hozzáférhet és csak a naplóállományok részletes vizsgálatával buktatható le. Ezeknek a szerviz felhasználóknak a jelszavait ráadásul ritkán (vagy soha nem) szokták megváltoztatni, ami külön öröm egy támadónak. Ezért a szerviz felhasználók jelszókezelését nagy körültekintéssel kell megtervezni, mind a használat, mind a tárolás tekintetében. Javasolt nem megjegyezhető, akár 40-50 karakter hosszú, bonyolult jelszavakat adni, melyeket érdemes lezárt borítékban, páncélszekrényben tárolni. Másik fontos szempont, hogy vizsgáljuk meg ezeknek a jelszavaknak a használatát, és zárjuk ki azokat a lehetőségeket, melyeknél a jelszót egy alkalmazás titkosítás nélkül továbbít a hálózaton keresztül. IT biztonságról közérthetően Oldal 45 Informatikai biztonsági koncepció Biztonsági beállítások: Az operációs rendszerek alap telepítésük során sok esetben tartalmaznak olyan elemeket, szolgáltatásokat melyekre a használatukkor nem lesz szükség. Ha biztonságos környezetet szeretnénk teremteni, ezeket az elemeket és szolgáltatásokat felül kell vizsgálni, és amennyiben feleslegesek, meg kell szüntetni. Általános szabályként elmondható, hogy egy rendszer annál biztonságosabb, minél kevesebb szolgáltatást nyújt a külvilág felé. Ez egyaránt érvényes a hálózati elérésekre és a bejelentkezés után hozzáférhető alkalmazásokra. Naplózás: A naplózásról a későbbiekben részletesen is szó esik. A naplózás feladata, hogy a rendszer működése során bekövetkező eseményeket rögzítse és visszakereshetővé tegye, mind hibakeresés, mind pedig valamilyen biztonsági esemény utólagos nyomon követése, felderítése érdekében. Ezért a naplózás beállítása és a naplófájlok kezelése kiemelt jelentőségű a biztonságos üzemeltetés szempontjából. Biztonsági szoftverek: Rendszereink biztonságát nem csak az operációs rendszer saját eszközeivel, hanem külső szoftverek integrálásával is növelhetjük. Hozzá kell azonban tenni, hogy a külső szoftverek alkalmazása nem jelenti azt, hogy a korábbi pontokat elhanyagolhatjuk a rendszer megerősítése szempontjából. A kétféle megoldásnak minden esetben javasolt együtt és nem egymást helyettesítve működnie. A legismertebb biztonsági szoftver típus a különböző vírusirtó szoftverek, melyek feladata az ártó kódok elleni védekezés biztosítása. További tipikus biztonsági szoftvertípusok az alábbiak:       Host alapú behatolás detektáló Tűzfal Titkosító, hitelesítő alkalmazás Naplózó kliens Biztonsági policy-t ellenőrző alkalmazások Adatmentő alkalmazás Vállalati környezetben ezek közös jellemzője, hogy valamilyen központi menedzsment felületről lehet őket kezelni, megkönnyítve a rendszer adminisztrációját. Alkalmazások védelme Az alkalmazások védelme alapvetően megegyezik az operációs rendszerek védelme fejezetben leírtakkal. Itt is fontos szempont a gyártó által kiadott javítások rendszeres telepítése, a hozzáférések és jogosultságok pontos beállítása. Tipikusan az alkalmazások gyakran saját jogosultsági rendszerrel rendelkeznek, melynek finomhangolása és pontos beállítása alapvető egy nagyvállalati környezetben. Tipikus biztonsági hibaforrás, hogy az üzemeltetők pontosan és részletesen szabályozzák a fájlstruktúrához történő hozzáféréseket és az operációs rendszerekbe történő bejelentkezést, a vállalat központi alkalmazásait azonban minden egyes felhasználó azonos jelszóval használja, vagy akár sokszor megegyező IT biztonságról közérthetően Oldal 46 Informatikai biztonsági koncepció néven is lépnek be. Ha meggondoljuk a cég érzékeny adatainak jó része megtalálható az olyan céges alkalmazásokban, mint számlázó, iktató rendszer, vagy vállalatirányítási rendszer, esetleg CRM alkalmazás. Éppen ezért ezeknek az alkalmazásoknak a hozzáférését éppen úgy kell(ene) védeni, mint az állományokat operációs rendszer szinten. Az alkalmazásba történő bejelentkezés során javasolt megvizsgálni, hogy a jelszó titkosítva halad-e át a hálózaton. Web-es alkalmazásoknál a bejelentkezéshez javasolt HTTPS kapcsolatot használni. A mentések fontossága már hangsúlyozva lett korábban. Itt a mentett állományok kezelésére és tárolására szeretnék még kitérni. Ha a mentéseket nyilvános helyen tároljuk és mindenki hozzáfér, akkor szintén kiadjuk a cég érzékeny adatait. Rendelkezésre állás biztosítása, riasztások kezelése Akár mennyire is korlátozzuk az adatokhoz történő hozzáférést, nem szabad megfeledkezni a fő célról. Az informatikai rendszerek szolgáltatásokat nyújtanak, melyeket mások (pl.: a felhasználók) igénybe vesznek. Az üzemeltetés fő feladata ennek folyamatos biztosítása. Ennek megvalósításához több oldalról kell egyszerre biztosítani a rendszerek működését. Rendelkezésre állás Rendelkezésre állás az a tényleges állapot, amikor is egy informatikai rendszer szolgáltatásai - amely szolgáltatások különbözők lehetnek - állandóan, illetve egy meghatározott időben rendelkezésre állnak, és a rendszer működőképessége sem átmenetileg, sem pedig tartósan nincs akadályozva. Ebben az összefüggésben jelentősége van az információ vagy adatok rendelkezésre állásának, elérhetőségének is. Értékét legtöbbször %-ban adjuk meg, éves időintervallumra vetítve. Például: 99%-os rendelkezésre állás azt jelenti, hogy az év 365 napjának 99%-ban a szolgáltatás elérhető. Ez első hallásra nem tűnik rossznak, de ez 3,56 nap állást jelent. Ha belegondolunk, ez több mint 85 óra. Ha ez a 85 óra kiesés munkaidőben történik, akkor összességében akár egy hét is lehet. De mit szólna egy vezető ahhoz, hogy alkalmazottai évente egy hetet nem tudnak dolgozni? „Ami elromolhat, az el is romlik!” Ezt Murphy óta tudjuk. Ennek megelőzésére a kritikus informatikai rendszereket feltétlenül érdemes nagy rendelkezésre állással tervezni. Ez gyakorlatilag azt jelenti, hogy lehetőleg minél több komponenst duplikálunk, és a duplikált rendszereket úgy kötjük össze, hogy ha az egyik kiesik, akkor a másik azonnal (leállás nélkül) a helyébe léphessen. Tipikusan elromló berendezések lehetnek a tápok, illetve a diszkek. Ezeket már egy kiszolgálón belül is lehetőség van duplikálni, vagy diszkek esetében RAID5 technológiát alkalmazni. IT biztonságról közérthetően Oldal 47 Informatikai biztonsági koncepció Egy tipikus HA (High Availability) megoldás nagy rendelkezésre állású kiszolgáló rendszer kialakítására5: Tovább növelve a rendelkezésre állást, akár a teljes kiszolgálót duplikálhatjuk. De tárolhatjuk adatainkat, illetve virtualizációt alkalmazva kiszolgálóinkat is, független diszkrendszereken, melyeket lehetőségünk van több fizikai szerver között megosztani. Ha ezeket a kiszolgálókat meglehetős távolságra helyezzük el egymástól, akár katasztrófa helyzetben sem kell adataink és szolgáltatásaink miatt aggódnunk. Az egyes szervereket, mint fájlokat, másolgathatjuk automatizált formában, és ahhoz a fizikai kiszolgálóhoz rendeljük, amelyik éppen működőképes. Természetesen mindennek ára van és bármilyen beruházás előtt érdemes pontosan kiszámolni, hogy az adatok rendelkezésre állása mekkora beruházást is ér meg valójában. Megelőzés, riasztás Milyen jó is volna tudni előre, hogy mi az, ami legközelebb el fog romlani, illetve ha már elromlik, valaki értesíthetne azonnal, hogy cselekedni kell! Valójában egyik kívánság sem újdonság, komolyabb rendszerek esetében mindkettőre régen alkalmaznak megoldásokat. 5 http://en.wikipedia.org/wiki/High-availability_cluster (HA topológia) IT biztonságról közérthetően Oldal 48 Informatikai biztonsági koncepció Egy berendezés, mielőtt végleg meghibásodik és megáll, a legtöbb esetben hetekkel, hónapokkal előbb produkál olyan eseményeket, melyek a hiba bekövetkeztére utalnak. Ezek az események általában jóval a tényleges leállás előtt megjelennek a rendszernaplókban. A probléma ott van, hogy a napi több ezer (vagy több millió) esemény között megbúvó hibajegyeket általában nincs ember, aki észrevegye. Ezért nem is emberekkel nézetik végig a bejegyzéseket, hanem alkalmazásokkal, melyek előre meghatározott mintákat keresnek a naplóállományokban. Amennyiben egy ilyen, előre definiált, esemény bekövetkezik, ez más automatizált folyamatokat indít el (pl: email, sms küldés, adat mentés indítása, stb.), így a megfelelő emberek rögtön tudomást szereznek a problémáról. A rendszer határértékeit, riasztási mintáit érdemes pontosan meghatározni, ellenkező esetben könnyen úgy járhatunk, mint a kiskondás a mesében, aki állandóan farkast kiáltott, vagy a másik véglet szerint akkor sem riaszt a rendszerünk, ha tényleg baj van. Ennél fontosabb azonban, hogy arról is kapjunk információt, ha egy rendszer tényleg váratlanul elérhetetlenné válik, akár azért mert meghibásodott, akár azért, mert a hozzá vezető hálózaton történt valamilyen hiba. A tipikus megoldás ebben az esetben, hogy egy olyan független monitorozó rendszert alkalmazunk, amely folyamatosan, rendszeres időközönként ellenőrzi, hogy kritikus eszközeink elérhetőek, illetve szolgáltatásaink megfelelően működnek. Természetesen a riasztás és ellenintézkedések foganatosítása ebben az esetben is kritikus fontosságú. A rendszerek monitorozása két módon történhet: 1. Távolról, vagyis hálózaton keresztül ellenőrzi a monitor rendszer, hogy minden rendben van-e kritikus alkalmazásaink és szolgáltatásaink körül. 2. Telepített Ügynök (Agent) segítségével belülről is rálát a rendszerre. Persze, szokás szerint mindkét esetnek van előnye és hátránya egyaránt. Egy telepített alkalmazás általában jóval több és részletesebb adatot tud gyűjteni, azonban egy kritikus erőforrás és alkalmazások szempontjából is finomhangolt - rendszer működését akár jelentős mértékben is visszavetheti egy rosszul beállított vagy nem kompatibilis helyi monitorozó alkalmazás, amely rendszeresen vizsgálgatja a rendszer által használt állományokat. Hitelesítés Általában elmondható, hogy a hitelesítés és jogosultságok kezelése az informatikai biztonság Alfája és Omegája. Alapvetően ezzel biztosíthatjuk adataink bizalmasságát, hiszen csak meghatározott személyeknek engedélyezzük, hogy egyáltalán hozzáférhessenek az információhoz. Ez a folyamat azonban több lépésből áll. Először is egy hiteles azonosítás szükséges, melynek során egyértelműen be kell tudnunk azonosítani a hozzáférést kérőt. Ezt a folyamatot autentikációnak hívjuk. Tipikus esetben az autentikáció két faktorból áll össze: 1. Név, vagy azonosító (Vagyok valaki) 2. Egyedi jelszó (Tudok valamit) IT biztonságról közérthetően Oldal 49 Informatikai biztonsági koncepció Ezt speciális esetekben azonban érdemes megfejelni egy harmadik faktorral: 3. Biometria, token, OTP (Van valamim) Három faktoros autentikáció: Az egész folyamat során kiemelt jelentősége van az alábbiaknak: 1. Az autentikációs folyamatot harmadik félnek ne legyen lehetősége nyomon követni. (Ha valakinek sikerül megszerezni a jelszavunkat, akkor meg tud bennünket személyesíteni. Ezzel nem csak hozzáfér az adatainkhoz, de képessé válik akár bűncselekmények elkövetésére is a mi nevünkben.) 2. A hitelesítési adatok biztonságos módon, visszafejthetetlen titkosítással kerüljenek tárolásra, harmadik fél által hozzáférhetetlen módon. (Ellenkező esetben illetékteleneknek lehetősége lesz az összes felhasználói adat megszerzésére és a teljes hitelesítési rendszerünk összeomlik.) A hitelesítés megvalósítása több módon történhet. Egyszerűbb esetben a kliens elküldi a nevet és a jelszót, úgy ahogyan a felhasználó ezt begépelte. A szerver ezt ellenőrzi, vagyis összehasonlítja a nevet a felhasználói listájában, illetve a jelszót a jelszólistában. Ha egyezést talál, akkor engedélyezi a bejelentkezést. Ilyen egyszerű hitelesítésre példa a POP3 protokoll, mellyel az elektronikus leveleinket tölthetjük le a szolgáltatótól, illetve egy apache webszerver htaccess fájl alapján történő hitelesítése. Egy tipikus POP3 példa Telnet klienssel megvalósítva. A félkövérrel szedett sorok a kiadott parancsokat jelentik. A normál betűk a POP3 szerver által küldött válaszokat: C:\>telnet freemail.hu 110 IT biztonságról közérthetően Oldal 50 Informatikai biztonsági koncepció +OK user Tesztuser +OK pass titkosjelszo +OK list +OK 1 1400 . retr 1 +OK Return-Path: Delivered-To: [email protected] Date: Mon, 9 Apr 2012 14:14:18 +0200 (CEST) Subject: Teszt Hello Word! dele 1 +OK quit +OK A kapcsolat megszakadt az állomással. C:\Users\Hzs> A kommunikációt teljes egészében látjuk és értelmezhetjük. A [email protected] címről érkezett egy levél a [email protected] címre. A levél fejléce „Teszt” volt, a tartalma összesen két szó: „Hello Word!”. A kliens először kilistáztatta a szerverrel, hány levele érkezett (list), majd letöltötte magához a levelet (retr 1), majd törölte a szerverről IT biztonságról közérthetően Oldal 51 Informatikai biztonsági koncepció (dele 1). Ugyanez a forgalom jelenik meg ilyenkor a hálózaton is, és bárki, aki ezt képes megszerezni, ugyanígy láthatja a személyes információkat. Összetettebb esetben, saját autentikációs protokollt használunk. Ennek több előnye is van: Az autentikáció után rögtön lehetőség van a különböző engedélyezett erőforrásokhoz történő hozzáférés kezelésének. Ezt a folyamatot autorizációnak hívjuk. Az autentikációs protokollok jóval összetettebbek, titkosított, hitelesített kommunikációt igényelnek a kliens és a hitelesítő szerver között, továbbá időbélyeget használnak a pontos azonosítás érdekében, és erőforrások széles köréhez képesek így hozzáférést biztosítani. A kliens sikeres autentikáció és autorizáció után egy jegyet (ticket) kap a szervertől, mellyel képes a továbbiakban azonosítani magát a hálózaton. Tipikus autentikációs protokoll a Kerberos, mely egy kulcscsere alapú hitelesítési eljárást alkalmaz, és többek között a Microsoft tartományvezérlő kiszolgálók is ezt használják hitelesítésre. A Kerberos működését az alábbi sematikus ábra szemlélteti6: KDC: Key Distribution Server AS: Authentication Server TGT: Ticket Getting Ticket 6 http://mccltd.net (Kerberos sematikus ábra) IT biztonságról közérthetően Oldal 52 Informatikai biztonsági koncepció 1. A kliens először a kulcs kibocsátó szerverhez (KDC) fordul és hitelesíti magát. 2. Sikeres hitelesítés után egy azonosító jegyet igényel és kap. 3. A jeggyel már képes más szolgáltatásokat igénybe venni. Az autentikáció és autorizáció után a kliens elindul a dolgára, de ettől még nem szabad szem elől téveszteni. A nyomkövetésre szolgál az accounting, melynek révén bárhol is próbál a kapott jeggyel érvényesülni, ez valamilyen formában tárolásra kerül. Így biztosítható, hogy a kliens minden cselekménye visszakereshetővé válik. Együttesen ezt a három funkciót AAA néven ismerik, és a felhasználók teljes körű hitelesítési eljárását jelenti. Jogosultságkezelés Az előző fejezetben tárgyalt középső A betű, az autorzáció jelenti azt a folyamatot, melynek során hozzáférési jogokat biztosítunk a különböző erőforrásokhoz (pl.: hálózati megosztás, nyomtatás, weboldal elérése). Azt a logikai rendet, amely alapján a különböző jogosultságokat megtervezzük és kiosztjuk jogosultsági rendszernek nevezzük. A megfelelően működő jogosultsági rendszernek több kritériuma is van, melyek közül az alábbiak a legfontosabbak: 1. Megkerülhetetlenség: Könnyű belátni, hogy ha a kiosztott jogosultságokat, korlátokat meg lehet kerülni, az egész rendszer értelmetlenné válik. 2. „Need to know” elv: Csak a szükséges minimum jogok kerüljenek kiosztásra. 3. Csoport alapú jogkezelés: Ez az elv azt jelenti, hogy igyekezzünk mindig csoportokhoz jogosultságot rendelni és ne egyénekhez. Egy jogosultsági rendszer tervezésekor mindig érdemes átlátható, könnyen karbantartható logikát felépíteni. Ennek legegyszerűbb módja, ha az azonos szintű jogokkal rendelkező entitásokat közös csoportokba rendezem, és csak a csoportokat rendelem hozzá ahhoz az erőforráshoz, melyhez a hozzáférést biztosítani akarom. A csoportképzés egyik jól kezelhető elve, hogy az egyes felhasználói csoportokat a szervezet működési felépítése alapján alakítom ki. Általában elmondható, hogy az azonos területen dolgozók, azonos állományokhoz, programokhoz kell, hogy hozzáférjenek. Ha ezt tartom szem előtt, a tervezéskor átlátható, világos szerkezetű csoport és erőforrás struktúrát kapok, melyet könnyű üzemeltetni. IT biztonságról közérthetően Oldal 53 Informatikai biztonsági koncepció Az alábbi ábra alapján a Konyveles_group csoportba tartozó felhasználók hozzáférnek a Konyveles mappához, a Konyveles_boss_group csoportba tartozók, pedig egyaránt hozzáférnek a Konyveles_vezetok_mappához és a Konyveles mappához: User1 User2 User3 Konyveles_vezetok Konyveles_boss_group Konyveles Fájlszerver User4 User5 User6 Konyveles_group Ez az egyszerű elv segít abban, hogy egy mappához történő új hozzáférést átlátható módon tudjunk kezelni: az új felhasználót berakom abba csoportba, amelyik hozzáférhet a kérdéses mappához. Ennél természetesen léteznek bonyolultabb eljárások is, különösen nagyméretű infrastruktúrákban. Tipikus példa egy olyan Microsoft Active Directory címtár struktúra, mikor több tartomány kerül kialakításra, erdőbe rendezve és szükség van tartományok, fák, vagy erdők közötti kereszt jogosultságok kiosztására. A címtárak olyan adatbázisok, melyek lehetővé teszik a tartományokba tartozó objektumok (fájlok, megosztások, perifériák, kapcsolatok, adatbázisok, felhasználók, csoportok stb.) központosított tárolását és adminisztrálását. Ekkor az úgynevezett AGDLP erőforrás kiosztási eljárást javasolt alkalmazni, mely az alábbi logika szerint épül fel: IT biztonságról közérthetően Oldal 54 Informatikai biztonsági koncepció 1. A felhasználókat global csoportokba kell rendezni. 2. A különböző erőforrásokhoz local csoportokat kell rendelni. 3. A global csoportokat a megfelelő local csoportok tagjaivá kell tenni Beszélni kell a különböző jogosultsági típusokról is. Ezeket talán a fájlokhoz rendelhető jogosultságok alapján egyszerű megérteni. Az egyes jogosultságok fő típusai a UNIX rendszerek megjelenése óta, vagyis bő 40 éve nem változtak jelentősen, és ez alapján a legegyszerűbb bemutatni őket. Alapvetően megkülönböztetünk:    olvasási jogot (r: read) írási jogot (w: write) végrehajtási jogot (x: execute) Természetesen sok egyéb jogosultság is létezik. Ráadásul az egyes alkalmazások külön alkalmazás-specifikus jogok kiosztását is kell, hogy támogassák, az alapelvek azonban megegyeznek az itt tárgyaltakkal. Titkosítás, hitelesítés Az információ titokban tartása, csak „beavatottak” számára történő megosztása, szinte egyidős az emberiséggel. A különböző titkosírások története minden kultúrában felbukkan és a titok titokban tartása gyakran háborúkat is képes volt eldönteni. A leghíresebb ilyen eset a II. világháborúhoz kötődik, mikor a német titkosító berendezés, az Enigma kódját sikerült feltörni lengyel kriptográfusoknak és matematikusoknak, jelentős előnyöket nyújtva ezzel a szövetséges haderőknek. Az informatikában a titkosítás vagy rejtjelezés a kriptográfiának az az eljárása, amellyel az információt (nyílt szöveg) egy algoritmus (titkosító eljárás) segítségével olyan szöveggé alakítjuk, ami olvashatatlan olyan ember számára, aki nem rendelkezik az olvasáshoz szükséges speciális tudással, amit általában kulcsnak nevezünk. Elképzelhető azonban olyan szituáció, mikor a titkosított kód rendben megérkezik a címzetthez, de a benne tárolt és IT biztonságról közérthetően Oldal 55 Informatikai biztonsági koncepció visszafejtett információ kompromittálódott. Ez egy informatikai környezetben tipikusan akkor fordul elő, ha a két kommunikáló fél közé beékelődik egy harmadik, aki rendelkezik a visszafejtő kulccsal, és kedve szerint tudja módosítani a küldött üzeneteket. Közismert nevén Man in the Middle támadásnak hívják ezt a fajta eljárást, és talán a legjobban az alábbi vicc képes szemléltetni: Amerikában elkapnak egy mexikói bankrablót és a sheriff egy spanyol tolmács segítségével hallgatja ki a bűnözőt: Sheriff a Tolmácshoz: Kérdezze meg, hová dugta pénzt. Ha nem mondja meg, rögtön lelövöm. Tolmács a Rablóhoz: Hová dugtad a pénzt? Mond meg, mert főbe lőnek. Rabló a Tolmácshoz: A templomkertben ástam el, a nagy tölgytől északra. Tolmács a Sheriffhez: Nem fél a haláltól. Természetesen a példa sántít, mivel valódi Man in the Middle támadás esetén a kommunikáló felek nem tudhatnak a beékelődött harmadikról. A példa azonban jól szemlélteti, hogy a titkosítás mellett szükség van olyan eljárásokra, melyek az információ és a küldő hitelességét és önazonosságát hivatottak biztosítani. A titkosítási eljárások két fő csoportba oszthatók: 1. Szimmetrikus kulcsú titkosítás 2. Nyilvános kulcsú titkosítás Mindkettőt rendszeresen használjuk, akár együtt is, és mindkettő más-más előnyökkel és hátrányokkal rendelkezik. A Szimmetrikus kulcsú titkosítás már nagyon régóta létezik. Lényege, hogy a titkosítási eljárás során 1 db kulcsot használok, mely a titkosításra és a visszafejtésre is szolgál. Ebben az esetben nagyon fontos, hogy ezt a kulcsot, hogyan juttatom el a partner félnek vagy feleknek, akikkel titkosítva szeretnék kommunikálni. Ha a kulcscsere során a titok sérül, és a kulcs illetéktelenek kezébe kerül, akkor hiába minden, a titkos információ bizalmasságát nem lehet szavatolni. A szimmetrikus titkosítás logikai ábrája: ...10100011101010111110001... IT biztonságról közérthetően Oldal 56 Informatikai biztonsági koncepció Tipikus szimmetrikus titkosítási eljárások: DES, 3DES, AES, IDEA A kulcscsere problémáját hivatottak megoldani a nyilvános kulcsú titkosítási eljárások. Ennek során kulcspárokat használunk, melyek az alábbi fontos tulajdonsággal bírnak: Az egyik kulccsal eltitkosított tartalmat csak és kizárólag a másik kulccsal lehet visszafejteni és viszont. Ekkor a kulcsok közül az egyiket kinevezem publikus kulcsnak, és bárkinek közre adom, akivel titkosan szeretnék kommunikálni; a másikat viszont privát kulcsként kezelem, és a továbbiakban „a szívem felett őrzöm”. A nyilvános kulcsú titkosítás logikai ábrája: ...10100011101010111110001... Privát kulcs Publikus kulcs Ezzel a megoldással nem csak a kulcscsere és a titkosítás, hanem a hitelesítés problémáját is sikerült megoldani az alábbiak szerint: 1. Titkosított üzenetet küldök, ha az üzenetet a partnerem publikus kulcsával kódolom el. Ekkor ezt az üzenetet csak és kizárólag az ő privát kulcsával lehet visszafejteni, ami csak nála lehet. 2. Hiteles információt küldök, ha az üzenetet a saját privát kulcsommal kódolom el. Ekkor az üzenetet csak azén közreadott publikus kulcsommal lehet visszafejteni, ami azt bizonyítja, hogy csak az én privát kulcsommal készülhetett. 3. Titkos és hiteles üzenetet küldök, ha a titkosítás után az üzenetet még az én privát kulcsommal is aláírom, ezzel bizonyítva, hogy az információ minden kétséget kizárólag tőlem származik. Nagyméretű infrastruktúra esetén szükség lehet arra, hogy a nyilvános kulcsok kezelését egy központi rendszer végezze. Ezt az infrastruktúrát, melynek feladata a kulcsok kibocsátása, karbantartása, visszavonása és hitelesítése, PKI-nek nevezzük (Public Key Infrastructure). Egy nagyméretű szervezeten belül azonban szeretnénk tudni, hogy ki is az, akiben megbízhatunk, ha kulcsot cserélünk vele. Egy internet méretű hálózaton ez a fajta elvárás különösen fontos. Ezért létrejöttek olyan szervezetek, melyek feladata a publikus kulcsok hitelesítése. Közmegegyezéses alapon mindenki megbízik néhány kulcskibocsátó szolgáltatóban, és ha ők aláírnak egy publikus kulcsot, akkor annak a kulcsnak a tulajdonosában is megbízunk. Pontosan ezen az elven működnek a különböző internetes banki rendszerek. A titkosított (HTTPS) oldalukat a böngészőnk hitelesnek fogadja el, mivel egy mindenki által hitelesnek tartott PKI szolgáltató írta alá az oldal tanúsítványát. Ha IT biztonságról közérthetően Oldal 57 Informatikai biztonsági koncepció azonban egy titkosított oldal nem rendelkezik hiteles tanúsítvánnyal, akkor minden okunk megvan a kételkedésre a kibocsátó valódisága felől. Ha gond van az oldal hitelességével, azt általában a böngésző programok is rögtön jelzik: Visszatérve egy vállalati környezetre, természetesen nincs akadálya, hogy ilyen nyilvános kulcsú infrastruktúrát használjunk céges környezetben, azonban mint minden más esetben, úgy itt is fontos a célok pontos meghatározása és a részletes előzetes tervezés. Talán nincs is még egy olyan területe az informatikai biztonságnak, ahol ennyi sikertelen projekt indult volna, mint a vállalati szintű PKI struktúra kialakítása. A különféle titkosítási, illetve jelszókezelési eljárások közös gyenge pontja lehet, ha túl rövid kulcsot választunk. Noha a ma használt titkosítási eljárások matematikai úton nem fejthetők vissza a kulcs ismerete nélkül, a próbálgatás módszerével azonban mindig célt lehet érni. Csupán elég idő, illetve elég nagy számítási kapacitás szükséges hozzá. Adataink védelmének szempontjából egyáltalán nem mindegy, hogy ez az „elég idő” mindössze néhány napot, vagy néhány ezer évet jelent. Az egyes kulcsok hossza és a titkok megfejtésének várható ideje között ugyanis pontosan itt van a különbség. VPN A titkosítás, titkosított adattovábbítás elterjedése új lehetőségeket nyitott távoli hálózatok összekötésére, illetve a felhasználók távoli munkavégzésére. Virtual Private Network (VPN) feladata, hogy nem megbízható hálózat (internet) fölött, hiteles, titkosított módon biztosítson összeköttetést, számítógépek, illetve hálózatok között. Alapvetően két fajtáját különböztetjük meg: IT biztonságról közérthetően Oldal 58 Informatikai biztonsági koncepció Site-to-site VPN, mely hálózatok összekötésére szolgál. Tipikus felhasználási területe, mikor egy több telephellyel rendelkező vállalat telephelyei kerülnek összekapcsolásra. Ekkor logikailag a teljes elosztott hálózat egynek látszik. Ebben az esetben az összeköttetés két fix IP címről történik, és általában a telephelyeken elhelyezett tűzfalak építik fel egymás között a kapcsolatot. Road-Warrior VPN, melynek során egyes távoli felhasználók csatlakoznak be a céges hálózatba, tipikusan mobil munkaállomásokról, hogy a céges informatikai erőforrásokat, információkat igénybe vegyék. Sok esetben használják távmunka végzésére, de jellemző felhasználási területe a távoli rendszeradminisztráció is. A VPN kapcsolatok tervezése és kiépítése során az alábbi szempontokat kell szem előtt tartani: 1. Válasszunk megbízható titkosítást! Több VPN-képes protokoll is használatos, és az egyes protokollok konfigurálása során is számtalan beállítási lehetőséggel lehet élni. Általánosan ki lehet jelenteni, hogy az IPSec és SSL alapú VPN technológiák tekinthetők megbízhatónak. Természetesen itt is sok függ a titkosítás módjától. A próbálgatásos feltörési módszerek (Brute Force Attack) ellen ugyanis sajnos egyedül a minél nagyobb kulcs nyújt védelmet. Ide tartozik a VPN felhasználók és gépeik hitelesítése is. Megbízható hitelesítési megoldás lehet az egyszer használatos jelszavak bevezetése, illetve kombinálása a standard VPN hitelesítéssel. SSL alapú VPN-ek működése során elvileg a kliens bármilyen idegen gépről létesíthet kapcsolatot, elég egy böngészővel letölthető kisalkalmazást telepíteni a gépre. Talán nem kell részletezni, hogy milyen károkat képes okozni egy otthoni, tipikusan vírusokkal többszörösen felülfertőzött gép egy nagyvállalati hálózaton. 2. Védjük a klienseket! A távoli kliens, miután bejelentkezett, logikailag a céges hálózatunk részévé válik. Előtte nem tudjuk, hogy hol járt, milyen hálózatokra csatlakozott. Ezért nagyon fontos, hogy a mobil kliensek esetében kifejezetten szigorú biztonsági szabályokat alkalmazzunk a vírusvédelem, desktop tűzfal, javítócsomagok, betörés detektáló alkalmazások tekintetében. Lehetőség van a kliensek biztonsági beállításainak automatizált ellenőrzésére a VPN kapcsolódás engedélyezése előtt. Ekkor, ha egy előfeltétel nem teljesül (pl.: a vírusirtó adatbázisa nem friss), a kapcsolat nem jöhet létre. 3. Védjük a hálózatot a kliensektől! A külső VPN kapcsolatok minden biztonsági intézkedés ellenére kockázatot hordoznak magukba. Nem láthatjuk, hogy valójában kit és milyen környezetből engedünk be a hálózatunkra. Ezért javasolt a VPN-ről elérhető szolgáltatásokat csak a legszükségesebbekre korlátozni, illetve a VPN kliensek számára külön biztonsági zónát kialakítani. 4. Naplózzunk! A VPN kapcsolatok naplózása és nyomon követése üzemeltetési, hibakeresési és biztonsági szempontokból egyaránt hasznos és fontos szempont. IT biztonságról közérthetően Oldal 59 Informatikai biztonsági koncepció Határvédelem A vírusok mellett a tűzfalak az informatika „legromantikusabb” szereplői. A klasszikus tűzfal értelmezés szerint egy vállalati tűzfal egy középkori várfalhoz hasonló módon védi a privát hálózatot a külvilágtól. A technika fejlődésével, illetve a hálózatok határainak megváltozásával a tűzfalak szerepe, feladata és működésük is jelentős változáson ment keresztül. A tűzfalak működésének megértéséhez röviden és nagyon felszínesen érdemes megismerni az internetes hálózati kommunikáció, vagyis a TCP/IP protokollcsalád működését: A számítógépes hálózatokon a gépek egymással hálózati csomagok küldésével és fogadásával kommunikálnak. A küldendő információt kisebb-nagyobb adatcsomagokra bontják, berakják egy borítékba, azt megcímzik, mint egy levelet és elküldik a hálózaton keresztül. A címzett megkapja, kicsomagolja, és az adattartalmat összegyűjtve felhasználja (pl.: összeállítja egy weboldallá, amit letöltöttünk megnézni). Az egész hálózati forgalomban a boríték játssza a legfontosabb szerepet, mert arra van ráírva, hogy ki a küldő és ki a feladó. Apró nehezítés a hasonlat pontos megértésében, hogy nem egy, hanem egyszerre több borítékba csomagolják az adatot, amit más-más módon címeznek meg. A fogadó fél egymás után kibontja a borítékokat és értelmezi a címzéseket, aminek a végén megkapja az adatot. Ezeket a „borítékokat” nevezzük hálózati rétegeknek, és úgy működnek, mint a Matrjoska babák, aminek a közepén csücsül az adat, amit küldünk. Az egyes hálózati rétegeket az alábbi ábra szemlélteti7: 7 http://ccna5.com/ (OSI rétegek) IT biztonságról közérthetően Oldal 60 Informatikai biztonsági koncepció A Fizikai réteg – Physical Layer a legalsó szint (legkülső boríték), mely biztosítja, hogy az egyes bitek kikerüljenek a kommunikációs csatornára (Pl.: rézkábel), továbbá az adó és a vevő azonos módon értelmezze a jeleket. Az Adatkapcsolati réteg – Data Link Layer felel a szomszédos gépek közötti hibamentes átvitel biztosításáért. A hálózati kártyák egyedi címeit használja azonosításként (MAC address). Hálózati réteg – Network Layer felelős az egyes hálózatok közötti kommunikáció biztosításáért. Ebben a rétegben jelennek meg az IP címek és hálózati címek, itt zajlik az útválasztás (routing), amely az internet működésének legfontosabb eleme. Szállítási réteg – Transport Layer szintén hibaellenőrzést végez, de már a végpontok között, továbbá meghatározza az összeköttetés egyéb jellemzőit. Itt jelennek meg a portok, vagy kapuk, melyek révén nyomon követhetők az egy gépen, egyidejűleg futó különféle alkalmazások üzenetei. Alkalmazási réteg – Application Layer a felső három réteget az egyszerűség kedvéért most együtt értelmezzük. Már a szállítási rétegben megjelenő port számában utaltunk rá, de ebben a rétegben dől el végképp, hogy milyen módon is kommunikálunk, pl.: egy weboldalt akarunk kérni vagy egy emailt küldeni. A Hitelesítés fejezetnél tárgyalt POP3 levél lekérés a 3-4-5 hálózati rétegek szerint így épül fel:    Hálózati réteg: Forrás IP; Cél IP Szállítási réteg: Forrás port (pl.: 1024); Cél port (POP3: 110) Alkalmazási réteg: Itt jelennek meg azok a parancsok és a válaszul küldött adatok, melyek a korábbi fejezetben be lettek mutatva (USER; PASS; LIST; RETR; DELE; QUIT). A borítékos példából kiindulva, a tűzfal egy olyan postamesterre hasonlít, aki megnézi a levelek címzését (akár több borítékba is belekukkant), és nemcsak továbbítja a címzettnek a levelet, hanem pontosan meghatározott szabályok alapján eldönti, hogy a címzett kaphat-e ilyen levelet ettől a feladótól. A pontos definíció szerint a tűzfal feladata az általa határolt bizalmi zónák, hálózati szegmensek tranzit forgalmának biztonságos, azonosított és megfelelő szinten naplózott kezelése, az adott informatikai infrastruktúrára vonatkozó biztonsági szabályzat előírásainak kikényszerítése. A tűzfal tehát az általa felügyelt hálózatokat zónákra osztja. Az egyes zónák között a forgalom csak a tűzfalon keresztül haladhat át (a tűzfal mindegyik zónába beletartozik egyegy hálózati kártyával). A zónákat különböző biztonsági szintekre szokták besorolni, és a szabályokat ezekhez igazítják. IT biztonságról közérthetően Oldal 61 Informatikai biztonsági koncepció Az alábbi logikai ábra egy kisméretű infrastruktúra tipikus, 3 zónával rendelkező tűzfalát és zónáit ábrázolja: Internet Web szerver Demilitarizált zóna Intranet Az ábrán látható tűzfal három zónája: Internet: Nem megbízható zóna DMZ: Korlátozottan megbízható, un. demilitarizált zóna. Tipikusan az internetről elérhető szolgáltatások kerülnek ide (Pl.: céges web-szerver, publikus ftp-szerver, stb.), hogy esetleges sérülésük ne veszélyeztesse a vállalat érzékeny, belső adatait. Intranet: Megbízható zóna. A cég belső hálózata, ahol a kiszolgálók és munkaállomások, valamint a céges adatok találhatók. IT biztonságról közérthetően Oldal 62 Informatikai biztonsági koncepció Tűzfal szabályok tervezésére vonatkozó alapvető szabályok a következők: 1. A tűzfal zónái között forgalmat kezdeményezni mindig a magasabb biztonsági szintű zónából lehet az alacsonyabb felé (Pl.: mi a védett hálózatból kilátunk az internetre, de az internet ne lásson be hozzánk). 2. A tűzfalak szabályait a szükséges minimum elv alapján kell kialakítani (Pl.: ha egy gépnek engedélyezni kell egy speciális adatcsatornát, azt a vele azonos zónában lévő gépek már ne tudják használni). 3. Lehetőség szerint titkosított forgalmat ne vezessünk keresztül a tűzfalon ellenőrzés nélkül (ezt a szabályt korlátozottan lehet csak betartani, hiszen a dolgozók internet bankolásának ellenőrzése több adatvédelmi törvényt is sért, az internet bankolás pedig titkosított SSL csatornán történik.). A tűzfalak fejlődése valójában az alkalmazott ellenőrzési technológiák kiterjesztését jelenti, ezért a működés megértését segíti egy rövid összefoglaló: Bastion host A „bástya számítógép” egy speciálisan megerősített számítógép, melyre a kliensek bejelentkeznek, és a kevésbé megbízható szolgáltatásokat innen veszik igénybe. Előnye, hogy csak egy gép biztonságáról kell gondoskodni. A mai tűzfalak megerősített, feladatra orientált és felesleges szolgáltatásoktól lecsupaszított (restricted) operációs rendszerei a bastion host-ok utódainak tekinthetők. Ma is használunk ilyen megoldásokat, gyakori, hogy védett, bizalmas környezetből az internet elérést (böngészés, levelezés) csak ilyen megerősített, elszeparált gépekről engedélyezik, melyek érzékeny adatokat nem tartalmaznak és ezekről továbbhaladni a belső zónák felé nem lehet. Csomagszűrő tűzfal Ez tekinthető az első igazi tűzfalnak. A hálózati rétegek közül a 3-4-ben dolgozik, vagyis meg tudja határozni, hogy milyen IP címről és portokról, milyen IP címre és portokra engedi a forgalmat. Jellemzője, hogy a válaszok számára külön szabályban kell engedélyezni, hogy visszataláljanak a küldőhöz. Állapottartó-csomagszűrő tűzfal Az előző továbbfejlesztett változata. Itt az elküldött kéréseket és tulajdonságaikat a tűzfal egy állapottáblában rögzíti és az ezekre érkező válaszokat már a tábla alapján automatikusan visszaengedi, nincs szükség külön visszaengedő szabályra. A csomagszűrő tűzfalak a leggyakoribb tűzfal megoldások. Közös jellemzőjük, hogy nem látnak bele az alkalmazásba, amit az adott porton továbbengednek, használatukkal csak kinyitjuk azt a kaput, amin az adott szolgáltatás általában menni szokott. Ez adatszivárgási szempontból komoly problémákhoz vezethet, megoldására több alternatíva is létezik. IT biztonságról közérthetően Oldal 63 Informatikai biztonsági koncepció Alkalmazás-proxy tűzfal A tűzfalak legszofisztikáltabb verziója. A csomagszűrésen túl, képes az alkalmazási rétegben is ellenőrizni az áthaladó forgalmat, így nem lehet hamisított portok használatával átverni, mint egy csomagszűrőt. Fontos tulajdonsága még, hogy itt nem csomagtovábbítás, hanem csomag újraépítés történik, tehát ha az eredeti hálózati csomag tartalmazott is valami szabálytalanságot, azt a tűzfal nem fogja továbbítani. Az általános hiedelemmel ellentétben a támadók szinte soha nem a tűzfalat „törik fel”, mivel maga tűzfal ebből a szempontból általában egy meglehetősen zárt, robosztus rendszer. A cél általában egy tűzfalon keresztül kiajánlott szolgáltatás, tipikusan egy publikus web szerver. A legtöbb esetben ilyenkor a web szerver gyengeségét (pl.: javító csomag hiánya, vagy túlzottan megengedő jogosultságok) használják ki. Egy csomagszűrő tűzfal semmilyen formában nem vesz részt ebben a folyamatban, mivel a támadó forgalom is azon a porton zajlik, amit ő enged a szabályok alapján és nem lát be. Egy alkalmazás-proxy tűzfal már képes lehet ilyen támadások elhárítására, amennyiben a támadó kód úgy van megszerkesztve, hogy ütközik az adott forgalomtípus szabványával. A tűzfalakra egyéb funkciókat is rá szoktak ültetni, ilyen például a víruskeresés, spam szűrés, tartalomszűrés az áthaladó forgalomban. Komoly infrastruktúra esetében azonban ezeket a funkciókat célszerű elosztott rendszereken elvégezni, a tűzfalnak pedig azt a feladatot adni, amire való. A tapasztalatok alapján ugyanis egy dedikált spamszűrő, vagy webszűrő eszköz szélesebb spektrumon konfigurálható, mint egy tűzfalba illesztett, hasonló funkciókat ellátó modul. Egy hasonlattal éve, James Bond kocsiján kívül nincs olyan autó, amelyik egyszerre gyors, jól bírja a terepet, úszik és repülni is tud. Továbbá, a legtöbb esetben a VPN kapcsolatok is a tűzfalakon végződnek. Ez, amennyiben a tűzfal méretezése megengedi, hasznos megoldás, mivel egybevág a tűzfal alapfeladatával, és így a titkosított csatornából előbújó forgalmat a tűzfal képes elemezni, naplózni és szűrni. A tűzfalak és hálózatok fejlődése során részben a szerepük is átértékelődött. Ma már nem lehet egyértelműen meghatározni egy hálózat határát, mivel számtalan eszközzel képesek vagyunk rá csatlakozni, szinte bárhonnan. Csak néhány példát említve: okostelefonok, wifi, bluetooth eszközök, VPN-ek. Ezért, bizonyos szempontból a hálózat határai is dinamikusan változónak tekinthetők. Ha védeni szeretnénk a hálózatunk egyes területeit egymástól, és tudni szeretnénk, hogy mi is történik a hálózatunkon, érdemes azt minél több szegmensre (zónára) bontani, és a zónák közötti forgalmat pontosan definiálni, elemezhetővé tenni. Egy nagyteljesítményű alkalmazás-proxy tűzfal ezt a feladatot képes ellátni, így a tűzfal határvédelmi területről sok esetben a hálózat központi elemévé kezd válni, éppen úgy, mint a közlekedési rendőr egy forgalmas kereszteződésben. IT biztonságról közérthetően Oldal 64 Informatikai biztonsági koncepció Ártó kódok elleni védelem Vírusok, férgek, trójaiak napi rendszerességgel képesek megkeseríteni a felhasználók és üzemeltetők életét, ha mással nem, hát azzal, hogy az ellenük való védekezés jelentős erőforrásokat igényel. Honnan is származnak a vírusok8? Neumann János 1948-ban publikálta önreprodukáló automatákról szóló elméletét. Ő ugyan nem számítógép vírusokra gondolt, de egy vírus meglehetősen hasonló módon többszörözi meg saját magát. 1972-ből az első vírusnak nevezhető kód a nagygépes környezetbe írt egyik játék, az ANIMAL volt. Érdekessége, hogy az adatcsere még lyukszalagokkal történt, a vírus mégis elég sok gépen megjelent. Az első mikroszámítógépekre írt vírus 1982-ben az Apple-II gépre készült és minden ötvenedik újraindításkor egy kis verset írt a képernyőre. A 90-es években a vírusokat viccből, vagy rosszindulatból írták. Ugyan képesek voltak komoly károkat, adatvesztést okozni, de terjedésük lassú volt, mivel csak lemezeken, CD-ken kerülhettek továbbításra. Körülbelül az ezredforduló óta a fertőzések terjedése az internetes kommunikáció elterjedésével hihetetlen mértékben felgyorsult, ezzel együtt a számuk is jelentősen megnövekedett és növekszik ma is. A különböző ismert ártó kódok száma több milliós nagyságrendűre rúg, és ez exponenciálisan növekszik évről évre. Ráadásul, ami a legfontosabb, az ártó kódok készítése hobbiból üzletté vált. Ma szinte kizárólag csak olyan alkalmazások fertőzik meg a gépeket, melyek valakik számára vélt, vagy valós haszonnal kecsegtetnek. A vírusírás komoly üzleti tevékenységgé vált, mely köré szervezett bűnözői csoportok épültek. Ebből kifolyólag a mai ártó kódok jóval veszélyesebbek, mivel kizárólag csak az alábbi célokért készítették el őket: 1. Adataink megszerzése 2. Más nevében illegális tevékenység végzése 3. Kéretlen üzleti ajánlatok küldése Főbb típusok A védekezés formáinak tárgyalása előtt ismerjük meg őket közelebbről: Vírus: Klasszikus definíció szerint a vírus olyan program, amely más programokat fertőz oly módon, hogy azok kódját saját maga vagy önmaga fejlettebb változatának beépítésével módosítja. A vírusok tehát egyes befogadó fájlokat (pl.: exe) fertőznek, 8 Szőr Péter: A vírusvédelem művészete; SZAK Kiadó Kft. 2010 (Szőr, 2010) IT biztonságról közérthetően Oldal 65 Informatikai biztonsági koncepció illetve ezek hivatkozásainak módosításával átveszik a vezérlést, és reprodukálással új vírusgenerációkat hoznak létre. Féreg (worm): A férgek olyan vírusok, melyek elsősorban hálózati környezetben reprodukálódnak. Rendszerint, de nem minden esetben önálló programok, melyeknek nincs szüksége gazdaprogramra. Trójai program: A trójai programok olyan, önmagukat gyakran álcázó, másolódásra nem képes független programok, melyek feladata, hogy a célzott gépen valamilyen nem kívánt feladatot hajtsanak végre. Ilyen tipikus feladatok az alábbiak:    hátsó hozzáférést nyissanak (ezeket backdoor programoknak is nevezik), programokat indítanak, kommunikálnak, adatokat küldenek, fogadnak. A fent felsoroltakon kívül még számos verziója létezik az ártó kódoknak, mint például jelszólopók, logikai bombák, letöltő programok, rootkitek, stb.) Külön kell említést tenni a viccprogramokról (joke), a hoax-okról, melyek tipikus példái a lánclevelek, különböző hirdető- és kémprogramokról, melyek általában a felhasználói szokásainkat fürkészik. Ezek általában nem tekinthetők kifejezetten károkozó programnak, közvetve azonban információkat juttatnak ki rólunk. Erre a tipikus példa a lánclevél, mely egy álhírt továbbítva akár több száz valós email címet is tartalmazhat, a kéretlen levelek küldőinek legnagyobb örömére. Valójában ma már ezek a típusok meglehetősen ritkán jelentkeznek vegytiszta formájukban külön-külön. Mivel jelenleg a trójai programok, férgek és rootkit-ek a leggyakoribbak, a vírus elnevezés is idejétmúlt lett a konkrét definíció alapján. Mivel a mai ártó kódok általában több komponenst is tartalmaznak, ráadásul legtöbbször megnyitják a kaput más kódok előtt, ezért célszerűbb az összetett fenyegetés nevet használni. Ettől függetlenül a köznyelvben a vírus és vírusvédelem kifejezés továbbra is él, ebben a dokumentumban is történik ilyen megnevezése, de tudni kell róla, hogy ma általában egy jóval komplexebb támadási forma régi időkből megmaradt összefoglaló neveként értelmezzük. Fertőzési módszerek A vírusok fertőzési módja és leginkább a sebessége a technológia fejlődésével köthető párhuzamba. A nagyméretű hálózatok térhódítása előtt a terjedés csak lassan zajlott. Az internet elterjedésével azonban korábban elképzelhetetlen mértékben nőtt a vírusok terjedési sebessége. Az első ilyen vírus, mely gyorsan több millió gépet tudott megfertőzni, a Melissa nevű email vírus volt, melyet 1999-ben detektáltak. A vírus emailben terjedt, és felhasználói interakciót igényelt, vagyis a kapott email csatolt állományát tudatosan meg kellett nyitni, hogy aktiválódni tudjon a gépen. Később több hasonló sikereket elért email vírus is követte, gyakorlatilag hasonló forgatókönyvvel. Az email vírusok nagy sikerének az volt az oka, hogy emailt küldeni elvileg bárki, bárkinek a nevében képes. A fertőzött gépek a IT biztonságról közérthetően Oldal 66 Informatikai biztonsági koncepció további fertőzések küldésére a gépen található címlistát használták véletlenszerű módon. Így az ártó kód jó eséllyel olyan feladótól érkezett, akit az áldozat ismert és rendszeresen leveleztek is. Az email vírusok mellett megjelentek a hálózaton terjedő, operációs rendszerek, illetve publikus alkalmazások sebezhetőségeit kihasználó ártó kódok. Az internetre, illetve ha sikerült bejutnia, akkor zárt hálózatokra csatlakozó gépek, publikusan elérhető szolgáltatásait keresi és használja ki az így megírt kód. Tipikus példájuk a Slammer worm, amely a Microsoft SQL adatbázis kiszolgálójának egy sérülékenységét használta ki. (Meg kell jegyeznem, hogy én először nem hittem abban, hogy ez a vírus ekkora sikert ér el. Úgy gondoltam, senki nem olyan óvatlan, hogy egy működő adatbázisszervert védelem nélkül kidugjon az internetre. Keservesen csalódtam.) A biztosabb siker elérése érdekében az ártó kódok akár több módon is képesek fertőzni. Erre a legjobb példa a Conficker vírus, amely emailben, hálózati sebezhetőséget kihasználva, jelszópróbálgatással, illetve pendrive-on egyaránt képes volt terjedni. Ma a leginkább elterjedt támadási forma a fertőzött weboldalak alkalmazása. Ilyenkor a felhasználókat valamilyen módon rá kell venni, hogy eljussanak az oldalra, illetve népszerű oldalakat kell megfertőzni. A csali még mindig gyakran emailben érkezik, illetve a különböző közösségi oldalakon terjedő alkalmazások, illetve megosztások juttatják el az áldozatot a kívánt oldalra, ahonnan az áldozat az oldal megnyitásával letölti és aktiválja a saját gépén az ártó kódot. Évek óta várja a szakma az okostelefonokat támadó, világméretű vírustámadást, ez azonban egyelőre még várat magára, noha egyre szaporodnak a telefonokra írt ártó kódok. Ha egy gépet fertőzés ér, és a kód képes lefutni, általában megkezdi a terjedését, illetve visszajelentkezik egy központi kiszolgálóra, ahonnan újabb ártó kódokat tölt le, illetve frissíti a feladatát. Furcsán hangzik, de az ártó kódok ma éppen úgy működnek, mint a nagyvállalati vírusirtó rendszerek. A fertőzött számítógépek nagy többsége távolról menedzselhető gépek hálózatát alkotja, melyeket zombi-hálózatnak neveznek. Ezek a hálózatok néha milliónyi gépből állnak, és komoly kereskedelmi értékük van az informatikai sötét oldalán. Egy zombi hálózat tipikus felhasználási módjai az alábbiak: 1. Adatok, személyes információk szerzése a fertőzött gépről. Ez tipikusan bankszámla információkat jelent, de az eszközök lehetőséget biztosítanak célzott információkeresésre és továbbításra is, attól függően, hogy mi a célja vagy megbízása a zombi hálózat irányítóinak. 2. Kéretlen levelek küldése állandóan frissülő email cím adatbázisok alapján. 3. Interneten keresztüli támadások a zombi hadsereg felhasználásával bizonyos szerverek ellen. Ezek a támadások tipikusan DoS (Denial of Service) támadások, melynek lényege, hogy egyszerre, nagytömegű kérések özönét küldik egy kiszolgálónak, amely képtelen ezekre mind válaszolni és elérhetetlenné válik. Jelenleg IT biztonságról közérthetően Oldal 67 Informatikai biztonsági koncepció az Anonymous hacker csoport ilyen támadásokat hajt végre világszerte céljaik elérése és figyelemfelhívás érdekében. 4. További potenciálisan megfertőzhető gépek felderítése és fertőzése. 5. Vásárlásra buzdítás (zsarolás), nehezen eltávolítható programok állandó futtatásával. A védekezés formái Az ártó kódok elleni védekezésről elsőre mindenkinek a különböző vírusirtó szoftverek jutnak eszébe. Ezt megelőzően azonban itt is fontos kiemelnünk az operációs rendszerek védelmének két legfontosabb ismérvét, a javítócsomagok rendszeres telepítését, illetve a jogosultságok, felesleges szolgáltatások korlátozását. A védelem fontos részét képezi a felhasználók oktatása. Ahogy láttuk, nagyon sok esetben a vírusok terjesztői megtévesztésre játszanak, és sajnos sokszor járnak sikerrel, ezért az oktatás kiemelt jelentőséggel bír. A célszemélyek megtévesztése az informatikai támadások leghatékonyabb formája (social engineering) a sikeres célzott rendszerfeltörések legnagyobb részben így indulnak, a kódok bejuttatása, jogosultságok szerzése mind csak ez után történik meg. Ebből is látszik, hogy biztonsági rendszereink leggyengébb pontja még mindig maga az ember. Ahogy belénk kell, hogy rögzüljön, hogy körülnézünk, mielőtt lelépünk a járdáról, éppen olyan óvatosan kell kezelni az ismeretlen, gyanús emaileket, linkeket, weboldalakat. Ezek azonban csak a védelem alapját biztosítják. Az ártó kódok elleni védekezés ma nem képzelhető el vírusvédelmi szoftver nélkül. A vírusirtó szoftverek A vírusirtók működésük során alapvetően mintaillesztéses keresési módszerrel vizsgálják a számítógépeken található állományokat, és kísérlik meg a fertőzött állományok tisztítását, az ártó kódok törlését, karanténba helyezését. A mintákat a gyártók rendszeresen frissítik, általában naponta, de bizonyos esetekben akár óránként is jelenhetnek meg újabb minták, ezért a helyi vírusadatbázisok rendszeres és automatikus frissítése nagyon fontos. Az egyes gépekre telepített vírusirtók alapvetően két módon képesek működni: 1. Online keresés, melynek során a vírusirtó folyamatosan figyeli a rendszer írási/olvasási műveleteit, és végrehajtás előtt a kérdéses állomány, memóriaterület tisztaságát ellenőrzi. 2. Offline keresés, melynek során sorban az összes állományt átvizsgálja, elfekvő, nem aktív ártó kódok után kutatva. A kétféle működés együtt képes kifejteni megbízható védelmet, vagyis a folyamatos, online védelem mellett rendszeres időnkénti offline ellenőrzést is javasolt elvégezni. A mintaillesztésen túl a vírusirtók vizsgálják a programok egyedi viselkedését, memória és hálózathasználatát, hasonlóságát más ártó kódokhoz és sok egyéb paramétert. Ezek alapján az információk alapján képesek megbecsülni, hogy egy új kód valóban ártalmas-e. Ha a gyanús kód az összesített vizsgálaton túllép egy bizonyos pontot, vírusnak minősül. Ezt a fajta keresési elvet heurisztikus keresésnek nevezik. IT biztonságról közérthetően Oldal 68 Informatikai biztonsági koncepció A fenti keresési eljárások azonban általában csak ismert, vagy a már ismerthez hasonló kódok ellen nyújtanak védelmet. Az újabb és újabb ártó kódok jelenlegi mértékű megjelenése miatt azonban felmerült az igény olyan védekezési formákra, melyek ismeretlen kódok ellen is képesek hatékony védelmet nyújtani. Ezeket összefoglaló néven Zero Day protection-nek nevezzük. Tipikus formái az alábbiak:  A vírusirtó a vírusok behatolási pontjait és rendszeren belüli terjedési eljárásait elemzi, és egyedi szabálybázissal blokkolja ezeket a területeket. A megoldás egyaránt hasznos megelőzésre, és új, ismeretlen vírus terjedésének megakadályozására, átgondolatlan használata azonban üzemeltetési oldalról problémákhoz vezethet. Memória túlcsordulás elleni védelem alkalmazása. A memória túlcsordulás a legtipikusabb támadási forma. Azt a fajta fejlesztői hibát használja ki, melynek során a programozó nem gondoskodott egy eljárás pontos memória használatáról, ezzel lehetőséget biztosít olyan kód futtatására, mely máshová, akár végrehajtható területre is írhat a memóriában. Bizonyos szoftverek képesek az ilyen folyamatokat előzetesen tesztelni, és ha fenn áll a túlcsordulás veszélye, nem engedik futni a kódot. A gyanús kódot azonosításra kiküldi egy központi elemző kiszolgálóra, mely kiterjesztett heurisztikával, illetve a legfrissebb adatbázismintákkal elemzi a kapott kódot.   Nagyméretű hálózatok (pl.: nagyvállalatok) figyelembevételével érdemes megtervezni: Központi menedzsment vírusvédelmét az alábbi alapelvek Egy nagykiterjedésű vírusvédelmi rendszert nem lehet egyesével telepíteni és a szabályokat módosítani, nem is beszélve a frissítések kezeléséről. Ezért szükséges egy olyan központi kiszolgálót használni, amely képes az alábbi, vírusirtó programokhoz kapcsolódó feladatok megbízható és automatizált elvégzésére:        Telepítés Konfigurálás Frissítések központosított, automatizált terítése Riasztások kezelése Ismeretlen gépek felismerése és kezelése Riportolás Eltávolítás IT biztonságról közérthetően Oldal 69 Informatikai biztonsági koncepció Rendszerszemlélet Mivel a vírusvédelem gyakorlatilag minden gépen megtalálható, és minden adatmozgást ellenőriz, ezért nagyon fontos, hogy a működése megfelelően legyen szabályozva. Ennek kialakítása komplex rendszerszemléleti gondolkodásmódot igényel, különben az informatikai szolgáltatások sérüléséhez vezethet. Fontos, hogy a vírusvédelmi rendszer működése során ne okozzon fennakadást a normál informatikai folyamatok ellátásában, de minden olyan esetben hatékonyan közbelépjen, mikor a rendszer üzemszerű működését ártó kódok megjelenése veszélyeztetné. Több olyan, általában szerveralkalmazás is van, melyek kezelése speciális beállításokat igényel a vírusirtókon, ellenkező esetben az alkalmazás bármely pillanatban megállhat, és az adatai sérülhetnek. Ez tipikus hiba lehet egy vírusvédelmi rendszer telepítésekor, ha erre nem készülünk fel, és nem a gyártók ajánlásai alapján állítjuk be a védelmi szintet. Naprakészség Az egyes vírusok elterjedését, nagymértékben befolyásolja az, hogy a kiadott ellenszérum, milyen gyorsan kerül terítésre a teljes belső hálózaton, illetve a kiemelt jelentőségű ellenőrzési pontokon. Egy működő vírusvédelmi rendszer felkészültségének meghatározására talán ez az egyik legfontosabb mérőszám. Ezért mindenképpen javasolt a vírusvédelmi alkalmazások legalább 3-4 óránkénti (de esetenként akár óránkénti) automatikus frissítése. A frissítések terítése során fontos szempont a hierarchikus kialakítás, és a túlterhelés ellen figyelemmel kell lenni a rendelkezésre álló sávszélességre. Többszintű védelem A többszintű védelem azt jelenti, hogy az informatikai folyamatokba történő bekapcsolódás során általában nem elég csak egyszer megvalósítani a kódok ellenőrzését, mivel, amennyiben ott bármely okból sérülne a védelem, az elszabadult vírusok megfékezésére több ellenőrzési pont már nem áll rendelkezésünkre. Ezért, a magas biztonsági szint megvalósításához, minden esetben többszintű védelem kialakítását preferáljuk. Így az egymásra épülő folyamatok minden ponton ellenőrzés alá kerülnek, ami a folyamatvezérlési, beavatkozási lehetőségek kitágításához és egy un. „három dimenziós” védelmi struktúra kialakításához vezet. Egy érkező levél ellenőrzése során ez tipikusan azt jelenti, hogy érdemes egy email gateway-en, és/vagy a levelező kiszolgálón, illetve a klienseken egyaránt ellenőrizni a levél tisztaságát. Tartalomszűrési eljárások A tartalomszűrésnek két fő feladata van: 1. Meghatározni azokat a tartalmakat, melyek engedélyezetten elérhetők, illetve tiltottak a vállalat hálózatából. IT biztonságról közérthetően Oldal 70 Informatikai biztonsági koncepció 2. Meghatározni azokat a tartalmakat, melyek engedélyezetten kiküldhetők a vállalat hálózatából. Tartalomszűréssel az email és az internet böngészés területét szokás ellenőrizni. Tipikus megoldás a hálózat peremén elhelyezett gateway alkalmazások kialakítása, melyeken keresztül vezetik a ki- és bejövő forgalmat (email, web, ftp), és amelyek előre definiált szabályrendszer alapján vizsgálják, naplózzák, engedélyezik vagy tiltják az adott tartalmat. Legfontosabb területei az alábbi fejezetekben kerülnek részletezésre. Kéretlen levelek szűrése A kéretlen levél, közismert nevén spam valójában az angol Monty Pyton humorista csoport egyik előadásából kapta a nevét, melyben egy kereskedő minden vevőjére spam nevű húskonzervet próbált rásózni. Egy 2009-es felmérés megállapította, hogy a kéretlen levelek az internet teljes levelezési forgalmának több mint 90% százalékát teszik ki. Ez az irtózatos mennyiségű levél komoly gondot okoz a felhasználóknak és a vállalati rendszergazdáknak egyaránt. A levelek változatos céllal érkeznek, vannak vásárlásra buzdító, információt kicsaló, vírusos weboldalra invitáló levelek egyaránt közöttük. A feladat, hogy egyrészt megbízhatóan el kell választani őket a valóban hasznos levelektől, másrészt meg kell oldani, hogy a levelező kiszolgálót ne terhelje túl ez az áradat, harmadrészt gondoskodni kell azokról az esetekről, mikor egy valódi levél tévedésből spam minősítést kap (false pozitive). Egy levél elolvasása és kiértékelése erőforrás igényes folyamat, ezért hasznosabb lenne, ha már a fogadáskor, olvasás nélkül tudnánk minősíteni. A levelezési rendszer és a levelezés szabályainak megerősítése, előzetes feladó-ellenőrzések beépítése pontosan ezt szolgálja. Bevezetésükkel a kéretlen levelek jelentős hányadától tudunk úgy megszabadulni, hogy nincs szükség valódi tartalomellenőrzés elvégzésére. A megmaradt mennyiség általában még mindig többszöröse a cég valós levelezési forgalmának. Ennek kezelése általában spamszűrő alkalmazást igényel. A spamszűrők tipikusan a vírusirtóhoz hasonlóan működő, rendszeresen frissülő adatbázissal rendelkező alkalmazások. A beérkező leveleket több szempont szerint elemzik és pontozzák. Bizonyos, egyénileg állítható ponthatár felett a levél spam-nek minősül, alatta normál levélként továbbításra kerül. A korszerű spamszűrők 96-99%-os hatékonysággal képesek működni. A megmaradt leveleket egyedi feketelisták létrehozásával lehet kiszűrni. A false pozitive találatok kezelésére a spam-eket javasolt egy ideig karanténban tárolni. Ha a levél valóban fontos volt, ekkor egy ideig még kikérhető a karanténból, csak később kerül végleges törlésre. URL szűrés Sok felhasználó szerint a vállalati irodai munka egyik legfájóbb pontja az internet elérés korlátozása. A felhasználók a legtöbb helyen csak korlátozott, a munkájukhoz szükséges tartalmakat érhetnek el, ráadásul az is naplózásra kerül. Ennek a munkaidő „hasznos” kitöltésére való törekvésén túl más praktikus oka is van, a sávszélesség kímélése. Megtörtént IT biztonságról közérthetően Oldal 71 Informatikai biztonsági koncepció eset, hogy egy nagyvállalat képtelen volt beleférni a meglévő internet sávszélességbe. A bővítési igény már a vezetőség előtt volt, aláírásra várva, mikor próbaképpen letiltották a YouTube videómegosztó elérhetőségét. A szűknek érzett sávszélesség forgalma a tizedére esett vissza. A bővítést elnapolták, évi több millió forintot takarítva meg ezzel. A különböző URL filter megoldások általában a gyártó által publikált, rendszeresen frissülő adatbázisból dolgoznak, ahol az egyes weboldalak különböző, téma szerinti kategóriákba kerülnek besorolásra. A hozzáférési listák általában felhasználói csoportok alapján kerülnek összerendelésre. Természetesen lehetőség van egyedi módosítások bevezetésére, saját listák generálására. A tiltott oldalak blokkolásra kerülnek, a beállítások gyakran csak munkaidőre lépnek érvénybe. A felhasználói tevékenység naplózásra kerül, melynek során a meglátogatott oldal, illetve a letöltött adatmennyiség is tárolásra kerül. Adatszivárgás elleni védelem Az elmúlt években váltak sláger témává az adatszivárgást megelőző rendszerek (DLP: Data Loss Prevention). Az igény, ami életre hívta őket, az volt, hogy az évek óta alkalmazott klasszikus jogosultsági rendszer nem nyújt elégséges védelmet a céges adatok kiszivárogtatása ellen. Ez nem azt jelenti, hogy a jogosultsági rendszer elhibázott és könnyen megkerülhető volna. Ahogy korábban már szó volt róla, az adatlopások legnagyobb része a szervezeten belül történik, és általában olyan munkatárs végzi, aki napi szinten hozzáfér az érzékeny adatokhoz, dolgozik velük, így alkalom adtán könnyedén kimásolhatja egy adathordozóra vagy feltöltheti egy weboldalra, esetleg webmailen küldheti el. Ennek megakadályozására született meg az a technológia, melyet összefoglaló néven adatszivárgás elleni védelemnek neveznek. A megoldás lényege, hogy egyrészt lezárják és ellenőrzötté teszik az összes olyan kivezető utat, melyen keresztül a cégből adat távozhat az email csatolmánytól kezdve, a CD íráson keresztül, a nyomtatásig. Másrészt nyomon követik és naplózzák az érzékeny dokumentumok életútját, verzióit, akár a belőlük kimásolt és más formátumba áttöltött részeket is. Ehhez szükség van a cég adatvagyonának a felmérésére és kategorizálására, hiszen meg kell tudni mondani a DLP rendszerben, hogy az adott adattípusra milyen szabályok érvényesek. Ez a DLP rendszer legnehezebb része. Amennyiben az adatvagyonleltár hiányos, úgy a kialakításra kerülő rendszer sem fogja megfelelően ellátni a funkcióit. Az adatszivárgást megelőző szoftvereknek alapvetően két típusát különböztetjük meg: 1. kliens oldali adatvédelem 2. hálózati adatvédelem A kliens oldali DLP megoldásoknak egyrészt teljes körű eszköztámogatással kell rendelkezniük, vagyis pontosan meg kell tudni határozni, hogy egy klienshez csatlakoztatott eszközre (Pl.: telefon, kamera, pendrive, SD kártya, bármi, ami adattárolásra szolgálhat) IT biztonságról közérthetően Oldal 72 Informatikai biztonsági koncepció milyen írási/olvasási szabályok érvényesek, és az aktuálisan bejelentkezett felhasználó mit tehet ezekkel az eszközökkel. Másrészt az adatvagyon eredményei alapján érvényre kell tudni juttatni a kialakított biztonsági szabályokat. Ennek során az ismert és még ismeretlen eszközöket, a különböző felhasználói csoportokat, valamint az eltérő adatkategóriákat rendeljük össze egy szabályrendszerbe. A cél az, hogy érzékeny adat csak engedélyezett útvonalon, engedélyezett felhasználói tevékenység okán, és csak úgy juthasson ki a rendszerből, hogy arról pontos naplóbejegyzés, esetleg bizonyítékként másolat keletkezzék. A hálózati DLP eszközök hasonló funkciókat látnak el. Ezeket általában web és email tartalomszűrő eszközökhöz szokás csatolni. Feladatuk megegyezik a kliens oldali DLP komponensekével. A DLP megoldások képesek adat és információ mintákat keresni a különböző továbbítandó állományokban, mint például bankszámlaszámok, személyi igazolvány számok. Ezekkel az előre definiált mintákkal jelentősen lehet egyszerűsíteni a szabályok kialakítását. Naplókezelés, naplóelemzés Már többször szó esett az események naplózásának fontosságáról. Naplózás a 80-as évek óta létezik informatikai környezetben. Kezdetben kizárólag diagnosztikai szempontból vezették be, a biztonsági szempontok csak később jelentek meg. Ezzel el is jutottunk a naplózás két legfontosabb okához, nevezetesen a hibakeresés és az adatvédelmi, biztonsági események kezeléséhez. Igen valószínű, hogy nincs is olyan üzemeltető vagy fejlesztő, aki nem próbált volna még valamilyen hibakódról részletesebb információt keresni egy probléma behatárolásához vagy elhárításához. Kezdő informatikusok rendszeresen szoktak megsemmisülten elkullogni tapasztalt társaik szeme elől, mikor egy általuk felvetett problémára az rögtön visszakérdez: Megnézted mi van a naplóban? Ahogy az informatikai biztonság egyre hangsúlyosabb szerepet kezdett játszani a mindennapi életünkben, úgy nőtt az események tárolásának, visszakövethetőségének igénye. Ráadásul, új szempontként, megjelent a felhasználói és üzemeltetői tevékenységek naplóztatása, mely ma az egyik legfontosabb terület, az előző fejezetben tárgyalt adatszivárgást megelőző rendszerek is ebből nőtték ki magukat. A rendszerek helyi naplózása azonban több szempontból sem volt képes kielégíteni a felmerült igényeket. Egyrészt egy komoly meghibásodás képes tönkretenni a naplófájlokat is, így jóval nehezebb a probléma utólagos rekonstruálása. Másrészt az üzemeltetők is gyarló emberek, akik abban különböznek a felhasználóktól, hogy van joguk és lehetőségük ezeknek a naplóknak a törlésére és megváltoztatására, miután valami rosszaságot tettek. Előbb utóbb az informatikában is fel kellett tenni a kérdést: Quis custodiet ipsos custodes? – vagyis ki őrzi az őrzőket? IT biztonságról közérthetően Oldal 73 Informatikai biztonsági koncepció A választ a központi naplórendszerek adták meg. Ezek feladata, hogy a különböző rendszerekben keletkezett naplóeseményeket egy elszeparált környezetben, rendezetten tárolják, így biztosítva az egyes események visszakereshetőségét. A központi naplórendszerek üzemeltetése tipikusan a biztonsági szabályzatokból megismert Biztonsági Felügyelő feladata kell, legyen, az üzemeltetők csak olvasási joggal férhetnek hozzá. Ezzel biztosítható az üzemeltetői tevékenység kontrollja. A központi naplózó rendszerek meglétét és működésüknek sarokpontjait ma számos szabvány előírja, bevezetésük több területen is (Pl.: pénzügyi rendszerek) kötelező érvényű. A megvalósítás számos nehézséget rejt magában, hiszen heterogén rendszerektől kell azonos formátumú üzeneteket begyűjteni, és biztosítani kell a naplóesemények sértetlenségét és bizalmasságát is. A naplózó rendszerek kialakításának főbb szempontjai az alábbiak: 1. Nagyon pontosan meg kell határozni, hogy mi az az információ, amelyet gyűjteni szeretnénk. Sajnos sem a túl kevés, sem a túl sok adat nem hoz elvárható eredményt. Az előbbi könnyen érthető, de a túl sok esemény naplózása is komoly problémákhoz vezethet, többek között a vizsgált rendszerek performanciája területén, ugyanis sokszor minden erőforrásukat az köti le, hogy a keletkezett óriási naplómennyiséget elküldjék, illetve a feldolgozó rendszerek oldaláról a válaszidők, a kereshetőség, az adattárolás költsége mind problémaként jelentkezik. Az egyes szabványokban megfogalmazottak segítséget tudnak nyújtani a naplózás mélységének meghatározásában. Pl.: PCI DSS szabvány kimondja, hogy az összes rendszerkomponens minden eseményéről rögzíteni kell, legalább a felhasználó azonosságára, az esemény típusára, bekövetkezési dátumára és idejére, illetve az esemény eredetére, nevére, sikerességére vagy elutasítására vonatkozó adatokat. 2. Biztosítva kell, legyen az adatok megbízható továbbítása, kezelése, tárolása és visszakereshetősége. Ha lehetőség van a naplózás folyamatába harmadik félnek belenyúlni, és a naplózásra küldött információkat megváltoztatni, az a teljes rendszer hitelességét veszélyezteti. További szempont az esemény keletkezési idejének hiteles és meg nem változtatható módon történő rögzítése. 3. A naplózó rendszernek megfelelő rendelkezésre állással kell rendelkeznie. A kritikus adatok gyűjtése nem állhat meg és nem veszélyeztetheti sem azt az infrastruktúrát, amelyet éppen naplózunk, sem pedig a hálózat rendelkezésre állását amelyen a naplóadatok áthaladnak. 4. Amennyiben a központi naplózó rendszerben nemcsak tároljuk a keletkezett eseményeket, hanem valamilyen logika alapján fel is dolgozzuk, esetleg a független rendszerek eseményeit korrelációban vizsgáljuk, e folyamat során pontosan határozzuk meg, hogy milyen információkat szeretnénk szűrni, milyen riasztásokra van igény. Ellenkező esetben vagy túl sok riasztást kapunk vagy a lényeges eseményekről sem kapunk információt. IT biztonságról közérthetően Oldal 74 Informatikai biztonsági koncepció Betörés detektálás Ha kialakítottunk és rendszeresen karbantartunk egy biztonsági rendszert az előzőekben tárgyalt szempontok és technológiák alapján, felmerül a kérdés, hogy milyen módon lehet közvetlenül tudomást szerezni a támadásokról, lehetőleg még anélkül, hogy azok elérnék a kritikus rendszereinket. Ez az igény különösen a publikus szolgáltatások esetében merül fel, hiszen egy web szerver sok esetben nyújt csábító célpontot a támadóknak, nekünk viszont az a feladatunk, hogy a támadó adatcsomagok lehetőleg el se jussanak a céljukig. Erre a problémára nyújtanak megoldást a betörés detektáló rendszerek (IPS: Intrusion Detection System). Működésük egyaránt hasonlítható a vírusirtó és az alkalmazás-proxy tűzfal működésére. Megkülönböztetünk hálózati és host alapú IPS rendszereket. Host IPS A host alapú rendszereket a védendő gépekre telepítjük, így egy vírusirtóhoz hasonló módon működnek. Feladatuk egyrészt egy rendszeresen frissülő adatbázis alapján a különböző hálózati és lokális támadási minták elemzése, felismerése és blokkolása, mielőtt az adott támadás ki tudná fejteni a hatását. Másrészt alkalmasak a Zero Day Protection esetében tárgyalt betörési kísérletek (túlcsordulásos típusú támadás) felismerésére és semlegesítésére. Fontos megjegyezni, hogy a host IPS rendszerek szigorú szabályai képesek normál üzleti alkalmazásokat is leállítani, amennyiben azok nem felelnek meg a biztonsági követelményeknek, esetleg nem rendelkeznek megfelelő javító csomagokkal. Megtörtént eset, hogy egy klienseket védő host IPS bevezetés után a felhasználók egy ideig egyetlen pdf állományt sem voltak képesek megnyitni, mivel az Adobe Reader program nem rendelkezett a szükséges javító csomagokkal. A szoftver ezt biztonsági hiányosságként érzékelte, és blokkolta a futását. Ezért bevezetésük és működési módjuk (blokkol, riaszt, naplóz) minden esetben előzetes tervezést és részletes tesztelést igényel, nemcsak az aktuális állapot tekintetében, hanem az üzemeltetés kérdéseiben is. Network IPS A hálózati betörés detektálók tipikusan célhardverek, melyeket a kritikus hálózati zónákba illesztünk, hogy elemezzék az áthaladó hálózati forgalmat. Bizonyos esetekben tűzfal modulként is alkalmazhatók, ez mindig az aktuális rendszer méretének és biztonsági igényének a függvénye. Működésük alapvetően kétféle lehet: A kérdéses forgalmat kitükrözzük a Network IPS számára egy hálózati aktív eszköz szabad portján. Ebben az esetben az éles forgalom másolatát vizsgálják. Tipikusan csak naplózásra, illetve riasztások generálására használatos ez a mód, bár itt is van lehetőség az automatizált közbeavatkozásra. Ekkor az eszközt egy másik interfészen visszakötjük a vizsgált hálózatba, és ha valamilyen káros forgalmat lát, ő válaszol a célgép helyett, és lezárja a kapcsolatot IT biztonságról közérthetően Oldal 75 Informatikai biztonsági koncepció (reset csomagokat küld). A megoldás hátránya, hogy legalább az első támadó csomag mindenképpen eljut a célgépre. Továbbá a hálózati eszközöket is át kell konfigurálni a forgalom tükrözés kialakításához. In-line bekötés esetén a vizsgált forgalom keresztülhalad az IPS eszközön, és tiltott adatcsomagok esetén az eszköz egyszerűen nem továbbítja a csomagot. Ennek a megoldásnak előnye, hogy nagy biztonsággal képes megállítani a támadásokat. Hátránya, hogy gondoskodni kell az IPS nagy rendelkezésre állásáról, mivel meghibásodása a teljes zóna forgalmát leállíthatja. Másik fontos szempont, hogy ha az IPS alul van méretezve, az szintén a hálózati forgalom lassulásához, megakadásához vezethet, különösen gigabites, nagy sávszélességű szegmensek esetében. A két működési módot tipikusan kombinálva szokták alkalmazni. A bevezetés során hosszú ideig hallgatózó módban működik az eszköz, majd in-line módba kerül riasztó üzemmódba. A változatos hálózati forgalmak pontosabb értelmezése érdekében az eszközök élesítése előtt mindig javasolt egy úgynevezett tanuló üzemmód alkalmazása, mikor a helyi jellegzetes forgalmak megismertetésre kerülnek a fals riasztások kizárása érdekében. A bevezetés során elsősorban a tanulás, illetve a performancia tesztelése a legfontosabb szempontok. A blokkolás bekapcsolása az élesítés utolsó folyamata. Az IPS-re is elmondható, hogy öncélú bevezetése az alap infrastruktúra megerősítése és részletes előzetes tervezés nélkül nem növeli a biztonsági szintet. Ráadásul sok esetben a bevezetés csak félig történik meg, az IPS eszköz riasztás és blokkolás rendszere nem kerül kidolgozásra. Összefoglalás Mivel jelen tanulmány alapvetően nem informatikai szakembereknek íródott, igyekeztem „emberi nyelven” összefoglalni az informatikai biztonság felépítésének főbb területeit. Természetesen ilyen terjedelemben ez csak a teljesség igénye nélkül történhetett. Az információ biztonság tárgyalt területeinek legtöbbje mind külön szakmának tekinthető, olyan további mélységekkel, melynek megismerése külön-külön is teljes embert kívánó feladat lenne. Az információ védelme mindig is fontos volt az emberiség életében, de jelentősége ma sokkal inkább kihat a mindennapjainkra, mint korábban. A védelmi megoldások és technológiák eltérőek lehetnek, de minden esetben fontos, hogy az információ legfőbb biztonsági tulajdonságaira koncentráljanak: 1. bizalmasság 2. sértetlenség 3. rendelkezésre állás IT biztonságról közérthetően Oldal 76 Informatikai biztonsági koncepció A védelem megtervezésekor javasolt szabványos megoldásokban gondolkodni, de mindig figyelembe kell venni a helyi sajátosságokat, különben a védelmi eljárásaink vagy hatástalanok lesznek, vagy a rendszer normál működését károsítják, legrosszabb esetben mindkét verzió egyszerre is előfordulhat. Le kell számolni azzal a téveszmével, hogy az informatikai rendszerek statikus, egyszer felépített és magukra hagyható rendszerek. Ellenkezőleg, állandóan és dinamikusan változó környezeteknek kell őket tekinteni, az üzemeltetési modellnek is ezt kell tükröznie (életciklus modell). A tervezés során meg kell határoznunk a kockázatokat, majd a nagyléptékű, folyamat- és szabályzat orientált szempontok felől érdemes közelíteni a konkrét technológiai megvalósítás felé. A tervezés másik fontos szempontja a rendszerszemlélet. Ha egyes rendszereket függetlenül kezelünk, a problémákról és veszélyekről soha nem fogunk valós képet kapni. Minden esetben először a meglévő, védendő produktív rendszerünk alapjait kell biztonságossá tenni (jogosultságok kezelése, javítások telepítése, naplózás), erre építhetők fel hatékonyan a különböző biztonsági technológiák. Javasolt szempont, hogy soha ne gyártót, hanem technológiát válasszunk. Jelen tanulmányban ezért egyetlen biztonsági gyártó terméke sem jelent meg nevesítve. Természetesen a fenti szemlélet nemcsak újonnan összeállításra kerülő zöldmezős rendszerek esetében működik, a szempontok meglévő környezetekben is megvalósíthatók. IT biztonságról közérthetően Oldal 77 Informatikai biztonsági koncepció Hivatkozásjegyzék: DRP kép. (dátum nélk.). Forrás: www.e-janco.com HA topológia. (dátum nélk.). Forrás: http://en.wikipedia.org/wiki/High-availability_cluster ISO/IEC:27001:2006 Az információbiztonság irányítási rendszerei. (dátum nélk.). Kerberos sematikus ábra. (dátum nélk.). Forrás: http://mccltd.net Krasznay, C. (dátum nélk.). Kockázatkezelés. Forrás: www.krasznay.hu Mentési séma. (dátum nélk.). Forrás: www.flylib.com OSI rétegek. (dátum nélk.). Forrás: http://ccna5.com/ Szőr, P. (2010). A vírusvédelem művészete. SZAK Kiadó Kft. IT biztonságról közérthetően Oldal 78