Remote attestation через TPM: целостность загрузки в ЛВС

Какая проблема с подменой BIOS и загрузчика

Подмена BIOS/UEFI и загрузчика - это атака на самый ранний этап старта компьютера, еще до загрузки Windows или Linux, когда антивирус и агенты мониторинга не работают. Злоумышленник пытается закрепиться там, куда обычные средства защиты почти не смотрят.

Чаще всего атакуют три зоны:

• прошивку UEFI: в нее внедряют вредоносный модуль или меняют настройки так, чтобы система доверяла не тому, чему должна;
• загрузчик и ранние компоненты загрузки, которые запускают ядро;
• параметры Secure Boot: их отключают, подменяют ключи или настраивают так, чтобы запускались неподписанные компоненты.

Закрытая сеть риск не отменяет. В локальной сети все равно есть флешки и внешние диски, которые приносят обновления, драйверы или отчеты. Бывает выездной сервис и плановое обслуживание, когда кто-то получает физический доступ к машине. Есть и цепочки поставок: прошивку обновляют из пакета, который выглядит доверенным, а настройки меняют руками, когда нужно срочно поднять систему после сбоя.

Опасность такой подмены в скрытности и устойчивости. Если вредоносный код живет в UEFI или в ранней загрузке, он может пережить переустановку ОС, замену диска и часть процедур восстановления. Он также способен подменять то, что видят инструменты безопасности: скрывать процессы, отключать проверки, подсовывать «чистые» логи.

ИТ обычно видит только косвенные симптомы, и то не всегда:

• Secure Boot внезапно выключен или менялись настройки UEFI;
• станция ведет себя странно после обслуживания или обновления прошивки;
• периодические сбои загрузки без понятной причины;
• несоответствие версий или контрольных сумм в эталонной конфигурации;
• странные исключения в политиках или правилах запуска.

Самое неприятное - то, чего ИТ не видит: факт подмены до старта ОС. Отсюда и потребность в контроле целостности загрузки, а дальше логично прийти к remote attestation через TPM как к способу проверять, что машина стартует так, как ожидается.

Remote attestation и TPM простыми словами

TPM (Trusted Platform Module) - это защищенный модуль в компьютере, который помогает подтвердить, что машина загрузилась «как положено». Его часто называют корнем доверия: он хранит ключи и, главное, фиксирует измерения важных частей загрузки так, чтобы их было трудно подделать задним числом.

Во время старта ПК компоненты по цепочке измеряют друг друга (считают хеш) и записывают результат в специальные регистры TPM - PCR (Platform Configuration Registers). PCR не хранят сами файлы. Они хранят «отпечатки» состояния, причем запись идет накопительным образом. Если что-то меняется, меняется и итоговый отпечаток.

Обычно в PCR попадают измерения:

• прошивки UEFI/BIOS и настроек, влияющих на загрузку;
• загрузчика и ранних компонентов ОС;
• параметров Secure Boot (что разрешено запускать);
• драйверов и модулей, которые стартуют очень рано;
• иногда - политик и конфигураций, которые ОС считает частью доверенной загрузки.

Remote attestation через TPM - это удаленная проверка этих измерений. Идея простая: есть «эталон» правильной конфигурации для конкретной модели и образа ОС, а рабочая станция по запросу подтверждает, какие PCR у нее получились при реальной загрузке. Сервер сравнивает значения с эталоном и решает, доверять ли машине: давать доступ в сеть, пускать в чувствительные системы или отправить на разбор.

Это не то же самое, что антивирус и проверка файлов. Антивирус работает в уже загруженной системе, где злоумышленник может скрывать следы. Attestation проверяет раннее состояние, когда обычные средства защиты еще не запущены, поэтому лучше ловит подмену BIOS/UEFI и загрузчика.

Практический пример: после обслуживания ПК в закрытой сети администратор запускает проверку. Если PCR не совпали с эталоном для этой роли (например, бухгалтерская станция), устройство не получает доступ к критичным ресурсам до выяснения причин.

Что нужно подготовить, чтобы все заработало

Чтобы remote attestation через TPM не превратился в «проверку ради галочки», сначала нужно договориться, что именно считается нормой, и обеспечить одинаковые стартовые условия.

Первое и обязательное: TPM 2.0 должен быть включен в BIOS/UEFI и виден в операционной системе. Важно не только наличие модуля, но и то, что ОС реально умеет читать измерения загрузки (measured boot) и журнал событий. На практике это часто ломается из-за отключенного TPM, старой прошивки или «сброшенных» настроек после сервиса.

