Ügyfélnél

A Microsoft nem értékesít közvetlenül, licenceit a partnereink keresztül adja el. Egyedül a MCS szolgáltatásait "kínáljuk" direktben, de az tanácsadás és nem szoftver. Így aztán úgy tűnhet, hogy távolabb vagyunk az ügyfelektől, mint egy átlagos vállalat. Nem így van. Közvetlenül is járjuk a vevőinket, mert a szoftver nem adja el magát: a dolgok hasznosságáról egy Microsoftosnak kell a legtöbbet tudnia – az érékesítési modell más lapra tartozik.

A csoportot, amelynek TSP-ként a tagja vagyok Bátorfi Péter vezeti. Az első napookban mondta még, hogy az ügyfélnél töltött idő (customer face time) a lehető legértékesebb: mi vagyunk azok, akik a leghitelesebben adhatjuk át a technológiai vagy bármely egyéb kategóriába tartozó tudást, mi lendítjük át az ügyfelet a holtponton, győzzük meg olyasmiről, amiben azelőtt kételkedett, végeredményben pedig felgyorsítjuk az a folyamatot, amelynek eredménye az árbevétel. (Egy kereskedelmi részen dolgoznánk elvégre ;-))

A múlt héten a meggyőzés élménye erősítette bennem, hogy jó helyen keresem a kenyerem. Egy olyan ügyfélnél jártam, ahol a biztonság kiemelkedő jelentőségű. Azt a feladatot kaptam, hogy mutassam be nekik, hogyan lehet egy OWA-t biztonságosan kipublikálni. A helyzetemet három dolog nehezítette. Először is OWA kipublikálást már csináltam ugyan, de azért mégsem jártam körbe minden eshetőséget, minden apróságot a témában. Kicsit irodalmazva hamar rájöttem, hogy ez a téma erősen kötődik az ISA-hoz, a 2006-os verzióban pedig épp ez volt az egyik terület, amelynél hatalmas az előrelépés. Lényegében egyetlen napom maradt, hogy OWA-ISA2006 témában mindent összegyűjtsek. Harmadik tényezőként az nehezítette a helyzetet, hogy a hallgatóságom (legalábbis egy része bizonyosan a) "Microsoft? Ha lehet, ne!" attitüddel ült le a témához.

Helyet foglaltunk, és megkértem őket, hogy beszéljenek egy kicsit a helyzetről. Nos, a feladat egyszerű: vezérigazgatói elvárás, hogy az OWA az utolsó Internet kávézóból is legyen elérhető. Eddig nekik egy "szuper-biztonságos", "nagyon bonyolul", "nagyon drága", "nagyon sokat tudó" védelmi rendszerük épült ki, erre tessék, most át kell lyukasztani a tűzfalakat, mint egy szitát, oda a biztonság. Ráadásul a főnök nevét és jelszavát ellopják billentyűzet-figyelővel (keylogger), és huss, már szállnak is a bizalmas adatok elfelé. "Szóval erre gondoltok, ugye?" – és feldobtam az alábbi ábrát

 

 Igen! Pontosan erre gondoltak. Az OWA tartománytag, és mint olyat csak "lehetetlen" módszerekkel helyezhetjük a DMZ-be. Ez nem biztonságos! Ez minden, csak nem biztonság! Egyetértettem velük.  Node, mi akkor a biztonság? Összegyűjtöttem néhány elvárást és felsoroltam őket, nagyjából az alábbiak szerint:

  • A forgalom titkosítása. – Az világos, hogy a kliens szerver, továbbá aszerverek közötti forgalom titkosítható legyen
  • A tűzfal nyitott portjainak megszüntetése. – Drasztikusan csökkenteni kell a nyitott kapuk számát és így a támadási felület nagyságát 
  • Az SSL forgalom vizsgálata. – Mégha titkosítottuk is a kapcsolatot, akkor is jó lenne belenézni, hogy mi áramlik a csatornában. Vírusvédelemre lenne szükség például
  • A HTTP/HTML szabvány ellenőrzése – Ha már felbontottuk a SSL csatornát, akkor ki kellene szűrni minden olyan HTML kódot, amely potenciálisan veszélyes, nem odavaló, az OWA-ra nm jellemző stb.
  • A bejövő kapcsolat előzetes hitelesítése. – Még azelőtt kellene a kapcsolatot hitelesíteni, hogy egy TCP csatorna felépülhet tartománytag gép és nem tartománytag eszküz között, ezzel is elszigetelve a védendő rendszereket.

