în ultimii ani, world wide web a cunoscut o creștere exponențială a hackerilor, malwares, ransomwares și a altor programe sau părți rău intenționate care încearcă în mod constant să găsească o modalitate de a fura datele noastre personale: având în vedere acest scenariu, este de la sine înțeles că securizarea datelor dvs. a devenit una dintre cele mai importante sarcini pe care ar trebui să le prioritizăm, indiferent de rolul pe care îl jucăm de obicei. Nevoia generală (și urgentă) de a preveni accesul neautorizat la informații personale, sensibile și/sau critice este ceva ce ar trebui recunoscut de toată lumea – utilizatori finali, proprietari de servicii, Administratori de servere și așa mai departe: diferențele sunt în mare parte legate de ceea ce trebuie să protejăm și cum ar trebui să facem asta.

nu este nevoie să spunem că alegerea modului adecvat de a ne proteja datele este adesea ulterioară unei evaluări a riscurilor bine executate, urmată de o analiză costuri-beneficii, care este o abordare excelentă pentru a ne ajuta să găsim măsurile tehnice și organizatorice adecvate de implementat în scenariul nostru specific. Aceasta este, de asemenea, modalitatea corectă de a acționa în conformitate cu Regulamentul General privind protecția datelor (GDPR), astfel cum se prevede la art. 32-securitatea prelucrării:

luând în considerare stadiul actual al tehnicii, costurile de implementare și natura, domeniul de aplicare, contextul și scopurile prelucrării, precum și riscul de probabilitate și gravitate diferite pentru drepturile și libertățile persoanelor fizice, operatorul și persoana împuternicită de operator pun în aplicare măsuri tehnice și organizatorice adecvate pentru a asigura un nivel de securitate adecvat riscului

Iată o listă cu cele mai comune măsuri tehnice și organizatorice pentru a asigura protecția și securitatea datelor în zilele noastre:

  • controlul accesului: Protejați toate acces fizic la server, client și/sau camere de date cu chei, carduri cip, pereți, dulapuri, alarme și îi place.
  • minimizare: asigurați-vă că toate părțile autorizate pot accesa numai datele legate în mod specific de sarcinile și/sau autorizarea lor specifică, fără a li se permite să vadă altceva.
  • integritate: Protejați-vă datele împotriva pierderii, distrugerii sau deteriorării accidentale folosind contramăsuri adecvate (senzori de incendiu/inundații, recuperare în caz de dezastru și altele asemenea).
  • pseudonimizare: Înlocuiți datele legate de utilizator cu blocuri de text aleatorii, anonime, astfel încât proprietarul să poată păstra intrările (în scopuri statistice) și, în același timp, să le elimine de orice informații personale.
  • criptare în tranzit: asigurați-vă că datele sunt întotdeauna transmise folosind standarde puternice de criptare în tranzit (certificate SSL/TLS) și prin conexiuni sigure: Acest lucru se aplică și oricărui tip de site web și serviciu bazat pe web care conține formulare, ecrane de conectare, capacități de încărcare/descărcare și așa mai departe.
  • criptare în repaus: Protejați-vă unitățile locale de stocare a datelor (inclusiv cele utilizate de servere și clienți mobili pentru desktop &) cu un standard puternic de criptare at-rest; asigurați-vă că datele stocate în SaaS și serviciile bazate pe cloud sunt, de asemenea, criptate at-rest.
  • Confidențialitate: împiedicați prelucrarea neautorizată sau ilegală prin implementarea unor concepte precum separarea preocupărilor & separarea sarcinilor, aplicarea politicilor de parolă și așa mai departe.
  • Recuperabilitate: Asigurați-vă că toate datele relevante sunt supuse unor copii de rezervă regulate și, de asemenea, asigurați-vă că le verificați în mod regulat pentru a vă asigura că datele pot fi preluate cu succes.
  • evaluare: trimiteți întregul sistem la revizuiri tehnice periodice, audituri terțe, adoptați un set eficient de indicatori de securitate și așa mai departe.

în acest post vom vorbi despre două dintre aceste măsuri tehnice: criptarea în tranzit și criptarea în repaus, lăsând celelalte subiecte pentru articole suplimentare.

Introducere: cele trei etape ale datelor digitale