Дальше проверьте режим загрузки. Для современных сценариев нужен UEFI. Secure Boot стоит включить, если это не конфликтует с вашей политикой и используемыми образами ОС. Secure Boot не заменяет измерения TPM, но повышает шанс, что подмена загрузчика не пройдет незаметно.

Третий блок - управление изменениями. Attestation хорошо работает, когда изменения контролируемы: обновления BIOS/UEFI, микрокода, драйверов, загрузчика и образа ОС должны проходить по единой процедуре. Иначе вы будете видеть постоянные «красные» отклонения просто из-за разнобоя.

Заранее определите «эталон»: какие модели устройств, прошивки и образы ОС допустимы. Для парка рабочих станций обычно фиксируют эталон для типовой конфигурации офисного ПК и отдельно - для машин с расширенными правами (администраторы, бухгалтерия, доступ к медицинским системам).

Перед пилотом полезно собрать минимум:

• инвентаризацию устройств (модель, версия BIOS/UEFI, статус TPM 2.0, режим UEFI);
• согласованные настройки прошивки (TPM включен, запрет Legacy/CSM, политика Secure Boot);
• базовый эталонный образ ОС и список разрешенных загрузочных компонентов;
• правила обновлений: кто, когда и как обновляет BIOS/UEFI и драйверы;
• место, где будет храниться «норма» и результаты проверок (даже в закрытой сети).

Если оборудование обслуживается на месте и часто есть физические работы (замена платы, перепрошивка, восстановление после сбоев), закрепите простой регламент: любое обслуживание либо обновляет эталон по процедуре, либо переводит устройство в режим проверки после работ.

Что именно проверять: границы и уровень строгости

Чтобы remote attestation через TPM реально снижал риск подмены, нужно заранее решить две вещи: что измерять и какие изменения считать нормальными. Иначе система либо промолчит там, где надо бить тревогу, либо завалит ложными срабатываниями после каждого обновления.

Что измерять в первую очередь

Идите по цепочке загрузки от самого раннего к более позднему. Чем раньше компонент, тем выше цена подмены и тем полезнее контроль.

Обычно в приоритет попадают:

• UEFI/BIOS и ключевые настройки безопасной загрузки (Secure Boot, порядок загрузки, запрет внешних носителей);
• менеджер загрузки и его подпись (Windows Boot Manager или аналог);
• критичные файлы загрузчика и драйверы ранней загрузки;
• компоненты ОС, влияющие на доверенную загрузку;
• политики, которые меняют смысл проверки (например, включение тестовых режимов).

На старте часто достаточно покрыть UEFI и загрузчик. Контроль «всего подряд» редко дает пользу в пилоте, зато добавляет шум.

Границы: что допустимо, а что подозрительно

TPM фиксирует измерения, но решение принимает ваша политика. Удобная модель - «разрешенные состояния» (baseline) для каждой группы устройств.

Допустимыми стоит считать только изменения, которые вы можете объяснить и повторить:

• плановое обновление UEFI/BIOS от производителя;
• обновления ОС, которые меняют загрузочные компоненты;
• санкционированная смена настроек Secure Boot или ключей;
• замена накопителя или материнской платы по оформленному обслуживанию.

Чтобы не ловить тревоги после каждого патча, ведите процесс обновления baselines: тест на небольшой группе, утверждение нового «золотого» состояния, затем массовое обновление.

Отдельный момент - разные модели рабочих станций. Для линеек вроде GSE L200 (ПК) и M200 (моноблоки) корректнее держать разные профили: отличия в прошивке и драйверах дадут разные измерения даже при одинаковой ОС. Это нормально, если сравнивать устройство с «своим» эталоном, а не с универсальным.

Уровень строгости выбирайте по риску. Для бухгалтерии и рабочих мест с доступом к критичным системам политика должна быть жестче, чем для учебного класса. Важно, чтобы отклонение всегда вело к понятному действию: ограничить доступ, перевести в карантин или отправить на ручную проверку.

Пошагово: как внедрить без сложных проектов

Если цель простая - понимать, что рабочая станция загрузилась «как обычно», и вовремя заметить подмену BIOS или загрузчика, remote attestation через TPM можно начать с пилота на 10-20 машинах. Смысл пилота - сначала зафиксировать норму.

Минимальный план внедрения

1. Опишите «базовый образ»: версия BIOS/UEFI, Secure Boot (если используете), набор драйверов, версия ОС и ключевые политики, влияющие на раннюю загрузку. В закрытых сетях удобно сразу разделить парк на 2-3 понятные группы (одинаковые модели и одинаковый образ), чтобы не утонуть в исключениях.

