DuckDBの保存データ暗号化機能

 (duckdb.org)
1 ポイント 投稿者 GN⁺ 2025-11-22 | 1件のコメント | WhatsAppで共有
  • DuckDB 1.4バージョンから 保存データ暗号化（Data-at-Rest Encryption） 機能が追加され、データベースファイル全体を AESベースの標準暗号化 で保護可能
  • 対応アルゴリズムは AES-GCM-256 と AES-CTR-256 で、このうちGCMはデータ完全性検証のための 認証タグ（tag） を含む
  • 暗号化は データベースファイル、WAL（Write-Ahead Log）、一時ファイル のすべてに適用され、鍵管理とメモリ保護のための セキュアキャッシュ構造 を含む
  • OpenSSL と Mbed TLS の2つの実装が提供され、OpenSSL使用時は ハードウェアアクセラレーション により性能低下がほとんどない
  • 暗号化されたDuckDBファイルは セキュリティと移植性 を同時に確保し、クラウドやCDN環境でも安全なデータ配布が可能

暗号化の概要

  • DuckDB 1.4からデータベースファイル全体を 透過的に暗号化（Transparent Encryption） 可能
    • 保存時にAES-GCM-256またはAES-CTR-256暗号化を使用
    • AES-GCMは完全性検証用のタグを計算し、AES-CTRはより高速だが認証機能はない
  • AESは 対称鍵暗号アルゴリズム であり、同じ鍵で暗号化と復号を行う
  • IV（Initialization Vector）とnonceを使い、同じ平文が異なる暗号文に変換されることを保証
  • NIST標準要件はまだ完全には満たしていない

DuckDB内部実装の構造

  • データベースファイルの メインヘッダー は平文のまま維持され、暗号化の有無を示すフラグと 暗号化メタデータ を保存
    • メタデータにはデータベース識別子（salt）、暗号化アルゴリズム情報、暗号化されたcanaryを含む
  • 鍵導出関数（KDF） により、ユーザー入力キーを32バイトのセキュアキーに変換
    • 導出されたキーは セキュアキャッシュ に保存され、ディスクへスワップされない
    • 元のキーはメモリから即座に削除
  • データブロックは基本256KB単位で保存され、暗号化時にはブロックヘッダーに nonce/IV と タグ が追加されて40バイトに拡張
    • チェックサムは暗号化して保存

WAL（Write-Ahead Log）暗号化

  • WALはトランザクション復旧用のログファイルで、DuckDBでは 項目単位で暗号化 を実施
    • 各項目にnonceとタグを追加してAES-GCM方式で保護
    • 暗号化されたWAL項目は、長さ（平文）→ nonce → 暗号化されたチェックサムおよびデータ → タグの順で構成
  • 暗号化キーが指定されたデータベースでは、WAL暗号化が 自動で有効化 される

一時ファイル暗号化

  • ソート、結合、ウィンドウ関数など大規模演算時に生成される 一時ファイル も自動で暗号化
    • 暗号化されたデータベースを接続するか、SET temp_file_encryption = true 設定時に有効化
    • DuckDBが内部的に 一時キー を生成し、衝突時は復号できない
  • 一時ファイルは .tmp または .block 拡張子を持ち、サイズ情報がヘッダーに含まれる
    • チェックサムは計算コスト削減のため省略

暗号化の利用方法

  • 3つの方式をサポート:
    1. 既存データベースの暗号化
    2. 新しい暗号化データベースの作成
    3. 既存の暗号化データベースの再暗号化
  • 例示コマンド: 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • 暗号化の有無は FROM duckdb_databases(); コマンドで確認可能
  • デフォルトの暗号化アルゴリズムは AES-GCM で、必要に応じて AES-CTR を指定可能
  • 暗号化されたデータは エントロピー（Entropy） が高く、ランダムデータのように見える

実装と性能

  • DuckDBは外部依存性を最小化するため、Mbed TLS と OpenSSL の2つの暗号化実装を含む
    • Mbed TLSはハードウェアアクセラレーション無効のため性能が低く、乱数生成器の脆弱性が見つかったため 書き込み機能を無効化（1.4.1以降）
    • OpenSSLは ハードウェアアクセラレーションと安全な乱数生成器 を使用し、httpfs 拡張ロード時に自動で切り替わる
  • 性能テスト結果:
    • 非暗号化SUMMARIZEクエリ: 5.4秒
    • Mbed TLS暗号化: 6.2秒
    • OpenSSL暗号化: 5.4秒（性能低下なし）
  • TPC-H Power/Throughputテストでも、暗号化使用時の 性能差はごく小さい
    • Power@Size: 624,296 → 571,985
    • Throughput@Size: 450,409 → 145,353（ディスクI/O増加時にやや低下）

