Microsoft OneDrive, Google Drive, MEGA, Yandex Disk, Apple iCloud vagy Dropbox? Nem, nem fogok írni sokak után egy ezer plusz egyedik cikket arról, hogy ezeket összehasonlítgassam, inkább írok arról, hogy milyen szempontok alapján érdemes fájlhoszting szolgáltatót választani személyes célra.

Sokakkal előfordult már, hogy otthon felejtettek egy fontos pendrive-ot, esetleg ellopták a gépét vagy más módon, de fontos adatokat vesztett el, amikről ugye a felhasználó sosem készít mentést, amíg először meg nem történik a baj. A cloud fájlhoszting szolgáltatók ugyan ezt a problémát gyakorlatilag egy az egyben ki tuják küszöbölni, használják is egyre többen, viszont nagyon nem mindegy, hogy melyiket, több szempontból sem.

Nagyon gyors felzárkóztatóként írom, hogy ezekhez a szolgáltatásoknak része egy gépre telepíthető kliensprogram, amivel ki lehet jelölni azokat a mappákat a gépen, amiket szeretnénk a saját gépünk mellett a felhőben is tárolni. Azaz ha egy ezen belüli fájlt módosítunk, a módosítás  szinte azonnal megtörténik a felhőben tárolt példányon is, hasonlóan minden  más fájlművelethez, azaz az egész olyan, mintha egy hálózati meghajtó lenne. Itt most a személyes használatra szánt szolgáltatásokkal fogok foglalkozni, főleg információbiztonsági és stabilitási szempontból, de emészthetően.

Ahhoz képest, hogy mennyi fájlhoszting szolgáltató van meglepően kevés az olyan, aminek a freemium változata szerintem megfelel az átlagos felhasználói igényeknek és azoknak a biztonsági követelményeknek, amiket ha mindenki követne, egy boldogabb világban élnénk.

Korábban már írtam róla, hogy a PRISM-para után számos semmiből előtűnő netes cég, legyen szó levelezésről, fájlhosztingról vagy csevegőprogramról, úgy fogta ki a szelet a vitorlából, hogy a felhasználók tájékozatlanságára építve olyan ostobaságokkal bizonygatta azt, hogy ők aztán tényleg a legbiztonságosabbak, mint például hogy a szervereik valamilyen egzotikus országban vannak, ahova nem ér el sem az EU sem az USA mocskos mancsa /*#LOL!*/, illetve egymást akarták túllicitálni azzal kapcsolatban, hogy a szervereiken milyen erősségű titkosítás mellett tárolják a felhasználóik adatait.

Nos, több tárhelyszolgáltató valóban megvalósította, hogy a felhasználó amikor adatot feltölt, azt kliensoldalon a kliensprogram vagy a böngésző titkosítja, eleve titkosítva tolja fel a szerverre, a szerver azt tárolja, amikor pedig a felhasználó letölt a tárhelyéről, letöltődik a szerverről az igencsak erősen titkosított adatmassza, amit a felhasználó a saját kulcsával, amit jelszó véd, szépen kibont. Eléggé gyorsan belátható, hogy ugyan ilyen esetben nyilván a szolgáltató sem látja, hogy milyen adatot is tárolnak nála ténylegesen, viszont egyrészt nagyban korlátozza a lehetséges kényelmi szolgáltatásokat, másrészt eszközfüggő ugyan, de a fájlok szinkronban tartását lassabban végzi. Harmadrészt pedig olyan kockázat ellen véd, aminek a bekövetkezési esélye meglehetősen kicsi, nevezetesen, hogy valaki közvetlenül a szerverhez férjen hozzá valamilyen módon, aztán arról emeljen le adatokat, amihez ugye eleve tudnia kellene, hogy egy sok(tíz)ezer gépből álló privát cloudban melyik gép is az, amelyiken az ellopni, hatóságok esetében pedig lefoglalni kívánt adat van. Nos, igen, a jó öreg MEGA-ra gondolok, amivel végfelhasználói szempontból a legnagyobb para látszólag paradox módon éppen az, hogy nincs lehetőség jelszóhelyreállításra vagy a fiók teljes törlésére, ha a felhasználó nem tud belépni. Az viszont igenis életszerű, hogy valaki az áldozat  MEGA-jelszavát egy keyloggerrel ellopja, belépés után megváltoztatja, a fiók tulajdonosa pedig nem tehet semmit.

A MEGA-t azért emeltem ki, mert a legbiztonságosabb szolgáltatónak tartják, elméletben az is, gyakorlatban viszont épphogy ezért nem.

