Zfs шифрование: TrueNAS: методы шифрования | Блог Элкомсофт | Дропшиппинг

Содержание

TrueNAS: методы шифрования | Блог Элкомсофт

В сетевых хранилищах известных производителей, как правило, доступны те или иные способы шифрования. Synology, Asustor, TerraMaster отдают предпочтение шифрованию на уровне папок, в то время как QNAP, Thecus, а также Asustor при использовании функции MyAcrhive используют вариант полнодискового шифрования. Подробно об этом можно почитать в нашем сравнении методов защиты данных у крупных коммерческих производителей NAS. Сегодня же мы рассмотрим способы шифрования, использующиеся в одной из самых распространённых систем для организации сетевого хранилища от домашнего до корпоративного уровня — TrueNAS разработки американской компании iXSystems.

Что такое TrueNAS?

TrueNAS — название программного обеспечения с открытым исходным кодом, под управлением которого работают компьютеры, выполняющие функции сетевого хранилища данных (NAS). Прародителем TrueNAS в его современном виде является проект FreeNAS, изначально выпущенный в 2005 году разработчиком Olivier Cochard-Labbé.

Несколько лет спустя разработчик передал права на FreeNAS американской компании iXSystems, которая и занимается разработкой и продвижением проекта по сей день.

Изначально FreeNAS был полностью бесплатным, однако через какое-то время iXSystems выпустила коммерческую версию продукта – TrueNAS, которая использовалась в крупных коммерческих компаниях. В то же время компания продолжала развивать и бесплатную версию FreeNAS. Не так давно обе системы были объединены под названием TrueNAS: различия между платной и бесплатной версиями заключаются скорее в сопровождении и технической поддержке, чем в функциональных возможностях.

Базовая операционная система TrueNAS

Изначально система TrueNAS работала поверх операционной системы FreeBSD со всеми её сильными и слабыми сторонами. Именно для FreeBSD в своё время была доступна поддержка файловой системы ZFS, которая является основным преимуществом TrueNAS. Со временем файловая система ZFS стала доступна и для операционных систем Linux в виде OpenZFS, после чего разработчики TrueNAS занялись адаптацией продукта под ОС Debian Linux.

Таким образом, на сегодняшний день существует две версии TrueNAS: TrueNAS Core, основанный на FreeBSD, и TrueNAS Scale, работающий поверх Debian Linux. На момент написания статьи в TrueNAS Scale используется версия Debian 11 (Bullseye).

TrueNAS в обоих обладает полноценной поддержкой всех возможностей файловой системы ZFS, включая все функции управления многодисковыми конфигурациями. Поддерживаются создание и управление всеми уровнями хранилищ (vdev, zpool, dataset), шифрование, моментальные снимки и их репликация (включая зашифрованные снимки, в том числе для томов с неизвестным ключом шифрования), а также дедупликация данных.

С точки зрения эксперта-криминалиста различий между системами не так много, но они есть. Так, основанный на FreeBSD TrueNAS Core поддерживает шифрование по методу GELI (этот тип шифрования специфичен для FReeBSD) и native ZFS encryption, реализованный средствами OpenZFS 2.0. В то же время версия TrueNAS Scale, работающая поверх Debian Linux, поддерживает только native ZFS encryption и не позволяет создавать тома, зашифрованные GELI.

Важные особенности TrueNAS

В TrueNAS есть целый ряд интересных особенностей, однако далеко не все из них представляют интерес для эксперта-криминалиста. С нашей точки зрения важными являются следующие особенности системы:

TrueNAS всегда устанавливается на отдельный физический накопитель. На этом накопителе не могут быть созданы тома для хранения данных, и этот накопитель не может быть зашифрован (за возможным исключением аппаратного шифрования диска, при использовании которого необходимо разблокировать диск при включении устройства).
Для шифрования данных пользователь может задать как пароль, так и двоичный ключ.
При использовании шифрования данных с ключом (в отличие от шифрования с паролем) TrueNAS позволяет сохранить ключи шифрования для автоматического монтирования зашифрованных данных. Если пользователь сохраняет ключи шифрования, то записаны они будут на загрузочный накопитель.
Шифрование по методу native ZFS encryption не является методом полнодискового шифрования в классическом смысле: ряд структур ZFS остаётся доступен для операций контроля целостности, исправления ошибок, дедупликации, создания и репликации моментальных снимков даже тогда, когда пароль или ключ не были введены (т. е. зашифрованный том заблокирован). Соответственно, даже без ключа шифрования доступна информация об использованном месте на диске и размере файловых систем (но не о размере отдельных файлов или папок, как это происходит в шифровании на уровне файловой системы eCryptFS, которое используется в NAS от Synology, Asustor и TerraMaster.)

При создании зашифрованного набора данных (dataset) пользователь может выбрать алгоритм шифрования (по умолчанию — AES-256-GCM) и указать число итераций функции преобразования ключа pbkdf2 (по умолчанию — 350,000 итераций). Эта информация сохраняется в метаданных; угадывать алгоритм шифрования или подбирать число итераций при монтировании зашифрованного диска не придётся.

Методы шифрования в TrueNAS

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

Аппаратное шифрование на уровне жёсткого диска SED (Self Encrypting Drive), доступное в некоторых моделях дисков.

Подробное описание функции даёт понять, что при использовании SED пользователь теряет некоторые возможности ZFS — например, возможность репликации зашифрованных данных на удалённое устройство с неизвестным ключом шифрования. В качестве метода шифрования SED не является уникальным для TrueNAS; точно таким образом диски могут быть защищены в любой другой системе, поддерживающий этот тип защиты.

Диски, защищённые SED в TrueNAS, ничем не отличаются от дисков, защищённых SED в любой другой системе, и не имеют характерных для TrueNAS особенностей.

Следующий метод шифрования в TrueNAS — GELI, принятый за стандарт в операционной системе FreeBSD. В TrueNAS 12 создание зашифрованных GELI томов более не поддерживается, но ранее созданные тома по-прежнему можно смонтировать. Стандарту GELI больше десяти лет, он давно известен и хорошо изучен. На русском языке ознакомиться с его особенностями можно, например, из статьи Записки криптонавта: Осваиваем защиту данных в BSD (xakep.

ru).

