Когда вы арендуете GPU, root на машине с вашими данными есть у кого-то другого. Шифрование защищает датасет по пути и пока он лежит на диске, но задаче обучения нужно расшифровать его в памяти, и в этот момент настойчивый хост может его прочитать. Поэтому настоящие решения такие: кому вы доверяете (проверенному дата-центру или анонимному домашнему серверу), как мало данных вы отправляете и нужны ли вам конфиденциальные вычисления — единственный вариант, который убирает оператора хоста из цепочки доверия.
Это руководство — про машины, на которые вы заходите сами, например инстансы на Vast.ai или RunPod. В нём разобраны модель угроз, что закрывает каждая мера защиты и порядок очистки, который работает на современных накопителях. Источники — в конце; всё проверено в сентябре 2026 года.
Модель угроз
Начните с того, кто может добраться до данных и как. У арендованного GPU-инстанса семь реалистичных путей.
Оператор хоста. У владельца физической машины есть на ней root. На контейнерном маркетплейсе вроде Vast.ai клиенты работают в непривилегированных Docker-контейнерах: это изолирует вас от других арендаторов, но не от хоста — root на хосте может читать файлы и память контейнера. Так контейнеры устроены на любой платформе.
Сетевой путь. Данные идут с вашего ноутбука или из бакета на узел. Этот путь закрыть проще всего.
Платформа-маркетплейс. У компании между вами и хостом хранятся ваш аккаунт, ваши SSH-ключи и всё, что остаётся в её собственных логах. Что она может с этим делать, определяют её условия — поэтому раздел о договорах ниже так важен.
Остатки на диске. Удалённые файлы могут пережить аренду и остаться на диске, где их найдёт следующий арендатор или хост.
Снимки и постоянные тома. Копии, о которых вы просили сами (сетевой том, остановленный инстанс) или которые сделал хост (резервные копии), живут дольше задачи.
Другие арендаторы. Другие клиенты на той же машине. При изоляции через ВМ или целой машине в вашем распоряжении этот риск мал, но у GPU здесь бывали настоящие уязвимости. LeftoverLocals (CVE-2023-4969) позволяла одному процессу читать локальную память GPU другого процесса на некоторых GPU Apple, AMD и Qualcomm; Trail of Bits восстанавливала около 181 МБ на один запрос к LLM на AMD Radeon RX 7900 XT — достаточно, чтобы восстановить ответ модели. На GPU NVIDIA, ARM и Intel Trail of Bits признаков уязвимости не нашла.
Ваши же хвосты. Токен Hugging Face, облачные ключи или закрытый SSH-ключ, забытые на узле. На практике большинство утечек начинается именно так.
Что закрывает шифрование, а что нет
У шифрования три задачи, и на арендованном GPU две из них вы можете решить сами.
При передаче: просто. Используйте SSH (scp, sftp, rsync -e ssh) или HTTPS из бакета. Vast.ai заявляет, что соединения SSH и его API зашифрованы. Никогда не используйте обычные HTTP-ссылки и файлообменники без аутентификации.
При хранении: шифруйте до загрузки, чтобы файл на диске хоста был бесполезен без ключа. Проще всего это сделать с помощью age:
# on your own machine
tar -cf - train/ | age -p > train.tar.age
scp -P 22345 train.tar.age [email protected]:/workspace/На узле расшифровывайте прямо в память, чтобы открытый текст никогда не касался диска:
mkdir -p /dev/shm/train
age -d /workspace/train.tar.age | tar -xf - -C /dev/shm/trainage -d спрашивает пароль в терминале, так что ключ никогда не записывается на узел. /dev/shm — файловая система в оперативной памяти; сначала проверьте её размер командой df -h /dev/shm, потому что в контейнерах её часто делают маленькой. Если данные не помещаются в RAM, понадобится расшифрованная копия на диске, и тогда раздел об очистке ниже становится важнее.
Полное шифрование диска через LUKS — обычное решение на своих серверах, но внутри непривилегированного контейнера dm-crypt, как правило, не настроить, да и рабочий ключ всё равно был бы у хоста.
При использовании: вот где дыра. Для обучения GPU нужны тензоры в открытом виде, и память CPU, которая их подаёт, тоже содержит открытый текст. Любой с root на хосте в принципе может сделать дамп этой памяти. Шифрование при хранении ничего не даёт против враждебного хоста во время работы. С этим справляются только аппаратные конфиденциальные вычисления.
Secure Cloud или Community Cloud
Хост — единственный риск, который гигиена не убирает, поэтому выбор хоста — самое важное ваше решение. Два крупных маркетплейса именно поэтому делят свои мощности.
| Вариант | Кто управляет железом | Что пишет платформа |
|---|---|---|
| RunPod Secure Cloud | Дата-центры T3/T4 | Для «продакшена и чувствительных данных» |
| RunPod Community Cloud | Одноранговые провайдеры | Для «нагрузок, где важна цена»; новые хосты не принимаются |
| Vast.ai Secure Cloud | Проверенные дата-центры | ISO 27001, стандарты Tier 3/4, проверенная физическая безопасность |
| Прочие хосты Vast.ai | От дата-центров до частных лиц | У частных хостов «меры безопасности могут быть менее формальными» |
Для чувствительных данных Vast.ai сам советует пользоваться только провайдерами Secure Cloud, шифровать данные при хранении, не держать учётные данные на инстансах и использовать внешнее управление ключами. Ровно это я бы посоветовал любому.
Даже в сертифицированном дата-центре есть два ограничения. Во-первых, ISO 27001 сертифицирует процессы оператора; нечестного сотрудника она не исключает. Во-вторых, хост, который обрабатывает для вас персональные данные, по GDPR — обработчик, и статья 28 требует договора с ним, а между вами и хостом стоит маркетплейс. Выясните, с какой компанией вы на самом деле заключаете договор и что она обещает насчёт своих хостов.
Для по-настоящему чувствительной работы следующая ступень — GPU-инстанс у крупного облачного провайдера, с которым у вас уже есть DPA и, возможно, BAA. Это выводит вас за пределы маркетплейсов и стоит дороже в час. Диапазоны цен — в нашем сравнении цен на аренду GPU.
Конфиденциальные вычисления на H100
Конфиденциальные вычисления (CC) — единственная технология из перечисленных, которая задумана для защиты данных от оператора хоста во время работы задачи. На GPU NVIDIA Hopper и Blackwell для дата-центров это устроено так:
- Нагрузка работает в конфиденциальной ВМ (CVM) на базе AMD SEV-SNP или Intel TDX на CPU. Архитектура NVIDIA исходит из того, что гипервизор и ОС хоста могут быть скомпрометированы; оператор с доступом к гипервизору «или даже к самой системе» не должен иметь возможности прочитать память CVM.
- Перед использованием ВМ проверяет, что GPU подлинный и работает в режиме CC с подписанным сертификатом устройства, который можно сверить через NVIDIA Remote Attestation Service (NRAS).
- Данные, буферы команд и ядра CUDA, идущие по PCIe, шифруются и подписываются и проходят через зашифрованный промежуточный буфер в общей памяти.
NVIDIA открыла общий доступ к CC на одном H100 с CUDA 12.4 в апреле 2024 года. Где её реально можно арендовать на сентябрь 2026 года:
| Облако | Инстанс | GPU | TEE на CPU |
|---|---|---|---|
| Azure | NCCads H100 v5 | 1 × H100 NVL, 94 ГБ | AMD SEV-SNP (EPYC Genoa) |
| Google Cloud | a3-highgpu-1g, Confidential VM | 1 × H100 | Intel TDX |
| Google Cloud | g4-standard-48, Confidential VM | RTX PRO 6000 | AMD SEV |
Прежде чем на это опираться, учтите ограничения:
- Один GPU на ВМ. В серии Azure один GPU, а конфиденциальные GPU-ВМ Google не поддерживают многоузловые кластеры. Большие запуски обучения на нескольких GPU отпадают.
- Выделение ресурсов. В Google Cloud конфиденциальные A3 High работают только как Spot или flex-start и не поддерживают резервирование.
- Скорость передачи. В техническом обзоре NVIDIA 2023 года пропускная способность между CPU и GPU в режиме CC оценивалась примерно в 4 ГБ/с — её ограничивает шифрование на CPU. Загрузка чекпоинта на 16 ГБ занимает около 16 ÷ 4 = 4 секунд чистой передачи; для инференса это нормально, но конвейер данных, который гонит много гигабайт на каждом шаге, это почувствует. В более поздних версиях драйверов заявлены улучшения производительности, так что замерьте свою задачу.
- Память GPU не шифруется. NVIDIA оставляет HBM на подложке в открытом виде, исходя из того, что распространённые инструменты физических атак до неё не дотягиваются.
- Не на маркетплейсах. Потребительских карт GeForce, которые обычно стоят у хостов Vast.ai и RunPod Community Cloud, нет ни в одном из этих списков поддерживаемого.
CC меняет то, кому приходится доверять: вместо персонала хоста — железу и аттестации NVIDIA, производителю CPU и собственному образу ВМ. Для регулируемых данных, где важен ответ «администраторы облачного провайдера не могут это прочитать», это единственный вариант на арендованном железе, который к такому ответу приводит.
До и во время задачи
Сократите данные до загрузки
Самая дешёвая защита — данные, которые никогда не покидают вашу машину. Перед передачей:
- Уберите столбцы, которые модели не нужны, особенно имена, email, номера счетов и свободные текстовые заметки.
- Замените прямые идентификаторы случайными токенами, а таблицу соответствия держите у себя.
- Урежьте корпус до того, что нужно методу. Дообучение через LoRA или QLoRA настраивает небольшой набор дополнительных весов, и целая рабочая база данных ему нужна редко; реалистичная конфигурация разобрана в нашем руководстве по дообучению.
- Помните, что веса модели несут информацию. Модель, дообученная на чувствительных текстах, может повторять их фрагменты, поэтому адаптер тоже считайте чувствительным.
Кроме того, именно обезличенные данные снимают большинство юридических вопросов, о которых ниже.
Учётные данные и сеть на узле
Исходите из того, что всё, что вы кладёте на узел, могут скопировать.
- Используйте fine-grained токен Hugging Face с правом чтения только того репозитория, который нужен, и отзовите его, когда задача закончится.
- Никогда не копируйте на арендованную машину свой основной закрытый SSH-ключ, корневые облачные учётные данные или пароли от рабочих баз данных. Если задача должна записывать результаты в бакет, создайте ключ, который может писать только в один префикс и истекает в течение суток.
- Забирайте результаты по SSH, а не отправляйте их с узла долгоживущими ключами.
- Проверьте, что слушает порты, командой
ss -tulnp. Привяжите Jupyter, TensorBoard и серверы инференса к127.0.0.1и подключайтесь к ним через SSH-туннель (ssh -L 8888:127.0.0.1:8888 ...), а не открывайте публичный порт.
Очистка, которая работает на современных дисках
Обычный совет — пройтись по датасету shred, когда закончили. Он делает не то, что думают. В руководстве GNU coreutils сказано, что shred рассчитывает на то, что файловая система и железо перезаписывают данные на месте, и перечислены случаи, когда это не так: журналируемые и лог-структурированные файловые системы, например ext4 в режиме data=journal, Btrfs, XFS и ZFS, RAID, файловые системы со снимками, сжатые файловые системы и SSD, которые из-за выравнивания износа пишут новые данные в другое место. Арендованный GPU-узел почти наверняка попадает сразу в несколько из этих случаев.
Что работает вместо этого:
- Сделайте копию на диске бесполезной. Если диска касался только архив, зашифрованный age, достаточно его удалить; без пароля это шум. Руководство NIST по очистке носителей (SP 800-88 Rev. 2, сентябрь 2025) рассматривает этот подход, криптографическое стирание, как стандартный метод.
- Уничтожайте, а не останавливайте. На Vast.ai остановка инстанса сохраняет его данные (и продолжает тарификацию хранилища), а уничтожение «безвозвратно удаляет инстанс и все данные». На RunPod диск контейнера очищается при остановке пода, том
/workspaceпереживает остановку и удаляется при terminate, а сетевой том переживает всё, пока вы его не удалите. - Удалите созданные сетевые тома. Они по замыслу живут дольше подов.
- Отзовите то, чем пользовались. Токен Hugging Face, ключи бакетов, а также удалите одноразовый открытый SSH-ключ, который добавляли на маркетплейс для этой задачи.
Как хост очищает диски между арендаторами, в прочитанной мной документации маркетплейсов не описано. Исходите из того, что никак, — шаг 1 защищает вас в любом случае.
Договоры и регулирование
Технические меры значат меньше, чем один юридический факт: разместив данные на чужой машине, вы делаете её владельца участником обработки.
- GDPR. GPU-хост, который обрабатывает для вас персональные данные, — обработчик. Статья 28 требует обработчика, дающего «достаточные гарантии», и обязывающего договора. Одноранговый хост, с которым вы ничего не подписывали, этому не соответствует, а машина может находиться за пределами ЕС. Обезличивайте данные или берите провайдера, который подписывает DPA.
- HIPAA. HHS указывает, что облачный провайдер, хранящий электронные медицинские данные, является business associate, даже если данные зашифрованы и ключа у него нет. Шифрование медицинских записей перед отправкой непроверенному хосту не отменяет необходимости в BAA.
- Договоры с вашими клиентами. Многие корпоративные соглашения ограничивают субподрядчиков и место хранения данных. Проверьте их до первой загрузки. Юридический риск часто больше технического.
Те же правила со стороны чат-сервисов разобраны в соседней статье о том, почему компании ограничивают публичные AI-инструменты.
Инференс на GPUFlow: другой компромисс
GPUFlow — не место для датасета. Это маркетплейс инференса: вы арендуете GPU по часам и получаете OpenAI-совместимый API-ключ (базовый URL https://gpuflow.app/v1) к открытой модели, которую провайдер запускает (обычно через Ollama) на своём собственном компьютере. Нет ни SSH, ни командной оболочки, ни доступа к файлам, и обучать или дообучать там нельзя. На диске провайдера не лежит ничего вашего, потому что загрузить туда ничего нельзя.
Это снимает проблемы с дисками и учётными данными из этого руководства. Проблему хоста это не снимает. Пока идёт аренда, каждый промпт и ответ проходит через машину провайдера в открытом виде. Условия GPUFlow запрещают провайдерам записывать, читать, хранить и передавать их, и сам GPUFlow текст не хранит, но у провайдера root на машине, так что правило держится только на договоре. Если прогнать через него датасет по записи на промпт, каждая запись окажется на этом компьютере.
Поэтому используйте его для публичных, синтетических или правильно обезличенных данных и для проверки открытой модели или приложения на API в стиле OpenAI. Регулируемые и конфиденциальные записи держите на своём железе, у провайдера, с которым у вас есть договор, или в конфиденциальной ВМ. В быстром старте с API то же самое сказано одной строкой: не отправляйте пароли, номера карт и другие секреты, которыми не поделились бы с незнакомым человеком. Та же схема со стороны провайдера — в статье безопасно ли сдавать видеокарту в аренду.
Чек-лист
До:
- Определите класс данных. Регулируемые данные и данные, конфиденциальные по договору с клиентом, отправляются провайдеру с договором или в конфиденциальную ВМ, а не на хост из Community Cloud.
- Сократите и обезличьте.
- Зашифруйте через age; пароль на узел не попадает.
Во время:
- Расшифровывайте в
/dev/shm, если помещается. - Только узкие токены с коротким сроком жизни.
- Сервисы привязаны к localhost, доступ через SSH-туннели.
После:
- Заберите результаты по SSH; дообученные веса считайте чувствительными.
- Уничтожьте инстанс и все сетевые тома.
- Отзовите токены и одноразовые ключи.
Источники
- Изоляция контейнеров и Secure Cloud на Vast.ai: FAQ по безопасности Vast.ai; остановка и уничтожение: управление инстансами
- RunPod Secure Cloud и Community Cloud: выбор пода; сохранность хранилища: типы хранилища
- LeftoverLocals: Trail of Bits, январь 2024
- age: github.com/FiloSottile/age
- Ограничения shred: руководство GNU coreutils, вызов shred
- NIST SP 800-88 Rev. 2: объявление NIST, сентябрь 2025
- Архитектура конфиденциальных вычислений на H100: NVIDIA, Confidential Computing on H100 GPUs for Secure and Trustworthy AI; общий доступ: NVIDIA, апрель 2024
- Azure: серия NCCads H100 v5
- Google Cloud: поддерживаемые конфигурации Confidential VM, создание инстанса Confidential VM с GPU
- Статья 28 GDPR: gdpr-info.eu
- HIPAA и облачные провайдеры: HHS, разъяснения по HIPAA и облачным вычислениям
- GPUFlow: быстрый старт с API, к чему арендаторы имеют и не имеют доступа, условия, политика конфиденциальности
Всё проверено в сентябре 2026 года.