Mobileszköz-menedzsment és annak biztonsági aspektusai A következő néhány percben a mobileszközök-menedzsmentről és annak biztonsági aspektusairól lesz szó, de annak nem elsősorban a "klasszikus" értelemben vett biztonsági, hanem elsősorban üzembiztonsági aspektusairól. A biztonsági szempontokat, mint minden általában a funkcionális igényekkel kell összevetni, illetve megvizsgálni hogy az egyes piaci szereplők eszközei miként és milyen megoldásokat szállítanak. De menjünk egy kicsit vissza az időben, és nézzük meg, hogy honnan is fejlődtek ki a jelenleg elérhető rendszerek. Ádor István 2015. március

Hogyan kezdődött… 2000-es évek elejétől napjainkig Application Gateway MS ActiveSync Mobile Device Management Enterprise Mobility Management Valamikor a 2000-es évek elején speciális appliance-ek jelentek meg a piacon, amik alkalmazás gateway-ként az akkori meglehetősen kis felbontású javarészt fekete fehér kijelzővel rendelkező készülékekre pl.: Nokia 6310i, 6600, stb. Ilyen eszköz volt a Nokia One Business server, illetve a Symbian rendszerekhez a SyBase Afaria. Ez idő tájt a készülékek központi menedzsmentje még nem volt cél. És hát tegyük hozzá, hogy az akkori biztonsági követelmények sem feleltek meg a mai elvárásoknak. Akkor még bőven elég volt egy privát APN, amivel az eszközöket, pontosabban a SIM kártyákat be lehetett azonosítani. Ennek a korszaknak a végét jelentette a WiFi lefedettség térnyerése, mert ezek a kontrollok csak 2G-s, 3G-s hálózatban működtek. Nagyjából ebben az időben jelent meg az Exchange-ben az ActiveSync funkció! Ez volt az áttörés, ami felgyorsította az eseményeket. „Szabványos" interface-en keresztül már nem csak a leveleket, kontaktokat, hanem szinte a teljes Exchange szolgáltatási portfóliót elérhetővé tette. De tagadhatatlan tény, hogy ezzel beindult valami, amihez nagyban hozzájárult az is, hogy az okos telefonok elkezdtek terjedni, aminek hatására az árak elkezdtek lecsökkenni. Megnyílt egy olyan piac, amit ma Mobile Device Managementnek hívunk. Megjelentek a különböző gyártók, szállítók, akik különböző irányból, de azonos célokkal megoldást adtak olyan kérdésekre, mint: eszköznyilvántartás, eszközök központi kezelése, egységes policy definíciók.

A Gartner 2011-es Magic Quadrant szereplőinek szoftvereit összehasonlítva a megvalósított kontrollok között lényegi eltérés csak abban volt, hogy melyik gyártó, melyik mobil operációs rendszerre helyezte először a fókuszt. Gyakorlatilag minimálisak voltak az eltérések. Amit ezek a rendszerek tudnak: nagyjából azok az elvárások, amikről az előbb már szó volt.

Az elmúlt pár évben jócskán átalakult a piaci helyzet Az elmúlt pár évben jócskán átalakult a piaci helyzet. Ebből is látszik, hogy milyen nagy sebességre kapcsoltak az eszközgyártók. Az is szépen látszódik, hogy egyre inkább az alkalmazásmenedzsment felé tolódik el a hangsúly. Az átalakulások másik oka a felvásárlások, ami például a Zenprise esetében is történt: felvásárolta a Citrix és így lett belőle XenMobile.

Problémák Régi, mai, … Ügyfélszolgálat Üzemeltetés Kitettség A rendszerek terjedésével, felhasználószám bővítésével megjelentek a problémák. "Egyrészt mindenki örül, hogy a beruházás megtérül, mert valóban használják a rendszert, valóban kihasználják a lehetőségeket." Tipikusan lehetőség szüli az igényt esete: "A kollégának is van, nekem is kell. Lehet hogy nem fogom használni, de kell…" Az az igazság, hogy ez annyira trendi a mai napig, hogy ezt - még - tényleg használják… Hogy kihasználják-e? Az már más kérdés. Ahogyan változnak a felhasználói igények úgy növekednek az üzemeltetéssel szemben támasztott elvárások, megjelentek az egyes szervezeteknél olyan problémák, amikkel eddig vagy sokkal kisebb mértékben, vagy egyáltalán nem kellett számolni. Aki üzemeltetett már ilyen rendszert azok biztosan szembesültek ezekkel a problémákkal: Mindig, mindenhonnan, mindenkor elérhetőnek kell lenni a rendszernek. Ha a rendszer elérhető távolról, bármikor, akkor bármikor lehet probléma. Ki kell terjeszteni a Helpdesk ügyeleti rendjét… MDM rendszerrel a belső Exchange rendszert az internet felől elérhetővé tesszük, ami megnöveli a szervezet kitettségét a támadásokkal szemben. A jó kis tartalom szűrhető SMTP kapcsolatot, megtoldjuk HTTP, HTTPS csatornával is, amin keresztül nemcsak az Exchange, hanem a felhasználói azonosítók is támadhatóakká vállnak. Persze a jobb megoldások reverse proxy-val védik az Exchange-t, ami jobb mint ha nem lenne, de az sem tud tökéletes védelmet biztosítani. Kép forrása: www.claranet.co.uk

