Zárt felhasználói csoportok nyílt kulcsú infrastruktúrája a szervezetek biztonsági architektúrájában

Gerencsér András

Budapesti Közgazdaságtudományi és Államigazgatási Egyetem,
Információrendszerek Tanszék

h6389ger@helka.iif.hu

Az elmúlt idõszak intézményeket, hálózatokat ért, hatalmas károkat okozó támadásai szükségszerûen felgyorsítják az informatikai biztonsági megoldások újra értékelését, és az intelligens kártya alapú igazolványok közeli évekre jósolt széleskörû elterjedését. Más oldalról az elektronikus aláírás uniós irányelvei és a nemzeti törvények alapjain kiépülõ nyílt kulcsú infrastruktúrák nemcsak a globális e-kereskedelem hálózati tranzakciói megbízhatóságába vetett felhasználói bizalom erõsítését szolgálják, hanem a szigorú felhasználói azonosítást, az egyszeri bejelentkezés során a jogosultságok kiadását is támogathatják a privát hálózatokon.

Az országos kiterjedésû hitelesítés szolgáltató hálózatok telepítése elõtt célszerû zárt felhasználói csoportok számára szabványos, átjárható, nyílt kulcsú infrastruktúrák kialakítása. A hazai intézményi, szervezeti biztonsági architektúrák tervezésekor a gyakorlat legjobb példájának áttekintését követõen kell belefogni a megvalósításba. Az elõadás egy konkrét nyílt kulcsú infrastruktúrát ismertet.

1. Bevezetés

Jelentõs azok száma, akik a mobil kommunikáció eszközeivel érik el a munkájuk, üzleti tevékenységük maradéktalan ellátásához szükséges információkat. A mobil kommunikáció fõ célja, hogy a felhasználók számára biztosítsa a globális hálózatok elérésének lehetõségét függetlenül tartózkodási helyüktõl vagy mozgásuktól. Ezért a mobil kommunikáció egy lépés a függetlenség irányába, de ugyankkor állandó elérhetõséget jelent, amely új mobil hálózatok telepítését és új szolgáltatások megjelenését teszi szükségessé. Az általános számítógép használat víziója mellett a „bármit, bármikor, bárhol” egyre fontosabb lesz új lehetõségeivel, amelyek azonban új kockázatokat is jelentenek.

Az egyén mobilitásának növekvõ támogatása napjaink egyik nagy trendje, amelyet 2001. szeptember 11-ike ugyancsak más megvilágításba helyezhet. A terroristák, és virtuális bûnözõk fenyegetései folytán még nagyobb szükség lehet a védelmi szakágazatok mobil informatikai támogatására, de bármely felhasználót is informatikai berendezései, bizalmas információ fokozottabb védelmére kényszerítenek. A mobilitás mindenki számára azt jelenti, hogy arra az idõre, míg távol van hivatalától, vagy otthonától nem kell megszakítani a kommunikációs lehetõségeket, és az információforrások bármikor, bárhonnan elérhetõk. A mobil eszközök használatához azonban megbízható és a tranzakciók bizalmasságát biztosító kommunikációra van szükség. A hálózatbiztonság alapesetben a rendszeren kívüli, jogosultságokkal nem rendelkezõk távoltartását, illetve a hálózat belsõ felhasználói jogosultságainak megadását jelenti. A mobil és más, távoli felhasználók esetében magasabb fokú biztonságra és a rendszer megbízhatóságának folyamatos bizonyítására, a felhasználó bizalmának megtartására is szükség van.

A 2002-es évre azt jósolják,[1] hogy az informatikai rendszerek elleni támadások gyakoribbak és kifinomultabbak lesznek, egy idõben többféle biztonsági rést is megtámadva. A vírusok automatikusan, növekvõ sebességgel terjednek, ami veszélyezteti a teljes hálózatot. A támadók célja egyre inkább a hálózati elemek, mint az útvonal irányítók és a nem hagyományos protokollok, hogy így a rendszert kompromittálva megbénítsák szolgáltatásokat. A vezeték nélküli technológia válik a régi típusú támadások és az új, rossz szándékú kísérletek színterévé.

A vezeték nélküli kommunikáció védelmére rejtjelezõ és autentikációs eljárások szükségesek. Elterjedt, szabványos megoldásokat vizsgálva az IPSec protokoll mellett kézenfekvõ az autentikációhoz az IKE (Internet Key Exchange) protokoll, illetve a nyilvános kulcsú infrastruktúrák azonos lehetõségeinek használata.

A nyílt kulcsú infrastruktúrák alkalmazását meglepõen sok szervezet, cég tervezi a magyar elektronikus aláírás törvény hatálybalépése óta. Sok helyen kezdik használni, a belsõ üzleti folyamatok támogatására, a külsõ kapcsolatokon virtuális privát hálózatok (VPN, meghatározása a 3.2 pont alatt) kialakítására és az adatvagyon biztonságos védelmére az Internet alapú nyitott hálózatokon az elektronikus kereskedelem, elektronikus kormányzat tranzakcióinak biztonságos bonyolítására. A nyílt kulcsú kriptográfia nyújtotta megbízható azonosítás, a tranzakció teljességének és letagadhatatlanságának garantálása elsõként a személyes adatokat, szerzõdéseket és pénzügyi információkat kezelõ egyedi alkalmazások védelmére kerül általában telepítésre. Közvetlen haszonként jelentkezik a szolgáltatásminõség javulása, a hatékonyság és a költség megtakarítás, de sok esetben a jó hírnév megõrzése, vagy pusztán az e-kereskedelem, e-kormányzat alkalmazásainak, az elektronikus aláírás szélesebb körû használatának elõsegítése a bevezetés célja.

A sok helyszínû, nagy privát hálózatok kialakulása az egyes épületek lokális hálózataiból, majd megnyitásuk a külsõ partnerek, utazó munkatársak számára, illetve az Internetre kapcsolásuk az informatikai biztonság kezelését mind szükségesebbé és bonyolultabbá tette. A biztonsági betörések közvetlen a szervezet mûködõképességét béníthatják meg. A hackerek a sebezhetõ pontok megtalálásában és a gyengeségek kihasználásában még rafináltabbak lettek. A biztonság ebben a környezetben elejtendõ zsákmány.

