Urmăriți fișierele DuckDB criptate pe toată durata lor de viață
Evaluați criptarea DuckDB prin durata bazei de date, a WAL și a fișierelor temporare, păstrarea cheilor și recuperare, comparând precis criptarea discului.
De 
Paul. Arhitectură și infrastructură
Fișierul criptat al bazei de date acoperă doar o parte din datele pe care o operațiune de analiză le scrie pe disc. Modificările recente pot exista într-un jurnal de tranzacții, iar datele intermediare ale interogărilor pot ajunge în fișiere temporare. Decizia de criptare ar trebui să urmărească aceste fișiere și cheile necesare pe duratele lor de viață diferite. Altfel, aplicația poate proteja fișierul numit explicit și poate trece cu vederea datele create pe parcurs.
Articolul DuckDB datat 19 noiembrie 2025 explică criptarea bazelor de date introdusă în 1.4.0 și tratează baza principală, WAL și fișierele temporare. Trimite cititorii la 1.4.2, al cărui anunț de lansare este datat 12 noiembrie. Explicația criptării și anunțul 1.4.2 au roluri diferite: articolul explicativ ulterior nu a fost lansarea inițială a funcției.
Întrebarea tehnică utilă este ce date trebuie să poată fi recuperate, de către cine și după ce defecțiuni. Acoperirea fișierelor și administrarea cheilor aparțin aceluiași răspuns. Numele unui algoritm de criptare nu poate stabili singur că exporturile, copiile de siguranță și urmele operaționale ale aplicației respectă limitele protecției dorite.
Datele persistente cer o cale durabilă de recuperare
Baza principală conține informații pe care aplicația se așteaptă să le redeschidă. Prin urmare, cheia de criptare are nevoie de reguli de păstrare și recuperare care să reziste dincolo de procesul aflat în execuție. Păstrarea fișierului criptat fără mijlocul de a-l deschide poate conserva confidențialitatea, dar compromite disponibilitatea. Proiectarea trebuie să țină cont de ambele consecințe.
Jurnalul de tranzacții, numit WAL, face parte din această recuperare a datelor persistente. Conține modificări relevante pentru recuperare, astfel că examinarea exclusivă a unei baze închise normal poate omite un fișier important. Explicația DuckDB descrie criptarea WAL alături de criptarea bazei. Prezentarea implementării este sursa pentru această acoperire, nu un experiment făcut pentru articolul de față.
La evaluarea aplicației, identificați cine poate obține cheia bazei și când. Întrebați apoi dacă operatorul care recuperează datele poate obține cheia potrivită pentru o copie de siguranță mai veche. Fișierul bazei și cheia pot avea reguli diferite de păstrare și acces. Aceste reguli trebuie să se întâlnească în momentul recuperării; documentarea lor separată, fără această legătură, lasă o lipsă practică.
Evitați includerea cheilor reale în exemple sau în transcrieri de diagnostic doar pentru a demonstra aranjamentul. O evaluare atentă poate examina responsabilitățile și căile de obținere fără să copieze secretele într-un document de planificare. Criptarea schimbă ce dezvăluie fișierul stocat. Nu face inofensivă divulgarea datelor de acces folosite pentru a-l deschide.
Datele temporare au alt scop
O interogare amplă poate avea nevoie să scrie pe disc date intermediare. Durata lor de viață intenționată este mai scurtă decât cea a bazei, dar un proces întrerupt poate lăsa fișiere în urmă. Caracterul temporar descrie utilizarea intenționată, fără să garanteze că octeții dispar imediat după orice defecțiune.
DuckDB descrie criptarea automată a fișierelor temporare când este atașată o bază criptată și o setare explicită pentru criptarea fișierelor temporare. Descrie chei temporare generate intern, care se pierd la oprirea anormală. Secțiunea despre fișiere temporare explică distincția rezultată: datele intermediare criptate rămase pe disc nu sunt concepute să devină o copie recuperabilă a bazei.
Această diferență schimbă întrebarea despre recuperare. Pentru bază și WAL, posibilitatea recuperării face parte din scop. Pentru fișierele intermediare abandonate, păstrarea cheilor pentru recuperări viitoare ar fi altă cerință decât eliminarea lucrului temporar. Nu impuneți aceeași durată de viață a cheii ambelor categorii doar fiindcă ambele sunt criptate.
Curățarea are în continuare un rol. Fișierele temporare care nu mai pot fi citite ocupă spațiu, iar operatorii trebuie să înțeleagă ce poate rămâne după o defecțiune. Criptarea poate reduce consecințele asupra confidențialității fără să preia responsabilitatea pentru capacitatea de stocare sau repornirea aplicației. Un plan operațional complet leagă aceste probleme fără să le trateze ca pe același control.
Limitele aplicației rămân în afara funcției bazei
Luați cazul ipotetic al unui raport care citește date protejate și scrie un CSV pentru altă echipă. CSV-ul exportat este un fișier nou, creat intenționat. Criptarea bazei nu stabilește cum este păstrat exportul sau cine îl poate descărca. Același raționament se aplică rezultatelor copiate în jurnalele aplicației sau în alt sistem.
Aceasta nu înseamnă că DuckDB ar trebui să controleze fiecare fișier ulterior. Înseamnă că proprietarul aplicației trebuie să definească unde se termină responsabilitatea funcției bazei. Inventarul fișierelor ar trebui să includă și ce se produce în afara motorului bazei atunci când conține informațiile pe care organizația dorește să le protejeze. Altfel, un traseu intern sigur poate alimenta unul extern neexaminat.
Contează și precizările actuale. Pagina despre criptare, în forma accesată acum, include un avertisment că nu îndeplinește încă cerințele oficiale NIST. Data introducerii lui nu a fost stabilită aici, deci nu ar trebui prezentat ca afirmație publicată cu certitudine la 19 noiembrie 2025. Nici pagina actuală nu justifică o afirmație de certificare. Experimentele de performanță ale autorilor nu măsoară activitatea altei aplicații.
Criptarea întregului disc poate răspunde unei întrebări mai restrânse
Cel mai puternic contraargument este o organizație preocupată strict de pierderea unui dispozitiv oprit. Criptarea întregului disc, configurată corect, poate răspunde deja acelei amenințări în limitele definite. Criptarea suplimentară a bazei poate adăuga administrarea și recuperarea cheilor fără să schimbe suficient răspunsul la acel scenariu restrâns pentru a justifica efortul.
Comparația se schimbă când fișierele părăsesc volumul, copiile ajung în alt sistem de stocare sau un proces în execuție are acces la date decriptate. Protecția întregului disc nu însoțește automat fișierul exportat. Nici criptarea bazei nu protejează datele față de o aplicație care are legitim dreptul să le citească. Precizați adversarul și condițiile de acces înainte de a compara măsurile.
Alegeți cel mai restrâns aranjament de protecție care acoperă amenințarea reală și nevoile de recuperare. Unele produse vor folosi ambele niveluri; pentru altele poate ajunge controlul mai restrâns. O evaluare în cadrul mentenanței software ar trebui să lege fiecare fișier relevant de durata cheii și de persoana responsabilă. Această hartă este mai utilă decât afirmația necondiționată că baza de date este criptată.