Secure Boot + TPM: що вони захищають (і що ні)

Почніть з моделі загроз, а не з галочки

Secure Boot і TPM часто продають як «безпеку завантаження». Це схоже на продаж «пасків безпеки». Паски чудові — але проти конкретних проблем. Вони нічого не роблять проти інших. Ваше завдання — обрати правильні засоби безпеки для тієї аварії, яка ймовірна у вас.

Для чого Secure Boot (в одному реченні)

Secure Boot — про примус: дозволяється виконувати лише довірені компоненти завантаження (прошивка → завантажувач → ядро) на основі перевірки підписів.

Для чого TPM (в одному реченні)

TPM — про секрети та докази: може безпечно зберігати ключі і фіксувати вимірювання процесу завантаження (PCR), щоб ви могли прив’язати доступ до «відомих хороших» станів або довести, що сталося.

Реалістичні загрози при завантаженні, які можна пом’якшити

• Атаки «зламаний покоївка» (evil maid): хтось отримує фізичний доступ до вимкненого ноутбука або сервера й маніпулює ланцюжком завантаження або витягає ключі з диска.
• Bootkit для персистенції: шкідник вбудовується під ОС (завантажувач, раннє ядро, initramfs), тож переінсталяція «зсередини ОС» не очистить систему.
• Дрейф образу постачання / золотого образу: вузол завантажив інше, ніж ви збудували, і ви хочете криптографічно виявити це.
• Крадіжка облікових даних через офлайн-доступ до диска: атакуючий краде диск або машину і пробує читати його поза місцем призначення.

Загрози, які ці механізми самі по собі не вирішать

• Віддалене RCE у вашому застосунку після завантаження ОС.
• Експлойти ядра після завантаження, що не вимагають заміни ланцюга завантаження.
• Зловмисні інсайдери з правами адміністратора, які можуть підписати власне ПЗ, якщо їм дозволено володіти підписними ключами.
• Вразлива прошивка, яка може брехати про те, що вона верифікувала.

Цитата, яку варто тримати на стіні, бо вона рятує від нісенітниць:

Перефразована ідея (Gene Kim): «Підвищення надійності — це про поліпшення системи робіт, а не про героїчні дії під час аварій.»

Secure Boot і TPM стають системою робіт, коли ви їх оперуєте: керування ключами, потоки оновлень, перевірки атестації та процедури аварійного доступу. Якщо ваш план — «увімкнути і надіятися», це не план. Це майбутній інцидент.

Secure Boot: що він запроваджує

UEFI Secure Boot — це рівень прошивки, що примушує виконувати підписані бінарні EFI. Прошивка буде виконувати лише ті EFI-бінарі, які підписані ключем, якому вона довіряє. Це суть. Все інше — shim, MOK, інструменти дистрибутивів — це оболонка, щоб це працювало в реальному житті.

Ланцюжок довіри, конкретно

Типовий Linux-ланцюжок на комерційному обладнанні виглядає так:

• Прошивка UEFI містить довірені ключі і логіку перевірки.
• shim — невеликий підписаний завантажувач, зазвичай підписаний широко довіреним ключем і здатний завантажувати додаткові ключі.
• GRUB/systemd-boot завантажується через shim і сам може перевіряти ядро та initramfs.
• Ядро завантажує модулі; примус підписування модулів — це окрий контроль.
• initramfs піднімає сховища і монтує root; якщо це недовірена частина, ви можете втратити все до старту «реальної» ОС.

Цінність Secure Boot проста: він не дозволяє запускати непідписаний (або неправильно підписаний) EFI-компонент. Це блокує клас bootkit-ів і спроб підтасування. Він також «завалить» вас о 2:00 ранку, якщо ваш процес підписування недбалий.

Ключі, з якими ви зустрінетесь (і яких слід поважати)

• PK (Platform Key): верхній ключ, що контролює конфігурацію Secure Boot.
• KEK (Key Exchange Key): авторизує оновлення баз підписів.
• db: допустимі підписи/хеші.
• dbx: відкликані підписи/хеші ( «список ні» ).
• MOK (Machine Owner Key): список ключів, керований shim; часто використовується, щоб дозволити власні ядра/модулі без заміни платформених ключів.

