Şifreli Yedekleme Yapılandırması: Bacula Güvenliği

Tarafındankomut
0 Comments

Yedekleme sistemleri kurduğunuzda genellikle ilk düşündüğünüz şey “verilerimi güvenli bir yere kopyalayalım” oluyor. Ama güvenli yer derken çoğu zaman fiziksel güvenliği kastediyoruz; teyp rafı kilitli mi, NAS cihazı sunucu odasında mı gibi sorular. Oysa şifreli olmayan bir yedekleme, fiziksel olarak elinizde olsa bile ciddi bir güvenlik açığı demektir. Bacula kullanıyorsanız şans sizin tarafınızda çünkü bu sistem, yedekleme verilerini şifrelemeniz için oldukça kapsamlı araçlar sunuyor. Bu yazıda Bacula’da şifreli yedekleme yapılandırmasını gerçek dünya senaryolarıyla adım adım ele alacağız.

Neden Şifreli Yedekleme Şart?

Bir müşteri hikayesiyle başlayalım. Orta ölçekli bir şirketin BT altyapısını denetlediğinizde Bacula ile güzelce yapılandırılmış bir yedekleme sistemi görüyorsunuz. Günlük full ve incremental yedekler çalışıyor, retention policy ayarlı, raporlar mail ile geliyor. Tek sorun: yedekler tamamen açık metin olarak NAS’a yazılıyor. O NAS cihazına erişim için şirket ağına girmeniz yeterli. Bir çalışan ya da ağa sızan bir saldırgan tüm yedekleri olduğu gibi okuyabiliyor.

Bu senaryo ne kadar yaygın? Şifreli yedekleme yapılandırması düşündüğünüzden çok daha az yaygın. Çünkü kurulum aşamasında “şifreli yedek” seçeneği çekici gelmiyor, performans kaygısı var, anahtar yönetimi karmaşık geliyor. Ama GDPR, KVKK ve PCI-DSS gibi düzenlemeleri düşündüğünüzde şifreli yedekleme artık “iyi olur” kategorisinden “zorunlu” kategorisine geçmiş durumda.

Bacula’nın sunduğu şifreleme PKI tabanlıdır. Yani asimetrik şifreleme kullanıyor. Bu yaklaşım hem güvenli hem de anahtar yönetimi açısından esnek bir yapı sunuyor.

Bacula Şifreleme Mimarisi

Bacula’nın şifreleme mekanizmasını anlamak yapılandırmayı çok kolaylaştırıyor. Sistem şu şekilde çalışıyor:

  • File Daemon (fd) tarafında şifreleme gerçekleşir, Storage Daemon tarafında değil
  • Veriler istemci tarafında şifrelenir ve Storage Daemon bu veriyi göremez
  • PKI altyapısı kullanılır: her istemci için bir sertifika çifti gerekir
  • Master key mekanizması ile merkezi anahtar yönetimi yapılabilir

Bu mimari özellikle önemli çünkü Storage Daemon’a ya da Bacula Director’a erişimi olan birinin bile şifreli yedekleri okuyamaması anlamına geliyor. Veri, istemci makinede şifreleniyor ve yalnızca doğru private key ile deşifre edilebiliyor.

OpenSSL ile Sertifika Üretimi

Şifreli yedekleme için önce PKI altyapısını kurmamız gerekiyor. Her File Daemon için bir sertifika çifti oluşturacağız ve isteğe bağlı olarak bir master key yapılandıracağız.

Önce bir CA (Certificate Authority) oluşturalım. Üretim ortamında kurumsal CA kullanmak daha iyi olsa da test ve hatta birçok üretim ortamı için self-signed CA yeterli:

# CA dizini oluştur
mkdir -p /etc/bacula/ssl/{ca,clients,master}
cd /etc/bacula/ssl/ca

# CA private key oluştur
openssl genrsa -aes256 -out ca-key.pem 4096

# CA sertifikası oluştur (10 yıl geçerli)
openssl req -new -x509 -days 3650 
  -key ca-key.pem 
  -out ca-cert.pem 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/OU=IT/CN=BaculaCA"

# İzinleri düzenle
chmod 600 ca-key.pem
chmod 644 ca-cert.pem

Şimdi bir istemci (File Daemon) için sertifika oluşturalım:

# İstemci için private key
cd /etc/bacula/ssl/clients
openssl genrsa -out webserver01-key.pem 2048

# CSR (Certificate Signing Request) oluştur
openssl req -new 
  -key webserver01-key.pem 
  -out webserver01-csr.pem 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/OU=IT/CN=webserver01.sirket.com"

# CA ile imzala
openssl x509 -req -days 1825 
  -in webserver01-csr.pem 
  -CA ../ca/ca-cert.pem 
  -CAkey ../ca/ca-key.pem 
  -CAcreateserial 
  -out webserver01-cert.pem

# Bacula'nın beklediği formatta birleştir (cert + key aynı dosyada)
cat webserver01-cert.pem webserver01-key.pem > webserver01-combined.pem
chmod 600 webserver01-combined.pem
chmod 644 webserver01-cert.pem

Master Key Yapılandırması

Master key mekanizması Bacula’nın çok kullanışlı bir özelliği. Normal şifreleme senaryosunda yedekleri geri yüklemek için o istemcinin private key’ine ihtiyaç duyarsınız. İstemci çöktüyse ve private key dosyası kayboldu ise ne yaparsınız? İşte bu noktada master key devreye giriyor.

Master key ile tüm istemcilerin yedeklerini tek bir merkezi key ile de deşifre edebiliyorsunuz. Bu anahtarı güvenli bir yerde (tercihen offline, HSM veya şifreli USB) saklarsanız felaket senaryolarında hayat kurtarıcı oluyor.

# Master key çifti oluştur
cd /etc/bacula/ssl/master

# Master private key (güçlü parola ile)
openssl genrsa -aes256 -out master-key.pem 4096

# Master sertifika
openssl req -new -x509 -days 3650 
  -key master-key.pem 
  -out master-cert.pem 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/OU=IT/CN=BaculaMasterKey"

chmod 600 master-key.pem
chmod 644 master-cert.pem

# Master key'i offline yedeğe kopyala
# Bu adımı ASLA atlama!
# cp master-key.pem /media/encrypted-usb/bacula-master-key-backup.pem

File Daemon Şifreleme Yapılandırması

Sertifikalar hazır, şimdi File Daemon tarafında şifrelemeyi aktif edelim. Her istemcideki bacula-fd.conf dosyasını düzenleyeceğiz:

# /etc/bacula/bacula-fd.conf

FileDaemon {
  Name = webserver01-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  Maximum Concurrent Jobs = 20
  
  # PKI Şifreleme Yapılandırması
  PKI Signatures = Yes
  PKI Encryption = Yes
  
  # Bu istemcinin sertifika ve key'i
  PKI Keypair = "/etc/bacula/ssl/clients/webserver01-combined.pem"
  
  # CA sertifikası (imza doğrulama için)
  PKI CA = "/etc/bacula/ssl/ca/ca-cert.pem"
  
  # Master key sertifikası (sadece public key yeterli)
  PKI Master Key = "/etc/bacula/ssl/master/master-cert.pem"
}

Yapılandırmayı doğrulamak için:

# Syntax kontrolü
bacula-fd -t -c /etc/bacula/bacula-fd.conf

# Servisi yeniden başlat
systemctl restart bacula-fd

# Log kontrolü
journalctl -u bacula-fd -n 50 --no-pager | grep -i "pki|encrypt|error"

TLS İletişim Güvenliği

Şifreleme sadece depolanan veri için değil, aktarım sırasında da gerekli. Bacula bileşenleri arasındaki iletişim (Director-FD, Director-SD, Console-Director) TLS ile korunabilir. Bu özellikle WAN üzerinden ya da güvenilir olmayan ağ segmentlerinde çalışan File Daemon’lar için kritik.

Director yapılandırması (bacula-dir.conf):

# Director TLS yapılandırması
Director {
  Name = bacula-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/run/bacula"
  Maximum Concurrent Jobs = 20
  
  # TLS Director tarafı
  TLS Enable = Yes
  TLS Require = Yes
  TLS Verify Peer = Yes
  TLS CA Certificate File = "/etc/bacula/ssl/ca/ca-cert.pem"
  TLS Certificate = "/etc/bacula/ssl/director/director-cert.pem"
  TLS Key = "/etc/bacula/ssl/director/director-key.pem"
}

