Шифрування диска на машині, яка вам не належить

Кожен провайдер, що продає приватність, каже, що диски зашифровані. Здебільшого це правда, і здебільшого це відповідь на запитання, якого ніхто не ставив. У шифрування є три стани, про які варто турбуватися, і сервер проводить усе своє робоче життя саме в тому стані, який повне шифрування диска не охоплює. Ця стаття показує, де насправді проходить межа, що лежить по кожен її бік, і чим із двох варіантів, що продаються під однією назвою, є той, у якому ключ тримаєте саме ви.

Три стани — і той, який ніхто не шифрує

Кажуть, що дані перебувають в одному з трьох станів, і галузь переконливо впоралася з двома з них. У стані спокою — це дані на диску, який зараз ніхто не читає: тут усе вирішує повне шифрування диска та шифрування бази даних або сховища об’єктів поверх нього. У стані передавання — це дані, що перетинають мережу: тут усе вирішує TLS, і настільки надійно, що помилково видано сертифікат тепер стає новиною. У стані використання — це дані, завантажені в пам’ять працюючого процесу, а саме там мусить опинитися кожен байт, який віддає ваш сервер, хай навіть на мить, щоб узагалі бути відданим.

Фраза шифрування у стані спокою — точна, і саме через це її легко прочитати неуважно. Вона описує стан ваших даних, поки машина вимкнена. А сервер — це машина, чия єдина робота — не бути вимкненою. Місяцями, поки він працює, його томи відкриті, файли бази даних читає будь-який процес, запущений від потрібного користувача, а шифрування в цей час не робить нічого, окрім очікування на відключення живлення.

Друге, що ховається за цими чотирма словами, — кому належить ключ. Під ними продають два зовсім різні варіанти. Провайдер може шифрувати рівень сховища ключами, якими керує сам: це захищає його процес виведення обладнання з експлуатації і зменшує його власний ризик витоку, і це справді захищає вас від диска, що виносять за межі будівлі, — але стороною, яка тримає ключ, лишається та сама сторона, про яку йшлося у вашому запитанні. Або том можна зашифрувати всередині вашої власної машини, ключем, який не існує ніде, крім вашої голови і пам’яті працюючого ядра. Лише другий варіант змінює те, що здатна отримати третя сторона, і лише про другий варіант ідеться в решті цього посібника.

Усе це — не аргумент проти шифрування дисків. Це аргумент на користь того, щоб знати, який із восьми сценаріїв нижче ви вже покрили, а який — ні. Шифрування, що зупиняє одну реальну загрозу, варте того, щоб його мати; шифрування, у яке ви вірите, що воно зупиняє всі вісім, гірше за відсутність шифрування взагалі, бо ця віра закриває розмову.

Де живе ключ, поки машина працює

Коли ви розблоковуєте том LUKS, парольна фраза, яку ви вводите, — це не ключ. Вона розкриває головний ключ, що зберігається в заголовку тому, і далі цей головний ключ живе в пам’яті ядра, поки том не закриють або машина не втратить живлення. Через нього проходить кожне читання й кожен запис. Немає такої конфігурації робочого зашифрованого диска, за якої ключ перебуває десь-інде, поки диск використовується, — це не деталь реалізації, яку хтось міг би виправити, це і є те, що означає користуватися зашифрованим диском.

На обладнанні, яким володієте ви самі, ця пам’ять лежить у корпусі в кімнаті, яку контролюєте ви, і атака на неї — річ екзотична: фізична присутність і ті секунди залишкового заряду, які тримають чипи пам’яті після відключення живлення. На віртуальному сервері ситуація відрізняється не кількісно, а якісно. Пам’ять вашого ядра є ділянкою пам’яті хоста. Гіпервізор здатен звертатися до неї за визначенням, адже саме через звернення до неї гіпервізор і виділив її вам. Три цілком звичайні операції читають цю пам’ять:

• Жива міграція. Перенесення працюючої віртуальної машини між фізичними хостами копіює її пам’ять просто під час роботи. Це не помилка, а функція — саме так хост обслуговують без перезавантаження вас, — і ваш головний ключ перебуває серед сторінок, які копіюють.
• Знімок, що включає пам’ять. Знімок лише диска для тому, який ви зашифрували самостійно, містить шифротекст і нічого більше. Знімок, що дає змогу машині відновити роботу рівно з того місця, де вона зупинилася, містить і ключ, бо ключ — частина того, з чого й складається це «рівно те саме місце».
• Дамп пам’яті. Пам’ять вашої гостьової машини живе всередині адресного простору процесу на хості. Читання пам’яті цього процесу — рутинна операція налагодження, а потрібні для цього інструменти постачаються разом зі стеком віртуалізації, і їх не треба нишком проносити.

Ніщо з цього не стверджує, що ваш провайдер робить бодай щось із перерахованого. Це стверджує, що ці дії не потребують жодної співпраці з вашого боку, не лишають сліду в чомусь, що ви можете побачити, і невідмінні від звичайного обслуговування платформи. Це єдина властивість, варта того, щоб потрапити до моделі загроз: не те, що хтось робить, а те, що він здатен зробити, і ви про це не дізнаєтеся. Та сама логіка, застосована на рівень вище, пояснює, чому реєстр і проксі перед вашим сервером мають бути в тому самому списку, що й хост.

Проблема перезавантаження та обхідний шлях, що її знецінює

Зашифрований кореневий том потрібно розблокувати ще до того, як система завантажиться настільки, щоб прийняти SSH-з’єднання. На ноутбуці ви вводите парольну фразу з клавіатури. На машині за дві тисячі кілометрів, у будівлі, куди ви ніколи не заходили, у потрібну мить немає жодної клавіатури, до якої ви могли б дотягнутися. Кожна практична відповідь на це — компроміс, і лише один із чотирьох варіантів нижче зовсім не є компромісом, а лише виглядає так, ніби його зробили.

Чотири способи розблокувати зашифрований кореневий том на віддаленій машині

Спосіб	Автоматичне перезавантаження	Зупиняє викрадений диск	Чого це коштує
SSH у завантажувальний образ	Ні	Так	Мінімальний SSH-сервер усередині initramfs дає змогу підключитися й ввести парольну фразу. Машина лишається вимкненою, доки не прокинеться і не стане досяжною людина. Це чесний варіант, і його ціна реальна: перезавантаження о четвертій ранку — це простій, доки хтось його не помітить.
Ключ, що видається мережею	Так	Частково	Машина отримує ключ розблокування під час завантаження із сервера, який ви тримаєте деінде, і ви можете відмовити у видачі ключа машині, яка перемістилася або яку перезавантажили не ви. Сервер ключів має лишатися доступним і розташовуватися там, куди не дотягнеться та сама ухвала, — інакше ви просто розділили один ключ між двома дверима з одним замком.
Файл ключа у завантажувальному образі	Так	Ні	Ключ лежить в initramfs, initramfs лежить на незашифрованому завантажувальному розділі, а завантажувальний розділ лежить на тому самому диску, який ви захищали. Хто забирає диск, забирає й ключ разом із ним. Ця конфігурація поширена, вона чудово завантажується і не захищає геть нічого.
Прив’язка до TPM	Так	Частково	На обладнанні, яким володієте ви самі, справжній чип безпеки видає ключ лише незміненому ланцюжку завантаження. На віртуальному сервері цей чип емулює сам хост, тож прив’язка ключа до нього передає ключ саме тій стороні, від якої ви намагалися його приховати.

Третій рядок вартий довшого погляду. Саме туди ви потрапляєте, коли вимогу сформулювали як диски мають бути зашифровані, і ніхто не запитав навіщо. Аудит проходить. Блоковий пристрій справді зашифрований. Ключ їде на тому самому шматку заліза, у файлі, який відновлювальна оболонка прочитає секунд за чотири.

Це і є найяскравіша практична різниця між орендованою віртуальною машиною і власною. На виділеному обладнанні позасмуговий інтерфейс керування дає консоль, яка переживає перезавантаження, тож перший рядок таблиці перестає бути простоєм і стає двохвилинною перервою, — а проблема емульованого чипа з четвертого рядка просто зникає, бо чип припаяний до плати, а не написаний у коді тією стороною, від якої ви захищаєтеся.

Що насправді дає повне шифрування диска

Те саме запитання, поставлене вісім разів. Важлива саме остання колонка, бо в кожному рядку, де шифрування не допомагає, допомагає щось інше, — і назвати це «щось інше» і є вся цінність цієї вправи.