Якщо запам’ятати лише одне правило з операційної точки зору: поводьтесь із ключами підписування як із обліковими даними продакшн-бази. Якщо ваш ключ підписування витік, «Secure Boot увімкнено» перетворюється на «Secure Boot дозволяє стійкість для нападників».

Жарт №1: Secure Boot — як контролер з блокнотом — дуже ефективний, поки ви не роздасте фотокопії браслетів на парковці.

TPM: що він вимірює, зберігає і чого не забуває

TPM (Trusted Platform Module) — це маніпуляційностійкий компонент (чіп або реалізація у прошивці), призначений робити кілька речей надзвичайно добре: захищати ключі, видавати криптографічні докази і записувати вимірювання раннього завантаження у PCR (Platform Configuration Registers).

Основи TPM 2.0, що важливі в операціях

• PCR: спеціальні регістри, що фіксують ланцюг хешів вимірювань. Ви не «встановлюєте» PCR; ви їх розширюєте, тобто PCR = HASH(PCR || new_measurement). Це робить історію незмінною.
• Sealing: шифрування (упакування) секрету так, щоб TPM видав його лише якщо машина знаходиться в конкретному стані (часто визначеному значеннями PCR).
• Attestation: підписання твердження про значення PCR (і іноді журнал подій), щоб віддалена сторона могла перевірити стан завантаження.
• Endorsement і identity keys: ключі, що дозволяють TPM довести, що це справжній TPM, і говорити від імені конкретної машини.

Пастка «TPM авто-розблокування»

Використання TPM для авто-розблокування LUKS/BitLocker — поширене. Це також те, де багато хто обпалюється, бо плутає зручність з безпекою.

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

TPM — не магічна «ізольована зона для всього»

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

Жарт №2: TPM — це сховище, а не няня; воно не зачинить двері серверної за вас.

Secure Boot vs Measured Boot: застосування vs докази

Ці дві речі плутають, бо обидві стосуються цілісності завантаження. Вони — різні інструменти з різними режимами відмов.

Secure Boot (примус)

• Питання, на яке відповідає: «Чи дозволено виконувати цей бінарник?»
• Механізм: перевірка підпису за дозволеними ключами (db) та відкликаннями (dbx).
• Режим відмови: система не завантажується.
• Операційний біль: процес підписування, ротація ключів, відкликання, драйвери третіх сторін.

Measured Boot (докази)

• Питання, на яке відповідає: «Що було виконано?»
• Механізм: вимірювання, що записуються в PCR + журнал подій; пізніше підлягають атестації.
• Режим відмови: ви можете все ще завантажитися, але атестація не пройде або запечатані секрети не відкриються.
• Операційний біль: дрейф PCR через оновлення, зміну прошивки або конфігурації.

На практиці сильні платформи роблять обидва: Secure Boot запобігає очевидному підтасуванню; measured boot дає аудит і умовну довіру для видачі ключів.

Чого Secure Boot + TPM не захищають

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

Вони не зупиняють Runtime-компроміс

Якщо атакуючий отримає виконання коду в запущеній ОС і підніметься до root, Secure Boot не вижене його. TPM не викличе поліцію. Вам потрібні жорсткіше ядро, патчі, найменші привілеї і справжній моніторинг.

Вони не гарантують чесність прошивки

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

Вони не захищають від «авторизованого» шкідливого ПЗ

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

Вони не вирішують проблему викрадених сесій

Secure Boot і TPM можуть допомогти захистити ключі диска в стані спокою. Вони не захистять вже розблоковану машину від залогіненого атакуючого, вкраденого SSH-агента або скомпрометованої SSO-сесії. Це інша загроза — інші контрзаходи.

Вони не роблять відновлення «легшим»

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

Цікаві факти та історичний контекст (те, що люди забувають)

