Ghid de pornire rapidă OpenZFS Native Encryption

Fotografie de aproape a unui lacăt.
Mărește / Criptarea pe disc este un subiect complex, dar acest articol ar trebui să vă ofere o idee bună despre implementarea OpenZFS.

Una dintre numeroasele caracteristici pe care OpenZFS le aduce la masă este criptarea nativă ZFS. Introdus pentru prima dată în OpenZFS 0.8, criptarea nativă permite unui administrator de sistem să cripteze în mod transparent datele în repaus chiar în ZFS. Acest lucru evită nevoia de instrumente separate, cum ar fi LUXOS, VeraCrypt, sau Bitlocker.

Algoritmul de criptare OpenZFS implicit este unul aes-256-ccm (înainte de 0.8.4) sau aes-256-gcm (> = 0.8.4) când encryption=on este setat. Dar poate fi specificat și direct. Algoritmii suportați în prezent sunt:

  • aes-128-ccm
  • aes-192-ccm
  • aes-256-ccm (implicit în OpenZFS <0.8.4)
  • aes-128-gcm
  • aes-192-gcm
  • aes-256-gcm (implicit în OpenZFS> = 0.8.4)

Cu toate acestea, criptarea OpenZFS nativă nu se limitează la algoritmii utilizați. Prin urmare, vom încerca să vă oferim o bază scurtă, dar solidă din punctul de vedere al administratorului de sistem cu privire la „de ce” și „ce”, precum și la „cum” simplu.

De ce (sau de ce nu) criptarea nativă OpenZFS?

Un administrator inteligent de sistem care dorește să furnizeze criptare în repaus, evident, nu are nevoie de criptare OpenZFS nativă. După cum sa menționat în introducere, LUKS, VeraCrypt, și multe alte scheme sunt disponibile care pot fi stratificate sub sau deasupra OpenZFS în sine.

Mai întâi „de ce nu”

Pune ceva de genul Linux LUKS în cadrul OpenZFS are un avantaj – cu toate disc criptat, un atacator întreprinzător nu mai poate vedea numele, dimensiunile sau proprietățile ZFS datasets și zvols fără acces la cheie. De fapt, atacatorul nu poate vedea neapărat că ZFS este în uz!

Dar există dezavantaje semnificative de pus LUKS (sau similar) în cadrul OpenZFS. Una dintre cele mai enervante este că fiecare individual discul care va face parte din pool trebuie să fie criptat, fiecare volum fiind încărcat și decriptat înainte de pool-ul ZFS import Etapa. Aceasta poate fi o provocare vizibilă pentru sistemele ZFS cu multe discuri – în unele cazuri multe zeci discuri. O altă problemă cu criptarea sub ZFS este că stratul suplimentar este încă un lucru care trebuie să meargă greșit – și este capabil să anuleze toate garanțiile normale de integritate ZFS.

READ  Jucătorul Pokemon Go își „flexează” captura Shadow Raid Mewtwo

Punând LUKS sau similar în OpenZFS scapă de problemele menționate mai sus – a LUKS criptă zvol are nevoie de o singură cheie, indiferent de numărul de discuri implicate și de LUKS layerul nu poate anula de aici garanțiile de integritate OpenZFS. Din păcate, criptarea de pe ZFS introduce o nouă problemă: nu utilizează în mod eficient compresia OpenZFS inline, deoarece datele criptate sunt în general incompresibile. Această abordare, de asemenea necesită utilizarea unui zvol pe un sistem de fișiere criptat, precum și un sistem de fișiere invitat (de exemplu, ext4) pentru a formata LUKS volumul în sine cu.

Acum „de ce”

Criptarea nativă OpenZFS împarte diferența: funcționează deasupra straturilor normale de stocare ZFS și, prin urmare, nu subminează garanțiile de integritate ale ZFS. Dar nici nu interferează cu compresia ZFS: datele sunt comprimate înainte de a fi salvate într-un fișier criptat. dataset sau zvol.

Există, totuși, un motiv și mai convingător pentru alegerea criptării OpenZFS native, care se numește „încărcare brută”. Replicarea ZFS este ridicol de rapidă și eficientă, de multe ori mai multe ordine de mărime mai rapide decât instrumentele independente de sistemul de fișiere, cum ar fi rsync– și trimiterea brută nu numai că permite reproducerea criptată datasetnisip zvols, dar pentru a face acest lucru fără a expune cheia sistemului la distanță.

Aceasta înseamnă că puteți utiliza replicarea ZFS pentru a face copii de rezervă ale datelor pe un fara incredere locație, fără a vă face griji cu privire la citirea datelor dvs. private. Cu trimiterea brută, datele dvs. sunt reproduse fără a fi decriptate vreodată și fără ca ținta de rezervă să o poată decripta vreodată. Aceasta înseamnă că vă puteți reproduce copiile de rezervă în afara locației la casa unui prieten sau într-un departament de vânzări, cum ar fi rsync.net sau zfs.rent fără a vă compromite confidențialitatea, chiar dacă serviciul (sau prietenul) în sine este compromis.

READ  Co-fondatorul Apple, Steve Wozniak: „Este timpul să recunoaștem dreptul de a repara”

În cazul în care trebuie să vă recuperați copia de rezervă în afara site-ului, o puteți replica pur și simplu. înapoi atunci la propria locație și numai apoi încărcați cheia de decriptare pentru a accesa efectiv datele. Acest lucru funcționează fie pentru replicarea completă (mutarea fiecărui bloc pe fir), fie pentru replicarea incrementală asincronă (pornind de la un instantaneu comun și mutând numai blocurile care s-au schimbat de la acel instantaneu).

Ce este criptat și ce nu?

Criptarea nativă OpenZFS nu este o schemă completă de criptare a discului: este activată sau dezactivată pentru fiecare set de date / de zvol și nu poate fi activată pentru grupuri întregi ca întreg. Conținutul seturilor de date criptate sau zvols este protejat împotriva spionajului în repaus, dar metadatele care descriu seturile de date / zvols în sine nu sunt.

Să presupunem că creăm un set de date criptat numit pool/encryptedși, mai jos, creăm alte câteva seturi de date pentru copii. encryption Proprietatea copiilor este moștenită în mod implicit din setul de date părinte, deci putem vedea următoarele:

root@banshee:~# zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase banshee/encrypted
Enter passphrase: 
Re-enter passphrase: 

root@banshee:~# zfs create banshee/encrypted/child1
root@banshee:~# zfs create banshee/encrypted/child2
root@banshee:~# zfs create banshee/encrypted/child3

root@banshee:~# zfs list -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         1.58M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   320K   848G      320K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

root@banshee:~# zfs get encryption banshee/encrypted/child1
NAME                      PROPERTY    VALUE        SOURCE
banshee/encrypted/child1  encryption  aes-256-gcm  -

Deocamdată, seturile noastre de date criptate sunt toate asamblate. Dar chiar dacă le separăm și descărcăm cheia de criptare, făcându-le inaccesibile, putem vedea totuși că A exista, precum și proprietățile acestora:

root@banshee:~# wget -qO /banshee/encrypted/child2/HuckFinn.txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn

root@banshee:~# zfs unmount banshee/encrypted
root@banshee:~# zfs unload-key -r banshee/encrypted
1 / 1 key(s) successfully unloaded

root@banshee:~# zfs mount banshee/encrypted
cannot mount 'banshee/encrypted': encryption key not loaded

root@banshee:~# ls /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

root@banshee:~# zfs list -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         2.19M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   944K   848G      720K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

După cum putem vedea mai sus, după descărcarea cheii de criptare, nu mai putem vedea copia noastră proaspăt descărcată a Finn Huckleberry în /banshee/encrypted/child2/. Ceea ce noi poate sa încă vedem existența – și structura – întregului nostru arbore criptat ZFS. Putem vedea, de asemenea, proprietățile fiecărui set de date criptat, inclusiv, dar nu limitat la USED, AVAIL, și REFER din fiecare set de date.

READ  Canalele Nintendo Wii și DSi Shop au fost indisponibile de câteva zile

Trebuie remarcat faptul că încercarea de a ls un set de date criptat a cărui cheie nu este încărcată nu va produce neapărat o eroare:

root@banshee:~# zfs get keystatus banshee/encrypted
NAME               PROPERTY   VALUE        SOURCE
banshee/encrypted  keystatus  unavailable  -
root@banshee:~# ls /banshee/encrypted
root@banshee:~# 

Acest lucru se datorează faptului că există un director gol pe gazdă, chiar și atunci când setul de date real nu este montat. Reîncărcarea cheii nu încarcă automat setul de date:

root@banshee:~# zfs load-key -r banshee/encrypted
Enter passphrase for 'banshee/encrypted': 
1 / 1 key(s) successfully loaded
root@banshee:~# zfs mount | grep encr
root@banshee:~# ls /banshee/encrypted
root@banshee:~# ls /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

Pentru a accesa noua noastră copie a Finn Huckleberry, va trebui, de asemenea, să montăm seturile de date proaspăt reîncărcate:

root@banshee:~# zfs get keystatus banshee/encrypted/child2
NAME                      PROPERTY   VALUE        SOURCE
banshee/encrypted/child2  keystatus  available    -

root@banshee:~# ls -l /banshee/encrypted/child2
ls: cannot access '/banshee/encrypted/child2': No such file or directory

root@banshee:~# zfs mount -a
root@banshee:~# ls -lh /banshee/encrypted/child2
total 401K
-rw-r--r-- 1 root root 554K Jun 13  2002 HuckFinn.txt

Acum că am încărcat amândoi cheia necesară și montat seturile de date, putem revizui datele noastre criptate.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *