ZFS anlık görüntülerini send/receive işlemi sırasında şifreleyerek güvenli yedek akışları sağlamak

ZFS anlık görüntülerini sistemler arasında taşımam gerektiğinde, özellikle güvensiz ağlar üzerinden, gizlilik için temel taşıma mekanizmasına güvenmem. Bunun yerine, zfs send akışını OpenSSL veya age üzerinden şifreleyerek, alıcı tarafında şifresini çözerek akışı kendisi şifreler. Bu sayede, hedef sistemde tam-disk şifrelemesi gerektirmeden yedek verileri hem dinlenmekte hem de aktarım sırasında şifreli tutarım. İşte bu ortamda nasıl yapıyorum:

Akışı neden şifreliyken sadece diski değil şifreliyoruz?

Tam-disk şifrelemesi, verileri dinlenme halinde korur, ancak yedek gönderildikten sonra, zfs send | ssh gibi ham bir komut kullanıyorsanız akış düz metin olarak kalır. Ağda dinleme yapan bir saldırgan veya ara makineyi ele geçiren bir saldırgan, anlık görüntülerinizi okuyabilir. Akışı şifreleyerek, akış ele geçirilir veya güvensiz bir ortamda saklansa bile, sadece şifre çözme anahtarının sahibi yedeği yeniden oluşturabilir.

Bu yaklaşım, yerel ZFS şifrelemesini desteklemeyen uzak sistemlere veya depolama katmanını kontrol etmediğim sistemlere yedek göndermeyi de mümkün kılar—örneğin kiralanmış bir yedek sunucusu veya bir arkadaşın NAS cihazı gibi.

OpenSSL ile Şifreleme (simetrik anahtar)

Basitlik ve uyumluluk açısından, önceden paylaşılmış bir anahtar kullanarak OpenSSL sıkça tercih ederim. İlk olarak bir anahtar üretir ve onu her iki uçta da güvenli bir şekilde saklarım:

# 32 baytlık anahtar üret (256-bit)
head -c 32 /dev/urandom > /root/backup.key
chmod 600 /root/backup.key

Kaynak sistemde, gönderim akışını OpenSSL şifrelemesiyle birleştiririm:

zfs send tank/data@snap1 | \
  openssl enc -aes-256-cbc -md sha256 -pass file:/root/backup.key | \
  ssh backup@remote 'cat > /tmp/snap1.enc'

Uzak sistemde, işlemi tersine çeviririm:

ssh backup@remote 'cat /tmp/snap1.enc' | \
  openssl enc -d -aes-256-cbc -md sha256 -pass file:/root/backup.key | \
  zfs recv backup/tank/data

-md sha256 seçeneği, güçlü bir anahtar türetme fonksiyonu sağlar. Otomatik betiklerde -salt kullanmaktan kaçınırım; çünkü dikkatli yönetilmedikçe determinizmi bozar—burada ise anahtar dosyası yeterli entropi sağlar.

Yaş için modern şifreleme kullanımı

OpenSSL'den daha basit ve daha modern bir şey istiyorsam age kullanırım. Dosya şifrelemesi için tasarlanmıştır ve akışlarla iyi çalışır. Genel anahtar ile şifrelerim ve karşılık gelen özel anahtar ile çözerim.

İlk olarak bir anahtar çifti oluştururum:

age-keygen -o /root/age.key
# Genel anahtarı çıkar
age-keygen -y /root/age.key > /root/age.key.pub

Daha sonra şifrelenmiş akışı gönderirim:

zfs send tank/data@snap1 | \
  age -r $(cat /root/age.key.pub) | \
  ssh backup@remote 'cat > /tmp/snap1.age'

Şifreyi çöz ve al:

ssh backup@remote 'cat /tmp/snap1.age' | \
  age -d -i /root/age.key | \
  zfs recv backup/tank/data

age’i tercih ederim çünkü yanlış yapılandırmak daha zor—şifre modu yok, tuz yönetimi yok—ve anahtarlar basitçe yönetilebilir.

Bir sarma betiğiyle otomasyon

Komutu tekrarlamamak için şifreleme, aktarım ve şifre çözme işlemlerini yöneten küçük bir betik kullanıyorum. OpenSSL için bir versiyonu şu şekildedir:

#!/bin/bash
set -euo pipefail

SNAPSHOT="$1"
REMOTE_HOST="$2"
REMOTE_POOL="$3"
KEYFILE="/root/backup.key"

if [[ ! -f "$KEYFILE" ]]; then
  echo "Şifreleme anahtarı bulunamadı: $KEYFILE" >&2
  exit 1