1. Secure Boot з’явився з масовими UEFI ПК на початку 2010-х, і відразу зіткнувся з реальністю, що люди встановлюють ОС, відмінні від заводських.
2. TPM 1.2 передував TPM 2.0 на роки; TPM 2.0 розширив алгоритми і гнучкість, що добре, доки ви не намагаєтесь стандартизувати це на хаотичному флоті.
3. Measured boot старший за більшість кар’єр у cloud-native: концепція ланцюга вимірювань походить з ранніх досліджень довіреного обчислення, а не з сучасного DevSecOps-брендингу.
4. Список відкликань UEFI (dbx) — реальний операційний важіль: він може «вбити» старі завантажувачі після оновлення, якщо ви на них залежите.
5. shim існує тому, що існує реальність: це практичний компроміс, щоб дозволити дистро брати участь у екосистемі Secure Boot без того, щоб кожен користувач з дня нуль керував платформеними ключами.
6. Підпис модулів — не те саме, що Secure Boot: навіть із увімкненим Secure Boot непідписані модулі ядра можуть бути шляхом до компрометації ядра, якщо примус підписування модулів не налаштований.
7. Значення PCR змінюються з нудних причин, як-от оновлення прошивки, зміна порядку завантаження або перемикання визначених UEFI-налаштувань. Це не «TPM, який капризує», це вимірювання, що виконує свою роботу.
8. Існують віртуальні TPM (vTPM), широко використовуються в віртуалізаційних стеках; вони корисні, але ваша довіра переходить до гіпервізора і його керування ключами.

Практичні завдання: команди, значення виводу та рішення

Ось перевірки, які я запускаю, коли хтось каже «Secure Boot увімкнено» або «TPM налаштовано». Мене цікавлять не відчуття, а докази.

Завдання 1: Перевірити стан Secure Boot з Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Що це означає: UEFI Secure Boot увімкнено і ядро це бачить.

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

Завдання 2: Підтвердити режим завантаження UEFI vs legacy BIOS

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Що це означає: Secure Boot вимагає режиму UEFI; legacy робить цю розмову в основному академічною.

Рішення: Якщо ви бачите «Legacy» на обладнанні, яке має бути захищеним, у вас проблема з базовим образом/прошивкою.

Завдання 3: Переглянути зареєстровані MOK-ключі (поширено в Linux-флотах)

cr0x@server:~$ mokutil --list-enrolled | head
MokListRT:
  SHA1 Fingerprint: 12:34:56:78:90:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88
  Subject: CN=Corp Kernel Signing CA

Що це означає: shim повірить бінарникам, підписаним цими ключами (залежно від конфігурації).

Рішення: Якщо ви не впізнаєте Subject, розглядайте це як потенційне порушення політики. Якщо впізнаєте — переконайтесь, що приватний ключ контролюється як продакшн-секрет.

Завдання 4: Перевірити, чи підписані завантажувач і ядро (Debian/Ubuntu стиль)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Windows UEFI Driver Publisher
image signature certificates:
 - subject: /CN=Canonical Ltd. Secure Boot Signing

Що це означає: EFI-бінарник містить ланцюг підписів. Примус Secure Boot діє лише на те, що ви реально виконуєте.

Рішення: Якщо постачальник підпису не відповідає вашому середовищу, можливо, ви довіряєте ширшим ключам, ніж хотіли. Для строгих середовищ використовуйте власну стратегію PK/KEK/db.

Завдання 5: Перевірити стан примусу підписування модулів ядра

cr0x@server:~$ cat /sys/module/module/parameters/sig_enforce
Y

Що це означає: Ядро вимагає підписані модулі (як налаштовано).

Рішення: Якщо «N» на системах, відкритих до недовіреного коду, розгляньте увімкнення; якщо «Y» ламає драйвери від постачальника, вам потрібен чистий процес підписування модулів, а не нічні винятки.

Завдання 6: Підтвердити наявність TPM-пристрою

cr0x@server:~$ ls -l /dev/tpm* 2>/dev/null
crw------- 1 root root  10, 224 Feb  5 10:12 /dev/tpm0
crw------- 1 root root 253,   0 Feb  5 10:12 /dev/tpmrm0

Що це означає: TPM доступний ОС. /dev/tpmrm0 — інтерфейс менеджера ресурсів (переважний для багатьох інструментів).

