Cel mai bun mod de a cripta datele sensibile de pe server cu HSM și chei simetrice

Trebuie să stochez datele sensibile (cum ar fi fotografiile clienților) într-o bază de date SQL în cel mai sigur mod în cazul unor încălcări de securitate. Datele nu vor fi accesate de către clienți, ci doar proceselor interne care efectuează unele validări. Clienții nu au nicio introducere, cum ar fi parole, doar se înregistrează la noi și ținem evidența datelor lor. Criptarea pe partea clientului nu este posibilă în configurația actuală, de aceea trebuie să criptăm pe partea serverului și avem, de asemenea, un HSM în rețeaua noastră privată cu chei private.

O idee a fost să folosiți criptarea cheii simetrice și să stocați acea cheie la nivel local.Problema cu această soluție este că, dacă un atacator obține acces la server și la baza de date, el poate obține cu ușurință acea cheie și poate decripta datele.

O altă idee a fost să folosești modulul HSM pe care îl are compania și să criptezi cheia simetrică cu cheia publică HSM. Când serverul trebuie să gestioneze datele, trimite cheia criptată la HSM și gestionează cheia simetrică numai în memorie. Problema cu acea soluție este că trebuie să stochez acreditările de conexiune HSM și dacă un atacator o pune mâna pe aceasta și decriptează cheia simetrică, întreaga bază de date este compromisă.

Ar fi suficient de sigur pentru a genera chei simetrice aleatorii pentru fiecare fișier pe care îl criptăm, apoi să criptăm cheia simetrică cu cheia publică HSM și să stocăm atât datele criptate, cât și cheia simetrică criptată? Și dacă da, care ar fi cel mai bun mod de a-l păstra? Un șir pkcs7 base64?

Deoarece acesta este mai mult un SE teoretic, voi face o abordare teoretică mai generică împreună cu câteva detalii specifice. Trebuie să definiți mai întâi un model de amenințare. Pentru a-l defini, există o grămadă de întrebări pe care să ți le pui.

1. De ce sunt actorii tăi? O abordare ușoară ar fi dacă luați în considerare acești trei actori: server, bază de date, HSM. De asemenea, puteți lua în considerare mai mulți actori, de ex. considerând www utilizator pe care rulează serverul dvs. și rădăcină utilizator, puteți face același lucru cu baza de date etc.
2. Cum sunt acești actori conectați între ei. Desigur, în cazul tău cred că este așa

   HSM <-> Server <-> Baza de date

4. Care dintre ele poate fi accesat de atacator? Va avea atacatorul acces la server, la baza de date, la HSM sau la orice combinații specifice ale acestora?
5. Acum să luăm în considerare cel mai rău caz în care serverul tău este corupt de către atacator, ceea ce înseamnă că atât HSM, cât și baza de date pot de asemenea (teoretic) să fie corupte. Apoi, în opinia mea, cea mai bună ofertă este să criptați datele de partea clientului.De asemenea, probabil că veți dori o derivare a cheii simetrice sau nesimetrice din intrarea privată a utilizatorului dvs. (de exemplu, că depinde de parola lui), astfel încât numai el să le poată decripta. Protonmail folosește o infrastructură similară, puteți arunca o privire Aici la cartea lor albă.

Alte câteva note. Chiar dacă utilizați HSM pentru criptarea/decriptarea fișierelor dvs., în cazul serverului corupt încă nu există un canal de comunicare securizat de la HSM la Client.

Sper că te-am ajutat puțin, pentru că sunt o mulțime de scenarii pe care trebuie să le iei în considerare și pe care nu le-ai detaliat pe toate.