Exchange 2010 és az információ védelme – első rész

Egy egészen érdekes területre fogunk ebben a két részesre tervezett bejegyzésben kalandozni. Önzo módon a számomra két legkedvesebb szakterületet fogom ötvözni. Ez pedig a levelezés és a biztonság. Túlzás nélkül, könyveket lehetne megtölteni a biztonságos levelezés cím alatt. Nem is túl pontos a kifejezés, hiszen mi az, hogy biztonság? Mi az, hogy biztonságos? Ez túl tág fogalom. Pedig nap, mint nap mindenki használja ezeket a kifejezéseket az üzleti informatikában:

• „legyen biztonságos”,
• „a biztonsági szempontokat ne hagyjátok figyelmen kívül”
• „az adatbiztonság nálunk nagyon fontos”

Belénk nevelodött a hosszú évek alatt az, hogy a biztonságra figyelni kell, de tapasztalatom alapján az alapok sok esetben hiányoznak, így aztán a fogalmak, majd késobb a megoldások egy légüres térben lebegnek, súlytalanul. Amint ezen a légüres teret határoló képzeletbeli falon egy hajszálrepedés megjelenik, azon keresztül az egész egy pillanat alatt elillan, ködbe vész. A külso nyomás hat ránk.

Nem vállalkozom arra, hogy a világ biztonsági képletét megfogalmazzam. De arra vállalkozom, hogy a mai témakört egy általánosan elfogadott, nem Microsoft találmány szerinti vázba helyezzem be, ami a külso nyomásoknak jobban ellenáll.

Mélységi védelem

A tuzfalak világa amióta ido az ido, számomra vonzó volt. Eleinte csak távolról szemléltem ezt a világot, gyujtöttem a tudást és a tapasztalatot, majd késobb hozzáfogtam a tervezéshez és építkezéshez. Már az elso fázisban feltunt, hogy a szakértok sokszor azt mondták: tegyünk egymás mögé két eltéro típusú tuzfalat, ezzel biztonságban lesz a rendszer. Ez logikusnak tunt egy ponton, de nem értettem teljesen a helyzetet. Miért kell egy második tuzfal? Hát az elso nem elég jó? Vajon ha az elso tuzfalat kompromittálják, akkor a másodikat nem fogják tudni egyszeruen kompromittálni? Ezek a kérdések forogtak a fejemben, míg nem egy szép napon teljesen új értelmezést nyert számomra ez a terület. Kaptam egy tippet. A tipp pedig a mélységi védelem fogalma volt. Azt mondták a téma neves szakértoi, hogy nézzem meg a mélységi védelmet és meg fogom érteni. Jelentem így 10 év távlatából is, megnéztem és megértettem. Csakhogy a mélységi védelem nem mondja azt, hogy több különbözo tuzfal egymás mögött jobb. Szó nincs errol. Ez a természetes emberi reakciónk eredménye: ami komplikált azt egyszerusítjük, ami egyszeru azt pedig komplikáljuk…

Ha a mélységi védelem nem a tuzfalakról és azok verziójáról szól, akkor mirol? A gondolat eredetileg a hadsereg tudományvilágában fogalmazódott meg. A célja az volt, hogy bontsuk rétegekre a védelmet és lehetoségeinkhez mérten ezekben a rétegekben védelmi technológiák felhasználásával óvjuk az értéket, vagy akadályozzuk meg a „betörést”. A modern IT-vezérelt világunkban, az IT biztonságban a mélységi védelmet alkalmazzuk. Tudattalanul is. Hiszen külön védjük általában hálózati rétegben az adatokat, a munkaállomásokat és kiszolgálókat, kialakítottunk DMZ (Perimeter) hálózatot stb. Tudattalanul is tesszük mindezt és sokszor nem is rosszul. De mi lenne az eredmény, ha mindezt tudatos építkezéssel végeznénk el? A kérdés költoi, hiszen az egyszerubb utat, a „ne gondolkodjunk, csak még egy tuzfalat tegyünk le, vagy a tuzfalat is védjük tuzfallal” mentalitást könnyebb követni. Definiáljuk a mélységi védelem modern IT biztonságban használatos rétegeit:

 

• Szabályok, folyamatok, tudatos felkészülés – ez nem technológia
• Fizikai biztonság – technológia, de általában nem IT technológia
• Perimeter – a perimeter hálózat és a DMZ hálózat kifejezések csereszabatosak; a perimeter hálózatban beszélünk általában tuzfalakról
• Belso hálózat – az adott IT infrastruktúra belso hálózata; kiváló védelmi technológia lehet az IPSec
• Gép – a belso hálózaton muködo számítógépekrol van szó, amelyek védelme szükséges; kiváló védelmi technológia a gép szintu tuzfalak, vírusvédelmi rendszerek használata
• Alkalmazás – a gépeken muködo alkalmazások, napjainkban a legnagyobb veszélyforrást ezek jelentik; védelmi technológiák elsosorban a biztonságos programozás, a helyes patch management folyamatok és technológiák alkalmazása
• Adat – a valódi érték valójában az adat, amivel dolgozunk, nem kihagyható, megkerülhetetlen az adatrétegben történo védekezése