primul lucru pe care ar trebui să-l facem este să enumerăm câte” stări ” pot avea de fapt datele digitale și să ne asigurăm că le înțelegem pe fiecare dintre ele:

  • în repaus: aceasta este starea inițială a oricăror date digitale: în termeni foarte scurți, aceasta indică datele care sunt stocate undeva fără a fi utilizate și/sau transmise nimănui (inclusiv software, terțe părți, ființe umane etc.). De la Hard Disk-uri locale la depozite atașate la rețea, de la pendrive USB la dispozitive mobile, de la foldere de sistem la servere de baze de date, orice sistem de stocare fizic și logic, unitate sau dispozitiv este menit să fie utilizat pentru a conține date în repaus… cel puțin pentru o vreme.
  • în tranzit: cunoscut și sub numele de”în mișcare”. Acest lucru este relativ la datele care sunt transmise undeva în altă parte. Este demn de remarcat faptul că conceptul de „transfer de date” poate avea loc între orice număr de părți, fără a se limita la doar două (expeditorul și un receptor): de exemplu, atunci când transferăm un fișier de pe computerul nostru desktop pe laptopul nostru folosind LAN-ul nostru, practic efectuăm un transfer de date care implică o singură parte (SUA); invers, atunci când trimitem o tranzacție către o bază de date distribuită, cum ar fi un blockchain, aplicăm un transfer de date între o cantitate nedeterminată de părți (întregul nod blockchain).
  • în uz: ori de câte ori datele nu sunt doar stocate pasiv pe un hard disk sau pe un suport de stocare extern, ci sunt procesate de una sau mai multe aplicații – și, prin urmare, în proces de generare, vizualizare, actualizare, adăugare, ștergere și așa mai departe – se intenționează să fie „în uz”. Este de la sine înțeles că datele utilizate sunt susceptibile la diferite tipuri de amenințări, în funcție de locul în care se află în sistem și de cine le poate accesa și/sau utiliza. Cu toate acestea, criptarea datelor în uz este destul de dificil de realizat, deoarece cel mai probabil ar paraliza, împiedica sau prăbuși aplicația care o accesează de fapt: din acest motiv, cel mai bun mod de a proteja datele utilizate este de a se asigura că aplicația va avea grijă de o astfel de lucrare prin adoptarea celor mai sigure modele de dezvoltare și implementare în codul său sursă.

suma celor trei afirmații explicate mai sus se numește „cele trei etape ale datelor digitale”: acum că avem esența lor, suntem gata să ne scufundăm adânc în subiectele de criptare.

criptarea datelor în repaus

din definiția „în repaus” dată mai sus putem înțelege cu ușurință modul în care acest tip de date este de obicei într-o stare stabilă: nu călătorește în sistem sau rețea și nu este acționat de nicio aplicație sau terță parte. Este ceva care a ajuns la o destinație, cel puțin temporar.

motive să-l folosească

de ce ar trebui să ne cripta chiar aceste date, atunci? Ei bine, există o serie de motive întemeiate pentru a face acest lucru: să aruncăm o privire la cele mai semnificative.

furt fizic

dacă dispozitivul nostru este furat, criptarea în repaus va împiedica hoțul să poată accesa imediat datele noastre. Sigur, se poate încerca în continuare să-l decripta folosind brute-force sau alte metode de criptare-cracare, dar acest lucru este ceva care va lua o cantitate rezonabilă de timp: ar trebui să fie cu siguranta posibilitatea de a scoate contramăsuri adeguate înainte ca acest lucru se întâmplă, cum ar fi: schimbarea info cont el ar putea fi capabil de a vedea sau de a folosi; urmăriți dispozitivul nostru și / sau emiteți o „ștergeți toate datele” utilizând Serviciile noastre de gestionare a dispozitivelor la distanță Google sau Apple; și așa mai departe.

furt logic

dacă PC-ul nostru, site-ul web sau contul de e – mail sunt piratate de un utilizator sau software rău intenționat, criptarea în repaus va face ca infractorul să nu poată accesa datele noastre-chiar și atunci când este furat sau descărcat: este practic același scenariu de furt fizic, cu excepția faptului că este mult mai subtil, deoarece majoritatea utilizatorilor (sau administratorilor) nici măcar nu vor fi conștienți de acest lucru.

Iată o altă șansă bună de a ne aminti cuvintele minunate rostite de John T. Chambers, fost CEO al Cisco, Inc.:

există două tipuri de companii: cele care au fost hacked și cele care nu știu că au fost hacked.

având în vedere starea actuală a Internetului în zilele noastre și supra-abundența de malwares și încercări de hacking măsurabile, aceeași afirmație poate fi spus pentru orice utilizator final care posedă un dispozitiv web-enabled: 100% garantat.

erori umane

să nu mai vorbim de furturile fizice și/sau logice, există o mulțime de alte scenarii în care criptarea datelor în repaus ar putea fi un salvator: de exemplu, dacă ne-am pierdut smartphone-ul (și cineva îl găsește); sau dacă facem o greșeală în timp ce atribuim permisiuni, acordând utilizatorilor (sau clienților) neautorizați acces la fișiere/foldere/date pe care nu ar trebui să le poată vedea; sau dacă uităm parola locală pentru PC sau e-mail la vedere, permițând astfel oricui nu are chef să respecte confidențialitatea noastră să arunce o privire asupra lucrurilor noastre; iar lista ar putea continua o vreme.

cum ne poate ajuta

pentru a rezuma toate acestea, am putea răspunde la întrebările noastre anterioare cu o singură linie spunând că criptarea datelor noastre în repaus ne-ar putea ajuta să facem față mai bine unei posibile încălcări a datelor.

nu ne va ajuta să prevenim acest lucru – ceea ce este în mare parte o sarcină pentru firewall – uri, antivirusuri, bune practici și protocoale de securitate-dar cu siguranță ne va oferi șansa (și timpul) să configurăm contramăsurile adecvate, sperăm să minimizăm daunele generale cauzate de orice posibilă scurgere.

cum se implementează

implementarea unui protocol de securitate de criptare a datelor în repaus poate fi ușoară sau dificilă, în funcție de următorii factori:

  • ce surse/depozite de date fizice și logice dorim (sau avem) să protejăm: sursele fizice includ Hard Disk-uri, elemente NAS, smartphone-uri, pendrive USB și așa mai departe, în timp ce sursele logice includ baze de date locale sau la distanță, active bazate pe cloud, dispozitive virtualizate și așa mai departe;
  • cine trebuie să aibă acces la aceste date: (utilizatori locali sau la distanță sau alte terțe părți care se conectează la noi), software bazat pe om (cum ar fi MS Word) sau procese sau servicii automate (cum ar fi o sarcină de rezervă nocturnă);
  • cât de mult suntem dispuși să sacrificăm în ceea ce privește performanța generală și/sau ușurința accesului pentru a spori securitatea: putem cere tuturor utilizatorilor noștri locali (și la distanță) să decripteze aceste date înainte de a le putea accesa? Ar trebui să folosim o parolă, un jeton fizic sau un cod OTP? Putem face criptarea suficient de transparentă pentru a nu împiedica utilizatorii noștri externi și, de asemenea, pentru a permite aplicațiilor și instrumentelor noastre software să se ocupe de datele criptate ori de câte ori vor trebui să se ocupe de acestea?

din fericire, acești factori sunt bine cunoscuți de majoritatea instrumentelor de criptare at-rest, care au fost concepute pentru a ne proteja datele fără a compromite funcționalitatea generală a mediului nostru:

  • dacă dorim să criptăm unități de Hard Disk fizice (sau logice), putem folosi instrumente software excelente, cum ar fi VeraCrypt (100% gratuit) sau AxCrypt (versiune gratuită disponibilă);
  • dacă trebuie să ne protejăm pendrivele USB, putem folosi instrumentele menționate mai sus sau să achiziționăm o unitate Flash criptată hardware care implementează mecanisme de deblocare bazate pe amprente sau parole (începând de la 20~30 de dolari);
  • dacă dorim să criptăm datele stocate într-un sistem de gestionare a bazelor de date, majoritatea SGBD disponibile astăzi oferă tehnici de criptare native (criptare InnoDB tablespace pentru MySQL și MariaDB, criptare transparentă a datelor pentru MSSQL și așa mai departe);
  • dacă căutăm o modalitate de a stoca în siguranță mesajele noastre de e-Mail, putem adopta cu ușurință un standard securizat de criptare a e-mailurilor, cum ar fi S/MIME sau PGP (ambele sunt gratuite): deși aceste protocoale sunt în mare parte legate de criptarea în tranzit, deoarece protejează datele destinate în mare parte să fie transferate părților la distanță, de fapt sunt utilizate în mod obișnuit pentru a efectua o criptare pe partea clientului, ceea ce înseamnă că protejează mesajele de e-mail în timp ce sunt încă în repaus. Inutil să spun, deoarece aceste mesaje vor fi cel mai probabil trimise, destinația noastră va trebui, de asemenea, să adopte același standard pentru a le putea citi.

