Exchange 2010 és az információ védelme – második rész

Folytassuk hát onnan ahol abbahagytuk…kis kiegészítéssel. Ér eltéríteni az eredeti gondolataimtól, levelek, megjegyzések (comment) formájában. Most is így történt. Eredetileg kétrészesre terveztem ezt a „sorozatot” de idoközben több visszajelzést is kaptam, hogy az AD RMS muködésérol is kellene egy írás. Így kicsit módosítva az elképzeléseimet és a bloggal kapcsolatos elvárásaimat, lesz egy harmadik epizód, ami témájában a blog eredeti céljától (Exchange Server) eltér.

A mai, második és így aztán nem befejezo bejegyzésben áttekintjük azt, hogy az Exchange Server és az AD RMS milyen találkozási-, milyen integrációs pontokkal rendelkeznek. Áttekintjük azt, hogy ezeket miként konfigurálhatjuk és azt is, hogy az integrációnak milyen elonyei vannak. Az olvasás során fogadjuk el azt kiinduló állapotnak, hogy már van egy jól muködo AD RMS szolgáltatásunk. Fókuszban az Exchange és az integráció.

Az AD RMS képes az elektronikus tartalmak titkosítására és arra, hogy a felhasználók jogait a dokumentumhoz „láncolja”. Ezzel az elektronikus tartalom tárolási helyétol függetlenítjük a jogosultság kezelését, tárolását valósítja meg. Ez a kívánatos és szükségszeruen a legjobb biztonsági megoldás, ahogy azt korábban már tárgyaltuk. Óvhatjuk és félthetjük a pénzes táskát a pénzszállítóknál, de egy ponton túl többszörös túlero ellen hasztalan. Ekkor a bankjegyeket megfestjük hogy azok használhatatlanok legyenek. Az AD RMS lényegében a bankjegy festo.

A következo táblázatban összefoglaltam az Exchange 2010 és AD RMS integrációs lehetoségeket:

Architektúra

Egy jó ábra mindennél többet elmond. Nézzük, hogy mennyire sikerült jól ez az ábra. A legfontosabb résztvevok az architektúrában:

• Active Directory címtár
• AD RMS kiszolgáló
• Exchange Server 2010
• Service Connection Point

A résztvevok közti összefüggés a következo:

• Az AD RMS kiszolgáló regisztrálja a Service Connection Point (SCP) objektumot az Active Directory címtárban. Ez az ábrán az 1-es lépés. Az SCP objektum a címtárban egy út jelzotáblaként fogható fel. Megmutatja azt, hogy az adott szolgáltatást hol kell keresnünk. Az SCP nem Exchange, és nem AD RMS funkció, ezt az Active Directory biztosítja. Vannak termékek amik használják, vannak amik nem. Az AD RMS a Configuration partíció alatt a Services/RightsManagementServices elérési út alatt hozza létre az SCP bejegyzését.
• Az Exchange Server alapértelmezésben az SCP alapján találja meg az AD RMS kiszolgálót. Az Active Directory-ban megkeresi az adott SCP-t. Ez az ábrán a 2-es lépés.
  • Ugyanígy találják meg alapértelmezésben az RMS kliensek is az AD RMS kiszolgálót. Lássuk be, az Exchange Server valójában egy AD RMS kliens. A felismerés sok további helyes következtetés levonására jó.
• Ha már tudja az Exchange kiszolgáló azt, hogy az AD RMS kiszolgálót hol érheti el, akkor gyakorlatilag minden adott ahhoz, hogy kommunikáljon vele. Az ábrán a hármas lépés az Exchange kiszolgáló és az AD RMS kiszolgáló közti kommunikációt szimbolizálja. A szükséges kulcsokat, tanúsítványokat az Exchange kiszolgáló az AD RMS kiszolgálóval való kommunikációja során kapja meg.
• Legvégül nézzük az RMS védett tartalmakat. Azok mindvégig az Exchange kiszolgálón vannak. A szükséges titkosítás / ki titkosítás, liszenszelési muveleteket a hármas lépésben az AD RMS-tol beszerzett kulcsok és tanúsítványok birtokában az Exchange kiszolgáló végzi. Tehát a levelek, levélmellékletek nem kerülnek át semmilyen formában az AD RMS kiszolgálóra. Ez több szempontból is fontos és hasznos tudnivaló.

