LINUX.ORG.RU

Шифрование

 , , ,


2

2

Привет всем!

Думаю, как лучше обеспечить конфиденциальность данных. Ничего особенного, но хотелось бы иметь защиту на случай, например, потери носителя (вместе с компьютером :-). Данные:
* Файлы рабочего проекта
* Ключи от рабочего сервера
* Личная переписка
* Всякое разное: документы, фото, какие-то заметки
* Ничего наказуемого

Погуглил, вижу такие, понятные мне решения: LUKS, eCryptfs, fscrypt.

Размышления следующие:
* Кажется, для меня нет смысла в шифровании системного раздела или всего блочного устройства. Зачем шифровать стандартные пакеты и настройки в /etc? Если система будет скомпрометирована, то в любом случае проще всё переустановить. Так же, возможно, будет отдельный пользователь, которого не надо защищать, для игр и всякой ерунды. Т.е., если шифровать не всё, то это должно положительно отразиться на производительности.
* Следовательно, eCryptfs или fscrypt для домашней директории целиком будут лучше, чем целое блочное устройство.
* eCryptfs это «слоёная файловая система», файлы доступны и в зашифрованном виде (нижний слой). Я думаю, что можно прямо так, с нижнего слоя, делать резервные копии на другой носитель, тогда его отдельно не надо будет шифровать. И можно хоть в облако загрузить. Или лучше не надо?
* С другой стороны, fscrypt это элемент самой файловой системы ext4, а не надстройка сверху, значит работать должно быстрее.
* В нескольких местах читал, что дистрибутивы отказываются от eCryptfs, мол разработка заглохла, не развивается. Там реально есть какие-то проблемы с безопасностью, потерей данных и производительностью или это просто перестало быть модным?

Я пока склоняюсь к eCryptfs. Носитель SSD.

★★★★★

На современном железе, по моему опыту, оверхед шифрования не заметен на глаз, так как скорость чтения/записи неизбежно ниже скорости шифрования. В свою очередь, шифрование реализованное в ядре быстрее.

Я бы просто сделал luks на весь диск (кроме UEFI раздела), а внутри LVM для всего остального (включая swap).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

luks на весь диск

А TRIM при этом до SSD проходит?

И что думаешь по поводу использования шифрованных данных на eCryptfs для резервного копирования, хорошая идея?

ls-h ★★★★★
() автор топика

Весь home fscrypt на всякий случай.
Остальное на съёмном накопителе с ссылками из home.
Ключи, данные, пароли к ключам, в разных местах хранить.
И автоматически блокировать.
Сам не проверял.

naKovoNapalBaran
()

Я исхожу из простоты установки и поддержки. Например, в установщике Федоры предлагается lvm+luks. Вот так я и сделал.

положительно отразиться на производительности

Насколько я понимаю, в современных процессорах операции шифрования аппаратно ускорены, соответственно об этом нечего переживать.

Im_not_a_robot ★★★★★
()

Советую luks. Программа может сохранять информацию в разных местах файловой системы, поэтому вариант LUKS полностью предотвращает этот риск. Хотя согласен, что не всем нужно. У LUKS есть бонус - можно зашифровать один большой раздел, а поверх него создать логические тома с помощью LVM или с помощью файловой системы (например, btrfs).

mxfm ★★
()
Ответ на: комментарий от mxfm

Программа может сохранять информацию в разных местах файловой системы

Но если зашифровать полностью домашнюю директорию пользователя, то как программа что-то сохранит вне?

ls-h ★★★★★
() автор топика

Тут уже сказали, я только присоединюсь: LUKS+LVM.

О более сложных схемах не беспокойтесь, всё равно никто шифрование ломать не станет, ведь гораздо проще сломать носителя ключа шифрования.

Camel ★★★★★
()
Ответ на: комментарий от ls-h

Это сужает пространство для утечки. Остаётся мусор в tmp, некоторые программы ещё пишут в /var и /opt.

mxfm ★★
()

Рассмотрите еще возможность шифорвния средствами самого SSD. Иногда это хороший вариант.

i586 ★★★★★
()

Для того чтобы программа не сохраняла никуда свои данные кроме /home, можно сделать chmod -R a-w /, хотя это и так вроде по умолчанию в большинстве дистров.

realbarmaley ★★
()

Есть смысл шифровать всё. Так как можно в какую-то уязвимую скриптуху в /etc при наличии физического доступа насовать интересных скриптов. А такой скриптухи там вагон, поверь.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.