Один из моих клиентов попросил, чтобы их веб-сервер был зашифрован, чтобы предотвратить автономные атаки на высокочувствительные данные, содержащиеся в базе данных mysql, а также / var / log. У меня есть полный root-доступ к выделенному серверу на популярном хосте. Рассматриваю 3 варианта -
FDE - это было бы идеально, но только с удаленным доступом (без консоли) Я полагаю, это было бы очень сложно.
Xen - установка XEN и перемещение своего сервера внутри виртуальной машины XEN и шифрование виртуальной машины - что кажется проще сделать удаленно.
Parition - шифрование нестатических разделов, на которых находятся конфиденциальные данные, например / var / home и т. д.
Какой был бы упрощенный подход, удовлетворяющий требованиям?
Было бы целесообразно проконсультироваться с хостом, чтобы узнать, могут ли они либо подключить IP KVM, либо установить карту удаленного доступа (IPMI, HP iLO, iDRAC или RAS, в зависимости от ситуации), чтобы обеспечить зашифрованный удаленная консоль.
Для любого решения FDE вам обязательно потребуется незашифрованная начальная загрузка системы. Как минимум, он будет состоять из MBR, загрузчика, ядра и initrd.
Можно включить в сеть систему начальной загрузки FDE, используя что-то вроде Мандос или с использованием полной установки ОС с последующим переключением на реальную ОС путем удаленного запуска пользовательских сценариев, которые используют возможности pivot_root, chroot (или kexec) после cryptsetup и монтирования.
Использование Xen и наличие виртуальной машины с зашифрованным хранилищем аналогично использованию всей ОС для начальной загрузки, но с меньшими затратами и более простым обслуживанием. Единственный недостаток этого подхода - накладные расходы на виртуализацию.
Подход блочного устройства (LV, раздел или петля), безусловно, прост в использовании, особенно если вы пытаетесь внести изменения в производственной системе.
Теперь совет: если вы можете получить доступ к удаленной консоли (полный KVM, а не серийный) и вы создаете новую машину, а затем переходите к FDE. Все текущие дистрибутивы поддерживают его в установщике, и это будет вариант с минимальным обслуживанием.
В противном случае:
Даже не думайте об использовании FDE. Система начальной загрузки с удаленным доступом будет слишком хрупкой, и когда она выйдет из строя, ее исправить станет кошмаром. Не пытайтесь преобразовать живую систему на лету, если вы действительно действительно не знаете, что делаете.
Если вы создаете новую машину для этого обновления безопасности и накладные расходы на виртуализацию приемлемы, тогда выберите подход 2. Это будет наиболее разумный вариант для вас и любого другого будущего системного администратора, который нужно понимать / поддерживать. При таком подходе вы можете использовать шифрование установщика, предоставляемое ОС, внутри виртуальной машины, а не шифровать хранилище на хосте, если хотите (за / против обоих подходов к обслуживанию / миграции и т. Д.).
Если вам необходимо внести это изменение в производственную систему (чего я настоятельно не рекомендую. Заставьте клиента заплатить за надлежащую миграцию с помощью второй системы), выберите подход 3 и используйте блочное устройство в формате LUKS (желательно логический том). .
В любом из этих сценариев базовая система или код начальной загрузки, очевидно, могут быть троянскими, так что ключ шифрования будет раскрыт. Не тратьте зря время, пытаясь снизить этот риск, если у вас нет много свободного времени и у вашего клиента есть деньги, которые нужно сжечь. Если вам нужно смягчить его, вы захотите установить что-то вроде Osiris.
Помните, что данные будут подвергаться гораздо большему риску из-за ошибок программного обеспечения, систем резервного копирования, неправильной конфигурации, неверных паролей и т. Д.
Прежде всего, обратите внимание, что вам не нужно создавать отдельный раздел для шифрования данных; вы можете использовать loopback-монтирование для монтирования файла как (зашифрованного) раздела.
Но что еще более важно, вам нужна четкая модель угроз. Чего именно боится ваш клиент?
Обычно размещенный сервер должен быть доступен только уполномоченному персоналу клиента и некоторому специализированному персоналу хостинг-провайдера. Боятся ли они, что хостинг-провайдер попытается скопировать данные за их спиной? Боятся ли они физического взлома? Они хотят защитить себя от случайного слежения или от изощренного злоумышленника, возможно, с повторным доступом?
Это повлияет на то, какое решение им нужно. Например. простое шифрование данных означает, что операционная система все еще уязвима для установки трояна, пока система отключена. Злоумышленник может отключить систему, установить троян, перезапустить; впоследствии они могут копировать данные из зашифрованной области, пока она доступна.
Кроме того, любое решение для шифрования потребует предоставления ключа / парольной фразы для разблокировки шифрования. Когда это будет предоставлено? Как? Какие у вас есть безопасные каналы? Что, если, например, система перестает загружаться и ее нужно восстановить? Тогда кто-то, кому доверяют ключ, должен будет присутствовать физически; это будет возможно?
Без ответа на все эти (и многие другие) вопросы нет разумного ответа.
Конечно, вы можете просто развернуть какое-то шифрование и покончить с этим, но это может не защитить от атаки и только вызовет ненужные затраты и ложное чувство безопасности.
Примечание: Здесь есть интересное обсуждение шифрования данных на сервере: Автоматическая загрузка и защита Linux-сервера с зашифрованной файловой системой