Minule jsem reportovala o zašifrování raid pole, na kterém jsou datová úložiště všech běžících služeb serveru, jako databáze, maily, weby, git repozitáře atd. Bylo potřeba zajistit, aby po restartu serveru došlo nejdříve k odemknutí raid pole, k namountování všech složek s daty a pak teprve ke startu příslušných služeb.

Server nemá grafickou kartu, proto by nebylo vhodné nakonfigurovat to na prompt hesla.

Luks umožňuje každému zašifrovanému kontejneru přiřadit několik hesel nebo key files. Soubor s klíčem je pak možné uložit na flash disk a nechat jej při bootu načíst. Server tak může automatizovaně zašifrovaný disk při startu automaticky odemknout. Klíč není na serveru nikde uložený, takže usb disk s heslem představuje jakýsi šém, bez kterého nelze server rozběhnout.

Nejdřív jsem se rozhodovala, jaký flash disk použít – samozřejmě se dá použít jakýkoliv, nicméně musel by být bezpečně schovaný a dostupný pouze k tomuto účelu. Protože se mi ale hromadí různé privátní ssh klíče které taky potřebuju někam bezpečně ukládat, rozhodla jsem se nakonec pro řešení pomocí hardwarově šifrovaného USB flash disku. První zkušenosti s těmito disky jsem udělala při koupi levnějšího modelu Verbatim, na který odkládám některé zálohy serveru.

U disku Verbatim se jedná o poměrně velký flashdisk, který sice funguje tak jak má, ale má jednu nevýhodu: číselné heslo lze vložit až po zasunutí disku do USB portu zapnutého počítače. To mimochodem znamená, že jej nelze prakticky používat bez prodlužovacího USB kablíku, protože mačkat maličká, ale tuhá tlačítka zasunutého disku si koleduje o poškození USB konektoru. Disk se po výpadku napájení z USB portu uzamkne. Na zálohování je to dobré řešení, nicméně pro účely automatizovaného startu serveru to vhodné není, protože by bylo flash disk potřeba odemykat během startu serveru (až po náběhu jeho napájení) – tohle cvičení podstupovat nechci.

Jiný model flashdisku s HW šifrováním – Kingston DataTraveler 2000 je v tomto ohledu bez chyby – ovšem je taky o dost dražší: Obsahuje akumulátor, který umožňuje, že lze disk odemknout i mimo PC a pak jej teprve, už odemčený, zasunout do USB portu.

Disk je menší, vlastně rozměrově srovnatelný s jinými flash disky. Má vícero dalších funkcí: umí více uživatelských hesel, admin heslo, po odemčení jej zamknout pro zápis, timeout, po kterém se automaticky uzamkne; nicméně stačí mi úplně jeho základní funkce. Na tento disk, byť jsem si pořídila kapacitně daleko skromnější verzi, můžu nyní směle ukládat privátní klíče, debilníky s hesly, a nechat jej válet na stole bez obav. Dobrá věcička.

Na flash disk jsem pomocí /dev/random vygenerovala klíč do souboru keyFile, který budu používat pro odemykání datového disku. Takto připravený keyFile jsem přidala do zašifrovaného datového kontejneru:

cryptsetup luksAddKey /dev/md0 /mnt/fkey/keyFile

Pro účely automatizovaného startu serveru je vhodné flashdisk s klíčem identifikovat buďto podle UUID nebo podle jmenovky. Zatímco UUID se generuje náhodně při formátování disku, label lze přepsat a disk je jednodušeji zaměnitelný. Řekněme, že jsem flashdisk s klíčem pojmenovala FKEY.

Nechám jej tedy namountovat při startu prvním záznamem v fstabu:

LABEL=FKEY   /mnt/fkey    vfat    noauto,x-systemd.idle-timeout=600,x-systemd.device-timeout=600

Timeout jsem nastavila 10 minut – tak dlouho bude server při startu čekat na zasunutí flash disku, pokud na to zapomenu před samotným startem. To je tak dlouho, že server bez flashdisku prakticky nenastartuje, resp. bude hned zjevné, že je něco špatně. Následuje mount zašifrovaného pole:

/dev/mapper/encryptedData    /mnt/data    ext4    noatime

a pak další mounty už do konkrétních datových složek jednotlivých služeb, tentokrát už s parametrem bind např:

/mnt/data/www    /var/www    none    bind

Následně jsem vytvořila záznam v crypttab, kterým se zašifrovaný disk při mountu odemkne:

encryptedData    /dev/md0 /mnt/fkey/keyFile    luks,noauto

Prvním parametrem je název zařízení, které cryptsetup po odemčení disku zřídí v /dev/mapper. Třetím parametrem je cesta ke klíči na USB disku. Argument ve čtvrtém parametru noauto je velmi důležitý – způsobí, že se tento záznam nepustí při bootu automaticky, ale až tehdy, pokud jiný proces – totiž mount v fstab – nezavolá zařízení /dev/mapper/encryptedData. A fstab se spouští až po sestavení RAID pole, na kterém je zašifrovaný kontejner uložený.

Celý postup jsem si nejdříve vyzkoušela na virtuálním serveru. Fungovalo to krásně, ale po odebrání USB disku z úspěšně spuštěného virtuálního stroje se provedl umount datového disku a k zamknutí zašifrovaného pole. Před fyzickým odebráním flash disku je tedy nejdřív nutné jej odpojit příkazem umount. Aby to bylo automatické, vytvořila jsem  jednoduchý script, který provede umount flash disku pár vteřin po zdařilém startu serveru – to zajistí záznam v crontabu:

 @reboot sleep 10 && umount.sh

Odpojený flash disk lze z USB portu vyjmout, zašifrované pole zůstane odemčené a server může sloužit.

Výše uvedený postup jsem použila poté, co jsem vyzkoušela metodu, která používá passdev script volaný záznamem crypttabu a vyžaduje aktualizaci initramfs. Je to postup potřebný pro odemčení systémového oddílu. V mé aplikaci pro odložené odemčení datového disku (noauto) se mi to rozchodit nepodařilo, a našla jsem si tuto jednodušší a lehce pochopitelnou cestu.

Jedna věc je vyzkoušet si postup na virtuálním stroji, úplně jiná na provozním serveru bez monitoru. Restart serveru jsem spojila s instalací SATA řadiče a s připojením dalšího disku. Takže zatajit dech, server shutdown, úprava HW, zasunutí šému s dešifrovacím klíčem a start…

Výše uvedený postup proběhl naštěstí bez chyby a server po několika vteřinách po startu obnovil všechny své služby. Tedy jedna chyba se přece jen vyskytla – nedošlo k automatickému umountu flash disku. Chybu jsem posléze našla – script umount.sh jsem uložila chybně s oprávněním 600, nikoliv 700 (chybělo právo execute).

 

 

 

 

Další díly seriálu

<< Server 9: upgrade a zašifrování RAID poleServer 11: přechod na RAID6 >>