Ha belegondolunk a jelszólopás rizikója miatt, a felhasználói név és jelszó páros egy-egy belépéshez mindenhol édeskevés, pláne abban az esetben, ha az összes dokumentumunk fenn tanyázik a fellegekben, ugyanakkor a többlépcsős hitelesítést aminek a legegyszerűbb megvalósítása, hogy a felhasználói néven és jelszón kívül egy SMS-ben érkező vagy mobilapp által generált, fél percig érvényes tokent is meg kell adni belépéskor, ha olyan eszközről lép be, amiről korábban nem lépett még be. Azaz az azonosítás kétlépcsős, 2-FA. Viszont egy kezemen meg tudom számolni, hogy hány normális fájlhoszting szolgáltató van, amelyik ezt lehetővé is tenné, legalábbis a freemium változataiban.

Nem teljesen mindegy, hogy szerveroldalon az adat mennyire titkosított abban az esetben, ha egy közönséges jelszólopással is elérhető mind a kliensoldalon keresztül? Na ugye! A saját fájljainkhoz tipikusan csak a saját eszközeinkkel szeretnénk hozzáférni, ugyanakkor a jól kialakított 2-FA lehetővé teszi, hogy ha idegen gépen kell belépnünk egy fájl eléréséhez, a munkamenet egyszeri legyen, azaz más gépén ne jegyezze meg a böngésző, mint saját eszközt. Tehát a 2-FA elemi feature kell, hogy legyen!

A MEGA-t még akkor kezdtem el használni, amikor nekem alkalmasabb még nem volt, nemrég az átköltözésnél pedig volt szerencsém kipróbálgatni a komolyan vehető alternatívákat, amikkel kapcsolatban azt tapasztaltam, hogy több téren éppen arra alkalmatlanok, amire kitalálták őket.

Szép dolog, ha nagy az ingyenesen használható tárhely, ez viszont teljesen mellékes, ha nem talicskával hordjuk fel a HD pornót, hogy ne a gépen foglalja a helyet, hanem valóban dokumentumokat, forráskódokat és fotókat tárolnánk rajta, ami pedig nyilván sok apró fájlt jelent, amit a szolgáltató esetleg egyszerűen nem tud kezelni. Márpedig tényleges felhasználói adatból átlagosan 10-20 GB-nál több aligha van, aminek folyamatosan frissnek is kell maradnia.  

Google szolgáltatást a Youtubeon kívül elvből nem használok ugye, viszont eleve titkosított fájlokat próbáltam feltolni a Google Drive-ba, aminek a kliensprogramja az első volt, amelyik egyszerűen megadta magát, mivel nem tudta kezelni a túl sok fájlt a feltöltésnél. Kiírta ugyan, hogy behalt, azt már nem, hogy milyen fájloktól dobta el az agyát. Viszont abban az esetben, ha valakit nem zavar, hogy a Google-felhőben tárolt adatok olyan infrastruktúrán működnek, aminek a kialakításánál a költséghatékonyság volt az egyik fő szempont, a Google semmiféle felelősséget nem vállal egy-egy adatvesztés miatt, hajrá! Ugyanakkor a Google Drive jól teljesít nagy méretű fájlok feltöltésénél, de itt különösen igaz, hogy a felhőbe eleve titkosítva kellene feltolni az adatot. A Google mezei és üzleti felhasználásra szánt Google Apps változata közt semmiféle lényegi különbség nincs.

A Google Drive szerveroldalon ugye nem titkosít. Hogy miért eleve titkosítva? Egy fél pillanatig se felejtsük el, hogy az adatok védelme elméletileg a Google európai leányvállalatának policyjától függ, gyakorlatilag meg ugye annak az államnak a jogbiztonságától, ahol az adott konkrét felhasználó adatait ideiglenesen vagy tartósan tároló szerverek vannak. A Google pedig stílusosan a felhasználó földrajzi helyéhez legközelebbi adatközpontba fogja az adatot lapátolni, nos, Magyarország meg nem egy olyan ország, ahol különösebb visszhangja lenne egy adatlopásnak.

Az Európában kevésbé ismert Yandex Disk kliensprogramja már lényegesen jobban teljesített sok apró fájl esetén, de alapvetően szintén megadta magát idővel, de nem ez volt benne a legirritálóbb, hanem az, hogy az én esetemben pont akkor nem működött a kliensprogram, amikor a 2-FA-t bekapcsoltam, innentől kezdve pedig felejtős a dolog, ugyan alighanem a hibát előbb-utóbb javítják. Webes felületen 2-FA mellett viszont problémamentesen működik, tökéletesen alkalmas olyan adatok tárolására, amiknek az elérésére, módosítására csak ritkábban van szükség.

