Если вы арендовали сервер, то полного контроля у вас над ним нет. Это значит, что в любой момент к хостеру могут прийти специально обученные люди и попросить предоставить любые ваши данные. И хостер их отдаст, если требование будет оформлено по закону.
Вы очень не хотите, чтобы логи вашего веб-сервера или данные пользователей попали кому-то еще. Идеальную защиту построить не получится. Защититься от хостера, который владеет гипервизором и предоставляет вам виртуальную машину почти невозможно. Но, возможно, получится немного снизить риски. Шифрование арендованных машин не так бесполезно как кажется на первый взгляд. Заодно посмотрим на угрозы извлечения данных из физических серверов.
Модель угроз
Как правило, хостер будет стараться максимально защищать интересы клиента настолько, насколько это возможно по закону. Если в письме от официальных органов запросили только логи доступа, хостер не будет отдавать дампы всех ваших виртуальных машин с базами данных. Не должен, по крайней мере. Если попросят полностью все данные, то хостер скопирует виртуальные диски со всеми файлами и вы об этом не узнаете.
Вне зависимости от сценария развития событий ваша основная задача — сделать атаку слишком сложной и дорогой. Обычно есть три основных варианта угрозы.
Официальный
Чаще всего в официальный офис хостера присылают бумажное письмо с требованием предоставить нужные данные согласно соответствующему постановлению. Если все оформлено корректно, хостер предоставляет нужные логи доступа и другие данные официальным органам. Обычно просто просят прислать нужные данные.
Изредка, если очень надо, представители правоохранительных органов приезжают в ЦОД лично. Например, когда у вас свой выделенный сервер и данные оттуда можно забрать только физически.
Во всех странах для получения доступа на частную территорию, проведения обыска и других мероприятий требуется наличие доказательств того, что данные могут содержать важную информацию для расследования преступления. Кроме этого требуется оформленный по всем регламентам ордер на обыск. Тут могут быть нюансы связанные с особенностями местного законодательства. Главное, что нужно понимать — в случае правильного официального пути представители ЦОДа не пустят никого дальше проходной.
Более того, в большинстве стран нельзя просто так взять и выдернуть работающее оборудование. Например, в России до конца 2018 года, согласно статье 183 УПК РФ, часть 3.1, гарантировалось, что при производстве выемки, изъятие электронных носителей информации производится с участием специалиста. По ходатайству законного владельца изымаемых электронных носителей информации или обладателя содержащейся на них информации специалистом, участвующим в выемке, в присутствии понятых с изымаемых электронных носителей информации осуществляется копирование информации на другие электронные носители информации.
Потом, к сожалению, этот пункт из статьи убрали.
Тайный и неофициальный
Это уже территория деятельности специально обученных товарищей из NSA, FBI, MI5 и прочих трехбуквенных организаций. Чаще всего законодательство стран предусматривает крайне широкие полномочия для подобных структур. Более того, почти всегда есть законодательный запрет на любое прямое и косвенное разглашение самого факта сотрудничества с подобными силовыми ведомствами. В России есть аналогичные правовые нормы.
В случае подобной угрозы вашим данным, их почти наверняка вытащат. При этом помимо простого изъятия может использоваться весь неофициальный арсенал бэкдоров, уязвимостей нулевого дня, извлечение данных из оперативной памяти вашей виртуальной машины и прочие радости. Хостер при этом будет обязан максимально помогать специалистам силовых структур.
Недобросовестный сотрудник
Не все люди одинаково хороши. Кто-то из админов ЦОДа может решить подзаработать и продать ваши данные. Дальше развитие событий зависит от его полномочий и доступов. Самое неприятное, что администратор с доступом к консоли виртуализации имеет полный контроль над вашими машинами. Всегда можно снять снапшот вместе со всем содержимым оперативной памяти и дальше неторопливо его изучать.
VDS
Итак у вас есть виртуальная машина, которую вам выдал хостер. Как вы можете организовать шифрование, чтобы себя обезопасить? На самом деле, практически никак. Более того, даже чужой dedicated-сервер может оказаться в итоге виртуальной машиной, в которую прокинуты нужные устройства.
Если задачей удаленной системы является не просто хранение данных, а выполнение каких-то вычислений, то единственным вариантом работы с недоверенной машиной будет реализация гомоморфного шифрования. При этом, система будет проводить вычисления без возможности понять, что именно она делает. К сожалению, накладные расходы для реализации такого шифрования настолько велики, что практическое их применение на данный момент ограничено очень узкими задачами.
Плюс, в момент, когда виртуальная машина запущена и выполняет какие-то действия, все зашифрованные тома находятся в доступном состоянии, иначе ОС просто не сможет с ними работать. Это значит, что имея доступ к консоли виртуализации, вы всегда можете снять снапшот работающей машины и извлечь все ключи из оперативной памяти.
Многие вендоры предпринимали попытки организовать аппаратное шифрование RAM для того, чтобы даже хостер не имел доступа к этим данным. Например, технология Intel Software Guard Extensions, которая организовывает области в виртуальном адресном пространстве, защищённые от чтения и записи извне этой области другими процессами, включая ядро операционной системы. К сожалению, вы не сможете полноценно довериться этим технологиям, так как вы будете ограничены своей виртуальной машиной. К тому же, уже существуют готовые примеры успешной атаки на эту технологию. И все же, шифрование виртуальных машин не так бессмысленно, как может показаться.
Шифруем данные на VDS
Сразу оговорюсь, что все, что мы делаем ниже на полноценную защиту не тянет. Гипервизор позволит сделать нужные копии без остановки сервиса и незаметно для вас.
- Если по запросу хостер передаст “холодный” образ вашей виртуальной машины, то вы в относительной безопасности. Это наиболее частый сценарий.
- Если хостер отдаст полный снапшот работающей машины, то все довольно плохо. Все данные будут смонтированы в системе в открытом виде. Кроме того, появится возможность порыться в RAM в поисках приватных ключей и тому подобных данных.
По умолчанию, если вы развернули ОС из ванильного образа, у хостера нет root доступа. Всегда можно примонтировать носитель с rescue-образом и поменять пароль от root, сделав chroot в окружение виртуальной машины. Но это потребует перезагрузки, что будет замечено. Плюс, все примонтированные зашифрованные разделы будут закрыты.
Впрочем, если развертывание виртуальной машины идет не из ванильного образа, а из заранее подготовленного, то хостер часто может добавлять привилегированную учетную запись для оказания помощи в аварийной ситуации у клиента. Например, чтобы изменить забытый пароль от root.
Даже в случае полного снапшота не все так печально. Атакующий не получит зашифрованные файлы, если вы примонтировали их из удаленной файловой системы другой машины. Да, в теории можно расковырять дамп оперативной памяти и извлечь ключи шифрования оттуда. Но на практике это очень не тривиально и очень маловероятно, что процесс зайдет дальше простой передачи файлов.
Заказываем машину
Для наших тестовых целей берем простую машину в разделе для заказа серверов. Много ресурсов нам не нужно, поэтому возьмем вариант с оплатой за фактически потраченные мегагерцы и трафик. Как раз хватит поиграться.
Классический dm-crypt всего раздела не взлетел. Диск по умолчанию отдается одним куском, с root на весь раздел. Уменьшать раздел с ext4 на примонтированном root — это практически гарантированный кирпич вместо файловой системы. Я попробовал) Бубен не помог.
Создаем криптоконтейнер
Поэтому не будем шифровать раздел целиком, а используем файловые криптоконтейнеры, а именно прошедший аудит и надежный VeraCrypt. Для наших целей этого достаточно. Для начала вытаскиваем и устанавливаем пакет с CLI-версией с официального сайта. Можете заодно проверить подпись.
wget https://launchpad.net/veracrypt/trunk/1.24-update4/+download/veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
dpkg -i veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
Теперь мы создадим сам контейнер где-то в нашем home, чтобы монтировать его вручную при перезагрузке. В интерактивном варианте задайте размер контейнера, пароль и алгоритмы шифрования. Можете выбрать патриотичный шифр Кузнечик и хеш-функцию Стрибог.
veracrypt -t -c ~/my_super_secretТеперь давайте установим nginx, примонтируем контейнер и зальем в него секретную информацию.
mkdir /var/www/html/images
veracrypt ~/my_super_secret /var/www/html/images/
wget https://upload.wikimedia.org/wikipedia/ru/2/24/Lenna.pngЧуть поправим /var/www/html/index.nginx-debian.html, чтобы получить нужную страницу и можно проверять.
Подключаемся и проверяем
Контейнер примонтирован, данные доступны и отдаются.
А вот тут машина после перезагрузки. Данные надежно лежат в ~/my_super_secret.
Если очень надо и хочется хардкора, то можно зашифровать всю ОС, чтобы при перезагрузке она требовала подключения по ssh и ввода пароля. Этого также будет достаточно в сценарии простого изъятия “холодных данных”. Вот инструкция с использованием dropbear и удаленным шифрованием дисков. Хотя в случае VDS это сложно и избыточно.
Bare metal
Не так просто поставить собственный сервер в датацентр. Чужой dedicated может оказаться виртуальной машиной, куда прокинуты все устройства. Но что-то интересное в плане защиты начинается тогда, когда у вас появляется возможность разместить в датацентре свой доверенный физический сервер. Здесь уже можно в полный рост использовать традиционный dm-crypt, VeraCrypt или любое другой шифрование на ваш выбор.
Надо понимать, что при реализации тотального шифрования сервер не сможет самостоятельно подняться после ребута. Нужно будет поднимать соединение до локального интерфейса IP-KVM, IPMI или другого подобного аналога. После чего мы вручную вводим мастер-ключ. Схема выглядит так себе с точки зрения непрерывности и отказоустойчивости, но особых альтернатив тут нет, если данные настолько ценные.
NCipher nShield F3 Hardware Security Module
Более мягкий вариант предполагает, что данные зашифрованы, а ключ находится непосредственно в самом сервере в специальном HSM (Hardware Security Module). Как правило это очень функциональные устройства, которые не только обеспечивают аппаратную криптографию, но и имеют механизмы обнаружения попытки физического взлома. Если кто-то начнет ковырять ваш сервер болгаркой, то HSM с независимым источником питания сбросит ключи, которые хранит в своей памяти. Атакующему достанется зашифрованный фарш. При этом перезагрузка может происходить автоматически.
Удаление ключей — намного более быстрый и гуманный вариант, нежели активация термитной шашки или электромагнитного разрядника. За такие устройства вас будут очень долго бить соседи по стойке в датацентре. Тем более, что в случае использования TCG Opal 2 шифрования на самих носителях вы практически не испытываете никакого оверхеда. Все это происходит прозрачно для ОС. Правда, при этом надо доверять условному Samsung и надеяться, что там честный AES256, а не банальный XOR.
При этом не нужно забывать, что все лишние порты должны быть отключены физически или тупо залиты компаундом. Иначе вы даете возможность атакующим провести DMA-атаки. Если у вас есть торчащий наружу PCI Express или Thunderbolt, включая USB c его поддержкой — вы уязвимы. Атакующий сможет через эти порты провести атаку и получить прямой доступ к памяти с ключами.
В совсем изощренном варианте атакующий сможет провести cold boot атаку. При этом он просто заливает хорошую порцию жидкого азота в ваш сервер, грубо извлекает замороженные планки памяти и снимает с них дамп со всеми ключами. Часто для проведения атаки достаточно обычного охлаждающего спрея и температуры в районе -50 градусов. Есть и более аккуратный вариант. Если вы не отключили загрузку с внешних устройств, то алгоритм атакующего будет еще проще:
- Заморозить планки памяти без вскрытия корпуса
- Подключить свою загрузочную флешку
- Специальными утилитами снять данные из оперативной памяти, которые пережили перезагрузку, благодаря заморозке.
Разделяй и властвуй
Ок, у нас есть только виртуалки, но хочется хоть как-то снизить риски утечки данных.
Можно в принципе попробовать пересмотреть архитектуру и разнести хранение данных и обработку по разным юрисдикциям. Например, фронтенд с ключами шифрования у хостера в Чехии, а бэкенд с зашифрованными данными где-нибудь в России. В случае стандартной попытки изъятия, крайне маловероятно, что силовые структуры смогут провести это одновременно в разных юрисдикциях. Плюс это частично страхует нас от сценария со снятием снапшота.
Ну или можно рассмотреть совсем чистый вариант — End-to-End шифрование. Конечно это выходит за пределы ТЗ и не подразумевает выполнение вычислений на стороне удаленной машины. Тем не менее, это вполне приемлемый вариант, если речь идет о хранении и синхронизации данных. Например, это очень удобно реализовано в том же Nextcloud. При этом синхронизация, версионирование и прочие плюшки серверной части никуда не денутся.
Итого
Не бывает идеально защищенных систем. Задача состоит лишь в том, чтобы сделать атаку дороже потенциальной выгоды.
Некоторое снижение рисков доступа к данным на виртуальной можно получить, комбинируя шифрование и раздельное хранение у разных хостеров.
Более или менее надежный вариант — использование своего железного сервера.
А хостеру все равно придется так или иначе доверять. На этом держится вся индустрия.
