Сначала вывод: TPM — это не сейф, это сопроцессор, припаянный к материнской плате. Когда у прошивки AMD TPM были обнаружены уязвимости высокой опасности в версиях 8.3/8.5, моей первой реакцией было не прошивать микрокод, а пересмотреть наш собственный реестр хранения ключей — все машины, где корневой ключ шифрования резервных копий был напрямую привязан к TPM, помечены как требующие доработки. В этой статье я расскажу о трёх вещах: как был скомпрометирован корень доверия, к каким последствиям приводит цепная реакция утечки ключей и какую схему развязки ключей я сейчас использую.
Корень доверия TPM — кому он доверяет
Ключевая ценность TPM — это обещание, что «ключ никогда не покидает чип». Закрытый ключ генерируется и используется внутри чипа, внешняя шина передаёт только результаты, а не ключи. Эта модель работает при условии, что прошивка чипа заслуживает доверия. Реализация TPM от AMD идёт по пути fTPM, прошивка выполняется на защищённом сопроцессоре внутри процессора. Проблемы, раскрытые в версиях 8.3 и 8.5, по сути являются дефектами изоляции памяти и проверки команд на уровне прошивки: после получения прав на локальное выполнение кода атакующий может сконструировать определённую последовательность команд и прочитать объекты ключей, которые должны были быть изолированы.
Обратите внимание на ограничение: требуются локальные права. Поэтому многие первым делом думают: «Не важно, на мой сервер ведь никто не зайдёт». Проблема в сценарии резервного копирования. Агенты резервного копирования, сервисы снапшотов, обёртка ключей TDE баз данных — эти процессы сами работают на хосте. Как только веб-приложение взломано и побег из контейнера удался, атакующий получает локальные права и затем напрямую обращается к TPM на чтение. Цепочка доверия обрывается на звене прошивки, и LUKS, BitLocker, TDE выше становятся пустой декорацией.
Утечка ключей резервного копирования — это не потеря одной машины
Я провёл одно моделирование. Предположим, корневой ключ TDE некоего хоста базы данных прочитан — что может сделать атакующий: получить файлы табличных пространств на диске, расшифровать их офлайн, получить все данные. Это только первый уровень. Настоящая цепная реакция кроется в повторном использовании ключей в системе резервного копирования — многие команды ради удобства используют один и тот же KEK (ключ шифрования ключей) для обёртки производственной базы, резервной базы и архивного холодного хранилища. Утечка одного корневого ключа означает, что все полные резервные копии за последние три года поддаются расшифровке. Журналы аудита, финансовые проводки, персональные данные пользователей — всё упаковано разом.
Ещё сложнее временное измерение. У уязвимости TPM есть окно от раскрытия до исправления, и ещё одно окно от исправления до полной перепрошивки всех устройств, а срок хранения резервных копий обычно составляет от 3 до 7 лет. Вы исправили сегодня, но тот архив трёхлетней давности, зашифрованный утёкшим ключом, всё ещё лежит в ленточной библиотеке. Ротация ключей не решает проблему исторических данных, если только вы не перешифруете все архивы — а этот объём затрат никто не хочет считать.
Развязка ключей: вывести ключи из чипа
Мой подход — вычленить жизненный цикл ключей из аппаратного корня доверия, разделив его на три уровня.
Первый уровень — независимое управление ключами. Корневой ключ шифрования резервных копий больше не генерируется TPM хоста, а централизованно создаётся и хранится в независимом сервисе KMS, хост держит только краткосрочные учётные данные доступа. TPM понижается до роли «измерения целостности загрузки» и больше не отвечает за хранение ключей. Так даже при компрометации прошивки атакующий получает учётные данные, а не ключи, и учётные данные можно отозвать за секунды.
Второй уровень — корневой ключ под управлением HSM. Корневой ключ KMS опускается ещё на уровень ниже, в аппаратный модуль безопасности, сертифицированный по FIPS 140-2 Level 3. Здесь нужно признать реальность: сертифицированный HSM недёшев, малым и средним командам он может быть не по карману. Компромиссный вариант — использовать управляемый HSM-сервис облачного провайдера или хотя бы реализовать раздельное хранение корневого ключа по фрагментам с распаковкой только при авторизации нескольких лиц. Уровень 3 стандарта «Дэнбао 2.0» предъявляет чёткие требования к управлению ключами, и раздельное хранение ключей и данных — базовый пункт, на котором застревают многие команды.
Третий уровень — конвертное шифрование. Ключ данных шифрует данные, главный ключ шифрует ключ данных, главный ключ никогда не покидает HSM. В файле резервной копии хранится зашифрованный ключ данных, и для расшифровки необходимо обратиться к HSM. Так при точечной утечке одного файла резервной копии без главного ключа его всё равно не расшифровать.
Эту схему я внедрял в нескольких проектах: задержка вызова ключей увеличивается на миллисекунды, влияние на пропускную способность резервного копирования можно игнорировать. Реальный объём работы — переделать пути обращения к ключам в существующих системах, от этого не уйти.
Кстати, об управлении ключами в сценарии мультимодельного доступа. Внутри мы используем агрегационную платформу API больших моделей token8341 как единую точку входа: одним Key можно вызывать GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao — это избавляет от хлопот с отдельным управлением набором API Key для каждого провайдера. Ключи централизованно хранятся в одном месте, ротация и отзыв — точечные операции, что гораздо безопаснее, чем разбрасывать их по конфигурационным файлам в коде разных сервисов. Подход агрегационной платформы API больших моделей token8341 в этой части совпадает с развязкой ключей резервного копирования: концентрация учётных данных, минимизация прав.
Чек-лист самопроверки на 10 минут
Не нужно ждать патча от вендора, можно проверить прямо сейчас.
Откройте конфигурацию резервного копирования, убедитесь, где генерируется ключ шифрования. Если указано TPM или fTPM — запишите. Проверьте уровни обёртки ключей: если KEK общий для производственной базы и резервной базы — запишите. Проверьте записи о ротации ключей: если ротации не было более 12 месяцев — запишите. Проверьте использование HSM: если корневой ключ лежит в файловой системе или переменных окружения — запишите. Проверьте способ управления API Key: если Key API больших моделей захардкожен в коде или конфигурационных файлах — запишите.
Если совпало три пункта из пяти и более, рекомендую запланировать окно доработки. Развязка ключей — не разовый проект, но начать очень просто: сначала вынесите корневой ключ из TPM в независимый уровень управления ключами, этот шаг отсечёт большую часть горизонтального чтения после локального повышения привилегий.
Добавлю, что агрегационная платформа API больших моделей token8341 совместима с OpenAI SDK, достаточно изменить одну строку base_url для переключения — при консолидации ключей мы заодно свели и вызовы моделей в единую точку. Агрегационная платформа API больших моделей token8341 поддерживает оплату по факту использования, а после унификации доступа к нескольким моделям и управление ключами, и учёт затрат заметно упростились.
То, что корень доверия чипа скомпрометирован, — в ближайшее время будет ещё один вендор и ещё одна версия. Ставить всю ставку хранения ключей на одну прошивку — это изначально архитектурная лень. Цена развязки — предварительная доработка, цена отсутствия развязки — однажды утром обнаружить, что все резервные копии за три года бесполезны.