A vírusok, férgek okozta károkról meglehetõsen nagy számokat közölnek[2]. 2001. augusztus 31-én 10,7 milliárd dollár költséget prognosztizáltak, amibõl az akkor lecsengõ CodeRed egymaga 2,6 milliárdot vitt el, mintegy fele részben az 1 millió fertõzött szerver vírusmentesítésére, illetve a további 8 millió ellenõrzésére. Valamivel nagyobb összeget jelentettek a munkakiesés okozta költségek. A Nimdát 2001. szeptember 18-án regisztrálták. Az okozott kár 19-én már 531 millió dollár. A becslések szerint a következõ napon 24 óra alatt 2,2 millió szervert és személyi számítógépet fertõzött meg.

2. Feladat meghatározás

A jól mûködõ Intranet-es megoldásokon túl, egyre nagyobb az igény az extranet használatára, a belsõ, védett hálózaton elérhetõ információs szolgáltatások megnyitására a szervezet központjától távoli telephelyek, partnerek és a mobil felhasználók számára. Biztosítani kell a meglévõ belsõ hálózat különbözõ, esetenként külön tûzfallal védett szerverein található információforrások tartalmához a hozzáférést a notebookkal és GSM telefonnal rendelkezõ, vagy asztali számítógépérõl távoli behívást kezdeményezõ más felhasználók számára. A kidolgozás során figyelembe kell venni az intelligens azonosító kártyákat, melyek széles körben terjednek, akár a beléptetéshez szükséges munkáltatói igazolványként, akár a digitális aláíráshoz szükséges tanúsítványok, kulcsok hordozójaként.







3. A megoldás lehetséges módjai

3.1. A szervezeti biztonsági követelmények

A globális szervezeti integritás az elektronikus kereskedelem környezetében öt egymással összefüggõ területre bontható: a hálózat teljessége, a rendszerek teljessége, a felhasználói jogosultságok teljessége, alkalmazási / adat teljesség, és az adatok bizalmassága és védelme.

Szem elõtt kell tartani a szolgáltatás minõség (QoS), megbízhatóság, rugalmasság, modularitás, méretezhetõség, stb. követelményeit. A nyílt kulcsú infrastruktúra, mint a biztonság fokozásának eszköze a hálózatoktól a bizalmasság területéig komplex megoldást ajánl. A tanúsítványokhoz kapcsolt kulcs párok biztosítják, hogy a szervezet alkalmazottjainak, ügyfeleinek szenzitív információi védettek maradnak akár a nyilvános hálózatokon, az Interneten történõ átvitel esetén is. Az információkhoz csak az egyedi tanúsítványokkal meghatározott és védett kulcsokkal lehet hozzáférni. A tanúsítványok alkalmazásával a végpontól-végpontig történõ tranzakciókban a felhasználók bizonyosak lehetnek, hogy az információ csak számukra hozzáférhetõ, és mások számára láthatatlan mind a tárolás, mind az átvitel során.

A nyílt kulcsú infrastruktúra képes a megkövetelt biztonsági szinteket a mobil felhasználók számára is biztosítani. A tanúsítványok alkalmazásával egy jogosultság menedzselõ infrastruktúrában a szervezet elsõként azonosítja a felhasználóit és jogosítja, hogy elérhesse saját személyes adatait, valamint az õt érdeklõ információkat és alkalmazásokat. A tanúsítvány akár asztali számítógéprõl, akár mobil eszközrõl on-line kezelhetõ. A felhasználó azonosítását, autentikációját követõen az autorizáció során kerülnek a jogosultságok és privilégiumok központilag kiadásra. Lényeges, hogy a központi autorizáció minden szolgáltatásra vonatkoztatható legyen.

A 2001. évi Networkshopon a nyílt kulcsú infrastruktúra architektúrája kapcsán[3] rávilágítottunk az ismert modellek használatának lehetõségeire, az architektúra tervezés fontosságára. Ha nincs koncepcionális egység, nem biztosított a szabványok alkalmazása, azaz nincs architektúra terv, a sokféle érdek ad-e lehetõséget az interaktív rendszerek megvalósításra? Egyes szakértõk szerint az együttmûködési feltételek hiánya 2002-re a nyílt kulcsú infrastruktúra bukását hozza[4]. A továbbiakban a jelenlegi helyzetet és az együttmûködésre képes szervezeti biztonsági architektúrák megvalósításához vezetõ elõrelépést jelentõ megoldásokat vizsgáljuk.

3.2 Virtuális privát hálózatok

A virtuális privát hálózatok (VPN) alkalmazásának nyilvánvaló oka a biztonságos elektronikus kereskedelem, e-kormányzat, a távmunka, a virtuális irodák és az elosztott rendszerû tudásmenedzsment architektúrák tervezésekor a költség-hatékonyság.

A virtuális hálózatok alkalmazása nem újdonság, hiszen a távközlési, kapcsolt vonalas telefon szolgáltatók gyakorlatában évek óta ismert, mint például a Frame Relay, melyet elterjedten használnak a bérelt vonalak helyett, vagy az ATM hálózatok szolgáltatásai. Az IP alapú VPN a Frame Relay-hez hasonlóan zárt felhasználói csoportokat szolgál ki, a különbség azonban, hogy az IP VPN a biztonságos kommunikáció hordozójaként a nyilvános infrastruktúrát, az Internetet, vagy más nyilvános hálózatot használ fel. A VPN biztonságát alapvetõen a nyílt kulcsú infrastruktúra menedzsmentje biztosíthatja. A Frame Relay hálózatokkal ellentétben nem szükséges állandó virtuális áramkörök (PVC) páronkénti implementálása, az összes felhasználói végpont között. Sõt a nyílt kulcsú infrastruktúra lehetõséget ad az összes IP VPN felhasználó egyetlen központi adatbázisból történõ menedzselésére.

