Безопасность начинается
ниже поверхности.

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

Допустимость и измерение

Secure Boot проверяет компоненты загрузочной цепочки относительно доверенных подписей и политики отзыва. Measured Boot сохраняет измерения выбранных компонентов. В первом случае важен допуск к запуску; во втором — возможность позднее оценить измеренное состояние.

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

Обновление меняет контекст

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

Полезный отчёт отдельно отвечает: что запущено, почему это разрешено и чем подтверждён результат.

Первоисточники: спецификации UEFI · Microsoft: безопасность загрузки Windows.

Руткит связывают с сокрытием присутствия и вмешательством в представление системы: процессы, файлы, соединения или другие признаки могут выглядеть иначе для наблюдателя. Буткит действует в загрузочной цепочке и получает влияние до запуска обычных средств защиты ОС.

Сначала определить слой

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

Разбор BlackLotus у Microsoft показывает, почему внимание к загрузочной цепочке существенно для расследования. Изменения на EFI System Partition и состояние защитных механизмов дают материал для оценки, но отдельный необычный файл сам по себе не устанавливает причину.

Сохранять различия

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

Отсутствие признака полезно лишь вместе с ответом на вопрос: мог ли этот источник его увидеть?

Первоисточник: Microsoft: расследование кампании BlackLotus.

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

Проверка зависит от режима

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

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

Что сохранять в отчёте

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

Первоисточник: Linux Kernel: Kernel module signing facility.

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

Свежесть — часть смысла

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

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

Три роли

Архитектура RATS разделяет сторону, предоставляющую свидетельства, проверяющую сторону и потребителя результата. Такое разделение помогает не смешивать сбор данных, их оценку и решение о доступе.

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

Первоисточники: TCG: TPM 2.0 Library · IETF RFC 9334: RATS Architecture.

seL4 — микроядро с формальной верификацией и моделью полномочий на основе capabilities. Малый привилегированный фундамент позволяет строить систему из изолированных компонентов с явно выделенными ресурсами и каналами взаимодействия.

Доказательство имеет область

Формальная гарантия относится к определённому свойству, модели и конфигурации. Она зависит от предпосылок о платформе и от охваченных частей системы. Из этого не следует, что произвольное приложение поверх ядра автоматически получает все те же гарантии.

Инженерная работа продолжается в пользовательских службах, драйверах, конфигурации полномочий и интерфейсах. Уязвимый сервис с избыточными правами остаётся значимым риском даже при сильных свойствах ядра.

Вопросы к проекту

Какие объекты доступны компоненту? Кто может выдать или отозвать право? Как ограничены память, устройства и IPC? Какие зависимости входят в доверенную базу? Такой разговор превращает слово «изоляция» в проверяемую архитектуру.

Первоисточник: seL4 Foundation: What is seL4?

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

Интерфейс остаётся поверхностью проверки

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

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

Что предполагалось о платформе

Оценка TEE включает модель угроз и доверенные уровни платформы. Отдельно рассматриваются доступность сервиса, происхождение его кода, обновление и поведение при отказе. Изоляция данных и гарантированное выполнение в нужный момент — разные свойства.

Первоисточники: OP-TEE: Core architecture · OP-TEE: Security scope.

Фраза «компонент работает в песочнице» оставляет открытым главный вопрос: какие действия ему доступны? Полезное описание перечисляет разрешённые ресурсы, интерфейсы, ограничения и владельца политики.

Ограничить поверхность

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

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

Проверить завершение

У изолированной задачи есть жизненный цикл. После её остановки важны освобождённые ресурсы, отозванные права и состояние зависимых компонентов. Иначе завершившийся процесс может оставить действующие возможности или занятые объекты.

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

Первоисточник: Linux Kernel: Seccomp BPF.

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

От наблюдения к решению

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

Согласие двух источников увеличивает уверенность лишь с учётом их зависимостей. Если оба читают одну и ту же изменённую структуру, совпадение не даёт независимого подтверждения. Расхождение, напротив, стоит сохранить для расследования.

Пакет для повторной проверки

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

Для PANDORA BOX этот принцип соединяет Audit, Sense, Trust и квитанцию операции: команда получает историю, пригодную для повторного разбора.

Первоисточник: IETF RFC 9334: роли и свидетельства аттестации. Связанный проект: доверенная архитектура PANDORA BOX.