Рішення: Якщо відсутній — перевірте налаштування BIOS/UEFI (TPM вимкнено), відсутність драйверів або конфігурацію VM (немає vTPM).

Завдання 7: Прочитати можливості TPM, щоб підтвердити TPM 2.0

cr0x@server:~$ tpm2_getcap properties-fixed | grep -E 'TPM2_PT_FAMILY_INDICATOR|TPM2_PT_MANUFACTURER'
  TPM2_PT_FAMILY_INDICATOR: "2.0"
  TPM2_PT_MANUFACTURER: "INTC"

Що це означає: Підтверджує сімейство TPM і виробника. Це допомагає при відлагодженні непостійної поведінки на різних ревізіях обладнання.

Рішення: Якщо очікували 2.0, але бачите інше (або інструменти видають помилки), зупиніться і стандартизуйте обладнання/прошивку або підлаштуйте інструменти.

Завдання 8: Зняти знімок поточних значень PCR

cr0x@server:~$ tpm2_pcrread sha256:0,2,4,7
sha256:
  0 : 2F4A...9C11
  2 : A1B2...C3D4
  4 : 88EE...1020
  7 : 0D0C...BEEF

Що це означає: PCR — це хеші, що представляють виміряний стан завантаження (залежно від прошивки і конфігурації). PCR 7 часто асоціюють зі станом політики Secure Boot на багатьох платформах.

Рішення: Використовуйте ці значення для виявлення дрейфу або прив’язки секретів. Якщо PCR 7 несподівано змінився після оновлень — очікуйте, що запечатані секрети перестануть відкриватися, поки ви не перевипечатаєте або не відкоригуєте політику.

Завдання 9: Перевірити журнали вимірювань IMA/EVM (якщо увімкнено)

cr0x@server:~$ test -r /sys/kernel/security/ima/ascii_runtime_measurements && head -n 3 /sys/kernel/security/ima/ascii_runtime_measurements
10 8b6c2f0c8d9e1e... ima-ng sha256:... boot_aggregate
10 1a2b3c4d5e6f... ima-ng sha256:... /usr/lib/systemd/systemd
10 9f8e7d6c5b4a... ima-ng sha256:... /usr/bin/sudo

Що це означає: IMA розширює вимірювання за межі раннього завантаження до файлів у рантаймі (якщо налаштовано). Інший контроль, але часто поєднується з атестацією TPM.

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

Завдання 10: Підтвердити, що LUKS використовує TPM для розблокування (приклад systemd-cryptenroll)

cr0x@server:~$ sudo systemd-cryptenroll --dump /dev/nvme0n1p3 | sed -n '1,25p'
CRYPTTAB ENROLLMENT:
  Entry Token 0:
        Token Type: systemd-tpm2
        PCRs: 7
        SRK Handle: 0x81000001

Що це означає: Том має TPM2-токен, зареєстрований і прив’язаний до PCR 7 у цьому прикладі.

Рішення: Прив’язка лише до PCR 7 поширена і іноді прийнятна, але часто недостатня для високої впевненості. Розгляньте прив’язку додаткових PCR (наприклад, пов’язаних із завантажувачем/ядром) залежно від платформи і вашої толерантності до зламаних оновлень.

Завдання 11: Перевірити поведінку розпечатування, симулювавши невідповідність політики (безпечна перевірка лише для читання)

cr0x@server:~$ sudo systemd-cryptenroll --tpm2-pcrs=0+7 --dry-run /dev/nvme0n1p3
Failed to enroll TPM2 token: PCR 0+7 policy would change (existing token uses PCRs: 7)

Що це означає: Зміна політики PCR змінює, коли TPM видасть ключ. Ось чому «прив’язати до більшої кількості PCR» — це не безкоштовно.

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

Завдання 12: Переглянути записи завантаження і підтвердити, що ви завантажуєте саме те, що думаєте

cr0x@server:~$ sudo efibootmgr -v | head -n 15
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,2c9d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Що це означає: Показує шлях до EFI-бінарника, що реально використовується. Атакувальники і випадковості люблять альтернативні записи завантаження.

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