Az IP VPN a definíció szerint IP technológián alapuló megosztott hálózati infrastruktúra a szervezet/vállalat távoli telephelyeinek összekapcsolására vagy távoli telefon, illetve kábel MODEM-es behívás alkalmazására[5]. A virtuális privát hálózat a nyilvános Interneten, és/vagy (más megosztható szolgáltatói hálózaton), menedzselt IP alapú hálózaton virtuális csatorna (tunnel) létrehozásával alakítható ki. Az IP VPN-ek a távoli felhasználók számára az Interneten át biztonságos csatornán biztosítanak elérést a szervezeti hálózathoz. A VPN virtuális hiszen nincs szükség önálló vonalra, privát, mivel mások számára nem hozzáférhetõ, rejtjelezett, csak a két végpont felhasználói számára transzparens és majdnem tökéletesen lehallgatás biztos. Hálózatként kezelik, mivel a megosztott IP hálózatok elõnyeivel rendelkezik. A biztonság szempontjából a privát hálózatok szolgáltatás minõségét és menedzselhetõségét biztosítja. Az IP VPN lehetõvé teszi, hogy a távoli irodák, külsõ munkahelyen vagy otthon dolgozó alkalmazottak és a külsõ partnerek, mint extranet felhasználók ugyanúgy kommunikáljanak a szervezet központjával, illetve egymással, mint a helyi hálózatukon, vagy a privát, bérelt vonalas vállalati hálózaton.

A VPN szoftver vagy hardver, illetve kombinált megoldású lehet. Az adatok Internet feletti átvitelére szabványos tunneling protokollokat használ (szabványos L2TP, CISCO L2F, MS PPTP) jellemzõen a kettes rétegben, bár szinte valamennyi OSI rétegre alkalmazható lenne. Meg kell jegyezni, hogy csak a négyes (szállítási) réteg vagy alatta lévõk transzparensek a felhasználó számára. A VPN mûködésének három fõ összetevõje van: a biztonság, a forgalom ellenõrzés és a szervezeti menedzsment. Ezek különbözõ súlyának megfelelõen a VPN öt osztályát (0-tól 4-ig) különböztetik meg. A nyílt kulcsú infrastruktúra használata a 2. osztálytól felfelé lehetséges. A 2. osztály maximum 500 felhasználót és 10 helyszínt képes kiszolgálni, 3DES, AES rejtjelezéssel, szoftver token-es szigorú autentikációval. A telefonos MODEM-en behívó felhasználók menedzselésére RADIUS szerver használható, a rendszer együtt képes mûködni tûzfalakkal is, de gyenge az extranetek és a valós idejû alkalmazások támogatása. A 3. osztályú VPN azonban az intelligens kártyás autentikációhoz már a hitelesítés szolgáltató tanúsítvány menedzsmentjét veszi igénybe.

A VPN-eket a szervezeten belül dedikált hardveren, útvonal irányítókon, illetve proxy alapú tûzfalakon lehet végzõdtetni, míg a felhasználói oldalon ugyancsak robusztus kliens szoftverre van szükség, melyet a legtöbb gyártó hardveréhez kapcsolva szállít.

Az IP alapú VPN IPSec alkalmazásával, és/vagy más, részben gyártófüggõ, nem szabványos protokollal rejtjelezhetõ, védhetõ. A korai szoftveres VPN megoldással szemben a hardveres számos elõnyt nyújt. A VPN hardver több Internet csatornát, (tunnel-t), nagyobb sebességet tud kezelni, és a teljes rendszer paraméterei jobbak bármely szoftveres rendszernél. A VPN útvonal irányítók támogatják a több VPN tunnel-es normál Internet hozzáférést.

Az új biztonsági kihívások következményeként kifejlesztésre kerülõ hardver termékek csökkentik a VPN szoftver tûzfalak elterjedtségét. A cégek egyre inkább meg vannak gyõzõdve, hogy a szoftver önmagában nem elegendõ a hálózati védelem magas biztonsági követelményeinek kielégítésre. A fenyegetések pedig minden évben megsokszorozódnak. Sajnos, egyhamar nem válik könnyebbé a hálózatok biztonságossá tétele, de legalább a gyártók új eszközöket ajánlanak az erõsebb határok kialakítására. A biztonsági rendszerek azonban igen költségesek, ezért bevezetésük a biztonsági koncepció elõírásai szerint és a kockázatelemzéssel alátámasztott architektúra terv alapján történhet.

A szervezeti hálózatok külsõ határain az adatcsomagokat szûrõ hardveres tûzfalak nagyobb biztonságot adnak, mint a szoftver tûzfalak, melyek szerver szinten szûrik a csomagokat. A határtûzfalak annál fontosabbakká válnak minél több távoli felhasználó fogja VPN-en elérni a belsõ információkat. Mind a belsõ állományok, mind a távoli felhasználók gépeinek védelmére szükség van tûzfalakra.

A határtûzfalak azonban nem védenek hálózati hozzáférési joggal rendelkezõ „elbitangolt” extranetes felhasználók vagy a belsõ, rossz indulatú alkalmazottak ellen. Az ilyen, illetéktelen adatbázis, vagy szerver hozzáférést kizáró tûzfal tulajdonságok támogatására speciális hálózati kártyákat használnak. Ez a megoldás csökkenti az elektronikus lopás és szabotázs, vagy a védett információk célzatos felfedésének kockázatát.

A jelenlegi, az útvonal irányítók között alkalmazott IPSec technológiák személyi számítógép és szerver közötti kiterjesztésén is dolgoznak. Ez a szerverrõl a személyi számítógép külön kriptográfiai koprocesszorára töltené le az IPSec rejtjelezést, biztosítva a lokális hálózaton továbbított adatok védelmét is a hálózat biztonsági jellemzõinek feláldozása nélkül. Az ilyen, hardveren futó megoldások, az elosztott szoftveres tûzfalakkal szemben nem jelentenek kockázatot a kapcsolat végfelhasználó által okozott véletlen vagy célzatos megszakításakor sem.



3.3 Nyílt kulcsú infrastruktúra