criptarea datelor în tranzit

după cum sugerează și numele, datele în tranzit ar trebui văzute la fel ca un flux de transmisie: un exemplu excelent de date în tranzit este o pagină web tipică pe care o primim de pe internet ori de câte ori navigăm pe web. Iată ce se întâmplă sub capotă pe scurt:

  1. trimitem o solicitare HTTP (sau HTTPS) către serverul care găzduiește site-ul web pe care îl vizităm.
  2. serverul web acceptă solicitarea noastră, o procesează găsind conținutul (static sau dinamic) pe care l-am cerut, apoi ni-l trimite ca răspuns HTTP (sau HTTPS) printr-un port TCP dat (de obicei 80 pentru HTTP și 443 pentru HTTPS).
  3. clientul nostru, de obicei un browser web precum Google Chrome, Firefox sau Edge, primește răspunsul HTTP(e), îl stochează în memoria cache internă și ni-l arată.

după cum putem vedea, există în mod clar o transmisie de date între server și client: în timpul acestei trasmission, datele solicitate (codul HTML al paginii web) devin un flux care trece prin cel puțin cinci stări diferite:

  1. începe la-rest (stocare server),
  2. apoi se schimbă la in-use (memorie server web),
  3. apoi la in-transit (folosind protocolul de transfer hipertext pe un port TCP dat),
  4. apoi din nou la in-use (browser web),
  5. și în final La at-rest (cache client).

motive pentru a-l utiliza

acum, să luăm de la sine înțeles că atât serverul, cât și clientul au implementat un nivel puternic de criptare a datelor în repaus: aceasta înseamnă că prima și a cincea stare sunt sigure pe plan intern, deoarece orice încercare de intruziune ar fi făcută împotriva datelor criptate. Cu toate acestea, statul terț – în care datele sunt în tranzit-ar putea fi criptat sau nu, în funcție de protocolul pe care serverul și Clientul îl folosesc de fapt pentru a transmite datele.

Iată ce se întâmplă de obicei sub capotă atunci când se utilizează protocolul HTTP:

Encryption in-transit and Encryption at - rest-definiții și cele mai bune practici

după cum putem vedea, problema de securitate este destul de evidentă: atunci când serverul web procesează cererea primită și decriptează în mod transparent datele solicitate, canalul utilizat pentru a le transfera către clientul web (HTTP) nu este criptat: prin urmare, orice parte ofensatoare care reușește să realizeze cu succes un atac adecvat (a se vedea mai jos) ar putea avea acces imediat la datele noastre necriptate .

cum ne poate ajuta

dacă sunteți curioși ce fel de atacuri pot fi folosite împotriva unui protocol de transmisie bazat pe TCP necriptat, cum ar fi HTTP, iată câteva amenințări de care ar trebui să fiți conștienți:

  • interceptarea: un atac de nivel de rețea care se concentrează pe captarea pachetelor mici din rețeaua transmisă de alte computere și citirea conținutului de date în căutarea oricărui tip de informații (mai multe informații aici).
  • omul din mijloc: un atac bazat pe manipulare în cazul în care atacatorul relee în secret și/sau modifică comunicarea între două părți pentru a le face să creadă că comunică direct între ele (mai multe informații aici).

implementarea protocoalelor adecvate de criptare în tranzit pentru a asigura punctele finale critice de transfer de date ne va ajuta cu siguranță să prevenim aceste tipuri de amenințări.

cum se implementează

