Išoriniai duomenų centrai (arba kitaip debesys) ir jų teikiamos paslaugos, tikriausiai, nepaliko nė vieno abejingo. Vieni teigia, kad raginimai eiti į debesis – tik duomenų centrų įrangos gamintojų ir paslaugų teikėjų sukeltas triukšmas, kiti – debesų kompiuterija yra neišvengiama ateitis. Taip pat tenka išgirsti visiškai priešingų nuomonių apie debesų saugumą: nuo pasisakymų, kad debesys ir duomenų saugumas yra nesuderinami dalykai, iki patikinimų dėl aukšto saugumo lygio.
Todėl norėčiau panagrinėti debesų kompiuterijos temą informacijos konfidencialumo užtikrinimo pjūviu. Ar įmonės duomenys išoriniame duomenų centre gali būti tokie pat saugūs kaip ir vidiniame (nuosavame) duomenų centre? Pavyzdžiui, įvertinusi ekonominę naudą, įmonė svarsto galimybę perkelti dalį savo IT ūkio į debesis. Tačiau gali iškilti klausimas, ar sutaupydama įmonė pajėgs užtikrinti apdorojamos informacijos konfidencialumą?
Absoliutaus saugumo nėra
Pažvelkime į šią temą per rizikos prizmę. IT paslaugų teikimas remiasi tam tikromis prielaidomis apie apdorojamų duomenų vertę, pageidaujamą konfidencialumo užtikrinimo lygį, galimas grėsmes ir pažeidžiamumus. Natūralu, kad dėl ribotų išteklių neįmanoma apsisaugoti nuo visų galimų pavojų. Todėl reikia rasti kompromisą tarp pageidaujamo informacijos konfidencialumo užtikrinimo lygio ir išlaidų apsaugai. Ant vienos svarstyklių lėkštės turime sudėti savo baimes ir abejones, ant kitos – kainą, kurią galime skirti informacijos apsaugai. Kitaip tariant, turime nustatyti savo įmonės rizikos apetitą: kokias rizikas norime eliminuoti arba sumažinti iki priimtino lygio, o kokias prisiimti su visomis pasekmėmis.
Šioje vietoje derėtų pakalbėti apie vadinamąjį absoliutų saugumą. Pavyzdžiui, jūsų įmonė kuria kažką itin slapto, brangaus ir galingo (pvz., atominį ginklą). Į informacijos saugumą yra investuojamos didžiulės pinigų sumos ir naudojamos naujausios technologijos. Natūralu, kad nesinaudosite debesų paslaugomis ir jūsų IT sistemos bus fiziškai atjungtos nuo interneto. Tačiau, jei jūsų priešininkas yra pakankamai didelis ir turtingas (pvz., galingiausia pasaulio valstybė), tai jis gali apeiti jūsų apsaugos priemones ir sužlugdyti projektą (pvz., sukurti neaptinkamą, USB atmintinėmis plintantį virusą, kuris sugadina urano sodrinimo centrifugas).
Šį pavyzdį pateikiu norėdamas parodyti, kad absoliutaus saugumo nėra: įsibrauti tiek į vidinius duomenų centrus, tiek į debesis yra įmanoma, jei tik jūsų priešininkas turi pakankamos motyvacijos ir pajėgumų.
Kur duomenys saugesni – vidinėse saugyklose ar debesyse?
Tačiau sugrįžkime prie pagrindinio nagrinėjamos temos klausimo – kur duomenys bus saugesni: vidinėse saugyklose ar debesyse? Kadangi absoliutaus saugumo idėją jau atmetėme, informacijos saugumą tikslingiau būtų panagrinėti palyginimo būdu.
Pabandykime palyginti informacijos saugumo riziką, kai duomenys yra saugomi vidinėse duomenų saugyklose, su gresiančiais pavojais debesyse. Sudarykime galimų pavojų sąrašą, pavyzdžiui, įsibrovimas iš interneto, duomenų centrą administruojančio personalo nesankcionuoti veiksmai, vartotojai nesilaiko nustatytų informacijos saugumo reikalavimų, klaidos dėl žmogiškojo faktoriaus, informacijos saugumo priemonių būklės ir veiksmingumo nežinojimas, pasinaudojimas kito asmens prieigos teisėmis ir pan. Pasirinkime rizikos skalę: skirtingus rizikos lygius galime pažymėti spalvomis (žalia – mažai tikėtina, geltona – galima, raudona – labai tikėtina) arba skaičiais nuo 1 iki 5. Be abejo, siūloma skalė yra subjektyvi. Jeigu galite, kiekvieną riziką apskaičiuokite ir išreikškite galimus įmonės nuostolius litais per metus.
Sudarykite paprastą lentelę iš trijų stulpelių: pirmąjį stulpelį sudarys rizikų sąrašas, atitinkamai antrame ir trečiame stulpeliuose – rizikų lygis vidiniame duomenų centre ir debesyse. Stulpelių gali būti ir daugiau. Pavyzdžiui, vidinio duomenų centro IT priežiūrą gali užtikrinti rangovas arba vidinio duomenų centro gali iš viso nebūti (pvz., duomenys yra saugomi kiekvieno darbuotojo kompiuteryje decentralizuotai). Taip pat galite pridėti ir scenarijų, kuriame visi įmonės duomenys nukeliauja į debesis, o visų informacinių sistemų bei IT infrastruktūros priežiūra visiškai perduodama rangovams. Tuomet kiekvieno scenarijaus rizikai priskirkite lygį pagal pasirinktą skalę.
Nuspalvinę rizikos lygius šviesoforo spalvomis, gausime rizikų žemėlapį. Analizuoti surinktus duomenis ganėtinai paprasta. Jei rizikos lygis yra toks pat dabartiniame ir debesų scenarijuje, vertinkime tik ekonominį naudingumą ir pasirinkime pigiausią variantą.
Jei debesų scenarijus rizikingesnis, įvertinkime savo įmonės rizikos apetitą. Gali būti, kad rizikos sumažinimas iki priimtino lygio (pvz., keliant papildomus saugumo reikalavimus debesų paslaugų teikėjui) padidins paslaugų kainą ir nebeliks ekonominio patrauklumo. Gali nutikti ir taip, kad kai kurios debesų scenarijaus rizikos bus mažesnės už dabartines (pvz., 24x7 saugumo įvykių monitoringas, kurio jūsų įmonė neturėjo). Bet kuriuo atveju, rizikos žemėlapis suteikia įmonės vadovams galimybę vienoje vietoje pamatyti informacijos konfidencialumo rizikas ir įvertinti jas kartu su galima ekonomine nauda.
Tokio rizikos vertinimo kokybė priklauso nuo ją atliekančių darbuotojų objektyvumo. IT specialistai gali bijoti prarasti savo darbo vietas dėl galimo duomenų centro perkėlimo į išorę, todėl bandys sureikšminti savo vaidmenį, užtikrinant informacijos saugumą.
Debesų kompiuterijos paslaugų pardavimo vadybininkai nersis iš kailio, įrodinėdami aukštą teikiamų paslaugų saugumo lygį. Įmonės informacijos saugumo specialistas (jei tokį turite) taip pat gali būti nekonstruktyvus visur matydamas tik pavojus. Įmonės vadovai žinodami savo darbuotojų ir kitų suinteresuotų pusių baimes bei lūkesčius gali kritiškiau įvertinti sudarytą rizikų žemėlapį ir taip susidaryti geresnį vaizdą apie informacijos konfidencialumo užtikrinimo galimybes išoriniuose duomenų centruose.
Taigi, nėra vienareikšmiško atsakymo į klausimą ar būtina pulti stačia galva į debesis, ar nuo to susilaikyti. Pasirinkimą nulemia konkretūs įmonės poreikiai, požiūris į informacijos saugumą ir rizikos apetitas.