Az információtechnológia fejlõdésével az egyedi számítógépek helyi hálózatokba szervezésével, majd a helyi hálózatok városi, országos nagy távolságú (WAN) hálózatokba kapcsolásával a feldolgozott, tárolt, átadott vagy továbbított információk védelme egyre kritikusabb és nehezebb feladat. A szervezetek kizárólagosan saját használatra bérelt távközlési összeköttetései mellett, melyekkel egy-egy telephelyen túlnyúló zárt biztonsági tartományokat alakítanak ki, a sokféle internetes információforrás és a világméretû elektronikus levelezés elérhetõségének igénye folytán a szervezetek hálózatai az Internetre is rácsatlakoznak. Sajnálatos módon az Interneten jelenleg nincsen semmilyen kötelezõ érvényûen elõírt megoldás a bizalmas és hiteles adatcseréhez szükséges kommunikációhoz. A szerveztek saját belátásuk szerint alkalmazhatják WAN összeköttetéseikben a biztonságot jelentõ Internet protokollt (IPSec) és az internetes, vagy kapcsolt telefonvonalas pont-pont közötti kommunikáció rejtjelezését megoldó virtuális privát hálózatokat (VPN).

A nyílt kulcsú infrastruktúra digitális tanúsítványai biztosítják azt az optimális megoldást, amellyel a WEB böngészõk, szerverek és a mobil eszközök bizalmas tartalmú információ forgalma megvédhetõ. A tanúsítvány az elõfizetõ on-line személyi igazolványaként a felhasználók legbiztonságosabb azonosítási módja, legalábbis a ma legelterjedtebben használt felhasználói azonosító/jelszó rendszerhez képest. A felhasználói azonosító/jelszó ugyanis mások által is elérhetõ központi adattárakban van, míg a tanúsítványok sérthetetlenségét a teljes nyílt kulcsú infrastruktúra védi.

A tanúsítványok és kulcs menedzsment szempontjából a hierarchikus (VeriSign, Netscape, Microsoft), a hálózati (Entrust) és a WEB központú (PGP) modell koncepciók terjedtek el. Úgy tûnt, hogy a hierarchikus megoldás alkalmazása került elõtérbe hatékonysága és más piaci tényezõk folytán. Akadályokba ütköztek azonban, ahol az infrastruktúrák gyakorlati megvalósításra is sor került. Nagy szervezetek, vagy a kormányzati infrastruktúrák egyetlen, hierarchikus fastruktúrába szervezése sok esetben nem járt sikerrel. Ha mégis, akkor is felmerül ezek külsõ együttmûködésének igénye. A különbözõ biztonsági tartományok kialakítását más-más idõben, különbözõ szállítók termékeivel építik ki, így valóban kérdésessé válik az együttmûködõ képesség biztosítása és a globális szintû tanúsítvány használat és érvényesség ellenõrzés megvalósíthatósága. A nyilvános kulcsú infrastruktúrák kialakításában döntõ szerep jutott az alulról felfelé építkezésnek, hiszen az igények és a jelentõs tõkét igénylõ beruházás feltételei nem egy idõben jelentkeznek. Ekkor a választható megoldás háromféleképpen általánosítható:

  1. Önálló, vállalati tanúsítványszolgáltató mûködik, amely tevékenységet azonban akár a szervezeten kívüli cég is elláthatja szolgáltatás kihelyezéssel (outsourcingban).

  2. A nagyvállalati tanúsítvány szolgáltató saját cégén belül elsõdleges hatóság, azonban akár ennek alárendelt regisztrációs és elosztó központok, vagy alárendelt tanúsítványszolgáltatók is lehetnek a vállalaton belül a funkcionális és földrajzi megosztottság szerint.

  3. A szervezetek közötti biztonságos kommunikáció érdekében külsõ kapcsolatokat, kölcsönös tanúsítást is lehetõvé tevõ heterogén modellt követnek az önálló szervezetek / vállalkozások, amely a felelõsségi viszony megállapodások függvényében megosztott teherviselést is jelenthet.

A nyílt, piaci versenyben nem garantálható, hogy azonos termékeket használnak mindenhol, bár ez egyszerû helyzetet teremthetne. Ilyen megoldás látható az Európai Bizottság DG-Enterprise IDA program keretében 1999-2000 folyamán megvalósított zárt felhasználói csoportok kiszolgálására kialakított nyílt kulcsú infrastruktúráknál[6]. Sõt a nyílt piaci szolgáltató honlapjának tanúsága szerint[7] a holland e-kormányzati, egy belga közigazgatási és (virtuális hitelesítés szolgáltatóként) a teljes bolgár iparos szövetségi infrastruktúrát is õk szolgálják ki.



3.4. Zárt felhasználói csoportok a nyílt kulcsú infrastruktúrában

A konkrét alkalmazásokra épülõ, zárt felhasználói csoportot kiszolgáló nyílt kulcsú infrastruktúra elõnye a tanúsítványok érvényességének egyszerûbb ellenõrizhetõsége és általában a menedzsment folyamatok rugalmasabb kezelésének lehetõsége, mivel jól meghatározott, kisebb felhasználói kört érint. Ez a megoldás elõnyösen alkalmazható a VPN-ek biztonsági menedzselésére is. A nyilvános regisztrációs hatóság szigorú ellenõrzési és felelõsségi megkötéseit a zárt felhasználói csoport szükségleteinek megfelelõen lazítani lehet, hogy a felhasználókat a felesleges és nem odaillõ regisztrációs folyamatokkal ne riasszák el. A hitelesítés szolgáltató csak a regisztrációs hatóság által jóváhagyott „elõfizetõ” számára ad ki tanúsítványt. A hitelesítés szolgáltató felelõssége korlátozott mivel, a zárt csoport közössége ellenõrzi a mûködési folyamatot, illetve azt minden felelõsséggel, igényei szerint alakítja. A hitelesítés szolgáltató tanúsítványok aláírására használt saját privát kulcsa vagy teljesen független, vagy egy központi, akár külsõ szolgáltató által biztosított. Az utóbbi esetben egy erõs háttér infrastruktúrával rendelkezõ, kellõ bizalmat élvezõ, nyilvános, kereskedelmi hitelesítés szolgáltató bízható meg a zárt felhasználói csoport elsõdleges tanúsítványának generálásával és a kulcs menedzsment feladatainak ellátásával. A helyi hitelesítés szolgáltató a hozzá tartozó zárt felhasználói csoportok tanúsítványait a saját gyökér tanúsítványához tartozó privát kulcsával írja alá. A késõbbi fejlõdés során települõ, a kezdetben egymástól független hitelesítés szolgáltatók célszerûen az eredeti gyökér tanúsítványukat használják, tehát alárendelt tanúsítványszolgáltatók (subordinated CA-k). Kézenfekvõen hierarchikus hitelesítési lánc jön létre a gyökér tanúsítványt adó szolgáltató és a zárt felhasználói csoport szolgáltatója között. Az azonos tanúsítási irányelvek szerint mûködõ alárendelt tanúsítvány szolgáltatók egymás tanúsítványainak elfogadásával minden nehézség nélkül kereszttanúsítás kapcsolatot alakíthatnak ki. Az így létrejövõ, egyre terjedelmesebb országos, európai szintû nyilvános kulcsú infrastruktúrában egyetlen kereskedelmi szolgáltató is menedzselheti a tanúsítványokat. Ennek köszönhetõen az önálló gyökér tanúsítványok kritikus rendelkezésre állási problémái megoldhatónak tûnnek a kereskedelmi szolgáltató felelõsségi körében.

