Я знаю, что название кажется совершенно противоречивым, но позвольте мне уточнить. Чтение Брюса Шнайера недавняя статья об удалении данных заставило меня задуматься, что на каждом сервере должно быть шифрование всего диска, хотя бы потому, что знание rm file надежно удаляет файл, и если его больше нигде нет, он исчезнет навсегда.
Если бы я нашел способ, скажем, запустить один «действительно безопасный» сервер, который служил ключевым сервером для ключей дешифрования файловой системы LUKS, а все остальные серверы просто выполняли какую-то сетевую загрузку, в которой они обращались к этому «действительно безопасному» «сервер ключей, могу ли я добиться полной автоматизации на этих машинах? Поскольку я должен предположить, что Amazon может (при желании) легко извлекать ключи шифрования, действительно ли я теряю какую-либо безопасность при такой настройке? Под полной автоматизацией я подразумеваю возможность добавлять и удалять машины по желанию без какого-либо ручного вмешательства от моего имени или физического доступа. Кроме того, машины должны иметь возможность перезапускаться самостоятельно и не задыхаться в ожидании пароля для дешифрования.
Кроме того, возможно ли это? Я думал, что есть способ сделать что-то подобное, но сейчас я немного не уверен в этом предмете.
Это обычный вариант использования FDE, когда вы предоставляете FDE пустой пароль. Затем вам нужно настроить загрузчик FDE, чтобы пропустить запрос пароля и просто загрузить компьютер с пустым паролем. Если вы используете LUKS, вы, вероятно, можете изменить исходный код и перекомпилировать загрузчик LUKS, чтобы просто пропустить ввод пароля и продолжить с пустым паролем.
Обратите внимание, что использование пустого пароля для FDE является не небезопасно в этом случае (чтобы облегчить стирание диска). Пароль шифрует ключ шифрования диска, который, в свою очередь, шифрует диск. Это сделано для того, чтобы можно было изменить пароль без повторного шифрования всего диска. Таким образом, даже если ключ шифрования диска не зашифрован или не защищен, содержимое все равно будет защищено, когда этот ключ шифрования диска будет надежно удален.
Когда пришло время списать сервер, вы просто сотрите несколько первых мегабайт, содержащих загрузчик, а затем убедитесь, что загрузчик исчез.
Другой вариант использования - установить загрузчик на другое устройство / носитель, который легче разрушить, чем жесткий диск. Когда пришло время списать сервер, вы либо сохраняете загрузочный носитель, либо уничтожаете его.
Загрузка через PXE также является жизнеспособным решением. Затем вы помещаете весь загрузчик на PXE-сервер. Можно даже прошить iPXE ( http://www.ipxe.org ) в чип материнской платы / сетевой карты, а затем можно будет загрузить загрузчик через HTTP / HTTPS.
Некоторые накопители также используют эту встроенную функцию, при которой он генерирует случайный ключ шифрования, сохраняет его во флэш-памяти или на пластине диска, а затем шифрует весь накопитель. Когда вы затем вводите команду ATA Secure Erase, она надежно стирает ключ шифрования, делая весь диск нечитаемым.
Можно автоматизировать виртуальные машины с помощью FDE (Full Disk Encryption), за исключением раздела / boot.
Вот несколько вариантов, каждый из которых использует стандартное шифрование LUKS в Linux:
Может быть, я не получил вашего ответа или я новичок, но не могли бы вы создать Golden Image, который уже имеет шифрование, а затем развернуть его с помощью Zero touch? Управляйте с помощью чего-то вроде Puppet или SCCM, но что я считаю очень бесполезным, так это то, что вы хотите, чтобы пароль вводился автоматически (для этого наверняка может быть создан некоторый код), но тогда это делает сервер менее безопасным и сводит на нет цель шифрование.