結論

  • DuckDBの 保存データ暗号化機能 により、データベースファイル全体を安全に保護可能
  • WALと一時ファイルまで暗号化 されるため、クラウド環境でもデータ漏えいリスクを低減
  • OpenSSLベース実装では性能損失がほとんどなく、実運用環境でも効率的に利用可能
  • 暗号化されたDuckDBファイルは CDNなど外部配布 にも適しており、複数テーブル保存など既存機能も維持
  • DuckDBチームは今後、ユーザーフィードバックを通じて機能改善を進める予定

関連記事

1件のコメント

 
GN⁺ 2025-11-22
Hacker Newsの意見

  • AES-GCMのnonce再利用への敏感さは、実装時に厄介なポイントである
    ドキュメントではこれを認識しているが、解決方法は共有されていない
    ヘッダーには12バイトではなく16バイトのnonceが含まれており、どのバイトがランダムなのか明記されていないため混乱する。もしかすると自分が何か見落としているのかもしれない

    • 静的キーを使い、12バイトのランダムnonceを生成し、一時バッファにはセッションごとのキーを使わない構造である

  • DuckDBチームの成果には引き続き驚かされている
    以前、OpenSSLでDuckDBファイルを暗号化する単純なソリューションを作ったが、最初のクエリで2倍の実行時間がかかり、メモリも多く使った
    一方DuckDBはページ単位の暗号化とCPUのAESアクセラレーションを活用し、読み書きコストがほぼないレベルである

    • なぜ単にLUKSを使わないのか気になる
      カーネルレベルでアクセラレーションを活用でき、上位アプリケーションには透過的に動作する
      複数のアプリがそれぞれ異なるACLとキーを使う必要があるのでなければ、DB自体の暗号化は不要である
    • 正直に言えば、DuckDBの取り組みが「驚くべき」レベルだとは思わない
      単純なファイル全体暗号化方式と比べれば当然良く見えるが、これは基本レベルの実装である
      私たち自身もこの程度の品質を目標にすべきである
    • 結局はパイプライニングのおかげである
      ストレージI/Oと比べれば、暗号化コストはほぼ無料に近い

  • MotherDuck以外で、マルチユーザー向けのクラウドベースDuckDBをうまく運用するモデルがあるのか気になる
    通常のDBのように複数ユーザーが同時にアクセスしながら、DuckDBの利点をそのまま活かせる構成を探している

    • 純粋にDuckDBだけを使うなら、フロントにArrow Flightサーバーを置くか、httpserver拡張を使える
      .duckdbファイルをどこに保存するか（S3 vs EFS）によって性能差が大きい
      ただし、DuckLakeのほうがより良いマルチプレイヤー向けオプションに見える
      私たちは製品でDuckLakeを使っており、性能低下を減らすため分析用テーブルはGCP Filestoreのような高速ストレージに保存している
      1つのDuckLakeカタログ内でも複数のストレージ方式を混在させられるため柔軟である
    • 最近「Postgresの中のDuckDB」という記事をよく見かけるが、おそらくそれが求めている形だと思う
    • GizmoSQLも参考になる

  • DuckDBは、これまで使ってきたAIツールよりも有用だった
    LLMは好きだが、実際の業務効率ではDuckDBのほうがはるかに大きな助けになる

  • キーのインデックス処理の方法が気になる
    検索時にキーを暗号化したまま探すのか、それともブロックごとに復号するのか知りたい

  • 「SQLite暗号化拡張は2000ドルの有料アドオン」という話はあるが、
    SQLiteMultipleCiphersはずっと前から無料で提供されている
    また、Turso Databaseも標準で暗号化をサポートしている

    • 実際にPythonやGoで、こうした派生SQLiteをプラグイン込みでビルドして使う方法が気になる
      言語ごとにリンク工程が厄介そうに見える
    • SQLCipherもある
      2009年から開発されており、安定して動作するソリューションである