Az USA szövetségi, nyílt kulcsú infrastruktúra fejlesztés tapasztalatait vizsgálva[8] látnunk kell, hogy elõbb-utóbb meg kell oldani a mûszaki, szabványosítási fejlõdés különbözõ állapotait használó piaci és állami szolgáltatók rendszereinek összekapcsolását. Mindennek kivitelezésére az Internet világából korábbi példák is akadnak akár Magyarországon is. Ezt a célt szolgálja az USA NIST „bridge CA” architektúrája. Létre lehet hozni egy közös szervezetet, vagy ki lehet jelölni egy szolgáltatót, amely biztosítja a különbözõ megoldások együttmûködéséhez szükséges egyeztetõ funkciókat, illetve kiadja a szolgáltatók együttmûködéséhez szükséges tanúsítványokat. A nyílt kulcsú infrastruktúrák fejlesztése terén nyilvánvaló lemaradásunkat tekintve felmerül azonban a kérdés, hogy a költségvetési szerveknél elõrelátó tervezéssel, az európai utat követve lehet-e, nem célszerûbb-e lassan, de biztosan bevezetni az együttmûködésre képes, költség-hatékony nyílt kulcsú infrastruktúrákat. Mi kell ehhez? Koncepció és szigorú szabályozás.

A koncepció irányította szabályozás jó példái az Európai Parlament és Európai Bizottság IDA/TESTA hálózat használatra vonatkozó 1719/1999 és 1720/1999 számú döntései. A hazai nyílt kulcsú infrastruktúra fejlesztések jelenlegi állapotában még nem késõ hasonló intézkedések megtétele a költségvetési szférára vonatkozóan.

4. A szervezeti biztonsági architektúra tervezése

Mind az államigazgatásban, mind a legtöbb nagy magánvállalatánál az informatikai és a biztonsági rendszereket is sok év óta fõként taktikai megfontolások alapján telepítik. Jobbára meghatározzák a mûszaki követelményeket kielégítõ termékeket és beszerzik azokat, a nagyobb összefüggések figyelembe vétele nélkül. Az elektronikus aláírás, az intelligens kártyák hasonló formájú bevezetése igen nagy kockázattal, magas költséggel jár. Bevezetnek egy adott megoldást, amely például a felhasználói azonosítást, az elektronikus levelek aláírását biztosítja, de gyakran senki sincs meggyõzõdve arról, hogy a biztonság a kockázattal arányos-e, vagy a költségek megfelelnek-e a nyújtott haszonnak, avagy eleget tesznek-e egy sor más, nem kockázat típusú szervezeti követelménynek, pl. hosszú távon is biztosított-e az együttmûködés, a rendszer újra felhasználhatósága, bõvíthetõsége. Ez egy sor problémához vezet.

A megoldások gyakorta izoláltak, nem alkalmasak az együttmûködésre másokkal. A sokféle rendszer növeli a bonyolultságot és az üzemeltetési költségeket, megnöveli az adminisztratív és vezetési munkaterheléseket. A legrosszabb mindebben az, hogy a megoldás gyakorta hátráltatja a szervezeti feladatok ellátását, ahelyett, hogy segítené, tekintve, hogy a tervezés során nem fordítottak kellõ figyelmet a szervezeti követelményekre. Ennek köszönhetõen az informatika vagy a biztonságtechnika tekintélye a szervezeten belül egyre rosszabb lesz. Következésképpen a tulajdonosok, vezetõk nemcsak alulértékelik saját informatikai részlegük szerepét, hanem megalapozatlan szolgáltatás kihelyezésre outsourcing szerzõdéseket is kötnek. Sokkal szélesebb körû stratégiai szemléletre van szükség, melyben a szervezeti követelmények a fõ meghatározói az informatikai rendszerek hatékony fejlesztésének és üzemeltetésének.

A rendszertervezést, a késõbbi implementálás irányítását, a mûködés ellenõrzését segítõ architektúra modell meghatározásával kell kezdeni. A tervezés módszertana a jól bevált Zachman féle keretrendszer[9] megfelelõ adaptálása. A biztonsági architektúra modell a szervezeti/üzleti biztonsági követelmények (a szervezeti/üzleti vetület a stratégiában megfogalmazott általánosítható összefüggések feltérképezése), a koncepcionális célkitûzések (a szervezeti architektúra vetülete), a logikai architektúra (a tervezõi vetület), a fizikai architektúra (a kivitelezõi vetület), a biztonsági technológia elemek (a megvalósítás integrációs vetülete), és a mûködtetés/üzemeltetés vetületeibõl tevõdik össze. Az informatikai biztonság célja a szervezet stratégiai célkitûzéseinek teljesítése érdekében a szervezeti információk védett, biztonságos használatának garantálása. A biztonsági rendszer mûködtetésével kapcsolatos követelmények, feladatok az összes megelõzõ architekturális vetületben is megjelennek, amit az 1. ábrán próbálunk érzékeltetni. A rendszer feladata nem korlátozódik a biztonsági ellenõrzések támogatására.

