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

Сейчас все облачные платформы, построенные по принципу Cloud Native, используют виртуализацию и контейнеризацию для реализации микросервисной архитектуры. Поэтому здесь и далее мы будем говорить о безопасности виртуальных машин (VM), понимая под ними как полную виртуализацию, так и паравиртуализацию и контейнеры (Docker и т.п.). Идеалом для пользователя облака было бы получить такую же (или почти такую же) безопасность своих удаленных виртуальных машин, как при локальной работе. Как этого достичь?

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

Если у вас мало времени, можно сразу переходить к Резюме.

State of the art

Пользователь может подготовить виртуальную машину (VM) или всю архитектуру на своих компьютерах, зашифровать и передать в облако для дальнейшей работы. Однако, контейнер, начиная работать, использует для этого RAM, где данные обрабатываются в открытом виде и могут быть скопированы или изменены. Особенный риск представляют «моментальные снимки» (snapshots), которые повсеместно используются для фиксации состояния контейнера и представляют собой копию RAM и регистров CPU, ассоциированных с данной VM. При восстановлении (откате) контейнера к этому состоянию происходит обратный процесс – данные из файла загружаются в RAM и регистры.

Так было до недавнего времени, пока AMD не вывела на рынок технологию SEV^[i] (Secure Encrypted Virtualization), которая позволила шифровать данные на лету при передаче их CPU в RAM и обратно. Это позволяет создать бесшовный контекст безопасности контейнера – данные никогда не находятся в открытом виде. Данную технологию поддержали ведущие вендоры и сообщества средств виртуализации: VMware^[ii], Openstack^[iii], Kata (IBM)^[iv], Qemu^[v] и пр. Было заключено стратегическое партнерство^{[vi] [vii]} между Google и AMD с целью построения безопасных доверенных облачных сервисов. На базе этой технологии предоставляются сервисы AWS^[viii] и Azure^[ix]. Список более чем авторитетный.

Минусы технологии вытекают из ее реализации: используется симметричный шифр AES 128, при этом ключ шифрования вырабатывается и хранится в CPU (в его специальной области Secure Processor). Трудности начинают появляться, когда VM нужно переместить на другой физический сервер. В терминах VMware это^[x]:

• System Management Mode

• vMotion

• Powered-on snapshots (however, no-memory snapshots are supported)

• Hot add or remove of CPU or memory

• Suspend/resume

• VMware Fault Tolerance

• Clones and instant clones

• Guest Integrity

• UEFI Secure Boot

А ведь это те функции, за которые мы полюбили виртуализацию: гибкий автоматизируемый DevOps, отказо- и катастрофоустойчивость за счет миграции VM на другие серверы и датацентры, экономия энергии за счет концентрации работающих VM на одних серверах и отключения остальных и т.д. Таким образом, повышение безопасности привело к реальным, а не надуманным ограничениям.

Одновременно с ограничениями в удобстве необходимо помнить и о предельной нагрузке на ключ – объему информации, зашифрованному на одном ключе (большой объем данных, зашифрованных на одном ключе, может дать преимущество для злоумышленника в подборе этого ключа). CPU обменивается с RAM очень значительными объемами данных. Таким образом, ключ необходимо периодически и довольно часто менять. Можно ли получить все сразу?

Распределение ключей и безопасность с комфортом

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

Этапы миграции:

1. Создание состояния VM на 1-м сервере и запись его в общее (доступное обоим серверам) хранилище.

2. Старт VM на 2-м сервере по данным состояния из общего хранилища.

3. Синхронизация состояний двух VM по сети.

4. Передача управления и потока данных на 2-ю VM.

5. Стоп 1-й VM.

6. Пост-процедуры – удаление ненужных файлов.

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

Распределение ключей^[xi] – классическая задача в симметричных схемах шифрования (мы помним, что в SEV применяется AES – симметричный шифр). В эпоху ожидания квантового превосходства дополнительно к существующим добавляется требование квантовой стойкости – свойство алгоритма, которое не дает значительного преимущества квантовому компьютеру перед традиционным. По способу реализации квантово-стойкие алгоритмы делятся на квантовые (используются законы и явления физики) и пост-квантовые (используются математические операции). Первые имеют значительное преимущество – они имеют доказанную стойкость^[xii], которая не поменяется от появления новых вычислителей или даже научных открытий. Готовность технологии очень высокая, и оборудование доступно на рынке. Преимущество вторых состоит в простоте применения, нужно лишь сменить алгоритм распределения ключей. Однако, здесь пока нет готового продукта – национальных стандартов или стандартов отрасли, только недавно NIST отобрал кандидатов на эту роль в США^[xiii].

Quantum Key Distribution

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

Таким образом, ключ одновременно можно получить у пользователя и на сервере, где создается VM, и использовать его для шифрования. Однако, более предпочтительна схема с таким алгоритмом:

1. Сервер получает команду от пользователя на создание VM.

2. CPU генерирует ключ (1) и создает VM, шифруя аллоцированную RAM на этом ключе.

3. Одновременно с п. 3 стартует процедура QKD, в результате которой пользователь и CPU будут иметь по идентичному секретному ключу (2).

4. Далее CPU выполняет операцию XOR (сложение по модулю 2) ключей (1) и (2) и отправляет результата по любому открытому каналу пользователю.

В такой последовательности можно несколько сократить время запуска VM – не нужно ждать, пока система QKD распределит ключи.

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

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

У такого решения есть и слабые стороны:

1. QKD использует законы физики и имеет физические ограничения – около 100 км длина квантового канала. Были заявления о 1000 км^[xiv], но коммерческие реализации на сегодняшний день недоступны. Стоит ожидать, что долгое время потребителями столь безопасных сервисов будут корпорации, которые, как правило, имеют собственные служебные помещения рядом с датацентрами для физического доступа и обслуживания собственной техники. Так что для них это не будет значимым ограничением.