Завдання 13: Перевірити наявність помилок завантаження, пов’язаних із Secure Boot, у журналі

cr0x@server:~$ sudo journalctl -b -0 | grep -iE 'secure boot|shim|mok|verification|lockdown' | head
kernel: secureboot: Secure boot enabled
kernel: Lockdown: integrity: Kernel is locked down from EFI Secure Boot mode
shim: MokManager: Processing MOK enrollment request

Що це означає: Підтверджує режим lockdown і показує події реєстрації ключів.

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

Завдання 14: Визначити режим lockdown ядра (поширено з увімкненим Secure Boot)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity [confidentiality]

Що це означає: Ядро в режимі lockdown, що обмежує певні дії, які могли б обійти гарантії цілісності.

Рішення: Якщо ваші інструменти залежать від обмежених інтерфейсів (наприклад, для налагодження), сплануйте альтернативні робочі процеси. Не вимикайте Secure Boot лише щоб налагоджувач працював; використовуйте підписані ядра для контролю або контрольовані дебаг-білди.

Завдання 15: Переглянути оновлення dbx (відкликання), що можуть зламати завантаження

cr0x@server:~$ sudo mokutil --dbx | head
dbx:
  0: sha256 3f2a...d91c
  1: sha256 7a9b...0011

Що це означає: Перелічує відкликані хеші/сертифікати в dbx, як видно через mokutil.

Рішення: Якщо завантажувач, на який ви спираєтесь, з’явився в dbx (безпосередньо або через ланцюг сертифікатів), вам треба оновити компоненти завантаження по всьому флоту до застосування відкликання, інакше вузли застрягнуть.

Завдання 16: Переконатися, що TPM не в стані «потребує уваги»

cr0x@server:~$ dmesg | grep -iE 'tpm|crb|tis' | head -n 10
tpm_tis 00:05: 2.0 TPM (device-id 0x1B, rev-id 16)
tpm tpm0: TPM2.0 device found (CRB interface)

Що це означає: Ядро розпізнало TPM і інтерфейс. Помилки тут часто корелюють з неправильними налаштуваннями прошивки або багами BIOS.

Рішення: Якщо бачите тайм-аути або помилки локальності — віддайте пріоритет оновленням прошивки або виправленням платформи перед тим, як будувати системи, залежні від TPM.

Швидкий план діагностики: знайдіть вузьке місце швидко

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

По-перше: провал примусу чи невидача ключа?

• Машина взагалі не завантажується, падає в прошивку або на промпт завантажувача: ймовірно, примус Secure Boot або відкликання завантажного компонента.
• Машина завантажується, але диск не розблоковується автоматично / просить ключ відновлення: ймовірно, TPM відмовився розпечатати через дрейф PCR або зміну стану TPM.
• Машина завантажується і диск розблоковано, але атестація вказує «недовірено»: ймовірно, невідповідність measured boot, парсинг журналу подій або дрейф базової лінії.

По-друге: перевірте три «джерела правди»

1. Налаштування прошивки: Secure Boot увімкнено? CSM/legacy вимкнено? TPM увімкнений/активований? Чи було нещодавнє оновлення прошивки?
2. Компоненти завантаження: який EFI-бінарник виконано (efibootmgr), чи валідні підписи (sbverify), чи змінився dbx (mokutil –dbx)?
3. Вимірювання/ключі: значення PCR (tpm2_pcrread), політика реєстрації (systemd-cryptenroll –dump) і журнали (journalctl, dmesg).

По-третє: вирішіть, які виправлення вам дозволено робити

• Екстрене відновлення сервісу: використовуйте ключі відновлення, завантажте відомий добрий підписаний носій, відкотіть проблемне оновлення.
• Виправлення коректності: оновіть/підпишіть заново завантажувач/ядро, скоригуйте політику PCR контрольованою процедурою перевипічки, впровадьте зміни db/dbx у правильному порядку.
• Довгострокове виправлення: стандартизуйте версії прошивки, керування ключами і графік оновлень; реалізуйте обмеження розміщення робочих навантажень через атестацію для чутливих сервісів.