# Client tanımında TLS
Client {
  Name = webserver01-fd
  Address = 192.168.1.101
  FDPort = 9102
  Catalog = MyCatalog
  Password = "gizli-parola-buraya"
  
  TLS Enable = Yes
  TLS Require = Yes
  TLS CA Certificate File = "/etc/bacula/ssl/ca/ca-cert.pem"
  TLS Certificate = "/etc/bacula/ssl/director/director-cert.pem"
  TLS Key = "/etc/bacula/ssl/director/director-key.pem"
}

Storage Daemon için de benzer yapılandırma gerekiyor:

# /etc/bacula/bacula-sd.conf Storage TLS

Storage {
  Name = File-Storage
  SDPort = 9103
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  
  TLS Enable = Yes
  TLS Require = Yes
  TLS Verify Peer = Yes
  TLS CA Certificate File = "/etc/bacula/ssl/ca/ca-cert.pem"
  TLS Certificate = "/etc/bacula/ssl/storage/storage-cert.pem"
  TLS Key = "/etc/bacula/ssl/storage/storage-key.pem"
}

Şifreli Yedekleme Testi ve Doğrulama

Yapılandırmayı tamamladıktan sonra gerçekten şifreli yedek alınıp alınmadığını doğrulamanız gerekiyor. Bunu kabul etmeden güvende olduğunuzu varsaymak tehlikeli.

# bconsole ile test yedek çalıştır
bconsole << EOF
run job=webserver01-job level=Full yes
wait
messages
quit
EOF

# Yedek dosyasının şifreli olup olmadığını kontrol et
# Bacula yedek dosyaları .bsr ve volume dosyalarında saklanır
# Storage'da volume dosyasına bak

# Volume başlıklarını incele
bls -V Volume001 /var/lib/bacula/storage/ 2>&1 | head -50

# Şifrelenmiş içerik okuma denemesi (başarısız olmalı)
strings /var/lib/bacula/storage/Volume001 | grep -i "passwd|password|secret" | head -10
# Eğer burada bir şey çıkıyorsa şifreleme çalışmıyor demektir!

Doğrulama için daha kapsamlı bir test scripti:

#!/bin/bash
# /usr/local/bin/test-backup-encryption.sh

VOLUME_PATH="/var/lib/bacula/storage"
LOG_FILE="/var/log/bacula/encryption-test.log"
ALERT_EMAIL="[email protected]"

echo "=== Bacula Şifreleme Testi - $(date) ===" >> "$LOG_FILE"