Вісім сценаріїв і те, чи змінює повне шифрування диска результат

Сценарій	Шифрування допомагає	Що насправді вирішує результат
Диск списують, перепродають або повертають за гарантією	Так	Ніщо інше цього не покриває. Диски постійно залишають дата-центри, санація — це процес, а процеси іноді тихо дають збій. Це той самий сценарій, для якого й винайшли повне шифрування диска, і саме проти нього воно працює точно так, як заявлено.
Машину вимикають і виймають диск	Так	Той самий захист із тією самою межею, і ця межа — слово вимкнена. Машину, яку забирають працюючою, забирають розблокованою: її томи відкриті, а ключ — на місці, у пам’яті.
Копія резервної копії лежить деінде	Частково	Шифрування вихідного тому нічим не допомагає копії даних. Результат вирішує те, чи резервну копію зашифрували ще до того, як вона пішла, ключем, який не зберігається на машині, що її резервують.
Платформа робить знімок	Частково	Знімок лише диска для тому, який ви зашифрували самі, — це шифротекст, марний для будь-кого без вашої парольної фрази. Знімок, що фіксує стан пам’яті, фіксує разом із ним і ключ. Обидва звуться «знімками».
Хтось отримує оболонку на працюючій машині	Ні	Том уже відкритий, і зловмисник читає файли, а не блоки. Цей рядок вирішують оновлення, принцип найменших привілеїв і облікові дані, які не повторюються між сервісами, а шифрування тут не додає нічого.
Оператор хоста або будь-хто, хто володіє його доступом	Ні	Допомагає лише шифрування, ключ якого взагалі ніколи не потрапляє на машину. Апаратне шифрування пам’яті — єдиний виняток, і воно всюди вимкнене за замовчуванням, про що йдеться в наступному розділі.
Провайдеру вручають ухвалу	Частково	Юрисдикція вирішує, хто може вимагати і на якій підставі; шифрування вирішує, що може містити відповідь. Наша опублікована правова позиція складається з двох окремих речень, і важливі обидва: ми не тримаємо ключів клієнтів і не можемо їх надати, а для незашифрованого тому на віртуальному сервері все одно потрібна ухвала, що прямо називає цей сервіс.
Вам потрібно розкрити витік	Частково	Якщо ваші користувачі в ЄС, стаття 32 GDPR прямо називає шифрування серед очікуваних від вас заходів, а стаття 34 знімає обов’язок повідомляти окремих осіб — але ніколи регулятора — якщо дані було зроблено незрозумілими. Чи застосовується це, залежить виключно від того, де був ключ у момент, коли дані пішли назовні.

Над диском: що виживає при ворожому хості

Усе сказане досі стосується рівня, що закінчується на блоковому пристрої. Над ним лежать ще три речі, і разом вони — єдина відповідь на п’ятий, шостий і сьомий рядки цієї таблиці.

Шифруйте над застосунком, а не під ним

Шифрування на рівні полів означає, що застосунок шифрує значення ще до того, як воно потрапить у базу даних, і розшифровує його вже після зчитування. Дамп бази даних дає шифротекст, хай хто його зняв і яким би шляхом. Це коштує вам можливості шукати чи індексувати зашифровані стовпці, тому воно й доречне лише для небагатьох полів, які цього варті, — тіла повідомлень, завантажені документи, токени сторонніх сервісів, — а не для всього підряд. Кінець цього шляху — наскрізне шифрування: ключ належить користувачу, сервер ніколи не тримає відкритий текст, а ворожий хост не отримує нічого, бо там просто нема чого отримувати. Це єдина архітектура на цій сторінці, якій справді байдуже, хто керує залізом, і це рішення продукту, ухвалене задовго до будь-якого рішення про інфраструктуру.

Резервні копії — окреме рішення, а не наслідок

Найпоширеніший спосіб, яким дані покидають зашифровану машину, — це резервна копія. Знімок, надісланий у сховище об’єктів, дамп бази даних, синхронізований на другого провайдера, архів, викачаний на робочу станцію, — жоден із них узагалі нічого не успадковує від тому, з якого походить. Шифруйте в момент запису даних у резервну копію, ключем, що зберігається там, куди сама машина не дотягнеться, — щоб скомпрометований сервер не міг розшифрувати власну історію. А тоді відновіть одну копію на іншій машині ще до того, як вона знадобиться: зашифрована резервна копія, яку ви не можете відкрити, — на диво акуратний спосіб втратити все відразу. Копія в іншій країні — це ще й копія під іншим набором правил, тобто друга юрисдикція, яку ви обрали, самі того не помітивши.