Вузьке місце зазвичай не «TPM зламавався». Воно — «ми щось змінили, що не виміряли, і тепер наша політика робить саме те, що ми попросили».

Поширені помилки: симптом → причина → виправлення

1) Симптом: Після оновлення ядра сервери завантажуються, але авто-розблокування LUKS не працює

Причина: Ключ, запечатаний у TPM, був прив’язаний до PCR, яких зачепило оновлення (або до стану Secure Boot, що змінився через оновлення db/dbx).

Виправлення: Скористайтесь шляхом відновлення для завантаження, потім перевипечіть/зареєструйте TPM-токен під новий виміряний стан. Розгляньте прив’язку до PCR, що відповідають вашій стратегії оновлень, і тестуйте оновлення у канарковому кільці.

2) Симптом: «SecureBoot увімкнено», але непідписані модулі ядра все одно завантажуються

Причина: Примус підписування модулів не увімкнений (або модулі підписані ключем, якому ядро довіряє через MOK/вбудований сертифікат).

Виправлення: Увімкніть примус підписування модулів там, де потрібно; проведіть аудит довірених ключів; впровадьте пайплайн підписування модулів. Не покладайтеся лише на Secure Boot для цілісності модулів.

3) Симптом: Раптово не вдається завантажити старе відновлювальне середовище

Причина: Оновлення dbx відкликало старий завантажувач/shim, що використовується на цьому носії.

Виправлення: Підтримуйте оновлене відновлювальне середовище, підписане поточними довіреними ключами; тестуйте завантаження носіїв після оновлень dbx; тримайте задокументований шлях аварійного доступу, що не залежить від відкликаних компонентів.

4) Симптом: Атестація не проходить на підмножині однакових за моделлю серверів

Причина: Різні версії прошивки або налаштування BIOS (CSM, режим Secure Boot, порядок завантаження) викликають дрейф PCR.

Виправлення: Стандартизуйте прошивку, забезпечте базис конфігурації і збирайте базові значення PCR для кожної моделі/прошивки. «Ідентичний» флот зазвичай — це прагнення, а не факт.

5) Симптом: Інструменти TPM видають помилку «No TPM device found» у VM

Причина: vTPM не прикріплений або не виставлений; або гість не має драйверів.

Виправлення: Додайте vTPM у конфігурацію гіпервізора; перевірте наявність /dev/tpmrm0; переконайтесь в наявності модулів ядра. Якщо ви не можете довіряти гіпервізору — не прикидайтеся, що vTPM дає апаратні гарантії.

6) Симптом: Secure Boot увімкнено, але маніпуляції з фізичним доступом дозволяють підмінити ланцюг завантаження

Причина: Налаштування прошивки не захищені (немає пароля адміністратора), атакуючий може вимкнути Secure Boot або зареєструвати свої ключі.

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

7) Симптом: Не можна налагоджувати продакшн через блокування з боку lockdown

Причина: Secure Boot активував політику lockdown ядра, яка обмежує доступ до деяких інтерфейсів для обходу цілісності.

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

Три корпоративні міні-історії (анонімізовано, правдоподібно та боляче)

Міні-історія 1: Інцидент через хибне припущення («Secure Boot означає, що наші драйвери безпечні»)

Середня SaaS-компанія ввела Secure Boot на вузлах Kubernetes. Це була вимога для відповідності. Команда безпеки поставила галочку, інфраструктурна команда отримала купу перезавантажень прошивки, і всі оголосили перемогу.

Через кілька тижнів пул вузлів почав поводитися дивно: періодичні втрачені пакети, піки CPU у softirq, а потім випадкові паніки ядра. Класичні «апаратні або драйверні» симптоми. Вони злили вузли, замінили кілька і проблема пішла за образом, а не за шасі.

Корінь проблеми не був екзотичним: сторонній модуль ядра встановили як частину «пакета продуктивності». Він був підписаний — бо організація заради зручності зареєструвала широкий MOK-ключ для полегшення інсталяції від постачальників. Скомпрометований артефакт потрапив у ланцюг постачання і був все ще підписаний ключем, якому всі довіряли. Secure Boot чемно виконав політику: «Якщо підписано цим ключем — запускай».

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