Ami azt illeti az ábra nem tökéletes. Alaposan levan egyszerusítve. Mindegyik pont alapvetoen további részletekre bontható. Az Exchange kiszolgáló esetében ezt részletesen kibontjuk.

Logikus kérdés lehet, hogy melyik Exchange kiszolgáló kommunikál, az AD RMS kiszolgálóval? Ha nagyobb egységekben gondolkodunk akkor azt a kérdést is feltehetjük, hogy melyik Exchange szerepkör kommunikál az AD RMS kiszolgálóval?

A helyes válasz valójában függ attól, hogy melyik integrációs szolgáltatást használjuk. A következo táblázat funkciók szerinti bontásban megmutatja, hogy melyik Exchange szerepkör kommunikál az AD RMS kiszolgálóval:

Most már ismerjük az alap architektúrát és értjük azt is, hogy melyik szerepkör kommunikál, az AD RMS kiszolgálóval. Beszéljünk pár szót magáról a kommunikációról. A kommunikáció Web Service alapú (a Web Service-rol beszéltünk az Autodiscover tárgyalásakor, ha hiányzik a fogalom a fogalomtáradból, akkor lapozz vissza ide).

Az AD RMS több Web Service alapú szolgáltatást biztosít. Ezek közül az egyik ilyen szolgáltatás: Server Certification. Ez a Web Service teremti meg annak a lehetoségét, hogy kiszolgálók igényeljenek, kulcspárokat és tanúsítványokat. Fontos tudni, hogy az AD RMS-ben a Server Certification alapértelmezésben le van tiltva. Így az Exchange és az AD RMS integrációjának egyik fontos lépése a Server Certification engedélyezése. A letiltás lényegében azt jelenti, hogy senkinek sincs joga a Server Certification funkciót implementáló Web Service hívásához. Az engedélyezés ennek megfeleloen viszonylag egyszeru. Alapértelmezés szerint telepített AD RMS kiszolgáló esetében a C:\Inetpub\wwwroot\_wmcs\certification elérési út alatt található a ServerCertification.asmx. Ehhez a fájlhoz kell Read & execute jogosultságot adnunk minden Exchange kiszolgálónak. Ezt a lépést ha több tagból álló AD RMS rendszerünk van, akkor az összes tagon el kell végezni.

Az Exchange telepítokészlet egy Exchange Servers nevu biztonsági csoportot létrehozott. Ennek tagja minden Exchange kiszolgáló (a telepítés részeként bekerül a csoportba), így a jogosultság beállításakor alanyként használhatjuk ezt a csoportot.

A legtöbb titkosítás esetében fontos kérdés, hogy mi történik a kulcsvesztések esetén. Illetve fontos kérdésként szokott felmerülni az is, hogy van-e lehetoség arra, hogy a küldo és a fogadón kívül más is hozzáférhessen a tartalomhoz. Ez utóbbi esetben fontos kiemelni azt, hogy nem a használt algoritmusok gyengeségének vagy egy kiskapu kihasználásáról beszélünk. Itt arról van ilyenkor szó, hogy tudunk-e kontrollált módon olyan jogosultságot adni, hogy minden tartalomhoz hozzáférhet az alany. Az AD RMS tervezésekor ez a kérdés napirendre került és a tervezok úgy döntöttek, hogy lehetoséget teremtenek erre. Ez azért megnyugtató. Képzeljük el azt az esetet, hogy UserA titkosít egy dokumentumot amihez o és csak o férhet hozzá. Majd UserA bármilyen módon eltunik a rendszerbol. Mi történik ilyenkor a titkosított dokumentummal? Az AD RMS esetében ha úgy döntünk, akkor módunkban áll a dokumentum kinyitására. Természetesen ehhez a leheto legmagasabb jogosultsággal kell a rendszerben rendelkeznünk. Ezt úgy hívjuk az AD RMS esetében hogy Super User. Az AD RMS telepítése után a Super Users funkció kivan kapcsolva.

Ha szükséges bekapcsolhatjuk és hozzáférhetünk a tartalmakhoz. Az Exchange Server integrációja esetében ennek az AD RMS funkciónak különös jelentosége van.

Lássuk be: bizonyos integrációs esetek elvileg nem muködhetnek, hiszen az Exchange Server-nek nincs joga a titkosított tartalmakhoz. Példa: ha UserA küld egy védett dokumentumot UserB-nek, akkor az Exchange Server hogy képes azt kibontani és megvizsgálni? Super User jogosultság nélkül valójában sehogy. A következo integrációs szolgáltatások igénylik az RMS Super User jogosultság meglétét:

• OWA integráció
• Transzport decryption
• Journal Report decryption

Az AD RMS szolgáltatásban a Super Users funkció engedélyezése a következok szerint történik:

• Létre kell hozni egy Universal Security csoportot az Active Directory címtárban
• Létre kell hozni egy Disztribúciós listát (Distribution List) az Exchange-ben, az elozo pontban létrehozott Security csoporthoz tartozóan
• Engedélyezni kell az AD RMS konfigurációjában a Super Users funkciót
• Be kell állítani a korábban létrehozott csoportot, mint Super User csoport

A végeredmény így néz ki:

Egy csoportnak tehát megadtuk a jogot. De kit kell betenni a csoportba? Az Exchange telepíto létrehozott több rendszer postaládát is. Ezek közül a FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 rövid nevu és könnyen megjegyezhetot használja az Exchange. Tegyük be hát ezt a felhasználót a korábban létrehozott Super Users csoportba.

Ezzel eljutottunk az elokészítés végéhez. Egyszeru ugye? Ha van egy muködo AD RMS rendszerünk, akkor nem is kell más tennünk, mint engedélyezni a Server Certification funkciót és beállítani / engedélyezni a Super User funkciót. Ezzel készen állunk az integráció engedélyezésére.

Integráció engedélyezése

Ha minden adott, elo van készítve az integrációra az AD RMS rendszerünk, akkor a feladat roppant egyszeru. Két powershell parancs kapcsolódik az AD RMS integrációhoz:

• Get-irmconfiguration – segítségével lekérdezhetjük az Exchange IRM (Information Rights Management == AD RMS) konfigurációját
• Set-irmconfiguration – segítségével beállíthatjuk / módosíthatjuk az Exchange IRM konfigurációját

Az integráció beállításához nincs más teendonk, mint a következo powershell parancsot futtatni: set-irmconfiguration –InternalLicensingEnabled $true –verbose

A parancs segítségével a belso levélforgalmunkra vonatkozóan engedélyezzük az AD RMS integrációt. Az Exchange kiszolgálók SCP alapú felderítést fognak végezni az AD RMS kiszolgáló megtalálásához. De mit is kapunk pontosan azzal, ha lefut a parancs? Nézzük meg a get-irmconfiguration parancs segítségével:

A fenti powershell kimenetet fordítsuk le emberi nyelvre is:

Ezen a ponton ha elbizonytalanodtunk, akkor az értheto. Egyfelol másként hívja a powershell taxonómia az adott funkciókat, mint ahogy a marketing (ez nem ritka és a fejlesztés ilyen mértéku darabolása miatt van ez így). Másfelol az elozo táblázatból kiolvasható, hogy három funkcióhoz nem tartozik külön engedélyezés / tiltás (elevenítsük fel az összes integrációs lehetoséget – elso táblázat). A helyes magyarázat az, hogy ezeket a szolgáltatásokat valóban nem lehet önállóan ki- / bekapcsolni. Másként: ha az internalLicensingEnabled = $true érték, akkor a következo szolgáltatások be vannak kapcsolva, csak legfeljebb nem használjuk oket:

Logikailag most az következne, hogy demonstrálom az összes integrációs szolgáltatást. Azonban kósza kísérletet sem teszek erre. Az írásos forma nem kedvez ennek. Azonban a transzport házirend integráció kapcsán egy érdekes pont van, amire ki kell térnünk.

