Как хостер видит вашу виртуалку и что он может

MAATRIX

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

Виртуальный диск — это файл, который лежит на хранилище хоста

Когда вы создаёте VM в Proxmox, KVM, XCP-ng или любом другом гипервизоре, диск гостевой системы — это не какое-то отдельное защищённое устройство. Это файл (qcow2, raw-образ, LVM-том, ZFS zvol — в зависимости от бэкенда хранилища) на файловой системе или блочном устройстве хост-сервера. Гипервизор просто представляет этот файл гостевой ОС как виртуальный SATA/VirtIO-диск.

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

qemu-img convert -f qcow2 -O raw /var/lib/vz/images/101/vm-101-disk-0.qcow2 /mnt/extract/disk.raw

смонтировать образ через qemu-nbd или losetup + kpartx, прочитать разделы, найти файлы — если внутри VM нет полнодискового шифрования, всё содержимое видно как есть, в открытом виде. Это не эксплойт и не взлом — это штатная административная возможность гипервизора, та же самая, которая нужна для бэкапов, миграции, восстановления после сбоя.

Если внутри гостевой ОС включено полнодисковое шифрование (LUKS на Linux, BitLocker на Windows), ситуация меняется — но не полностью. Зашифрованный раздел, смонтированный офлайн (VM выключена), для стороннего наблюдателя выглядит как случайные данные — прочитать содержимое файлов без ключа нельзя. Это реальная и работающая защита от одного конкретного сценария: снятия образа диска выключенной или неактивной машины и последующего анализа офлайн.

Но LUKS/BitLocker не защищает от:

• доступа к образу диска как таковому — файл никуда не девается, его можно скопировать, унести, хранить сколько угодно;
• анализа во время работы VM — пока машина включена и раздел смонтирован, ключ шифрования находится в оперативной памяти гостевой ОС в расшифрованном виде (иначе ОС не могла бы читать/писать файлы);
• метаданных — размер диска, паттерны использования места, факт существования VM с таким-то именем и конфигурацией доступны хостеру независимо от шифрования содержимого.

Табличка для ясности, от чего реально защищает шифрование диска внутри VM:

Так что шифрование диска — правильная и нужная мера, но она закрывает конкретный класс рисков (офлайн-доступ к содержимому файлов), а не весь вопрос доверия к инфраструктуре целиком.

Снапшот работающей VM — это не только диск, но и память

Здесь начинается менее очевидная часть. Снапшот в Proxmox/KVM у работающей (не выключенной) VM с флагом --vmstate сохраняет не только состояние диска на момент снятия, но и содержимое оперативной памяти процесса QEMU, который эту VM исполняет:

qm snapshot 101 pre-update --vmstate 1

Это штатная функция, нужная для живой миграции между хостами и для восстановления машины ровно в том состоянии, в котором она была, без перезагрузки гостевой ОС. Технически это делает virsh dump или встроенный механизм QEMU, снимающий образ памяти процесса — тот самый механизм, который разбирается в статье про снапшоты в Proxmox и в материале о том, что происходит с памятью при живой миграции.

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

Ключевой технический факт: администратор гипервизора может сделать такой снапшот с работающей VM, не уведомляя и не спрашивая арендатора. Внутри гостевой ОС это никак не отражается — гипервизор просто приостанавливает vCPU на доли секунды, копирует состояние памяти на диск хоста и возобновляет исполнение. Никакого визуального или логического индикатора внутри VM не появляется. Технически это неотличимо от паузы гипервизора при обычном обслуживании хоста.

Это не значит, что каждый снапшот кто-то читает и анализирует — в подавляющем большинстве случаев снапшоты делаются автоматизированно (перед обновлением, для бэкапа) и никогда никем не просматриваются вручную. Но с точки зрения технической модели угроз это возможность, которая существует архитектурно, а не гипотетически.

Что это значит на практике — и что не значит

Важно разделить две вещи: техническую возможность и реальную практику массового добросовестного хостинга.

Возможность — реальна и следует напрямую из того, как устроена виртуализация: гипервизор управляет ресурсами гостя, и любой ресурс, которым он управляет (диск как файл, память как область адресного пространства QEMU-процесса, сетевой интерфейс как виртуальный мост), в принципе доступен на уровне хоста.

Практика — для нормального коммерческого хостера злоупотребление этим технически бессмысленно и разрушительно для бизнеса:

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

Это тот же баланс, что описан в материале про ответственность за данные при аварии у хостера: договор и репутация регулируют поведение, а не техническая невозможность действия. Разница между "хостер технически не может" и "хостеру невыгодно и запрещено" — принципиальная для правильной оценки риска. Подробнее о том, какие обязательства провайдер берёт на себя именно на уровне договора (а не архитектуры), см. статью про договор с хостером — это дополняющий, а не противоречащий взгляд на тот же вопрос.