implementarea unui model eficient de criptare în tranzit este în mare parte o chestiune de a respecta o serie largă de recomandări și cele mai bune practici în timp ce proiectați transferul real de date: ce protocoale să (nu) utilizați, ce software să (nu) adoptați și așa mai departe. De exemplu:

  • ori de câte ori dispozitivul de transmisie este accesibil prin interfața web, traficul web trebuie transmis numai prin Secure Sockets Layer (SSL) folosind protocoale de securitate puternice, cum ar fi Transport Layer Security (TLS): acest lucru se aplică oricărui site web și / sau serviciu accesibil WAN, inclusiv servere de e-mail și Like-uri. Începând de astăzi, cel mai bun (și mai simplu) mod de a implementa securitatea TLS și de a implementa criptarea în tranzit pentru orice site web este obținerea unui certificat SSL/TLS HTTPS: acestea pot fi achiziționate fie de la autoritățile CA înregistrate (Comodo, GlobalSign, GoDaddy, DigiCert și lista lor uriașă de revânzători/subselleri), fie generate automat printr-un proces de auto-semnare, așa cum am explicat pe scurt în acest post. Deși certificatele auto-semnate vor acorda același nivel de criptare al omologilor lor semnați CA, în general, nu vor fi de încredere de către utilizatori, deoarece clienții browserului lor nu vor putea verifica buna credință a identității emitentului (dvs.), semnalând site-ul dvs. ca fiind „de încredere”: din acest motiv, acestea ar trebui utilizate numai pe servere/servicii neproductive (sau care nu sunt accesibile publicului).
  • orice date transmise prin e-mail ar trebui să fie securizate folosind instrumente de criptare a e-mailurilor puternice din punct de vedere criptografic, cum ar fi S/MIME sau PGP, pe care le-am acoperit deja când am vorbit despre criptarea datelor la repaus: deși aceste protocoale își efectuează criptarea la nivel de client (și, prin urmare, la repaus), sunt, de asemenea, excelente pentru a proteja fluxul asincron în tranzit al unui mesaj de e-mail.
  • orice date binare trebuie criptate folosind instrumente adecvate de criptare a fișierelor înainte de a fi atașate la e-mail și/sau transmise în orice alt mod. Majoritatea protocoalelor de compresie, inclusiv ZIP, RAR și 7Z, acceptă un nivel decent de criptare protejată prin parolă în zilele noastre: utilizarea lor este adesea o modalitate excelentă de a adăuga un nivel suplimentar de securitate și de a reduce dimensiunea atașamentului în același timp
  • transmiterea Non-web a textului și / sau a datelor binare ar trebui, de asemenea, să fie criptată prin criptarea la nivel:
    • dacă baza de date a aplicației se află în afara serverului de aplicații, conexiunea dintre baza de date și aplicație trebuie criptată folosind algoritmi criptografici conformi FIPS.
    • ori de câte ori criptarea la nivel de aplicație nu este disponibilă, implementați criptarea la nivel de rețea, cum ar fi IPSec sau SSH tunneling și/sau asigurați-vă că transmisia în sine este efectuată folosind dispozitive autorizate care funcționează în subrețele protejate cu controale puternice de firewall (VPN și altele asemenea).

următorul tabel prezintă câteva exemple de protocoale de rețea nesigure pe care ar trebui să le evitați și omologii lor securizați pe care ar trebui să le utilizați în schimb:

Transfer Type What to avoid (insecure) What to use (secure)
Web Access HTTP HTTPS
E-Mail Servers POP3, SMTP, IMAP POP3S, IMAPS, SMTPS
File Transfer FTP, RCP FTPS, SFTP, SCP, WebDAV over HTTPS
Remote Shell telnet SSH2
Remote Desktop VNC radmin, RDP

criptare End-to-End

criptarea în tranzit este foarte utilă, dar are o limitare majoră: nu garantează că datele vor fi criptate la punctul de plecare și nu vor fi decriptate până când nu sunt utilizate. Cu alte cuvinte, datele noastre ar putea fi în continuare precedate de interceptori ocazionali și/sau rău intenționați, inclusiv furnizori de internet, furnizori de servicii de comunicații și oricine ar putea accesa cheile criptografice necesare pentru a decripta datele în timpul tranzitului.

