Până în 2020, serviciile de Cloud Computing sunt aşteptate să ajungă la 411 miliarde de dolari în ceea ce priveşte veniturile. Cifra este aproape dublă faţă de cele 219.6 miliarde de dolari încasate în 2016. De ce se va întâmpla acest lucru, vă întrebaţi? Motivele sunt simple: costuri scăzute, productivitate ridicată.
Cloudul are un impact important asupra modului în care serviciile sunt accesate, livrate şi consumate de către utilizatorul final. Prin facilitarea accesului la acestea, organizațiile și guvernele pot reduce costurile operaționale, îmbunătățind în același timp calitatea vieții cetățenilor.
În ciuda tuturor avantajelor, cloudul modifică modul în care dezvoltăm, implementăm și menținem aplicațiile, precum și procesele pe care le folosim pentru a gestiona datele. Tendințele cum ar fi fintech, inteligența artificială, healthtech, comunicarea machine to machine și smart cities, împing mai multe date personale către cloud.
Cu toate acestea, uitându-ne la mijloacele folosite de către organizaţii pentru a-și proteja bunurile digitale, se pare că nu am învățat prea multe din definiţia lui Einstein asupra nebuniei: "A face mereu același lucru, așteptând rezultate diferite".
Pentru o perioadă lungă de timp, organizaţiile şi-au concentrat strategiile de securitate pe protejarea datelor aflate în cadrul perimetrului acestora, fiind un model eficient la momentul respectiv.
Sistemul de securitate perimetral este cel mai adesea comparat cu un castel: ziduri groase, turnuri de supraveghere şi o singură intrare păzită. Cu toate acestea, dacă reuşeşti să intri, ai acces la tot. Din această cauză securitatea perimetrală este descrisă ca având un interior sensibil şi un exterior puternic.
În lumea IT, aceasta se traduce prin:
Datele companiei salvate în baze de date SQL sau NoSQL sub formă de text;
Au fost create numeroase instrumente pentru fiecare nivel, cu scopul de a ajuta organizațiile să se protejeze de infracţiuni cibernetice. Variind de la sisteme de detectare sau prevenire a intruziunilor, până la firewalluri, honeypots, prevenirea pierderilor de date, IAM, managementul dispozitivelor, s-ar putea crede că avem totul.
Companiile investesc sume uriașe de bani în aceste instrumente pentru a proteja interiorul sensibil: Datele. Credem că există câteva opțiuni foarte bune pe piaţă, unele dintre ele create chiar aici în România.
Potrivit dovezilor, undeva greşim cu siguranţă. Anul acesta am depăşit 5 milioane de date furate sau pierdute pe zi. Şi aici ne referim doar la date personale. Numărul nu acoperă toate documentele confidenţiale pierdute în fiecare zi de către companii şi organizaţii guvernamentale. Un alt aspect al acestor date este faptul că doar 4% din aceste date sunt criptate, în general la nivel de bază de date.
Se pare că în ziua de azi întrebarea nu este dacă o companie va fi atacată, ci când, cum, de către cine şi de ce. Putem considera probabilitatea unei breşe de securitate ca o funcție compusă din numărul de date, valoarea lor și efortul necesar pentru a ajunge la ele. Situaţia în care cu siguranță nu doriți să fiți este cel în care aveți un volum mare de date și este nevoie de un efort relativ scăzut pentru a ajunge la acesta.
O altă întrebare pe care ar trebui să ne-o punem este "avem încă un perimetru de apărat"? Noi credem că nu există nici unul, sau cel puţin singurul mod în care ne putem imagina unul este la un nivel micro. Cu alte cuvinte, există un perimetru în jurul fiecărei date sau grup restrâns de date. Tendinţele din ultimii ani cum ar fi SaaS, mobilitate, cloud, BYOD şi M2M, fac ca definiţia clasică a perimetrului să fie depăşită.
Credem că securitatea perimetrului aşa cum o percepem astăzi nu mai funcționează.
Cei de la Forrester au ajuns la aceeaşi concluzie în 2013 când au publicat, împreună cu NIST, un raport în care propun un nou model de securitate: Zero Trust. Practic, ei au ajuns la concluzia că perimetrul, așa cum a fost definit până în acel moment, nu mai poate fi apărat.
Companiile nu ar trebui să aibă încredere în traficul care provine din interiorul rețelelor organizației, ci să îl gestioneze ca trafic extern. Dacă tot traficul este coordonat în același mod, indiferent de originea acestuia, nu există niciun motiv pentru aplicaţiile externe să poată fi accesate numai din interiorul reţelei. Prin urmare, acestea pot- de altfel, este recomandat- să fie expuse la Internet. Astfel, companiile vor câştiga noi oportunităţi de productivitate, flexibilitate sporită și agilitate, permițând echipelor de securitate să se concentreze asupra aceleiași abordări privind protecția datelor ca și pentru aplicațiile externe.
Pentru a putea proteja datele companiei în acest nou context, o organizaţie trebuie să definească micro-perimetrele, precum şi un sistem detaliat de drepturi. Combinate cu o abordare "never trust, always verify" şi un control puternic al accesului, acestea vor duce la o securitate mai bună decât modelul "always trust internal users". Ca punct final, se recomandă și logarea și inspectarea întregului trafic.
O implementare a acestui model este cea creată de Google, construită pe principiul Zero Trust, numită BeyondCorp. Modelul este similar, dar aduce câteva recomandări noi:
Trebuie să fie verificată identitatea utilizatorului și a dispozitivului înainte de a-i acorda acces utilizatorului la o aplicație;
Accesul în sistem este un inventar dinamic al drepturilor bazate pe activitatea utilizatorului.
Aceste noi abordări aduc o nouă definiție a perimetrului companiei, combinându-l cu o verificare constantă a dispozitivelor și utilizatorilor, monitorizare constantă și o nouă configurare a drepturilor de acces.
Deși apreciem aceste noi modele care, fără îndoială, aduc organizațiile un pas în faţă în protejarea datelor, credem că nu sunt suficiente. Acesta este motivul pentru care noi, cei de la UNLOQ, am dus abordarea un pic mai departe.
În timp ce ne concentrăm în continuare asupra protejării perimetrului, ne îndreptăm atenţia către micro-perimetre. Folosim cele mai bune concepte din modelele anterioare, cărora le adăugăm criptarea de date la cel mai granular nivel. Într-un fel, inversăm abordarea: mai întâi criptam datele, iar mai apoi adăugăm diferite niveluri de securitate.
Există două aspecte principale care trebuie luate în considerare atunci când vorbim despre criptarea datelor:
Nivelul la care este realizată criptarea. Teoretic, cu cât aceasta este făcută mai aproape de client (browser, aplicaţie mobilă etc.), cu atât sistemul este mai sigur;
Similar cu modelele anterioare, abordarea noastră este construită pe trei concepte: autentificarea fiecărei solicitări, verificarea drepturilor și monitorizarea întregului trafic. Extindem conceptul de identitate la aplicații și lucruri, adăugând criptarea.
Obişnuim să spunem că facem datele irelevante. Reuşim acest lucru fie prin criptarea lor, fie le facem inutile, cum ar fi în cazul parolelor, fie le eliminăm de tot, prin autentificare fără parole.
Verificând constant drepturile de acces ale utilizatorilor, dispozitivelor și locațiilor la o anumită informaţie, oferă companiilor un nivel ridicat de control, securitate și transparență. În plus, tendința de criptare a datelor este confirmată şi de Gartner, care prezice o maturare a sistemelor de coordonare a cheilor de criptare în următorii 5 ani.
UNLOQ KMS este un sistem de controlare a cheilor de criptare care permite organizațiilor să aplice conceptul Seal Atomic în sistemele lor. Sistemul permite unei companii să administreze miliarde de chei, practic una pentru fiecare câmp din baza lor de date. Astfel, o bază de date existentă poate deveni o grămadă de text codificat fără nici un sens în lipsa cheilor.
UNLOQ KMS are patru componente principale care guvernează modul în care se acordă accesul la date: Permisiuni, Politici, Management de chei și Audit.
Sub-sistemul de Permisiuni permite companiilor să definească permisiuni granulare la cheile de criptare în funcţie de două concepte principale: identități și resurse. O identitate poate fi orice utilizator, aplicație sau obiect. Este considerată o resursă fie un obiect, cum ar fi toate datele asociate unui utilizator, fie un atribut asociat unui utilizator, cum ar fi numele de familie. Pentru fiecare resursă emitem o cheie de criptare. În plus, adăugăm diferite opțiuni de grupare și etichetare pentru a ajuta companiile să gestioneze date la scară mare, precum și protocolul HMAC pentru a semna toate tranzacțiile și, astfel, pentru a proteja companiile de încercările de compromitere a datelor.
UNLOQ KMS foloseşte sub- sistemul Politici pentru a verifica și a restricționa accesul la cheile de criptare pentru dispozitivele autorizate. O companie poate defini reguli bazate pe locația dispozitivului, tipul dispozitivului, semnătura, furnizor, sistemul de operare, browserul și pluginurile instalate. De exemplu, s-ar putea permite accesul la cheile de criptare pentru o anumită resursă unui anumit utilizator sau unui grup de utilizatori numai dacă accesează cheia din Cluj, de la ora 9 la 5, de pe un dispozitiv cu MacOS Sierra, ce are cea mai recentă versiune de Chrome instalată, care nu a fost compromis și care nu are instalate pluginuri.
Practic, Permisiunile şi Politicile definesc cine şi în ce condiţii poate să acceseze o anume cheie de criptare a unei resurse.
Sistemul de gestionare a cheilor face două lucruri majore:
Coordonează emiterea, rotaţia și protecția cheilor;
Există trei niveluri de chei, fiecare dintre ele o criptează pe cea precedentă:
Chei de criptare a resursei - cele care sunt folosite pentru a cripta conținutul într-o terță aplicaţie;
Chei de lanţ - utilizate pentru gruparea și criptarea cheilor de criptare a resurselor;
Fiecare cheie de lanț poate fi protejată de una sau mai multe chei principale. Astfel, companiile se pot asigura că nimeni din organizație nu poate schimba de unul singur sistemul de criptare. Am văzut câteva cazuri interesante în care acest lucru este de o valoare reală pentru instituțiile financiare multinaționale mari.
Sub-sistemul de Audit înregistrează orice încercare de a recupera o cheie de criptare și răspunsul la această solicitare. Pentru a securiza sistemul de audit, criptăm toată informaţia din datele transmise şi oferim un sistem de etichetare ce poate fi folosit pentru a filtra sau a căuta. Ca și în cazul permisiunilor, vom semna orice intrare și vom înlănţui logurile prin includerea în semnătură a semnăturii anterioare. Prin urmare, eliminarea unor intrări din lanţ nu este posibilă fără spargerea lanţului de semnături.
În funcţie de cine solicită cheia de criptare sau decriptare şi de cine efectuează criptarea sau decriptarea propriu-zisă, există patru cazuri posibile. Fiecare dintre acestea are avantaje diferite, așa cum vom vedea.
Înainte de a trece mai departe, să vedem cum s-ar întâmpla acest lucru în arhitectura tradițională bazată pe API:
Clientul, care poate fi orice aplicație web, mobilă sau desktop, ar solicita o resursă;
În acest caz, resursele sunt păstrate în format text. Dacă cineva a reuşit să treacă de nivelul aplicaţiei, acesta ar avea acces la întreaga bază de date. Acesta este, de fapt, cazul despre care auzim la ştiri mai mult sau mai puţin zilnic.
Cu toate acestea, dacă s-ar folosi KMS, lucrurile ar decurge după cum urmează:
Clientul solicită resursa;
Aplicația face apoi o solicitare către KMS cu API-ul cheii de lanţ, ID-ul resurselor şi ID-ul utilizatorului;
KMS verifică permisiunile utilizatorului. Dacă totul este în regulă, generează API-ul cheii de criptare a resursei și o trimite înapoi la aplicație;
Aplicația trimite clientului API-ul temporar al cheii de criptare a și textul codificat al resursei;
Clientul face o solicitare către KMS cu API-ul cheii de criptare a resursei și datele dispozitivului;
KMS verifică dacă dispozitivul are acces la cheia de criptare a resursei. Dacă da, eliberează cheia de criptare a resursei;
În mod evident, tot traficul trece printr-o conexiune TLS. În ceea ce priveşte performanța, scopul nostru este de a face orice solicitare API în mai puțin de 200ms.
Principalele avantaje sunt:
KMS nu cunoaște conținutul resurselor.
Acest caz ar putea fi preferat de unele organizații care utilizează versiunea cloud publică a UNLOQ KMS.
Cel de-al doilea caz este similar primului, diferența fiind că KMS este cel care efectuează criptarea / decriptarea. Dacă în abordarea anterioară, KMS trimite cheia de criptare clientului pentru a efectua criptarea / decriptarea, în acest caz clientul trimite conținutul resursei către KMS, iar KMS efectuează criptarea / decriptarea. Acest model păstrează avantajul de a primi direct datele dispozitivului. Pe de altă parte, în acest tip de implementare, cheia nu părăsește sistemul. Acest lucru ar putea fi preferat pentru unele organizații care folosesc KMS ca o implementare on-premise.
În al treilea caz, nu vor exista solicitări suplimentare de la nivelul clientului, însă aplicația va trebui să capteze datele clientului și să le transmită către KMS, în cazul în care dorește să aplice diferite politici. Deoarece criptarea / decriptarea se realizează la nivelul aplicației, conținutul nu ajunge niciodată la serverul KMS.
Ultimul caz este similar celui precedent, cu excepția faptului că aici aplicația va trimite conținutul resursei către KMS pentru a realiza criptarea / decriptarea.
În ceea ce privește standardele de criptare, sistemul utilizează cele mai populare: RSA 2048, AES 256-CBS, SHA 256, HMAC.
Prin emiterea cheilor la cel mai granular nivel, sistemul asigură dispersia riscurilor. Chiar dacă, într-un scenariu improbabil, una dintre chei este expusă, acest lucru compromite doar o anumită resursă, nu întreaga bază de date. În plus, ar trebui accesată în acelaşi timp atât baza de date a aplicațiilor, cât și KMS pentru a obţine datele organizației.
Prin toate principiile pe care le-am așezat la baza elaborării sistemului de management al cheilor, asigurăm confidenţialitate la nivel individual.
Principiile stepping stone şi key ceremony permit acoperirea cazurilor unor organizații mari care ar putea necesita ca generarea cheilor lanțului să fie numai din locații specifice și să fie controlate de un grup de oameni, nu de persoane individuale.
Prin separarea sarcinilor, ne asigurăm că persoanele care emit cheile lanțului sunt diferite de cele care gestionează sistemul. Sistemul asigură rotația cheilor și toate API-urile cheilor de criptare a resurselor sunt temporare. Prin înlănţuirea logurilor, asigurăm că traseul de audit este legal executoriu.
Companiile ar putea alege să-și cripteze complet baza de date la nivel de câmp sau să cripteze numai datele sensibile. Un motiv în spatele acestui fapt este legat de preocupările privind rezidența datelor. Există țări care interzic în mod strict transferul de informații personale din țară. Pentru o multinaţională acest lucru poate fi destul de problematic. Cu toate acestea, textul codificat nu este o informație personală.
Anonimizarea poate fi asigurată prin împărțirea unui tabel imens conținând datele utilizatorilor în informații personale (date care pot identifica o persoană) și informații care pot fi considerate statistice (cum ar fi orașul, vârsta etc.) și să cripteze cheia și poate informațiile personale. În acest fel, s-ar putea utiliza în siguranță datele statistice pentru diferite analize sau algoritmi AI. În alte cazuri de utilizare ar putea fi asigurarea gestionării drepturilor digitale sau a seifurilor de documente.
Un nivel ridicat de control, securitate și transparență este necesar într-o lume tot mai mobilă pentru organizațiile din întreaga lume, în special în contextul actual al digitalizării serviciilor şi a obligaţiilor de conformitate. În plus, așa cum a spus Einstein, "nu putem rezolva problemele noastre cu aceeași gândire pe care am avut-o atunci când le-am creat".
Credem că acest lucru nu a fost niciodată mai relevant decât în securitatea informatică de astăzi. Credem că trebuie să schimbăm modul în care privim mijloacele pe care le folosim pentru a proteja datele utilizatorilor. Credem că trebuie să ne mutăm atenția de la protejarea perimetrului la protejarea a ceea ce contează cu adevărat: datele.
de Mircea Vădan
de Emilia Toma
de Melania Duma