A Microsoft OneDrive kliensprogramja szintén a sok apró fájlba döglött bele először, viszont ha ezeket a húzós tartalmú mappákat külön-külön töltöttem fel, problémamentesen működött. A OneDrive-val kapcsolatban többször emlegetett adatvédelmi aggály, hogy folyamatosan pásztázza a felhasználók által feltöltött tartalmakat, alapvetően illegális tartalmak után kutatva, például a nagy mennyiségű, szerzői jogvédelem alá eső, megosztott könyvek, na meg a visszaélésre esetlegesen alkalmas fotók miatt harap. Szép és jó, hol itt a probléma?
Természetesen mindezt egy mintázatfelismerő algoritmus végzi, az viszont ismétcsak nem világos, hogy ha az algó talál ilyet, akár falspozitívan gyilokpornóként azonosítva egy farsangi képet, azonnal szögre akasztja a felhasználót vagy éppenséggel bekerül egy nagy kalapba, ahol már emberi ellenőrzésen is átmegy a dokumentum. Természetesen az is előfordulhat, hogy egy leendő, még nem szabadalmaztatott gyógyszerhatóanyaggal kapcsolatos részletes dokumentumot tekint a nagyokos algoritmus valami drogos cuccnak, ami enyhén szóval nem szerencsés, ha egy teljesen kívülálló alkalmazott elé kerül ellenőrzésre. Ugyan lehet még olvasni az Onedrive-on szinkronizálható fájlok számát érintő 20000-es limitről, ezt nem tapasztaltam.

Fontos tudni, hogy ilyen tartalmi ellenőrzést végez az összes nagyobb cloud szolgáltató, amelyiknek van rálátása a felhasználói adatokra, egyetlen megoldásként ismétcsak az javasolható, hogy a különösen rázós doksikat eleve titkosítva töltsük fel.

Szintén lényeges, hogy ne bízzunk ezer százalékig a felhőben, legyen air gapped másolata is mindennek olyan pendriveon, amit csak akkor húzunk elő, amikor nagyon kell. Ugyanis hiába, hogy a fájlhoszting szolgáltatókat arra találták ki, hogy kényelmesebbé és egyszerűbbé tegyék a fájlok kezelését különböző eszközök közt, simán előfordulhat, hogy pont ez okoz adatvesztést.

Ugyan nem mentem bele részletekbe, de ha egy fájlt módosítunk a saját gépünkön mondjuk Windowsban és természetesen nem sokkal később az OSX-et futtató almás laptopunkkal szeretnénk elérni, a szinkronizáló kliensprogramnak nyilván meg kell oldania, hogy a fájl újabb verzióját érjük el. Hogy ezt melyik kliensapp hogyan csinálja, annak nem mentem utána nagyon, a MEGA például a fájlok korábbi verzióiról készít egy-egy példányt, ami alapértelmezés szerint a felhasználó elől el van rejtve, de előhúzható szükség esetén. Annak felismerése, hogy melyik fájl a legújabb és melyiket kell figyelembe vennie a szoftvernek, valószínűleg úgy történik, hogy a szoftver megvizsgálja egyrészt az utolsó módosítás pontos idejét időbélyeg  szerint vagy éppen nyilvántartja a fájlok kiszámított hash értékét ami azonnal megváltozik, ha a fájlban módosítás történik. Az időbélyeget vagy a hash-ellenőrzőösszeget pedig ügyesen tárolja és kezeli olyan sebességgel, hogy ebből a felhasználó semmit se vegyen észre.

Aki szinkronizált már életében bármit bármivel találkozhatott azzal a jelenséggel, amikor éppen ez a kényelmi funkció okoz adatvesztést. Például a hülye box.com cloud esetén, amiről még nem írtam, ha a szinkronizálás rosszul van beállítva – jobb családokban a felhasználónak eleve szinte semmit sem kell állítgatnia – olyan módon, hogy egy helyben tárolt üres mappát szinkronizáljon egy olyannal, ami a felhőben már megvan vagy éppen fordítva, a box.com képes és az üres mappához igazodik úgymond, azaz törli a teljes tartalmát, ráadásul úgy, hogy azt esetleg vissza sem lehet állítani.

A cloud tároló vállalati környezetben gyakorlatilag megkerülhetetlen, személyes használat esetén pedig könnyebbé teszi az életet, viszont érdemes figyelembe venni, hogy mi az, amire alkalmatlan valamilyen szempontból – például a darkwebről bizonyítékként lementett tartalmak tárolására nem a legalkalmasabb.

Egy nem is olyan régi hír szerint pedig a legkomolyabb versenyzők esetén sem szavatolható 100%-ig, hogy valaki valamilyen újfajta technikával ne lásson át a felhőkön: Man-in-the-Cloud

Pontosabb, bővebb magyarázat? Kapcsolatfelvétel? Kattints ide!