Міні-історія 2: Оптимізація, що обернулась проти них («Прив’яжемо ключ диска до більшої кількості PCR для кращої безпеки»)

Команда фінансових послуг вирішила посилити політику шифрування диска на ноутбуках Linux. Вони використали TPM і подумали, що прив’язка ключа до більшої кількості PCR зробить підміни складнішими. Тож прив’язали до широкого набору: прошивка, завантажувач, ядро і деякі конфігураційні вимірювання.

У лабораторії виглядало класно. Потім почалися звичайні оновлення. Прошивки розгорталися хвилями, інколи через інструменти OEM, інколи через IT. Частина машин отримала BIOS-оновлення, що змінило виміряні компоненти і PCR. Ноутбуки завантажувалися, але TPM відмовлявся розпечатувати ключ. Користувачів скидало в процес відновлення, служби підтримки завалились.

Команда безпеки спочатку думала, що це «нестабільність TPM». Це не так. Це політика, що виконує свою роботу: ці машини вже не були в старому виміряному стані.

Вони відновилися через запасні ключі і контрольовану процедуру повторної реєстрації після оновлень. Також навчилися прив’язувати до PCR, що відповідають їх оперативному темпу, і ставити оновлення прошивки в той же процес, що й оновлення ОС. Більше PCR може бути сильнішим. Це також може стати запланованим відмовним сервісом.

Міні-історія 3: Нудна, але правильна практика, що врятувала день («Ми тестували зміни dbx як продакшн-деплой»)

Велике підприємство мало змішаний Linux-флот: bare metal сервери, ноутбуки і партію пристроїв, що були по суті ПК у корпусі. Вони мали практику, яка здавалася надто консервативною: будь-яке оновлення прошивки й будь-які оновлення Secure Boot db/dbx пролітали через канаркові кільця з тестуванням завантаження, включно з відновлювальними носіями.

Одного кварталу оновлення dbx відкликало вразливий компонент завантаження. Це був правильний крок з безпеки. Це також те, що може залишити машини без завантаження, якщо ви ще використовуєте старі shim-версії або застарілі образи відновлення.

Оскільки у них були канарки, вони виявили проблему рано: їх старе ISO відновлення більше не завантажувалося. Виправлення було простим: оновити відновлювальне середовище зі свіжим підписаним shim і оновити образ постачальника пристроїв перед тим, як відкликання поширилось по флоту.

Жодної драми. Жодного дзвінка на аварійку. Жодних викладачів, які довідалися, що таке «dbx». Просто невеликий інцидент, закритий тихо. Ось такого роду неефектна операційна гігієна тримає вас на роботі.

Контрольні списки / покроковий план (що робити в реальній організації)

Контрольний список A: Розгортання Secure Boot без самонаведених простоїв

1. Інвентар режиму прошивки: підтвердіть UEFI в усіх місцях; усуньте інсталяції з legacy BIOS.
2. Визначте стратегію ключів: дефолти постачальника vs власні PK/KEK/db. Якщо потрібен сильний контроль організації — плануйте власні ключі й ескроу.
3. Налагодьте пайплайн підписування: хто підписує ядра/модулі? де зберігається ключ? які існують затвердження? де логи аудиту?
4. Плануйте зміни dbx: відстежуйте відкликання; тестуйте, що ваші компоненти завантаження й відновлювальні носії не відкликані.
5. Канаркуйте все: прошивка, shim, завантажувач, ядро і оновлення dbx. Тестування завантаження — не опційно.
6. Визначте break-glass: консоль поза смугою, відновлювальні носії, ключі відновлення і людський процес їх використання.

Контрольний список B: Використання TPM для розблокування диска без самообману

1. Визначте, від чого захищаєтеся: вкрадений ноутбук, викрадений сервер чи підміна?
2. Обирайте політику PCR свідомо: прив’язка лише до PCR 7 зручна; ширша політика сильніша, але крихка. Вибирайте згідно з реаліями оновлень.
3. Зберігайте ключі відновлення безпечно: ескроу з контролем доступу і журналюванням. Тестуйте відновлення щоквартально.
4. Плануйте оновлення прошивки: вони змінять PCR. Створіть робочий процес повторної реєстрації.
5. Моніторте дрейф: збирайте базові значення PCR; оповіщайте про несподівані зміни для чутливих ролей.