# Son yedek volume dosyasını bul
LATEST_VOLUME=$(ls -t "$VOLUME_PATH"/*.vol 2>/dev/null | head -1)

if [ -z "$LATEST_VOLUME" ]; then
    echo "HATA: Volume dosyası bulunamadı!" >> "$LOG_FILE"
    exit 1
fi

echo "Test edilen volume: $LATEST_VOLUME" >> "$LOG_FILE"

# Açık metin hassas veri araması
SENSITIVE_PATTERNS=("password" "passwd" "secret" "BEGIN CERTIFICATE" "PRIVATE KEY")
FOUND_PLAIN=0

for pattern in "${SENSITIVE_PATTERNS[@]}"; do
    COUNT=$(strings "$LATEST_VOLUME" | grep -ic "$pattern" 2>/dev/null)
    if [ "$COUNT" -gt 0 ]; then
        echo "UYARI: '$pattern' pattern'i $COUNT kez açık metin olarak bulundu!" >> "$LOG_FILE"
        FOUND_PLAIN=1
    fi
done

if [ "$FOUND_PLAIN" -eq 1 ]; then
    echo "KRİTİK: Şifreleme doğrulaması BAŞARISIZ!" >> "$LOG_FILE"
    mail -s "BACULA ŞİFRELEME ALARMII" "$ALERT_EMAIL" < "$LOG_FILE"
    exit 2
else
    echo "OK: Şifreleme doğrulaması başarılı." >> "$LOG_FILE"
fi

Felaket Kurtarma: Master Key ile Geri Yükleme

En kritik senaryolardan biri şu: istemci makinesi tamamen yandı, hem uygulama hem de Bacula File Daemon’u kurduğunuz diske gitti. Yeni bir sunucu kuruyorsunuz ve yedekten geri yüklemeniz gerekiyor ama o istemciye ait sertifika ve private key de gitti.

İşte bu durumda master key kullanmanız gerekiyor:

# Yeni sunucuda geçici File Daemon kurulumu
apt-get install bacula-fd

# Master key'i güvenli depodan kopyala
# USB'den veya güvenli bir sunucudan:
scp backup-admin@güvenli-sunucu:/backup/master-key.pem /etc/bacula/ssl/master/
scp backup-admin@güvenli-sunucu:/backup/master-cert.pem /etc/bacula/ssl/master/

# Geçici File Daemon yapılandırması
cat > /etc/bacula/bacula-fd.conf << 'FDCONF'
FileDaemon {
  Name = webserver01-fd-recovery
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  
  PKI Signatures = Yes
  PKI Encryption = Yes
  
  # Master key ile geri yükleme
  PKI Keypair = "/etc/bacula/ssl/master/master-key.pem"
  PKI CA = "/etc/bacula/ssl/ca/ca-cert.pem"
  PKI Master Key = "/etc/bacula/ssl/master/master-cert.pem"
}

Director {
  Name = bacula-dir
  Password = "director-fd-parolasi"
}
FDCONF

systemctl restart bacula-fd

# Director'dan geri yükleme başlat
bconsole << 'RESTORE'
restore
5
webserver01-fd
/
mark *
done
yes
quit
RESTORE

Parola ve Erişim Yönetimi Best Practice’leri

Şifreleme ne kadar güçlü olursa olsun, parolaları bacula-dir.conf içinde düz metin olarak saklıyorsanız sorun var demektir. Birkaç pratik öneri:

  • bconsole parolaları için en az 32 karakter uzunluğunda, rastgele üretilmiş parolalar kullanın
  • pwgen -s 32 1 veya openssl rand -base64 32 ile güçlü parola üretin
  • Yapılandırma dosyalarının izinlerini sıkılaştırın
# Yapılandırma dosyası izinleri
chown root:bacula /etc/bacula/bacula-dir.conf
chmod 640 /etc/bacula/bacula-dir.conf

chown root:bacula /etc/bacula/bacula-fd.conf
chmod 640 /etc/bacula/bacula-fd.conf

# SSL sertifika dizini izinleri
chown -R root:bacula /etc/bacula/ssl/
chmod 750 /etc/bacula/ssl/
chmod 600 /etc/bacula/ssl/**/*-key.pem
chmod 644 /etc/bacula/ssl/**/*-cert.pem

# İzin kontrolü
find /etc/bacula/ssl/ -name "*-key.pem" -exec ls -la {} ;

Üretim ortamında Bacula parolalarını bir secret management sisteminde (HashiCorp Vault, Ansible Vault) saklamak iyi bir pratik:

# Ansible Vault ile şifrelenmiş yapılandırma
ansible-vault create /etc/ansible/group_vars/bacula-servers/vault.yml

# vault.yml içeriği:
# bacula_director_password: "UretilmisGucluParola123!"
# bacula_fd_password: "BaskaBirGucluParola456!"
# bacula_sd_password: "VeUcuncuBirParola789!"

# Template'de kullanım:
# Password = "{{ bacula_director_password }}"

Sertifika Yenileme ve Bakım

Sertifikalar bir gün expires olacak ve bunu unutursanız tam da kötü bir anda yedekleme sisteminiz çalışmaz hale gelir. Proaktif bir sertifika takip scripti:

#!/bin/bash
# /usr/local/bin/check-bacula-certs.sh
# Crontab: 0 9 * * 1 /usr/local/bin/check-bacula-certs.sh

CERT_DIR="/etc/bacula/ssl"
WARN_DAYS=90
ALERT_EMAIL="[email protected]"
HOSTNAME=$(hostname -f)

check_cert() {
    local cert_file="$1"
    local cert_name=$(basename "$cert_file")
    
    if [ ! -f "$cert_file" ]; then
        echo "HATA: $cert_file bulunamadı!"
        return 1
    fi
    
    # Bitiş tarihini al
    EXPIRY=$(openssl x509 -enddate -noout -in "$cert_file" | cut -d= -f2)
    EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
    NOW_EPOCH=$(date +%s)
    DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
    
    if [ "$DAYS_LEFT" -lt "$WARN_DAYS" ]; then
        echo "UYARI: $cert_name sertifikası $DAYS_LEFT gün sonra sona eriyor!"
        return 1
    else
        echo "OK: $cert_name - $DAYS_LEFT gün geçerli"
        return 0
    fi
}

ISSUES=0
REPORT=""

# Tüm sertifikaları kontrol et
while IFS= read -r -d '' cert; do
    RESULT=$(check_cert "$cert")
    REPORT="${REPORT}${RESULT}n"
    if ! check_cert "$cert" > /dev/null 2>&1; then
        ISSUES=$((ISSUES + 1))
    fi
done < <(find "$CERT_DIR" -name "*-cert.pem" -print0)

if [ "$ISSUES" -gt 0 ]; then
    echo -e "Bacula Sertifika Uyarısı - $HOSTNAMEnn$REPORT" | 
        mail -s "[$HOSTNAME] Bacula Sertifika Uyarısı: $ISSUES Sorun" "$ALERT_EMAIL"
fi

echo -e "$REPORT"

Güvenlik Denetimi ve Log İzleme

Şifreli yedekleme yapılandırdınız ama birisi yanlış bir sertifikayla bağlanmaya çalışıyor mu? Bunu log’lardan takip etmeniz gerekiyor.

# Bacula güvenlik loglarını izle
tail -f /var/log/bacula/bacula.log | grep -E "ERR|WARN|TLS|PKI|auth|denied"

# Başarısız bağlantı denemelerini say
grep "Authorization problem" /var/log/bacula/bacula.log | 
    awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# TLS hata raporu
grep -i "tls|ssl|certificate" /var/log/bacula/bacula.log | 
    grep -i "error|failed|invalid" | tail -50

Logları merkezi bir sistemde toplamak için rsyslog ile Bacula loglarını ayrı bir hedefe yönlendirebilirsiniz:

# /etc/rsyslog.d/bacula.conf
if $programname == 'bacula-dir' or $programname == 'bacula-fd' or $programname == 'bacula-sd' then {
    action(type="omfwd"
           target="log-server.sirket.com"
           port="514"
           protocol="tcp")
    action(type="omfile"
           file="/var/log/bacula/bacula-security.log")
    stop
}

Gerçek Dünya Notları ve Sık Yapılan Hatalar

Birkaç yıllık Bacula deneyiminden derlediğim, üretim ortamında karşılaşılan tipik sorunlar:

  • PKI Keypair dosyasında cert ve key sırası önemli: Cert önce, key sonra gelmelidir. Tersine yaparsanız bacula-fd başlayamaz ama hata mesajı çok açıklayıcı olmayabilir.
  • Master key’i online tutmayın: Master key online bir sunucuda durursa amacını yitiriyor. Güvenli bir vault veya offline depolama kullanın. Yılda bir kez geri yükleme testi yapın.
  • TLS ve PKI ayrı kavramlar: TLS iletişim güvenliği içindir, PKI veri şifrelemesi içindir. İkisini de yapılandırmalısınız, biri diğerinin yerini tutmaz.
  • Sertifika CN ile Bacula client Name eşleşmesi şart değil ama tavsiye edilir: İzlenebilirlik açısından sertifika CN’ini client adıyla aynı tutmak log analizi sırasında hayat kurtarır.
  • Performans etkisini ölçün: Şifreleme CPU kullanımını artırır. Yoğun yedekleme penceresi olan büyük ortamlarda istemci bazlı profil çıkarın. Modern donanımlarda genellikle yüzde 5-15 arası ek CPU yükü beklenir.

Sonuç

Bacula’da şifreli yedekleme yapılandırmak başlangıçta karmaşık görünse de birkaç temel adımdan oluşuyor: PKI altyapısı kurulumu, File Daemon üzerinde PKI yapılandırması, iletişim için TLS aktivasyonu ve düzenli bakım için izleme scriptleri. Bu adımları geçtikten sonra yedekleriniz hem aktarım sırasında hem de depolanırken korunuyor.

En kritik nokta master key yönetimi. Bu anahtarı kaybederseniz ve istemci sertifikaları da gittiyse şifreli yedekleriniz işe yaramaz hale gelir. Master key’i birden fazla güvenli yerde saklayın ve en az yılda bir kez felaket kurtarma testi yapın; üretim benzeri bir ortamda master key kullanarak geri yükleme yapabildiğinizi doğrulayın.

Şifreli yedekleme bir ürün değil bir süreç. Sertifika takibi, periyodik geri yükleme testleri ve log izleme olmadan yapılandırmanız zamanla işlevsiz hale gelebilir. Bu yazıdaki scriptleri cron’a ekleyin, alert’leri kurun ve yedekleme güvenliğinizi aktif olarak yönetin.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir