Sifrovani disku a souboru

Šifrování disků a souborů

TLS, SSH i VPN chrání data na cestě. Tahle stránka je o datech v klidu — na disku serveru, v záloze, na flashce, kterou vozíš k rodičům.

Je to disciplína, kde se dělá jedna zásadní chyba: šifruje se, aniž by bylo jasné, proti čemu. Proto začneme tím.

Navazuje na stavební kameny a doplňuje zabezpečení serveru.

Proti čemu to vlastně chrání

Šifrování disku má velmi úzký a velmi konkrétní účel:

Situace	Pomůže?
Ukradený notebook nebo NAS	ano
Vyhozený nebo prodaný disk	ano
Disk poslaný do reklamace	ano
Záloha ležící u kamaráda nebo v cizím cloudu	ano
Zabavený vypnutý stroj	ano
Útočník, který se dostal na běžící systém	ne
Ransomware	ne — a naopak, on šifruje tobě
Zranitelná webová aplikace	ne
Uniklé heslo do služby	ne
Zabavený běžící stroj	ne

Vidíš ten vzorec? Šifrování disku chrání data, dokud je systém vypnutý. Jakmile běží, klíč je v paměti a souborový systém je odemčený — root i útočník vidí všechno naprosto normálně.

To není jeho nedostatek, to je jeho definice. Jen je potřeba mít správná očekávání a neusnout na vavřínech: na běžícím serveru dělá práci firewall, aktualizace a přístupová práva, ne LUKS.

Kde má naopak šifrování naprosto zásadní přínos, je záloha mimo dům. Pravidlo 3-2-1 tě vede k tomu, že jedna kopie leží někde, kde na ni nevidíš. Ta kopie musí být šifrovaná — jinak jsi právě rozdal svoje data.

LUKS: šifrovaný disk na Linuxu

Standardní řešení, součást jádra, žádná instalace navíc.

Vytvoření

cryptsetup luksFormat --type luks2 /dev/sdb1
cryptsetup open /dev/sdb1 data
mkfs.ext4 /dev/mapper/data
mount /dev/mapper/data /mnt/data

# a zpátky
umount /mnt/data
cryptsetup close data

Výchozí nastavení je dobré a nemá se měnit: AES-256 v režimu XTS a odvození klíče z hesla přes Argon2id, který je odolný proti hádání na grafických kartách.

cryptsetup luksDump /dev/sdb1

Hlavička je jediné, co tam opravdu záleží

Tohle je nejdůležitější odstavec o LUKS.

Disk se nešifruje přímo tvým heslem. Existuje hlavní klíč, který vznikne náhodně při vytvoření svazku a nikdy se nemění. Ten je uložený v hlavičce disku, zašifrovaný tvým heslem — a hesel může být osm (LUKS2 jich zvládne víc).

Z toho plynou tři věci:

Změna hesla je okamžitá. Nepřešifrovává se disk, jen se přebalí hlavní klíč.

Můžeš mít víc hesel. Tvoje, záložní v trezoru, klíčový soubor pro automatické odemčení.

Poškozená hlavička = konec. Pár kilobajtů na začátku disku drží jediný klíč k celému obsahu. Přepsaná hlavička znamená, že data jsou nenávratně pryč, i kdyby zbytek disku byl v naprostém pořádku.

Zálohuj hlavičku. Hned po vytvoření.

cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /bezpecne/luks-sdb1.img

Ten soubor ulož mimo daný disk. Zároveň ale pozor: obsahuje hlavní klíč zabalený starými hesly — když někdy heslo změníš kvůli podezření na únik, stará záloha hlavičky ho pořád přijímá. Chraň ji jako samotná data.

cryptsetup luksAddKey /dev/sdb1              # přidat heslo
cryptsetup luksKillSlot /dev/sdb1 1          # odebrat slot

Odemčení bez klávesnice

Server v komoře nemá kdo při každém restartu odemknout. Možnosti, od nejjednodušší:

Klíčový soubor na jiném médiu — v /etc/crypttab s klíčem na USB. Levné a průhledné, ale kdo ukradne server i s flashkou, má obojí.

TPM čip. Klíč vydá čip jen tehdy, když se stav systému shoduje s tím při zápisu:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdb1
systemd-cryptenroll --recovery-key /dev/sdb1     # nouzový klíč, vytiskni si ho

Disk vytažený z tohoto stroje nikdo neotevře. Zároveň si uvědom, co to znamená: stroj se odemkne sám, takže krádež celého stroje tě nechrání, pokud útočník umí spustit systém. Kombinace TPM + PIN to řeší.

Odemčení přes SSH při startu. Nejelegantnější řešení pro domácí server:

apt install dropbear-initramfs
# klíč do /etc/dropbear/initramfs/authorized_keys
update-initramfs -u

Po restartu naběhne minimální SSH v initramfs, ty se připojíš, zadáš heslo a systém pokračuje. Chová se to přesně tak, jak chceš: bez tebe stroj nenaběhne, ale nemusíš k němu chodit.