Problémák Régi, mai, … Adatkapcsolat Megbízhatóság Mentés Jogi problémák A kiszolgáló oldal: Mindig működik? Szolgáltatási időablak kiterjed a mobil elérésre is? Az Adatkapcsolat: Működik? Biztos? Olyan adatkapcsolatokra is üzleti szolgáltatásokat aggatunk, amit addig esetleg nem arra méreteztünk, építettünk ki. A mobilok tönkremennek: hát igen. Minél okosabb, minél többet tud, annál rövidebb az élettartalma. Lokálisan tárolt adatok mentése is problémákat vet fel. Felhasználói igény: át tudnák tölteni a régi telefonomról a privát SMS-eket…? Az igény jogos, csak a jogi háttér kérdéses. Ha már jogi problémák: egyáltalán nincs tisztázva, hogy egy készülék, amit céges policy alapján magán célra is használhat a dolgozó, akkor az ott lévő adatokat hogyan kell kezelni? Az most magán adat, vagy céges? Ha feltételezhető, hogy magán adat is van az eszközön, akkor az üzemeltető milyen jogalapon kezelheti, vagy férhet hozzá? Kép forrása: www.claranet.co.uk

De fejlődik a világ, változnak az igények De fejlődik a világ, változnak az igények. Ez a látványos grafikon is azt mutatja, hogy mennyire előtérbe helyeződik a mobilitás.

Új igények A szervezet határa elmosódik Céges és magán adatok keveredése BYOD = Bring Your Own Device II Bring Your Own Daemon A vállalatok érdeke, hogy a mobilfelhasználók számának növekedésével ne növekedjenek a céges készülékek beszerzési költségei. Másrészről pedig a felhasználók szeretnének egyre drágább, szebb, jobb, okosabb készüléket. Vagy legalábbis látszólag okosabb készüléket használni, még olyan áron is, hogy saját készüléket vásárolnak. A másik probléma, hogy senki nem szeretne egyszerre több készülékkel a zsebében rohangálni. Ez keltette életre a BYOD őrületet. Ki tudja, hogy valójában mit is jelent? … Bring your own daemon (Ahogy egyik szarajevói kolléga írta.) Hogy mi ezzel a baj? Hát üzemeltetői szemüvegen keresztül nézve csak a baj van vele. Visszautalnék a két lappal korábban felvetett jogi kérdésre: ha a készüléken van, vagy lehet magán adat, akkor milyen jogon kezelheti azt a rendszer üzemeltetője? Kép forrása: claudesuper.com

Új igények A szervezet határa kitolódik A levelezőrendszer elérése már nem elég: Közös könyvtárak Intranet Belső alkalmazások A másik ettől sokkal nagyobb probléma, hogy ma már kevés a levelező rendszer elérésének biztosítása. A felhasználónak már kevés, hogy látja a levelei mellett a naptárját, jegyzeteit, kontakt listáját. Egyre több mindent szeretne elérni mobilról, tabletről is azokból az információforrásokból, amik szükségesek a munkájához. Szeretné elérni a cég belső file szerverét, a belső intranetes oldalakat, alkalmazásokat, stb. És - hála a kitűnő marketingnek - egyre inkább terjednek a Unified Communication, lánykori nevén a video- és audio-konferencia megoldások. Ami persze jó, mert előre lendíti a technika fejlődést, de biztos, hogy fel vagyunk rá készülve? Kép forrása: parsonenterprises.com