Transzport házirend integráció

Az egyik ha nem a leghasznosabb integrációs szolgáltatás a transzport házirenddel való kombinálás. Valójában az integráció elég egyszeru. A transzport házirendek szerkesztése során Exchange Server 2010 esetében rendelkezésünkre áll a „rigths protect message with RMS template” muvelet. Ezt a muveletet kiválasztva és specifikálva az adott RMS sablont, a levélre automatikusan rákerül a védelem. Jól hangzik ugye? A feltételeket pedig mi magunk határozhatjuk meg a transzport házirend összeállításánál. A transzport házirenddel a feltételek összeállítása során a levél fejlécét, törzsét és mellékletének tartalmát egyaránt vizsgálhatjuk. A gyakorlatban ez azt jelenti, hogy *nincs* olyan tulajdonsága a levélnek ami alapján ne tudnánk szurni. Ez elég megnyugtatóan hangzik. Ha ezt még kiegészítjük azzal a ténnyel is, hogy a transzport házirendek során van lehetoségünk RegEx kifejezések használatára is, akkor a lehetoségeink tényleg határtalannak tunhetnek (no persze lehetne ezt még fokozni).

Mi az a RegEx? A Regular Expression rövidítéseként szoktuk használni. Hogy mire való, azt egy példán keresztül lehet a legjobban érzékeltetni. A feladatunk a következo: a belso levelezésben azokat a leveleket amik bankkártya számot tartalmaznak védenünk kell AD RMS-el. Regular Expression kifejezés használata nélkül az összes lehetséges kártyaszámot a szabályban fel kellene tüntetni, az összes lehetséges írásmóddal. Lássuk be ez elég reménytelen, amikor a legtöbb kártyaszám 4*4 karakter hosszú. A Regular Expression ezt a feladatot teszi egyszeruvé. Ugyanis definiálhatom azt, hogy a keresett kifejezés (esetünkben a kártyaszám) hogy épül fel. Vagyis leírom az Exchange számára azt, hogy keresse azokat az értékeket amik a következoképpen néz ki: 4 számjegy után kötojel, vagy perjel, vagy szóköz ami után 4 számjegy, ami után kötojel, vagy perjel, vagy szóköz………..

A következo ábrán egy ilyen transzport házirendet láthatunk.

Az Exchange Server 2010 esetében a .NET platform biztosítja a RegEx használatóságát. Az elérheto kifejezések listáját pontosan dokumentáltuk, az elérheto a következo linken: Regular Expressions in Transport Rules.

Érdemes kiemelni, hogy a RegEx a transzport házirendben az AD RMS-tol függetlenül elérheto és használható. A „text pattern” típusú transzport házirendek RegEx típusúak, van belolük jócskán:

Zárszó

Messzirol indultunk, hiszen az elso részben áttekintettük általánosan azt, hogy miért jobb az adatot az adat rétegben megóvni. A második részben áttekintettük azt, hogy az Exchange Server 2010 milyen integrációs pontokkal rendelkezik. Áttekintettük azt is, hogy miként kell elokészítenünk az AD RMS infrastruktúránkat, valamint bemutattam hogy miként kell az Exchange rendszerben a szolgáltatást bekapcsolni. Végül, de nem utolsó sorban a transzport házirend integrációnál megvizsgáltuk a RegEx használhatóságát. Fontos kiemelnem azt, hogy ez kedvcsinálónak elegendo, de szakértok ettol még nem leszünk. De maradjunk a realitás talaján. Ha mindenki eljut idáig, akkor fokozhatjuk ezt tovább. Addig azonban még hosszú út áll elottünk, de minden Exchange és biztonságot kedvelo szakembert csak bíztatni tudok. Az integráció nem nehéz feladat, nem szabad túldimenzionálni. Az AD RMS szolgáltatás képességeit pedig mint egy ügyesen elhelyezett kiegészíto nagymértékben emeli, hiszen a szolgáltatás alapveto problémáját a felhasználót tudjuk kihagyni a rendszerbol.

Adós vagyok az ígért harmadik epizóddal, amin hamarosan elkezdek dolgozni.