Шифрування пам’яті і чому воно у вас, найімовірніше, відсутнє

У того стану, який ніхто не шифрує, усе ж є апаратна відповідь. Розширення конфіденційних обчислень — SEV-SNP від AMD, TDX від Intel — шифрують пам’ять і стан регістрів гостьової машини ключем, який тримає окремий процесор безпеки, а не гіпервізор, тож хост, який знімає дамп пам’яті, отримує у відповідь лише шифротекст. Це реальна і вже доступна технологія. Але вона й вузька: SEV-SNP вимагає кремнію EPYC третього покоління або новішого, хост має бути свідомо налаштований під неї, а гостьова машина повинна засвідчити, що отримала її. Майже жоден універсальний віртуальний сервер цього не пропонує, і жоден не пропонує це мовчки. Вважайте, що у вас цього немає, якщо провайдер не заявив про це письмово і не може пояснити, як самостійно перевірити це засвідчення.

Налаштування, чесне щодо власних меж

Усе це не закінчується висновком не варто й старатися. Це закінчується конфігурацією, межі якої ви можете вголос назвати, не здригнувшись.

1. Запишіть єдиний сценарій, від якого ви насправді захищаєтеся (5 хв). Списаний диск, машина, вилучена під час роботи, ворожий хост, судова ухвала, витік, який треба розкрити. У них різні відповіді, і налаштування, розраховане одразу на всі п’ять, надійно не досягає жодного з них.
2. Розташуйте шифрування там, де ваш ключ (рішення). Якщо ключ тримає провайдер, ви купили захист лише від диска, що покидає будівлю, і нічого понад це. Якщо вам потрібно більше, том має розблоковуватися зсередини гостьової машини, вами особисто, чимось, чого платформа ніколи не бачить.
3. Шифруйте том із даними, а не кореневий (налаштування). Зашифрований корінь означає, що кожне перезавантаження чекає на вас. Окремий зашифрований том, що містить каталог бази даних, завантаження й секрети, дає змогу машині піднятися самостійно, поки чутлива частина лишається закритою, доки ви самі її не відкриєте. Це компроміс, на який варто йти більшості малих платформ, і майже ніхто його не формулює вголос.
4. Ніколи не лишайте файл ключа на незашифрованому завантажувальному розділі (правило). Якщо машина завантажується без нагляду, без сервера ключів і без консолі, ключ лежить на диску — третього варіанту нема. Це прийнятний компроміс, якщо викрадений диск і справді є всією вашою моделлю загроз, і самообман у будь-якому іншому випадку.
5. Шифруйте резервні копії в момент запису, ключем, що зберігається деінде (налаштування). А тоді відновіть одну з них на іншій машині — того дня, коли нічого не горить.
6. Сформулюйте одним реченням, що саме ви покрили (5 хв). Щось на кшталт: зловмисник, який виймає цей диск зі стійки, не отримує нічого, а будь-хто з правами root на працюючій машині чи на її хості отримує все. Якщо це речення незручно записувати, то саме тому, що воно правдиве.

Два з цих шести пунктів — рішення, а чотири — налаштування. Рішення забирають пообіддя, налаштування — годину, і ця година нічого не варта без того пообіддя. Саме через зворотний порядок люди опиняються в третьому рядку першої таблиці — з машиною, що проходить аудит і не захищає їх ні від кого.

Від якого сценарію ви захищаєтеся — це насамперед питання моделювання загроз, а вже потім питання шифрування, і годинна версія цієї вправи видає речення з кроку шість майже як побічний продукт. Якщо відповіддю виявляється судова ухвала, а не викрадений диск, то рівень, який вирішує результат, узагалі не на вашому диску — це питання про те, чиє право дотягується до вашого провайдера, і як це перевірити, перш ніж довіряти.

Написано інженерами, які підтримують платформу, і востаннє перевірено сьогодні. Якщо щось тут неправильне або застаріло, повідомте про це через панель клієнта — саме звідти прийшла приблизно половина цих посібників.