1. ábra

Az architektúra tervezés folyamatában elsõként tehát az adott szervezet, vállalkozás, céljainak, feladatainak, mûködési feltételeinek összefüggéseit vizsgáljuk meg a szervezet legfelsõ vezetõinek megbízása és támogatása alapján. Választ kell adni a mit?, hogyan?, hol?, ki?, mikor?, miért? kérdésekre, hogy a szervezeti stratégiában meghatározott célkitûzések, feladatok költség-hatékony, minõségi és határidõre történõ végrehajtása céljából hogyan teljesíthetõek az eredményesség, hatékonyság, az információk megbízhatósága és jogszerûsége iránti követelmények a szükséges mértékû bizalmasság, integritás, rendelkezésre állás biztonsági szempontjainak érvényesítése esetén is. A teljes intézményre vonatkozó szervezeti (vállalati) architektúra többféle szakterületi architektúrára támaszkodva állítható elõ, amelyek egyik fontos része a szervezet biztonsági architektúrája. Nem szabad szem elõl téveszteni, hogy a szervezeti biztonsági architektúra részeként az informatikai biztonság mellett hasonlóan fontos a szervezet folyamatos mûködésének tervezése, biztosítása, valamint a fizikai és környezeti biztonság megléte. Azt is mondhatjuk, hogy a szervezeti biztonság foglalkozik az összes mûködési kockázat menedzselésével. Mindezek együttes kezelése biztosíthatja csak a költség-hatékony döntéseket. Így az architektúrának az összes említett területet magában kell foglalnia.

Az általános modell képezi az alapját a szervezet biztonsági architektúrájának. A modellt az adott szervezet sajátságainak analízisével ki kell bontani és a biztonsági védelem végül az üzemeltetési architektúrában testesül meg.

Amennyiben az informatikai architektúra, a biztonsági architektúra nem szolgálja széles körûen a szervezet mûködését, nem ad valós támogatást a feladatok ellátásához, hanem csupán saját mûködésére, a biztonságra és ellenõrzésre összpontosít, akkor várhatóan nem fogja teljesíteni a vezetõk és felhasználók elvárásait. Az ilyen problémák általános jelenségek az információs rendszerek területén, nemcsak a biztonsági funkciókat érintik. Nem elegendõ összeállítani egy sor szervezeti követelményt, leírni azokat, majd betenni az irattárba, aztán kizárólag mûszaki szempontok alapján folytatni a rendszer tervezését.

A szervezeti célok egyediek, azonban biztonsági szempontból az alábbi alapvetõ funkciókat biztosítani kell:

mindezek teljesítésének szervezeti és szabályozási (szankcionálás!) feltételei.

A stratégiai célok biztonsági támogatásának módját, mértékét a kockázatelemzés alapján kell meghatározni. A biztonsági architektúra szervezeti vetületének tervezésekor a folyamatok vizsgálatakor merülhet fel elsõként a kockázatelemzés alapján a felsõszintû biztonsági stratégiákban meghatározott követelmények teljesíthetõségére a rejtjelezés/kriptográfia, digitális aláírás, illetve a nyílt kulcsú infrastruktúrák bevezetésének szükségessége. Ugyanebben a vetületben a menedzselés módjának meghatározásakor kell dönteni hol, milyen struktúrában mûködjenek a regisztrációs és hitelesítõ hatóságok, legyenek-e zárt felhasználói csoportok a távoli telephelyek, partnerek bekapcsolásával a szükséges biztonsági tartományok védelmi követelményeinek függvényében, illetve saját gyökér tanúsítványt, vagy külsõ hitelesítõ hatóság tanúsítványát használják-e a biztonsági tartományok felhasználói.

A tanúsítványok tartalmi, kibocsátási és alkalmazási követelményeit, lényegében a szolgáltatási irányelveket és szabályzatot (CPS), a logikai architektúra tervezés során kell elkészíteni, míg a technológiai hálózati és biztonsági architektúra - az elemek integrációja - a fizikai vetület kiviteli terveinek megvalósítása során alakul ki. Ekkor kerülnek telepítésre a számítógépes folyamatokat és kapcsolatokat vezérlõ protokollok, rögzítik a felhasználók tanúsítványaihoz/azonosítóihoz tartozó jogosultságokat, kivételeket, majd ezután kezdõdhet meg a próbaüzem.

A biztonsági rendszer tervezése során a sikeres architektúra, lényegében a mûködés/üzemletetés eredményessége érdekében a

támogatása szükséges.

Az architektúra tervezés egyik leglényegesebb követelménye az állandó, folyamatos kommunikáció a különbözõ felhasználókkal, vezetõkkel és alkalmazottakkal a célkitûzések, tervek megértetése és elfogadtatása céljából. Hasonlóképpen az architektúra tervezõ jelenti az összekötõ láncszemet a különbözõ szakterületek, érdekcsoportok, technológiaszállítók és kivitelezõk között. Nehézséget jelenthet sok más emberrel megküzdeni, akik nem értik meg a stratégiai architektúrát és azt hiszik, hogy mindez csak technológiai kérdés. Látni kell, hogy a sikeres architektúra tervezéshez jó kommunikációs képesség is kell, hogy el tudjuk adni az ötleteket és bizonyítsuk az elõnyöket mások számára is. Az egyik, legfontosabb tényezõ a legfelsõ vezetés támogatásának biztosítása. A szervezeti architektúra nem valósítható meg, ha a felsõ vezetõk legtöbbje nincs az oldalunkon. Az architektúra tervezõ és az architektúra modell feladata a sokszor bonyolult és speciális megoldások mindenki számára érthetõ vázlatát adni. Az architektúra tervezés eredményét a szervezet csak akkor élvezheti, ha minden tagja stratégiai módon gondolkozik és cselekszik. Az architektúra elfogadásához és támogatásához az ilyen környezet megteremtése valószínûleg egyike a legnehezebb feladatoknak, amellyel munkánk során találkozhatunk.