Диски, зашифрованные по стандарту GELI, можно расшифровать средствами как TrueNAS Core (не обязательно оригинальной инсталляции — можно установить чистую версию системы и смонтировать диски в ней), так и средствами чистой операционной системы FreeBSD (документация).

Шифрование по методу native ZFS encryption — новый для TrueNAS стандарт шифрования, появившийся в 12-й версии системы в обеих ветках (TrueNAS Core и TrueNAS Scale). Строго говоря, native ZFS encryption не является методом полнодискового шифрования в классическом смысле: ряд структур ZFS остаётся доступен для операций контроля целостности, исправления ошибок, дедупликации, создания и репликации моментальных снимков даже тогда, когда пароль или ключ не были введены (т.е. зашифрованный том заблокирован). Нужно ли отдельно упоминать возможность

моментально сменить пароль или ключ шифрования без перешифровки всего набора данных? Да, нужно: механизм шифрования, который используется в Synology, TerraMaster, Asustor (за исключением архивов MyArchive) такой роскоши не предоставляет, и в случае утечки ключа шифрования или пароля пользователю останется только смириться.

Детальный анализ особенностей этого метода шифрования провели в редакции Ars Technica в статье A quick-start guide to OpenZFS native encryption.

Пользователь может выбрать алгоритм шифрования и, при использовании пароля, указать число итераций функции pbkdf2. Эта информация сохраняется в метаданных.

Данные могут быть зашифрованы как паролем (passphrase), так и двоичным ключом. После создания зашифрованного набора данных пользователь может скачать и сохранить ключ шифрования.

В TrueNAS поддерживается наследование шифрования, что позволяет зашифровать дочерние наборы данных как тем же («унаследованным») способом, что и родительский пул, так и с отличным от него паролем, алгоритмом шифрования и числом итераций функции pbkdf2.

При использовании двоичного ключа шифрования становится доступной возможность автоматического монтирования зашифрованных наборов данных в процессе загрузки. В этом случае двоичный ключ сохраняется на загрузочном накопителе TrueNAS. При использовании пароля (passphrase) возможность автоматического монтирования не поддерживается.

Native ZFS encryption обладает рядом достоинств в сравнении как с классическим для систем на основе Linux механизмом дискового шифрования LUKS, так и с использующимся в системах FreeBSD GELI. Шифрование ZFS даёт возможность выполнять заметную часть операций на уровне команд zfs и zpool на зашифрованных дисках, даже если ключ шифрования не указан или неизвестен. В список поддерживаемых команд входят сервисные операции по верификации целостности данных, моментальные снимки и их репликация и ряд других команд. Если же диск зашифрован LUKS, то для выполнения подобных операций потребуется сначала смонтировать диск, для чего необходимо ввести ключ шифрования.

Важным различием между версиями TrueNAS Core (FreeBSD) и TrueNAS Scale (Debian Linux) является поддержка классического для FreeBSD метода шифрования GELI. В актуальных сборках TrueNAS шифрование GELI более не поддерживается ни в одной версии системы. Тем не менее, пользователи TrueNAS Core могут продолжать пользоваться зашифрованными дисками GELI или осуществить миграцию путём монтирования зашифрованного диска и переноса данных. Для пользователей TrueNAS Scale поддержки GELI нет ни в каком виде; это стоит учитывать при работе с зашифрованными GELI дисками.

У шифрования ZFS есть ряд слабых мест, позволяющих получить некоторую информацию о зашифрованных наборах данных с неизвестным ключом шифрования. Во-первых, без ввода ключа шифрования доступны имена и размеры файловых систем и другие данные, доступные с помощью команд zfs и zpool. В отличие от использующегося в коммерческих NAS от Synology или Asustor механизма шифрования eCryptFS, шифрование ZFS не позволяет узнать количество или размеры зашифрованных файлов, а также прочие метаданные, недоступные с помощью команд zfs и zpool.

ZFS encryption не защищает таблицы дедупликации, что позволяет узнать адреса дублированных (совпадающих) блоков на диске. Содержимое отдельных блоков данных останется недоступным. Ценность этой информации сомнительна; данный аспект native ZFS encryption не считается критическим с точки зрения безопасности.

Можно упомянуть уязвимость CRIME (Compression Ratio Info-leak Made Easy), которая может быть реализована в сценариях, в которых используется сжатие данных до их шифрования. Ценность доступных этим способом типов данных исчезающе мала по сравнению с затраченными на реализацию атаки усилиями.

Дополнительная информация

Механизм шифрования native ZFS encryption подробно документирован. Рекомендуем ознакомиться с информацией на официальном сайте TrueNAS:

TrueNAS Core: Storage Encryption | (truenas.com)
TrueNAS Scale: Encryption | (truenas.com)

Сравнение native ZFS encryption с другими методами шифрования NAS

Функции шифрования, использующиеся в коммерческих сетевых хранилищах производства Synology, Asustor и их конкурентов, использующих шифрование на уровне сетевых папок, на удивление рудиментарны. Единожды зашифровав сетевую папку, пользователю придётся мириться с невысокой скоростью шифрования, особенно на мелких файлах; невозможностью когда-либо сменить пароль шифрования, а также с тем, что любой желающий сможет узнать точное число файлов и размер каждого из них. В то же время для зашифрованных папок доступны функции контроля целостности, дефрагментации, создания и репликации моментальных снимков — даже если пароль шифрования неизвестен. Здесь пользователь получает удобство в ущерб скорости и безопасности.

Немногим лучше обстоят дела у конкурентов, использующих шифрование диска LUKS. С одной стороны, LUKS — действительно непробиваемая защита, гарантированно скрывающая не только содержимое файлов, но и метаданные файловой системы, работающая, к тому же, с исключительно высокой производительностью и позволяющая моментально сменить скомпрометированный пароль. С другой — зашифрованный LUKS диск без ввода ключа шифрования нельзя ни дефрагментировать, ни проверить целостность файловой системы, ни создать моментальный снимок, ни тем более — его реплицировать на другое устройство. Здесь пользователь получает высокую скорость и безопасность — в ущерб удобству. Разумеется, сохранение ключа шифрования в самой системе снимает вопросы к удобству использования — но и низводит безопасность решения практически до нуля.

Механизм шифрования GELI, доступный в ОС FreeBSD и использущийся в системах FreeNAS и TrueNAS Core, обладает набором достоинств и недостатков, похожим на шифрование LUKS.

Механизм ZFS native encryption, использущийся в системах TrueNAS Core и TrueNAS Scale, является исключительно удачной комбинацией достоинств радикально отличных подходов к шифрованию. С одной стороны, ZFS native encryption защищает действительно важные метаданные файловой системы — такие, как точный размер и количество файлов; позволяет моментально сменить скомпрометированный пароль; работает с высокой производительностью независимо от размера файлов; позволяет как выбрать алгоритм шифрования, так и настроить стойкость защиты к атаке методом перебора; наконец, позволяет гибко настраивать защиту дочерних наборов данных. С другой — на зашифрованном наборе данных без ввода ключа шифрования можно проводить операции контроля целостности и обслуживания файловой системы, создавать и реплицировать моментальные снимки — и всё это без необходимости расшифровывания самих данных.

С нашей точки зрения механизм ZFS native encryption получился действительно удачным, современным решением, обеспечивающим высокопроизводительную и надёжную защиту данных с минимальным количеством компромиссов и слабых мест. Мы собираемся продолжать исследование шифрования ZFS.

Заключение

В механизмах шифрования GELI и native ZFS encryption, использующихся в сетевых хранилищах TrueNAS, серьёзных уязвимостей не обнаружено. Эксплуатация известных на данный момент слабостей позволяет извлечь ограниченный объём метаданных, включающих информацию, доступную через команды zfs и zpool (например, размеры и конфигурацию файловой системы, адреса дублирующихся блоков данных — но не содержимое самих блоков). В отличие от зашифрованных eCryptFS папок, методы шифрования ZFS не позволяют узнать число и размер файлов и папок.

Установка ubuntu 20.04 с корнем на шифрованном ZFS зеркале и UEFI загрузкой / Хабр

На моей домашней машине вот уже 7 лет работает пара дисков, объединенная в soft raid1. И вот на днях один диск в зеркале наконец начал сыпаться. Появился повод переустановить систему с нуля и начать использовать шифрование, которое 7 лет назад не было задействовано. В процессе гугления о состоянии дел в конфигурации LUKS поверх mdadm я вышел на статью сравнивающей производительность zfs vs mdadm/ext4. А потом нашел другую статью с тестированием производительности зашифрованных дисков использующих LUKS и zfs. Согласно обеим статьям zfs демонстрирует весьма неплохую производительность и я решил попробовать ее в деле.

На хабре некоторое время назад уже были статьи на ту же тему:
2019 Ubuntu 18.04 Root on ZFS
2018 Установка Debian с корнем на шифрованном ZFS зеркале
2018 /boot на ZFS зеркале

Я решил написать свою статью, поскольку использую для загрузки UEFI (в прошлых статьях использовалась legacy загрузка), ну и плюс с момента последней статьи прошло 3 года и мне показалось, что проверенная в деле современная инструкция может быть полезна для сообщества.

При установке я в основном ориентировался на вот эти статьи:
Ubuntu 20.04 Root on ZFS
Installing UEFI ZFS Root on Ubuntu 20.04 with Native Encryption

Я буду описывать установку на виртуальную машину virtualbox. Установка на настоящее железо ничем не отличается.

Итак, я создал виртуальную машину с парой дисков по 20гб и 8гб памяти. Загрузился с ubuntu-20.04.1-desktop-amd64.iso, кликнул на try ubuntu и запустил терминал. В терминале я сразу перешел под рута, так как все используемые команды требуют рутовых привилегий. Первым делом я определил несколько переменных:

export DISK1=/dev/disk/by-id/ata-VBOX_HARDDISK_VBad5107ca-df268eef
export DISK2=/dev/disk/by-id/ata-VBOX_HARDDISK_VBaf134a71-943e2d11
export HOSTNAME=ubuntu-zfs-vm
export USERNAME=toor

Теперь можно разметить диски:

sgdisk --zap-all $DISK1
sgdisk --zap-all $DISK2
sgdisk -n1:1M:+256M -t1:EF00 -c1:EFI $DISK1
sgdisk -n1:1M:+256M -t1:EF00 -c1:EFI $DISK2
sgdisk -n2:0:+1024M -t2:be00 -c2:Boot $DISK1
sgdisk -n2:0:+1024M -t2:be00 -c2:Boot $DISK2
sgdisk -n3:0:0 -t3:bf00 -c3:Ubuntu $DISK1
sgdisk -n3:0:0 -t3:bf00 -c3:Ubuntu $DISK2

Для загрузки я буду использовать UEFI, так что надо создать диск с типом EF00, отформатированный под vfat:

mkfs. msdos -F 32 -n EFI ${DISK1}-part1
mkfs.msdos -F 32 -n EFI ${DISK2}-part1

Настала пора создавать zfs. Я буду использовать grub, который поддерживает загрузку с zfs, хотя и не со всеми опциями. Так что создание загрузочного раздела требует явным образом указать только то, что понимает grub:

zpool create -f -o cachefile=/etc/zfs/zpool.cache -o ashift=12 \
    -o autotrim=on -d -o feature@async_destroy=enabled \
    -o feature@bookmarks=enabled -o feature@embedded_data=enabled \
    -o feature@empty_bpobj=enabled -o feature@enabled_txg=enabled \
    -o feature@extensible_dataset=enabled \
    -o feature@filesystem_limits=enabled -o feature@hole_birth=enabled \
    -o feature@large_blocks=enabled -o feature@lz4_compress=enabled \
    -o feature@spacemap_histogram=enabled -O acltype=posixacl -O canmount=off \
    -O compression=lz4 -O devices=off -O normalization=formD -O relatime=on \
    -O xattr=sa -O mountpoint=/boot -R /mnt \
    bpool mirror ${DISK1}-part2 ${DISK2}-part2

Загрузочный раздел создан, можно создавать корневой раздел (поскольку мы используем шифрование нам надо будет ввести пароль):

zpool create -f -o ashift=12 -o autotrim=on -O encryption=aes-256-gcm \
    -O keylocation=prompt -O keyformat=passphrase -O acltype=posixacl \
    -O canmount=off -O compression=lz4 -O dnodesize=auto \
    -O normalization=formD -O relatime=on -O xattr=sa -O mountpoint=/ \
    -R /mnt rpool mirror ${DISK1}-part3 ${DISK2}-part3

Можно создавать датасеты. Я решил ограничиться минимумом:

