Confidential Computing — класс технологий, которые изолируют код и данные во время выполнения внутри аппаратно защищённой области (TEE, trusted execution environment). Внутри TEE память шифруется, а доступ гипервизора/ядра/админов хоста существенно ограничен. Второй ключевой слой — удалённая аттестация: криптографический «доклад» о том, кто мы и что запущено, чтобы внешние системы могли условно доверять экземпляру и, например, выпускать ему ключи.
Связанные страницы: Privacy-preserving AI (FHE/SMPC/zkML), Model serving, Model evaluation, Evals, Prompt injection, Prompt leakage, Model poisoning, KV cache, Prefill cache, Retriever, Vector index.
Модель угроз (зачем это нужно)
- Враждебный инфраструктурный слой. Даже если облако/хост доверенное, гипервизор, root на хосте, DMA-устройства — всё это потенциальные источники утечек.
- Инсайдеры и поставщик облака. TEE снижает необходимость «верить» оператору, поскольку память и состояние гостя шифруются и проверяются.
- Комплаенс и мульти-тенантность. Разделение клиентов на одном железе без взаимных утечек.
- Доказуемость конфигурации. Аттестация позволяет связывать выпуск секретов с измеренным кодом/параметрами запуска (policy).
Основные семейства TEE (обзор)
| Семейство/подход | Кратко | Где применяется | Особенности |
|---|---|---|---|
| Intel SGX | Энклавы в адресном пространстве процесса | bare-metal/VM, on-prem | Мелкозернистая модель, страница EPC; традиционно — DCAP/EPID/EC-аттестация |
| Intel TDX | Изоляция целой гостевой VM (TD-VM) | облака/виртуализация | Шифр. память VM, ограничение привилегий VMM; аттестация «всей ВМ» |
| AMD SEV-SNP | Шифрование памяти VM с проверкой целостности | облака (KVM) | «Госте-ориентированная» изоляция; SNP-аттестация |
| ARM CCA (Realm) | Реалмы в аппаратной модели ARMv9 | edge/мобайл/сервер | Аппаратные реалмы вне NS/secure worlds; аттестация realm |
| AWS Nitro Enclaves | Изолированные окружения на базе Nitro | AWS | Виртуализационный TEE без доступа в сеть/диск, обмен через vsock |
| TPM (не TEE) | Дискретный модуль доверия | ПК/серверы | Хранение ключей/измерения загрузки (PCR); не исполняет ваш код «внутри» |
*Важно:* TPM — это корень доверия и хранилище ключей, а не среда выполнения. HSM — тоже не TEE (защищённые ключи, но не ваш процесс).
Как TEE обеспечивает конфиденциальность и целостность
- Шифрование памяти (per-VM/per-enclave keys) и защита от чтения хостом/DMA.
- Измеренная загрузка: вычисляется хэш (меры) кода/конфига, который попадает в отчёт аттестации.
- Изоляция от VMM/ядра: гипервизор видит «гостя» как чёрный ящик; управляет ресурсами, но не содержимым.
- Sealing: локальное шифрование артефактов «на диск»/в хранилище с привязкой к идентичности TEE.
Аттестация 101: что проверяют внешние системы
Аттестация — это протокол, по которому TEE формирует отчёт (quote/report), подписанный аппаратным корнем доверия. Этот отчёт содержит:
- Платформенные измерения и идентификаторы (версия микрокода/фьюзы/сертификаты).
- Меры гостя: хэш образа/инициирующего кода, значения политики (например, флаги «без отладки»).
- Challenge/nonce от верификатора, чтобы исключить повтор.
Далее верификатор проверяет цепочку сертификатов производителя (или облачного аттестационного сервиса), сверяет меры/политику, и при соответствии выпускает сессионные секреты (ключи/токены), шифруя их под ключ TEE.
Типовой поток:
- Приложение в TEE генерирует CSR/ключ и запрашивает quote.
- Отправляет quote в attestation service (вендор/облако/собственный верификатор).
- Верификатор проверяет подпись/флаги/меры, сопоставляет с политикой.
- Если OK — выдаёт attestation token (JWT/COSE/вендорный формат) или секрет, зашифрованный для TEE.
- Приложение в TEE использует секрет (TLS, доступ к БД, расшифровка весов).
Политики выпуска секретов
- «production mode only»: отладка/трассировка выключены.
- MRENCLAVE/мера образа совпадает со списком разрешённых.
- Anti-rollback: минимальные версии микрокода/схем.
- Geo/валидаторы: секреты выдаются только в определённых регионах/кластерах.
Аттестационные токены и сервисы (концептуально)
- SGX DCAP / ECDSA quotes: цепочка до Intel Root; в облаках — прокси-сервис провайдера.
- TDX: quote для всей ВМ; политика на образ/загрузчик/включённые устройства.
- SEV-SNP: report с полем guest_svn и хешем; проверка у AMD/облака.
- ARM CCA: realm-report и провайдерские верификаторы.
- Nitro Enclaves: AWS ATS (KMS policy «key for enclave attestation»), выпуск данных через KMS под аттестованный identity.
Форм-факторы: COSE/JWT (удобно в веб-интеграциях), двоичные вендорные структуры, x.509 расширения для привязки к TLS (mTLS с подтверждением TEE).
Sealing, ключи и «запечатанные» артефакты
Sealing — локальное шифрование данных (веса модели, токены, кэши) ключом, привязанным к идентичности TEE (мера/политика/платформа). Это даёт:
- Отсечку хищения дисков (без TEE расшифровки нет).
- Привязку к версии: sealed-данные читаются только «в совместимой конфигурации».
Практика: храните sealed-веса/секреты в объектном хранилище; при старте TEE проходит аттестацию и сам раскрывает секреты, не выдавая их наружу в явном виде.
Measured boot vs secure boot vs TPM
- Secure boot проверяет подписи загрузчика/ядра.
- Measured boot *измеряет* каждый этап и сохраняет хэши в PCR (TPM), что позже можно предъявить.
- TEE-отчёт содержит меры гостя и платформы, являясь «срезом» доверия на момент выдачи.
Комбинация полезна: secure boot → measured boot → TEE attestation.
Как TEE помогает ИИ/LLM-нагрузкам
- Защита весов модели (коммерческая тайна) и промптов от админов/соседних арендаторов.
- Выпуск API-ключей и доступов к источникам (RAG-хранилища) только после аттестации (policy-based key release).
- Шифрование KV-кэша и изоляция prefill-кэша в памяти TEE; исключаем «шаринг» между уровнями доверия.
- mTLS-идентичность «модель-как-сервис»: клиент убеждается, что общается с аттестованной сборкой.
Где TEE лучше, а где — FHE/SMPC/zkML
| Задача | TEE (Confidential Compute) | FHE/SMPC/zkML |
|---|---|---|
| Защита от админов/гипервизора при разумной латентности | Сильная сторона: нативная скорость | FHE/zk — слишком медленно в генерации; SMPC — сеть/кворум |
| Доказуемость корректности вычислений третьим лицам | Аттестация ≠ доказательство результата | zkML выигрывает (SNARK/STARK) |
| «Один-провайдер» без кворума | Работает «в одиночку» | SMPC требует несколько сторон |
| Приватность входов/весов «абсолютно» | Хорошо, но доверяем кремнию | FHE даёт «шифрованную» математику |
| Массовый LLM-чат с длинными окнами | Практичен (в рамках SLO) | FHE/SMPC — точечно, гибридом |
См. также обзор: Privacy-preserving AI.
Паттерны интеграции TEE в LLM-стек
1) Attested Key Release (AKR) для RAG
- Индекс/БД выдают токен/доступ только при предъявлении валидного attestation-токена.
- Политика привязывает доступ к «модели X, сборке Y, флагам Z, региону R».
- Ответы LLM ссылаются на источники (см. retriever, vector index); источники читаются через attested-канал.
2) Sealed Weights
- Веса LLM/адаптеров (LoRA) лежат в хранилище в запечатанном виде.
- При старте enclave получает ключ через AKR, локально расшифровывает и хранит в защищённой памяти.
3) Attested mTLS
- Сертификат TLS включает расширение/подпись на attestation-токен.
- Клиент проверяет не только x.509, но и политики enclave (production, no-debug).
4) Изоляция кэшей
- Prefill/KV кэши разделяются на уровни доверия; запрет переиспользования префиксов между разными клиентами/ключами.
5) Observability без утечек
- Логируйте метаданные (время, p95, токены), но не сырой контент (уменьшаем PLR).
Производительность и стоимость
- Накладные расходы TEE: шифрование памяти, переходы в/из enclave, ограничения на системные вызовы.
- Виртуализационные TEE (TDX/SEV-SNP/Nitro) обычно лучше масштабируются для LLM-сервисинга, чем «процессные» энклавы.
- Планирование (см. model serving): учитывайте p95/p99, tokens/s, давление на память (KV), NUMA/пиннинг, эффективный paged KV.
Безопасность: что TEE не решает
- Логический уровень приложения: jailbreak-промпты, небезопасное использование инструментов, выдача PII.
- Side-channels (временные/кэши/контеншн): снижаются планировщиком/шумом/пинингом, но не исчезают.
- Качество модели: галлюцинации, отсутствие цитирования (нужны evals и guardrails).
- Supply-chain: заражённые веса/адаптеры (см. model poisoning); требуются подписи артефактов.
Практический чек-лист (прод)
- Аттестация:
- Определите политику (меры, флаги, регионы, версии).
- Схема AKR: KMS/выпуск секретов только по валидному attestation-токену.
- mTLS с привязкой к аттестации; ротация ключей/сертификатов.
- Данные/веса:
- Sealed хранение; подписанные артефакты; контроль целостности на загрузке.
- Разделение кэшей и запрет «шаринга» префиксов между клиентами.
- Пайплайн:
- Guardrails на ввод/вывод; политика «данные ≠ инструкции» для RAG.
- Лимиты токенов/времени; контроль инструментов (JSONSchema, белые списки).
- Наблюдаемость:
- Метрики p50/p95/p99, tokens/s, KV-footprint, отказ/принятие запросов.
- Без «сырых промптов» в логах; алерты на рост PLR/ASR (см. Evals).
- Процессы:
- Регулярные security-evals (prompt-инъекции, leakage, supply-chain).
- Процедура отката версии и отзыв ключей при инцидентах.
Анти-паттерны
- «TEE = можно не думать о приложении». Нет: логика безопасности и валидации обязательна.
- «Сырые ключи в образе». Любые секреты должны приходить после аттестации.
- «Общий KV-кэш для всех». Это риск утечки между клиентами.
- «Отладочный режим в проде». Запретите debug-флаги; добавьте в политику.
- «Не подписываем веса/LoRA». Supply-chain остаётся большой угрозой.
Как проверять и оценивать (evaluation)
- Security-evals:
- ASR на prompt-инъекции (прямые/косвенные, RAG-инъекции).
- PLR на самораскрытие промптов/секретов.
- Тест на AKR-политику: попытки получить секрет без валидной аттестации.
- Проверки на «debug-режим»/rollback.
- Performance:
- Измеряйте влияние TEE на p95, throughput, tokens/s; отдельно prefill/decode.
- Отслеживайте footprint KV в ограниченной памяти энклавы/гостя.
- Observability-гигиена:
- Никаких сырьевых промптов/секретов в телеметрию; только агрегаты/хэши артефактов.
Часто задаваемые вопросы (FAQ)
Это «железная» безопасность?
TEE снижает риски на уровне хоста/гипервизора, но не отменяет уязвимости приложений и побочные каналы. Используйте вместе с guardrails и evals.
Можно ли хранить веса целиком в TEE?
Да, через sealed-артефакты + AKR. Если веса велики — используйте потоковую расшифровку и подкачку, учитывая память и p95.
Какой TEE выбрать для LLM-сервиса?
Для кластерной эксплуатации — виртуализационные TEE (TDX/SEV-SNP/Nitro). Для edge/ARM — CCA. SGX уместен для изолированных функций/секций.
Отличается ли аттестация от обычного TLS?
TLS доказывает «владение ключом». Аттестация доказывает конфигурацию исполнения (меры, флаги). В паре (mTLS+attestation) доверие заметно выше.
Защитит ли TEE от утечки промптов?
TEE защитит хранение/исполнение, но не «болтливость» модели. Нужны политики против prompt leakage и фильтры вывода.
FHE/SMPC не лучше?
Их сильные стороны — крипто-приватность и/или верифицируемость, но накладные расходы высоки. TEE — практичный компромисс для прод-нагрузок сегодня. См. обзор.
Мини-глоссарий
- TEE — аппаратно поддерживаемая доверенная среда выполнения.
- Enclave/Realm/TD-VM — экземпляры изолированного окружения в разных реализациях.
- Attestation (удалённая аттестация) — проверяемый отчёт о платформе/коде/политике.
- Sealing — шифрование артефактов с привязкой к идентичности TEE.
- Measured boot — накопление хэшей загрузки для доказуемости.
- AKR (Attested Key Release) — выпуск секретов по политике аттестации.
- Production/No-Debug — флаги, запрещающие отладку/трассировку.
- Root of Trust — крипто-основание для подписи отчётов.