Ezzel egyetértettek, ha lenne egy ilyen megoldás, az tényleg megfelelne nekik, feltéve, ha még azt is el lehet érni, hogy egy gépen ne maradhasson tartományi fiók és jelszó, sőt az le se lehessen lopni. Ezt a megoldást ajánlottam nekik:

 Rakjuk az OWA-t a belső hálózatra, a DMZ-be pedig tegyünk ISA-t (persze az ISA lehetne például a belső tűzfal, de ennél az ügyfélnél ez a lehetőség csak teoretikus). Az ISA működhet munkacsoportban, máris nincs szükség a tűzfal szitává lyuggatására. Képes SSL megszakításra és újra felépítésre, vagyis a 443-as csatornán zajló forgalmat megállítja, a titkosítást eltávolítja, a forgalmat URLScan vagy bármi egyéb beépülő modullal, vírusellenőrrel stb. megvizsgálja, végül egy új SSL csatornát építve fel továbbítja a belső hálózaton üzemelő OWA Front-End kiszolgálóknak. A legnagyobb dobás azonban a hitelesítés, mert képes az OWA helyett (26 nyelven) OWA bejelentkező képernyőt produkálni, így az anonim kapcsolatot hitelesíteni, még mielőtt a kérés az OWA kiszolgálóhoz elérne.

Jó, jó, de mi lesz a keyloggerrel? Gonosz konkurrencia elcseni a jelszót, aztán már hiába minden ellenőrizgetés. Nos, van erre is megoldás, ahogy az alábbi táblázat jól összefoglalja:

Az űrlap alapú hitelesítés történhet Felhaaználónév/jelszó; Felhasználónév/Passkód vagy mind a három egyidejű megadásával. Passkódot a SecurID és hasonló hitelesítési eljárások kérnek. Ez egy állandóan (percről percre) változó kód, amelyet minden hitelesítéskor egy apró kis készülékről kell leolvasni. Élettartama pár perc, vagyis ez jó közelítéssel ún. egyszer használatos hitelesítési adat (One Time Password, vagy OTP). No, ezt lelophatják billentyűzet-figyelővel.

Itt a vége a történetnek. A kollégák megnyugodtak: VAN biztonságos publikálási módja az OWA-nak, most már csak a költségeket kell összeszedni. Az előadás végeztével még a IT biztonsági vezetővel váltottam pár szót: igen, beszélhetünk a Rights Management Server-ről is. OK. Jövünk és megmutatjuk.

7 Responses to Ügyfélnél

  1. Tako says:

    Azt nem lehetne, hogy eljönnél hozzánk és bemutatnál nekem sok-sok mindent? Igaz, tuti, hogy nem fognak venni semmit se a főnökeim de én nagyon boldog lennék :) Valahol az alapoknál kezdenénk és én kérdeznék jó sok hülyeséget! na? :)))

  2. Tako says:

    (no name) = Takoca
     
    Tamás kérlek írj egy rövid bejegyzést róla hogy hogy a fenébe lehet úgy bejelentkezni hogy tudja ez a ***** hogy ki vagyok!
    ahogy nézem másnak se megy :(

  3. Tamas says:

    A munkámról még fogok írni, elhelyezve magamat a nagy egészben. Akkor megírom, hogy hova és mikor megyünk ki, az alapján majd elndöntöd, hogy meg tudunk-e jelenni nálatok. A bejelentkezéssel kapcsolatban az a tanácsom, hogy a profilodba vegyél fel egy képet (lehet az egy kis rajzocska is, mindegy) Ha azt a kis képet látod miközben írod a kommentet, akkor tudni fogom, hogy ki voltál. Egyébként anonim lesz a komment. Nekem legalábbis ez a tapasztalatom.

  4. Unknown says:

    Szia Tamás!Biztos bennem  van a hiba, szerettem volna e-mailt írni neked, de a webnaplódból nem derül ki a címed…Gratulálok az új munkádhoz!Amúgy Outlook HTTPS és OWA problémáim vannak. E-mail-emet tudod, keressél meg légyszi!

  5. snefi says:

    hat eleg erdekes azert hogy kiepitenek egy kelloen magas biztonsagi szintet de mellete semmi szakmai dolgot nemolvasnak el…..
    ha google-ban rakeresek akkor is egy csomo talalta van es talan meg webcast is hogy hogy lehet megoldani…
    erdekes szakmai hater lehet annal az ugyfelnel…..
    vagy rosszul gondolom?

  6. Tamas says:

    Ki vagyok én, hogy minősítsem az ügyfelet?😉
    A tájékozatlanság betudható annak is, hogy az ügyfél kevéssé preferálja az MS szoftvereket. A maguk területén (Unix, sun, java, iSeries stb.) biztosan járatosabbak. Nem kell azonnal rosszra gondolni
     
    Az e-mail címem ide sem írom le, biztonsági okokból, pontosabban a gépek számára nem írom le. Mert egyébként mind a gmail-ben, mind pedig a hotmail-ben a lepenyet előtag szerepel a kukac előtt.

  7. Tamas says:

    Js, és légyszi kövessétek az egyik előző megjegyzésben leírtakat, mert így tényleg nem tudom kinek kellene válaszolnom. :-(

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: