Jinak ještě k nějakým dalším možnostem k prozkoumání, resp. asi kdybych něco takového řešil, zvážil bych to
ZFS a jeho nativní šifrování datasetů.
Tohle mi z hlediska správy přijde ideální, je to integrované v rámci jednoho celku s RAID-Z a správou svazků a velmi flexibilní, protože to umožní kombinovat šifrovaná i nešifrovaná data v jednom poolu podle datasetu. Při zálohách přes zfs-send na jiný ZFS systém se dá zvolit jesti se bloky přenáší 1:1 v šifrované podobě, nebo se dešifrují (obojí může mít své opodstatnění).
Zkoušel jsem si to na čtyřdiskových NASech s FreeBSD, fungovalo mi to základně velice hezky.
Kde je mínus? - dá se dohledat relativně dost issues a sem tam i nějaká horror story. Asi bych s tím musel strávit ještě docela dost času a testování, než bych se rozhodl.
Na stranu druhou, mimo těch problému, kterých se dá najít pro oba pokročilé fs (i s BTRFS) tuny a záleží na verzi, systému, hardware, přesnému použití atp., tam jsou zas reporty od lidí, co už to někde mají roky bez potíží.
Btw. tohle používá QNAP coby "shared folder encryption" v QuTS Hero.
SED (self-encryption-drive).
Tohle se tak trochu nabízí a zas to může mít své výhody i nevýhody.
Výhody jsou, že se to po odemčení v systému tváří jako standardní disk a hlavně tam není žádný praktický výkonový dopad toho šifrování.
Věci ke zvážení.
- zatímco LUKS, ZFS atp. se po softwarovém rebootu, kexec reloadu samy neodemknou, tak SED většinou zůstanou odemčené, dokud se nevypne napájení. I když to také může záviset na řadiči (pokud se používá). Může, nemusí hrát roli.
- jsou typicky trochu dražší než disky bez šifrování, i když pokud uvažujete o DC Ultrastarech nemusí to být takový nárůst
- můžou nastat komplikace s nástroji okolo na odemykání, i jejich kompatibilitou.
SATA modely většinou implementují standard TGC Opal, SAS disky TGC Emerald (Enterprise), které definují i příkazy na správu šifrování, bezpečného mazání atp.
Odemčení může být buď z OS, případně SAS/SATA kontroleru z firmware, jestliže ten umí správu SED disků.
- můžou nastat komplikace při přesunu z jednoho vendora řadiče a úložiště na druhého
U těch Opal disků znám v podstatě jen jeden program, co běží na Linuxu, BSD, UEFI PBE - sedutil-cli. Existuje i pár jeho forků, co řeší různé změny. Používal jsem to na SSD, ale na HDD je stejný princip. Určitě bych si dopředu ověřil, jestli to funguje s konkrétním diskem a jestli bych to byl nějak schopen zapracovat do inicializace a odemykání toho úložiště.
Enterprise disky pak mají ekvivalentní SCSI příkazy a zároveň víc možností (víc hesel a uživatelů atp.). Tam osobně neznám žádnou obecnu utilitu pro Linux, co by to rovnou umožňovala spravovat SED. Tedy pokud neberu to, že by zkoušel posílat hexa příkazy z toho standardu pomocí sg_utils.
Na druhou stranu tu jejich správu zas umí některé řadiče (RAID i HBA). Často to funguje tak, že se ve skupině disků vygenerují a použijí samostatné klíče, které se pod společným heslem šifrovaně uloží v NVRAM řadiče.
Tohle heslo se pak může zadávat buď při startu serveru (např. UEFI op-rom aplikací), nebo je to propojeno s BMC serveru. To většinou vyžaduje režim externí správa klíčů a komunikuje to např. s iDracem nebo iLO, které pak můžou zas mít na síti i nějaký nadřazeý systém na ověřování a klíče. Další možnost bude pak v managment nástrojích od řadiče ze systému.
V případě Arecy mají jejich SAS/SATA řadiče dokonce svůj ethernet port a embeedovaný webserver a management přístupny mimo OS.
Já sám jsem se s SED setkal buď v nějakých enterprise úložištích (úplně mimo cenově), nebo v serverech od Dellu, HP (byť jsem je osobně nespravoval). Tde byly jejich brandované řadiče a integrace do BMC, jak jsem zmiňoval. Zároveň disky byly také součástí, takže odpadl problém s případnou kompatibilitou.
Kdybych to měl řešit jako DIY skládačku, určitě bych to minimálně konzultoval s prodejci tady (jako Anafra), nebo se pokusil zařídit nějaký test.
14 Odpovědí
4335 Zhlédnutí