LVM
LVM (Logical Volume Manager) je systém pro správu logických oddílů, v Linuxu je implementován pomocí device mapperu, mechanismu pro mapování jednoho blokového zařízení na jiné. Ptáte se, proč používat LVM místo klasických diskových oddílů? LVM umí řadu věcí, které s "klasickými" diskovými oddíly neuděláte. Kupříkladu - vyhradíte si diskový oddíl určité velikosti a posléze (za provozu) zjistíte, že velikost je nevyhovující - oddíl je buď zbytečně velký, a ubírá tak místo ostatním oddílům, nebo je příliš malý, a začne na něm brzy docházet místo.
Logické "oddíly" (dále svazky) spravované pomocí LVM můžete vytvářet, rušit, měnit jejich velikost, pořizovat z nich snapshoty, ale také je přesouvat mezi fyzickými zařízeními, a to vše za běhu, bez nutnosti restartu.
Další vlastností LVM je relativní nezávislost logických svazků na fyzických zařízeních. Můžete "poskládat" LVM z několika oddílů na různých discích, a tuto "skupinu" pak rozdělit, jako by se jednalo o jeden velký spojitý prostor. Podobnost s RAIDem 0 je zde evidentní, stejně jako vyplývající hrozba ztráty dat v případě ztráty některého fyzického zařízení. LVM nicméně umí i ekvivalent RAIDu 1, tedy zrcadlení dat na více fyzických zařízení. Neumí už ovšem paritně založenou redundanci (ekvivalent RAIDu 5 a 6).
Princip funkce LVM
Představte si LVM jako vrstvu, kam na jedné straně nasypete "fyzická zařízení" (de facto jakékoliv myslitelné blokové zařízení), a na druhé straně si na vzniklém spojitém prostoru vytvoříte logické svazky, tedy z pohledu linuxového správce konkrétní bloková zařízení, na kterých pak můžete dle libosti vytvářet souborové systémy a se kterými můžete poměrně flexibilně manipulovat, a to i za běhu. LVM můžete samozřejmě postavit nad jakýmikoliv blokovými zařízeními, tedy třeba nad linuxovým softwarovým RAIDem nebo nad šifrovaným zařízením (třeba pomocí dm-crypt/LUKS, viz níže).
Schéma ilustrující princip funkce LVM
A teď ještě jednou a za pomoci terminologie LVM (vizte obrázek nad tímto odstavcem). Úplně vespod máme physical volumes (fyzické svazky). To mohou být diskové oddíly, celé pevné disky nebo úplně jiná bloková zařízení. Všechna tato zařízení se umístí do volume group (skupiny svazků), která se pak tváří jako jeden velký spojitý prostor, který můžete alokovat do konkrétních logical volumes (logických svazků).
Důvodem, proč preferuji anglickou terminologii, je fakt, že příkazy pro správu LVM jsou z anglických názvů odvozeny. Kupříkladu, vytvoření fyzického svazku (physical volume) se provádí příkazem pvcreate. Ale samotnou správu LVM si probereme podrobněji až v některém z dalších dílů.
Smysl LVM na serveru
Přínosem LVM je především flexibilita práce s logickými svazky ve vztahu k fyzickým zařízením. Pokud na nějakém svazku začne docházet místo, není problém ho zvětšit, a to i za běhu. Snapshoty jsou neocenitelnou pomůckou v mnoha situacích (počínaje snadnějším zálohováním). Naopak LVM představuje vrstvu funkcionality navíc, kde se může vyskytnout problém (i když je třeba dodat, že LVM v Linuxu je již dostatečně zralá technologie pro produkční nasazení) nebo která může zkomplikovat záchranu dat v případě havárie (opět je třeba zdůraznit nutnost zálohování).
Diskové šifrování
Diskové šifrování na serverech je minimálně využívanou funkcionalitou, ale ať už se rozhodnete diskové šifrování nasadit či nenasadit, měli byste vědět, o co se jedná, co vám diskové šifrování nabídne, před čím vás ochrání, a před čím vás naopak neochrání.
Diskové šifrování je metoda, při níž se obsah pevného disku (resp. konkrétních šifrovaných oddílů) udržuje zašifrovaný, ale operační systém je schopen prostřednictvím online šifrování a dešifrování zpřístupnit šifrovaný svazek tak, jako by se jednalo o svazek nešifrovaný. Předpokladem je samozřejmě zadání správného hesla.
To znamená, že v optimálním případě nebude útočník schopen získat bez znalosti klíče citlivá data na šifrovaných oddílech, pokud si třeba odnese pevný disk nebo ho vytrhne z běžícího serveru.
Úskalí diskového šifrování je nicméně mnoho, a na serveru to platí dvojnásob. Za prvé, velmi záleží na použitých kryptografických metodách a jejich implementaci. Diskové šifrování je problematické z toho důvodu, že se šifrují data o velkém objemu, a ještě navíc data, která mají určité vzorce, a o kterých lze mnohé usoudit, i když data nejsme schopni dešifrovat (toto zahrnuje datové struktury souborových systémů, prázdné místo, apod.). Je tedy třeba použít vhodné řešení (v našem případě dm-crypt/LUKS), vhodné kryptografické metody (viz dále) a samozřejmě dostatečně silné heslo.
Ilustrační obrázek
Za druhé, diskové šifrování v současné době není schopné nahradit fyzické zabezpečení serveru - to znamená, že před útočníkem schopným dostat se fyzicky k našemu serveru, data příliš chráněna nejsou. Existuje řada útoků, proti kterým se u serveru nelze rozumně bránit. Tyto útoky zahrnují nejobávanější cold boot attack (předpokládá fyzický přístup k serveru, když server běží), ale i útoky na části systému, které z principu šifrovat nelze (zavaděč, obrazy jader, iniciální ramdisk, apod.) - tyto útoky je možné realizovat i v situaci, kdy je server vypnutý.
Za třetí, diskové šifrování znamená poměrně citelný dopad na rychlost čtení a zápisu dat, ale také na zatížení serveru - šifrování a dešifrování totiž zajišťuje procesor, a šifrování / dešifrování jako takové je výpočetně náročné. V Linuxu je navíc ještě problém v tom, že diskové šifrování obstarává u každého oddílu jen jedno vlákno, což nám vytváří úzké hrdlo u vícejaderných a víceprocesorových konfigurací, kde není dost dobře možné jejich výhodu paralelních výpočtů využít.
Za čtvrté, stejně jako u LVM se jedná o vrstvu funkcionality navíc, kde může dojít k chybě, a kde může přehození jediného bitu způsobit nečitelnost celého jednoho bloku. Dvouúrovňové šifrování v rámci LUKS navíc vytváří single point of failure, kde, pokud dojde k narušení integrity hlavičky šifrovaného svazku, přijdeme zcela jistě o všechna data (hlavička totiž obsahuje klíč k dešifrování celého oddílu).
Za páté, pro dešifrování oddílů je nutné zadat heslo, což u serveru, který by měl po restartu co nejdříve naběhnout, komplikuje situaci. Ještě více situaci komplikuje absence fyzické přítomnosti správce, pokud je server umístěn v datacentru a spravován na dálku. Toto se však dá řešit zadáním hesla přes SSH. Není mi známo, že by Debian tuto možnost měl vestavěnou, ale je možné sestavit vlastní řešení třeba na základě návodu na debian-administration.org.
Jaký má tedy diskové šifrování smysl? U serveru přichází v úvahu následující alternativy:
- ochrana proti úniku dat z defektních nebo jinak vyřazených pevných disků
- ochrana proti úniku dat následkem zcizení serveru - ovšem pouze pokud by ke zcizení došlo ve chvíli, kdy je server vypnutý, tzn. třeba při jeho převozu z jednoho datacentra do druhého
- minimální ochrana před neznalým útočníkem s fyzickým přístupem k disku
Uživatelé RAIDu mi nyní pravděpodobně řeknou, že k zabezpečení dat před prvním zmíněnou situací postačí fakt, že data se nachází třeba v RAIDu 5 nebo 6. Ano, v takové situaci sice nelze rekonstruovat původní data, nicméně vzhledem k tomu, že data se v rámci RAIDu 5 a 6 rozdělují na bloky určité velikosti, je přeci jen možné získat nějaká data i z disku v diskovém poli - tím, že se pokusíme vytáhnout informace z datových bloků. Pokud nakládáme s citlivými daty, může být i takto omezený "únik" nepřijatelný.
Diskové šifrování není vzhledem ke svým nevýhodám vhodné pro nasazení na běžný server, ale určitě se velmi hodí správcům pro ochranu citlivých dat jako SSH klíčů, hesel nebo jiných materiálů na přenosných zařízení nebo desktopech.
dm-crypt
Dm-crypt je vrstva využívající device mapper (viz výše), která umožňuje využít CryptoAPI (konkrétní implementace šifrovacích algoritmů, módů, hashí, apod.) v linuxovém jádře k online šifrování blokových zařízení.
LUKS
LUKS je postavený na dm-cryptu a jedná se o rozšíření, které poskytuje dvouúrovňové šifrování spolu s vhodnou funkcí pro derivaci klíče (PBKDF2). Dvouúrovňové šifrování znamená, že oddíl je šifrován hlavním klíčem (master key), a tento klíč je pak zašifrován některým z uživatelských klíčů. Uživatel zadá svůj klíč, kterým je dešifrován hlavní klíč, a ten dešifruje příslušný šifrovaný oddíl. Výhodou je možnost použít více klíčů nebo kompromitovaný klíč velmi snadno změnit, bez nutnosti celý oddíl přešifrovat. Funkce pro derivaci klíče PBKDF2 o něco málo zvyšuje bezpečnost slabších klíčů a znesnadňuje slovníkový útok.
Praktická realizace diskového šifrování
Jak už bylo zmíněno, nelze šifrovat úplně všechno, oddíl zahrnující /boot musí zůstat nešifrovaný. Všechno ostatní (včetně kořenového oddílu) může být šifrované (a má-li šifrování mít alespoň nějaký smysl, je třeba šifrovat nebo jinak zabezpečit swap i veškerá umístění, kam by se mohla dostat citlivá data - např. /tmp). Šifrování lze postavit nad RAIDem a výsledný šifrovaný svazek použít pro LVM, třeba jak je to naznačeno na tomto obrázku.
Schéma ilustrující možnou konfiguraci RAIDu, dm-crypt/LUKS a LVM
Na tomto obrázku bych rád ilustroval, jak složité struktury pro uložení a zabezpečení dat je možné vytvářet. Spolu s tím bych rád upozornil na to, že na pořadí v tomto případě velice záleží - proto je třeba navrhnout způsob práce s úložištěm s rozmyslem, což je také důvodem, proč se těmto tématům věnuji před samotnou instalací.
Co se týče nastavení, volby šifry a šifrovacího módu, jen ve stručnosti. Šifru si vyberte dle libosti, ale pokud možno takovou, která není zastaralá (jako například Blowfish) - ideální je vybírat některého z finalistů AES. U diskového šifrování dnes nepřipadá v úvahu jiný mód než XTS. Módy cbc-essiv i LRW obsahují zranitelnosti. Více o teorii šifrovacích módů pro diskové šifrování si můžete přečíst v článku Disk encryption theory.
To je pro tentokrát vše. Příště se konečně vrhneme na instalaci Debianu na server. Práci s LVM a dm-crypt/LUKS a jejich správu probereme v některém z dílů po instalaci.
Příští díl můžete očekávat ve středu 23. prosince.