2. QKD – это дорого. До недавнего времени это действительно было так с ценой около €100k за комплект. Однако в нашем сценарии нужна система, которая работает на небольших расстояниях, что снижает требования к уровню техники и, соответственно, цену^[xv]. Плюс к этому технологии развиваются и растет тиражирование IP, что также приводит к снижению цены. Поэтому в самое ближайшее время можно ожидать цену около €2-3k на сервер.

3. Применяется не самый стойкий шифр AES 128. Это создает риски подбора ключа. На сегодняшний день данный риск можно нивелировать более частой сменой ключей, в перспективе стоит ожидать, что AMD и другие чипмейкеры перейдут к более стойким шифрам.

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

Оценка трендов

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

В процессе подготовки статьи мнения авторов разделились от “внедрять повсеместно” до “зачем натягивать сову на глобус”.

На сегодняшний день SEV достаточно нишевая технология и вряд ли нужна всем. У нее есть узкие области применения, но облака живут без нее давно и довольно успешно. Внедрение SEV повсеместно потребует перекроить не только функционал, но и предлагаемые облаками свойства, изобрести массу “костылей”, что сделает всё сложным и плохо поддерживаемым. Например, миграция машин, восстановление из бекапов/снепшотов (особенно если хост-машина "приказала долго жить"), горячее резервирование, репликация – все это будет в разной степени ограничено или невозможно без выхода за пределы концепции SEV. Не говоря уже о банальном vendor lock-in, ведь технология доступна только на процессорах AMD EPYC.

Важно отметить, что технология SEV позволит иначе взглянуть на Edge computing и различные “толстые” embedded решения (автомобили, например). Для работы железа в недоверенной среде это подходящая технология. К сожалению, именно для таких применений технология пока не очень готова, поскольку ее изначально позиционировали для серверных решений и ЦОДов. Надеемся, что развитие пойдет в правильном направлении, и скоро ее можно будет увидеть в этих нишах.

Что касается квантового распределения ключей (QKD), то пока технология – дорогая экстравагантная игрушка. У нее невероятные характеристики и крутые физика с математикой внутри, но есть ограничения, которые вряд ли позволят ее применять для облачных технологий повсеместно.

Реалистичные сценарии

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

• Open RAN^[xvi]. Это концепция инфраструктуры мобильных операторов, которая выросла из сложения NFV, Cloud Native и полной открытости интерфейсов, как попытка ухода от проприетарных моновендорных решений. Здесь есть компонент, управляющий NFV – MANO[xvii] (Management and Orchestration), компрометация которого означала бы потерю контроля оператором над своей сетью. Сюда же можно отнести и компоненты (VNF), реализующие функции безопасности.

• softHSM^[xviii]. Технология, которая виртуализирует святая святых криптографии – HSM. На сегодняшний день, HSM является ключевым (в прямом и переносном смыслах) компонентом при идентификации SIM-карты в сети мобильного оператора и пластиковой карты в банкомате. Излишне говорить о необходимости его защиты “насколько это возможно”.

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

Резюме

Технология AMD SEV существенно повышает уровень безопасности виртуальной инфраструктуры облаков, приближая его к случаю локальных вычислений. Ограничения, возникающие при этом, могут быть сняты применением квантового распределения ключей (QKD).

Главной альтернативой QKD остается применение пост-квантовых алгоритмов распределения ключей, когда они будут стандартизированы. При этом необходимо помнить, что стойкость квантового распределения ключей доказана математически, а пост-квантового – нет. Для последнего всегда остается риск, что в будущем будет изобретен некий алгоритм или вычислитель, который сделает его уязвимым.

Оборудование, реализующее AMD SEV и QKD, уже представлено на рынке, его цена в ближайшее время достигнет приемлемого уровня. Такое решение применимо в облачных платформах, NFV, Open RAN – в любой Cloud Native инфраструктуре.

Олег Гурин, BDM

Кирилл Лебедев, CEO

Основатели SIBlink

^[i] https://www.amd.com/en/processors/amd-secure-encrypted-virtualization

^[ii] https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-FB511CBA-4B89-469F-9799-D1347E1F2B0A.html

^[iii] https://docs.openstack.org/nova/latest/admin/sev.html

^[iv] https://lists.katacontainers.io/pipermail/kata-dev/2018-February/000029.html

^[v] https://www.qemu.org/docs/master/system/i386/amd-memory-encryption.html

^[vi] https://cloud.google.com/blog/products/identity-security/google-amd-partner-to-build-a-more-secure-future-with-confidential-computing

^[vii] https://www.amd.com/en/press-releases/2022-05-25-amd-expands-confidential-computing-presence-google-cloud

^[viii] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sev-snp.html

^[ix] https://techcommunity.microsoft.com/t5/azure-confidential-computing/azure-confidential-vms-using-sev-snp-dcasv5-ecasv5-are-now/ba-p/3573747

^[x] https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-FB511CBA-4B89-469F-9799-D1347E1F2B0A.html

^[xi] https://en.wikipedia.org/wiki/Key_distribution

^[xii] https://en.wikipedia.org/wiki/Quantum_key_distribution

^[xiii] https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022

^[xiv] https://inspirehep.net/literature/2646574

^[xv] https://epjquantumtechnology.springeropen.com/articles/10.1140/epjqt/s40507-021-00101-2

^[xvi] https://www.o-ran.org/

^[xvii] https://osm.etsi.org/

^[xviii] https://www.wikidata.org/wiki/Q58644991