Hornák Zoltán: Informatikai biztonság-menedzsment A biztonság és különösen az IT biztonság jó menedzselése más területekhez képest jelentısen eltérı szemléletet kíván. Itt a szervezés kevésbé a "hogyan mőködjön", sokkal inkább a "hogyan kerüljük el, hogy ne mőködjön rosszul" csavart alapgondolatot követi. Tekintve, hogy a nem kívánt események okai természetes, véletlenszerő tényezık, illetve rosszindulatú, intelligens, szakmailag felkészült személyek támadásai is lehetnek, rendkívül sok veszélyforrást kell figyelembe venni még a legegyszerőbb esetben is. Már szinte közhelynek számít, hogy az összes veszélyforrást kiküszöbölni a gyakorlatban nem lehet, vagyis tökéletes, 100%-os biztonság nincs. Hogyan teremtsünk hát olyan rendszert, olyan szervezetet, ahol a lehetıségekhez képest mégiscsak minimalizálni tudjuk a veszélyeket, kockázati tényezıket? Hogyan vegyük számba és védjük ki az IT rendszert fenyegetı veszélyforrásokat? Hogyan határozzunk meg olyan világos alapelveket, amelyeket követve egy informatikai rendszerben a biztonság menedzselhetı? Ezekre és hasonló kérdésekre próbál meg ez az írás választ adni.
1./53
Tartalomjegyzék
1.
Informatikai biztonság a szervezeti biztonság tükrében
4
2.
Biztonság-szervezés 2.1 Helyzetfelmérés 2.2 Veszélyforrás-feltárás 2.3 Kockázat-menedzselés 2.3.1 Kockázatelemzés 2.3.2 Védelmi intézkedések meghatározása 2.4 Biztonságpolitika 2.5 Informatikai Biztonsági Szabályzat 2.6 Katasztrófa-elhárítás menedzselése 2.6.1 Fogalmak meghatározása 2.6.2 Katasztrófa-elhárítási módszertanok 2.6.3 BIA – Business Impact Analysis 2.6.4 Mentési-visszaállítási stratégia 2.6.5 Katasztrófa-elhárítási terv 2.6.6 Tesztelés, oktatás, karbantartás 2.7 Biztonsági audit 2.8 Összefoglalás
6 6 7 7 9 13 13 15 16 16 18 19 20 20 21 22 23
3.
Biztonsági alapmódszerek 3.1 CIA követelmények 3.1.1 Bizalmasság 3.1.2 Sértetlenség 3.1.3 Rendelkezésre-állás 3.2 PreDeCo védelem 3.3 Zónarendszer 3.4 Biztonsági minısítések 3.5 Humán biztonság
23 23 24 26 26 27 29 29 31
4
IT Biztonsági technikák 4.1 Felhasználók azonosítása 4.1.1 Tudás, avagy jelszó alapú azonosítás 4.1.2 Birtok, avagy kulcs alapú azonosítás 4.1.3 Biometriai azonosítás 4.2 Logikai hozzáférés-védelem 4.2.1 Önkényes hozzáférés-védelem (DAC) 4.2.2 Kötelezı hozzáférés-védelem (MAC) 4.2.3 Naplózás (audit) 4.3 Biztonságos kommunikáció 4.3.1 Biztonságosan nyugtázott üzenetküldés 4.3.2 Sértetlen üzenet-továbbítás 4.3.3 Hiteles üzenet-továbbítás 4.3.4 Bizalmas üzenet-továbbítás 4.3.5 Távoli azonosítás 4.3.6 Letagadhatatlanság 4.3.7 Összefoglalás 4.4 Rendelkezésre állás menedzsment 4.4.1 Megbízhatóság jellemzık 4.4.2 Hibatőrı struktúrák 4.4.3 RAID adattárolás 4.4.4 Biztonsági mentések
32 32 33 34 35 35 36 36 36 36 37 38 39 39 41 41 42 43 43 46 49 52
2./53
4.4.5 5
Archiválás
53
Összefoglalás
53
3./53
1.
Informatikai biztonság a szervezeti biztonság tükrében
Az informatikai biztonság nem értelmezhetı a vagyonvédelemtıl, illetve a szervezeti biztonsági kérdésektıl függetlenül. A biztonság, illetve a kockázatok menedzselését komplexen, minden szempontra kiterjedıen kell kezelni. Természetesen az egyes területek részleteikben elkülöníthetıek, de ekkor is kapcsolódniuk kell egymáshoz és az alapelveknek azonosnak kell lenniük, valamint nem lehetnek "hézagok" a felosztott területek között. Az egységes alapelvek kialakítása egyeztetéssel, a különbözı területek párbeszédével vagy központi irányítással a gyakorlati tapasztalatok alapján nem mőködik. Üdvözítı megoldásnak az úgynevezett szervezeti biztonság megteremtése számít, ahol a biztonság menedzselése beépül az egész szervezet mőködésébe és a szervezetben dolgozókban egységes, tudatos biztonsági szemléletet alakít ki. Tekintve, hogy sok esetben a belsı visszaélések, illetve a hanyagság, a gondatlanság is komoly kockázatokat jelent, ezen veszélyeket is szervezeti szinten kell kezelni. A biztonság szervezeti szintő menedzselésében a minıség-biztosításhoz hasonlatos kontroll-szemlélet nyújt általános, alapelv jellegő megközelítési módot. A biztonságot ilyen értelemben a megkívánt állapot fenntartásaként értelmezzük. Védekezünk az ellen, hogy e normál állapottól eltérjünk (prevenció), illetve igyekszünk az eltérést minél hamarabb felismerni (detekció) és a mőködést a rendes kerékvágásba visszavezetni (korrekció). Annak megfogalmazására, hogy mi a fenntartani, megvédeni kívánt állapot az úgynevezett kontroll célok (control objectives) szolgálnak. A kontroll célok szemléletének jó megértése, egy adott szervezet esetében e célok jó kijelölése és szervezeti szintő tudatosítása kulcskérdés. Gyakorlatilag egy CIO, egy informatikai menedzser szintjén a biztonság a control objective-eken keresztől menedzselhetı. Fontos megérteni, illetve ráérezni, hogy ennek a szemléletnek megfelelıen egy control objective sohasem a konkrét, a biztonságot szolgáló technikára, módszerre vonatkozik, hanem a védekezéssel elérni kívánt állapotra. Ennek tükrében tehát nem control objective az, hogy "minden hálózati forgalom rejtjelezett legyen", hanem ekkor is az elérni kívánt célt kell megfogalmazni: "bizalmas adatokhoz csak jogosultak férhessenek hozzá". Bár elsı ránézésre a gyakorlati megvalósulás szemszögébıl az elıbbi két követelmény azonos eredményre vezet, hiszen az illetéktelenek elıl tipikusan rejtjelezéssel lehet elrejteni a továbbított információt, a második meghatározás mégis jóval tágabb. Ez utóbbi ugyanis magába foglalja mind a védekezés (esetünkben a rejtjelezés), mind az illetéktelenek tevékenységének (lehallgatás) felismerését, mind az esetlegesen bekövetkezı, nem kívánt esemény esetén a probléma mielıbbi kezelését (pl. lehallgatott jelszó esetén a jelszó azonnali felfüggesztését, illetve cseréjét). Így a control objective különleges helyzetekben is pontosabb, jobban megfogható irányelveket ad. Tehát a kontroll szemléletnek megfelelıen olyan szervezetet kell létrehozni, amelyben a biztosítani kívánt kontroll célok jól vannak megfogalmazva és ahol maga a szervezet már egyben a belsı problémákra, a biztonságot fenyegetı tipikus szervezeti gondokra is megoldást nyújt. Egy ilyen ideális szervezetben minden döntést és minden végrehajtást is kontrollálni kell, hogy a biztonsági követelmények minden szinten teljesüljenek. Ez a gyakorlatban azt jelenti, hogy a biztonsággal foglalkozó személyzetnek, illetve biztonsági felelısnek minden döntési és kivitelezési folyamatban megfelelı intézkedési, illetve vétó jogkörrel részt kell vennie, és a
4./53
szervezetnek, a szervezeten belüli folyamatoknak is ennek a célnak kell alárendelve lenniük. Az informatikai vezetés szempontjából ez annyit jelent, hogy a biztonsági felelısnek még az informatikai menedzser döntéseit is tudnia kell kontrollálni. Vagyis a biztonsági szervezet NEM lehet a CIO alárendeltje, hanem azzal legalább egy szinten kell elhelyezkednie a szervezeti hierarchiában. Egy példa jellegő szervezeti felépítés látható a következı ábrán:
Vezérigazgató Titkárság
Titokvédelmi felügyelõ Informatikai vezérigazgató helyettes
Gazdasági vezérigazgató helyettes
Biztonsági vezetõ
Adatbiztonsági osztály
Adatbiztonsági felügyelõ
Informatikai osztályok
Vagyonbiztonsági felügyelõ
Informatikai osztályok
1. ábra: Biztonsági szerepkörök egy szervezeti hierarchiában Vagyis a biztonsági követelmények teljesítéséért felelı biztonsági menedzser közvetlenül a felsı vezetésnek tartozik beszámolási kötelezettséggel és maguktól az egyes szervezeti egységektıl, így az informatikai szervezettıl is – szervezeti és pénzügyi értelemben – függetlenül dolgozik. Ez a szervezeti megosztottság nyújt garanciát arra, hogy a biztonsági kérdéseket megfelelı súllyal kezeljék és ne kerülhessenek a háttérbe. Gyakran elıfordul ugyanis az, hogy az informatikai rendszerek tervezésénél, kivitelezésénél a rendelkezésre álló idı, pénz illetve személyi erıforrások szőkössége miatt az egyébként drágán teljesíthetı biztonsági követelményekbıl engednek. Ennek elkerülése végett a biztonsági szervezetnek külön, az informatikai beruházási-, fejlesztési kerettıl független költségvetéssel kell rendelkeznie. Ebben a szervezeti felépítésben az informatikai vezetés, a CIO feladata, hogy minél jobban megértse a biztonsági szakemberek gondolkodásmódját és minél jobban tudjon velük együttmőködni. A függetlenített biztonsági szervezet további elınye, hogy a különbözı biztonsági területek – a vagyonvédelem, a humánpolitika, a kockázatkezelés – felé szorosabb kapcsolatot tud fentartani, így a bevezetıben említett biztonsági alapelvek egységes, harmonizált kidolgozására és érvényesítésére több a remény.
5./53
2.
Biztonság-szervezés
A biztonság és azon belül az informatikai biztonság megteremtése egy szervezeten belül hosszabb folyamat eredménye. Ezt a folyamatot, amely során egy többékevésbé már mőködı állapotból egy fokozottabb, szervezettebb biztonsági állapotot kívánnak létrehozni, hívjuk biztonság-szervezésnek. Számos tanácsadó cég rendelkezik olyan szolgáltatásokkal, melyekkel ezt a folyamatot segítik. Több, részleteiben is kidolgozott metodika is létezik arra, hogy az egyes lépéseket hogyan kell végrehajtani, hogy e komplex feladat még nagyobb szervezetek, nagyobb rendszerek esetében is kezelhetı legyen. A különbözı módszertanok ismertetésére itt nem térünk ki, de a biztonság-szervezés fıbb lépéseit – amelyekben az egyébként eltérı módszertanok is nagyjából azonosak – vesszük sorra.
2.1
Helyzetfelmérés
A biztonság-szervezés folyamata általában nem a kezdetektıl, hanem valamilyen már mőködı állapotból indul ki. Elsı lépésként tehát azt kell felmérni, hogy biztonsági szempontból milyen helyzetbıl indulunk ki, illetve hogy az aktuális gyakorlatnak milyen veszélyei vannak, melyek azok a területek ahol a legfontosabb a biztonságot erısíteni. A helyzetfelmérésnek két szempontot kell alapvetıen vizsgálnia: 1. A jelenlegi szabályozás megfelelı-e annak kikényszerítésére, hogy a biztonsági célok megvalósuljanak. 2. A gyakorlat megfelel-e a szabályzatokban elıírtaknak, illetve a szabályozatlan területeken a szakmailag elvárható szinvonalnak. Ennek megfelelıen számos hiányosság tárható fel, amelyek bár a konkrét veszélyektıl távolinak látszhatnak, olyan alapvetı problémákra utalnak, amelyek kezelése nélkül a biztonság hatékony menedzselése nem megoldható, ami végül komoly kockázati tényezıkhöz vezethet. Ezek a magas szintő hiányosságok tipikusan a következı nagy csoportokba sorolhatók: •
biztonsági követelmények nincsenek meghatározva (missing control objectives),
•
szabályzatok hiányosak vagy teljesen hiányoznak (missing controls),
•
a szabályozási rend, illetve a belsı ellenırzés nem megfelelı arra, hogy kikényszerítse a szabályok gyakorlati betartását (inadequate controls),
•
a gyakorlat eltér a szabályozástól,
•
az informatikai rendszer kialakítása, mőködtetése technikai veszélyeket hordoz magában (biztonsági lyukak, security flaws).
A felmérés eredményeként számos olyan hiányosságra fény derülhet, amely biztonsági problémák eredendı okául szolgálhat. Bizonyos kontrollok hiánya nem jelent feltétlenül biztonsági problémát, amennyiben valamilyen más úgynevezett kompenzáló kontroll (compensating control) az adott hiányossággal, gyengeséggel való visszaélést megakadályozza. Például, ha a hálózati forgalom nem rejtjelezett egy belsı hálózaton, akkor is megoldható a lehallgatás-védelem, ha a hálózat egészét fizikai megközelítés szempontjából védik. A feltárt hiányosságokat ezért egyenként elemezni kell, hogy valóban jelentenek-e és ha igen milyen súlyosságú biztonsági problémát. A helyzetfelmérés eredményébıl a biztonsági problémák listájának kigyőjtésével a veszélyforrás-feltárás lépése foglalkozik, míg az így
6./53
listaszerően összegyőjtött veszélyforrások súlyosságát a kockázatelemzés lépése határozza meg.
2.2
Veszélyforrás-feltárás
A helyzetfelmérés eredményeit elemezve, a szabályozás és a gyakorlat figyelembe vételével összeállítható egy lista arról, hogy az adott rendszert milyen veszélyforrások fenyegetik. Természetesen egy ilyen lista nem lehet teljes, de a helyzetfelmérés állításain szisztematikusan végighaladva, és a múltban elıfordult eseteket, tapasztalatokat is figyelembe véve, a leglényegesebb fenyegetı tényezık összegyőjthetıek. A listából esetlegesen kimaradt veszélyeket (például a teljesen valószínőtlen esetet, hogy egy repülıgép beleütközik az épületbe) mint maradék kockázat kezeljük A feltárt veszélyforrásokat tipikusan a következı szempontok szerint szokás csoportosítani: •
szervezési gyengeségek (szervezési hiányosságokból eredı veszélyek),
•
természeti veszélyforrások (pl. tőz, csıtörés, árvíz, villám, földrengés),
•
fizikai veszélyek (pl. betörés, lopás, rongálás),
•
logikai fenyegetések (pl. informatikai csalás, hálózati betörés, lehallgatás),
•
humán veszélyforrások visszaélések).
(belsı
munkatársak
hanyagsága,
gondatlansága,
A hatékony mendzselés szempontjából rendkívül fontos a veszélyforrás feltárás eredményeként létrejött lista megléte. Ennek segítségével ugyanis a biztonsági szervezés pontos teendıi, az elvégzendı feladat nagysága, az elırehaladás állapota jól becsülhetı és késıbb a készültség foka jól követhetı.
2.3
Kockázat-menedzselés
A veszélyforrások jelentısen eltérıek lehetnek a kisebb súlyú csalásoktól a katasztrófális hatású természeti csapásokig. A (költség-)hatékony menedzselés szempontjából így azt is meg kell vizsgálni, hogy az egyes veszélyforrások mekkora kockázatot jelentenek, hiszen egy határon túl nincs értelme erıforrásokat áldozni a kis kockázatú veszélyekre, különösen ha a kockázat sokkal kisebb, mint a védekezés költsége. A kockázatelemzés nyújt segítséget abban, hogy a leggyengébb pontokat, a legnagyobb kockázatokat jelentı fenyegetı tényezıket azonosítani lehessen és ennek ismeretében a költséghatékony, kockázatarányos védekezést lehessen kialakítani. A kockázatarányos védekezés nem csak költségminimalizálás szempontjából lényeges. Egy határon túl ugyanis semmi értelme bizonyos területeken túlzottan védekezni, amíg más területeken sokkal nagyobb kockázatú vszélyek is vannak a rendszerben. Például hiába szerelünk fel betörésbiztos bejárati ajtót egy helyiségre, ha abba az ablakon keresztül könnyedén be lehet mászni. A kockázatok meghatározása így az egyenszilárdságú védelem kialakításában is fontos szerepet játszik. A kockázat matematikai definíció szerint a kár várható értéke egy adott idıszakban. Képletszerően meghatározva:
R = ∑ pt × d t t∈T
7./53
ahol R a kockázat (risk), T a veszélyforrások (threat) halmaza, p t egy adott veszélyforrás bekövetkezési valószínősége (probability) az adott idıszakban, d t pedig a veszélyforrás bekövetkezésekor keletkezı kár (damage) mértéke. Egy informatikai rendszer esetében azért van különösen nehéz feladatunk a kockázat mértékének pontos meghatározásakor, mert a fenti képlet egyetlen paraméterét sem tudjuk jól megbecsülni. Ugyanis, mint láttuk a veszélyforrások listája sem lehet teljes; sok esetben a bekövetkezési valószínőség becsléséhez nem nem áll rendelkezésre korábbi statisztikai, tapasztalati érték; a keletkezett kár pedig egy informatikai rendszerben komplex, áttételes hatásmechanizmuson keresztül realizálódik, amely hatásmechanizmus feltérképezése, és a kár pénzben kifejezett meghatározása sem magától értetıdı. Például egy egyszerő hard diszk meghibásodás okozhatja, hogy nagy mennyiségő adat visszaállíthatatlanul megsemmisül. Ilyenkor az elsıdleges kár, a hard diszk megjavításának költsége eltörpül az áttételesen okozott károkhoz viszonyulva. Az elveszett adatok pótlásának költségei, a visszaállítás ideje alatt fennakadt üzleti folyamatok és még rosszabb esetben az ennek hatására elmaradt üzleti haszon hatalmasak lehetnek a bekövetkezés konkrét okától függetlenül. A kockázatbecslés során így a következı ábrán látható modellt szokás alkalmazni:
2. ábra: Veszélyforrások hatásának, a károk továbbterjedésének mechanizmusa A veszélyforrások általában konkrét rendszerelemeket támadnak, majd az egyes rendszerelemek sérülése hat a velük kapcsolatban lévı alkalmazásokra, amelyeknen keresztül a munkafolyamatokban – mind az alaptevékenységben, mind az operatív, taktikai és stratégiai irányításban is – fennakadások lehetnek. Amennyiben a kár hatását nem sikerül kellıen menedzselni, a fennakadás az ügyfelek, partnerek, üzleti folyamatok szintjén is érzékelhetı lehet és ennek szélsıséges esetben piaci hatásai is lehetnek (imázs romlás, ügyfelek elpártolása, piacvesztés). A hatás továbbterjedésének megfelelıen szokás ezért úgynevezett elsıdleges-, másodlagos- harmadlagos-, stb kárról beszélni. Egy informatikai rendszer esetében
8./53
a másodlagos-, harmadlagos károk nagyságrendekkel nagyobbak az elsıdleges-, másodlagos károknál, ezért rendkívül fontos minden veszélyforrás esetén egyenként elbírálni, hogy az esetlegesen bekövetkezı hatás meddig terjedhet ki. Tekintve, hogy informatikai rendszerekben a veszélyek, károk, illetve kockázati tényezık hatásmechanizmusa ennyire összetett, gyakorlatilag egyetlen módszertan sem vállalkozik arra, hogy a kockázat pénzügyi nagyságát közvetlenül megbecsülje, forintosítsa. A legtöbb, gyakorlatban alkalmazott kockázatbecslési módszertan a kategorizálás módszerét alkalmazza, azaz csak nagy nagyságrendben határozza meg a bekövetkezés valószínőségét és a kár nagyságát. Ez ugyan nem teszi lehetıvé, hogy a biztosításokhoz hasonlóan, számszerő kockázati értéket határozzunk meg egy veszélyforráshoz, és például ez alapján döntsünk arról, hogy az adott kockázati tényezı esetében milyen költségő védekezés kifizetıdı. Azonban ahhoz már jó kiinduló pontot ad, hogy az egyes kockázati tényezıket egymáshoz hasonlítva meghatározzuk a gyenge láncszemeket, amelyeket a legcélszerőbb kivédeni. Ezt a folyamatot nevezzük kockázatelemzésnek vagy kockázat-menedzselésnek, nevében is megkülönböztetve a kocskázat-becsléstıl.
2.3.1 Kockázatelemzés A kockázatok menedzselésének gyakorlati kivitelezésére számos eltérı módszertan létezik. Az alábbiakban egy leegyszerősített táblázatos módszert mutatunk be, amely ilyen formában nem teljes, de a folyamatot kellıen jól reprezentálja. A módszer során a következı táblázatot töltjük ki lépésrıl lépésre:
ID
Veszélyforrás
Bekövetkezés valószínősége P
SZ1
1. szervezeti vf
SZ2
2. szervezeti vf
Kár C
I
Kockázat A
... H1
1. humán vf.
... T1
1. természeti vf.
... L1
1. logikai vf.
... F1
1. fizikai vf.
...
1. táblázat: Kockázatelemzési tábla
9./53
R
Védelmi intézkedés
1. lépés: Kategóriák felállítása Elsı lépésként a rendszer nagyságától, az elemzett funkciók súlyától függıen, kategóriákat állítunk fel a bekövetkezés valószínőségének, illetve szándékos visszaélések esetén az úgynevezett támadási potenciálnak leírására; a károk nagyságának meghatározására; és az egyes veszélyforrások által jelentett kockázatok jellemzésére. a. Bekövetkezési valószínőség kategóriái Egy tipikus példa: •
PVS (very small) nagyon ritka: 10 éves távlatban valószínő csak az elıfordulása
•
PS (small) ritka: 1-10 éves távlatban elıforduló veszélyforrás, avagy felkészült, profi támadó tud csak visszaélni az adott gyengeséggel
•
PA (average) közepes: éves távlatban elıforduló, vagy átlagos szakember által kihasználható gyengeség
•
PL (large) nagy: évente akár többször is elıforduló esemény, vagy bárki által végrehajtható visszaélés
•
PVL (very large) gyakori: gyakran elıforduló eszközökkel kihasználható gyengeségek (pl. vírusok).
probléma,
automatikus
b. Kár kategóriák felállítása Egy lehetséges kategórizálás: •
DVS (very small) nagyon kicsi kár: elsıdleges, kis összegő kár
•
DS (small) kicsi kár: másodlagos, vagy komolyabb összegő kár
•
DA (average) közepes kár: fennakadás az alkalmazói rendszerekben
•
DL (large) nagy kár: komoly fennakadás az üzleti folyamatokban
•
DXL (extra large) nagyon nagy kár: már az ügyfélkörben is érezhetı, nehezen kiheverhetı kár
•
DD (disasterous) katasztrofális kár: az egész cég csıdjét okozó, esetleg komoly társadalmi hatású probléma.
c. Kockázati kategóriák meghatározása Kockázati kategóriák esetében, mint ahogy korábban is utaltunk rá, a legtöbb módszertan nem vállalkozik a kockázat forintosítására, mindössze olyan kategóriák felállítására, amely segít az összehasonlításban. E cél érdekében úgynevezett kockázati szorzótáblát szokás definiálni, amely megadja, hogy az egyes bekövetkezési valószínőség – okozott kár kategóriákhoz milyen kockázati kategóriát rendelünk.
10./53
Például: DVS
DS
DA
DL
DXL
DD
PVS
RVS
RVS
RS
RA
RL
RL
PS
RVS
RS
RS
RA
RL
RXL
PA
RS
RS
RA
RL
RXL
RXL
PL
RS
RA
RA
RL
RXL
RXL
PVL
RS
RA
RL
RXL
RXL
RXL
2. táblázat: Kockázati szorzótábla A kockázati szorzótábla összeállítása szakértıi feladat, lehetıséget biztosít arra, hogy az adott környezet specialitásait figyelembe vegyük a kockázatok nagyságának értelmezésénél. 2. lépés: Veszélyforrások listájának összeállítása Az elemzés nagyságrendi kategóriáinak rögzítése után a veszélyforrások listájának (a táblázat sorainak) meghatározása következik. A veszélyforrásokat tipikusan el szokás látni egy azonosítóval (ID) a késıbbi könnyő hivatkozás érdekében. Az azonosító elsı betőjele általában a veszélyforrás természetére utal: SZ – szervezeti H – humán L – logikai T – természeti F – fizikai veszélyforrás 3. lépés: Bekövetkezési valószínőségek nagyságrendi becslése A veszélyforrások bekövetkezési valószínőségének, illetve a gyengeség kihasználásához szükséges támadási potenciál megbecslése a P oszlop (probability) megfelelı kitöltésével történik. 4. lépés: Kárértékek nagyságrendi meghatározása A károk meghatározását az alapvetıen különbözı hatásmechanizmusok miatt külön szokás bontani a bizalmasság megsértésébıl (jogtalan információszerzésbıl), a rendszerben tárolt adatok manipulálásából (integritás sérülésbıl), illetve a rendelkezésre állásban bekövetkezett fennakadásból eredı károk esetében. A szakma ezen felosztásra a CIA hatásként hivatkozik az angol megfelelık (confidentiality, integrity, availability) kezdıbetői alapján. A táblázat kitöltése így a C, I, A oszlopok tartalmának meghatározásával folytatódik. 5. lépés: Kockázati tényezık származtatása Az R (risk) oszlop tartalma a kockázati szorzótábla alapján adódik. A CIA károk közül a legnagyobb értékőt vesszük általában figyelembe és ezt „szorozuk” össze a P oszlop tartalmával az 1/c. lépésben meghatározott kockázati szorzótábla segítségével. 6. lépés: Elviselhetetlen kockázatok kezelése A bemutatott kockázatelemzés tipikusan egy éves idıtartamra alkalmazható jól. Olyan esetekben, amikor nagy beruházással hosszabb távon kisebb gyakoriságú, de
11./53
nagy károkat okozó tényezıket lehet kiküszöbölni (pl.: háttér számítıközpont építésével) az eredı közepes, vagy kis kockázat nem indokolja rövid távon a nagy beruházás meglépését. Ezen esetek kezelésére szokás azon veszélyforrásokat megjelölni, amelyek ellen mindenképpen védekezni kell, függetlenül attól, hogy kicsi a bekövetkezési valószínőségük, mert az általuk okozott kár elviselhetetlen. Az elviselhetetlen kockázatokat a szorzótáblában is fel lehet tüntetni, illetve a kockázatelemzési táblázatban is jelölhetıek (külön oszlopban, vagy *-gal megjelölt sorokban). 7. lépés: Lehetséges védelmi intézkedések számbavétele Tipikusan külön dokumentumban (esetleg táblázatban) szokás az alternatív védekezési lehetıségeket összegyőjteni, feltüntetve nagyságrendi beruházási és üzemeltetési költségeiket és az általuk kielégített követelményeket. A kockázatmenedzselési táblázatban pedig már csak a választható, illetve javasolt védekezések azonosítóit szokás feltüntetni.
ID
Veszélyforrás
Bekövetkezés valószínősége
Kár
Kockázat
Védelmi intézkedés
P
C
I
A
R
PVL
-
DS
DA
RL
V1, V2
F1
Áramszünet
F2
HW meghibásodás (HD kivételével)
PL
-
-
DA
RA
V3, V4, V5
F3
Adathordozó meghibásodása
PL
DS
-
DL
RL
V4, V5, V6
H1
Betöréses lopás
PL
DL
-
DL
RL
V7, V8
L1
Lehallgatás
PL
DL
-
-
RL
V9
L2
Jogosulatlan módosítás
PS
-
DA
-
RS
V10
L3
Megszemélyesítés
PL
-
DA
-
RA
V11, V12
L4
Számítógépes betörés
PS
DL
DL
DS
RA
V13, V14, V15, V16
L5
Vírusfertızés
PVL
-
DS
DA
RL
V17
3. táblázat: Példa a kockázatelemzési tábla kitöltésére A kockázatelemzés eredményeinek hasznosítása Egy ilyen módon jól összeállított kockázatelemzési táblázat egy rendkívül hatékony eszközt ad a menedzsment kezébe, hogy a biztonság problémáját megfelelıen kezelje, jó döntéseket hozzon és szisztematikusan menedzselje a biztonsági kérdéseket.
12./53
2.3.2 Védelmi intézkedések meghatározása Vessünk újra egy pillantást a veszélyek hatásmechanizmusát bemutató ábrára (2. ábra). Amennyiben olyan intézkedéseket szeretnénk hozni a kockázatlelemzés eredményei alapján, amelyek a kockázat csökkentése irányába hatnak a következı alapvetı lehetıségeink vannak: 1. Veszélyforrás kiküszöbölése: Egy fenyegetı tényezıt teljes egészében kiküszöbölni megfelelı architektúrális átszervezéssel lehet. Védekezéssel csak nagyon ritka esetben érhetı el a teljes kiküszöbölés (pl.: megfelelı villámvédelemmel a villámcsapás hatása gyakorlatilag kivédhetı). 2. Veszélyforrás bekövetkezési valószínőségének védelmi mechanizmus (prevenció) alkalmazásával.
csökkentése:
erısebb
3. Veszélyforrás hatásának, az okozott kár nagyságának korlátozása: A kár esetében általában arról beszélhetünk, hogy a hatás továbbterjedését korlátozzuk a 2. ábranak megfelelıen. Ezt egyrészt átszervezéssel, ahol lehet a függıségek megszüntetésével tudjuk elérni, illetve a probléma mielıbbi felismerésével (detekció) és minél gyorsabb elhárításával (korrekció) is korlátozható a kár realizálódása. 4. Kockázat-áthárítás: Amennyiben a veszélyforrás bekövetkezését és a károk realizálódását elkerülni nem tudjuk, sok esetben az is megoldható, hogy a következményeket ne mi viseljük. Ahol lehet törekedni kell arra, hogy ilyen esetekben a kockázatokat másra hárítsuk: a beszállítói, illetve ügyfelekkel kötött szerzıdésekben kiköthetı például, hogy bizonyos veszélyek esetén (pl.: bankkártya másolás, PIN-kód lelesés) ık viseljék a következményeket. A kockázat áthárításának másik módja a biztosítások kötése. Sajnos az informatikai kockázatok tekintetében még rendkívül szőkösek ezek a lehetıségek A biztonság menedzselésekor fontos, hogy a fenti alapvetı lehetıségek közül a lehetı legtöbbet alkalmazzuk és az egész szervezet felé tisztán, egyértelmően megfogalmazzuk a kockázat-kezelés választott módját.
2.4
Biztonságpolitika
Nagyobb informatikai szervezetek esetén célszerő a biztosnágot szabályozó dokumentumoka két részre osztani: egy magas szintő, alapelveket, vezetıi döntéseket tartalmazó Biztonságpolitikára (BP) és egy konkrét, utasítás szintő Informatikai Biztonsági Szabályzatra (IBSZ). Ez a kettısség kifejezetten jól támogatja a hatékony menedzselhetıséget. A Biztonságpolitika irányelveinek meghatározásakor gyakorlatilag eltekinthetünk a konkrét informatikai megvalósítás részleteitıl és felsı vezetıi szinten születhet döntés a kockázatok kezelésének irányelveirıl. Az egyes veszélyforrások tekintetében a BP rendelkezik (1) a megfelelı védekezés elrendelésérıl, illetve a védelemmel szemben megfogalmazott követelményekrıl (a megvalósítás módja nem a Biztonságpolitika hatásköre!); (2) a kockázatok áthárításának módjáról (biztosítás, ügyfél-, partnerszerzıdések); (3) a felvállalt kockázatokról. A megfelelı védekezés irányelv jellegő megfogalmazása nem egyszerő feladat, hiszen különösen az informatika területén nagyon könnyő olyan követelményeket, biztonsági elvárásokat megfogalmazni, amelyek nem, vagy csak nagyon költésges, illetve a normál mőködést rendkívül nehézkessé tevı módon biztosíthatóak. Betarthatatlan szabályok pedig rendkívül károsak lehetnek, hiszen a szabályokkal szembeni lojalitást züllesztik. Ezért rendkívül fontos, hogy a biztonság menedzselésével foglalkozó vezetık – így a CIO is – legalább ökölszabályok szintjén tisztában legyenek az egyes biztonsági követelmények megvalósíthatóságával. Mint
13./53
a késıbbi fejezetekben látni fogjuk, (1) sajnos számos olyan informatikai biztonsági probléma létezik, amelyekre bizonyított módon nem létezik megoldás (pl.: Bizánci probléma); (2) a követelmények nagy részére azonban létezik olyan gyakorlati értelemben biztonságos megoldás, amely tetszıleges szintig erısíthetı (pl.: az aszimmetrikus rejtjelezés a használt rejtjelkulcsok korlátok nélküli növelésével tetszılegesen biztosnágossá tehetı); (3) ritkán ugyan, de tökéletes, egy adott veszélyforrást teljesen kiküszöbölı, elméletileg bizonyíthatóan biztonságos eljárás is létezik (pl.: Shannon-féle tökéletes rejtjelezı, az ún. One-Time-Pad); (4) továbbá számos olyan megoldás létezik, ahol valamilyen adott szintő védelem nyújtható, de a védelem foka nem fokozható. Ez utóbbi például a jelszó alapú felhasználó azonosítás, ahol a jelszavak kitalálásának nehézsége a számítási (próbálkozási) kapacitás folyamatos növekedésével nem tud lépést tartani, mert a felhasználóktól nem várható el, hogy egyre hosszabb és hosszabb jelszavakat jegyezzenek meg. De hasonló korlátozott védelmi képességüek a tőzfalak és a behatolás érzékelı (Intrusion Detection System – IDS) rendszerek is. Költségek nagyságrendje A követelmények teljesíthetıségével, illetve az egyes követelményeknek való megfelelés nagyságrendi költségeivel tehát tisztában kell lenni a Biztonságpolitika irányelveinek kialakításánál. Legjobb példa a költségek és a követelmények nagyságrendi függıségére a rendelkezésre állással szemben támasztott elvárások és azok teljesítésének költségei. Egy 5x8-as üzemidejő (egy héten 5 napig, napi 8 órát üzemelı) rendszer, amely kritikus helyzetben akár 1 hétig is kieshet, amíg egy esetleges meghibásodást kiküszöbölnek (sebezhetıségi ablaka 1 hét) nem kíván különös költségő extra intézkedést. Azonban egy 7x24-es rendszer 2 órás sebezhetıségi ablakkal (2 órán belül még katasztrófa helyzetben is biztosítani kell tudni a rendszer újraindítását) már a teljes számítóközpont duplikálását, on-line szinkronizálását, nagy megbízhatóságú hiba és katasztrófatőrı rendszerek alkalmazását követeli meg, amelyek költsége horribilis. Kockázat-áthárítás A kockázatok áthárításának alapvetıen két nagy módszere létezik: biztosítás, illetve az ügyfelekre, partnerekre szerzıdéses formában továbbhárított kockázatok megoldása. Ahol csak lehet igyekezni kell a beszállítókra, illetve – ha a piaci versenyhelyzet mgengedi – az ügyfelekre továbbhárítani bizonyos kockázati tényezıket. Például a beszállítóktól megkövetelhetı, hogy az általuk készített rendszerek bizonyos veszélyforrások ellen védettek legyenek és esetleges biztonsági esemény esetén saját költségen hárítsák el a problémát. Például HW szállító esetén megkövetelhetı, hogy meghibásodás, vagy katasztrófahelyzet esetén adott idın belül biztosítson tartalék eszközöket. Ügyfelek esetén tipikusan a csalásokból eredı károk háríthatóak át, például banki ügyfelek esetén a bankkártya lemásolásának, illetve a PIN-kód megszerzésének következményeit az ügyfélnek kell viselnie, holott szinte semmit sem tehet ezen veszélyek kiküszöbölésére. (Egy egyszerő vásárlásnál is leolvassák a kártyán tárolt információkat és a kártya birtokosnak PIN-kódját is egy olyan billyntyőzeten kell begépelnie, amely ki tudja hová továbbítja ezt a titkos információt!) A kockázat-áthárítás másik vonzónak tőnı megoldása, a biztosítások igénybevétele informatikai veszélyforrások kárainak enyhítésére, ma még csak gyermekcipıben jár.
14./53
Ennek több oka is van: •
Nehezen mérhetıek fel, illetve nehezen foghatóak meg azon veszélyek, amelyekre egy biztosításnak ki kellene terjednie.
•
A biztosítás igénybevételéhez szükséges minimális védekezés szintje egyedi elbírálást igényel, nincsenek olyan jól definiálható követelmények, mint például a széfekkel szemben.
•
A kockázat-elemzésénél láthattuk, hogy a károk számszerősítése még egy konkrét bekövetkezett esetben is nagyon nehezen mérhetı fel, nem beszélve a hipotetikus, nem elıre látható események hatásainak becslésérıl.
Még megkötött biztosítások esetén is adódhatnak problémák, viták abból, hogy például egy informatikai csalás ténye hogyan bizonyítható a biztosító társaság felé. Hiszen a bizonyíthatóság hiányában a kártérítés sem feltétlenül érvényesíthetı. Vagyis még kockázat-áthárításos védekezésnél is biztosítani kell, hogy a csalások leleplezıdjenek egy rendszerben és a visszaélés ténye BIZONYÍTHATÓ legyen. Tudatos kockázat vállalás Szokás mondani, hogy a biztonság nem más, mint tudatos kockázat vállalás. Sokkal jobb ugyanis félni, mint megilyedni, azaz ismert veszélyeket – mérlegelve a védekezés költségeit – tudatosan felvállalni, mint a veszélyeket meg sem ismerni. Nagyon fontos, hogy a védekezések mellızésérıl, a kockázatok vállalásáról mindig vezetıi szinten kell dönteni, az ilyen döntéseket a szakmai, technológiai szinten meghozni – különösen anélkül, hogy errıl a feletteseket tájékoztatnák – nem szabad. Biztosnágpolitikai döntések meghozatala A biztonságpolitika megfelelı elkészítéséhez, az irányelvek és a követelmények jó meghatározához, a megfelelı menedzsment döntések meghozatalához tehát ismerni kell: 1. a rendszert fenyegetı tényezıket (lásd veszélyforrások listája) 2. a veszélyforrások által jelentett kockázatok nagyságát 3. a védekezés követelményeinek megvalósíthatóságát 4. a védekezés nagyságrendi költségeit 5. a kockázat-áthárítás lehetıségeit Ezen információk alapján lehet dönteni: a., a megfelelı védelmi intézkedés alkalmazásáról, a védelem fokával szemben támasztott követelményekrıl b., a kockázat-áthárítás módjáról c., a kockázat tudatos vállalásról A fenti szempontok szerint összeállított Biztonságpolitika így egy menedzsment szintő szabályozás. A Biztonságpolitikát tipikusan a szervezet vezetıje (ügyvezetı igazgató, illetve a vezérigazgató) hagyja jóvá.
2.5
Informatikai Biztonsági Szabályzat
Az IBSZ hivatott a Biztonságpolitikában megfogalmazott irányelveket konkrét technikai követelmények, megoldások, illetve utasítások szintjére lebontani. Az IBSZ összeállítása szakmai feladat, részletes ismerete meghaladná e könyv terjedelmi korlátait.
15./53
Az IBSZ jóváhagyása általában az informatikai vezetı (CIO) szintjén történik, de nem ritka, hogy az informatikai szabályzatot is felsı vezetıi szinten hagyják jóvá. Itt annyit emelnék ki – mint CIO szempontot –, hogy a megfelelı menedzselés szempontjából a technikai részleteken túl az IBSZ elıírásainak biztosítania kell az utasítások végrehajtásának megfelelı ellenırzését is (belsı ellenırzés, külsı audit megkövetelése)! A megfelelı kontrollt magába a szabályozásba, illetve ügymenetbe célszerő beépíteni, mert így biztosítható, hogy ezen funkciók biztosan ne szenvedjenek sérelmet. Az IBSZ tertalmi és technikai felépítésével – tekintve, hogy ezen lépések már nagy mértékben függnek az adott rendszer sajátosságaitól – e könyv keretein belül nem foglalkozunk.
2.6
Katasztrófa-elhárítás menedzselése
Az informatikai rendszerek menedzselésének egyik sarkalatos pontja a rendelkezésre-állás menedzsmentje, amelyet külön fejezetben részletesebben is tárgyalunk. A biztonság-szervezés folyamatában a rendelkezésre állás tekintetében a katasztrófa-elhárítására való felkészülés megszervezése jelent egy fontos lépést. Ezért ezzel a területtel kiemelten szokás foglalkozni. Gyakorlati tapasztalatok többszörösen alátámasztják, hogy a megfelelı felkészülés nélkül kritikus helyzetekben a felmerülı technikai problémák sokasága (telepítı lemezek elérhetısége, SW-HW inkompatibilitás, segédeszközök hiánya, verzióproblémák) annyira lelassítják, megnehezítik egy rendszer újraindítását (az adatvesztéseket ne is említsük), hogy az már az elviselhetetlen, az üzletileg kezelhetetlen szinten túlnyúlik, aminek következményei beláthatatlanok. Ezért rendkívül fontos még az egészen kis szervezetek esetén is elıre megfelelıen felkészülni a katasztrófahelyzetben elvégzendı helyreállító tevékenységekre. Számos publikusan elérhetı ajánlás, illetve könyv foglalkozik részletesen a katasztrófa-elhárítás problémájával. Az eltérı módszertanok más és más célkitőzések alapján (van amelyik például csak az informatikai rendszer mőködésére koncentrál, van amelyik az üzleti folyamatok mőködésének biztosítását tartja fontosabbnak, stb.) más és más lépésekbıl építi fel a katasztrófákkal kapcsolatos elvégzendı tevékenységek listáját.
2.6.1 Fogalmak meghatározása Jelen könyv keretein belül a különbözı módszertanok bemutatására nincs mód. Ehelyett a széles körben használt, elfogadott szóhasználat, kifejezéstár definíciót vesszük sorra. Már csupán a fogalmak tisztázása is olyan fogódzót adhat, amellyel egy informatikai menedzser irányítani és kontrollálni tudja a szakemberek munkáját. Katasztrófa meghatározása A módszertanok többsége rendkívül pongyolán kezeli a katasztrófa fogalmát. Sokan katasztrófán a természeti csapásokat – árvizet, földrengést, tőzesetet – értik, holott az informatikai rendszerekben egy kritikus adathordozó meghibásodása, vagy egy vírusfertızés is okozhat szélsıséges esetben hatalmas – katasztrófális – károkat. A továbbiakban annak érdekében, hogy szemléletileg is tisztába tegyük ezt a fogalomkört, a következı ábrán feltüntetett módon határozzuk meg, hogy az események lefolyásának menetében hogyan értelmezhetıek egy informatikai katasztrófával kapcsolatos fogalmak:
16./53
katasztrófa-ok sebezhetıségi ablak informatikai katasztrófa normál mőködés
idı
katasztrófahelyzet
3. ábra: Informatikai katasztrófa bekövetkezése
katasztrófa-ok visszaállítás
helyreállítás idı
normál mőködés
katasztrófahelyzet
ideiglenes mőködés
normál mőködés
4. ábra: Informatikai katasztrófa elhárítása
Katasztrófa-ok A javasolt szóhasználatban katasztrófa-ok néven hivatkozunk arra az eseményre, amelynek hatására az informatikai rendszer annyira sérül, hogy további mőködése nem biztosítható és ha a mőködés visszaállítása a sebezhetıségi ablakon belül nem történik meg, akkor annak elviselhetetlen hatása lesz az üzleti folyamatokban. Ez a katasztrófa-ok lehet a gyakorlati életben katasztrófaként emlegetett természeti csapás (földrengés, árvíz), de lehet például meghibásodás, vírusfertızés, gondatlanság,vagy szándékos rongálás is. Katasztrófa-helyzet Kataztrófa-helyzetnek hívjuk azt az idıszakot, ami a katasztrófa-ok bekövetkezésétıl a minimális mőködési feltételek visszaállításáig tart, vagyis amikortól a helyzet már nem fenyeget az üzleti tevékenységben bekövetkezı elviselhetetlen hatással, illetve rossz esetben az informatikai katasztrófa bekövetkezéséig tart. Informatikai katasztrófa Informatikai katasztrófának vagy egyszerően csak katasztrófának azt hívjuk, amikor az informatikai rendszer normális mőködésében olyan hosszú ideig fennakadás van, aminek hatására az üzleti folyamatokban helyreállíthatatlan, elviselhetetlen károk keletkeznek. Gyakorlati tapasztalatok azt mutatják, hogy azon cégek túlnyomó többsége, amelyek informatikai rendszere hosszabb idıre leállt és ennek következtében az üzleti folyamataikban is komoly fennakadások voltak, nem tudták ezt a katasztrófát kiheverni és félév-év tárlatában csıdbe jutottak. Ezen tapasztalatok is rámutatnak a katasztrófa-elhárítás fontosságára. Tehát fontos megérteni, hogy ebben a szóhasználatban katasztrófán az informatikai rendszer leállásának hatását értjük és NEM a bekövetkezett kiváltó eseményt !
17./53
Míg a katasztrófa-okok gyakorlatilag kivédhetetlenek, addig ezen értelmezés szerint az informatikai katasztrófa elkerülhetı, elhárítható és ezért hívjuk katasztrófaelhárítási tevékenységnek azon intézkedéseket, amelyek e nem kívánt hatás kivédésére irányulnak. Visszaállítás és helyreállítás Két fogalmat különböztetünk meg egy katasztrófa-helyzet megszüntetésével kapcsolatban. Azon tevékenységeket, amelyek arra irányulnak, hogy a lehetı leghamarabb az informatikai rendszer legkritikusabb funkciói újra mőködjenek és az üzleti folyamatok leglényegesebb elemei újra folytatódjanak visszaállításnak (recovery) hívjuk. A visszaállítás eredményeként az informatikai rendszernek nem szükséges, hogy az összes funkciója mőködjön elegendı, ha az üzletmenet folytatásának biztosításához elengedhetetlen szolgáltatásokat képes ellátni. A helyreállítás (restoration) tevékeynsége a teljes informatikai rendszer normál mőködési állapotának helyreállítását célozza. Ekkor már a kevésbé fontos funkciók, illetve szolgáltatások újraindítása, illetve ha a meghibásodás kapcsán adatvesztés lépett fel, akkor az adatok pótlása is megtörténik. A helyreállítás elvben már a visszaállítás alatt is elindulhat. Mivel a helyreállytás mielıbbi véghezvitele is jelentısen csökkentheti a károkat, a megfelelı szervezés ebbıl a szempontból is nagyon fontos. Sebezhetıségi ablak Azt az idıt, ameddig egy cég üzleti folyamatai az informatikai renszer, – illetve alkalmazás-szintő követelmények meghatározásánál – az alkalmazói renszer leállását helyrehozhatatlan, elviselhetetelen következmények nélkül tolerálni képesek – sebezhetıségi ablaknak hívjuk. Amennyiben adott egy rendszer technológiai kialakítása és a visszaállítás folyamata meghatározható, hogy a visszaállítás legrosszab esetben mennyi idı alatt hajtódik végre. Ezt az idıt hívjuk a visszaállítás legrosszabb idejének. Ennek ismeretében eldönthetı, hogy egy renszer teljseíteni képes-e a sebezhetıségi ablak követelményét vagy sem.
2.6.2 Katasztrófa-elhárítási módszertanok Mint a bevezetıben már utaltunk rá, számos eltérı célokat megfogalmazó módszertan létezik a katasztrófa-elhárítás kapcsán. Részletes ismertetés nékül itt csak a fıbb csoportokat tekintjük át: DRP – Disaster Recovery Plan A DRP-t kidolgozó katasztrófa-elhárítási terv módszertanok kifejezetten az informatikai renszerek 1. megelızı intézkedéseire (pre disaster activities) 2. katasztrófa-helyzetben végzett visszaállító tevékenységekre (disaster recovery activities) 3. katasztrófa-helyzet elhárítását követı helyreállításra (post disaster activities) koncentrálnak, 4. illetve azon kiegészítı tevékenységeket írják le, amelyek a követelmények feltérképezéséhez, a katasztrófa-elhárítás teszteléséhez, oktatásához, valamint rendszeres karbantartásához szükségesek.
18./53
BCP – Buisness Continuity Plan A DRP-hez képest a BCP, az Üzletmenet-folytonosság biztosítási terv annyival nyújt többet, hogy nem csak kifejezetten az informatikai rendszerrel foglalkozik, hanem ahol lehet az üzleti folyamatok számára olyan alternatív eljárási módokat határoz meg (pl.: átmeneti manuális számlázás),hogy azokra áttérve az informatikai rendszer lebénulása esetén is folytatható legyen az üzletmenet.Természetesen a manulális tevékenységek nem képesek hosszabb távon kiváltani az informatikai rendszert, de annak sebezhetıségi ablakát képesek lehetnek megnyújtani, így adva nagyobb esélyt az idıben lezajló visszaállításnak. BRP – Business Recovery Plan A BRP az üzletmenet visszaállítási terv valahol a DRP és a BCP között helyezkedik el. Annyival mutat túl a DRP informatikai rendszerre fókuszáló szemléletén, hogy a visszaállytás és helyreállítás folyamatában az üzleti folyamatot is bevonja, hiszen egy komolyabb fennakadás esetén az informatikai renszer újraindításával még nem biztos, hogy az üzleti folyamatok is zökkenımentesen képesek újraindulni. A BRP a BCP-hez hasonlítva viszont nem keres átmeneti alternatív manuális megoldást az üzletmenet folytatásra, hanem az informatikai és üzleti folyamatok együttes, minél hamarabbi újraindítására koncentrál. Egyéb módszerek A fenti példákból si jól látható, hogy egyes esetekben több lehetıség közül is lehet választani aszerint, hogy az adott alkalmazás, illetve üzleti folyamat szempontjából milyen megközelítés a legcélszerőbb. Egyszerőbb esetben, ha a sebezhetzıségi ablakon belüli visszaállytás még valóban komolyabb hatások nélkül tolerálható elegendı DRP készítése, míg bonyolult üzletmenet esetén, ahol maguknak az üzleti folyamatoknak az újraindítása sem egyszerő a BRP megközelítése a célravezetıbb, míg ha a sebezhetıségi ablak követelménye nagyon kritikus a BCP katasztrófaelhárítási szemlélete alkalmazandó. Ezen eltérı kihívásokra adott válaszként számos további kombinált, összetett katasztrófa-elhárítási metodika is létrejött. Ezen módszerek részleteivel, alaposabb összehasonlításával itt nem foglalkozunk, pusztán néhány fontosabb, többnyire mindegyikük által alkalmazott lépést emelünk ki, az eddigiekhez hasonló fogalom-értelmezı stílusban.
2.6.3 BIA – Business Impact Analysis A BIA, vagyis az Üzleti hatáselemzés feladata, hogy felmérje, hogy az egyes üzleti folyamatok milyen mértékben függnek az informatikai rendszer egyes szolgáltatásaitól, mekkora idejő kiesés az amit még e folyamatok helyreállíthatatlan, elviselhetetlen hatások nélkül képesek tolerálni. A BIA eredményeként az egyes alkalmazásokkal szemben támasztott sebezhetıségi ablak követelményei határozhatóak meg. Tekintve, hogy nehezen megfogható hol csap át a még elviselhetı hatás az elviselhetetlenbe, néhány BIA módszertan fordítottan gondolkozik és arra keresi a választ, hogy az adott informatikai rendszer technológiai megvalósításából és a katasztrófa-elhárítási tevékenységekbıl meghatározható legrosszabb visszaállítási idıbıl kiindulva ezen kiesési idı milyen hatásokat vált ki az üzleti folyamatok szintjén. Ez utóbbi megközelítés így nem kalkulál több lehetséges alternatívával nem határoz meg konkrét sebezhetıségi ablakot csak arra ad választ, hogy a jelenlegi technológiával legrosszabb esetben is biztosítható visszaállítási idı elegendı-e vagy sem. Tekintve, hogy bizonyos határon túl a visszaállítás ideje csak nagyobb, tipikusan költséges architekturális átszervezéssel (pl.: meleg tartalékolásos vagy klaszteres, esetleg többszörözött rendszer bevezetésével) oldható meg, amikor is a
19./53
visszaállítás ideje ugrásszerően csökken, ez utóbbi módszer megfelelıbb alapot biztosíthat egy felsıbb szintő – az informatikai redszer architekturális átszervezését célzó – döntés meghozatalához.
2.6.4 Mentési-visszaállítási stratégia A Mentési-visszaállítási stratégia (Backup-Recovery Strategy) a biztonsági mentések ütemezésével kapcsolatos döntéseket tartalmazza. Mivel számos egymással ellentétes követelmény (mentés ideje, gyakorisága, visszaállítás ideje, adatvesztés mértéke) kompromisszumos összehangolásának eredménye a megfelelı backuprecovery stratégia kialakítása, minden rendszer esetében egyedileg kell meghatározni az optimális megoldást. A különbözı mentési módszerekrıl, az itt fellépı konzisztencia problémákról a késıbbiekben a „Rendelkezésre-állás menedzsment” fejezetben térünk ki bıvebben.
2.6.5 Katasztrófa-elhárítási terv A katasztrófa-elhárító módszertanok végeredménye mindegyik esetben egy terv dokumentum, amely a katasztrófa-helyzettel kapcsolatos legfontosabb információkat, teendıket tartalmazza. Ennek a tervnek minimálisan tartalmaznia kell a következıket: •
Katasztrófa-elhárításban, illetve a felkészülésben részt vevı személyek listája és elérhetıségeik (munkahelyi és otthoni címek és telefonszámok)
•
Felelısségi, döntési jogkörök
•
Felkészülési tevékenységek: a biztonsági mentések stratégiáját, szükséges eszközök tárolását, eszköz tartalékolási stratégiáját (tartalékkészlet, hideg tartalék)
•
Visszaállítási tevékenységek:
•
ki jogosult a katasztrófa-helyzet elrendelésére
riadóztatási lánc
visszaállítás ütemterve
a minimálisan szükséges funkciók, szolgáltatások listája
visszaállításhoz szükséges konkrét információk, technikai adatok
ellenırzı lista eldöntéséhez
(check
list)
az
újraindítás
megfelelı
elvégzésének
Helyreállítási tevékenység
a helyreállítandó funkciók, szolgáltatások listája
a helyreállításban részt vevı személyek és feladataik
adatvesztés pótlásának, az adatbázisok konzisztencia biztosításának módja
•
Tesztelési útmutató
•
Oktatási terv
•
Karbantartási terv
Fontos megjegyezni, hogy a Katasztrófa-elhárítási terv elkészítése mindössze egy jó mérföldkı annak biztosítása érdekében, hogy a vezetıi szintrıl kikényszeríthetı legyen a megfelelı felkészülés. Amennyiben egy rendszer folyamatos fejlıdésével, változásával e dokumentum és így a felkészülési tevékenységek nem tartanak
20./53
lépést, a terv elavulttá, pontatlanná és így használhatatlanná válik! Ennek következményei pedig beláthatatlanok. A naprakész felkészültséget folyamatosan biztosítani kell.
2.6.6 Tesztelés, oktatás, karbantartás A katasztrófa felkészülési tevékenységnek a mentési stratégia pontos végrehajtásán túl a tesztelés, oktatás és karbantartás a legfontosabb elemei. Tesztelés kikényszerítése A visszaállítás és helyreállítás elméletben kidolgozott lépéseinek gyakorlati tesztelése sok esetben komoly problémába ütközik, mivel az éles rendszerben a tesztek nem hajthatóak végre és az eredetivel azonos eszközpark általában nem áll rendelkezésre. Mindezek ellenére számos megtörtént eset tapasztalata alapján, ahol a mentésekbıl visszaállított rendszer valamilyen technikai probléma miatt nem mőködött, egyértelmően az a javalsat fogalmazható meg, hogy MINDEN ESETBEN KI KELL KÉNYSZERÍTENI, HOGY A KATASZTRÓFA-ELHÁRÍTÁSI TEVÉKENYSÉGEKET A GYAKORLATBAN IS TESZTELJÉK, ÉS DEMONSTRÁLJÁK, HOGY A VISSZAÁLLÍTOTT RENDSZER ÜZEMKÉPES ÉS ADATBÁZISA KONZISZTENS. Egy erıskező informatikai vezetınek nem szabad elfogadni a visszaállítás demostrálását technikai problémákra hivatkozva elutasítók érvelését! Minden körülmények között meg kell gyızıdni arról, hogy a kidolgozott visszaállítási módszer pontosan mőködik! Gyakorlatilag ez az ellenırzés az, amelynek segítségével kétséget kizáróan bizonyítani lehet, hogy a katasztrófa felkészülés rendben megtörtént. Amennyiben a visszaállítást nem tudják demonstrálni, könnyen elıfordulhat (és mint utaltunk rá, tapasztalatok alapján többször elı is fordul), hogy amikor szükség van rá, akkor nem mőködik az eltervezett visszaállítás, aminek következményei beláthatatlanok. Amennyiben az éles rendszerrel azonos kapacitású tartalék rendszer még a teszt idejére sem áll rendelkezésre, akkor is biztosítani kell, hogy legalább egy kisebb, csökkentett mérető adatbázissal az egész folyamatot végigpróbálják. Nagyon fontos, hogy a tesztelés során minden mővelet elvégzésének idejét pontosan mérjék és dokumentálják. Az objektív mérési eredmények ugyanis magukért beszélnek és semmilyen elméleti kalkulációval sem pótolhatóak. Egy felelıs vezetınek ezen objektív tények birtokában kell döntenie, hogy a felkészülést elfogadja-e, vagy tovább erıltesse annak megfelelıbb szinvonalú végrehajtását. A katasztrófa-elhárítás területén egy CIO kompromisszumot nem fogadhat el! Oktatás Az elıállt elhárítási tervet nem elegendı kinyomtatni és elhelyezni páncélszekrényben a rossz idıkre. Egy esetleges katasztrófa-helyzetben ugyanis senkinek sem lesz ideje azt elolvasni. Még felkészülséi idıszakban annak tartalmát az érintettekkel meg kell ismertetni, a teendıket oktatni kell, hogy a kritikus idıpontban valóban összeszokottan, szervezetten lehessen a nem várt helyzeteket is kezelni. A rendszeres oktatás segít továbbá a munkatársak körében a tudatosság, a megfelelı biztonsági szemlélet kialakításában is. Renszeres karbantartás Mint korábban utaltunk rá, egy elavult, nem naprakész katasztrófa-elhárítási terv nem tudja funkcióját betölteni, ezért rendkívül fontos, hogy annak tartalmát a rendszer változtatásaival szinkronban tartsuk. A megfelelı szintentartásról rendszeresen, félévente, de legalább évente a felelıs vezetınek, tipikusan a CIO-nak meg kell gyızıdnie.
21./53
Megemlíthetı, hogy komolyabb rendszerek esetén ez az idıszakos felülvizsgálat sem elegendı. Számos felügyeleti rendszer nyújt már olyan szolgáltatásokat, hogy nem csak az egyes változtatásokat, illetve ezen változtatások miatt szükséges lépéseket tudja kontrollálni, hanem például a biztonsági mentések precíz végrehajtását is figyelni tudja. Érdemes ezen rendszerek monitorozó-figyelmeztetı funkcióját a katasztrófa-elhárítási tevékenységek esetén is igénybe venni. CIO felelıssége Összefoglalva a CIO felelıssége a katasztrófa-elhárítással kapcsolatban: 1. Az üzleti folyamatok által az informatikai rendszerrel szemben támasztott követelmények felmérése, a BIA elemzés végrehajtása, a sebezhetıségi ablakok meghatározása. 2. Olyan katasztrófa-elhárítási rendszer kidolgozása, amelynél garantálható, hogy a visszaállítás legrosszabb ideje is teljesíti a sebezhetıségi ablakok követelményeit. 3. Tesztelni, illetve demonstrálni kell, hogy a visszaállítás mőködik és a visszaállított adatok konzisztensek. A CIO nem fogadhat el kompromisszumot a demonstráció mellızésérıl! 4. Az elkészült tervet oktatni kell az érintettek körében. 5. A rendszeres karbantartás elvégzésérıl a CIO-nak kell meggyızıdnie.
2.7
Biztonsági audit
A biztonság-szervezés megfelelı elvégzésérıl tipikusan külsı ellenırök, úgynevezett auditorok bevonásával szoktak megbizonyosodni. A belsı ellenırzésnek is természetesen megvan a funkciója ebben a folyamatban, de a külsı ellenırzés, tekintve hogy független a belsı szervezeti viszonyoktól, illetve hogy pont olyan problémákra tudja felhívni a figyelmet, amelyre eddig belülrıl nem gondoltak, a legtöbb esetben hatékonyabb tud lenni. ISACA Az információrendszer ellenıröknek (information systems auditoroknak) a nemzetközileg is elismert szervezete az Information Systems Audit and Control Association (ISACA), amely belsı vizsgák és kötelezı évenkénti továbbképzések révén ad ki szakértıi minısítéseket Certified Information Systems Auditor (CISA) néven. A CISA minısítés nemzetközileg elismert és már hazánkban is széles körben elfogadott, megkövetelt minısítés, gyakorlatilag a MTESZ által kibocsátott Információrendszer Ellenır szakértıi minısítés is ezt a vizsgát honosította. Szakértıi vélemény kibocsátására ilyen minısítéssel rendelkezı szakemberek jogosultak. Az ISACA információ-rendszer ellenırzési „bibliája” a Governance and Control Objectives for Information and Related Technology (COBIT). Ezt az alapmővet rendszeresen frissítik, hogy mindig megfeleljen a technika folyamatos fejlıdésének, így az irányelveken túl az IT rendszerekre vonatkozó konkrét útmutatást is nyújt. BS7799 Míg a COBIT nem szabvány, hanem „csak” az ISACA irányadó ajánlása, addig e témában a BS7799, amely a kezdetekben angol szabványként (Brittish Standard 77.99) jött létre, az ISO általi elfogadásával vált nemzetközi szabvánnyá ISO 17799 néven. A BS7799 konkrét követelmények szintjén határozza meg, hogy egy a szabványnak megfelelni kívánó szervezetnek milyen feltételeket kell teljesítenie. Míg az ISACA, illetve CISA auditorok nem bocsátanak ki „megfelelt/nem felelt meg” jellegő tanúsítványokat, addig a BS7799 szabványnak léteznek tanúsító intézetei,
22./53
amelyek jogosultak annak elbírálására, hogy egy szervezet megfelel-e a szabványban leírt biztonsági követelményeknek. A megfeleltségrıl az ISO 9000 minıségbiztosítási tanúsítványhoz hasonlóan igazolást kap a minısített szervezet. Elmondhatjuk, hogy ma már Magyarországon is létezik olyan cég, amely BS7799 tanúsítási szolgáltatást nyújt. Common Criteria Bár nem szorosan a biztonság-szervezés szintjéhez kapcsolódik, megemlítjük még a Common Criteria (CC) szabványt is (ISO15408), amely nem szervezetet, hanem egy konkrét terméket minısít biztonsági követelmények alapján. A minısítési rendszer alap filozófiája, hogy nem kifejezetten az elıállt végterméket vizsgálja, hanem inkább a tervezési és a kivitelezési folyamattal (HW, illetve SW fejlesztéssel) szemben állít fel követelményeket. Tekintve, hogy a szabványnak megfelelı szigorú fejlesztési módszertan jelentısen megdrágíthatja egy termék elıállítását és így a végfelhasználói árát is, jelenleg csak kevés ilyen CC-minısítéső termék kapható, a piac nem tudja igazán kikényszeríteni ilyen termékek gyártását, így sajnos csak lassan válik elfogadottá a CC szabványban megkövetelt szigorú fejlesztési módszertan.
2.8
Összefoglalás
Láthattuk, hogy a biztonság-szervezés egy hosszú, több egymásra épülı lépésbıl álló folyamat. A szervezeti szintő biztonság megteremtése érdekében ezért minden nagyobb vállalatnak ezen a folyamaton egyszer, de leginkább néhány évente rendszeresen, végig kell mennie. Tartson bárhol is ez a folyamat, látható, hogy egy CIO-nak mindig szoros pórázon kell tartania a biztonság témakörét, pontosan tudnia kell, hogy az egyes lépések során hol vannak azok a kontroll pontok, mérföldkövek, amelyek hiba nélküli teljesüléséhez ragaszkodnia kell.
3.
Biztonsági alapmódszerek
Mint a biztonság-szervezés folyamatánál is láttuk, ésszerő a biztonság menedzselését két szintre bontani. Egy biztonságpolitikai irányelvek és követelmények megfogalmazásának szintjére és magának a konkrét technológiai megvalósításának a szintjére. Ebben a fejezetben még mindig csak azon felsıbb szintő biztonsági alapmódszerekkel, irányelv jellegő megközelítésekkel foglalkozunk, amelyeket tipikusan a Biztonságpolitikában kell lefektetni.
3.1
CIA követelmények
A biztonság, a biztonságosság nehezen megfogható fogalmát további, sokkal jobban megfogalmazható követelményekre szokás bontani. Széles körben elfogadott a CIA felosztás, amely a •
bizalmasság (Confidentiality)
•
sértetlenség (Integrity)
•
rendelkezésre állás (Availability)
követelmények angol megfelelıinek kezdıbetői alapján kapta elnevezését. (Megjegyzés: bizonyos módszertanok, pl.: ITB81 további kategóriákat is megkülönböztetnek, mint például a hitelesség, vagy a funkcionalitás. Mivel a CIA megközelítés széles körben elfogadott, a továbbiakban mi is ezt követjük.) 1
Informatikai Tárcaközi Bizottság: Informatikai biztonsági módszertani kézikönyv 8-as számú ajánlás (http://www.itb.hu/ajanlasok/a8/index.html).
23./53
3.1.1 Bizalmasság A bizalmasság fogalmát, illetve a hasonló kifejezéseket, mint például a titkos, titkosított, rejtjelezett, kódolt fogalmakat gyakran összemossák, ezért próbáljuk meg egy kicsit körbejárni ezt a kérdéskört. Kódolás A precíz használat során a kódolás nem csak a rejtjelezés jellegő transzformációt, hanem például a sőrítés jellegő mőveletet is magában foglalja, így a bizalmasság, rejtjelezés szinonimájaként használni pongyolaság. A következıkben igyekszünk így ezt a kifejezést csak olyan helyzetben használni, ahol a szövegkörnyezetbıl egyértelmően kiderül, hogy konkrétan milyen kódolási lépésrıl van szó. Rejtjelezés A rejtjelezés valami olyan kódolási mőveletre utal, amelyet valamilyen titok, avagy rejtjel kulcs ismerete nélkül nehéz végrehajtani (pl.: digitális aláírás), vagy nehéz visszakódolni (lásd: szimmetrikus rejtjelezés). Tekintve, hogy a kriptográfia szóhasználatában a rejtjelezés a digitális aláírás jellegő kódolási technikákat is magában foglalja, amikor maga az aláírt üzenet akár nyílt, bárki által olvasható formában marad. Vegyük tehát észre, hogy a rejtjelezés nem feltétlenül jelenti a titkosságot! Titkosítás A titkosítás fogalma ugyanúgy nem tiszta. Bizonyos értelemben a titkosítás jelentheti, hogy egy nyomtatott, vagy elektronikus dokumentum fedılapjának jobb felsı sarkába odaírjuk, hogy „szigorúan titkos”, de jelentheti a titkosságot biztosító rejtjelezés elvégzését is. Vagyis mind a bizalmasságról való rendelkezést, mind a technikailag olvashatatlan formára történı kódolást is jelentheti. Fogalmak tisztázásának fontossága A biztonság jó menedzselésének feladata, hogy ezt és az ehhez hasonló kevert fogalmi rendszert feloldja, egyértelmővé tegye és a munkatársak körében tisztázza. A szervezetben belül tudatosítani kell, hogy a biztonság menedzselése során a rendelkezések, illetve a követelmények meghatározása és az azoknak megfelelı technikai szintő mőveletek – fogalmi és felelısségi szinten is – élesen elkülönülnek egymástól. (Hasonló példa a jogosultságok meghatározása is, ahol tipikusan egy vezetı írásban engedélyezi, hogy egy beosztottja milyen információkhoz férhessen hozzá, de a konkrét technikai beállításokat már a rendszergazda végzi. A „jogosultság meghatározása” így vezetıi hatáskör, míg a „jogosultság beállítása” rendszergazdai feladat.) Rendkívül fontos tehát, hogy a megfelelı szóhasználatot – a köznapi nyelv meglehetıs pontatlansága miatt – a Biztonságpolitika tisztázza és a szervezeten belül e fogalmi szemlélet tudatosuljon. Titok-kategóriák A Biztonságpolitika feladata továbbá, hogy magasabb szintő szabályozásokból, törvényi jogszabályokból és felügyeleti utasításokból átvegye a bizalmas adatok körének meghatározását, illetve kiegészítse azt az adott szervezet saját követelményeivel. A magyar törvényekben sajnos a titkosságra vonatkozó követelmények nincsenek összegyőjtve, összehangolva, hanem csak az egyes törvényi rendelkezésekben szétszórva találhatók meghatározások az egyes titok-kategóriákra, az azok kapcsán betartandó szabályokra és a törvénysértési szankciókra. A teljesség igénye nélkül a magyar jogrendben a következı titok-kategóriák léteznek:
24./53
•
államtitok, szolgálati titok, külföldi minısített adat (1995 LXV. 2§-5§)
•
személyes adat, különleges adat (pl.: vallási hovatartozás, egészségügyi adatok) (1992 LXIII 2§, 1999 LXXII)
•
magántitok (1978 IV 177§)
•
levéltitok (1978 IV. 178§, 1992 XLV 27§)
•
gyónási titok, orvosi-, ügyvédi titoktartás (1972 II 77§)
•
üzleti titok (1990 LXXXVI 5§, 1991 LXIX 18/a§)
•
adótitok (1990 XCI 46§)
•
banktitok, biztosítási titok (1991 LXIX 46§)
párttagság,
A Biztonságpolitika feladata annak meghatározása, hogy a szervezeten belül milyen titok-kategóriákat és azokat hogyan kezeljék. A kategóriák felállításával bıvebben a 3.4 fejezet foglalkozik. (Emlékeztetıül: a Biztonságpolitika a kezeléssel kapcsolatban a követelményeket és irányelveket rögzíti, a konkrét technikai megvalósításról az IBSZ rendelkezik.) Egy szervezeten belül tipikusan a törvények által megfogalmazott üzleti titok kategóriáját szokás tovább bontani, kiegészítve a személyes adatok védelmérıl szóló rendelkezésekkel. Az üzleti titkot az 1994 IX. törvény 20§-a a következıképpen határozza meg: ”üzleti titok a gazdasági tevékenységhez kapcsolódó minden olyan tény, információ, megoldás vagy adat, amelynek titokban maradásához a jogosultnak méltányolható érdeke főzıdik.” Ezt az általános megfogalmazást egy konkrét cég esetében fontos pontosítani és egyértelmővé tenni a munkatársak felé, hogy mely információk tekinthetık üzleti titoknak és melyek azok, amelyek publikusak, illetve kiadhatóak. Védelem foka A bizalmasság védelmének fokát irányelv szinten gondosan kell meghatározni annak érdekében, hogy könnyen betartható, mégis tudatos és kellıen erıs védelmet nyújtson. A különbözı érzékenységő adatok természetesen eltérı védelmi szinteket követelhetnek meg, amely eltérı követelményeket a meghatározott titokkategóriáknak tükrözniük kell. Általánosan megfogalmazva a védelem fokának meghatározásához minden titok-kategóriára a következıket kell egyértelmővé tenni: •
ki jogoslut egy adott információt az adott kategóriába sorolni;
•
mely információk tartoznak természetüknél fogva eredendıen az adott titokkategóriába;
•
ki jogosult egy információ titok-besorolását megváltoztatni;
•
kik férhetnek hottá és milyen feltételekkel az ilyen információhoz;
•
milyen fizikai, térbeli, tárolási, továbbítási korlátozó intézkedések vonatkoznak az adott minısítési kategóriára;
•
illetéktelen személyek ellen milyen fokú védelmi intézkedést kell alkalmazni;
•
milyen nyilvántartást (loggolást) kell vezetni az információkhoz való hozzáférésekrıl (bejelentkezés ténye, naplózás rekordonkénti hozzáférésrıl,...);
•
ki és milyen szinten ellenırzi a jogosultságoknak megfelelı szabályok betartását;
•
milyen szintő intézkedéseket kell foganatosítani az illetéktelen hozzáférések felderítése érdekében;
25./53
•
milyen szankciók, milyen eljárás alkalmazandó a szabályok megsértése esetén.
3.1.2 Sértetlenség A sértetlenség biztosítása analóg a bizalmassá biztosításával. Ebben az esetben is kategorizálás és a kategóriákhoz a „Bizalmasság” fejezetben látott módon különbözı követelmények meghatározása a szokásos megközelítés. A sértetlenség biztosítása kapcsán a konzisztencia és a hitelesség témakörét érdemes külön figyelemmel kezelni. A hitelesség biztosításról a 4.3.3 fejezetben, míg a konzisztencia kérdésérıl a 4.4.4 fejezetben térünk ki részletesebben. A Biztonságpolitika szintjén természetesen itt is csak az elvárásokat, illetve az irányelveket kell meghatározni.
3.1.3 Rendelkezésre-állás A rendelkezésre-állás követelményei talán abban térnek el a bizalmasság és a sértetlenség követelményeitıl, hogy itt pontosabb, objektíven mérhetı paraméterekkel leírhatóak az elvárások. A számos rendelkezésre-állási paraméter definíció jellegő ismertetésével a „Rendelkezésre-állás menedzsment” fejezetben foglalkozunk. Itt csak azon jellemzıkre térünk ki, amelyek a Biztonságpolitika szintjén érdekesek. Üzemidı Azt határozza meg, hogy egy rendszernek (tipikusan heti bontásban) mennyit kell üzemelnie és karbantartási célokra mikor és mennyi idıre állítható le anélkül, hogy az érdemi fennakadást okozna. Az üzemidıt tipikusan
x<óra> alakban szokás megadni, ahol azt határozza meg, hogy egy héten hány napot üzemel a rendszer (tipikusan 5 vagy 7), míg az <óra> az egy napon belüli üzemidıt határozza meg. Fontos pontosan érteni, hogy míg egy 5x12-es tipikus rendszer esetében van arra lehetıség, hogy esetenként a rendszert a biztonsági mentések idejére leállítsák, illetve hétvégente komolyabb karbantartási munkákat is elvégezzenek, míg egy 7x24-es rendszer esetén már speciális és így jóval költségesebb eljárásokat kell alkalmazni még az egyébként egyszerő karbantartói feladatok ellátására is. Rendelkezésre-állási tényezı Azt határozza meg százalékos formában, hogy egy rendszer az üzemidın belül mekkora arányban mőködik valóban jól. Azaz elıre nem várt leállásokból mekkora kiesés várható statisztikailag hosszú idıtávlatban. A rendelkezésre-állási paraméter tipikus értéke 99,9...%, így a hétköznapi szóhasználatban csak a 9-esek számával szokás rá hivatkozni (3 9-es, 4 9-es rendszer, stb.). A következı táblázat éves viszonylatban mutatja be, hogy a különbözı nagyságú rendelkezésre-állási paraméterek mekkora nem várt kiesési idıt engednek meg:
26./53
nagyságrend
A
max. kiesési idı 1 év alatt
1 9-es
90 %
36,5 nap (1 hónap)
2 9-es
99 %
3,5 nap
3 9-es
99,9 %
9 óra
4 9-es
99,99 %
1 óra
5 9-es
99,999 %
5 perc
6 9-es
99,9999 %
32 mp
7 9-es
99,99999%
3 mp
4. táblázat: Rendelkezésre-állási tényezı nagyságrendi értékei Látható, hogy az egyre nagyobb kategóriák rendkívül szigorodó elvárásokat határoznak meg. Egy tipikus PC architektúrájú szerver jó, ha a 2 9-es renkelkezésreállást biztosítani tudja, míg egy komoly központ esetén a 3 9-es szint elvárható. 4 9es fölött pedig már csak speciális, nagy rendelkezésre-állású architektúrák jöhetnek szóba. Sebezhetıségi ablak A sebezhetıségi ablak meghatározását már a katasztrófa-elhárításról szóló fejezetben megadtuk. Ez a paraméter azt az egyszeri maximális idıt határozza meg, amelyen belül egy rendszer mőködıképességét feltétlenül vissza kell állítani, különben a rá épülı üzleti folyamatok helyreállíthatatlan, elviselhetetlen károkat szenvednek. A fenti három paraméter az üzemidı, a rendelkezésre-állási tényezı és a sebezhetıségi ablak leírja egy rendszerrel szemben megfogalmazott fıbb elvárásokat. Ezen paraméterek gondos meghatározása kulcskérdés. Tekintve, hogy a paraméterek szigorúságától függıen nagyságrendi különbségek adódhatnak a technológiai kivitelezésben, a Biztonságpolitikának ebben az esetben fel kell vállalnia, hogy a rendelkezésre-állás követelményeit biztosító architektúrát irányelveiben meghatározza. A fıbb döntési lehetıségek itt a következık: •
Megbízhatóbb, úgynevezett nagy rendelkezésre-állású (HA, high-availability) rendszerek alkalmazása;
•
hideg, meleg, vagy forró tartalékolású rendszer választása;
•
hibatőrı, esetleg katasztrófatőrı, full redundáns rendszer alkalmazása.
Tekintve, hogy az említett megoldások költségvonzata rendkívül nagy különbséget, több nagyságrendi eltérést mutathat, a megfelelı döntés alapos mérlegelést követel.
3.2
PreDeCo védelem
A követelmények meghatározása után – még mindig az alapelvek szintjén maradva – meg kell határozni a védekezés módszereinek irányelveit. A védekezési módszerek tervezésére általánosan elfogadott és a gyakorlatban is rendkívül jól alkalmazható szemlélet az úgy nevezett PreDeCo kontrollok (PreDeCo controls)
27./53
megfogalmazása nyújt. A PreDeCo szemlélet szerint egy kontrol cél (control objective) biztosítására tett védelmi intézkedések három, alapvetıen más mőködéső védelmi mechanizmus ötvözésébıl tevıdnek össze. A PreDeCo név e három fı kontrol mechanizmus angol neveinek kezdıbetőibıl áll: •
Preventive controls:
•
Detective controls: felismerı kontrollok
•
Corrective controls: elhárító, helyreállító kontrollok
megelızı, kivédı kontrollok
A CIA követelmények és a PreDeCo kontrollok egy olyan keretet adnak a védelmi intézkedések egyébként végeláthatatlan listájának, amely szisztematizmust ad a tervezés folyamatához és így megkönnyíti a probléma menedzselését. Erre a keretrendszerre a legtöbbször, mint CIA x PreDeCo mátrix-ként hivatkoznak: C
I
A
Pre De Co 5. táblázat: CIA x PreDeCo mátrix A CIA x PreDeCo mátrix oszlopain, sorain, elemein szisztematikusan végighaladva könnyebb elkerülni, hogy valamirıl megfeledkezzünk, ugyanis a PreDeCo szemlélet nem engedi meg, hogy egy adott veszélyforrás esetén megelégedjünk például csupán preventív védekezés alkalmazásával. Túlzás nélkül elmondható, hogy korlátlan mennyiségő pénzt és erıforrásokat áldozhatunk egy veszély elhárítására, általában mindig marad valamekkora esélye annak, hogy a megelızı védelem ellenére a nem kívánt esemény bekövetkezik. Amennyiben csak a védekezésre koncentrálunk és nem készülünk fel arra, hogy ha esetleg mégis bekövetkezik a baj, akkor adott esetben az okozott kár könnyen továbbgyőrőzhet és a kockázatelemzésnél bemutatott módon a másodlagos-harmadlagos károk így óriásiak is lehetnek. A legtöbb esetben elmondható, hogy az eredı kockázatot úgy lehet (költségek szempontjából) a leghatékonyabban csökkenteni, ha a PreDeCo kontrollok egy jó egyensúlyát alkalmazzák. Egy jó példa a PreDeCo szemlélet alkalmazására egy cég WEB oldalát tartalmazó számítógép védelme. Az Interneten mára már elháríthatatlannak tőnı gyakorlattá vált, hogy automatikus hacker eszközök pásztázzák az IP végpontokat gyengén védett számítógépekre vadászva. Amennyiben egy számítógép különösebb védekezés nélkül kapcsolódik az Internetre, jó esélye van, hogy ezek az automatikus eszközök órákon belül rátalálnak és hogy napokon belül betörnek rá! A betörés a legtöbb esetben nem jár látható jelekkel. Az automatikus betörı programok a legtöbbször csak egy kiskaput nyitnak a rendszeren, amelyen a késıbbiekben ki-be járhatnak, illetve ritkább esetben a feltört gépet is felhasználják betöréseikhez (úgynevezett zombie-ként használják a feltört gépet, hogy ezzel álcázva magukat a betörés valódi forrása ne legyen visszakövethetı). Az „egyszerő” WEB oldalak általában nincsenek összekötve egy szervezet belsı rendszerével, csak úgymond információ forrással szolgálnak az ügyfelek felé. Az ilyen szerverek elleni támadások legtöbbször abban merülnek ki, hogy a WEB oldalakat lecserélik a támadás tényét hirdetı, az adott céget lejárató, ritkábban tiltakozó jellegő tartalomra (ezt a támadást hívják deface-nek). Annak ellenére, hogy tárgyiasult kárt még ezek a támadások sem
28./53
feltétlenül okoznak, a presztízs veszteség rendkívül komoly is lehet (különösképpen, ha a média felkapja a hírt). Akármennyire is védjük a szerverünket, az ügyes támadók csak nagyobb kihívásnak fogják tekinteni a feladatot és elıbb-utóbb be fognak törni a rendszerbe. Az üdvözítı megoldást a PreDeCo szemlélet alkalmazása jelentheti. Azaz minél hamarabb észlelni kell a támadás tényét – deface esetén azt, hogy a WEB oldalainkat módosították – és a lehetı leghamarabb el kell hárítani a támadás következményeit. Egy egyszerő módszerrel megoldható például, hogy a teljes WEB szervert tükrözzük és egy védett belsı hálózatról, ahová kívülrıl bejelentkezést nem engedünk, folyamatosan összehasonlítjuk az éles és a tükrözött szerver által adott válaszokat, és így ellenırizzük, hogy az éles WEB szerveren változik-e a tartalom. Egy betörés, amelynek érezhetı hatása is van így rendkívül hamar észlelhetı és a tükrözött szerverrıl az éles rendszer eredeti tartalma rövid idın belül visszatölthetı. Adott esetben egy ilyen gyors reakciónak még presztízsnövelı hatása is lehet, mondván, „annak ellenére, hogy megtámadták a rendszerünket, perceken belül elhárítottuk a támadást”2.
3.3
Zónarendszer
A védekezési módszerek tervezésénél egy másik alapmódszer a zónarendszer létrehozása és menedzselése. A zónarendszer alapja, hogy az informatikai rendszert az épületekhez hasonlóan területekre, zónákra osztjuk és az egyes zónákon belül, illetve a zónák határain különbözı védelmi szinteket határozunk meg. Ezzel a módszerrel lehetıvé válik, hogy a költségek optimalizálása céljából a nagyobb erısségő (és így jóval drágább) védelmi megoldásokat a valóban kiemelt zónában kelljen csak alkalmazni, illetve a zónák egymásba ágyazásával a kritikus rendszereknek egy természetesen fokozottabb védelmet biztosítsanak. A zónarendszer meghatározása tipikusan a Biztonságpolitika szintje, míg a zónák és azok védelmi szintjeinek kidolgozása tipikusan tapasztalt szakember feladata. Az egymásba ágyazott zónákat tipikusan a hozzáférhetıség szemszögébıl érdemes kialakítani. Például: •
Nyílt: bárki által hozzáférhetı terület, ügyfél fogadó iroda, illetve WEB oldalak.
•
Zárt: külsısök elıl zárt terület, csak belsı munkatársak, illetve engedéllyel rendelkezık részére.
•
Védett: csak zárt területrıl elérhetı, csak név alkalmazottak által elérhetı terület, pl.: számítóközpont.
3.4
szerint
engedélyezett
Biztonsági minısítések
A zónarendszerhez hasonló szemléletet követ a biztonsági minısítések rendszerére alapozott védelmi stratégia is. Ez a megoldás kevésbé a fizikai, területi felosztásra koncentrál, sokkal inkább logikai szempontból minısíti egy IT rendszer elemeit.
2
Mondhatja valaki, hogy ez a védelem sem kellıen jó, hiszen a támadó, ha egyszer betört, akkor a helyreállítás után újra be tud törni és így nem sokat érünk el. A gyakorlatban azonban nagyon rizikós többször egymás után ugyanoda betörni, iszen ha már várják a támadót, könnyebb azt lebuktatni, a forrást visszakövetni, illetve megismerve a támadó technikáját, kivédeni azt. Ha figyelembe vesszük, hogy ennek a megoldásnak a költségei hogyan viszonyulnak egy tőzfal, illetve egy behatolás felismerı rendszer (IDS) költségeihez és mennyivel hatásosabban csökkentik a kockázatot az okozott kár jelentıs korlátozásával, belátható, hogy az optimális megoldáshoz valóban célszerőbb a PreDeCo kontrollok együttes, kiegyensúlyozott alkalmazása.
29./53
Amennyiben a biztonsági minısítések rendszerét konzekvensen alkalmazzuk, a minısítésnek minden informatikai szempontból lényeges rendszerelemre ki kell terjednie: •
A rendszer által kezelt adatokra (mennyire érzékenyek egyes információk).
•
Az alkalmazói kezelnek).
•
Az alaprendszerekre (pl.: milyen rendelkezére-állást, illetve milyen fokú védelmet kell nyújtania az alaprendszernek).
•
Esetenként a felhasználók csoportjai is minısíthetıek (attól függıen, hogy milyen minısítéső adatokhoz férhetnek hozzá).
rendszerekre
(amelyek
különbözı
minısítéső
adatokat
A minısítési kategóriák felállításánál törekedni kell arra, hogy az irányelvek tiszták, könnyen érthetıek legyenek, mert csak ilyen esetben van esély arra, hogy a minısítési rendszeren alapuló védelmi megoldásokat a szervezeten belül tudatosítsuk és az egyes alkalmazottak valóban kövessék a rendszer iránymutatásait. Nem célszerő sok, csak apróságokban különbözı szintet bevezetni, mert csak a menedzselést nehezíti, illetve a tudatos alkalmazás ellen hat. Az információk bizalmasság szerinti kategorizálásának például egy felsı szintje tipikusan a következı: •
Nyilvános: olyan információk, amelyek bárkihez eljuthatnak, a cég reklámozza, kiadványaiban, illetve a WEB lapján feltünteti. Figyelni kell azonban arra, hogy ezen információk hitelességét is biztosítani kell.
•
Belsı: olyan információk, amelyeket nem hoz nyilvánosságra a cég, de titokban tartásukhoz méltányolható érdek nem főzıdik, illetve érdemben nem védik ıket. Ilyen információ lehet például a cég alkalmazottainak telefonszámai, az alkalmazott IT technológia, vagy az infrastruktúra nagysága. (Természetesen indokolt esetben e példa értékő információk titokban tartását is el lehet rendelni.)
•
Titkos: tipikusan a törvény által is meghatározott üzleti titok kategóriája, azaz „minden olyan tény, információ, megoldás vagy adat, amelynek titokban maradásához a jogosultnak méltányolható érdeke főzıdik”.
Általában a védett, azaz titkos információk körét további szintekre célszerő osztani a megkívánt védelem foka szerint: •
Alap minısítéső információ: eredendıen minden titkos információ ebbe a kategóriába sorolandó.
•
Fokozott minısítés: a cég mőködése szempontjából jelentıs információk.
•
Kiemelt minısítés: a legérzékenyebb, a cég szempontjából kritikus információk.
Ezek a minısítések (alap, fokozott, kiemelt) az adatokon túl a további IT rendszerelemre is átültethetıek, például az alkalmazói rendszerekre. Természetesen ekkor más értelmezést nyernek. A kritikus alkalmazói rendszernek kritériuma lehet például, hogy nagy összegő pénzügyi tranzakciókat kezel, vagy hogy több, mint 100 felhsználó használja a cégen belül. Ilyenkor is figyelni kell arra, hogy a fıbb irányelvek egységesek legyenek, az alkalmazottak megértsék a rendszer filozófiáját és könnyen megtanulják, tudatosítsák a vonatkozó szabályokat. Tipikusan a zónarendszer és a minısítési kategóriák azok, amelyeket a cégen belül az IT rendszeren túl az egyéb biztonsági osztályokkal is egyeztetni, egységesíteni célszerő (lásd 1. fejezet).
30./53
3.5
Humán biztonság
Egy szervezeten belül, illetve az informatikai rendszerben is tipikusan a belsı munkatársak jelentik a legtöbb veszélyt. Ennek kezelésére a humán veszélyeket szervezeti-, illetve Biztonságpolitikai szinten kell kezelni. Számos módszer, humánpolitikai védelmi intézkedéscsomag létezik annak biztosítására, hogy bizonyos belsı veszélyeket menedzselni lehessen. A következıkben néhány ilyen intézkedést mutatnunk be, annak érzékeltetésére, hogy milyen lehetıségek állnak rendelkezésre ezen a területen: Szerepkörök szétválasztása Talán a legkomolyabb humán veszélyforrást az hordozza, ha bizonyos kontrollálhatatlan szerepköröket személyi szinten nem választanak külön. Például, ha egy rendszer fejlesztıje és üzemeltetıje (rendszergazdája) ugyanaz, akkor szinte semmilyen mód nincs arra, hogy az ı tevékenységét ellenırizni, az általa elkövetett visszaéléseket felismerni lehessen. Ezért biztosítani kell – akár jelentıs kényelmetlenség árán is –, hogy az összeférhetetlen szerepköröket, funkciókat más személyek lássák el. Teljesítmény monitorozás Az alkalmazottak munkavégzési teljesítményének figyelése nem csak hatékonysági szempontból lényeges, hanem például ezen a téren egy jelentıs visszaesés intı jele lehet annak, hogy bizonyos magánéleti problémák miatt egy adott személy esetében megjelentek bizonyos kockázati tényezık. Ezeket a hatásokat idejében felismerve, segítségnyújtással a komolyabb problémák legtöbbször elkerülhetıek. Kötelezı szabadságolás, szerepkörök rotálása Az informatikai rendszerekre nézve komoly veszélyt jelent a személyi függıségek kialakulása, vagyis hogy bizonyos funkciókhoz csak egy bizonyos személy ért. Ez a helyzet a felderítetlen csalások lehetıségét, a zsarolási pozíciók kialakításának veszélyét, de a kritikus személy távozása esetén a mőködésben bekövetkezı fennakadás problémáját is magában hordozza. Személyek kritikussá válása ellen a kötelezı szabadságolás, helyettesítés, illetve nagyobb rendszerek esetében a szerepkörök rotálásának módszerével védekezhetünk. Üresíróasztal3 politika A tudatosságra és a rendre nevelés egyik leghatásosabb módszere az üresíróasztal politika megkövetelése. Azaz mindenkinek minden olyan dokumentumot, anyagot amelyekkel kapcsolatban a munkavégzést – akárcsak ideiglenesen – befejezte, illetve felfüggesztette, el kell pakolnia a tárolási helyére. Ebbe beleértendı az is, hogy a számítógépét, fiókját, szekrényét le-, illetve bezárja, még ha csak rövid idıre is távozik a helyérıl. Ez a módszer a véletlenül elıl hagyott titkos dokumentumok „betekintés” jellegő veszélyei ellen is jó kontrollnak bizonyul. A fent bemutatott humánpolitikai intézkedések jól példázzák azt, hogy milyen olyan irányelv jellegő védelmi intézkedések fogalmazhatóak meg szervezeti szinten, amelyek a biztonság tudatosítása irányába hatnak és amelyek e révén számos veszélyforrás kockázatát tudják jelentısen csökkenteni. Ezekkel a szervezeti költségvonzatuk nem megkérdıjelezhetetlen.
megoldásokkal minden esetben célszerő élni, mert jelentıs mégis jótékony hatásuk a biztonságra
3
Az üresíróasztal politikát egybeírjuk. Ezzel utalva arra, hogy ez alatt a fogalom alatt egy teljes filozófiát értünk és nem csak azt, hogy üresek az asztalok.
31./53
4 IT Biztonsági technikák Míg az elızıekben a Biztonságpolitika szintjén irányelv jelleggel megfogalmazott követelményeket és védelmi koncepciókat láttuk, ebben a fejezetben már a sokkal konkrétabb, az Informatikai Biztonsági Szabályzat (IBSZ) szintén alkalmazandó technikákat tekintjük át. Általában még az IBSZ sem tartalmaz teljesen konkrét, megvalósítás-szintő utasításokat, de az általa kijelölt technikák már egyértelmően kijelölik a védelmi intézkedés megvalósításának módját (pl.: az IBSZ a módszert igen, de az alkalmazott terméket nem határozza meg). A továbbiakban a leglényegesebb IT biztonságtechnikai módszereket fogjuk áttekinteni. Ezek a módszerek már letisztultak, alkalmazásuk mindennapi, egy-egy konkrét biztonsági problémát megfelelı szinten képesek megoldani. Az egyes biztonsági módszerek gyakorlati alkalmazása során azonban rendkívül sok probléma adódhat. Egy nem megfelelıen alkalmazott eljárás teljes egészében elveszítheti funkcióját. Például a legerısebb rejtjel algoritmus sem nyújt védelmet, ha a kódoláshoz szükséges kulcsokat nem biztonságosan kezelik. Minden biztonsági módszer esetében ezeket a problémákat, biztosítandó alapfeltételeket pontosan ismerni kell annak érdekében, hogy a védelem ne legyen megkerülhetı és így betöltse a kívánt funkcióját. Ezért gondoskodni kell róla, hogy a kivitelezésre megfelelı felkészültségő személyeket jelöljünk ki, illetve a kialakított rendszert szakértıkkel ellenıriztessük.
4.1
Felhasználók azonosítása
A számítógépek a külvilágról rendkívül kevés információval rendelkeznek, a felhasználót azonosítani így csak korlátozott módszerekkel tudják. Ezek a korlátozott módszerek pedig rendkívül sérülékenyek, gyakorlatilag bármelyik azonosítási alapmódszer bizonyos módszerekkel kikerülhetı. Az alap módszereket három fı terület szerint csoportosíthatjuk:
5. ábra: Azonosítási alapmódszerek csoportosítása Mivel az egyes azonosítási módszerek a gyakorlatban könnyen megtéveszthetıek, ezért úgy szokás fogalmazni, hogy egy biztonságos rendszereknek az azonosítás fenti háromszögébıl legalább két csúcsot, egymástól függetlenül4 kell alkalmaznia.
4
Ha ugyanis nem egymástól függetlenül alkalmazunk két azonosítási módszert (pl. a PIN kódot a bankkártya mágnescsíkján is tároljuk), akkor ahelyett, hogy a módszerek erısítenék inkább gyengíteni fogják egymást (a példában a kártya eltulajdonításával a PIN kód is megszerezhetı, illetve a PIN kód ismeretében hamis mágneskártya készíthetı).
32./53
Az azonosítás témakör másik nagy problémája, hogy a kényelmetlenségek elkerülése érdekében egy felhasználót csak egyszer – a rendszerbe bejelentkezéskor – szoktak azonosítani, és feltételezik, hogy anélkül nem hagyja el a bejelentkezés helyét, hogy a rendszerbıl ki ne lépne. A kilépés elmulasztása egyenértékő azzal, mintha valaki úgy menne el otthonról, hogy nyitva hagyná maga után a bejárati ajtót, azaz a bejelentkezett felhasználó jogaival ekkor bárki visszaélhet. Tapasztalatok alapján míg a bejárati ajtó bezárását az emberek ritkán felejtik el, a rendszerbıl való kijelentkezést sokan gyakran mellızik, így magára hagyott terminálok esetében egy idıkorlát (time-out) letelte után az automatikus lezárásról gondoskodni kell. Az egyes azonosítási módszerek alkalmazásánál további szempontokat is figyelembe kell venni, hogy minimálisra csökkentsük a megtévesztés, kikerülés lehetıségeit. A továbbiakban a fıbb módszerek buktatói közül emeljük ki a leglényegesebbeket.
4.1.1 Tudás, avagy jelszó alapú azonosítás Ezeknél a módszereknél a felhasználókat olyan információ alapján azonosítják, amit egyedül csak ık tudhatnak. A legegyszerőbb esetben ez lehet egy 4 számjegyő PINkód, de bonyolultabb esetben is csak egy hosszabb jelszó alapú azonosításra van általában mód. A módszerek gyengesége nyilvánvaló. Ha valamilyen módon a felhasználó által ismert információt bárki más is megtudja, akkor az egész védelem hatástalan. A jelszavak megszerezhetık, akár a billentyőleütések leolvasásával, akár jelszólopó trójai faló programokkal, de a bankkártyákhoz kötıdı PIN kódok is eltulajdoníthatók ál-terminálok segítségével. Ez utóbbi megoldás azt használja ki, hogy a felhasználó nem tudja és nem is tudhatja, hogy egy eszköz, amelynek megadja a titkos jelszavát megbízható-e vagy sem. Amennyiben egy eredeti mágneskártya és PIN-kód beolvasó terminált lecserélnek egy ál-készülékre, annak módjában áll mind a mágneskártya információját, mind a hozzá tartozó PIN-kódot feljegyezni, amellyel azután rosszindulatúan visszaélhetnek. Az ilyen jellegő jelszólopásokkal való visszaélés kockázatát egyedül a jelszavak gyakori cseréjével lehet valamelyest csökkenteni, ugyanis ilyenkor rövidebb idı áll rendelkezésre egy esetlegesen megszerzett jelszó felhasználására. Sok esetben azonban ez csak sovány vigaszt jelent. A jelszavak elıállítására alapvetıen két fı módszer képzelhetı el. Az egyik esetben a számítógép állítja elı valamilyen véletlen szám alapján, a másik esetben pedig a felhasználó maga találja ki. Az elsı esetben a felhasználó számára jelszó valamilyen értelmetlen karaktersorozat lesz, amelyet nehéz megjegyezni, ezért sokan papírra feljegyzik azt, alapvetıen aláásva ezzel a megoldás biztonságát. A másik esetben a felhasználók többsége valamilyen egyszerő módon képzi a jelszavakat (gyermekük nevébıl, születési idejébıl, becenevébıl, stb.), amely lehetıséget nyújt a próbálgatással való kitalálásukra. A felkészültebb behatolók kész szótárakkal rendelkeznek, amelyek a leggyakoribb jelszavakat tartalmazzák. A tapasztalat sajnos azt mutatja, hogy egy ilyen szótárazási technikával, még relatívan kevés (pl. 10.000) szót tartalmazó szótár esetén is, már a jelszavak rendkívül nagy száma (70-80%-a!) kitalálható. 10000-es nagyságrendő próbálkozás pedig a mai számítógépes kapacitások mellett nem jelent problémát. A kitalálási és egyéb technikák elkerülése végett egy jónak mondható jelszórendszernek legalább a következı követelményeket teljesítenie kell: •
Minimális jelszóhosszt (általában legalább 5 karaktert) kell megkövetelnie.
33./53
•
Kötelezıvé kell tennie minél nagyobb betőkészlet használatát (kis és nagybetők megkülönböztetése, valamint kötelezı jelleggel a jelszavaknak tartalmazniuk kell számot is).
•
Korlátoznia kell a jelszavakkal való kísérletezések számát (néhány – általában 3 – sikertelen próba után hosszabb idıre meg kell akadályoznia az újabb próbálkozásokat).
•
Nem juttathat vissza információt sikertelen próbálkozás esetén a jelszó jóságáról (például nem várakozhat tovább, ha a próba több karakterben tér el a jó jelszótól, mintha csak egy bető eltérés lenne).
•
A jelszavak cseréjét adott idıközönként kötelezıvé kell tennie (például havonta).
•
Korábban már használt jelszó jelszócsere után újra már ne legyen használható.
•
Rendelkeznie kell time-out funkcióval, azaz ha a felhasználó egy ideje (2-5 perce) inaktív, akkor fel kell tételeznie, hogy elhagyta a terminált, és a munka folytatásához az azonosítást, belépést újra el kell végeztetnie.
•
A jelszavakat egyirányú kódolással kell tárolnia, ahol a kódolt formából az eredeti jelszót nem lehet visszakövetkeztetni, annak érdekében, hogy még a rendszergazda se tudhassa meg más jelszavát.
4.1.2 Birtok, avagy kulcs alapú azonosítás A kulcs alapú azonosítás olyan tárgy alapján azonosít egy személyt, amely tárgy csak egy példányban létezik és az adott személy birtokában van. A módszer gyengesége abban áll, hogy az azonosítást szolgáló tárgyat, könnyő elveszíteni, ellopni, illetve egyszerőbb megoldásnál hamisítani. Az azonosító tárgyak többfélék lehetnek. Elsıdleges szerepük, hogy gépi módon könnyen kezelhetık, ám nehezen hamisíthatók legyenek. A könnyő kezelhetıségre több technikai megoldást is ismerünk: •
vonalkód,
•
lyukkártya,
•
mágneskártya,
•
chipkártya.
Ezek közül a vonalkód egyszerő fénymásolóval, a lyukkártya barkácsolással, a mágneskártya bárhol beszerezhetı író készülékkel hamisítható. A chipkártyáknak két fı változata van, a passzív és az aktív kártyák. A passzív kártyák írhatók-olvashatók is lehetnek, de nem képesek mőveletek végzésére, algoritmusok futtatására, így lényegében nem különböznek a mágneskártyáktól, vagyis ugyanúgy könnyen másolhatók, hamisíthatók. Magyarországon a telefonkártyák hamisítása kapcsán sajnos több példát is láthatunk erre. Az aktív chipkártyák azonban képesek rejtjel algoritmusok futtatására, így gyakorlatilag lehetetlenné teszik hamisításukat. Ezt a nyilvános kulcsú rejtjelezéshez használt egyirányú függvények használatával érik el. Az ilyen másolhatatlan, hamisíthatatlan chipkártyákat szokás a smarcard, vagy magyarul intelligens kártya elnevezéssel megkülönböztetni.
34./53
4.1.3 Biometriai azonosítás A biometria az ember valamilyen olyan egyedi jellemzıjét használja fel azonosításra, amely egyedi és gépileg is könnyen kezelhetı. Ilyen biometriai jellemzık például az ujjlenyomat, a hang, a szaruhártya érhálózata vagy éppen a fül alakja. A gyakorlatban a biometrikus azonosítási eljárások jelentik a legnagyobb biztonságot, de természetesen ennek megfelelıen az áruk is jóval magasabb. Ügyelni kell továbbá arra, hogy az egyszerőbb megoldások itt is könnyen kijátszhatók. Például ujjlenyomat ellenırzés esetén a kiszemelt személy ujjlenyomata könnyen megszerezhetı (például egy pohárról), aminek birtokában a bélyegzıkhöz hasonló gumi replika készíthetı a kívánt ujjról. Amennyiben az ujjlenyomat leolvasó berendezés nem képes az így készített mőujjat megkülönböztetni egy valódi, élı ujjtól, akkor könnyen kikerülhetıvé válik még ez a biometrikus azonosítási módszer is.
4.2
Logikai hozzáférés-védelem
Az emberi visszaélésekkel szembeni védekezés alap módszere, hogy az információkhoz való hozzáférést korlátozzuk, valamilyen módon a jogosultságokat ellenırizzük és biztosítjuk, hogy valóban csak az arra felhatalmazott személyek férhessenek hozzá bizalmas információkhoz. Hozzáférésen minden – az információval kapcsolatos – mővelet elvégzését értjük. Ezek a mőveletek általában a következık: olvasás, módosítás, létrehozás, törlés; de több megvalósítás ezeken az alap mőveleteken túl további hozzáférési módokat is megkülönböztet (például programok esetében futtatási jog). A hozzáférés-védelmekkel kapcsolatosan három fı problémakört említhetünk meg: •
hibamentes implementálás,
•
felhasználók azonosítása,
•
jogosultságok megadása.
Ha a jogosultsági rendszer megfelelıen le van fektetve, akkor technikailag annak eldöntése, hogy egy azonosított felhasználónak egy adott információhoz milyen mőveletek elvégzéséhez van joga, alapvetıen nem tőnik nehéz feladatnak. A probléma ott jelentkezik, hogy a mindig elıforduló programozási hibákból biztonsági lyukak keletkezhetnek, amelyek teszteléssel nehezen deríthetık ki. Így az ilyen és más biztonságtechnikai módszereknél a hibamentes implementálás nehezen teljesíthetı, pedig e nélkül a biztonság nem szavatolható. A felhasználók azonosítása a számítógépes rendszerekben azért jelent problémát, mert a gépek rendkívül kevés információval rendelkeznek a külvilágról. Szemléletesen szólva, egy számítógép egy lezárt dobozban kuksol, se nem lát, se nem hall, hozzá csak a billentyő lenyomásokból származó információk jutnak el. Ezért rendkívül nehéz megbizonyosodnia arról, hogy egy adott parancsot valóban a megfelelı felhasználó adott-e ki, vagy valaki csak megszemélyesítette ıt. A felhasználók azonosításainak módszereire az elızı fejezetben láthattunk példákat. Ha a felhasználókat megfelelıen azonosítottuk, a hozzáférés-védelmi rendszert hibamentesen implementáltuk, akkor is gondot okoz a jogosultságok beállításának, változtatásának biztonságos megoldása. Ez a probléma már nem is annyira technikai – hiszen elvben a jogosultság állítások is tetszılegesen jogkörökhöz rendelhetık – hanem sokkal inkább emberi kérdés. Alapvetıen kétféle szemlélet létezik. Az egyik esetben, ha valaki létrehoz egy információs egységet (dokumentumot), akkor az az ı tulajdona, ı rendelkezik róla, hogy ahhoz ki, milyen módon férhet hozzá. A másik szemlélet szerint pedig minden amit egy alkalmazott létrehoz, az a munkaadó
35./53
tulajdonát képezi, így a hozzáférési jogosultságok meghatározása nem a létrehozó személy, hanem egy központilag megbízott és felhatalmazott adminisztrátor joga.
4.2.1 Önkényes hozzáférés-védelem (DAC) Discretionary Access Control, önkényes hozzáférés kontroll. Tulajdonosi alapokon nyugvó hozzáférést szabályozó rendszer. Szemléletének megfelelıen mindenki szabadon, önkényesen rendelkezhet a saját tulajdonában lévı információkkal, azaz jogosultságait (például egy file írásához való jogát) szabadon továbbadhatja más felhasználóknak. Az ilyenfajta védelmek a trójai falovak és vírusok miatt nem nyújtanak megfelelı védelmet, mivel egy rosszindulatú program a felhasználó nevében eljárva annak jogait továbbörökítheti másokra, ezzel megkerülve mindenféle biztonsági intézkedést.
4.2.2 Kötelezı hozzáférés-védelem (MAC) Mandatory Access Control, kötelezı hozzáférés kontroll. A DAC rendszerrel ellentétben itt a biztonsági szabályokat, hozzáférési jogosultságokat néhány privilégiummal rendelkezı "rendszerfelügyelı" (supervisor, root, admin, ...) határozza meg. Az így felépített jogosultságrendszer betartása pedig mindenkire nézve kötelezı. Az ilyen rendszerek a trójai falovakból (egészen addig, amíg a rendszerfelügyelık a jogok állítását körültekintıen végzik) és a felhasználói tévedésekbıl adódó biztonsági veszélyeket kivédik.
4.2.3 Naplózás (audit) Egy szigorú biztonsági rendszerben a bejelentkezéseket, kijelentkezéseket, illetve a hozzáférési szempontból kritikus mőveleteket naplózni kell, az esetleges visszaélések vagy behatolási kísérletek felismerésének érdekében. A hitelesség biztosítása miatt a naplófile-nak magasabb biztonsági szinten kell elhelyezkednie, mint az adott felhasználónak, azaz a felhasználó a naplófile-t direkten ne változtathassa. Szigorú naplózásról beszélünk, ha egy mővelet elvégzésének szándékát még a mővelet végrehajtása elıtt biztonságosan naplózzuk. Ekkor nem fordulhat elı, hogy a számítógép elszállása, leállása miatt a napló bizonyos mőveletek vagy hozzáféréskísérletek feljegyzéseit nem tartalmazza. A naplózás védelmi szerepének betöltéséhez a létrejött napló állományokat rendszeresen ellenırizni kell, hogy az esetleges visszaélésekre valóban fény derüljön. Nagyobb rendszerek esetében ez az ellenırzési lépés rendkívül nagy (és valljuk be unalmas) terhet ró a rendszergazdákra, ami miatt gyakran mellızik elvégzését. Amennyiben a vezetés eltökélt a naplófile-ok rendszeres ellenırzésének megkövetelése mellett, akkor a végrehajtás felülvizsgálatát is célszerő folyamatosan biztosítani.
4.3
Biztonságos kommunikáció
Alapprobléma: két távoli fél biztonságosan szeretne információt cserélni. Kérdés mit nevezhetünk biztonságosnak? Látni fogjuk, hogy a biztonságos kommunikációnak több egymástól függetleníthetı összetevıje van. Rossz gyakorlat szerint sokan csak titkosításnak hívják a biztonságos kommunikáció megvalósítását. Ennek oka, hogy az alkalmazott rejtjelezési rendszerek általában a biztonságos kommunikáció problémáinak többségét megoldják így a rejtjelezés, a titkosítás, illetve a biztonság fogalmát sokan keverik.
36./53
A fogalmak egy részének tisztázását a "Bizalmasság"-ról szóló fejezetben már elkezdtük. A következıkben a biztonságos kommunikáció további követelményeinek megfogalmazásával, pontosításával fogunk foglalkozni. Látni fogjuk, hogy a biztonság több, egymástól akár függetleníthetı, néha pedig kifejezetten ellentétes követelményekre bontható. E követelmények meghatározása egy konkrét esetben ezért szakmai gondosságot igényel. Menedzsment szinten ezért fontos, hogy legalább a fıbb ismérvekkel tisztában legyünk. A követelmények fogalmi meghatározásával párhuzamosan minden esetben megvizsgáljuk azt is, hogy vajon az adott követelmény kielégíthetı-e, illetve milyen szinten elégíthetı ki. Mint a Biztonságpolitika fejezetben láttuk fontos, hogy menedzsment szinten tisztában legyünk azzal, hogy mely követelmények elégíthetıek ki, illetve, hogy a különbözı követelmények nagyságrendileg milyen nehézségek, milyen költségek árán teljesíthetıek. A kielégíthetıség kapcsán két fontos fogalmat szokás használni: •
Elméletileg biztonságos megoldás létezik, vagyis az adott követelmény matematikailag bizonyítható módon kielégíthetı.
•
Gyakorlatilag biztonságos megoldás létezik, ha a támadó esélyeit elıre rögzítve, tetszılegesen kicsi esélyhez is készíthetı olyan megoldás, amely esetén a támadó esélye ennél az elıre megadott tetszılegesen kis esélynél még kisebbé tehetı.
Mint látni fogjuk létezik elméletileg biztonságosan teljesíthetı követelmény is, de van olyan követelmény, amely esetén bizonyítható, hogy sajnos még gyakorlatilag biztonságos megoldás sem létezik. A teljesíthetıség ilyen értelmezése olyan ökölszabályokhoz vezet, amelyeket még vezetıi szinten is pontosan ismerni kell. Vegyük hát sorra követelményeket:
a
biztonságos
kommunikációval
szemben
támasztható
4.3.1 Biztonságosan nyugtázott üzenetküldés A biztonságos üzenetküldés alapvetı követelménye lehet, hogy meggyızıdjünk arról, hogy az elküldött üzenetet a másik fél sértetlenül megkapta, azaz az üzenettovábbítás biztonságosan nyugtázott legyen. Bár talán meglepı, de sajnos erre a problémára még a legegyszerőbb védelmi szintnek megfelelı megoldás sem adható. Bizánci probléma A nyugtázott üzenetküldés problémájára a szakirodalomban a Bizánci problémával szoktak hivatkozni. A történelmi példa alapján két szövetséges hadsereg két szemközti domb tetején foglal állást, míg az ellenség a völgyben helyezkedik el. Az ellenség olyan létszám fölényben van, hogy mindkét szövetséges haddal képes lenne elbánni külön-külön egymás után. Azonban ha a szövetségesek egyszerre tudnák két oldalról megtámadni a völgyben állomásozó ellenséget, akkor gyızelmet tudnának aratni felette. A két szövetséges hadvezérnek csak az ellenséges vonalakon átküldött futárokkal van módja üzenetet cserélni. A futárokat azonban elfoghatják, így nem biztos, hogy egy elküldött üzenet meg is érkezik. A kérdés: megoldható-e valamilyen módszerrel, hogy bármely futár elvesztésével a két szövetséges hadvezér úgy egyeztesse a támadás idıpontját, hogy biztos legyen benne, hogy a másik fél is támadni fog az egyeztetett idıpontban. Indirekt bizonyítással és teljes indukcióval egyszerően belátható, hogy ilyen megoldás nem létezik. Ugyanis ha feltételezzük, hogy véges n lépésben (n futár küldése után) egy megoldás eredményre vezet, akkor az n-ik lépésben küldött futárt
37./53
tekintve arra a következtetésre juthatunk, hogy már az (n-1)-ik lépésben is biztosnak kellett volna lennie a támadás idıpontjában a szövetséges hadvezéreknek. Hiszen aki az n-ik futárt küldte az már semmilyen információt nem vár, vagyis az (n-1)-ik lépésben is biztos volt a dolgában. A futárt fogadó fél pedig lehet, hogy nem kap további üzenetet, hiszen az n-ik futárt elfoghatják, vagyis neki is biztosnak kellett lennie a támadás idıpontját tekintve már (n-1)-ik lépésben. Az (n-1)-ik lépésre ugyanezt a gondolatmenetet alkalmazva véges lépésben ellentmondásra jutunk, ha feltesszük, hogy a hadvezérek elıre nem egyeztették a támadás idıpontját. Természetes, független üzenetvesztések Az elızı történelmi példa alapján láttuk, hogy tetszıleges (legrosszabb esetet feltételezı) üzenetvesztés esetén nem létezik olyan elméletileg biztonságos nyugtázott üzenet-továbbítás, amely során mindkét fél meggyızıdhet arról hogy egy egyeztetés sikeres volt. Azonban ha természetes, nem rosszindulatú üzenetvesztést tételezünk csak fel (valamilyen csatorna-zaj eredményeként), akkor egy-egy üzenet-továbbítás sikerességét valamilyen valószínőséggel jellemezhetjük. Ebben az esetben egy üzenetküldés biztonságos nyugtázását bármilyen elıre rögzített értéknél nagyobb valószínőséggel meg tudjuk oldani, vagyis a probléma gyakorlatilag biztonságosan megoldható. Rosszindulatú, intelligens üzenetelnyelés Más a helyzet azonban, ha rosszindulatú, intelligens emberi támadást tételezünk fel és a támadó az üzenet egyeztetés módszerét, protokollját is ismeri. Ebben az esetben a Bizánci problémánál látott bizonyítás alapján egy támadó bármely kifinomult protokoll esetén elnyelhet bizonyos üzeneteket úgy, hogy valamelyik felet kétségek között tartsa. Sajnos ebben az esetben sem elméleti sem gyakorlati értelemben vett biztonságos megoldás nem létezik!
4.3.2 Sértetlen üzenet-továbbítás Csatorna zajok és emberi manipuláció következtében egy továbbított jelsorozat torzulhat, megváltozhat a kommunikáció során. Alapvetı követelmény, hogy ilyen esetben is az átvitt információ ne sérüljön, illetve sérülés esetén annak tényét ki lehessen mutatni.
6. ábra: Üzenetek sérülésének modellje az üzenettérben Abban az esetben, ha a jeltérben az érvényes információ-tartalommal rendelkezı jelsorozatok elég ritkán, illetve egymástól megfelelıen távol helyezkednek el, akkor a véletlenszerő (nem rosszindulatú) jeltorzulások esetén a torzulás nagy valószínőséggel felfedezhetı, illetve "javítás a legközelebbi érvényeshez" elvet követve akár javítható is. A gyakorlatban a javítás és a hiba detektálást ötvözve
38./53
szokták használni, azaz ha kis javítással egy torzulás kompenzálható, akkor javítják míg nagyobb torzulás esetén hibajelzés és újraadás megoldását alkalmazzák. A hiba-detektáló és javító kódoknak megalapozott matematikai hátterük van. Erre itt nem térünk ki. Természetesen semmilyen esetben sem zárható ki annak lehetısége, hogy olyan csatorna-zaj (vagy emberi manipuláció) adódjon egy elküldött üzenethez, hogy az egy másik érvényes üzenetbe menjen át, így elméletileg biztonságos sértetlen üzenet-továbbítás nem valósítható meg. Amennyiben csak véletlenszerő csatorna-zajt tételezünk fel és a rosszindulatú emberi manipulálás lehetıségét kizárjuk, a jeltér kellı megnövelésével megoldható, hogy bármely elıre rögzített értéknél kisebb legyen annak valószínősége, hogy a csatorna-zaj hatására egy érvényes üzenet egy másik érvényes üzenetbe menjen át, azaz gyakorlatilag biztonságosan megoldható a sértetlen üzenet-továbbítás.
4.3.3 Hiteles üzenet-továbbítás A sértetlen üzenet-továbbításnak emberi manipuláció ellen védı követelményét akkor tudjuk biztosítani, ha a vevı fél biztos lehet benne, hogy az üzenetet a kívánt fél küldte és harmadik fél nem állíthatta azt elı. Az ilyen üzenet-továbbítást, amikor egy továbbított üzenet tartalma és küldıjének sértetlensége garantálható hitelesnek nevezzük. Mivel a hitelesség része a sértetlen üzenet-továbbításnak és ott láttuk, hogy elméletileg biztonságos megoldás a problémára nem létezik, ezért a hitelesség sem oldható meg elméletileg biztonságosan. A gyakorlatban hogyan oldható meg, hogy egy harmadik rosszindulatú fél az elküldött üzenetet ne vihesse át egy másik érvényes üzenetbe? A megoldás egyszerő: az érvényes üzeneteket titokban kell tartani (azt csak a küldı és a vevı ismerje) így még egy intelligens támadó is csak véletlenszerően képes találgatni az érvényes üzenetekre. Ha a jeltér kellıen nagy, akkor annak valószínősége, hogy a támadó beletalál egy érvényes üzenetbe tetszılegesen kicsivé tehetı. Így a hiteles üzenet-továbbítás gyakorlatilag biztonságosan megoldható.
7. ábra: Érvényes üzenetek elrejtése a hitelesség biztosítása érdekében A hitelesség biztosítására a gyakorlatban MAC (message authentication code, szokás még szimmetrikus aláírásnak is nevezni) illetve a digitális aláírás módszerei alkalmazhatóak.
4.3.4 Bizalmas üzenet-továbbítás A bizalmas vagy titkos üzenet-továbbítás követelménye azt jelenti, hogy az adón és a vevın kívül más harmadik fél a továbbított jelsorozatból a továbbított információt megérteni ne legyen képes. Ezt a funkciót a gyakorlatban a rejtjelezés valósítja meg.
39./53
Ekkor a továbbítani kívánt információt olyan kódsorozattal írják le, amely a kód ismerete nélkül nem vagy csak nagyon nehezen fejthetı meg. A ma elfogadott felfogás szerint a rejtjelezéshez használt algoritmust nem tekintik titkosnak, hanem az algoritmus végrehajtása során alkalmaznak egy titkos bitsorozatot, kulcsot amely ismerete nélkül a kódolt szöveg nem érthetı. Shannon-féle tökéletes titkosító Tökéletes rejtjelezésnek nevezzük azt a megoldást, amely során a kulcs ismerete nélkül a kódolt szövegbıl a továbbított információra elméletileg sem lehet következtetni. Az információ-elmélet kidolgozója, Shannon tiszteletére az ilyen rejtjelezı algoritmusokat nevezzük Shannon-féle tökéletes titkosítónak. Könnyen belátható, hogy ilyen rejtjelezı algoritmus készíthetı. Vegyük például a bitenkénti kizáró vagy mőveletet. Amennyiben a XOR mővelet minden bitjét 50-50%ban véletlenszerően, egymástól függetlenül választjuk meg és sehol máshol sem használjuk fel (azaz titokban tartjuk), akkor az így végzett kódolás eredményeképpen a kódolt szöveg és a nyílt információ között nem lesz összefüggés. Ha a kódolt szövegben például 0 áll, akkor a nyílt szövegben 50-50% valószínőséggel lesz 0 vagy 1, illetve fordítva ha a kódolt szövegben 1 áll, akkor a nyílt szövegben ugyanúgy 50-50% valószínőséggel lesz 0 vagy 1, azaz a nyílt szövegre nem lehet következtetni a kulcs ismerete nélkül. A szakirodalom az ilyen rejtjelezıt One-time pad-nek hívja utalva rá, hogy a kulcsot szigorúan csak egyszer szabad felhasználni. Az ilyen tökéletes titkosítóknak azonban van egy nagy hátrányuk. Az információ elmélet matematikai apparátusával könnyen belátható, hogy tökéletes titkosító csak akkor készíthetı, ha magának a kulcsnak az információ tartalma nagyobb, mint az átvinni kívánt adatok információ tartalma (Shannon-tétel). Szemléletesen szólva a kulcs összesőrített hossza mindig nagyobb, mint az átvitt adatok összesőrített hossza. Mivel a kulcsot a két kommunikáló fél között titkos csatornán megbízhatóan kell átvinni, ez gyakorlatilag egyenértékő feladat magának az információnak a titkos továbbításával. Így a tökéletes titkosítókat csak olyan rendkívül nagy biztonságot igénylı esetekben szokták alkalmazni, ahol lehetıség van a nagy mérető kulcs titkos továbbítására a kommunikáció elıtt, és a kulcs felhasználásra, a tényleges kommunikáció lefolytatására csak valamikor késıbb kerül sor. (Tipikus megoldás például két véletlen számokkal teleírt CD, amelyeket egy-egy tőzfalba helyezve 600700 MB adat tökéletes rejtjelezéssel történı átvitelére nyílik lehetıség.) Gyakorlati rejtjelezık Bár érdekes elméleti tény a tökéletes rejtjelezı létezése a gyakorlatban olyan megoldásokra van szükség, ahol a titokban átvitt információ mennyisége csekély és egy alkalmazott kulcs többször is felhasználható. A gyakorlati rejtjelezıvel szemben támasztott követelmény ennek megfelelıen így módosul: gyakorlati erıs rejtjelezésnek nevezzük azt a megoldást, amely során a kulcs ismerete nélkül a kódolt szövegbıl a továbbított információra csak kivitelezhetetlenül sok számítás eredményével lehet számottevı valószínőséggel következtetni. Ez a definíció nem zárja ki annak lehetıségét, hogy valaki véletlenül akár kevés számítással is megfejtse a kódolt szöveget, de ennek valószínőségének rendkívül kicsinek kell lennie. A gyakorlatban egy egész tudományág foglalkozik többször-használatos, rövid kulcsokkal mőködı, gyors és mégis erıs kódolást megvalósító rejtjelezı algoritmusokkal.
40./53
Összefoglalva megállapíthatjuk, hogy elméletileg biztonságos és gyakorlatilag biztonságos megoldás is létezik titkos üzenet-továbbításra.
4.3.5 Távoli azonosítás A nyílt hálózatokon, az Interneten szükség lehet arra is, hogy két olyan fél kezdeményezzen kommunikációt, akik még sohasem találkoztak (és meglehet sohasem fognak találkozni) személyesen, közvetlenül titkos információt nem cserélnek és mégis biztonságosan szeretnék egymást azonosítani. Ennek megoldását hívjuk távoli azonosításnak. Ismeretlen személyek csak úgy képesek egymást azonosítani, ha van valamilyen harmadik fél, aki bemutatja ıket egymásnak. A kérdés azonban felvetıdik: Hogyan találunk olyan személyt, aki ismeri mindkét felet? Ha ilyet nem találunk, akkor olyasvalakire van szükség, aki megbízható és ismer olyat, aki ismeri a másik felet és így tovább. Az ismeretségek ilyen láncolatában eljutunk oda, hogy valamilyen 0. lépésben elfogadunk valamilyen információt, alap tényt, amely a virtuális és a valós világban is egyezik és erre a biztos alapra támaszkodva építjük fel a virtuális világot a valós világ mintájára. (Ezt szokás a 0. lépés problémájának is hívni.) Filozófia magasságokba repít annak a kérdésnek a vizsgálata, hogy a valóságban mi az az alap amelybe az emberek kapaszkodhatnak, és amelyre hitüket, világnézetüket felépíthetik. Nem adható ugyanis olyan támpont amely alapján elméletileg biztonságosan lehetne a virtuális világban távolról azonosítani kommunikáló feleket. Gyakorlati megoldás azonban létezik: az Interneten elterjedt nyilvános kulcsú infrastruktúra (PKI – public key infrastructure) például nyújt olyan szolgáltatást, amelyben hitelesítı központok (CA-k – certification authority-k) elektronikus igazolványokat bocsátanak ki, amelyek egy-egy valós vagy jogi személyt és a birtokában lévı rejtjelkulcsot rendelik össze, így lehetıvé téve, hogy ismeretlen személyek is erıs rejtjelezésen alapulva igazolják magukat egymás elıtt.
4.3.6 Letagadhatatlanság Az elızıekben tárgyalt hiteles üzenet-továbbítás mindössze azt foglalta magában, hogy a vevı megbizonyosodhat arról, hogy az adott üzenet hitelt érdemlıen a feltéttelezett küldıtıl érkezett. Szükség lehet azonban számos esetben arra, hogy a vevı harmadik fél felé is igazolni tudja, hogy egy bizonyos dokumentum hitelt érdemlıen a feltételezett szerzıtıl származik. Tipikus példa erre egy Interneten keresztüli megrendelés, ahol vitás esetben az kereskedınek akár bíróság elıtt is igazolnia kell tudnia, hogy a feltételezett vevıtıl megrendelést kapott, azt teljesítette, így jogosan igényli a fizetséget. Ebben az esetben a hiteles üzenet-továbbításnál látott megoldás önmagában még nem elég, hiszen ha mindkét fél ismeri az érvényes üzenetek körét, akkor bármelyikük képes érvényes, így hitelesnek tőnı dokumentumokat elıállítani, egymásra semmit sem tudnak rábizonyítani. A kriptográfia talán legnagyobb eredménye, a nyilvános kulcsú rejtjelezés jelent megoldást erre a problémára. A nyilvános kulcsú rejtjelezés alapja egy két kulcsos algoritmus, ahol az egyik kulcs titkos, míg a másik nyilvánosságra hozható. A kulcsok egymásnak inverzei, azaz a titkos kulccsal kódolt információ csak a nyilvános párjával kódolható ki, és fordítva a nyilvános kulccsal kódolt információ csak a titkos párjával kódolható ki. Bár a kulcsok egyértelmően egymáshoz vannak rendelve mégsem lehetséges a nyilvános kulcsból a titkos kulcsot meghatározni.
41./53
Így ha valaki a titkos kulcsával kódol, aláír egy dokumentumot, azt kikódolni, az aláírást ellenırizni a nyilvános kulcs birtokában bárki képes, meghamisítani az így elıállított dokumentumot azonban nem lehet. Mivel a letagadhatatlanság a hitelesség része, ezért biztosítására elméletileg biztonságos megoldás nem létezik, azonban gyakorlatilag biztonságos megoldás a nyilvános kulcsú kriptográfia alkalmazásával létezik.
4.3.7 Összefoglalás A biztonságos kommunikáció egyes követelményeit és megvalósítási lehetıségeit a következıkben foglalhatjuk össze:
Elméletileg Gyakorlatilag biztonságos biztonságos Indoklás (emlékeztetı) megoldás megoldás
Követelmény Biztonságosan nyugtázott üzenetküldés
Bizánci probléma, indirekt teljes indukciós bizonyítás
Természetes, független üzenetvesztések
NINCS
VAN
Rosszindulatú, intelligens üzenetelnyelés
NINCS
NINCS
minden protokoll kijátszható
NINCS
VAN
érvényes üzenetbe torzulás; hibadetektáló / javító kódok
NINCS
VAN
sértetlenség érvényes eltitkolása
VAN
VAN
Shannon-féle tökéletes titkosító, Shannon-tétel
Távoli azonosítás
NINCS
VAN
0. lépés nyilvános infrastruktúra
Letagadhatatlanság
NINCS
VAN
hitelesség része; nyilvános kulcsú rejtjelezés
Sértetlen továbbítás
üzenet-
Hiteles továbbítás
üzenet-
Bizalmas továbbítás
üzenet-
valószínőségi alapon
része; üzenetek
problémája, kulcsú
6. táblázat: Biztonságos kommunikáció követelményei és a követelmények kielégíthetısége
42./53
4.4
Rendelkezésre állás menedzsment
Az informatikai rendszerek folyamatos mőködése ma már létfeltétele minden gazdasági szervezetnek. Ezen elvárás biztosítása azonban technikai szempontból nem könnyő feladat. Elkerülhetetlenek a meghibásodások, az elıre nem várt eseményekbıl származó leállások. A fennakadásokat tehát megfelelıen menedzselni kell. Pontosan kell ismerni, hogy nekkora mértékő leállást milyen módon lehet kezelni és fontos, hogy a valóban technikai szinten biztosított rendelkezésre-állással szemben milyen követelményeket támasszunk, ugyanis a megvalósítás költsége rendkívüli mértékben függ az elvárásoktól. A biztonságtechnika többi területéhez képest a rendelkezésre-állással szemben támasztott követelményeket objektív paraméterekkel meg lehet határozni. Az egyes követelményi szintek biztosításához azonban jelentısen eltérı struktúra szükséges, a komolyabb követelményeket kielégítı architektúrák pedig nagyságrendi különbségeket eredményeznek a költségek tekintetében. Ezért a rendelkezésre-állás menedzseléséhez a követelmények jó meghatározását és az elvárások biztosításának alapvetı, architekturális megoldásait is ismerni kell.
4.4.1 Megbízhatóság jellemzık A 3.1.3 "Rendelkezésre-állás követelményei" fejezetben már a leglényegesebb megbízhatósági paraméterekkel már megismerkedtünk: •
Az üzemidı x<óra> alakban határozta meg, hogy a rendszernek egy héten hány napot, egy nap hány órát kell mőködnie.
•
A rendelkezésre-állási tényezı 99.9...% alakban – a kilencesek számával megadva – a helyes mőködés arányát határozta meg nagy átlagban az üzemidın belül.
•
A sebezhetıségi ablak pedig azon legnagyobb kiesési idıre tesz korlátozást, amely alatt még komolyabb hiba, katasztrófa-helyzet esetén is újra kell tudni indítani a rendszert annak érdekében, hogy helyrehozhatatlan, elviselhetetlen károk ne származzanak az informatikai rendszer leállásából.
Annak érdekében, hogy ezeket a leglényegesebb paramétereket meg tudjuk határozni számos további megbízhatósági jellemzıt is használni szoktak egy rendszer vagy éppenséggel egy eszköz megbízhatóságának leírására. A legegyszerőbb hibamodell esetén csak azt vizsgáljuk, hogy egy eszköz vagy rendszer jól mőködik-e avagy nem jól mőködik. Azaz pusztán két állapotot kezelünk, és átmeneti (pl. kis hibás, idınként inkonzisztens) mőködést nem fogadjuk el "félmőködésnek". Ekkor egy rendszer legáltalánosabban az úgynevezett megbízhatósági függvénnyel (R(t)) jellemezhetı, amely az idı függvényében megadja, hogy mekkora annak valószínősége, hogy az adott rendszer, illetve eszköz az adott idıpontig egyszer sem hibásodik meg, azaz jól mőködik. Az R(t) függvény ennek megfelelıen egy szigorúan monoton csökkentı függvény. A megbízhatósági függvénnyel analóg módon az F(t)=1-R(t) meghibásodási függvényt is szokták alkalmazni, amely annak valószínőségét adja, meg, hogy az adott t idıpontig a rendszer meghibásodik.
43./53
valószínőség 100%
F(t)
R(t)
idı
8. ábra: Megbízhatósági R(t) és meghibásodási F(t) függvények Annak érdekében, hogy a fenti függvények monoton viselkedését szemléletesebbé tegyük a meghibásodás intenzitását (az elsı deriváltat) is vizsgálni célszerő az idı függvényében. A lambda (λ) paraméter formálisan a következıképpen definiált:
λ (t ) =
dF (t ) dt dR(t ) dt =− 1 − F (t ) R(t )
Amennyiben a meghibásodás intenzitását az idı függvényében ábrázoljuk egy jellemzı kádgörbét kapunk:
lambda
λ(t)
beégetési szakasz
mőködési tartomány (véletlen hibák)
elöregedés
idı
9. ábra: Meghibásodási intenzitás tipikus kádgörbe alakja Az eszközök, de a rendszerek nagy részére is igaz, hogy a beüzemelést követıen jóval gyakrabban fordulnak elı hibák – ezt az idıszakot szokás beégetési szakasznak hívni – majd egy hosszabb-rövidebb ideig a véletlen hibák dominálnak, amelyek nagyjából egyenletes eloszlással jelentenek meghibásodást, míg egy bizonyos idı elteltével az eszköz elöregszik és egyre nagyobb valószínőséggel lépnek fel problémák. Egy informaitkai eszköz esetében a beégetési szakaszon célszerő túljutni addig, amíg a rendszer üzemelése nem kritikus. Az IT eszközök esetében pedig az is elmondható, hogy az erkölcsi elöregedés általában gyorsabb, mint a fizikai
44./53
elöregedés és így a fejlettebb technológiájú eszközre való csere kiküszöböli az elöregedés hatását. A mőködési tartományban így a meghibásodás intenzitása nagyjából állandó λ=λ(t), ami örökifjú, exponenciális meghibásodási eloszlási függvényt eredményez:. R (t ) = e − λt Az exponenciális eloszlásfüggvénnyel számolni is könnyő, hiszen az átlaga is könnyen meghatározható a lambda reciprokával: E(R(t))=1/λ. Az R(t), F(t) illetve λ(t) függvények segítségével egy összetett rendszer esetén is pontosan meg lehet határozni, hogy mekkora annak valószínősége, hogy egy adott idıpontig a rendszer jól mőködik. Sok esetben azonban kevésbé a mőködés idıbeli lefolyása érdekes, hanem az átlagos jellemzık használata a célravezetıbb. A szokásos statisztikai jellemzık meghatározását a következı ábra szemlélteti:
jó
nem jó MTFF
MTTR
MTTF
MTBF
idı
10. ábra: Átlagos megbízhatósági jellemzık Az egyes paraméterek definitív jelentése: •
MTTF (Mean Time to First Failure): Az elsı meghibásodásig eltelt átlagos idı. A beüzemelési, beégetési szakasz lekezelésétıl függıen értéke nagyobb, de hibatőrı struktúrák esetén akár kisebb is lehet, mint a további meghibásodások között eltelt idı áltaga.
•
MTTR (Mean Time to Repair): Javítás átlagos ideje. Ez az érték tipikusan nem az adott eszköztıl, sokkal inkább a hozzá nyujtott szolgáltatásoktól függ.
•
MTTF (Mean Time to Failure): Meghibásodásig eltelt várható idı, avagy a helyes mőködés várható ideje. Tapasztalati értékek szerint az MTFF és az MTTF gyakran eltérnek egymástól, míg a késıbbi 2-ik, 3-ik, 4-ik meghibásodások között eltelt idık átlaga nagyjából azonos mértékő.
•
MTBF (Mean Time Between Failures): Meghibásodások között eltelt várható idı, azaz MTBF=MTFF+MTTR. Gyakorlatilag a rendszer "ciklus idejét" határozza meg. (Egyes gyártók eszközeik esetén nem az MTFF, hanem az MTBF értéket szokták megadni, mint a megbízhatóság mértékét, beleértve a szervízelés idejét is.)
Ezen paraméterek segítségével például a rendelkezésre-állási tényezı (A) többféleképpen kifejezhetı:
1 A=
MTTF MTTF 1 λ = = = MTBF MTTR + MTTF 1 + MTTR 1 + λ ∗ MTTR
λ
A fenti jellemzık értékeit tipikusan órában szokás megadni. Sokszor élnek a nagyságrendi kerekítés eszközeivel is. Így például a 10 000 órás MTTF nagyjából 1 év áltagos helyes mőködést jelent (ami gyakorlatilag azonos a λ=0.0001 paraméterrel). Hasonló nagyságrendi megfogalmazás, hogy a 4 9-es rendelkezésre állási tényezı (A=99,99%) körülbelül egy éven belül 1 óra állást enged meg. Ezekkel
45./53
a nagyságrendekkel és a különbözı követelmények által támasztott elvárások kielégítésének lehetıségeivel a rendelkezésre-állást menedzselı vezetınek tisztában kell lennie.
4.4.2 Hibatőrı struktúrák A megbízhatósági jellemzıkön eredendıen úgy lehet javítani, hogy megbízhatóbb, márkásabb eszközöket vásárolunk. Azonban egy határon túl így sem fokozható egy rendszer megbízhatósága. Ilyenkor struktúra szintjén kell kezelni a problémát. A következıkben a legjelentısebb hibatőrı struktúrákat fogjuk áttekinteni, annak érdekében, hogy lássuk milyen általános módszerek léteznek még kevésbé megbízhatóbb eszközökbıl is nagyobb rendelkezésre-állási paraméterekkel rendszelkezı rendszer létrehozására. Watchdog (WD) A legegyszerőbb, mégis rendkívül hatékony megoldás az úgynevezett watchdog (örzı kutya) alkalmazása. A watchdog elvárja, hogy egy rendszer amíg helyesen mőködik, megadott idıközönként küldjön számára ellenırzı szignált. Ezt a jelzést szokás "I'm alive" (életjel) üzenetnek is nevezni. Amennyiben a watchdog egy adott idıkorlát letelte után sem kap életjelet a rendszertıl, feltételezi, hogy valamilyen hiba lépett fel és újraindítja (reseteli) a rendszert. WD
reset
I'm alive
IN
CPU
OUT
11. ábra: Watchdog Ezzel a megoldással az átmeneti jellegő hibák gyorsan, hatékonyan kezelhetıek. Sıt nem csak hardver hanem szoftver hibák esetén is hatásos lehet az esetleges leállás után az automatikus újraindítás. Természetesen ez a megoldás permanens hibák elhárítására nem alkalmas, de ekkor is detektálhatja, hogy többszöri újraindításra sem tér magához a rendszer és riaszthatja a kezelıket. Vegyük észre, hogy ez a megoldás a hibák bekövetkezését nem befolyásolja (a watchdog tipikusan nagyon egyszerő eszköz, ritkán romlik el) MTFFWD=MTFF1, de a javítás idejét az esetek nagy részében jelentısen csökkenteni képes (MTTRWD<<MTTR1), így az eredı rendelkezésre-állási tényezı jelentısen javulhat (AWD>>A1). A watchdog tipikus alkalmazási területe a magára hagyott rendszerek felügyelete. Például lift-vezérlı, hőtıgép, mobil telefon, de tipikusan ebbe a körbe tartoznak az informatikai hálózati eszközök: routerek, gateway-ek is. Watchdog Processor (WDP) A watchdog továbbfejlesztett változataként fogható fel a watchdog processor. Ez már nem csak egy egyszerő életjelet vár a felügyelt rendszertıl, hanem képes annak belsı mőködésébe is belelátni. A WDP olyan lappangó hibákat is képes felismerni,
46./53
amelyek még nem okozzák a rendszer leállását – így az életjel üzenetek elmaradását – de már hibás mőködéshez vezetnek. Míg a watchdog egyszerő, gyakorlatilag bárhol alkalmazható univerzális eszköz, addig a watchdog processor egyedi, sıt sok esetben alkalmazásfüggı megoldás. Ezért drága és csak olyan helyen alkalmazzák, ahol a lappangó hibával mőködı rendszer veszélye, a hibás mőködés következménye nagyon súlyos is lehet (pl. atomerımő vezérlése). WDP
reset
state
IN
OUT
CPU
12. ábra: Watchdog processor Mivel a watchdog processor is egy komplex eszköz, meghibásodási valószínősége már összemérhetı lehet a felügyelt rendszerrel, aminek következtében azzal is számolni kell, hogy a WDP meghibásodik. Így az eredı áltagos meghibásodási jellemzıkbe az általa jelentett tényezıt is bele kell számolni, vagyis romolhat a rendszer MTTF jellemzıje (MTTFWDP≤MTTF1). Természetesen a gyors hibadetektálás, illetve az automatikus ujraindítás ebben az esetben is az áltagos javítási idı drasztikus csökkenésével jár (MTTRWDP<<MTTR1), így a rendelkezésre állási paraméter is sokkal jobb lesz, mint egy felügyelet nélküli rendszernél (AWDP>>A1). Mater-checker (MC) A legszorosabb felügyeletet a master-checker megoldás jelenti. Ebben az esetben egy, a felügyelt rendszerrel (master) teljesen azonos, azzal szinkronban mőködı ellenırzı rendszert (checker) alkalmazunk. Ez az ellenırzı rendszer ugyanazt a bemenetet kapja, mint az éles párja, majd az elıállított kimenet összehasonlításával a legkisebb eltérést is észre tudja venni.
CHECKER
IN
MASTER
=
OUT
13. ábra: Master-checker
47./53
GO/ NO GO
Ez az architektúra minden hardver hibát, eltérést képes kimutatni, de ezzel egyidejőleg elveszti azon képességét, hogy a szoftver hibákat is detektálni tudja. Másik hátulütıje, hogy a két eszköz bármelyikének meghibásodása a rendszer leállásához vezet és mivel a checker azonos meghibásodási jellemzıkkel rendelkezik, mint a master, gyakorlatilag kétszer akkora valószínőséggel hibásodik meg ez a struktúra, mintha a master csak magában mőködne: MTTFMC=MTTF1/2. Ennek kapcsán vegyük észre, hogy a redundancia nem nagyobb, hanem kisebb megbízhatóságot jelent! Ezért körültekintéssel kell eljárni redundáns architektúrák tervezésénél, ugyanis könnyen elıfordulhat, hogy a költségesebb megoldás nemhogy javít, de jelentısen ront az adott rendszer megbízhatósági jellemzıin. A watchdog-processoros megoldáshoz képest a master-checker elınye, hogy univerzális megoldás, gyakorlatilag bármilyen komplexitású eszköznél, rendszernél alkalmazható, amennyiben biztosítható, hogy a master és a checker teljes szinkronban mőködjenek. Például a Pentium processzorok minden átalakítás nélkül master-checker elrendezésbe köthetık. (Amikor a processzorok olvasnak a buszról, mindkét eszköz olvas, amikor a master ír, akkor a checker összehasonlítja a saját eredményét a master által a busra írt eredménnyel.) Többszörözött szavazásos rendszer (TMR) A master-checker megoldás továbbvitelével megoldható az, hogy nem csak kettı, hanem több eszközt is mőködtetünk párhuzamosan. A helyes kimenetet pedig szavazásos módszerrel határozzuk meg. Ekkor egy eszköz meghibásodása még nem jelenti a rendszer leállását.
1. CPU
IN
2. CPU
vote
OUT
3. CPU
14. ábra: Többségi szavazásos rendszer (TMR) A master-checkerhez hasonlóan ez a megoldás sem detektálja a szoftver hibákból származó hatásokat (ha a hardver mőködik megfelelıen), és a statisztikai megbízhatósági jellemzık tekintetében sem túlzottan jó (MTTFTMR=MTTF1*5/6)5. A TMR nagy elınye, hogy egy rövid ideig a megbízhatósági függvénye (R(t)) jóval nagyobb, mint a szimpla rendszeré. Így olyan, úgynevezett missziós rendszerekben, ahol a cél, hogy egy adott ideig nagy valószínőséggel mőködjön a rendszer, ez a megoldás kifejezetten üdvözítı lehet. Ilyen alkalmazási terület például egy mőholdak kísérleti útjai, ahol javításra nincs mód és mégis fontos, hogy a kitőzött cél eléréséig, küldetés teljesítéséig mőködıképes maradjon. 5
1/3 MTTF1 idı telik el várhatóan az elsı-, 1/2 MTTF1 a második meghibásodásig, így 1/3+1/2=5/6 az eredı.
48./53
Amennyiben nem magára hagyott rendszerrıl beszélünk és a kezelık az elsı, még kezelhetı, hiba fellépésekor rövid idın belül kicserélik, megjavítják a hibás elemet, akkor az elsı – felhasználók számára is érezhetı – meghibásodásig eltelt idı rendkívül nagyjá tehetı: MTTF*TMR=MTTF1*MTTF1/MTTR1) Tandem struktúra A master-checker és a TMR rendszer alapján látható, hogy hiába növeljük a redundanciát, az eredı rendszer megbízhatósága nem javul, kizárólag a gyors szervízeléssel tudunk javítani a mutatókon. A rendundancia további növelésére mutat példát a Tandem rendszer, ahol teljes a duplikáció, azaz minden, még az adatbusz is duplikálva van. A duplikáláson felül minden rendszerelemnek úgynevezett önellenırzı funkcióval kell rendelkeznie, azaz meg kell tudnia mondani, hogy az általa elıállított kimenet szerinte jó vagy sem. (Mint láttuk tetszıleges eszközbıl master-checker elrendezéssel készíthetı ilyen önellenırzı áramkör, bizonyos esetekben pedig – például a memóriánál, ahol hibadetektáló kódok is alkalmazhatóak – sokkal hatékonyabb megoldások is léteznek az önellenırzı funkció megvalósítására.) BUS
GO/ NO GO
IN
OUT
GO/ NO GO
GO/ NO GO
IN
ÖÁ
GO/ NO GO
IN
OUT
GO/ NO GO
OUT
GO/ NO GO
ÖÁ
OUT
GO/ NO GO
GO/ NO GO
IN
BUS
15. ábra: Tandem struktúra - minden elem diplikált és önellenırzı Az így felépített rendszerben tetszılegesen skálázható a redundancia mértéke, a meghibásodott elemek modulárisan cserélhetık, javíthatóak, azonban ez a megoldás rendkívül drága és csak a legmagasabb követelményeknek megfelelni kívánó rendszer esetében kifizetıdı. Hibatőrı struktúra választása Mint a fenti példák mutatják nem egyértelmő, hogy egy adott esetben milyen hibatőrı struktúrát célszerő alkalmazni. A nem megfelelıen alkalmazott redundancia akár ronthat is egy rendszer megbízhatósági jellemzıin. Egy ökölszabály azonban kijelenthetı, hogy egy, már létrehozott hibatőrı rendszer esetében a jó mőködés várható ideje gyakorlatilag a javítás idejétıl függ, fordított arányban. Ezért bármilyen megoldást is alkalmazzunk, rendkívül fontos megszervezni, hogy egy esetleges probléma elhárítása a lehetı leggyorsabb legyen.
4.4.3 RAID adattárolás Az elızı hibatőrı struktúrák esetében általános rendszerek, eszközök esetén alkalmazunk olyan architektúrális megoldást, amely a megbízhatóságot növeli.
49./53
Bizonyos speciális esetekben – amilyen tipikusan az adattárolás – a fentieknél sokkal hatékonyabb megoldás is nyújtható. A RAID (Redundant Array of Independent Disks) több, általában azonos paraméterő hard diszk speciális összekapcsolásával képes olyan struktúrát létrehozni, amelyben 1-2 diszk meghibásodása esetén is meg tudja akadályozni az adatvesztést, sıt még ilyen esetben is biztosítani tudja a folyamatos mőködést. A RAID rendszereket alapvetıen 6+1 kategóriába sorolják az alkalmazott hibavédelemtıl függıen. RAID0 A RAID0 gyakorlatilag redundanciát nem tartalmaz, így hibatőrı, hibajavító képessége nincs. Ez a megoldás mindössze azt biztosítja, hogy fizikailag több különbözı hard diszk logikailag összefőzve egy nagy diszknek látszik az operációs rendszer felé. Általában a RAID0 ezen szolgáltatását a többi RAID kategóriában is alkalmazni szokták. RAID1 A RAID1 kategória a teljes tükrözést fedi, azaz minden diszknek létezik egy párja. Páronként a diszkek azonos adatokat tárolnak. Így ha az egyik diszk meghibásodik, akkor a rendszer még a jó diszk alapján folyamatosan képes továbbmőködni. A jobb RAID1 termékek meghibásodás esetén a leállás nélküli (u.n. hot swap) cserét, majd a mőködés közbeni szinkronizációt (a jó diszkrıl az adatok áttöltését a megjavított diszkre) is biztosítani tudják. RAID2 A RAID2 az "egyszerő" duplikálásnál sokkal kifinomultabb hibajavító kód (un. Hamming kód) alkalmazásával meg tudja oldani, hogy 4 adat diszkhez 3 hibajavító diszk hozzáadásával akár két diszk meghibásodását is tolerálni képes. Látható, hogy itt a redundancia kevesebb, mint kétszeres, míg a hibatőrı képesség duplája, mint a tükrözéses esetben. A következı táblázat mutatja be a RAID2-nél alkalmazott 7,4,3 Hamming-kódot:
bináris Hamming érték kód
Érték
bináris Hamming érték kód
Érték
0
→
0000 000
8
→
1000 111
1
→
0001 011
9
→
1001 100
2
→
0010 101
10
→
1010 010
3
→
0011 110
11
→
1011 001
4
→
0100 110
12
→
1100 001
5
→
0101 101
13
→
1101 010
6
→
0110 011
14
→
1110 100
7
→
0111 000
15
→
1111 111
7. táblázat: 7,4,3 Hamming kód
50./53
Megfigyelhetı, hogy bármelyik két kód között legalább három jegyben eltérés van. (Az eltérı jegyek számát nevezik Hamming-távolságnak.) Így ha egy bináris számjegy megváltozik, még mindig legalább két jegynyi eltérés lesz más kódoktól, míg az eredetitıl csak egy. Így "melyikre hasonlít legjobban" alapon egy tévesztéses hiba javítható. Amennyiben nem megváltozik egy jegy, hanem az ıt tartalmazó diszk meghibásodik, akkor a meghibásodás ténye detektálható és ilyenkor törléses hibáról beszélünk. Törléses hiba esetén pedig még tetszıleges két bit letakarásakor is egyértelmő, hogy menyik eredeti kódszóra illenek a hiányos értékek. Vegyünk egy példát: a 4-es számjegyet a Hamming kód 0100 110 formában ábrázolja. Ha ebben a 2-ik bit megváltozik, akkor a 0000 110 sorozat a következı értékekre hasonlít: 0 (0000 000), 3 (0011 110), 4 (0100 110), 8 (1000 111) Látható, hogy az eredeti 4-es értékhez tartozó kódszó hasonlít a legjobban a módosult kódszóra, hiszen csak ebben az esetben van 1 bitnyi eltérés. Ellenırizhetı, hogy amennyiben nem bit változás, hanem meghibásodás történik, akkor még két számjegy elvesztése esetén is egyértelmő mi volt az eredeti kódszó. Komoly matematikai alapjai vannak a bonyolultabb, több hibát is javítani képes kódok elıállításának, illetve a "melyikre hasonlít legjobban" mővelet kiszámításának, a hibavalószínőségek megállapításának. Ezzel itt nem foglalkozunk részletesebben, de megemlítjük, hogy ezen módszerek alkalmazása nagyságrendekkel hatékonyabb megoldásokat eredményezhetnek, mint az egyszerő duplikáláson, tükrözésen alapuló technikák. RAID3 A RAID3 tetszıleges számú diszkhez ad hozzá egy plusz paritás diszket. A paritás disk az adatdiszkek tartalmának kizáró-vagy (XOR) eredményét tartalmazza. Így ha bármelyik diszk tönkremegy, akkor annak tartalma elıállítható az összes többi diszk tarmalmának és a paritás diszk tartalmának XOR-olásával. RAID4 Nagyon hasonló a RAID3-hoz. Ennél a kategóriánál is csupán egy extra, partiás értékeket tároló diszkre van szükség és így egy diszk meghibásodását képes javítani. A különbség mindössze a paritás diszk tartalmának számításában van. Még a RAID3 egy adatblokkot több diszkre mentett párhuzamosan, addig a RAID4 blokkos mőveletekkel dolgozik, így valamivel hatékonyabb tud lenni. RAID5 A RAID3 és RAID4 teljesítmény szempontjából vett továbbfejlesztett változata a RAID5. Itt a paritás értékek már nem egy külön dedikált paritás-diszken találhatóak, hanem elosztva a különbözı diszkeken "szétszórva" helyezkednek el. Ezzel fokozható a rendszer teljesítménye, mert nem kell minden írás mőveletnél ugyanahhoz a paritás diszkhez fordulni, amely az elızı esetekben így szők keresztmetszetté vált, hanem ez a terhelés megoszlik az adatdiszkek között. Eredendıen tehát a kihasználtság így nagyobb lehet, a rendszer teljesítménye fokozható.
51./53
RAID6 A RAID6 a RAID5-höz képest dupla paritás blokkokat vezetett be, amelyeket az elızıekhez hasonlóan szétszórva tárol az adatdiszkeken. A két paritás értéket "függılegesen" és "visszintesen" képzi, így 2 diszk meghibásodását is kezelni tudja. A RAID rendszerek kereskedelmi forgalomban kaphatók és megfelelıen gyors javítással valóban nagyságrendi javulást tudnak elérni a legkritikusabb területen, az adatok rendelkezésre állása terén. Így ahol csak mód van rá javasolt alkalmazásuk.
4.4.4 Biztonsági mentések Még abban az esetben is, ha nagy megbízhatóságú, több hibát is javítani képes RAID rendszert alkalmazunk adataink védelmére, elengedhetetlen a biztonsági mentések rendszerezett, ellenırzött végzése. A biztonsági mentések kapcsán három nagy fı problémakör jelentkezik: •
nagy rendszerek problémái (amikor a mentés és a visszaállítás idıtartama annyira nagy, hogy a normál mőködést, az üzemidıt fenyegeti),
•
on-line rendszerek (amennyiben egy rendszer nem állítható le a biztonsági mentés készítésének idejére, speciális módszereket kell alkalmazni a mentett adatok konzisztenciájának biztosítására),
•
elosztott rendszerek (az egymással kommunikáló rendszerek komoly kihívást jelentenek a biztonsági mentések rendszerének kidolgozásánál, ugyanis egy esetleges visszaállítás eredményeképpen elıállhat olyan helyzet, hogy bizonyos tranzakció(ka)t az egyik rendszer lekönyvelte, míg a másik a visszaállítás miatt az adott tranzakcióról semmit sem tud).
A mentési stratégia kidolgozására általános recept nem adható. Minden egyes konkrét esetben külön kell meghatározni, hogy az adott rendszer esetében mely mentési stratégia a legcélravezetıbb. Nagy rendszerek Nagy rendszerek esetén az jelent különös gondot, ha a mentés elvégzésének ideje annyira hosszú, hogy akkora leállás az üzemidıbe már nem fél bele. Az esetleges ritkább mentés pedig az utolsó mentés óta elveszett adatok mennyiségét növelheti meg jelentısen. Ekkor olyan módszerhez szoktak folyamodni, hogy a teljes rendszert, illetve adatbázist csak ritkábban (pl. hétvégente) mentik le (teljes mentés), míg napi rendszerességgel csak a változásokat mentik (inkrementális mentés). Az inkrementális mentés is további két fajtára osztható a kumulatív és a differenciális mentésre. Az elıbbinél az inkrementális mentés mindig az utolsó teljes mentéshez képesti változásokat menti, míg a differenciális mentés mindig az elızı – teljes vagy inkrementális – mentéshez képesti változásokat menti. Könnyen belátható, hogy a differenciális mentés kevesebb adatot ment, mint a kumulatív, így a hétköznapokban gyorsabban lefut. Visszaállításkor azonban a teljes mentés után számos differenciális mentést kell rendben visszatölteni, ami jelentısen lassabb procedúra, mint a kumulatív mentés-visszaállítás esetén, amikor csak a teljes mentést és a legutolsó kumulatív mentést kell visszatölteni. On-line rendszerek On-line rendszerek esetén a problémát az okozza, hogy ha a mentés végzése közben a rendszert nem állíthatjuk le, vagyis a mentés közben változik a mentett adatbázis tartalma, akkor az beláthatatlan inkonzisztencia problémákhoz vezethet.
52./53
Ilyen esetben az úgynevezett hideg mentés módszerét szokták alkalmazni, azaz az adatbázis tartalmát befagyasztják a mentés idejére és a változásokat nem végzik el benne, hanem pusztán feljegyzik egy külön listába (transaction log-ba). Miután a mentés befejezıdött az el nem végzett módosításokat a rendszer végrehajtja az adatbázison, így annak fizikai tartalma hamarosan utoléri az on-line mőködést. Elosztott rendszerek Lazán csatolt, egymással kommunikáló rendszerek esetében elıfordulhat, hogy a biztonsági mentések olyan szerencsétlenül történnek meg, hogy egy – a két rendszer közötti – tranzakciónak az egyik fele az egyik rendszer biztonsági mentésében már végrehajtott módon van elmentve, míg a másik rendszer esetében még a tranzakció végrehajtása elıtti állapot van megırizve. Ekkor inkonzisztens állapot alakulhat ki. Ha ilyenkor visszalépünk egy elızı mentési állapotra még ott is elıfordulhat ugyanez a konzisztencia probléma, és még régebbi állapotra kell visszalépni, és így tovább. Ezt a hatást nevezik Dominó-effektusnak, amikor egymás után derül ki a mentett állapotokról, hogy azok inkonzisztensek. Ha nem csak két hanem több rendszer végez adatcserét egymással, akkor megugrik annak valószínősége, hogy az egész mentési rendszer nem lesz megfelelı és jelentıs konzisztencia problémával kell szembenézni egy esetleges visszaállítás után. A Dominó-effektus elkerülésére számos megoldás létezik, amely a mentéseket képes úgy összehangolni, hogy konzisztencia problémák ne fordulhassanak elı. Minden hasonló esetben meg kell gyızıdni róla, hogy az adott termékek, az adott megoldások ezt a problémát megfelelıen kezelni tudják-e!
4.4.5 Archiválás A rendelkezésre-állás menedzsment témakörében említjük meg az archiválás feladatát is, bár ez a funkció valójában nem ide tartozik. Nagyon fontos fogalmilag tisztázni, hogy az archiválás az adatok történelmi visszakereshetıségét hivatott megoldani, míg a biztonsági mentések a nem várt adatveszteségek elkerülését célozzák. Sok esetben a biztonsági mentések archiválási szempontból nem használhatók, mert nem visszakereshetıek, illetve az archivált adatokból még nem biztos, hogy egy valamikori adatbázist teljes egészében minden szempontból vissza lehet állítani. Ezért a javasolt megközelítés az, hogy az archiválás és a biztonsági mentések funkcióit fogalmi és elvárási szinten élesen különítsék el.
5
Összefoglalás
A biztonság menedzsment témakörében láttuk, hogy az IT biztonság kezelésének problémája jelentısen túlmutat az informatikai rendszeren és az egész szervezetet, hierarchikus felépítést, ügymenetet is érintı kérdésrıl van szó. Komoly szakmai felkészültséget és precíz tudás igényel a biztonság megteremtése, illetve javítása. Rengeteget kell dolgozni annak érdekében, hogy a legjelentısebb veszélyforrásokat, a legnagyobb kockázatot jelentı tényezıket megfelelıen kezelni lehessen. Míg a másik oldalon, sajnos még komoly áldozatvállalások esetén sem küszöbölhetı ki az összes fenyegetı tényezı és maradó kockázatokkal, veszélyekkel mindig számolni kell. Tökéletes, 100%-os biztonság nincs. A biztonság menedzselésével tehát komolyan foglalkozni kell és ebben a tevékenységben rendkívül sok múlik a megfelelı felsı szintő vezetésen. A biztonság kérdése nem a rendszergazdák technikai mélységein, hanem sokkal nagyobb mértékben a jó menedzselésen múlik, akárcsak más területeken.
53./53
