プロンプトとコンテキスト
あなたのチームでは、機密性の高いオフライン分析データや顧客向けエクスポートをDuckDBファイルに保存しています。1.4 LTSへのアップグレードとデータベースファイル暗号化の有効化を計画しています。保護対象の境界、ATTACHの設定、鍵のライフサイクル、レガシーファイルの移行、バックアップのリカバリ、およびパフォーマンス検証について説明してください。また、メインファイルのみを暗号化するだけでは情報漏洩が残る理由についても説明してください。
面接官の評価ポイント
- データベースファイル、WAL、一時ファイル、バックアップ、エクスポートを区別できているか。
- DuckDBの
ENCRYPTION_KEY、ENCRYPTION_CIPHER、およびストレージバージョンの制約を正しく使用しているか。 - 鍵管理計画によって、鍵がSQL、ログ、イメージに入り込まないようになっているか。
- 移行、リカバリ訓練、ベンチマークによってセキュリティと運用性の両方が実証されているか。
確認すべき質問
- データベースファイルはオブジェクトストレージにアップロードされるのか、分析ノードにコピーされるのか、または一時ディレクトリに書き込まれるのか？
- 保管時のデータ（Data at Rest）のみを保護するのか、それとも承認されたプロセスが保持する平文も対象とするのか？
- 現在のDuckDBバージョン、クライアント言語、バックアップツールはストレージバージョン1.4をサポートしているか？
- 鍵ローテーション中にファイル全体を再書き込みできるか、またリカバリとダウンタイムの目標値はどのようなものか？
30秒での回答
DuckDB 1.4のデータベース暗号化は、デフォルトで256ビットAES-GCMを使用し、メインデータベース、WAL、一時ファイルを保護対象とします。これにはストレージバージョン1.4以降が必要です。実行時にKMSやシークレットマネージャーから鍵を注入し、短命なプロセスのみに公開し、SQL、引数、ログには一切含めないようにします。オフライン移行とリカバリ訓練のためにソースをコピーし、ATTACH ... (ENCRYPTION_KEY ...)を使用して暗号化コピーを作成した上で、読み取り、書き込み、バックアップ、およびレガシークライアントでの失敗動作をテストします。ベンチマークでは暗号化、httpfsによるOpenSSLパス、および並行性を比較します。リスクやパフォーマンスが評価基準を満たさない場合はロールアウトを停止し、厳格なアクセス制御の下で旧バージョンを維持します。
詳細解説
1. 保護境界の定義
公式ドキュメントによると、暗号化はメインデータベース、WAL、一時ファイルを対象としますが、エクスポートされたParquet、ログ、キャッシュコピー、またはメモリ内の平文は自動的には保護されません。保管時暗号化、プロセス権限、バックアップアクセスの目標を設定する前に、ファイルのライフサイクルとレプリケーションパスをマッピングしてください。
2. 暗号方式とストレージバージョンの選択
GCMはデフォルトの認証付き暗号モードです。CBCおよびCTRも設定可能ですが、整合性と互換性を明示的に評価する必要があります。暗号化にはストレージバージョン1.4以降が必須となるため、古いDuckDBバイナリではファイルを開けない可能性があります。アップグレード後に非互換性が発覚するのを防ぐため、起動スクリプトやリカバリスクリプトにバージョンチェックを組み込んでください。
3. 文字列ではなく鍵として管理する
KMS、シークレットマネージャー、または短期間のワークロードIDから鍵を取得し、メモリまたは保護されたファイル記述子に注入します。ENCRYPTION_KEYをリポジトリ、イメージレイヤー、シェル履歴、SQLログ、トレースにコミットしてはなりません。鍵のローテーションは通常、新しい鍵でデータベースを再書き込みし、検証した上でアトミックにファイルを置き換え、管理されたロールバック用コピーを保持することで行います。
4. バックアップの移行とリカバリ
ソースを読み取り専用にしてチェックサムとスナップショットを取得し、制御されたジョブで暗号化コピーを作成し、テーブルごとに行数、統計情報、重要なクエリ結果を比較します。バックアップには暗号化ファイル、鍵バージョン、リカバリ手順を含める必要があります。メインファイルのみをバックアップし、WALや一時的なエクスポートを見落とすと、リカバリの失敗や漏洩の原因となります。
5. パフォーマンスと運用上の障害の検証
コールドキャッシュスキャン、書き込み、WALのピーク、一時的なスピル、並行読み取りを個別に測定します。httpfsをロードするとOpenSSLとハードウェアアクセラレーションを使用して暗号化処理を高速化できますが、対象プラットフォームで必ず検証してください。誤った鍵や存在しない鍵、古いクライアント、ディスクフル、KMSの利用不可状態を想定した訓練を実施し、エラーが可視化され、平文へサイレントにダウングレードされないことを確認します。
質の高い模範回答
私は各DuckDBファイルをライフサイクルを持つ機密アセットとして扱います。メインファイル、WAL、一時ディレクトリ、バックアップ、エクスポート、オブジェクトストレージのコピーをマッピングし、1.4 LTSのデフォルトであるAES-256-GCMで暗号化コピーを作成し、ストレージバージョンの境界を文書化します。KMSは実行時に鍵を提供し、SQL、イメージ、ログ、コマンドラインを介して鍵が渡されることは決してありません。ローテーションではコピーを再書き込みして検証し、アトミックにスワップして、管理されたロールバック用コピーを保持します。本番展開の前には、テーブルレベルのチェック、リカバリ訓練、WALや一時ファイルを含むコールド/ホットキャッシュのベンチマークを実行します。KMS障害、レガシークライアント、またはパフォーマンス基準の未達が発生した場合はロールアウトを停止し、リスクと次回のテスト内容を記録しながら、旧バージョンを厳格な権限下で維持します。
よくある間違い
- メインファイルのみを暗号化し、WAL、一時ファイル、バックアップ、エクスポートを無視する。
- SQL、イメージ、シェル履歴、ログに鍵をハードコードする。
- ストレージバージョン1.4の互換性境界を無視し、古いクライアントを壊してしまう。
- セキュリティとパフォーマンスの観点でGCM、CBC、CTRが同等であると主張する。
- 誤った鍵、KMS停止、ディスクフル、リカバリ順序のテストをスキップする。
- コールドキャッシュ、スピル、並行読み取りを測定せず、クエリの平均実行時間のみを測定する。
フォローアップの質問と回答
暗号化後もデータが漏洩する可能性はありますか？
はい。エクスポート、ログ、キャッシュ、メモリ、および鍵を読み取る権限を持つすべてのプロセスが平文を公開する可能性があります。脅威モデルには、ファイルのライフサイクル、プロセス権限、バックアップアクセス、鍵の監査を含める必要があります。
データベースの鍵はどのようにローテーションしますか？
分離されたディレクトリで新しい鍵を使用してコピーを再書き込みし、チェックサムとリカバリを検証した後にアトミックに置き換えます。ロールバック期間中のみ古い鍵を保持し、その後KMSで鍵の取り消しと監査を行います。
なぜhttpfsをロードするのですか？
DuckDBのドキュメントによると、OpenSSLパスはハードウェアアクセラレーションを使用できるため、組み込みのmbedtlsよりも通常高速です。ただし、これは保証されたパフォーマンス結果ではなく、対象プラットフォームでベンチマーク検証すべき仮説として扱います。