Pe măsură ce lumea devine din ce în ce mai bazată pe date, gestionarea în siguranță a datelor utilizatorilor este mai critică ca niciodată.
În calitate de dezvoltatori, sarcinile noastre sunt deja destul de grele: ne confruntăm cu sisteme extrem de complexe și fragile, cu mai multe puncte de defecțiune, în timp ce transpunem dorințele umane în interfețe și backend-uri. A adăuga la sarcină este un aspect emergent și esențial: securitatea datelor. Și pentru un motiv întemeiat: noi, în calitate de clienți, suntem înfuriați dacă datele noastre sunt folosite greșit (deci este corect să oferim utilizatorilor noștri o experiență sigură și plăcută), iar guvernele și întreprinderile le cer pentru conformitate.
Cuprins
Securitatea datelor ca o treabă
Ceea ce îngreunează securitatea este că are mai multe straturi și devine lucrul-responsabilitatea-fiecărei-este-responsabilitatea-nimănui. Într-o echipă modernă de cloud, mai multe echipe controlează direct intrarea/ieșirea datelor: dezvoltatori, administratori de baze de date, administratori de sistem (oamenii DevOps, dacă doriți), utilizatori privilegiați de back-office și așa mai departe. Aceste roluri/echipe își pot închide rapid ochii și pot considera securitatea datelor ca fiind problema celorlalți. Totuși, realitatea este că au propriile lumi de care să aibă grijă, deoarece un administrator al bazei de date nu poate controla partea de securitate a aplicației, o persoană DevOps nu poate face absolut nimic cu privire la accesul la birou și așa mai departe.
Dezvoltatori și securitatea datelor
Acestea fiind spuse, dezvoltatorii au cea mai mare suprafață de acces atunci când vine vorba de date: ei construiesc fiecare parte a aplicației; se conectează la diverse servicii backend; jetoanele de acces cu feribotul înainte și înapoi; au întregul cluster de baze de date din care să citească/scrie la comanda lor; aplicațiile pe care le scriu au acces necontestat la toate părțile sistemului (de exemplu, o aplicație Django în producție are toate privilegiile de a arunca sau șterge întreaga colecție S3 din ultimii zece ani) și așa mai departe. Ca urmare, cea mai mare șansă de neglijență sau de supraveghere în ceea ce privește securitatea există la nivelul codului sursă și este responsabilitatea directă a dezvoltatorului.
Acum, securitatea datelor este o groapă fără fund și nu am cum să pot zgâria suprafața într-un singur post. Cu toate acestea, vreau să acopăr terminologia esențială pe care dezvoltatorii trebuie să o cunoască pentru a-și păstra aplicațiile în siguranță. Gândiți-vă la asta ca App Data Security 101.
Să începem!
Hashing
Dacă doriți o definiție extrem de riguroasă, există întotdeauna Wikipedia, dar în termeni simpli, hashing este procesul de conversie a datelor într-o altă formă, în care informațiile sunt ilizibile. De exemplu, folosind procesul binecunoscut (și foarte nesigur) al Codare Base64, șirul „Secretul meu este în siguranță cu tine?” poate fi convertit („hashed”) în „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Dacă începi să-ți scrii jurnalul personal în format Base64, de exemplu, familia ta nu îți poate citi secretele (cu excepția cazului în care știu să decodeze din Base64)!
Această idee de amestecare a datelor este folosită la stocarea parolelor, numerelor cărților de credit etc., în aplicații web (de fapt, ar trebui să fie folosită în toate tipurile de aplicații). Ideea, desigur, este că, în cazul unei încălcări a datelor, atacatorul nu ar trebui să poată folosi parolele, numerele cărților de credit etc., pentru a produce daune reale. Pentru a efectua această hashing sunt utilizați algoritmi foarte robusti și sofisticați; ceva de genul Base64 va fi o glumă și va fi spart instantaneu de orice atacator.
Hashingul parolei folosește o tehnică criptografică cunoscută sub numele de hashing unidirecțional, ceea ce înseamnă că, deși este posibil să amestecați datele, nu este posibil să le decriptați. Atunci de unde știe aplicația că este parola ta când te autentifici? Ei bine, folosește același proces și compară forma amestecată a ceea ce tocmai ai introdus ca parolă cu forma amestecată stocată în baza de date; dacă se potrivesc, ai voie să te autentifici!
În timp ce suntem pe tema hashurilor, iată ceva interesant. Dacă descărcați vreodată software sau fișiere de pe Internet, s-ar putea să vi s-a spus să verificați fișierele înainte de a le folosi. De exemplu, dacă doriți să descărcați Ubuntu Linux ISO, pagina de descărcare vă va arăta o opțiune pentru a verifica descărcarea; dacă faceți clic pe el, se va deschide o fereastră pop-up:
Fereastra pop-up vă spune să rulați o comandă, care, în esență, va hash întregul fișier pe care tocmai l-ați descărcat și va compara rezultatul cu șirul hash pe care îl vedeți pe pagina de descărcare: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db. Această conversie se realizează folosind algoritmul SHA256a cărui mențiune o puteți vedea în părțile finale ale comenzii: shasum -a 256 –check.
Ideea este că, dacă hash-ul produs prin cecul tău este diferit, asta înseamnă că cineva s-a amestecat cu descărcarea ta și ți-a furnizat un fișier compromis.
Unele nume familiare pe care le veți auzi în domeniul hashing-ului parolelor sunt MD5 (nesigur și acum dispar), SHA-1 și SHA-2 (familii de algoritmi, din care SHA-256 este membru, la fel ca SHA-512), SCRYPT, BCRYPT etc.
Sărare
Toate tipurile de securitate este un joc cu pisica și șoarecele: hoțul învață sistemul actual și vine cu un nou crack, care este observat, iar producătorii de lacăt își îmbunătățesc jocul și așa mai departe și așa mai departe. Criptografia nu face excepție. În timp ce convertirea hashurilor înapoi în parole a devenit imposibilă, atacatorii au dezvoltat de-a lungul timpului tehnici sofisticate care combină presupunerile inteligente cu puterea de calcul absolută; ca urmare, de nouă ori din zece, ei pot prezice parola corectă, având în vedere doar hash-ul.
„Domnul. Rumpelstiltskin, presupun?!”
Ca urmare, s-a dezvoltat tehnica sărării. Tot ceea ce înseamnă este că calculul hash al unei parole (sau al oricăror date) se va face pe baza unei combinații a două lucruri: datele în sine, precum și un șir nou aleatoriu pe care atacatorul nu îl poate ghici. Deci, cu sărare, dacă dorim să indexăm parola superman009, am selecta mai întâi un șir aleatoriu ca „sare”, de exemplu, bCQC6Z2LlbAsqj77, apoi efectuăm calculul hash pe superman009-bCQC6Z2LlbAsqj77. Hashul rezultat se va abate de la structurile obișnuite produse de algoritm, reducând considerabil sfera de aplicare a ingineriei inverse inteligente sau a presupunerilor.
Atât Hashing, cât și Salting sunt domenii incredibil de complicate și sunt în continuă evoluție. Deci, în calitate de dezvoltator de aplicații, nu am avea niciodată de-a face direct cu ei. Dar ne-ar ajuta foarte mult dacă le-am ști și am putea lua decizii mai bune. De exemplu, dacă mențineți un cadru PHP vechi și se întâmplă să vedeți că folosește hash-uri MD5 pentru parole, știți că este timpul să introduceți o altă bibliotecă de parole în procesul de creare a contului de utilizator.
Chei
Ați întâlni adesea termenul „chei” în contextul criptării. Până acum, am acoperit hashingul parolei sau criptarea unidirecțională, unde convertim datele ireversibil și distrugem forma originală. Aceasta este o idee proastă pentru utilizarea practică de zi cu zi – un document scris și trimis prin e-mail atât de sigur încât nu poate fi citit niciodată nu este de folos! Astfel, dorim să criptăm datele astfel încât să dorim ca informațiile să fie deschise cu expeditorul și destinatarul, dar în timp ce sunt transferate sau în timp ce sunt stocate, ar trebui să fie ilizibile.
Pentru aceasta, conceptul de „cheie” există în criptografie. Este exact așa cum sună: cheia unei încuietori. Persoana care deține informațiile le amestecă folosind un secret numit cheie. Cu excepția cazului în care receptorul/atacatorul are această cheie, este imposibil să descifrezi datele, indiferent cât de sofisticați ar fi algoritmii lor.
Taste rotative
În timp ce cheile fac criptarea posibilă și fiabilă, ele prezintă riscurile pe care parolele le fac: odată ce cineva cunoaște cheia, întregul joc este terminat. Imaginați-vă un scenariu în care cineva pirata o parte a unui serviciu precum GitHub (chiar dacă pentru câteva secunde) și poate pune mâna pe un cod vechi de 20 de ani. În interiorul codului, ei găsesc și cheile criptografice folosite pentru a cripta datele companiei (practică îngrozitoare de a stoca cheile împreună cu codul sursă, dar ai fi surprins cât de des se întâmplă acest lucru!). Dacă compania nu s-a deranjat să-și schimbe cheile (la fel ca și parolele), aceeași cheie poate fi folosită pentru a face ravagii.
Ca urmare, practica de schimbare a tastelor frecvent a evoluat. Aceasta se numește rotație cheie și, dacă utilizați orice furnizor respectabil de cloud PaaS, ar trebui să fie disponibil ca serviciu automat.
Credit imagine: AWS
De exemplu, AWS are un serviciu dedicat pentru acest numit AWS Key Management Service (KMS). Un serviciu automatizat vă scutește de problemele legate de schimbarea și distribuirea cheilor între toate serverele și este o problemă în zilele noastre când vine vorba de implementări mari.
Criptografia cu cheie publică
Dacă toate discuțiile anterioare despre criptare și chei te fac să crezi că este foarte greoaie, ai dreptate. Păstrarea cheilor în siguranță și transmiterea lor, astfel încât doar receptorul să poată vedea datele se confruntă cu probleme logistice care nu ar fi permis comunicațiilor sigure de astăzi să prospere. Dar totul datorită criptografiei cu cheie publică, putem comunica sau face achiziții online în siguranță.
Acest tip de criptografie a fost o descoperire matematică majoră și este singurul motiv pentru care Internetul nu se destramă din cauza fricii și a neîncrederii. The detalii ale algoritmului sunt complicate și extrem de matematice, așa că le pot explica aici doar conceptual.
Credit imagine: Electronic Frontier Foundation
Criptografia cu chei publice se bazează pe utilizarea a două chei pentru a procesa informații. Una dintre chei se numește cheie privată și ar trebui să rămână privată cu dvs. și să nu fie niciodată partajată cu nimeni; celălalt se numește Public Key (de unde provine numele metodei) și ar trebui să fie publicat public. Dacă vă trimit date, mai întâi trebuie să vă obțin cheia publică și să criptez datele și vi le trimit; la final, puteți decripta datele folosind cheia privată și combinația cheii publice. Atâta timp cât nu dezvălui cheia privată din greșeală, îți pot trimite date criptate pe care doar tu le poți deschide.
Frumusețea sistemului este că nu am nevoie să vă cunosc cheia privată, iar oricine interceptează mesajul nu poate face nimic pentru a-l citi, deși are cheia dumneavoastră publică. Dacă vă întrebați cum este posibil acest lucru, cel mai scurt și cel mai non-tehnic răspuns vine din proprietățile înmulțirii numerelor prime:
Este greu pentru computere să factorizeze numere prime mari. Deci, dacă cheia originală este foarte mare, puteți fi sigur că mesajul nu poate fi decriptat nici măcar peste mii de ani.
Securitatea stratului de transport (TLS)
Acum știți cum funcționează Criptografia cu cheie publică. Acest mecanism (cunoașterea cheii publice a receptorului și trimiterea lor de date criptate folosind aceasta) este ceea ce se află în spatele întregii popularități HTTPS și este ceea ce face ca Chrome să spună: „Acest site este securizat”. Ceea ce se întâmplă este că serverul și browserul criptează traficul HTTP (rețineți că paginile web sunt șiruri de text foarte lungi pe care browserele le pot interpreta) cu cheile publice ale celuilalt, rezultând HTTP Securizat (HTTPS).
Credit imagine: Mozilla. Este interesant de remarcat că criptarea nu are loc pe Stratul de transport ca atare; cel Modelul OSI nu spune nimic despre criptarea datelor. Doar că datele sunt criptate de aplicație (în acest caz, browser) înainte de a fi transmise stratului de transport, care ulterior le lasă la destinație, unde sunt decriptate. Cu toate acestea, procesul implică stratul de transport și, la sfârșitul zilei, totul are ca rezultat un transport sigur al datelor, așa că termenul liber de securitate a stratului „transport” a rămas.
S-ar putea chiar să întâlniți termenul Secure Socket Layer (SSL) în unele cazuri. Este același concept ca și TLS, cu excepția faptului că SSL a apărut cu mult înainte și acum este eliminat în favoarea TLS.
Criptare completă a discului
Uneori, nevoile de securitate sunt atât de intense încât nimic nu poate fi lăsat la voia întâmplării. De exemplu, serverele guvernamentale în care sunt stocate toate datele biometrice ale unei țări nu pot fi furnizate și rulate ca serverele de aplicații normale, deoarece riscul este prea mare. Pentru aceste necesități nu este suficient ca datele să fie criptate doar atunci când sunt transferate; trebuie să fie criptat și atunci când este în repaus. Pentru aceasta, criptarea completă a discului este utilizată pentru a cripta întregul hard disk pentru a se asigura că datele sunt sigure chiar și atunci când sunt încălcate fizic.
Este important de reținut că criptarea completă a discului trebuie făcută la nivel hardware. Asta pentru că dacă criptăm întregul disc, sistemul de operare este, de asemenea, criptat și nu poate rula când pornește mașina. Deci, hardware-ul trebuie să înțeleagă că conținutul discului este criptat și trebuie să efectueze decriptarea din mers pe măsură ce trece blocurile de disc solicitate către sistemul de operare. Datorită acestui lucru suplimentar, criptarea completă a discului are ca rezultat citiri/scrieri mai lente, ceea ce trebuie să fie reținut de dezvoltatorii unor astfel de sisteme.
Criptare end-to-end
Cu coșmarurile de confidențialitate și securitate în curs de desfășurare ale rețelelor sociale mari din zilele noastre, nimeni nu este conștient de termenul „criptare end-to-end”, chiar dacă nu au nimic de-a face cu crearea sau întreținerea aplicațiilor.
Am văzut mai devreme cum Full Disk Encryption oferă cea mai bună strategie anti-glonț, dar pentru utilizatorul obișnuit, nu este convenabil. Adică, imaginați-vă că Facebook dorește ca datele de pe telefon pe care le generează și le stochează în telefon să fie în siguranță, dar nu poate avea acces la criptarea întregului telefon și la blocarea tuturor celorlalte în acest proces.
Din acest motiv, aceste companii au început criptarea end-to-end, ceea ce înseamnă că datele sunt criptate atunci când sunt create, stocate sau transferate de aplicație. Cu alte cuvinte, chiar și atunci când datele ajung la destinatar, sunt complet criptate și sunt accesibile doar de către telefonul destinatarului.
Credit imagine: Google
Rețineți că criptarea end-to-end (E2E) nu oferă nicio garanție matematică, așa cum o face criptografia cu cheie publică; este doar o criptare standard în care cheia este stocată împreună cu compania, iar mesajele dvs. sunt la fel de sigure pe cât decide compania.
Concluzie 👩🏫
Probabil ați auzit deja de majoritatea acestor termeni. Poate chiar pe toate. Dacă da, te-aș încuraja să revizuiești înțelegerea acestor concepte, precum și să evaluezi cât de serios le iei. Amintiți-vă, securitatea datelor aplicației este un război pe care trebuie să-l câștigați de fiecare dată (și nu doar o dată), deoarece chiar și o singură breșă este suficientă pentru a distruge industrii întregi, cariere și chiar vieți!