Az első kérdést természetesen mindenkinek, illetve minden cégnek magának kell eldönteni, viszont az elmúlt évben kipattant megfigyelési botrányokat követően maga a döntés egyre nehezebben és persze költségesebben odázható el. Miért is fontos az adatbiztonság, ha az ember épp nem olyan paranoid, mint amennyire a biztonsági szakemberek azok, vagy épp annak látszani szeretnének? Tegyük fel a kérdést fordított logikával és lássuk, milyen eredményre jutunk! Miért nem válaszolunk közvélemény-kutatásokra szívesen az utcán, miért nem adjuk meg akárkinek személyes iratainkat, vagy éppen miért nem osztogatjuk névjegykártyánkat mindenütt, ahol csak megtehetnénk? Vélhetőleg, mert tartunk attól, hogy valaki visszaél adatainkkal, vagy csak egész egyszerűen úgy érezzük: a világon semmi köze nincs az adott információhoz.
Az önvédelem viszonylag gyenge a virtuális világban. Ki ne adott volna már meg különböző weboldalakon nevet, címet, telefonszámot, ami manapság még nem is tartozik a különösen kockázatos tettek közé. Ki ne telepített volna egy-egy olyan alkalmazást a Facebook-fiókjához, vagy regisztrált volna valahová a fiók segítségével, ahol csak úgy első ránézésre is több adathoz szerettek volna hozzáférni, mint amennyihez a nyújtott szolgáltatás szempontjából feltétlenül szükséges lett volna? Különös tekintettel arra, hogy ez a szolgáltatás olykor csak egy jópofa, vagy legalábbis abban a pillanatban annak tartott kép vagy videó megnézését tette lehetővé. És fordítva: ki és mikor nézte utoljára mondjuk LinkedIn-fiókjának biztonsági beállításait? A kockázat itt sem elhanyagolható, hiszen emberek személyes adatairól vagy éppen üzleti szempontból kritikus adatokról lehet szó. De még érdekesebb a dolog egy olyan típusú szolgáltatás esetén, mint amilyen példának okáért a SalesForce, a Google termékek vagy a Microsoft dokumentumtára, melyek komplett levelezés, címtár, naptár felhőben történő tárolására lettek kifejlesztve. Miért használjuk mégis ezeket a szolgáltatásokat?
Több okunk is van erre. Egyrészről az Edward Snowden kirobbantotta NSA botrányig jobbára csak az összeesküvés-elméletek hívei és biztonsági szakemberek gondolkodtak abban a kockázatban, amit az adataink feletti kontroll elvesztése jelent. Másrészt a felhőszolgáltatások számos olyan nehezen elvitatható értékkel bírnak, amiket nyilvánvalóan nem szeretnénk elveszíteni. Az adatszivárgás lehetősége tehát eddig is létezett, csak a kihasználására nem volt közvetlen bizonyíték, vagy ha volt is, figyelembe véve az előnyöket, ezt a kockázatot elviselhetőnek, vagy éppen elhanyagolhatónak gondoltuk. A helyzet értékelése a napvilágot látott információk fényében gyökeresen megváltozott. A probléma kezelésérére többféle megoldás is kínálkozik, ugyanakkor mindegyiknek megvannak a maga hátulütői.
Együtt élhetünk a kockázattal, ez a legkézenfekvőbb megoldás. Ha kellő megfontolás után akár magánemberként, akár cégvezetőként arra a következtetésre jutunk, hogy a felhőben tárolt adataink nem annyira érzékenyek, hogy megérné a fáradságot a problémákkal foglalkozni. Helyes lehet az a döntés, hogy nem teszünk voltaképpen semmit. Ugyanakkor célszerű időről-időre felülvizsgálni ezt a döntést, hiszen a tárolt adatainkban beállhatnak változások, esetleg a kockázat is nőhet, ha például sikerre viszünk egy startup-vállalkozást, nemcsak a cég, de az adatai iránti érdeklődés is nagyobb lesz. Tulajdonképpen ebben az esetben sem vagyunk védtelenek, hiszen a kockázat egy részét voltaképpen áthárítottuk azáltal, hogy a szolgáltatási szerződést elfogadtuk – már amennyiben igaz, hogy a szolgáltató kötelezettséget vállalt ebben a szerződésben arra, hogy adatainkat harmadik félnek nem adja át. Kérdéses persze milyen eséllyel indulunk egy olyan céggel szemben indított perben, mint amilyen a Google, a Microsoft, vagy más, a botrányban érintett cég, illetve mennyit tud segíteni egy esetleges kártérítés, amennyiben kiszivárgott adataink üzletünk alapját vagy éppen magánéletünk egy kényes területét érintették.
A kockázatkerülés is lehetőség, viszont ez esetben ez a felhőalapú szolgáltatások elkerülését jelenti. Ma már számos ilyen szolgáltatásnak létezik olyan változata, amit saját hálózatunkban működtethetünk (OpenStack, ownCloud...), illetve léteznek helyettesítő szoftvermegoldások is. Ha azonban ezek mellett tesszük le voksunkat, az üzemeltetés összes nehézségét, és ezzel együtt összes költségét is magunkra vállaljuk, amit minden bizonnyal eredetileg szerettünk volna elkerülni. Az outsourcing is felmerül, mint alternatíva, ahol tulajdonképpen a felhőszolgáltató által jelentett kockázatot egy másik cég által jelentett kockázatra cseréljük le, ami nem feltétlenül rossz döntés, hiszen az egyik, illetve a másik kockázat között jelentős különbség is lehet. Gondoljunk csak a már említett peres eljárásban való sikerünk esélyére egy hazai céggel szemben, vagy ha nem megyünk ennyire messzire, akkor egy kisebb, hozzánk közelebb álló cég működésébe több és alaposabb belelátásunk, több ráhatásunk lehet, mint amennyire ez egy nemzetközi cégóriás esetén igaz.
Mindent egyben megoldás nem létezik, ritka az az eset is, amikor a kecske is jól lakik és a káposzta is megmarad. A kockázat ugyanakkor úgy is csökkenthető, hogy a felhőben rejlő előnyökről sem kell lemondanunk. Voltaképpen maguk a szolgáltatók kínálnak megoldásokat az adataink bizalmasságának megőrzésére. Az előző hasonlatot tovább fűzve azt mondhatnánk: kecskére káposztát, hiszen az alapprobléma épp az, hogy ezen szolgáltatók hitelessége vált kérdésessé. Egy ilyen esetben egy szerveroldali titkosítás – ami számos felhőalapú megoldás esetén lehetséges – azt jelenti, hogy a szolgáltató az általa birtokolt kulccsal titkosítja adatainkat. Ez ugyan védelmet jelent abban az esetben, ha az adatszivárgás nem szándékolt, a támadó csak a titkosított adatokhoz, a kulcshoz magához nem jutott hozzá. Másrészről viszont nem jelent semmilyen garanciát arra az esetre, hogy ha a szolgáltató maga adja ki az adatainkat, hiszen a titkosító kulcs birtokában erre lehetősége van. A kliensoldali titkosítás – vagyis amikor az általunk létrehozott kulccsal történik az adatok rejtjelezése – hatásos lehet a szolgáltatói kockázat csökkentésére, hiszen a felhőszolgáltató már csak a titkosított adatainkat tárolja, viszont teljes egészében nem szünteti meg a problémát. A szolgáltatás eléréséhez adott kliensprogram – legyen az egy tényleges alkalmazás vagy csupán egy böngésző által futtatott kód – még mindig kiszolgáltathatja a kulcsot a szolgáltatónak, vagy bárki másnak. Az esetek jelentékeny részében nincs rálátásunk arra, hogy a kliens voltaképpen mit tesz az adatainkkal, hiszen a működés analízise sem egy egyszerű feladat, emellett ha a szoftver forrása zárt, akkor annak vizsgálata egyáltalán nem lehetséges. Nem elhanyagolható tény, hogy a legnépszerűbb megoldások – köztük a Google Drive, Microsoft SkyDrive vagy a SugarSync – ezt a megoldást nem támogatják.
Nem bízni senkiben az alapelv, ha titkosításról beszélünk. Ez annyit tesz, az adatot minden esetben titkosítani, az integritását minden esetben ellenőrizni, a kulcs hozzáférését minden esetben limitálni kell. Viszont ha nem bízunk sem a kliens-, sem a szerveroldalban, hol lesz az eszköz, ami a titkosítást végzi? A kliens és a szerver között félúton. Ha találunk egy alkalmas pontot a hálózatunkban, ahol minden olyan forgalom áthalad, ami az adott felhőalapú szolgáltatás felé irányul, ez a pont alkalmasint lehet a határvédelmi pontunk, avagy a tűzfal – egy általunk kontrollált eszköz végezhetné el a szolgáltató irányába történő titkosítást és az onnan érkező adatok visszaalakítását rejtjelezés nélküli formájukba. Itt tárolódna a nyílt és a titkos kulcsunk egyaránt. Ebben az esetben sem a kliens-, sem a szerveroldali titkosításra nincs szükségünk, hiszen a rejtjelezést és a visszaállítást magunk végezzük, következésképp a kulcsoknak erről az eszközről nem kell kikerülni, magán az eszközön a hozzáférés könnyen korlátozható, illetve megfigyelhető. A működésből következően a szolgáltatónál és az oda vezető úton egyaránt csak titkosított adatok jelennek meg, vagyis mind a szándékolt, mind a harmadik fél támadásából adódó adatszivárgás ellen védve vagyunk.
Nem fenékig tejfel ez a megközelítés sem, hiszen a titkosításra használt eszköz üzemeltetésének minden költségét, legyen az pénzben vagy munkaórában kifejezve, magunkra kell vállalnunk. Emellett a bizalmi probléma sem múlik el, csak áthelyeződik, lévén mindazok, akik hozzáférnek az eszközön tárolt kulcsokhoz, biztonsági szempontból kockázatot jelentenek. Arról sem szabad megfeledkeznünk, hogy a belső hálózatunkban az adatok továbbra is mindennemű védelem nélkül közlekednek, illetve a kliensgépeken is így tárolódnak, ebben a tekintetben különösen óvatosnak célszerű lennünk. További nehézséget jelenhetnek mindazok átterelése az eszközön, akik korábban az internet irányából érték el a felhőben tárolt információkat (például home office, road warrior). Ugyanakkor az adatvagyon megóvásának szempontjából egy vitathatatlan eredményt értünk el: visszaszereztük az adataink – pontosabban az adataink bizalmassága – feletti kontrollt. Tettük mindezt úgy, hogy mindeközben nem kellett lemondanunk a felhőalapú szolgáltatás adta előnyökről. Legalábbis elméletben, hiszen gyakorlati megoldásról eleddig nem esett szó.
A fenti videó egy illusztráció arra nézve, hogy miként ültethetjük át a fenti teóriát egy konkrét példa esetén a gyakorlatba. A konkrét példa a Google naptárszolgáltatása, ahol is először egy kliensalkalmazás segítségével (Thunderbird) veszünk fel egy eseményt, majd azt a webes felületen keresztül próbáljuk visszanézni; viszont azt tapasztaljuk, hogy az adatok (cím, helyszín, leírás) titkosítva – az egyszerű illusztráció kedvéért ez most csak Base64-kódolást jelent – jelennek meg. Visszanézve az eseményt a kliensprogramból ugyanakkor minden rendben lévőnek tűnik.
Az alkalmazott módszer pont az, amit a fentiekben kifejtettünk, vagyis hogy a kliens és a felhőszolgáltató közé egy kódoló/dekódoló eszközt helyeztünk el (ez esetben ez a Zorp technológia), amit a webes elérés során szándékosan kikerültünk, hogy megmutassuk, miként festenek az adatok mind a szolgáltatást nyújtó, mind a forgalmat a két végpont között lehallgatók, mind a bennünket kijátszani igyekvő titkosszolgálatok számára. Megnyertük ezzel a lépéssel a háborút a mondjuk NSA ellen? Biztosan nem, viszont okozunk némi fejtörést, és időt nyertünk – hogy mennyit, azt a következő Edward Snowden jóvoltából fogjuk megtudni.