depășirea unei astfel de limitări este posibilă datorită criptării End-to-End (E2EE), o paradigmă de comunicare în care numai părțile finale care comunică – de exemplu, utilizatorii – pot decripta și, prin urmare, citi mesajele. Datele criptate End-to-end sunt criptate înainte de a fi transmise și vor rămâne criptate până când vor fi primite de partea finală.

motive să-l folosească

pentru a înțelege mai bine modul de criptare end-to-end superseeds criptare în tranzit în ceea ce privește rezistența la trage cu urechea, să ne imaginăm următoarele scenarii.

  1. să presupunem că o terță parte reușește să-și planteze propriul certificat rădăcină pe o autoritate de certificare de încredere: o astfel de acțiune ar putea fi teoretic efectuată de un actor de stat, de un serviciu de poliție sau chiar de un operator rău intenționat/corupt al unei autorități de certificare. Oricine este capabil să facă acest lucru ar putea opera cu succes un atac om-în-mijloc asupra conexiunii TLS în sine, ascultând conversația și, eventual, chiar manipulând-o. Datele criptate End-to-end sunt rezistente nativ la acest tip de atac, deoarece criptarea nu este efectuată la nivel de server.
  2. criptarea End-to-end poate crește, de asemenea, nivelul de protecție între procesele utilizatorului generate de un sistem de operare. Vă amintiți defectele recente ale procesorului numite SPECTRE și MELTDOWN? Ambele au permis unei terțe părți rău intenționate (cum ar fi un proces necinstit) să citească datele din memorie fără a fi autorizate să facă acest lucru. Criptarea End-to-end ar putea evita un astfel de scenariu atâta timp cât criptarea este efectuată între procesul utilizatorului (spre deosebire de kernel), împiedicând astfel introducerea în memorie a oricăror date necriptate.

cum ne poate ajuta

criptarea End-to-end este cea mai sigură formă de comunicare care poate fi utilizată în zilele noastre, deoarece asigură că numai dvs. și persoana cu care comunicați puteți citi ceea ce este trimis și nimeni între ele, nici măcar serviciul care efectuează efectiv transmisia între colegi. Diverse implementări de criptare end-to-end sunt deja eficiente pe majoritatea aplicațiilor și serviciilor de mesagerie (inclusiv Whatsapp, LINE, Telegram și altele asemenea). Într-un scenariu tipic de „aplicație de comunicare”, mesajele sunt securizate cu o blocare și numai expeditorul și destinatarul au cheia specială necesară pentru a le debloca și citi: pentru o protecție suplimentară, fiecare mesaj este trimis automat cu propria blocare și cheie unică.

cum se implementează

criptarea End-to-end poate fi utilizată pentru a proteja orice: de mesaje de chat, fișiere, fotografii, date senzoriale pe dispozitive IoT, date permanente sau temporare. Putem alege ce date dorim să criptăm end-to-end. De exemplu, este posibil să dorim să păstrăm informații benigne legate de o aplicație de chat (cum ar fi marcajele de timp) în text clar, dar să criptăm end-to-end conținutul mesajului.

  • fiecare utilizator are o cheie publică privată & pe care software-ul trebuie să o genereze pe dispozitivul utilizatorilor la înscriere sau data viitoare când se conectează.
  • cheia publică a utilizatorului este publicată într-un loc public (cum ar fi un serviciu de gestionare a cheilor bazat pe REST): acest lucru este necesar pentru ca utilizatorii să își găsească reciproc cheile publice și să poată cripta datele între ele.
  • cheia privată a utilizatorului rămâne pe dispozitivul utilizatorului, protejată de magazinul de chei nativ al sistemului de operare (sau de alte magazine securizate).
  • înainte de a trimite un mesaj de chat sau de a partaja un document, aplicația criptează conținutul folosind cheia publică a destinatarului (partea clientului).

concluzie

călătoria noastră prin diferitele paradigme de criptare este completă: sperăm sincer că această imagine de ansamblu va ajuta utilizatorii și administratorii de sistem să-și sporească gradul de conștientizare a diferitelor tipuri de criptare disponibile astăzi.

Lasă un răspuns

Adresa ta de email nu va fi publicată.

lg