Új igények Új igények  Új problémák Illetéktelen hozzáférés Adatszivárgás A fenti igényeket persze ki lehet szolgálni a klasszikus értelemben vett MDM megoldások többségével, de Biztosítani kell valahogy, ha illetéktelen kezekbe kerül az eszköz, akkor ne férjenek hozzá - legalábbis könnyedén ne férhessenek hozzá – a készülékre lementett, tárolt adatokhoz. Mindenki azt hiszi, hogy ha titkosítva van a memóriakártya, akkor a probléma meg van oldva. Igen ám, de ha a jelszó, amivel a készülékhez hozzá lehet férni 5 db nulla, akkor nem biztos, hogy sokat ér a titkosítás. Másik probléma, hogy az adatszivárgást megelőző, meggátló rendszerek implementációs projektjei a vállalatok adatvédelmi határait próbálja védeni anélkül, hogy az adatok minősítését oldanák meg. Nem a csatornákat, hanem az adatokat kell(ene) védeni, amire ma még nagyon kevés szervezet van felkészülve. Arról nem is beszélve, hogy erre mobil oldalon még kevesebb gyártó tud használható megoldást adni. Jó példa erre a Lync kliens. Teljesen jól működik tableten. Persze telefonon is, csak ott a kis képernyőn nem sok értelme van. (Legalábbis én nem vagyok akkora zsonglőr, hogy megfelelő sebességgel tudjak chat-elni a kis képernyőn. De hát nem vagyunk egyformák.) A lényeg, hogy a Lync-nek van egy nagyon jó tulajdonsága: chat közben lehet állományokat ki illetve átküldeni a partnernek. Kép forrása: apptec360.com

Piaci helyzetkép Miből lehet meríteni? Mobileszköz-virtualizáció Security-konténer Az új igények alapján a piacon többféle technológiai megoldások vannak. Van olyan, ami az alap operációs rendszer mellett virtuális környezetben futtat egy másik operációs rendszert. Az egyiket lehet használni, mint magán eszköz, a másikkal pedig el lehet érni a vállalati infrastruktúrát. Ennek a legnagyobb problémája, hogy nagyon erőforrás igényes, azaz lassú és még hamarabb merül az aksi. A másik megvalósítás, ami sokkal előremutatóbb, az a security container-es megoldás. Itt a vállalati policy alapján az alkalmazások egy csoportja tud egymással kommunikálni, de onnan nem lehet adatot sem ki, sem pedig bejuttatni. Így a két környezet tökéletesen elkülönül egymástól, ami jól hangzik. Az elkülönített környezettel a céges adatvédelmi határ pontosan definiálható. Csakhogy van egy kis probléma: mi van a címlistával. A felhasználók évek alatt rászoktak arra, hogy egyszerűbb az Outlookban karbantartani a kontakt listájukat és onnan leszinkronizálni, mint a telefonon szerkeszteni. Az ilyen működésű MDM/EMM rendszerek általában a security container-en belül kezelik a címlistákat. Ez jó, mert biztonságos. Minden Auditor örül neki, csak éppen a felhasználó nem. Hogy miért? Mert két címlista lesz a készüléken. Az egyik a telefon beépített címtára, a másik a security konténeren belüli pedig szinkronizálódik a vállalati címlistával. Hívás kezdeményezésnél csak kényelmetlen a felhasználónak, hogy be kell lépnie a konténeren belülre (amit persze jelszóval védünk) és onnan kell kezdeményezni a hívást, de hívás fogadásnál a telefon nem fogja tudni a telefonszám alapján megjeleníteni a hívó nevét, hiába van felvéve a konténeren belül. Kép forrása: techday.com

