DuckDB’de depolanan veriler için şifreleme özelliği

 (duckdb.org)
1 puan yazan GN⁺ 2025-11-22 | 1 yorum | WhatsApp'ta paylaş
  • DuckDB 1.4 sürümünden itibaren depolanan veriler için şifreleme (Data-at-Rest Encryption) özelliği eklendi; böylece veritabanı dosyasının tamamı AES tabanlı standart şifreleme ile korunabiliyor
  • Desteklenen algoritmalar AES-GCM-256 ve AES-CTR-256; bunlardan GCM, veri bütünlüğü doğrulaması için kimlik doğrulama etiketi (tag) içeriyor
  • Şifreleme veritabanı dosyası, WAL (Write-Ahead Log) ve geçici dosyaların tümüne uygulanıyor; ayrıca anahtar yönetimi ve bellek koruması için güvenli önbellek yapısı içeriyor
  • OpenSSL ve Mbed TLS olmak üzere iki farklı uygulama sunuluyor; OpenSSL kullanıldığında donanım hızlandırma sayesinde performans kaybı neredeyse yok
  • Şifrelenmiş DuckDB dosyaları güvenlik ve taşınabilirliği aynı anda sağlıyor; bulut veya CDN ortamlarında da güvenli veri dağıtımı mümkün

Şifrelemeye genel bakış

  • DuckDB 1.4’ten itibaren veritabanı dosyasının tamamı şeffaf biçimde şifrelenebiliyor (Transparent Encryption)
    • Kaydetme sırasında AES-GCM-256 veya AES-CTR-256 şifrelemesi kullanılıyor
    • AES-GCM, bütünlük doğrulaması için etiket hesaplıyor; AES-CTR ise daha hızlı ancak kimlik doğrulama özelliği yok
  • AES, simetrik anahtarlı bir şifreleme algoritmasıdır; şifreleme ve şifre çözme için aynı anahtar kullanılır
  • IV (Initialization Vector) ve nonce kullanılarak aynı düz metnin farklı şifreli metinlere dönüşmesi garanti ediliyor
  • NIST standart gereksinimleri henüz tamamen karşılanmıyor

DuckDB içindeki uygulama yapısı

  • Veritabanı dosyasının ana başlığı düz metin olarak tutuluyor ve şifreleme durumunu gösteren bir bayrak ile şifreleme metaverisi saklanıyor
    • Metaveri içinde veritabanı tanımlayıcısı (salt), şifreleme algoritması bilgisi ve şifrelenmiş canary bulunuyor
  • Anahtar türetme işlevi (KDF) ile kullanıcı tarafından girilen anahtar 32 baytlık güvenli anahtara dönüştürülüyor
    • Türetilen anahtar güvenli önbellekte saklanıyor ve diske swap edilmiyor
    • Orijinal anahtar ise bellekten hemen siliniyor
  • Veri blokları varsayılan olarak 256 KB birimlerle saklanıyor; şifreleme sırasında blok başlığına nonce/IV ve tag eklenerek 40 bayt genişliyor
    • Sağlama toplamı şifrelenmiş olarak saklanıyor

WAL (Write-Ahead Log) şifrelemesi

  • WAL, işlem kurtarma için kullanılan günlük dosyasıdır; DuckDB’de kayıt bazında şifreleme uygulanıyor
    • Her kayda nonce ve tag eklenerek AES-GCM yöntemiyle korunuyor
    • Şifrelenmiş WAL kaydı şu sırayla oluşuyor: uzunluk (düz metin) → nonce → şifrelenmiş sağlama toplamı ve veri → tag
  • Şifreleme anahtarı belirtilmiş veritabanlarında WAL şifrelemesi otomatik olarak etkinleşiyor

Geçici dosya şifrelemesi

  • Sıralama, join, pencere işlevleri gibi büyük ölçekli işlemlerde oluşturulan geçici dosyalar da otomatik olarak şifreleniyor
    • Şifrelenmiş bir veritabanı bağlandığında veya SET temp_file_encryption = true ayarı yapıldığında etkinleşiyor
    • DuckDB dahili olarak geçici anahtar üretiyor; çakışma durumunda şifre çözme mümkün olmuyor
  • Geçici dosyalar .tmp veya .block uzantısına sahip oluyor ve boyut bilgisi başlıkta yer alıyor
    • Hesaplama maliyetini azaltmak için sağlama toplamı atlanıyor

Şifreleme nasıl kullanılır

  • Üç yöntem destekleniyor:
    1. Mevcut veritabanını şifreleme
    2. Yeni şifreli veritabanı oluşturma
    3. Mevcut şifreli veritabanını yeniden şifreleme
  • Örnek komut: 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • Şifreleme durumu FROM duckdb_databases(); komutuyla kontrol edilebiliyor
  • Varsayılan şifreleme algoritması AES-GCM; gerekirse AES-CTR olarak belirtilebiliyor
  • Şifrelenmiş verinin entropisi (Entropy) yüksek olduğu için rastgele veri gibi görünüyor

Uygulama ve performans

  • DuckDB, harici bağımlılıkları en aza indirmek için Mbed TLS ve OpenSSL olmak üzere iki şifreleme uygulaması içeriyor
    • Mbed TLS’te donanım hızlandırma devre dışı olduğundan performans daha düşük; ayrıca rastgele sayı üretecindeki bir zafiyet nedeniyle yazma işlevi devre dışı bırakıldı (1.4.1 sonrası)
    • OpenSSL, donanım hızlandırma ve güvenli rastgele sayı üreteci kullanıyor; httpfs uzantısı yüklendiğinde otomatik olarak buna geçiliyor
  • Performans test sonuçları:
    • Şifrelenmemiş SUMMARIZE sorgusu: 5.4 saniye
    • Mbed TLS ile şifreleme: 6.2 saniye
    • OpenSSL ile şifreleme: 5.4 saniye (performans kaybı yok)
  • TPC-H Power/Throughput testlerinde de şifreleme kullanımında performans farkı çok az
    • Power@Size: 624,296 → 571,985
    • Throughput@Size: 450,409 → 145,353 (disk I/O arttığında hafif düşüş)