Сетевой трафик на пути через инфраструктуру провайдера

Отдельный, хотя и не связанный напрямую с виртуализацией, аспект — сетевой путь. Трафик от вашей VM до внешнего мира на каком-то участке проходит через сетевое оборудование хостинг-провайдера: маршрутизаторы, коммутаторы, апстрим-каналы. На этом участке трафик технически может быть перехвачен средствами зеркалирования портов (port mirroring/SPAN), снятия дампа на пограничном роутере или через любой узел, где провайдер контролирует сетевое оборудование.

Здесь важно разграничить, что именно перехватываемо:

• Если у вас HTTPS/TLS с корректной настройкой (валидный сертификат, современные протоколы, HSTS) — содержимое трафика на прикладном уровне зашифровано end-to-end между клиентом и вашим сервером, и перехват на сетевом уровне провайдера даёт только метаданные: кто, когда, куда, сколько данных, но не содержимое запросов.
• Если у вас незашифрованный протокол (обычный HTTP, незащищённый SMTP, старый FTP) — содержимое трафика на сетевом пути в открытом виде, и любой, кто контролирует промежуточное сетевое оборудование, технически может его прочитать.
• Внутри одного хоста трафик между VM одного клиента и внешним миром обычно идёт через виртуальный мост (vmbr0 в Proxmox) — этот участок логически ближе всего к гипервизору и в принципе тоже наблюдаем администратором хоста.

Практический вывод простой и давно известный: TLS everywhere — не только для веб-трафика, но и для внутренних соединений между серверами, если они идут через публичную сеть или через инфраструктуру третьей стороны. Это снимает вопрос доверия к сетевому пути вне зависимости от того, кто им управляет.

Модель доверия: аренда VM — это не то же самое, что своё железо в своей серверной

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

Арендованная VM у хостинг-провайдера — принципиально другая модель: между вами и железом стоит ещё один administrative domain — сам провайдер, точнее, тот, у кого есть root на гипервизоре. Это не хуже и не лучше "само по себе" — это разные модели доверия с разными компромиссами, разобранные в статье собственный сервер безопаснее облака — миф или нет. У аренды VM есть очевидные плюсы (не нужно самому заниматься физической безопасностью, электропитанием, охлаждением, заменой дисков), но плата за них — необходимость доверять административному домену провайдера в том, что касается технических возможностей выше.

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

Практические меры, если данные действительно критичны

Если у вас есть данные, утечка которых недопустима ни при каком сценарии (медицинские записи, юридически защищённая переписка, ключи от других систем, финансовые данные с регуляторными требованиями), правильный подход — не полагаться исключительно на "провайдер обещал не смотреть", а снизить техническую поверхность атаки независимо от добросовестности провайдера:

1. Шифрование на уровне приложения, а не только диска. Если чувствительные данные шифруются самим приложением до того, как попасть на диск (например, поля базы данных шифруются на уровне ORM/приложения отдельным ключом, который не хранится на том же сервере), то даже полный дамп памяти или диска не даёт содержимого без ключа, который физически находится в другом месте — например, в HSM или KMS стороннего провайдера, отдельного от хостинга VM.

1. Разделение ключа и данных по разным доменам доверия. Ключи шифрования не должны храниться и не должны использоваться на той же машине, где лежат зашифрованные данные, если цель — защититься именно от административного домена хостера этой машины. Внешний KMS (собственный HSM, облачный KMS у другого провайдера, аппаратный токен) закрывает именно тот пробел, который LUKS/BitLocker внутри VM не закрывает.

1. Минимизация времени жизни чувствительных данных в открытом виде в памяти. Там, где возможно, приложение должно расшифровывать данные непосредственно перед использованием и не держать расшифрованную копию в памяти дольше необходимого — это снижает окно, в которое случайный или плановый снапшот памяти может что-то захватить.

1. TLS для всех сетевых соединений без исключений, включая внутренние — между приложением и базой данных, между микросервисами, даже если они физически "рядом" на одной приватной сети хостера.

1. Выбор репутационно надёжного провайдера для действительно чувствительных нагрузок. Для данных с высокими требованиями к конфиденциальности разумно смотреть не только на цену и характеристики VPS, но и на репутацию, юрисдикцию, наличие независимых аудитов (SOC 2, ISO 27001 и подобные), публичную историю инцидентов. Это не техническая гарантия, но статистически значимый фильтр — крупный провайдер с историей и репутацией, которую дорого терять, ведёт себя предсказуемо иначе, чем анонимный дешёвый хостинг без истории.

1. Физически изолированное железо для экстремальных случаев. Если требования комплаенса или модель угроз не допускают вообще никакого стороннего административного домена, единственное полное решение — собственное железо в собственной или строго контролируемой серверной, где root на гипервизоре есть только у вас. Это дороже и требует своей операционной работы, но закрывает вопрос архитектурно, а не организационно.

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

Частые вопросы