OWA?
Az Exchange Server egyik jól használható, előnyős komponense a beépített, HTTP-n keresztüli elektronikus levelezési lehetőség, az OWA (Outlook Web Access). Időtlen idők óta létezik, nálunk az Exchange 5.5-ös verziójának megjelenése óta áll nyitva ez a lehetőség a felhasználók számára. Egyszerű használni, tetszetős, csak IIS kell hozzá, a belső, switchelt hálózaton minimális terheléssel jár, bármelyik gépen használhatják a felhasználók és ha szükséges akár otthonról/távolból is. Az 5.5-ös változatot meg külön kellett telepíteni (a nyelvi csomagot meg még külön), az Exchange 2000-ben azonban nagyott lépett előre ez a szolgáltatás (főleg ha az első SP-t is telepítettük), mert alapesetben, az Exchange telepítése után bármilyen további konfigurálás nélkül működik (http://server_neve/exchange), a böngésző nyelvi beállításaitól függ a megjelenés nyelve, stb. Az Exchange 2003-ban pedig igazán kiforrott lett a termék, hiszen pl. léteznek böngészőtől függően eltérő változatok, spam és egyéb szűrők, jobb gombra helyi menü, többszörös műveletek, és még sok egyéb hasznos újdonság is.
Mi az Exchange 2000 óta nem is nyújtunk POP3 elérést a felhasználóknak, sem a LAN-on, sem kívülre (pontosabban kívülre igen, de csak VPN-en keresztül). Annak idején tartottam egy kicsit attól, hogy ez a "kényszerűség" problémákat okoz a diákok, de főleg a kollégák számára, de nem. Sőt... Viszont a hagyományos POP3 kliensekkel járó vírus/hordozhatóság/központi profil problémák miatt az üzemeltető számára valószínűleg ez a megoldás kényelmesebb, ha pedig megtekintünk egy Exchange 2003 OWA felületet, akkor rájöhetünk, hogy a felhasználóknak nyújtott funkcionalitás lassan 100%-osan megegyezik a hagyományos levelező kliensek által biztosítottal, így ők sem járnak rosszabbul. Az OWA-val kapcsolatos véleményem persze egy szubjektív, saját tapasztalaton alapuló vélekedés, ami természetesen vitatható, de én azért bátran ajánlom mindenkinek.
HTTPS?
Mindez szép és jó, marad azonban (legalább) egy probléma. A weben vagy akár a helyi hálózaton (a lényeg a HTTP) keresztül levelezni nem valami okos dolog napjainkban. A HTTP protokoll nem nyújt elég lehetőséget pl. a biztonságos hitelesítésre, vagy a csomagok titkosítására, elrejtésére. Mi az hogy nem nyújt eleget? Gyakorlatilag semmit sem. Velencén, a 2003-as rendszergazda táborban egy 5 perces bemutató keretében megmutattam, hogy a sima HTTP-n keresztüli OWA esetén, egy Network Monitorral (Network Monitor = a Microsoft legális hálózati sniffer programja, azaz a hálózati forgalom bitszintű elemzésére használhatjuk) egy apró, az interneten egyszerűen beszerezhető alkalmazással, a belső hálózatból az OWA forgalmat elkapva, pillanatok alatt elcsíphetjük a levelezők usernevét és jelszavát. Csak figyelni kell és kiszedni a forgalomból a lényeget, ennyi az egész. Ez eléggé kínos, de azért megoldás persze akad a kivédésére: alkalmazzuk a HTTPS-t! Ez megoldaná a biztonsági problémáinkat, hiszen az egész forgalom láthatatlanna válna, pontosabban látható pl. a fentebb említett Network Monitorral, de csak egy nagy adag zagyvaságot látunk, hiszen a HTTP forgalom "becsomagolva", átalakítva kerül majd a szemünk illetve a sniffer elé.
A HTTPS alkalmazása során az IIS-t felruházzuk ezzel a képességgel, azaz HTTPS webkiszolgálót faragunk belőle. Aztán az egész webszerverre vagy annak adott mappáira (pl. az OWA esetén kifejezetten az Exchange virtuális mappára) engedélyezzük vagy kötelezővé tesszük (inkább) az ilyen típusú forgalmat. De még mindig nem árultam el a lényeget: a HTTPS használatához legalább egy tanúsítványra (Certificate) szükségünk lesz.
Tanúsítvány?
Egy (nyilvános kulcsú) tanúsítvány egy olyan digitálisan aláírt dokumentum, amely a saját kulccsal rendelkező személy, eszköz, szolgáltatás vagy szervezet azonosságához köti a nyilvános kulcs értékét. Egy a nyilvános kulcsot használó infrastruktúra (PKI = Public Key Infrastructure) pedig olyan digitális tanúsítványok és hitelesítésszolgáltatók (CA = Certificate Authority) rendszere amely a nyilvános kulcsú titkosítás segítségével ellenőrzi és hitelesíti a forgalmazásban részt vevő felek jogosultságait. Tehát nekünk is egy ilyen infrastruktúrát kell felépítenünk, szerencsére elkészíteni lényegesen egyszerűbb mint ahogy hangzik :D. Persze egy tanúsítvány több célra is használható: adatok tikosítására (mint e cikk témája esetén látható), adatok digitális aláírására (pl. hiteles elektronikus levelek, dokumentumok), vagy adatok digitális aláírására ÉS egyúttal titkosítására vagy például digitális aláírásra ÉS intelligenskártyás bejelentkezés megvalósítására (SmartCard). Ebben a cikkben nagyon mélyen nem kívánok belemenni ezen részletekbe, így kanyarodjunk vissza a cikk témájához, azaz folytassuk azzal, hogy honnan szerzünk tanúsítványt a webszerverünkhöz, hogy végre nyugodtan hátradőlve használhassuk a HTTPS protokollt.
Erre két módszer létezik. Vásárolhatunk egyet pénzért illetve kreálhatunk egyet, ingyen. Tanúsítványt vásárolni egy kőkemény biztonsági feltételeknek megfelelő, minősített, legfelső szintű tanúsítványkiadó cégtől lehetséges. Magyarországon (tudomasom szerint) jelenleg kettő ilyen létezik, a Netlock Kft. és a MÁV Informatika Kft. Egy kötött rendű, bonyolult eljárás során rengeteg iratot és adatot kell benyújtanunk, amely igazolja hogy a kérő az valóban az intézményünk, valamint az intézmény feljogosított képviselője valóban az, akinek mondja magát. Ha minden szükséges előfeltétel megvalósul, akkor beadhatjuk (feltölthetjük) az IIS-ünk által kreált kérést (digitális formában, azaz ez egy .txt állomány), majd erre egy hosszabb (néhány hetes) időtartam után (amikor is ellenőrzik a fenti adataink valósságát) cég generál egy tanúsítványt, amelyet letölthetünk, és amely immár digitálisan és hitelesen igazolja azt, hogy ennek birtokosai valóban mi vagyunk. Ergo ha valaki ezután a tanúsítvánnyal ellátott weblapunkra vagy a weblap adott részeire (pl. az OWA) érkezik, akkor számára a tanúsítványban foglaltak alapján a tanúsítványkiadó cég garantálja, hogy a mi tulajdonunk a tanúsítvány, tényleg mi alkalmazzuk azt. Ezt tesszük azért hogy bátran mehessen a forgalom titkosítva, azaz például az elektronikus levelek olvasása az OWA-nkon keresztül.
