Език: Български
„Hold Your Own Key“ (HYOK) обещава, че главният ключ на вашата организация никога не е изложен пред доставчика. Това е важно, но има смисъл само ако е вярно и следствието: когато прекъснете достъпа до ключа, работата спира. Точно това следствие рядко се демонстрира — на сцената ще го проверим в една конкретна свободна реализация и ще видим, че „спира“ не значи „спира веднага“: ключовете за данни се кешират нарочно, заради производителността, а контролът живее един слой по-горе. Двама клиенти (tenants): единият — с ключ в собствена система зад мрежата (HYOK), другият — за сравнение, с ключ в HSM-а на оператора (без HYOK). Дърпаме кабела и гледаме какво спира веднага, какво продължава до следващото разопаковане на ключ и кой изобщо може да го направи. Всичко, което демонстрирам, е свободен софтуер и ще може да се пусне с docker compose up.
Лекцията е за хора, които разработват или поддържат системи с криптирани данни. Не е нужен опит с HSM.
За целта ще демонстрирам проекта KeyRack — open-core KMS на Rust, на който съм автор, като използвам изцяло отворената му част (ядрото под AGPL-3.0). Въпросите важат за всяка HYOK архитектура, а отговорите се различават между реализациите — затова ги проверяваме на живо.
- HSM не е KMS — и обратното (≈6 мин). HSM (хардуерен модул за сигурност) пази ключове и изпълнява криптографски операции — обикновено през PKCS#11: сесии, хендъли, операции. KMS (услуга за управление на ключове) е слоят, който приложенията реално ползват: жизнен цикъл, йерархия, политика за достъп, одит, изолация между клиентите. Това, че имате HSM, не значи, че имате KMS; KMS без HSM означава ключове, пазени само софтуерно.
- KEK като криптографска оторизация (≈5 мин). Главен ключ → ключове, които криптират ключове (KEK) → ключове за данни (DEK). KEK-овете са малко и се ползват при разопаковане — там живее контролът. DEK-овете са с порядък повече и се ползват непрекъснато — затова се кешират. Това е компромис за производителност, а не пропуск: никой хипервайзор няма да пита HSM-а на клиента преди всяко четене от диска.
- Демонстрация (≈15 мин). Клиент с ключ в HSM-а на оператора (SoftHSM в самата услуга) и клиент с ключ в собствена система зад мрежата (OpenBao Transit) — всичко в контейнери. Дърпаме кабела (
docker network disconnect) при втория: работещото натоварване продължава с вече разопакования си ключ, а всяко ново разопаковане — рестарт, нов диск, нова сесия — се проваля, щом изтече кешът на KMS слоя; после свързваме отново. При първия само операторът може да спре ключа. Същото и директно срещу бекендите — за да се види кое е поведение на HSM-а и кое на KMS слоя. Настройките, от които зависят времената, са на екрана. - Честните граници (≈5 мин). Ключът на отключен LUKS volume живее в паметта на хоста, докато volume-ът не бъде затворен. Изключването спира бъдещите разопаковки — не „връща“ вече декриптираните данни. Деактивирането на KEK блокира всяко ново разопаковане под него и е обратимо; унищожаването е необратимо (crypto-shredding) само ако няма други копия на KEK или на ключовете под него. SoftHSM и OpenBao заместват истински HSM.
- Въпроси (≈5 мин).
Ще си тръгнете с въпроси за всяка HYOK система, включително към доставчика си: кой може да прекъсне достъпа, кои операции минават през вашия ключ и кои — не, колко дълго живеят разопакованите ключове за данни и какво става при загуба на връзка. И „мога ли да видя одитна следа кога са използвани ключовете за данни?“ — въпрос, на който KMS не може да отговори, защото вижда само разопаковането, а не всяко използване на DEK; отговорът трябва да дойде от системата, която ги ползва — хипервайзор, база данни, приложение.