Контрольний список C: Атестація, яка не перетворюється на театральність

1. Визначте, що робитимете з результатами атестації: блокуватимете розміщення робочих навантажень, обмежуватимете секрети або просто зберігатимете докази?
2. Базуйте по класу платформи: модель обладнання + версія прошивки + профіль конфігурації.
3. Робота з оновленнями: поводьтеся з новими базовими значеннями як з релізом; просувайте через кільця тестування.
4. Зберігайте журнали: атестація без збереження — хобі, а не контроль.

FAQ

1) Чи Secure Boot щось шифрує?

Ні. Secure Boot верифікує підписи, щоб вирішити, що можна виконувати. Шифрування даних у стані спокою — окремий контроль (LUKS, BitLocker тощо).

2) Якщо Secure Boot увімкнено, чи я в безпеці від bootkit-ів?

Ви краще захищені від непідписаних або недовірених bootkit-ів. Якщо атакуючий може підписати шкідливий компонент довіреним ключем (або скомпрометувати ваш ключ), Secure Boot із задоволенням його запустить.

3) Що насправді зберігає TPM?

Він може зберігати ключі (або матеріал ключа), лічильники і невеликі блоби. Також фіксує PCR-значення (вимірювання) і може підписувати твердження атестації. Це не загальне сховище.

4) У чому різниця між прив’язкою до PCR і просто «TPM присутній» при розблокуванні диска?

Прив’язка до PCR означає, що TPM видає ключ лише якщо виміряний стан відповідає політиці. «TPM присутній» без осмисленої політики PCR — це здебільшого зручність; воно може не витримати маніпуляцій.

5) Чому оновлення прошивки ламає TPM-авто-розблокування?

Тому що змінилися виміряні компоненти, PCR-значення змінились, і TPM відмовився розпечатати ключ, прив’язаний до старих вимірювань. Це очікувана поведінка.

6) Чи можна використовувати TPM у VM і все ще стверджувати апаратну довіру?

Ви можете використовувати vTPM і отримати функції, як-от sealing і attestation у межах віртуалізаційного кордону. Але ваша довіра переходить до гіпервізора, його сховища секретів vTPM і його сценарію атестації.

7) Чи слід використовувати власні ключі Secure Boot (власний PK/KEK/db) скрізь?

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

8) Secure Boot — це те саме, що kernel lockdown?

Ні, але вони пов’язані на багатьох дистро. Коли Secure Boot увімкнено, ядро може перейти в режим lockdown, щоб заборонити дії, які могли б обійти гарантії цілісності.

9) Чи Secure Boot не дозволить завантажувати з USB-накопичувача?

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

10) Що варто логувати і моніторити?

Щонайменше: стан Secure Boot, зареєстровані ключі (MOK/db), зміни dbx, версії прошивки, наявність TPM і результати атестації для машин із чутливими робочими навантаженнями.

Наступні кроки, які дійсно мають значення

Якщо ви хочете, щоб Secure Boot + TPM були чимось більшим за позначку відповідності, зробіть три речі:

1. Опишіть вашу модель загроз простими словами. «Evil maid на ноутбуках» і «bootkit-персистенція на гіпервізорах» — це різні світи.
2. Оперуйте ключами і оновленнями: ставтесь до підписування як до продакшн-деплою, тестуйте зміни dbx як оновлення ядра, і стандартизуйте прошивку.
3. Практикуйте відновлення: ескроуйте ключі відновлення, тримайте оновлені відновлювальні носії і проводьте щоквартальну перевірку «чи можемо ми відновити запечатаний диск після оновлення прошивки?»

Secure Boot впроваджує те, чому ви довіряєте. TPM допомагає прив’язати секрети і довести, що сталося. Жодне з цього не замінює патчинг, контроль доступу чи нудні процеси. І саме «нудні процеси», на диво, — там, де жива більшість безпеки.