Tehát a mélységi védelem valójában az, ha ezekben a rétegekben egyaránt megvalósítjuk a védelmet. Ha csak újabb és újabb tuzfalakat helyezünk egymás mögé, akkor azzal legfeljebb a Perimeter (DMZ) hálózatunkat tesszük komplikáltabbá, nehezebben kezelhetové, ami egy ido után automatikusan csökkenti a rendszerünktol elvárható biztonsági szintet.

Reálisan áttekintve az látható, hogy úgy általában az informatikai rendszerekre jellemzo, hogy többé-kevésbé rendelkeznek szabályokkal és folyamatokkal, a fizikai biztonság ki van alakítva, rendelkeznek Perimeter (DMZ) hálózattal, a belso hálózaton elérheto védelmeket kevésbé használják, a gép szintu védekezés igazán ritka, az alkalmazások védelme vegyes és legvégül az adatréteggel szinte alig foglalkozunk.

Információ védelme az adatrétegben

Fókuszáljunk egy kicsit az adatrétegre. Egy helyesen kialakított adatrétegbeli védelem valóságos kincs. Összeszámolni sem tudom, hogy az elmúlt 5-8 évben hány olyan alkalom volt, amikor arra kellett választ találnom, hogy hogyan lehet az adatok illetéktelen eltulajdonítását megakadályozni. Az utóbbi 1-2 évben pedig igazi sláger termékké notte ki magát a különbözo adatszivárgást megakadályozó termékek piaca. Ragadjunk le ezen a ponton egy pillanatra. Mi a helyes módszer arra, hogy az adatokat az adatrétegben védjük? A válasz: titkosítás. Soroljunk fel néhány ide illeszkedo titkosítási implementációt:

• EFS – fájlrendszerben elérheto szimmetrikus kulcsú titkosítás
• S/MIME – nyíltkulcsú architektúrára épülo aszimmetrikus kulcsú titkosítás a levelezésben
• PGP – összetett titkosítási eljárás széles felhasználás körrel
• AD-RMS – nyíltkulcsú aszimmetrikus kulcsú titkosítás

Egy helyesen megválasztott tikosítással védett információhoz, még ha meg is találjuk az utat, egy kriptográfiai problémával fogjuk magunkat szembetalálni. Hiába szereztük meg az adatot, a megfelelo kulcsok birtokában nem férünk hozzá. Jól hangzik? Naná! Titkosítsuk hát az adatokat.

Ezen a ponton érdemes egy kis kitérot tenni. Az adatok elvesztésébol eredo IT fenyegetettség növekvo tendenciát mutat. Ezért védekezünk ellene. Ebbol ered az adatszivárgást érzékelo és megakadályozó technológiák terjedése, ami slágertermék napjainkban. Azonban ezek a technológiák a lehetetlen ígéretével állnak elo. Azt ígérik, hogy minden csatornát ahol az adatok közlekedhetnek, felügyelnek és az adatmozgást kontrollálni tudják. Bátran le merem írni azt a véleményt, hogy ez egyszeruen nem igaz. Minden csatornát nem lehet kontrollálni. Drága idonket és IT költségvetésünket ne egy olyan technológiára áldozzuk ami szélmalomharcot vív. Valóban az összes számítógépet, az összes hálózati protokollt, az összes kommunikációs csatornát képes egyetlen szoftver lefedni? Valóban meg tudja ezt tenni megfelelo teljesítménnyel? Valóban tartani fogja az adott szoftvergyár a lépést a világgal és az újabb és újabb technológiákra fel fog készülni? Vagy ha nem készül fel, akkor készen állunk arra, hogy lemondjunk az innovációról és fizetünk azért, hogy ne használjuk az új technológiákat? Nem kell túlságosan messzire menni, csak nézzünk körül, hogy milyen IT eszközök jelennek meg a hálózatunkon. Az IT Consumerization visszatarthatatlanul itt van. Tehát azt tanácsolom, hogy az adatainkat az adatrétegben védjük meg inkább olyan módon, hogy még ha az adat kiszivárog (az adat és nem az információ) a hálózatról, azt illetéktelen ne tudja megnyitni. Ezt kialakítani sokkal életszerubb, mint az adatkiszivárgást megakadályozni. Helyezzük a védelmünket racionális alapokra és hagyjuk az irracionális megközelítést. Minden csatorna? Ugyan már...