Počítej s tím, že to má vlastní host key, takže si do konfigurace klienta dej výjimku:

Host server-boot
    HostName 192.168.1.10
    User root
    UserKnownHostsFile ~/.ssh/known_hosts.boot

Výkon

S hardwarovým AES (každý procesor od roku 2010) je režie jednotky procent a na NVMe disku ji nepoznáš. Ověř si, že se akcelerace používá:

cryptsetup benchmark
grep -o aes /proc/cpuinfo | head -1

Když se aes v cpuinfo neobjeví (staré Atomy, některé ARM desky), zvaž místo AES-XTS variantu --cipher xchacha12,aes-adiantum-plain64 — Adiantum je navržený přesně pro procesory bez akcelerace a je v takovém případě podstatně rychlejší.

Šifrování konkrétního adresáře

Když nechceš celý disk:

gocryptfs — šifrovaný adresář nad běžným souborovým systémem, dobře se synchronizuje do cloudu:

gocryptfs -init ~/.sifrovane
gocryptfs ~/.sifrovane ~/tajne

ZFS s nativním šifrováním — když už ZFS používáš, je to nejčistší cesta:

zfs create -o encryption=on -o keyformat=passphrase tank/tajne

Šifruje se na úrovni datasetu, zfs send umí posílat data zašifrovaná na cílový stroj, který heslo nezná. Pro zálohu k někomu jinému je to ideální.

Pozor na jednu vlastnost: metadata jako názvy datasetů a velikosti zůstávají viditelné.

Soubory: použij age

age je moderní nástroj na šifrování souborů. Dělá jednu věc a nedá se nastavit špatně.

# vlastní klíč
age-keygen -o ~/.age/klic.txt
# Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

# zašifrovat pro sebe
age -r age1ql3z7... -o zaloha.tar.age zaloha.tar

# dešifrovat
age -d -i ~/.age/klic.txt -o zaloha.tar zaloha.tar.age

# jen heslem, bez klíčů
age -p -o soubor.age soubor

Nejlepší vlastnost: umí použít tvůj SSH klíč, takže nemusíš spravovat další sadu klíčů.

age -R ~/.ssh/id_ed25519.pub -o data.age data.tar
age -d -i ~/.ssh/id_ed25519 -o data.tar data.age

Uvnitř je X25519 na výměnu klíčů a ChaCha20-Poly1305 na data — přesně to, co dělá TLS, jen bez sítě.

GPG: když musíš

GPG umí totéž a ještě mnohem víc, ale je to nástroj z jiné doby: složitá konfigurace, matoucí správa důvěry, keyservery, které nikdo neudržuje, a rozhraní plné pastí.

Použij ho, když potřebuješ ověřovat cizí podpisy — podpisy balíčků, vydání softwaru, komunikaci s někým, kdo GPG používá.

gpg --verify software.tar.gz.asc software.tar.gz
gpg -c soubor                            # symetricky, heslem
gpg -e -r prijemce@example.cz soubor     # pro příjemce

Na vlastní soubory sáhni po age. Na podepisování vlastních věcí použij SSH klíč.

Co nepoužívat

openssl enc — nemá ověřenou integritu (zašifrovaný soubor jde nepozorovaně přepsat), odvození klíče z hesla je i s -pbkdf2 slabší než u konkurence a formát není nikde pořádně popsaný.

Zip s heslem — starý ZipCrypto je prolomený triviálně. Novější AES v zipu je v pořádku, ale závisí na tom, který nástroj archiv vytvořil, a to nikdy nevíš jistě.

„Šifrování" v kancelářských programech — u starších formátů jde o kosmetiku.

Zálohy

Nejdůležitější použití šifrování v klidu, protože záloha z definice leží někde jinde.

Šifruj u sebe, ne v cíli. Cílové úložiště nesmí mít klíč — jinak jsi svoje data svěřil poskytovateli.

# restic
restic -r sftp:zaloha@nas:/zalohy init
restic -r sftp:zaloha@nas:/zalohy backup /data /etc
restic -r sftp:zaloha@nas:/zalohy snapshots
restic -r sftp:zaloha@nas:/zalohy check --read-data-subset 5%
restic -r sftp:zaloha@nas:/zalohy restore latest --target /obnova

# borg
borg init --encryption=repokey-blake2 zaloha@nas:/zalohy
borg create zaloha@nas:/zalohy::"{now}" /data /etc
borg check zaloha@nas:/zalohy

Obojí šifruje na tvém stroji AES-256 a klíč odvozuje z hesla pomalou funkcí. Cílové úložiště vidí jen hromadu nesrozumitelných bloků — může to tedy klidně být cizí NAS nebo objektové úložiště v cloudu.

Tři věci, které se u zálohovacího hesla podceňují:

Heslo musí být silné. U borg init --encryption=repokey leží klíč v repozitáři zabalený tvým heslem. Kdo má kopii repozitáře, může heslo hádat offline, jak dlouho chce. Tady se mrkev-tramvaj-pisek-hlina vyplatí.