Sonuç

  • DuckDB’nin depolanan veriler için şifreleme özelliği sayesinde veritabanı dosyasının tamamı güvenli şekilde korunabiliyor
  • WAL ve geçici dosyalar da şifrelendiği için bulut ortamlarında veri sızıntısı riski azalıyor
  • OpenSSL tabanlı uygulamada performans kaybı neredeyse yok; bu da gerçek kullanım senaryolarında verimli kullanım sağlıyor
  • Şifrelenmiş DuckDB dosyaları CDN gibi harici dağıtım için de uygun; çoklu tablo depolama gibi mevcut işlevler korunuyor
  • DuckDB ekibi, gelecekte kullanıcı geri bildirimleriyle bu özelliği geliştirmeyi planlıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-11-22
Hacker News görüşleri

  • AES-GCM’de nonce yeniden kullanımı hassasiyeti, uygulama sırasında zorlayıcı bir nokta
    Dokümantasyon bunun farkında, ancak çözüm yöntemini paylaşmamış
    Başlıkta 12 bayt yerine 16 baytlık nonce yer alıyor ve hangi baytların rastgele olduğu belirtilmediği için kafa karıştırıcı. Acaba benim gözden kaçırdığım bir nokta mı var diye merak ediyorum

    • Yapı, statik bir anahtar kullanıyor, 12 baytlık rastgele nonce üretiyor ve geçici tamponda oturum başına anahtar kullanmıyor

  • DuckDB ekibinin başardıklarına şaşırmaya devam ediyorum
    Daha önce OpenSSL ile DuckDB dosyalarını şifreleyen basit bir çözüm yapmıştım; ilk sorguda 2 kat çalışma süresi oluyordu ve bellek de çok kullanıyordu
    Buna karşılık DuckDB, sayfa düzeyinde şifreleme ve CPU’nun AES hızlandırmasını kullanarak okuma/yazma maliyetini neredeyse yok denecek seviyeye indiriyor

    • Neden doğrudan LUKS kullanılmadığını merak ediyorum
      Çekirdek seviyesindeki hızlandırmayı kullanır ve üstteki uygulamalara şeffaf şekilde çalışır
      Birden fazla uygulamanın farklı ACL’ler ve anahtarlar kullanması gerekmiyorsa, veritabanının kendi içinde şifreleme gereksizdir
    • Dürüst olmak gerekirse DuckDB’nin yaptığı işin “şaşırtıcı” seviyede olduğunu düşünmüyorum
      Basit tüm-dosya şifreleme yaklaşımıyla karşılaştırınca elbette daha iyi görünüyor, ama bu temel düzeyde bir uygulama
      Bizim de kendi başımıza bu kalite seviyesini hedeflememiz gerekir
    • Sonuçta mesele pipelining
      Depolama G/Ç’siyle kıyaslandığında şifreleme maliyeti neredeyse bedava sayılır

  • MotherDuck dışında çok kullanıcılı bulut tabanlı DuckDB’yi iyi işleten bir model olup olmadığını merak ediyorum
    Birden fazla kullanıcının normal bir veritabanındaki gibi aynı anda erişebildiği ve DuckDB’nin avantajlarını koruyan bir yapı arıyorum

    • Yalnızca saf DuckDB kullanacaksanız, önüne bir Arrow Flight sunucusu koyabilir veya httpserver eklentisini kullanabilirsiniz
      .duckdb dosyasını nereye koyduğunuza bağlı olarak (S3 vs EFS) performans farkı büyüktür
      Ama DuckLake daha iyi bir çok kullanıcılı seçenek gibi görünüyor
      Biz üründe DuckLake kullanıyoruz ve performans düşüşünü azaltmak için analiz tablolarını GCP Filestore gibi hızlı depolamada tutuyoruz
      Tek bir DuckLake kataloğu içinde birden fazla depolama yöntemini karıştırabilmek esneklik sağlıyor
    • Son zamanlarda sık sık “Postgres içinde DuckDB” yazıları görüyorum; muhtemelen aradığınız yapı budur
    • GizmoSQL de bakmaya değer

  • DuckDB, şimdiye kadar kullandığım AI araçlarından daha faydalı oldu
    LLM’leri seviyorum ama gerçek iş verimliliği açısından DuckDB çok daha fazla yardımcı oluyor

  • Anahtarların indeksleme biçimini merak ediyorum
    Arama sırasında anahtarları şifrelenmiş halde mi buluyorlar, yoksa her blokta şifre çözme mi yapılıyor, bilmek isterim

  • “SQLite şifreleme eklentisi 2000 dolarlık ücretli bir add-on” deniyor ama,
    SQLiteMultipleCiphers uzun zamandır ücretsiz sunuluyor
    Ayrıca Turso Database varsayılan olarak şifrelemeyi destekliyor

    • Gerçekte Python ya da Go’da bu tür değiştirilmiş SQLite sürümlerini eklentiyle birlikte derleyip kullanma yöntemini merak ediyorum
      Bağlama süreci dil bazında epey zahmetli görünüyor
    • SQLCipher da var
      2009’dan beri geliştirilen ve kararlı çalışan bir çözüm