Piaci helyzetkép Ami még kérdéses Authentikációs sorrend Jelszószabályok Eszközazonosítás Lokalizáció Felhő - On premise Titkosítás Több postaláda elérése A másik probléma amit nem minden gyártó tud jól kezelni, hogy a felhasználó azonosítása előbb történik, mint a készüléké. (Exchange by default) Ez a brute-force jellegű jelszótöréseknek nyit kaput. Ha már jelszókérdés: mindig nagy kérdés, hogy hány hibás jelszó után zárja ki a felhasználót a rendszer. Létezik olyan Android-os levelező klienst, ami olyan sűrűn próbálkozik a felhasználó azonosítójával belépni, hogy amíg a felhasználó az asztali gépén lecseréli a domain-os jelszavát, addig ki is tiltotta a mobil készüléke az azonosítót. Az MDM rendszerek bevezetésével érdemes a jelszó policy-t is felülbírálni. A készülékek beazonosítása is érdekes kérdés, mi alapján azonosítja a rendszer a készüléket? Vannak olyan rendszerek, amelyek csak a készülék gyári száma alapján, van olyan is, ami a benne lévő SIM kártyát is beazonosítja. Van olyan megoldás is, ami a gyári szám, SIM kártya és felhasználói azonosító hármast együtt vizsgálja és csak akkor engedi az adatkapcsolatot, ha ez a hármas stimmel. Első olvasatra van egy okosnak tűnő megoldás a SIM kártya védelmére: több olyan rendszer is létezik, ami beállítás függően, de azonnal wipe-olja a készüléket, ha a SIM kártyát eltávolítják, vagy kicserélik. Ezzel két probléma lehet: képzeljük el, ha kontakt hibás SIM kártya érzékelője, vagy egyszerűen másik szolgáltatót vált a felhasználó, amivel új SIM kártyát is kap. A legtöbb menedzsment szoftver alkalmas arra, hogy meg lehessen határozni a készülékek helyét. Ez is jól hangzik, de arra már kevesebb rendszer képes, hogy ezt ki is lehessen kapcsolni, vagy megfelelő jogosultságú szinthez, akár négy szem elvű azonosításhoz lehessen kötni. Gondoljunk csak arra, hogy a kolléga nem biztos, hogy örül neki, ha az üzemeltető nyomon tudja követni, hogy éppen merre jár. A legtöbb megoldás felhő alapú, vagy legalábbis sokkal olcsóbb felhő alapú implementáció esetén. Igen, de mi van akkor ha a vállalati policy azonnal kizárja ezt. Azért a nagy gyártók érzik, hogy tisztán felhő szolgáltatásként elesnek, eleshetnek nagyobb ügyfelektől, ezért "On Premise" is elérhető a legtöbb termék, de nagyságrenddel drágábban. Amikor a mobilok biztonságáról beszélünk, akkor mindig felmerül, hogy nemcsak az adatokat, hanem néha magát a beszélgetést is titkosítani kellene, erre is van több gyártónak megoldása, de jócskán leszűkíti a piacot. Ami szintén leszűkíti a piacot, ha egy security konténeren belül több postaládát szeretnénk kezelni. A felhasználói igény igen egyszerű: a titkárnő szeretné látni a saját és a főnöke postaládáját, naptárját, kontakt bejegyzéseit. Látszólag teljesen magától érthető igény, mégis elég sok és nagy gyártónak ez még nem jutott eszébe. Kép forrása: xconomy.com

Konklúzió Ami biztos Kevés a klasszikus MDM Security konténer – jónak tűnik, de… Ahány eszköz, annyi biztonsági szint Növekvő rendelkezésre állási igény Csökkenő biztonsági szint Biztonsági tudatosságot növelni kell Az adatokat kell(ene) védeni Ma már kevés a klasszikus értelemben vett MDM megoldás. A security konténer szerű megoldások jó iránynak tűnnek, de még mindig fejlődési fázisban vannak a gyártók, még mindig a gyerekbetegségekkel küzdenek. A biztonsági beállítások érvényre jutása a mobil készüléktől függ, ahány gyártó, ahány operációs rendszer annyiféle érvényre juttatott beállítás lesz. Mivel az operációs rendszerek kódja nem nyilvános, ezért az MDM gyártók csak loholni tudnak a kiadott operációs rendszerek után. Nem lesz egységes a biztonsági szint. Kevés a készülék biztonságára fókuszálni, mert az MDM, illetve az EMM rendszerek az egész infrastruktúra biztonsági szintjére hatással van, ráadásul negatív hatással. Ezért mind a frontend, mind pedig a backend rendszerek biztonsági szintjét növelni kell. Magasabb rendelkezésre állásra van szükség az üzemeltetők részéről. Oktatni kell a felhasználókat, növelni a biztonsági tudatosságot. Kevés az adatcsatornákat védeni, az adatok védelmét kell megoldani, ami a word/excel/pdf dokumentumoknál viszonylag könnyen megoldható, de Intranetes tartalmak, alkalmazások adatai ugyanúgy „problémás" lehet. Kép forrása: alamy.com

Konklúzió Merre tovább? Tesztelni, tesztelni, tesztelni! Rossz hír: 2 évente kezdődik elölről az egész… Sok gyártó, sok termék van ami ígéretesen hangzik, de mindenképpen érdemes pilot-olni, tesztelni. Sok mindent megold egy bevezetett MDM rendszer, de nagyon sok egyéb problémát vet fel: nem lesz homogén, periféria kontroll, … Egy biztos, bármelyik megoldás kerül kiválasztásra, az legfeljebb 2 évre szólhat, mert amilyen gyorsan változnak a felhasználói igények, olyan gyorsan változik a piac is. Kép forrása: alamy.com

Köszönöm a figyelmet!