Heslo musí přežít havárii. Zapsané v správci hesel, který je sám zálohovaný jinde, plus na papíře v šuplíku. Zašifrovaná záloha bez hesla je smazaná záloha.

Vyzkoušej obnovu. Nevyzkoušená záloha je jen naděje, jak už zmiňuje zabezpečení serveru. U šifrované to platí dvojnásob, protože přibyl další způsob, jak si zavřít dveře.

Neměnná kopie. Šifrování nechrání před ransomwarem — ten smaže i zašifrovanou zálohu, ke které má server přístup. Řeší to append-only režim, oddělené účty, nebo prostě disk, který je většinu času odpojený.

Hesla a tajemství

Správce hesel

Není to volitelná vymoženost, je to základní nástroj. KeePassXC (lokální soubor), Bitwarden nebo Vaultwarden (vlastní server), pass (soubory + GPG + Git).

Databáze je zašifrovaná hlavním heslem, které musí být dlouhé a jediné, které si pamatuješ. Čtyři až pět náhodných slov je lepší než osm znaků s háčky — viz entropie.

Tajemství v konfiguracích

Tohle je v homelabu nejčastější reálný únik. Ne prolomená šifra — hesla k databázi v docker-compose.yml, který je v Gitu.

# jsou práva rozumná?
find /opt -name "*.env" -o -name "docker-compose.yml" | xargs ls -l
chmod 600 .env

Nikdy to nedávej do Gitu. Když se to stane, nestačí commit smazat — historie zůstává a tajemství je spálené. Musí se změnit, ne skrýt.

Když konfigurace v Gitu být musí, patří tam zašifrovaná. Nejlepší dnešní kombinace je sops s age:

age-keygen -o ~/.config/sops/age/keys.txt
export SOPS_AGE_RECIPIENTS=age1ql3z7...
sops -e -i secrets.yaml     # zašifruje hodnoty, klíče nechá čitelné
sops secrets.yaml           # otevře v editoru, po uložení zase zašifruje

Chytré je, že šifruje jen hodnoty. Struktura souboru zůstane čitelná, takže git diff má pořád smysl a konflikty jdou řešit.

Kontejnery

services:
  db:
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_heslo
    secrets:
      - db_heslo
secrets:
  db_heslo:
    file: ./secrets/db_heslo.txt

Lepší než proměnná prostředí, protože ta je vidět v docker inspect i v /proc/<pid>/environ každému, kdo se na stroj dostane.

Zároveň si nic nenamlouvej: kdo je ve skupině docker, je fakticky root a dostane se ke všemu. Tohle je ochrana proti nedbalosti, ne proti útočníkovi.

Časté chyby

Šifrovaný disk na běžícím serveru jako ochrana proti hackerům. Nechrání. Chrání proti krádeži hardwaru.

Nezálohovaná hlavička LUKS. Nejlevnější způsob, jak přijít o všechno.

Zapomenuté heslo od zálohy. Druhý nejlevnější způsob.

Data zašifrovaná až v cíli. Když šifruje poskytovatel, chrání tě před ostatními zákazníky, ne před poskytovatelem.

Šifrovaná záloha na disku trvale připojeném k serveru. Ransomware ji smaže stejně jako všechno ostatní.

Klíč vedle dat. Klíčový soubor na tomtéž disku, heslo v crypttab, age klíč vedle šifrovaného archivu.

Šifrování místo mazání. Když data nepotřebuješ, nejlepší ochrana je nemít je.

Přešifrování pomalého SSD kvůli pocitu. Zjisti, jestli disk nemá vlastní hardwarové šifrování (SED/OPAL) — mnohé mají a implementace bývají mizerné, takže je stejně chceš vypnout a použít LUKS.

Tahák

# LUKS
cryptsetup luksFormat --type luks2 /dev/sdX
cryptsetup open /dev/sdX nazev ; cryptsetup close nazev
cryptsetup luksDump /dev/sdX
cryptsetup luksHeaderBackup /dev/sdX --header-backup-file h.img
cryptsetup luksAddKey /dev/sdX ; cryptsetup luksKillSlot /dev/sdX 1
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdX

# soubory
age-keygen -o klic.txt
age -R ~/.ssh/id_ed25519.pub -o data.age data.tar
age -d -i ~/.ssh/id_ed25519 -o data.tar data.age
age -p -o data.age data.tar          # jen heslem

# zálohy
restic -r sftp:user@nas:/z init / backup /data / snapshots / check
borg init --encryption=repokey-blake2 user@nas:/z

# tajemství v Gitu
sops -e -i secrets.yaml ; sops secrets.yaml

# generování hesel
openssl rand -base64 32

Kam dál

• Stavební kameny — co je uvnitř AES-XTS a ChaCha20-Poly1305
• Hashe, HMAC a podpisy — proč Argon2id na hesla
• Náhodnost a entropie — odkud se bere hlavní klíč
• Zabezpečení serveru — ochrana běžícího systému
• Postkvantová kryptografie — dlouhodobě uložená data