Confidențialitatea cloud computing prin utilizarea stocării redundante în rețea este o metodă de organizare a stocării datelor în cloud, care reduce probabilitatea pierderii sau interceptării datelor utilizatorului, împărțind informațiile originale în mai multe elemente și distribuind aceste elemente către diferite stocări independente de rețea. Această abordare vă permite să nu vă faceți griji cu privire la siguranța unui anumit element de date utilizator, deoarece va fi imposibil să restaurați informațiile originale din acesta.
Lipsa de confidențialitate este adesea citată ca unul dintre principalele obstacole în calea adoptării cloud computing-ului. Există 5 modele de servicii cloud concepute pentru a proteja datele clienților:
Utilizarea acestor metode, cuplată cu stocarea criptată a datelor, va ajuta la eliminarea parțială a problemelor de confidențialitate și integritate a datelor. Cu toate acestea, chiar și atunci când folosește stocarea criptată, clientul trebuie să încredințeze toate datele sale serviciului de criptare. Mai mult, atunci când procesează date în cloud, furnizorul de procesare trebuie să aibă și acces la toate datele.
Pe de altă parte, pericolul dezvăluirii informațiilor confidențiale constă în specificul lucrului cu serviciile cloud. Cert este că datele sunt stocate și prelucrate de unul sau mai mulți furnizori externi, care, la rândul lor, pot fi localizați într-o altă jurisdicție decât jurisdicția clientului. Lipsa de informații despre locul unde sunt localizate fizic datele poate fi incomod pentru client.
În prezent, există diverse legi care interzic exportul de date sensibile în afara acestei jurisdicții. Un exemplu este regulamentul general privind protecția datelor cu caracter personal adoptat în UE. Pentru a îndeplini aceste cerințe, furnizorii introduc servicii cloud geo-localizate: un client poate cere unui furnizor să se asigure că datele sensibile sunt stocate și procesate numai pe sisteme care sunt situate fizic într-o anumită zonă geografică, cum ar fi în Uniunea Europeană. Cu toate acestea, chiar și astfel de măsuri sunt o garanție de securitate foarte controversată, deoarece majoritatea furnizorilor fac tranzacții care depășesc granițele unei țări. Ca rezultat, chiar și datele stocate pe echipamentele situate într-o anumită jurisdicție pot fi accesate fără restricții teritoriale. Astfel, serviciile cloud sunt în prezent vulnerabile la atacuri externe și, mai mult, atacatorii care lucrează în compania furnizorului vă pot accesa cu ușurință datele.
Această secțiune descrie un protocol care utilizează NAS redundant și independent pentru a îmbunătăți confidențialitatea în cloud computing. Mai întâi, să formulăm condițiile pentru funcționarea cu succes a acestui protocol:
Această figură arată o diagramă a modului în care un client interacționează cu un serviciu de stocare și procesare în cloud printr-un nod de control.
Clientul își trimite datele la intrarea C&C a nodului. Apoi nodul de control le împarte în segmente, care sunt ulterior distribuite între stocările cloud disponibile și transmise acolo printr-o rețea criptografică mixtă (mix-net). Procesul invers urmează un scenariu similar, cu excepția faptului că, pe lângă segmentele de date solicitate de client, la nodul de control ajung elemente false. Acest mecanism face mai dificilă interceptarea segmentelor adevărate. În continuare, nodul de control elimină elemente ale căror ID-uri nu se potrivesc cu valorile tabelului și, folosind intrările „ID element - ID vecin”, aranjează segmentele în ordinea inițială. După aceea, datele primite sunt transmise utilizatorului.
Schema implică utilizarea unei rețele criptografice mixte în cloud și agenți de gestionare. Agenții mențin o relație unu-la-unu cu stocarea în cloud. Fiecare agent are un ID, care, în principiu, ar trebui să împiedice nodul C&C să descopere acel agent. Apoi, trebuie să configurați un serviciu cloud care poate funcționa în modul de difuzare, similar unui canal IRC . În cele ce urmează, ne vom referi la un astfel de serviciu ca un nod IRC. Diagrama detaliată este prezentată mai jos:
Fie D o parte de date care trebuie împărțită și încărcată în stocarea în cloud. Un utilizator U trimite datele D către un nod C&C, criptându-le cu cheia publică C&C a nodului K C&C .
U → C&C : {store−full, Auth, ID D , D} K C&CAcest mesaj este ignorat de nodul C&C atunci când este transmis. Un identificator ocupat alocat pentru datele de intrare poate fi reutilizat numai după ce datele au fost șterse.
Nodul C&C împarte datele în segmente, generând secvența H = <D S ,R S > , unde
Secvența R S indică modul în care segmentele datelor originale sunt legate, fără această informație este imposibil să se colecteze datele originale. În secvența rezultată, fiecărui element de date d i i se atribuie un ID di . Apoi, nodul C&C distribuie această secvență între furnizorii de stocare în cloud, potrivind identificatorul fiecărui furnizor cu elementul de date corespunzător. H = {d1, d2, ..., dn}
(CSx,...,CSy) → (d1,...,dn)
Livrarea fragmentelor de date are loc printr-o rețea criptografică mixtă către un nod IRC. Nodul C&C trebuie să mențină un tabel de corespondențe între elementele de date și serviciile cloud către care au fost trimise aceste elemente. Mai mult, este necesar să se asigure unicitatea tuturor identificatorilor fragmentelor de date, iar fiecare identificator trebuie ales în așa fel încât să fie imposibil să se determine dacă doi astfel de identificatori aparțin aceleiași date sursă. Una dintre condițiile pentru funcționarea cu succes a algoritmului presupune un număr mare de utilizatori și un trafic ridicat, ceea ce va duce la faptul că majoritatea mesajelor trimise aleatoriu și de la diferiți utilizatori nu vor putea fi ordonate și corelate între ele. . Astfel, odată cu transferul eficient al tabelelor de căutare, deschiderea datelor pentru interceptare nu va duce la pierderea acestora: un potențial atacator poate vedea că un fragment cu identificatorul X este trimis în stocarea în cloud cu identificatorul Y, dar nu poate asocia un anumit fragment cu datele originale D sau cu un anumit utilizator. În cele din urmă, utilizarea rețelelor mixte va face ca ID-ul furnizorului NAS să nu se distingă de ID-ul blocului.
Presupunem că există un set de nnoduri de rețea independente . Fiecare dintre ele joacă rolul unui serviciu cloud, iar cheile și adresele lor publice de criptare sunt cunoscute de nodul C&C. Luați în considerare o rută a mesajelor de la nodul B la nodul A într-o rețea cu un agent m 1 :{m1,...,mn}
decodificarea denumirilor:
Numerele aleatoare Rm , Ra sunt folosite ca protecție împotriva trimiterii de mesaje identice. Aplicând recursiv această schemă de încapsulare, puteți obține o rețea mixtă cu un număr arbitrar de noduri.
Un nod IRC primește un număr mare de fragmente de date în general de la un număr mare de noduri C&C (altfel nu are rost în rețele mix-net). Fiecare mesaj conține un parametru CS j , care identifică agentul care ar trebui să proceseze acest fragment. Nodul IRC trimite toate mesajele unul câte unul în format broadcast către agenți.
Agentul de stocare renunță la toate mesajele cu identificatori străini și își trimite propriile mesaje către stocarea în cloud. În funcție de configurația și preferințele utilizatorului, agenții își pot duplica fragmentele ca protecție împotriva pierderii de informații în timpul transferului de date. De asemenea, agenții conțin înregistrări ale fragmentelor transferate în stocare și identificatorii asociați. Furnizorilor de stocare nu li se acordă acces la acești identificatori.
Când utilizatorul U solicită datele stocate D , următorul mesaj este trimis către nodul C&C:
U → C&C : {retrieve−full, Auth, IDD } KC&C
În plus, nodul de control, prin nodul IRC, accesează fiecare stocare în cloud în care se află fragmentele de date. Rețineți că atunci când solicitați o anumită parte de date, autentificarea utilizatorului nu este necesară. Cu toate acestea, nu este posibil să începeți pur și simplu procesul de salvare a datelor în direcția opusă, deoarece în acest caz un atacator va putea să potrivească identificatorul de stocare cu adresa sa. În schimb, nodul C&C va trimite o comandă „căutare fragmente de date” fiecărui nod IRC și îi va da ID-urile tuturor fragmentelor. Pentru a face mai dificilă pentru un potențial atacator să analizeze informațiile transmise, nodul IRC va completa lista de identificatori solicitați cu identificatori falși, care ulterior vor fi aruncați.
Apoi agenții de stocare în cloud vor trăda segmentele solicitate, precum și fragmente de date aleatorii care nu au legătură cu datele utilizatorului. Datele false vor fi transmise chiar dacă agentul de stocare nu găsește niciun fragment care se potrivește cu identificatorii solicitați. Datele din stocarea cloud sunt transmise înapoi la nodul IRC prin agenții respectivi printr-o rețea mixtă (MIX-NET).
Nodul IRC, la rândul său, trimite fragmentele găsite la nodul C&C, din nou prin MIX-NET.
∀i|IRC → C&C : mix({CSj , return−part, IDdi , di }) - mesaj de la nodul IRC C&C către nodul care conține al-lea fragment de date
În cele din urmă, nodul C&C aruncă fragmentele care nu se potrivesc cu lista de identificatori și pune restul împreună. Fișierul rezultat este trimis înapoi utilizatorului.
C&C → U : {U, return−full, IDD , D} KU
Când utilizatorul trebuie să efectueze calcule folosind datele stocate, o solicitare este trimisă la nodul de control indicând operația și cheia unică NU generată de utilizator.
U → C&C : {process−cnc, operation, Auth, IDD , Nu } KC&C
Similar punctului anterior, datele necesare sunt transferate din stocarea în cloud către un nod gestionat, colectate împreună și redirecționate către furnizorii de cloud computing. Nodul C&C , pe baza formatului de date, selectează numărul optim de noduri de cloud computing.
C&C → CPj : mix({{CPj , process−cp, operation, D, Kpc , Nc } Kcpj })
După calcule, rezultatul este trimis înapoi la nodul de control printr-o rețea mixtă (MIX-NET). Și nodul C&C, la rândul său, trimite rezultatul utilizatorului:
CPj → C&C : mix({{result−cnc, Dresult , Nc } KPC })
C&C → U : {U, result−user, Dresult , Nu } KU