zfs create -o canmount=off -o mountpoint=none rpool/ROOT
zfs create -o canmount=off -o mountpoint=none bpool/BOOT
UUID=$(dd if=/dev/urandom bs=1 count=100 2>/dev/null \
    |tr -dc 'a-z0-9' | cut -c-6)
zfs create -o mountpoint=/ -o com.ubuntu.zsys:bootfs=yes \
    -o com.ubuntu.zsys:last-used=$(date +%s) \
    rpool/ROOT/ubuntu_$UUID
zfs create -o mountpoint=/boot bpool/BOOT/ubuntu_$UUID
zfs create -o canmount=off -o mountpoint=/ rpool/USERDATA
zfs create -o com.ubuntu.zsys:bootfs-datasets=rpool/ROOT/ubuntu_$UUID \
    -o canmount=on -o mountpoint=/home/$USERNAME \
    rpool/USERDATA/${USERNAME}_$UUID

Для установки системы давайте использовать debootstrap:

apt-get install -y debootstrap
debootstrap focal /mnt

Копируем на новую файловую систему недостающие компоненты:

echo $HOSTNAME >/mnt/etc/hostname
sed '/cdrom/d' /etc/apt/sources.list > /mnt/etc/apt/sources.list
sed "s/ubuntu/$HOSTNAME/" /etc/hosts > /mnt/etc/hosts
cp /etc/netplan/*. yaml /mnt/etc/netplan/

И монтируем псевдофс, нужные для продолжения установки:

mount --make-private --rbind /dev  /mnt/dev
mount --make-private --rbind /proc /mnt/proc
mount --make-private --rbind /sys  /mnt/sys

Заходим в chroot среду:

chroot /mnt /usr/bin/env DISK1=$DISK1 DISK2=$DISK2 USERNAME=$USERNAME \
    /bin/bash –login

Обновляем индексы бинарных пакетов, устанавливаем локаль:

apt-get update
locale-gen --purge "en_US.UTF-8"
update-locale LANG=en_US.UTF-8 LANGUAGE=en_US
dpkg-reconfigure --frontend noninteractive locales

Устанавливаем нужный нам часовой пояс:

dpkg-reconfigure tzdata

Монтируем EFI партицию. Обычно ее монтируют под /boot/efi, но в нашем случае партиций 2, плюс есть проблема очередности монтирования дисков. Я решил монтировать диск в другой иерархии и использовать симлинку:

mkdir /run/efi1
mount $DISK1-part1 /run/efi1
ln -s /run/efi1 /boot/efi
echo /dev/disk/by-uuid/$(blkid -s UUID -o value \
    ${DISK1}-part1) /run/efi1 vfat defaults 0 0 >> /etc/fstab
echo /dev/disk/by-uuid/$(blkid -s UUID -o value \
    ${DISK2}-part1) /run/efi2 vfat defaults 0 0 >> /etc/fstab

Устанавливаем прочие необходимые пакеты:

apt-get install -y grub-efi-amd64 grub-efi-amd64-signed linux-image-generic \
    shim-signed zfs-initramfs zsys ubuntu-minimal network-manager

Из-за регрессии надо добавить параметр ядра init_on_alloc=0:

sed -ie 's/\(GRUB_CMDLINE_LINUX_DEFAULT="[^"]*\)/\1 init_on_alloc=0/' \
    /etc/default/grub

Я предпочитаю иметь небольшой своп:

zfs create -V 4G -b $(getconf PAGESIZE) -o compression=off \
    -o logbias=throughput -o sync=always -o primarycache=metadata \
    -o secondarycache=none rpool/swap
mkswap -f /dev/zvol/rpool/swap
echo "/dev/zvol/rpool/swap none swap defaults 0 0" >> /etc/fstab
echo RESUME=none > /etc/initramfs-tools/conf. d/resume

Добавляем пользователя:

adduser $USERNAME
find /etc/skel/ -type f|xargs cp -t /home/$USERNAME
chown -R $USERNAME:$USERNAME /home/$USERNAME
usermod -a -G adm,cdrom,dip,plugdev,sudo $USERNAME

Обновляем inird и grub и выходим из chroot среды:

update-initramfs -c -k all
update-grub
grub-install --target=x86_64-efi --efi-directory=/boot/efi \
    --bootloader-id=ubuntu --recheck --no-floppy
exit

Размонтируем то, что было смонтировано в chroot среде и перезагружаемся:

mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | xargs -i{} umount -lf {}
zpool export -a
reboot

Поскольку все происходит в virtualbox отмечу, что с включенным UEFI виртуалка отказывалась грузиться с оптического привода. Так что в этом месте я убираю диск из виртуального привода и включаю UEFI загрузку.

Если не случилось ничего непредвиденного вы увидите меню grub. Но не спешите жать enter! Вместо этого загрузитесь в recovery mode, потому что при импорте корневого пула zfs произойдет ошибка, вызванная тем, что последний раз пул использовался на машине с другим именем. Исправляется это просто:

zpool import -f rpool
exit

После этого у вас спросят пароль для доступа к диску и загрузка продолжится вплоть до момента, когда вам будет предложено воспользоваться аварийной консолью (потому что мы загрузились в recovery mode) или нажать ctrl-d для загрузки в обычном режиме. Нажимайте ctrl-d. Через несколько секунд вы сможете войти в систему используя созданного ранее пользователя. На этом, впрочем, наши злоключения не заканчиваются. Посмотрите на директорию /boot и вы увидите, что она пустая. Загрузочный пул тоже не был импортирован. Исправим это:

zpool import bpool

И последний штрих — отметим обе партиции EFI, как требующие обновления при изменениях grub:

dpkg-reconfigure grub-efi-amd64

Вот теперь установка системы полностью завершена и вы можете перезагрузиться и воспользоваться пунктом меню grub по умолчанию. Из-за того, что по умолчанию в параметрах ядра присутствует quiet вы увидите черный экран. Пароль на доступ к диску придется вводить вслепую через несколько секунд после начала загрузки. Вы можете убрать quiet из параметров или поставить пакет plymouth.

Все команды выше можно скачать единым скриптом, которому для работы необходимо определить переменные DISK1, DISK2, HOSTNAME и USERNAME.

Краткое руководство по собственному шифрованию OpenZFS

Увеличить / Шифрование на диске — сложная тема, но эта статья должна дать вам четкое представление о реализации OpenZFS.

Paul Downey / Flickr CC BY 2.0

Одной из многих возможностей OpenZFS является встроенное шифрование ZFS. Собственное шифрование, впервые представленное в OpenZFS 0.8, позволяет системному администратору прозрачно шифровать хранящиеся данные в самой ZFS. Это устраняет необходимость в отдельных инструментах, таких как LUKS, VeraCrypt или BitLocker.

Алгоритм шифрования OpenZFS по умолчанию использует либо aes-256-ccm (до версии 0.8.4), либо aes-256-gcm (>= 0.8.4), если установлено шифрование =on . Но это также может быть указано напрямую. В настоящее время поддерживаются следующие алгоритмы:

aes-128-ccm
aes-192-куб.см
aes-256-ccm (по умолчанию в OpenZFS < 0.8.4)
aes-128-gcm
aes-192-gcm
aes-256-gcm (по умолчанию в OpenZFS >= 0.8.4)

В родном шифровании OpenZFS есть нечто большее, чем используемые алгоритмы, поэтому мы постараемся дать вам краткое, но надежное обоснование с точки зрения системного администратора на «почему» и «что», а также простое «как». .»

Почему (или почему бы и нет) встроенное шифрование OpenZFS?

Умный системный администратор, который хочет обеспечить шифрование в состоянии покоя, на самом деле, очевидно, не нуждается в собственном шифровании OpenZFS. Как упоминалось во введении, 9Доступны 0009 LUKS , VeraCrypt и многие другие схемы, которые можно размещать либо под, либо поверх самой OpenZFS.

Во-первых, «почему бы и нет»

Помещение чего-то вроде Linux LUKS под OpenZFS имеет преимущество — весь диск зашифрован, и предприимчивый злоумышленник больше не может видеть имена, размеры или свойства наборов данных ZFS . и зволс без доступа к ключу. На самом деле злоумышленник не всегда может увидеть, что ZFS вообще используется!

Но размещение LUKS (или аналогичного) под OpenZFS имеет существенные недостатки. Одним из самых сложных является то, что каждый отдельный диск , который будет частью пула, должен быть зашифрован, при этом каждый том загружается и расшифровывается до этапа импорта пула ZFS . Это может быть заметной проблемой для систем ZFS с большим количеством дисков — в некоторых случаях много десятков дисков. Еще одна проблема с шифрованием под ZFS заключается в том, что дополнительный уровень — это дополнительная вещь, которая может пойти не так, и она может отменить все обычные гарантии целостности ZFS.

 Реклама Установка  LUKS  или аналогичного поверх OpenZFS избавляет от вышеупомянутых проблем —  LUKS  с зашифрованным  zvol  требуется только один ключ независимо от того, сколько дисков задействовано, а слой  LUKS  не может отменить гарантию целостности OpenZFS. отсюда . К сожалению, шифрование поверх ZFS создает новую проблему — оно эффективно снижает встроенное сжатие OpenZFS, поскольку зашифрованные данные, как правило, несжимаемы. Этот подход также  требует  использования одного  zvol  на зашифрованную файловую систему вместе с гостевой файловой системой (например,  ext4  ) для форматирования самого тома  LUKS   .
 Теперь «почему» 
 Собственное шифрование OpenZFS разделяет разницу: оно работает поверх обычных уровней хранения ZFS и, следовательно, не снижает собственные гарантии целостности ZFS. Но это также не мешает сжатию ZFS — данные сжимаются перед сохранением в зашифрованном наборе данных    или  zvol  .
 Однако есть еще более веская причина выбрать собственное шифрование OpenZFS — так называемая «необработанная отправка». Репликация ZFS невероятно быстра и эффективна — часто на несколько порядков быстрее, чем инструменты, не зависящие от файловой системы, такие как  rsync , — а необработанная отправка позволяет не только реплицировать зашифрованные наборы данных   s и  zvol  s, но и делать это без предоставление ключа удаленной системе.
 Это означает, что вы можете использовать репликацию ZFS для резервного0057 ненадежное местоположение , не беспокоясь о том, что ваши личные данные будут прочитаны. При необработанной отправке ваши данные реплицируются без какой-либо расшифровки — и без того, чтобы цель резервного копирования вообще могла их расшифровать. Это означает, что вы можете реплицировать свои удаленные резервные копии в доме друга или на коммерческой службе, такой как rsync.net или zfs. rent, без ущерба для вашей конфиденциальности, даже если служба (или друг) сама по себе скомпрометирована.
 Если вам нужно восстановить удаленную резервную копию, вы можете просто реплицировать ее  обратно  в ваше собственное местоположение, а затем  только , загрузив ключ дешифрования для фактического доступа к данным. Это работает как для полной репликации (перемещение каждого отдельного блока по сети), так и для асинхронной инкрементной репликации (начиная с обычно хранимого моментального снимка и перемещая только те блоки, которые изменились с момента этого моментального снимка).
 Реклама Что зашифровано, а что нет? 
 Собственное шифрование OpenZFS не является схемой шифрования всего диска — оно включается или выключается для каждого набора данных или каждого zvol, и его нельзя включить для целых пулов в целом. Содержимое зашифрованных наборов данных или zvols защищено от шпионажа в состоянии покоя, но метаданные, описывающие сами наборы данных/zvols, защищены.
 Допустим, мы создаем зашифрованный набор данных с именем  pool/encrypted  и под ним мы создаем еще несколько дочерних наборов данных. Свойство  шифрование  для дочерних элементов по умолчанию наследуется от родительского набора данных, поэтому мы можем видеть следующее:
 root@banshee:~# zfs create -o шифрование=on -o keylocation=prompt -o keyformat=passphrase banshee /зашифровано
Введите кодовую фразу:
Повторно введите кодовую фразу:

root@banshee:~# zfs create banshee/encrypted/child1
root@banshee:~# zfs создает banshee/encrypted/child2
root@banshee:~# zfs create banshee/encrypted/child3

root@banshee:~# zfs list -r banshee/encrypted
ИМЯ ИСПОЛЬЗУЕТСЯ ДОСТУПНО ССЫЛКА ТОЧКА МОНТАЖА
банши/зашифровано 1.58M 848G 432K /банши/зашифровано
банши/зашифровано/ребенок1 320K 848G 320K /банши/зашифровано/ребенок1
банши/зашифровано/ребенок2 320K 848G 320K /банши/зашифровано/ребенок2
банши/зашифровано/ребенок3 320K 848G 320K /банши/зашифровано/ребенок3

root@banshee:~# zfs получить шифрование banshee/encrypted/child1
НАЗВАНИЕ СВОЙСТВО ЗНАЧЕНИЕ ИСТОЧНИК
banshee/encrypted/child1 шифрование aes-256-gcm -
 
 На данный момент все наши зашифрованные наборы данных смонтированы. Но даже если мы размонтируем их и выгрузим ключ шифрования, сделав их недоступными, мы все равно увидим, что они  существуют  вместе со своими свойствами:
 root@banshee:~# wget -qO /banshee/encrypted/child2/HuckFinn .txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn

root@banshee:~# zfs размонтировать банши/зашифровано
root@banshee:~# zfs unload-key -r banshee/encrypted
1 / 1 ключ(и) успешно выгружен

root@banshee:~# zfs mount banshee/encrypted
не удается смонтировать «banshee/encrypted»: ключ шифрования не загружен

root@banshee:~# ls /banshee/encrypted/child2
ls: невозможно получить доступ к '/banshee/encrypted/child2': нет такого файла или каталога

root@banshee:~# zfs list -r banshee/encrypted
ИМЯ ИСПОЛЬЗУЕТСЯ ДОСТУПНО ССЫЛКА ТОЧКА МОНТАЖА
банши/зашифровано 2.19M 848G 432K /банши/зашифровано
банши/зашифровано/ребенок1 320K 848G 320K /банши/зашифровано/ребенок1
банши/зашифровано/ребенок2 944K 848G 720K /банши/зашифровано/ребенок2
банши/зашифровано/ребенок3 320K 848G 320K /банши/зашифровано/ребенок3
 
 Как мы видим выше, после выгрузки ключа шифрования мы больше не можем видеть нашу только что загруженную копию  Huckleberry Finn  в  /banshee/encrypted/child2/  . Что мы можем   до сих пор видят существование и структуру всего нашего дерева, зашифрованного с помощью ZFS. Мы также можем видеть свойства каждого зашифрованного набора данных, включая, помимо прочего,  USED  ,  AVAIL  и  REFER  каждого набора данных.
 Стоит отметить, что попытка  ls   зашифрованного набора данных, для которого не загружен ключ, не обязательно приведет к ошибке:
 root@banshee:~# zfs get keystatus banshee/encrypted
НАЗВАНИЕ СВОЙСТВО ЗНАЧЕНИЕ ИСТОЧНИК
банши/статус зашифрованного ключа недоступен -
root@banshee:~# ls /banshee/encrypted
root@банши:~#
 
 Это связано с тем, что на хосте существует открытый каталог, даже если фактический набор данных не смонтирован. Повторная загрузка ключа также не приводит к автоматическому перемонтированию набора данных:
 root@banshee:~# zfs load-key -r banshee/encrypted
Введите кодовую фразу для «banshee/encrypted»:
1 / 1 ключ(и) успешно загружены
root@banshee:~# монтирование zfs | grep encr
root@banshee:~# ls /banshee/encrypted
root@banshee:~# ls /banshee/encrypted/child2
ls: невозможно получить доступ к '/banshee/encrypted/child2': нет такого файла или каталога 
 Чтобы получить доступ к нашей новой копии  Huckleberry Finn  , нам также потребуется смонтировать только что загруженные наборы данных с ключом:
 root@banshee:~# zfs get keystatus banshee/encrypted/child2
НАЗВАНИЕ СВОЙСТВО ЗНАЧЕНИЕ ИСТОЧНИК
статус ключа banshee/encrypted/child2 доступен -

root@banshee:~# ls -l /banshee/encrypted/child2
ls: невозможно получить доступ к '/banshee/encrypted/child2': нет такого файла или каталога

root@banshee:~# zfs mount -a
root@banshee:~# ls -lh /banshee/encrypted/child2
всего 401 тыс. 
-rw-r--r-- 1 root root 554K 13 июня 2002 г. HuckFinn.txt
 
 Теперь, когда мы оба загрузили необходимый ключ  и  смонтировали наборы данных, мы снова можем видеть наши зашифрованные данные.
 Собственное шифрование OpenZFS | Klara Inc 
 Начиная с версии 13.0, FreeBSD поддерживает долгожданную собственную функцию шифрования OpenZFS. Если вы использовали шифрование GELI FreeBSD в прошлом, у вас могут возникнуть вопросы относительно различий между двумя схемами шифрования, следует ли вам переходить на собственное шифрование OpenZFS и как реализовать его в вашей среде.  Эта статья начинается с краткого описания пользовательских различий между шифрованием диска FreeBSD GELI и собственным шифрованием OpenZFS, включая их преимущества и ограничения. Затем приводятся примеры создания зашифрованных наборов данных и управления ими.
 GELI и собственное шифрование OpenZFS  С точки зрения конечного пользователя, самая большая разница между собственным шифрованием GELI и OpenZFS заключается в том, что шифруется. Для упрощения GELI шифрует  диски   в то время как OpenZFS шифрует  наборов данных  . Давайте рассмотрим это различие более внимательно:
  Шифрование диска GELI:  думайте об этом как о независимом от файловой системы механизме шифрования «все или ничего», который защищает физические блочные устройства (диски) ниже уровня файловой системы. Во время загрузки каждый диск, защищенный GELI, должен быть расшифрован, прежде чем можно будет продолжить загрузку системы и смонтировать вышестоящую файловую систему. Для системы, использующей ZFS, это означает, что каждый зашифрованный с помощью GELI диск в пуле должен быть расшифрован, прежде чем пул можно будет импортировать, что усложняет системы с большим количеством дисков. Хуже того, ZFS не знает, что работает поверх зашифрованных устройств.
  ПРИМЕЧАНИЕ.   Программа установки 13.0 реализует GELI, если вы выберете параметр «шифрование» в управляемом разделе ZFS программы установки. Рекомендуется не выбирать этот параметр во время установки, если вы собираетесь использовать встроенную поддержку шифрования OpenZFS.
  Шифрование набора данных OpenZFS:   в отличие от шифрования «все или ничего», собственное шифрование OpenZFS применяется для каждого набора данных. Это дает возможность смешивать зашифрованные и незашифрованные наборы данных в одном пуле и означает, что вам не нужно расшифровывать все наборы данных при подключении или импорте пула.
  Что касается ввода парольной фразы для ключа:   в системе GELI запрос пароля для ключа происходит в начале процесса загрузки; после расшифровки система продолжает загружаться в обычном режиме. В системе с наборами данных, зашифрованными с помощью собственного шифрования OpenZFS, загрузка происходит нормально   , но зашифрованные наборы данных не монтируются до загрузки ключа.  
 Преимущества встроенного шифрования OpenZFS  С точки зрения системного администратора, использование встроенного шифрования дает множество преимуществ по сравнению с запуском ZFS поверх дисков с шифрованием GELI. Самым большим преимуществом является то, что вам не нужно монтировать зашифрованные наборы данных (для чего требуется доступ с ключом), чтобы выполнять административные задачи ZFS с помощью  zfs  или  zpool  команды. Это означает, что вы можете выполнять очистку, восстановление, создание моментальных снимков, репликацию и другие задачи по обслуживанию несмонтированных зашифрованных наборов данных, не требуя доступа к ключу.
 Все проверки целостности данных ZFS понимают собственное шифрование, даже если зашифрованные наборы данных размонтированы. Сжатие ZFS поддерживает собственное шифрование, что позволяет сжимать данные при сохранении в зашифрованном наборе данных.
 Можно реплицировать моментальные снимки незашифрованных наборов данных в зашифрованные наборы данных, включив  -x параметр шифрования  в команде  zfs recv . И наоборот, можно реплицировать моментальные снимки зашифрованных наборов данных в незашифрованные наборы данных. И, наконец, можно безопасно копировать моментальные снимки, включив параметр  -w  (необработанная отправка) в команду  zfs send  . Необработанная отправка позволяет выполнять репликацию в ненадежное расположение, поскольку данные остаются зашифрованными, а ключ не подвергается воздействию ненадежного расположения.
 Что нужно знать  Несмотря на то, что собственное шифрование OpenZFS во FreeBSD дает множество преимуществ, следует помнить о нескольких вещах, о которых следует помнить, поскольку они влияют на решения по проектированию вашей файловой системы:   . Поначалу это может показаться неинтуитивным и заставляет вас думать, где в пуле должны находиться ваши конфиденциальные данные. Это добавляет гибкости макету, поскольку вы можете выбирать, какие наборы данных защищать с помощью шифрования. Он также позволяет шифровать разные наборы данных с помощью разных ключей.
   Шифрование можно включить только во время создания набора данных   . К счастью, свойство шифрования для дочерних наборов данных по умолчанию наследуется от родительского набора данных. Поскольку вы не можете установить свойство шифрования для существующего набора данных, необходимость создания нового зашифрованного набора данных является более серьезной проблемой, если у вас уже есть много данных, находящихся в настоящее время в незашифрованных наборах данных. Решение состоит в том, чтобы создать зашифрованный набор данных и переместить конфиденциальные данные из их старого местоположения.
 Собственное шифрование    не шифрует все метаданные   . Вот почему задачи обслуживания по-прежнему можно выполнять с несмонтированным зашифрованным набором данных. Доступны некоторые метаданные ZFS, такие как имя, размер, использование и свойства набора данных. Однако количество и размеры отдельных файлов, а также содержимое самих файлов недоступны без ключа дешифрования.
 Загрузчик FreeBSD еще не поддерживает загрузку из зашифрованного набора данных.
 Создание зашифрованного набора данных  Давайте подробнее рассмотрим собственное шифрование в действии. У нас есть тестовая система FreeBSD 13.0 из установки по умолчанию. Вот смонтированные в настоящее время файловые системы:
 Поскольку шифрование применяется к каждому набору данных и применяется при создании набора данных, мы создадим новый зашифрованный набор данных в пуле  zroot  с именем  зашифровано.   Параметры командной строки (  -o  ) указывают, что мы хотим включить шифрование, будем использовать кодовую фразу и хотим, чтобы нам предлагалось ввести парольную фразу при каждом подключении набора данных. Обратите внимание, что парольная фраза должна быть запоминающейся (для вас), трудно угадываемой (для других) и иметь длину не менее 8 символов:
 Мы можем убедиться, что новый зашифрованный набор данных смонтирован; он был смонтирован во время создания, так как нам было предложено ввести парольную фразу:
 Мы можем убедиться, что новый набор данных зашифрован, запросив список его свойств шифрования:
  aes-256-gcm  — это алгоритм шифрования; значение по умолчанию для FreeBSD является самым сильным, доступным в настоящее время. Другие свойства указывают на то, что нам будет предложено ввести парольную фразу при монтировании набора данных. Поскольку это тестовая система, мы перезагрузимся и продемонстрируем, что зашифрованный набор данных не монтируется автоматически:
 Обратите внимание, что первая команда  zfs mount  завершилась неудачно, так как ключи шифрования не загружаются автоматически во время загрузки. Также обратите внимание, что мы не можем смонтировать набор данных до загрузки ключей. Команда  zfs load-key  используется для загрузки ключей шифрования. Мы попросили загрузить ключ для указанного набора данных;  load-key   прочитал свойства шифрования набора данных и предложил нам ввести парольную фразу. Затем мы смогли успешно смонтировать набор данных и убедиться, что он смонтирован.
 После загрузки ключа мы можем  zfs размонтировать  и  zfs смонтировать  без дополнительных запросов.
 Что произойдет, если мы попытаемся выгрузить ключ, пока зашифрованный набор данных все еще смонтирован?
 Другими словами, при монтировании зашифрованного набора данных его ключ остается загруженным, чтобы ZFS могла шифровать/дешифровать данные по мере их чтения и записи в набор данных. Если вы не хотите перемонтировать набор данных после его размонтирования, выгрузите его ключ. Не забывайте, что задачи обслуживания ZFS могут по-прежнему выполняться для несмонтированных наборов данных, даже если их ключи выгружены.
  Повторный доступ к зашифрованному набору данных   В этом примере у нас есть незашифрованный пул, который уже содержит данные, и мы хотим переместить эти данные в зашифрованные наборы данных. В пуле остается много свободного места, что обеспечивает достаточно места для локальной репликации существующих данных, чтобы мы могли протестировать миграцию данных перед уничтожением исходных незашифрованных наборов данных.
 Перед тем, как продолжить, есть небольшая проблема с курицей и яйцом, так как FreeBSD в настоящее время должна загружаться с незашифрованным набором данных (что также означает, что мы не хотим уничтожать незашифрованный корневой набор данных!). К счастью, мы можем просто переключиться на зашифрованную версию корневого набора данных после загрузки — этот процесс известен как 9. 0057 перепрошивка  .
 Давайте начнем с нуля в этой системе. Сначала мы создадим рекурсивный снимок всего  пула zroot :
 zfs snap -R zroot@backup 
 Затем мы создадим зашифрованный набор данных:
 zfs create -o Encryption=on -o keyformat =passphrase -o keylocation=prompt zroot/encrypted 
 Далее мы реплицируем моментальный снимок пула в зашифрованный набор данных.  -R  в команде  zfs send  рекурсивно отправляет все наборы данных в пуле моментальных снимков.  -x шифрование   в команде  zfs recv  указывает, что получаемый набор данных зашифрован. Обратите внимание, что приемная часть команды завершится ошибкой, если вы не укажете местоположение, которого еще не существует! В этом примере мы решили сохранить имя  zroot  , но поместили его ниже родительского набора данных с именем  зашифровано  :
 zfs send -v -R zroot@backup | zfs recv -x шифрование zroot/encrypted/zroot 
 Если мы введем  mount  после завершения репликации, то увидим кое-что интересное:
 Зашифрованные наборы данных определенно заполняются из моментального снимка. Но какие данные монтируются? Например, заполняется ли /mountpoint  zroot/ROOT/default  или  zroot/encrypted/zroot/ROOT/default ? Чтобы узнать это, получите значение свойства шифрования:
 zfs получить шифрование /
НАЗВАНИЕ СВОЙСТВО ЗНАЧЕНИЕ ИСТОЧНИК
zroot/ROOT/шифрование по умолчанию отключено по умолчанию
 
 Это имеет смысл, поскольку FreeBSD загружается с незашифрованным корневым набором данных. Вы можете повторить эту команду для каждой из точек монтирования, чтобы убедиться, что незашифрованные наборы данных — это те, которые монтируются в данный момент. Чтобы переключиться на зашифрованные наборы данных, измените  vfs.root.mount from  с помощью команды  kenv . Во-первых, давайте посмотрим на его значение по умолчанию:
 kenv vfs.root.mountfrom
zfs:zroot/ROOT/по умолчанию
 
 Затем укажите то же местоположение, но в зашифрованном наборе данных. В этом примере это:
 kenv vfs.root.mountfrom=zfs:zroot/encrypted/zroot/ROOT/default 
 Далее,     используйте эту команду для завершения работы системы без выгрузки ядра, чтобы она могла перезапустить с указанным зашифрованным набором данных, смонтированным как root:
 reboot -r 
 Вы можете подтвердить, что теперь система использует зашифрованные наборы данных, повторив предыдущую команду  zfs get  :
 zfs get шифрование /
НАЗВАНИЕ СВОЙСТВО ЗНАЧЕНИЕ ИСТОЧНИК
zroot/encrypted/zroot/ROOT/шифрование по умолчанию aes-256-gcm -
 
 Чтобы удалить незашифрованные наборы данных из вывода  mount  , установите для свойства  mountpoint  каждого незашифрованного набора данных значение  legacy  и добавьте эти файловые системы в /  и т. д./fstab.  Например, чтобы установить устаревшую точку монтирования для /  usr  /  home  и /  var/tmp: 
 zfs set mountpoint=legacy zroot/usr/home
zfs устанавливает точку монтирования = устаревший zroot/var/tmp
 
 Затем добавьте записи для этих файловых систем в /  и т. д.  /  fstab  :
 # Точка монтирования устройства FStype Options Dump Pass#
zroot/usr/дом /usr/дом zfs rw 0 0
zroot/var/tmp /var/tmp zfs rw 0 0
 
 Предложения для более сложных сценариев  Пример в этой статье демонстрирует базовый рабочий процесс для использования собственного шифрования OpenZFS:
 Создайте зашифрованный набор данных и, возможно, скопируйте в него существующие конфиденциальные данные.
 Чтобы предоставить доступ для чтения/записи к зашифрованному набору данных после загрузки системы (или после размонтирования и выгрузки ключа для зашифрованного набора данных), сначала загрузите ключ, а затем смонтируйте зашифрованный набор данных. Это позволяет удаленным безголовым системам загружаться в базовую систему, в которую вы можете войти по SSH, чтобы ввести парольную фразу, а затем повторно войти в зашифрованную систему.
 Чтобы остановить доступ для чтения/записи к зашифрованному набору данных, размонтируйте его и выгрузите его ключ.
 Этот базовый рабочий процесс можно изменить для более сложных сценариев, содержащих несколько зашифрованных наборов данных и зашифрованных дочерних наборов данных. Например, в загруженной системе со многими зашифрованными наборами данных вы, вероятно, не захотите вводить кучу парольных фраз и вручную монтировать несколько файловых систем после каждой загрузки системы! Вот несколько ресурсов, которые помогут вам упростить стратегию монтажа:
 Команды load-key и unload-key предоставляют рекурсивные (  -r  ) и все (  -a  ) переключатели для работы с несколькими наборами данных. Подробнее об использовании см. в zfs-load-key(8) и zfs-unload-key(8).
 Использование подсказки   для ключа   подходит для систем с небольшим количеством зашифрованных наборов данных или в тех случаях, когда монтирование всех наборов данных во время загрузки не критично. Это также может быть необходимо в средах, где политика безопасности требует, чтобы человек вводил парольные фразы вручную. Системы, которые лучше подходят для автоматического монтирования всех наборов данных при загрузке системы, должны использовать  keyfile   для  ключа  и либо  hex  , либо  raw  для  keyformat.  Дополнительные сведения о том, как создать файл ключа, см. в описании ключевого файла и его расположения в zfs-props(8).
 При автоматическом монтировании с помощью ключевого файла добавьте  -l  (загрузить ключи) к любому скрипту  zpool import .
 Чтобы изменить расположение или формат ключа, используйте zfs-change-key(8). Несмотря на название, эта команда на самом деле не изменяет мастер-ключ, который используется для шифрования/дешифрования.