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

Конфиденциальные вычисления обеспечивают аппаратную изоляцию кода и данных внутри доверенной среды выполнения. Эта модель уже применяется в российских проектах: в пилотных проектах Ассоциации ФинТех, в распределённой медицинской аналитике, в рамках импортонезависимых облачных платформ. Актуальные требования к обезличиванию данных, рекомендации ЦБ по защищённой аналитике и курс на цифровой суверенитет делают технологию особенно востребованной. В частности, интерес к ней усилился после принятия Федерального закона № 233-ФЗ от 8 августа 2024 года, который ввёл нормы об обращении с обезличенными персональными данными.

Что такое конфиденциальные вычисления

Confidential Computing, или конфиденциальные вычисления, — это защита данных в процессе вычислений, с использованием доверенных сред исполнения, или Trusted Execution Environments. Обычно используют сокращение TEE. Ключевая идея заключается в том, чтобы создать аппаратно-изолированную среду, внутри которой данные шифруются и обрабатываются так, чтобы не быть доступными ни ОС, ни гипервизору, ни самому провайдеру.

Доверенная среда реализуются на уровне процессора Intel SGX, AMD SEV, Arm TrustZone и др. У каждой архитектуры свои ограничения и нюансы. Например, у SGX это жёсткие лимиты по объёму защищённой памяти, у SEV — зависимость от уровня доверия к прошивке платформы и PSP.

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

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

Почему растёт интерес к конфиденциальным вычислениям

Требования регуляторов становятся строже. GDPR, HIPAA и 152-ФЗ задают требования к защите персональных данных; DSA регулирует обязанности онлайн-платформ и работу с незаконным контентом; DORA описывает управление ICT-рисками и устойчивость ИТ в финансовом секторе. Простого шифрования на диске или TLS уже недостаточно. Уязвимыми остаются инфраструктура, гипервизор и сам провайдер. Регуляторы требуют технических доказательств изоляции данных на всех стадиях, включая исполнение.

Компании чаще обсуждают, как контролировать доступ к данным в облаке. Большинство критичных сервисов давно вынесены, например, в AWS, Azure и GCP. При этом у организаций, размещающих чувствительные данные, нет механизмов верификации: кто и как может получить доступ к памяти, где обрабатываются данные? Поэтому вендоры добавляют поддержку доверенной среды: в Azure — виртуальные машины серий DCsv2, DCsv3 и DCdsv3 для Intel SGX-enclave, в AWS — Nitro Enclaves, в GCP — Confidential VM. Использование таких решений выходит за рамки прототипов: это реальные эксплуатационные настройки в банках, госсекторе, фарме.

Усложнились сценарии кооперации. Совместные модели машинного обучения, партнёрские аналитические расчёты, федеративное обучение, обработка данных в совместных конфиденциальных вычислениях — всё это требует архитектуры, в которой можно обрабатывать данные, не раскрывая их ни одной из сторон. Без доверенной среды или похожих механизмов такую задачу не решить без сложной криптографии, вроде FHE или MPC: FHE — полностью гомоморфное шифрование, MPC — многосторонние вычисления. Оба подхода могут быть тяжелее по производительности. 

Эволюция атак вышла за пределы приложен��й. После Spectre/Meltdown стало ясно, угрозы всё чаще затрагивают микрокод, прошивки и уровень гипервизора. Актуальны атаки по сторонним каналам и др. Ответом на это стало развитие аппаратных методов контроля доверенной среды исполнения, где целостность проверяется железом.

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

Как устроены доверенные вычисления

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

Но у подхода есть нюансы.

Аппаратный уровень

На аппаратном уровне применяются разные подходы к созданию доверенной среды исполнения.

У Intel это SGX — выделенный enclave внутри процессора обычно с объёмом EPC до 128–256 МБ. Такой механизм требует адаптации софта под Enclave SDK, особого контроля аллокаторов и работы с ECALL/OCALL. Прозрачности здесь нет, но зато обеспечивается контроль над полным стеком.

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

Arm идёт по своему пути. TrustZone реализует двухрежимную архитектуру — Secure и Normal World. Она чаще встречается в мобильных устройствах, но уже есть решения на серверных SoC, особенно в нишах, где важна лёгкая интеграция доверенной среды на ARM-платформах.

Инструменты и SDK

В экосистеме конфиденциальных вычислений ключевую роль играют инструменты разработки — SDK и фреймворки, позволяющие запускать приложения в изолированной среде. Под Intel SGX используется целый набор решений: от базового Intel SGX SDK до более высокоуровневых подходов вроде Open Enclave SDK, Gramine или SCONE. Каждый из них решает задачу по-своему. Где-то разработчику приходится писать под специфичный ABI, а где-то можно обойтись практически без модификаций, «завернув» стандартное POSIX-приложение в доверенный рантайм.

Если говорить об AMD SEV, то здесь всё проще: достаточно развернуть обычную виртуальную машину с нужными параметрами, например, через libvirt с флагами sev или sev-es. Код не требует изменений, а изоляция обеспечивается на уровне гипервизора и памяти.

Помимо запуска приложений важным компонентом является attestation — механизм удалённой проверки целостности и подлинности кода внутри enclave. Сторона, инициирующая запрос, должна быть уверена, что работает именно с той логикой, на которую рассчитывает. Для этого используются токены, подписанные платформенными ключами. У Intel SGX-аттестацию поддерживает, например, компонент Quoting Enclave. Такая процедура позволяет выстроить в распределённой системе доверие даже между незнакомыми участниками.

Поддержка у облачных провайдеров

В экосистеме облачных провайдеров поддержка конфиденциальных вычислений реализована по-разному. В Azure Confidential Computing используется Intel SGX — доступны типы виртуальных машин DCsv2 и DCsv3, с возможностью удалённой аттестации и интеграцией с Azure Key Vault. 

AWS предлагает Nitro Enclaves — это отдельная виртуальная машина, которую создают из ресурсов родительского EC2-экземпляра, отделенная от «родителя», не имеет доступа к интернету и взаимодействует только через VSOCK, а ключи при этом управляются через KMS.

В Google Cloud Confidential VM используют аппаратные механизмы, например AMD SEV, AMD SEV-SNP или Intel TDX — в зависимости от конфигурации — такой подход прозрачен для приложений, но требует доверия к самой платформе GCP, так как контроль остаётся на уровне провайдера.

Выбор между этими решениями часто сводится к балансу между уровнем изоляции, удобством интеграции и затратами на поддержку. SGX даёт максимальный контроль, но требует серьёзной доработки приложений. SEV проще в применении, но оставляет вопросы к модели доверия. TrustZone, хоть и менее распространён в серверных облаках, остаётся рабочим решением в нишевых задачах, особенно на ARM-платформах.

Где уже работают доверенные вычисления

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

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

При работе с моделями машинного обучения доверенная среда позволяет проводить инференс на конфиденциальных входных данных (например, диалоги пользователей, CRM-записи), не раскрывая их ни провайдеру, ни вендору модели. Это позволяет создавать приватные ИИ-сервисы без риска компрометации.

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

Преимущества и ограничения

Почему это работает:

  • Минимизация доверия к инфраструктуре. Доверенная среда гарантирует, что код и данные не может просматривать ни облачный оператор, ни DevOps, ни вредоносная прошивка. Даже если злоумышленник захватит root на хосте — из enclave он ничего не достанет.

  • Соответствие нормативке. Когда регулятор просит «гарантировать защиту данных при обработке», доверенная среда — один из немногих технически верифицируемых способов соблюдения этого требования. Это упрощает аудит и внедрение в «чувствительные» вертикали — в финансах, здравоохранении и госсекторе.

  • Облегчение взаимодействия между сторонами. В совместных конфиденциальных вычислениях участники могут получать совместные выводы, не создавая общий data lake. Всё происходит в enclave, без раскрытия данных между сторонами. Это снижает риски и сложность согласований между участниками.

Какие возникают трудности:

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

  • Ограничения по ресурсам. Объём памяти для enclave ограничен (EPC для SGX — порядка 128–256 МБ), что бьёт по производительности. Придётся оптимизировать, выносить часть логики наружу или использовать SGX2 с динамическим аллокатором.

  • Производительность. Шифрование памяти, аттестация, изоляция — всё это влечёт накладные расходы, и для некоторых задач это критично.

  • Модель доверия не универсальна. У SEV, например, есть зависимость от уровня доверия к AMD Platform Security Processor, сокращённо PSP. Это отдельный защищённый процессор на платформе AMD. При компрометации прошивки защита может быть снята. Не все готовы закрыть на это глаза.

  • Инфраструктура. Не все ЦОДы и облака поддерживают хосты с доверенной средой. Например, Nitro Enclaves в AWS ограничены определёнными типами instance. Планировать приходится заранее.

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