Sari la conținutul principal

Criptarea bazei de date

Libre WebUI include un serviciu de criptare la nivelul aplicației pentru valorile sensibile, înainte ca acestea să fie scrise în spațiul de stocare.

Metoda de criptare​

Backend-ul folosește AES-256-GCM prin modulul crypto din Node.js. Cheia de criptare trebuie să aibă 32 de octeți și să fie reprezentată ca șir hexazecimal de 64 de caractere:

ENCRYPTION_KEY=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Generați o cheie:

openssl rand -hex 32

Stocarea cheii​

Libre WebUI încarcă cheia în această ordine:

  1. ENCRYPTION_KEY din mediu.
  2. Un fișier persistent .encryption_key în directorul DATA_DIR selectat.
  3. Numai într-un spațiu de stocare nou, o cheie nou generată care este scrisă persistent în DATA_DIR/.encryption_key înainte de pornirea bazei de date.

Dacă atât mediul, cât și fișierul persistent furnizează o cheie, acestea trebuie să coincidă, altfel pornirea eșuează. O stare criptată existentă fără cheia sa originală eșuează, de asemenea, în siguranță; Libre nu generează niciodată o cheie înlocuitoare pentru un spațiu de stocare existent.

Reguli importante pentru cheie​

  • Creați o copie de rezervă a ENCRYPTION_KEY împreună cu baza de date.
  • Nu rotiți cheia fără un plan de migrare a valorilor criptate.
  • Pierderea cheii înseamnă că valorile criptate nu mai pot fi recuperate.
  • Schimbarea cheii fără recriptarea datelor face valorile criptate existente imposibil de citit.

Ce protejează​

Criptarea este aplicată de căile de cod care folosesc serviciul de criptare sau utilitarele de stocare criptată. Este destinată valorilor sensibile ale aplicației, precum credențialele și datele private ale utilizatorilor gestionate de aceste utilitare.

Nu reprezintă criptarea întregului disc, criptarea paginilor SQLite sau criptarea integrală între utilizatori și browser. Pentru aceste straturi folosiți criptarea discului și HTTPS.

Date Work​

Criptarea la nivelul aplicației nu criptează integral o sarcină Work. Fișierele sursă și dependențele proiectului Work sunt fișiere obișnuite în volume Docker denumite, limitate la sarcină. Conversațiile Work, rezultatele instrumentelor, ieșirea comenzilor și metadatele sarcinilor sunt stocate în SQLite și nu sunt criptate automat doar pentru că anumite căi de stocare a credențialelor folosesc serviciul de criptare.

Protejați rădăcina de date Docker și DATA_DIR cu controale de acces și criptarea discului atunci când este necesar. Creați împreună copii de rezervă pentru baza de date, ENCRYPTION_KEY și volumele Work gestionate. Trimiterea unei sarcini Work către un model la distanță poate dezvălui furnizorului contextul conversației și ieșirea solicitată a unui fișier sau a unei comenzi; criptarea stocării nu schimbă această limită de rețea.

Docker și Kubernetes​

Setați explicit o cheie stabilă pentru producție:

ENCRYPTION_KEY=replace-with-64-hex-characters
DATA_DIR=/data

Montați DATA_DIR într-un spațiu de stocare persistent. În Kubernetes, stocați cheia într-un Secret și montați datele într-un PersistentVolume.

Depanare​

Lungime nevalidă a cheii

Cheia trebuie să conțină exact 64 de caractere hexazecimale. Generați una nouă cu:

openssl rand -hex 32

Datele nu pot fi decriptate după o nouă implementare

Confirmați că este folosită aceeași valoare ENCRYPTION_KEY și că este montat același volum DATA_DIR.

Mediul de dezvoltare a generat o cheie nouă

Păstrați DATA_DIR/.encryption_key împreună cu baza de date. Alternativ, puteți seta aceeași valoare prin ENCRYPTION_KEY; dacă există ambele surse, acestea trebuie să coincidă.

Documentație conexă​