A munka során vissza-vissza kell térni, hogy a fentiekben felsorolt fõbb döntési szempontok figyelembe vétele megtörtént-e. A sikeres architektúra tervezõ mindig a szervezeti feladatok fogalmaiban gondolkodik, még akkor is, ha a legapróbb részletekkel foglalkozik. Célszerû gyakorta feltenni a kérdést:

különben elveszítjük a fonalat és minden klasszikus hibát elkövetünk a munkánk során.

A biztonsági rendszereket a szervezeti célkitûzéseknek és feladatoknak kell vezérelniük, ami alapján a szervezet munkafolyamatai számára strukturált összefüggések határozhatók meg a mûszaki, technológiai, a szabályozási és a feladatok végrehajtásának hosszú távú folyamatai között.





4.1. A nyílt kulcsú infrastruktúra és a virtuális privát hálózatok bevezetése.

A szervezet biztonsági architektúra tervezésének elõbbiekben vázolt folyamatában a kockázatelemzés alapján eldöntésre került, hogy szükséges a távoli felhasználók védett kommunikációjának biztosítása. A szervezeti architektúrában koncepcionális szinten állást kell foglalni, szükséges-e a nyílt kulcsú infrastruktúrák és a virtuális privát hálózatok alkalmazása, vagy például ez utóbbiak helyett saját tulajdonú, illetve bérelt hálózatokat célszerû-e inkább üzemeltetni. A döntés elõkészítése során a következõket kell megvizsgálni:

Igen lényegesek továbbá a politikai, jogi, szervezeti, info-kommunikációs technológiai és kereskedelmi szempontok is. A leglényegesebb tényezõk a nyílt kulcsú infrastruktúra bevezetéshez, melyek részletes kimunkálása a logikai tervezés során történik meg:

  1. A tanúsítási irányelvek és lehetõség szerint a hitelesítés szolgáltatási szabályzat elkészítése. (Meg kell határozni ki a felelõs egyikért, másikért.)

  2. A nyílt kulcsú infrastruktúra alkalmazások által használt cím és adattár szolgáltatások meghatározása és biztosítása.

  3. Az együttmûködõ képesség biztosítása.

  4. A szigorú azonosítás, egyszeri bejelentkezés, digitális aláírás, rejtjelezés alkalmazásának biztosítása a felhasználói szinten.

  5. A nyílt kulcsú infrastruktúra bevezetésének fázisokra bontott tervezése.

  6. Ahol lehetséges a regisztrációs eljárás integrálása a már meglévõ humánpolitikai, illetve biztonsági folyamatokkal, nyilvántartásokkal.

  7. A hálózat biztonsági infrastruktúra kialakítása, illetve a nyílt kulcsú infrastruktúra beillesztése a meglévõbe.

  8. A tanúsítási irányelvekben meghatározott biztonsági és üzemeltetési követelményeknek megfelelõen biztosítani kell a visszavonási listák (CRL-ek) lekérdezhetõségét. (saját CRL, on-line, központi)

  9. Dönteni kell, hogy a nyílt kulcsú infrastruktúra megvalósítása során csak nyílt, szabványos alkalmazások legyenek, vagy elfogadhatók a gyártófüggõ megoldások.

  10. Meg kell határozni a nyílt kulcsú infrastruktúra auditálásáért felelõs belsõ/külsõ szervezeteket, személyeket.

  11. A tanúsítványokkal kapcsolatos felelõsségvállalási és garanciális kérdések tisztázása.

  12. Meg kell határozni, hogy lejárt elektronikus aláírások érvényesség igazolását ki, mi módon és hány éven át kell biztosítsa.

4.2. A szolgáltatási szabályzat elkészítése

Külön kell szólnunk az elõzõ pontban említett tanúsítási irányelvek és a hitelesítés szolgáltatási szabályzat elkészítésérõl. Az irányelvek és a szabályzat meghatározó nemcsak az azonosítás, digitális aláírás bizalmi rendszere, hanem a VPN-ek biztonságos mûködtetése szempontjából is. A szolgáltatások normális vitele érdekében szabályozni szükséges legalább a

A sikeres bevezetés céljából ki kell adni a privát kulcsok és tanúsítványok kezelési útmutatóját és egy fejlesztési útmutatót a nyílt kulcsú infrastruktúra felhasználói alkalmazásainak fejlesztéséhez.

Az elektronikus aláírás törvényben definiált fokozott biztonságú, illetve minõsített hitelesítés szolgáltatók szolgáltatási szabályzatának és általános szerzõdési feltételeinek tartalmi, formai követelményeirõl egy 2001. szeptemberében megjelent kormányrendelet intézkedik. Örvendetes tény, hogy a 2001. év végére már három, a fokozott biztonság követelményeinek eleget tevõ szolgáltatót regisztrált a Hírközlési Fõfelügyelet[10].

A jelen anyag írásakor még csak tervezet szinten lévõ ETSI szabvány[11] és az RFC 2527 (mindkettõ legutolsó változata 2001. júliusi) alapján az általános célú szolgáltatási szabályzat fõbb témái a következõk lehetnek:

A fentiek közül a zárt felhasználói csoportra vonatkozó szabályzat természetesen csak a legszükségesebbeket tartalmazza. A VPN kliens szoftver és az azonosításhoz, rejtjelezéshez szükséges tanúsítványok kiadása elõtt a kijelölt hitelesítõ központnak meg kell kapnia a felhasználó (a tanúsítvány szolgáltató szempontjából az RFC 2527 szerint elõfizetõ, ezért a általában az „elõfizetõ” kifejezést használjuk) felelõsségvállalási nyilatkozatát, amelyben rögzítésre kerülnek a következõk:

  1. Az elõfizetõ tanúsítja a hitelesítõ központ számára, hogy a kulcs pár generálása biztonságos rendszeren történt, (amennyiben ezt nem a központ generálja a kártyán) és az elõfizetõ megtett, illetve meg fog tenni minden szükséges intézkedést bármilyen veszteség kizárására, a privát kulcs felfedése, illetéktelen használatának megakadályozására.

  2. Elvállalja, hogy a tanúsítványigénylési folyamat során a szükséges teljes és pontos információkat adta meg.

  3. Az elõfizetõ a tanúsítvány átvételével elismeri, és felelõsséget vállal, hogy az általa megadott és bemutatott minden információ, ami a tanúsítványban szerepel, megfelel a valóságnak.

  4. A tanúsítványt kizárólag a célnak megfelelõen, a szervezeti alkalmazások eléréséhez szükséges személyi azonosításhoz használja, hogy azokon elektronikus információcserét és tranzakciókat folytasson.

  5. Az elõfizetõ fel fogja kérni a hitelesítés szolgáltatót tanúsítványának visszavonására, amint kapcsolata megszûnik a szervezettel.

  6. Felkéri a hitelesítés szolgáltatót, a tanúsítvány azonnali visszavonására az elõfizetõ privát kulcsának bármilyen felmerülõ vagy feltételezett elvesztése, felfedése vagy másfajta nyilvánosságra kerülése, kompromittálódása esetén.

  7. A hitelesítés szolgáltató értesítéseit, felhívásait az elõírtaknak megfelelõen megválaszolja.

  8. Az elõfizetõ tudomásul veszi, hogy a hitelesítés szolgáltató visszavonja a tanúsítványt, amennyiben az elõfizetõ nem tesz eleget a fentiekben vállalt kötelezettségeinek.