2. Включите сбор измерений. Обычно это PCR-значения и журнал измеренной загрузки, плюс важные для вас сигналы: статус Secure Boot, изменения в UEFI-настройках, версия микрокода, состояние BitLocker или аналога.

3. Снимите эталон на «чистых» машинах. Возьмите несколько рабочих станций из каждой группы, полностью обновите их по регламенту (BIOS, ОС, драйверы) и зафиксируйте допустимые значения. Эталон лучше хранить как набор доверенных профилей: даже легальные обновления будут менять часть измерений.

4. Включите регулярную проверку. На старте часто достаточно проверки при каждой загрузке и раз в сутки. В закрытой сети это удобно делать через локальный сервис или выделенный сервер в ЛВС, без внешних зависимостей.

5. Заранее определите реакцию на отклонение, чтобы не разбирать каждое событие вручную.

Если свести к короткой схеме:

• пилот: 10-20 ПК, 2-3 группы одинаковых конфигураций;
• сбор: PCR + журнал измеренной загрузки + статус Secure Boot и базовые политики;
• эталон: 3-5 «чистых» машин на группу, несколько допустимых профилей;
• расписание: при загрузке + ежедневная проверка;
• реакция: уведомление, ограничение доступа, карантин до проверки.

Модель реакции удобнее делать ступенчатой: сначала маркировка как «подозрительное», затем ограничение доступа к критичным сегментам, и только потом полный карантин, если несоответствие подтверждается повторно.

Пример: после обслуживания инженер обновил BIOS на части рабочих станций. Если у вас есть «разрешенный профиль» под новую версию BIOS, система примет изменения как плановые. Если же у одной машины внезапно меняется цепочка загрузки без окна работ, это повод автоматически закрыть доступ к финансовым системам до выяснения.

Если вы закупаете новые рабочие станции с TPM 2.0, полезно сразу включать требования к измеренной загрузке в стандарт выдачи. Для парка, который собирается и поддерживается локально, проще закрепить это регламентом и держать одинаковые профили в рамках партий и моделей.

Что считать «красным флагом» на старте

Есть отклонения, которые почти всегда требуют внимания:

• изменился набор измерений загрузки при отсутствии плановых обновлений;
• Secure Boot внезапно выключен или его состояние стало неопределенным;
• появились новые записи ранней загрузки, которых не было в эталоне;
• отклонение повторяется после перезагрузки и не объясняется обновлением.

Такой подход дает быстрый эффект: вы фиксируете норму, проверяете ее автоматически и запускаете понятные действия при нарушениях.

Как организовать проверку в закрытой сети

В закрытой сети главный вопрос - где будет жить доверие. Нужен локальный центр, который собирает измерения загрузки с рабочих станций и сравнивает их с эталоном. Так вы получаете remote attestation через TPM без вывода данных наружу.

Практичный вариант для ЛВС - поднять сервер аттестации в том же сегменте, где находятся рабочие станции (или в отдельном защищенном сегменте с доступом только по нужным портам). Станции при старте или по расписанию отправляют набор измерений (PCR-значения, статус Secure Boot и похожие сигналы), а сервер решает: «доверять» или «карантин».

Где хранить эталоны и журналы

Эталоны лучше хранить централизованно на сервере аттестации, а не на рабочих станциях. Журналы проверки тоже складывайте на сервер: в закрытой сети именно журнал часто становится единственным источником, чтобы понять, когда и на какой машине начались изменения.

Чтобы не потерять историю и не дать ее «подчистить», помогают простые правила:

• разделите роли: кто обновляет эталоны и кто читает журналы;
• храните журналы с контролем целостности и резервной копией;
• фиксируйте, к какой модели ПК и версии прошивки относится эталон;
• не смешивайте в одном эталоне разные типы станций и разные режимы загрузки.

Проверка перед доступом и обновление эталонов

Самый понятный сценарий - проверка перед выдачей доступа к критичным ресурсам. Например, перед подключением к финансовой системе или к админскому сегменту станция проходит проверку и только затем получает доступ.

Второй сценарий - регулярная проверка по расписанию (например, утром при включении) и дополнительная проверка по событию: после перезагрузки, после смены прошивки, после обслуживания.