fi

zfs send "$SNAPSHOT" | \
  openssl enc -aes-256-cbc -md sha256 -pass file:"$KEYFILE" | \
  ssh "$REMOTE_HOST" "cat > /tmp/$(basename "$SNAPSHOT").enc"

ssh "$REMOTE_HOST" "\
  openssl enc -d -aes-256-cbc -md sha256 -pass file:"$KEYFILE" < /tmp/$(basename "$SNAPSHOT").enc | \
  zfs recv "$REMOTE_POOL" && \
  rm -f /tmp/$(basename "$SNAPSHOT").enc"

Betiği çalıştırılabilir yapıp şu şekilde çağırıyorum:

./zfs-send-encrypt.sh tank/data@snap1 backup.example.com backup/tank

Betik, alım başarıyla tamamlandıktan sonra uzak taraftaki geçici şifrelenmiş dosyayı temizler.

Anahtar yönetimi ve döndürme

Şifreleme anahtarını diğer kimlik bilgileri gibi ele alırım: bir parola yöneticisi veya gizli bilgiler kasasında saklanır, periyodik olarak döndürülür ve sürüm kontrolüne asla işlenmez. Otomatik yedeklemeler için, anahtarı izinleri sıkı (600) olan bir dosyadan yüklerim ve betiğin root olarak veya özel bir yedekleme kullanıcısı olarak çalıştırılmasını sağlarım.

age kullanıyorsam, özel anahtarı çevrimdışı tutar ve gerektiğinde hedef sistemde yalnızca şifresini çözerim—kritik sistemler için SSH anahtarlarını ele alma yöntemiyle benzer bir şekilde.

Performans konuları

Şifreleme CPU yükü ekler, ancak modern sistemlerde AES-NI, OpenSSL aes-256-cbc'yi çok hızlı hâle getirir—çoğu zaman CPU yerine disk veya ağ hızı sınırlayıcı olur. age, modern kriptografi (X25519, ChaCha20-Poly1305) kullanır ve aynı şekilde verimlidir.

Testlerimde, 100 GB'lık bir ZFS akışını şifrelemek, Xeon E5-2680 v4 üzerinde %5'ten az CPU kullanımına yol açtı ve 1 Gbps bağlantıyı doyurmadı. Eski donanım kullanıyorsanız önce benchmark yapın, ancak çoğu sunucu için etkisi néglible (önemsiz) düzeydedir.

Bütünlüğü Doğrulama

Şifreleme, sağlama toplamlarını etkilemediğinden, ZFS’nin yerleşik bütünlük kontrolleri hâlâ çalışır. Alındıktan sonra şu komutu çalıştırıyorum:

zfs diff backup/tank/data@snap1 backup/tank/data@snap2

Bu, akışın şifresinin çözülüp doğru şekilde alındığını onaylamak için. Aktarım sırasında oluşan herhangi bozulma, zfs recv komutunu sağlama toplamı hatasıyla başarısız olmasına neden olur.

Akışı Şifrelemekten Kaçınılması Gereken Durumlar

Her iki uç da güvenilir ve izole bir ağda ise (örneğin internete maruz kalmayan özel bir yedek VLAN gibi) ve depolama zaten durda iken şifreleniyorsa, basitlik açısından akış şifrelemesini atlayabilirim. Ancak bir yönlendirici, güvenlik duvarı veya üçüncü taraf altyapı üzerinden geçen her şey için varsayılan olarak şifreleme yaparım.

Son düşünceler

ZFS gönder/al akışlarını şifrelemek, depolama kurulumunuzu değiştirmeden yedeklerinize uçtan uca gizlilik eklemek için hafif bir yoldur. OpenSSL ile uyumluluk için veya age ile modern basitlik için kullanıyorsanız, anahtarı iyi yönetmek anahtardır—anahtarı bir kök şifresi gibi ele alın.

Yıllardır bu yöntemi kullanarak kenar sitelerinden merkezi bir kasa’ya günlük anlık görüntüler gönderiyorum ve bu, yedek sunucusu ele geçirilse bile anahtar olmadan veri okunamaz kalacağını bildiğim için rahat ediyorum.

ZFS anlık görüntülerini zaten kullanıyorsanız ([seviye düzeyi kurtarma](https://furkanikkan.com/urun/snapshot-yedekleme-ve-hizli-kurtarma-saniyede-block-level-geri-yukleme-64) konulu yazımda da bahsettiğim gibi), akış şifrelemesini eklemek, hareket halindeki verileri güvence altına almak için mantıklı bir sonraki adımdır.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M