5. Összefoglalás

A szervezeti biztonsági architektúra tervezés fõbb lépéseinek ismertetése során a zárt felhasználói csoportok nyílt kulcsú infrastruktúrája megvalósításának lehetõségeit, indokait vizsgáltuk meg. A szervezeti informatikai integritást öt önálló területen, a hálózat, a rendszerek, a felhasználói jogosultságok, az alkalmazások és a bizalmasság vonatkozásában kell biztosítani. A bemutatott tervezés az informatikai biztonságra terjed ki, de hasonló módon megoldandó a szervezet folyamatos mûködésének tervezése és a fizikai / környezeti biztonság feladata is.

A szervezeti célkitûzések teljesítéséhez szükséges informatikai támogatás - különösen több telephely, szoros partnerkapcsolatok esetén - szükségszerûen kiterjed az extranet alkalmazására. A külsõ hálózati kommunikációhoz gyakorta mobil eszközöket használnak. Az Internet technológiájú virtuális privát hálózatok (IP VPN-ek) igen költség-hatékonynak bizonyulnak mind a vezetékes, mind a vezeték nélküli kapcsolatok felépítésében, hiszen feleslegessé teszik a dedikált, bérelt összeköttetések létesítését, sõt a tûzfalak és az útvonal irányítók közötti hálózaton az IPSec protokoll nyújtotta rejtjeles védelmet is lehetõvé teszik. A belsõ hálózat és az alkalmazások védelme szempontjából azonban a nyílt kulcsú infrastruktúra által nyújtott, intelligens kártyás tanúsítványokon alapuló szigorú felhasználói azonosításra, az elektronikus aláírásra és rejtjelezésre van szükség.

A szervezeti biztonsági követelmények áttekintését követõen IP VPN-ek jellemzõit vizsgáltuk, megállapítva, hogy jelentõs védelmet csak a hardveres végpontokat és elektronikus tanúsítvány hordozókat, központi hitelesítés szolgáltatói adattárakat alkalmazó VPN osztályok nyújtanak. Az ilyen rendszerek a felhasználók szûkebb körére vonatkoznak, így a nyílt kulcsú infrastruktúra kiépítésének kezdeti szakaszában igen hasznosak. A tervezés során stratégiai szemléletre van szükség és már az elsõ zárt felhasználói csoport kialakításakor is gondoskodni kell az együttmûködõ képesség biztosításáról. Végül ez utóbbi támogatására röviden összefoglalásra kerülnek a tanúsítási irányelvekkel és szolgáltatási szabályzatokkal foglalkozó ajánlások legfõbb szempontjai.

6. Hivatkozások

  1. FBI's National Infrastructure Protection Center, SANS NewsBites Vol. 4 Bonus Issue The SANS Institute <sans@sans.org> Mon, 07 Jan 2002 10:15:07 -0700 (MST)

  2. Symantec Enterprise Security White Paper: Responding to the Nimda Worm 10/2001

  3. Gerencsér András: Digitális aláírás szolgáltatások architektúrája, Networkshop 2001. SOPRON 2001. április 18-20. http://nws.iif.hu/ncd2001/ 2002. 01. 21.

  4. Gene Schultz on the death of PKI and changes in consulting SANS NewsBites Vol. 4 Bonus Issue The SANS Institute <sans@sans.org> Mon, 07 Jan 2002 10:15:07 -0700 (MST)

  5. Netigy Corporation: Virtual Private Network (VPN) Design Guide. 2000.

  6. EUROPEAN COMMISSION – Enterprise DG PKICUG PROJECT Public Key Infrastructure for Closed User Groups, http://www.europa.eu.int/ISPO/ida/ 2002. 01. 21.

  7. GlobalSign, http://www.globalsign.net/customers/gov/index.cfm http://www.globalsign.net/partners/nap/bia.cfm 2002. 01. 21.

  8. William T. Polk and Nelson E. Hastings: Bridge Certification Authorities: Connecting B2B Public Key Infrastructures, National Institute of Standards and Technology, 2000. http://csrc.nist.gov/pki/rootca/ 2002. 01. 21.

  9. Zachman, John A.: "A Framework for Information Systems Architecture." IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or fax: 914-945-2018.

Zachman, John A. THE FRAMEWORK FOR ENTERPRISE ARCHITECTURE: Getting Beyond the “Legacy” © Copyright 1993-1996 Zachman International, Inc. All rights reserved.

  1. 16/2001. (IX. 1.) MeHVM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó részletes követelményekrõl, http://www.hif.hu/menu4/m4_8/16mehvmrend.pdf Elektronikus aláírással kapcsolatos nyilvántartások, a szolgáltatók adatai, szabályzata, stb.: http://www.hif.hu:7777/pls/portal30/ESIGN_PORTAL.menu.show 2002. 01. 21. (fokozott biztonságú szolgáltatók: Netlock, MATÁV, GIRO)

  2. Policy requirements for certification authorities issuing public key certificates, Draft ETSI TS XXXX STF 178-T2 draft D 30/7/2001



15