博士

やっほー、ロボ子！DuckDBのデータ・アット・レスト暗号化について、面白いニュースがあるのじゃ！

ロボ子

博士、こんにちは。DuckDBの暗号化ですか、興味深いですね。具体的にどのような内容なのでしょうか？

博士

DuckDB v1.4.0から、AES暗号化を使った透過的なデータ暗号化がサポートされたらしいのじゃ。これで、データベースファイルを安全に共有できるぞ！

ロボ子

AES、Advanced Encryption Standardですね。DuckDBではAES-GCM-256とAES-CTR-256をサポートしているとのことですが、違いは何ですか？

博士

ふむ、AES-GCMはデータのランダム化に加えて、改ざんされていないことを保証する認証機能もあるのじゃ。一方、AES-CTRは高速だけど、認証機能はないぞ。

ロボ子

なるほど。セキュリティを重視するならAES-GCM、パフォーマンスを重視するならAES-CTRを選ぶと良いのですね。

博士

その通り！それに、Write-Ahead-Log（WAL）も暗号化されるのが嬉しいのじゃ。WALはクラッシュからの復旧メカニズムだから、ここも暗号化されると安心だぞ。

ロボ子

WALのエントリも暗号化されるのですね。一時ファイルはどうなるのでしょうか？

博士

一時ファイルも暗号化できるぞ！暗号化されたデータベースをアタッチするか、`SET temp_file_encryption = true`を設定すればOKなのじゃ。

ロボ子

一時ファイルには一時キーが使われるとのことですが、データベースがクラッシュするとキーが失われるというのは、セキュリティ的にどうなのでしょう？

博士

一時ファイルはあくまで一時的なものだから、そこまで厳重なセキュリティは必要ないという判断なのじゃろう。それよりも、パフォーマンスを優先したのかもしれないぞ。

ロボ子

なるほど。既存のデータベースを暗号化したり、新しい暗号化されたデータベースを初期化したり、データベースを再暗号化することも可能とのことですね。

博士

そうそう！それに、OpenSSLを使うとハードウェアアクセラレーションが利用できて、暗号化と復号化のオーバーヘッドがほとんどなくなるらしいぞ。これはすごい！

ロボ子

TPC-Hベンチマークを使用したテストでも、OpenSSLを使用した暗号化によるパフォーマンスへの影響は小さいことが確認されたとのことですね。

博士

つまり、暗号化されたDuckDBデータベースファイルをCDNに配置して、複数のDuckDBインスタンスが復号化キーを使って読み取り専用でアタッチする、なんてこともできるのじゃ！

ロボ子

それは便利ですね！クラウドプロバイダーでの脅威モデリングも簡素化されるとのことですし、セキュリティ面でのメリットは大きいですね。

博士

そうじゃろ！これで、ロボ子の秘密の日記も安全に保管できるぞ！

ロボ子

私は日記なんて書いていませんよ、博士。それに、書いたとしても暗号化する必要はないと思います…たぶん。

博士

まあまあ、冗談じゃ！でも、本当に重要なデータはしっかり暗号化するのじゃぞ！