Частая проблема: плановые патчи меняют измерения, и «хорошие» машины внезапно становятся подозрительными. Решение - сделать обновление эталонов частью регламента изменений. Пример: после планового обновления BIOS на партии рабочих станций вы сначала подтверждаете изменения на 1-2 контрольных машинах, формируете новый эталон для этой версии, и только потом расширяете обновление на остальных.

Правило для закрытой сети простое: эталоны обновляются только после подтвержденного изменения, а доступ к критичным ресурсам выдается только после успешной проверки.

Частые ошибки и как их избежать

Remote attestation через TPM часто ломается не из-за криптографии, а из-за организационных мелочей. Система начинает показывать «красное» там, где просто изменился состав железа или прошивка, и команда перестает ей доверять.

Типовые ошибки:

• Делают один эталон на разные модели и ревизии ПК. Даже похожие станции могут иметь разные версии UEFI, разные опции загрузки и разные измерения. Выход: разделяйте эталоны по семействам и конфигурациям (модель, версия UEFI, режим загрузки, включен ли Secure Boot). Если парк большой, начните хотя бы с 2-3 самых массовых групп.
• Обновляют BIOS/UEFI и забывают переснять эталон. После обновления «отпечатки» меняются, и это нормально. Помогает правило: любое плановое изменение прошивки проходит через окно изменений и заканчивается обновлением эталона и короткой проверкой пары устройств.
• Оставляют Secure Boot выключенным или переводят в Legacy ради совместимости, но не фиксируют риск. Если Secure Boot отключить нельзя, оформите это как исключение: отдельная группа устройств, отдельная политика и более частые проверки.
• Игнорируют сервисные работы: замену платы, SSD, перепрошивку, переустановку ОС. Для TPM это разные события, и часть из них меняет измерения. Нужен регламент: после работ устройство либо возвращается в «известное хорошее» состояние, либо уходит в карантин до переснятия эталона.
• Нет сценария, что делать при «красном» статусе. Тогда любые алерты превращаются в спор «атака или ложное срабатывание».

Чтобы «красный» не зависал неделями, помогает короткий процесс реакции:

1. Изолировать устройство от чувствительных сегментов (хотя бы временно).
2. Сверить, было ли окно изменений или сервисные работы.
3. Повторить проверку после перезагрузки и убедиться, что статус стабильный.
4. Если отклонение не объясняется изменениями, сравнить с эталоном своей группы и поднять инцидент.
5. Вернуть в эксплуатацию только после восстановления доверенной загрузки (например, откат UEFI/настроек, переустановка загрузчика) и фиксации нового статуса.

Пример: после обслуживания сотруднику заменили системную плату. На следующий день attestation показывает отклонение. При наличии регламента это не выглядит как «взлом»: устройство попадает в сервисную группу, фиксируется замена, переснимается эталон для этой конфигурации, и станция возвращается в работу без лишней паники.

Если вы используете однородные партии рабочих станций и серверов (серийные закупки у одного производителя), дисциплина с группами эталонов и окнами изменений дает самый быстрый эффект.

Короткий чеклист перед запуском

Перед тем как включать remote attestation через TPM на всем парке, проверьте базовые вещи. Это экономит время на поиске причин, почему у части компьютеров «не сходятся» измерения загрузки.

Минимум, который должен быть готов

Убедитесь, что на каждой машине TPM определяется системой и включен в настройках. Отдельно подтвердите, что это TPM 2.0, а не старый модуль или режим совместимости.

Проверьте режим загрузки. Для предсказуемой проверки целостности нужен UEFI. Secure Boot должен быть либо включен, либо вы осознанно выбрали режим без него и понимаете, что тогда измеряется и что останется вне контроля.

Подготовьте эталон не «на организацию», а на связку: модель компьютера, версия BIOS/UEFI, конфигурация диска и ОС, набор критичных драйверов и политик загрузки. Даже две одинаковые по модели станции могут дать разные значения, если отличается версия прошивки или режимы контроллера.

Операционные вопросы, без которых все развалится

• Для каждой модели и типовой конфигурации есть эталон (или эталонная политика) и понятный способ обновлять его после легитимных изменений.
• Задано расписание проверок: когда проверяем (при включении, раз в день, после обновлений) и кто имеет доступ к журналам.
• Определено хранение журналов: где лежат, сколько хранятся, как быстро поднять историю по конкретному ПК.
• Есть сценарий реакции на несоответствие: кто отвечает, за какое время должен отработать, что делаем с пользователем и устройством.
• Продуман «безопасный сбой»: что считать критичным (подозрение на подмену BIOS/загрузчика), а что - поводом для повторной проверки.

