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:

Integrációs lehetoség	Leírás
Transzport házirend integárció	A transzport házirendben jelenik, meg új muveletként egy AD RMS sablon alkalmazásának lehetosége. Segítségével automatizált módon, felhasználói beavatkozás nélkül, a levél tartalma, vagy a levélmelléklet (!) tartalma alapján végezhetjük el a titkosítást.
Transzport decryption	A levél továbbítása során a levelet és annak mellékletét „felbontjuk” szerver oldalon, hogy a leveleket a többi eszközünk segítségével hatékonyan ellenorizhessük. Példa: · víruskereso képes a titkosított állományokban is keresni; · SPAM és egyé tartalomszuro képes az eredetileg titkosított állományokban is keresni
Journal Report decryption	Amennyiben használjunk az Exchange Journaling funkcióját, abban az esetben lehetoségünk van arra, hogy a levelet titkositatlan formában tároljuk el a Journal adatbázisban.
Exchange search integráció	Az Exchange Serach enging képes lesz az eleve titkosított adattartalmakat is indexelni. Így kereshetové vállnak a védett levelek és mellékleteik is.
OWA integráció	Böngészo add-on telepítésétol mentes AD RMS védett tartalom eloállítását és „fogyasztását” teszi lehetové. Nem csak a levelekre, de a Web-Ready levélmelléklet formátumokra is igaz.
Unified Messaging integráció	A hangposta üzenetek védhetoek automatikusan, így a hangposta üzeneteinket nem kerülhetnek ki házonkívülre.
Prelicensing	Már az Exchange Server 2007 esetében is elérheto funkció, az Exchange kiszolgáló a védett anyaghoz tartozó Use Licence tanúsítványt a felhasználó nevében lekéri és mellékeli azt a levélhez.

 

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:

Funkció	AD-RMS-el kommunikáló szerepkör
Transzport házirend integárció	HUB-Transport
Transzport decryption	HUB-Transport
Journal Report decryption	HUB-Transport
Exchange search integráció	Mailbox
OWA integráció	CAS
Unified Messaging integráció	UM
Prelicensing	HUB-Transport

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:

Powershell érték	Alapértelmezett beállítás	Integrációs lehetoség neve
JournalReportDecryption	engedélyezve	Journal Report decryption
ClientAccessServerEnabled	engedélyezve	OWA integráció
SearchEnabled	engedélyezve	Exchange search integráció
TransportDecryptionSetting	opcionális	Transzport decryption
EDiscoverySearchEnabled	engedélyezve	Exchange search integráció

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:

Transzport házirend integárció

Unified Messaging integráció

Prelicensing

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.

Comments

• Anonymous
  January 01, 2003
  Nem bizony. Itt kimaradt egy logikai lépés, az az AD RMS működésének az ismertetése. Ugye azt feltételeztem, hogy ezt mindenki ismeri, majd később úgy döntöttem, hogy a harmadik részben majd leírom, hogy is működik az AD RMS.A lényeg a következő: neked mint felhasználónak soha nem kell hordoznod magaddal semmilyen kulcsot, semmilyen adathordozón. Az adatgazda amikor egy információt AD RMS-el véd, akkor egy úgynevezett Publishing License bekerül a védett anyagba (levél, dokumentum stb.). A fogadó amikor hozzászeretne férni az anyaghoz, akkor a Publishing License-t az anyagból kiszedve elküldi az AD RMS rendszernek. Ezen a ponton azonosítja magát a felhasználó az AD RMS rendszernél és ha: 1, sikerült az azonosítás; 2, a publishing license alapján a felhasználónak valóban van joga, akkor kiállít az AD RMS egy use license-t. A use license birtokában az alkalmazás pedig rendereli a tartalmat és a korlátozásokat érvényre juttatja.Az OWA (pontosabban a CAS) integráció esetében a publishing licence birtokában a use licence beszerzését az Exchange végzi on-behalf, a felhasználó nevében. A levélhez a use licence-t csatolja.Az egész folyamat a felhasználó számára transzparens, legyen az OWA integráció, vagy natív AD RMS használat. A felhasználó amit hordoz, az az információ benne a publishing licence, az AD RMS szerver eléréséhez szükséges információ (URI) és tudja a felhasználó nevét / jelszavát.Az egész AD RMS rendszer hasonlít a hagyományos PKI-hoz, DE NEM AZ. A kérdés helyes és köszönöm, rávilágított arra a tényre hogy érdemes lesz beszélni az AD RMS rendszerről!Így érthető?
• Anonymous
  January 01, 2003
  Tovább formálódik az igény az AD RMS bejegyzésre. :) Erre viszont már csak akkor kerülhet sor ha hazamegyek. Az még 1 hónap.Alapvetően jól gondolod, DE ez nem csak így működhet. Eldöntheted a tartalom létrehozásakor (pontosabban a védelem illesztésekor), hogy MINDEN alkalommal kell-e csatlakozni az AD RMS rendszerhez vagy sem. Ha mindig csatlakozni kell, akkor valóban a háttérben mindne alkalommal kapcsolódsz és kérsz egy Use Licence-t (UL). Ha nem kell mindig csatlakozni, akkor valójában csak egyszer kell azt megtenned. Vagyis megnyitod a dokumentumot és kapsz egy UL-t. Ezt az UL-t a későbbiekben is felhasználhatod, tehát offline is elérhető a tartalom. Az UL-ben pedig bent van az, hogy mit tehetsz meg és mit nem tehetsz meg azzal az információval, vagyis offline állapotban is tudja az alkalmazás (Office, OWA esetében nincs értelme offline-ról beszélni) hogy mit kell tennie. Az UL viszont géphez van rendelve, tehát másik gépen újra csatlakoznod kell az AD RMS-hez.A lényeg: mindent a megrendelő igényei alapján. Ha high-secure rendszert akarsz, akkor mindig csatlakoznod kell. Ha azt akarod, hogy a főnök a repülőn ülve a laptopján megtudja nyitni az RMS védett anyagot és nincs épp Internet elérése, akkor azt is megtudod tenni. És a kettő nem zárja ki egymást. Csinálhatsz ilyen és csinálhatsz olyan RMS sablont is és az adat besorolás függvényében egyik vagy másikat használod.
• Anonymous
  January 01, 2003
  Tehát ha nem érem el az RMS szolgáltatást (mert offline vagyok, vagy nem tudom magam authentikálni) akkor no way hozzáférnem a titkosított anyaghoz. Megnyugodtam ...
• Anonymous
  January 01, 2003
  Na jó. De mivel az adatszivárgástól indultunk, egy kis kekec. Ha OWA - n keresztül el tudom érni a titkosított tartalmat, akkor cipelnem kell a kulcsot a notebook - omon. Akkor nem ott vagyunk ahol a part szakad?