Hosszú bevezeto után elérkeztünk az Active Directory Rights Management Services (ADRMS) szolgáltatásunkhoz (kihagyva a fenti felsorolásban megjeleno titkosítások összehasonlítását). Az AD-RMS valójában az adatrétegre fókuszál. Az adatokat titkosítja és az adatrétegbe beágyazza a jogosultságot. A titkosítás egyszeruen értheto fogalom. De mit takar az a képesség, hogy beágyazza a jogosultságot? Ez azt jelenti, hogy a dokumentumban titkosított módon van tárolva az az információ, hogy ki milyen jogosultsággal rendelkezik a dokumentum felett. Vagyis teljesen függetlenül attól, hogy az a dokumentum hol van: egy internet kávézó számítógépén, egy otthoni gépen, vagy a védettnek gondolt céges belso hálózaton, ugyanúgy csak az az egy felhasználó érheti el a dokumentumban tárolt információkat. Ez paradigmaváltás. Eddig az adatainkat komplikált fájlszerverek, fájl és megosztási szintu jogosultságaival próbáltuk szabályozni és amint azok a dokumentumok kikerültek a fájlszerverrol, máris önálló életet kezdtek élni. Vagyis bárki akihez eljutott a dokumentum, a benne tárolt információkat elérhette, olvashatta, továbbküldhette. Ezzel szemben az ADRMS segítségével a dokumentumba beágyazva tárolhatjuk a jogosultságot. Vagyis szivárogj adat (és nem információ), juss ki USB kulcson, emailben, Interneten keresztül nyugodtan, hiszen az adat helye többé nem befolyásolja azt, hogy az adatból ki jogosult az információt kiszedni. Ha ehhez még azt is hozzáadjuk, hogy az ADRMS titkosítja is az adatokat, akkor a kép egészen megszépül. Ez nem valamiféle szélmalomharc. Az adatok védelme sokkal inkább elérheto, mint az, hogy minden csatornán áthaladó minden adatot felügyelünk.

Az adatok védelmének egyetlen nehézsége van csupán, ami régóta gátja is annak, hogy ez terjedjen. A gát a felhasználó. Ha a felhasználóra bízzuk azt, hogy az adatréteg védelmet elvégezze, akkor hagytunk a rendszerben egy hatalmas rést. Az RMS elso verziója velünk van 2006 óta. Mégsem terjedt el. Ennek több oka is van. Az egyik, hogy keveset tud róla az IT világ, a másik pedig az, hogy a munka oroszlánrésze a kezdetek óta a felhasználó vállát nyomja. Vagyis a felhasználónak kell a védelmet a dokumentumokra, levelekre rátennie. Ez pedig a már korábban említett rést eredményezi. Mennyivel jobb volna, ha egy automatizmus ezt a végfelhasználó helyett elvégezné?

Nos ez az automatizmus mára valósággá vált. Az ADRMS integrálható:

• Fájl szerverrel – Windows Server 2008 R2 alapú fájl szerver esetében a fájl classification segítségével a dokumentumokat kategorizálhatjuk és a kategóriák alapján ADRMS segítségével titkosítható és védheto és mindezt teljesen automatizálva
• Sharepoint rendszerrel – egy SPS rendszerben tárolt dokumentumok a dokumentumtáron beállított tartalomvédelmet automatikusan megkapják
• Exchange Server 2010 – teljesen integrálható az Exchange kiszolgálóval, a következo részben ezt fogom bemutatni.

Ez a blog elsosorban az Exchange Serverrol szól, ezért az ADRMS muködését részletesen nem írom le, minden érdeklodotol ezúton is elnézést. Ha igény van rá, akkor jelezzétek és keresek rá fórumot ahol azt megírhatom. Addig is további információt az ADRMS-rol itt találhattok.

Definiáltuk hát a problémát, keretet adtunk a tartalom- és információvédelemnek. Láthattuk azt is, hogy automatizálható a tartalomvédelem és a legnagyobb problémát, a felhasználót részben, vagy egészben kiküszöbölhetjük a rendszerbol. A következo részben ígérem, az Exchange-re fogunk fókuszálni és részletesen át fogjuk nézni az integráció lehetoségét.

Ha szeretnéd tudni, hogy miként védheto meg automatikusan egy dokumentum vagy egy levél, ami tételezzük fel, hogy bankkártya adatokat tartalmaz, akkor ne hagyd ki a következo részt.

Comments

• Anonymous
  January 01, 2003
  Sűrű napjaim vannak, de igyekszem mihamarabb megírni a második részt. Jövő hétvégén elutazom, így az a terv, hogy addig befejezem.Ha van igény és érdekel néhány embert, akkor tehetünk kivételes kitérést az Exchange témakörtől az AD RMS-re. Esetleg egy extra harmadik részben.
• Anonymous
  January 01, 2003
  Izgalmas téma. Várjuk a folytatást. És az RMS is valóban "megérne egy misét".