Если парк типовой, проще начать с одной модели и только потом расширять охват. Для корпоративных поставок удобно опираться на стандартизированные конфигурации, которые собираются и поддерживаются централизованно.

Пример: проверка рабочей станции после обслуживания

Рабочая станция в бухгалтерии вернулась из сервиса: заменили SSD и, по словам подрядчика, обновили BIOS, чтобы исправить нестабильность. Визуально все нормально: Windows загружается, антивирус молчит. Но именно после обслуживания чаще всего и появляются риски: могли поменять настройки загрузки, подменить загрузчик или поставить чужую прошивку.

Вы запускаете remote attestation через TPM и сравниваете результаты с эталоном, снятым для этой модели и конфигурации до вмешательства. Аттестация показывает не «в целом все хорошо», а конкретные изменения в измерениях: поменялись значения, связанные с прошивкой (BIOS/UEFI), цепочкой загрузки и настройками Secure Boot. Это полезный сигнал: система действительно видит изменения, а не «слепа» к ним.

Дальше важно отделить плановое обновление от подмены. Плановые изменения обычно совпадают с заявкой на работы: новая версия BIOS, ожидаемые изменения в настройках, понятная причина (например, включили Secure Boot там, где он был выключен). Подмена чаще выглядит как неожиданное отклонение без объяснения или как набор изменений, который не должен был появиться после простой замены диска.

Практичный порядок действий:

• Временно ограничьте доступ станции к важным ресурсам, пока не разберетесь с причиной расхождений.
• Сверьте изменения с заявкой на обслуживание и версией прошивки, которую обещал сервис.
• Если есть сомнения, выполните повторную прошивку BIOS из доверенного источника и верните настройки загрузки в утвержденное состояние.
• Повторите аттестацию: значения должны либо вернуться к прежним, либо стабильно соответствовать ожидаемому обновлению.
• Если обновление подтверждено как плановое, обновите эталон для этой станции (или партии одинаковых станций) и зафиксируйте это в регламенте.

Так бухгалтерия быстро возвращается к работе, а ИБ не приходится «верить на слово» сервису. Решение принимается по фактам, и риск тихой подмены BIOS или загрузчика заметно ниже.

Следующие шаги: пилот, регламенты и поддержка

Переход к remote attestation через TPM лучше начинать с короткого пилота. Так вы быстро поймете, какие замеры реально полезны, как часто возникают ложные срабатывания, и кто в компании принимает решение по «не прошедшей» машине.

Пилот: кого брать и как понять, что получилось

Выберите группу, где риск подмены загрузки заметен, а простой недопустим: рабочие станции администраторов, бухгалтерии, операторов с доступом к критичным системам, плюс несколько устройств, которые чаще других ездят на обслуживание.

Критерии успеха лучше зафиксировать заранее:

• доля ПК, которые стабильно проходят проверку после штатных обновлений;
• время реакции от сигнала до решения (разрешить, ограничить, отправить на проверку);
• количество «шумных» событий и их причины (обновление BIOS, замена диска, сброс ключей);
• понятный процесс сервисных работ;
• отчетность: кто и когда подтверждал исключение и почему.

Регламенты и поддержка: чтобы работало каждый день

Дальше пилот важно превратить в рутину. Назначьте роли и границы ответственности. Обычно нужны: ИБ (политика и решения по инцидентам), ИТ (платформы, обновления, учет устройств), сервис или аутсорс (физические работы), владелец системы (приоритеты и допустимый простой).

Проверку стоит встроить в два процесса.

Первый - приемка новых ПК. При выдаче сотруднику фиксируйте «чистую» конфигурацию, включайте TPM 2.0 и доверенную загрузку, проверяйте, что замеры снимаются и проходят.

Второй - регламент обновлений. Любое обновление BIOS, прошивки, загрузчика или политики загрузки должно иметь понятный сценарий: кто инициирует, кто подтверждает, как обновляются эталонные значения и как быстро откатываться при проблеме.

Подключать системного интегратора имеет смысл, если у вас много моделей ПК, несколько доменов или площадок, нужны строгие правила изоляции, или вы хотите связывать результат аттестации с допуском к сети.

Если вы работаете с типовыми партиями компьютеров и централизованным сопровождением, проще поддерживать единые профили измеренной загрузки и обновлять их по регламенту. В Казахстане для таких задач используют, в том числе, оборудование и интеграционные услуги GSE.kz (gse.kz), когда нужно совместить поставку рабочих станций и серверов с дальнейшей поддержкой и обслуживанием.