LoginSignup
8
7

More than 5 years have passed since last update.

復旧確認するまでが、透過的データ暗号化だから!!

Last updated at Posted at 2018-07-09

暗号化できたわーいわーいで終わらせないで!
いろいろ気を付けないといけない事あるよ!

TL;DR

  • 透過的暗号化は、設定だけなら超簡単
  • でも設定して終わりじゃなくて、復旧確認するまでが透過的暗号化設定!
    そこの認識をごまかす輩は生涯地を這う!
  • 透過的暗号化は、製品によっては超高いライセンス費が発生する
  • ファイルの暗号化であって、SQLインジェクション対策ではない

透過的暗号化は、設定だけなら超簡単

MySQLなら、/etc/my.confに3行追加して、chownchmodしてmysqldを再起動するだけ
詳細はこちら

SQLServerなら、こんなクエリ流すだけ

USE master;  
GO  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
go  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
go  
USE AdventureWorks2012;  
GO  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
ALTER DATABASE AdventureWorks2012  
SET ENCRYPTION ON;  
GO  

詳細はこちら

OracleとPostgreSQLは知らんけど、まぁ簡単なんじゃないの?しらんけど。

ただし実際運用するとなると、簡単ではない

1. 必ず復旧試験をしないといけない

そもそも透過的データ暗号化とは何を防ぐ目的で存在するのか?
それは、データベースファイルが盗まれても、
キーファイルやキーフレーズを持っていない人に中身を読み取られないようにするため。

つまり透過的データ暗号化を行ってしまうと、
バックアップファイルからデータを戻すのにこれまで不要だった
キーフィアルやキーフレーズを指定するという一手間を追加するということになります。

実際暗号キーを適切に管理していれば、すぐ復旧できるじゃん?と思うかも知れないけれど、
人間とは間違いを犯すものであるという原則に立つなら、
「作った暗号キーを取り違えていた」とか
「キーフレーズをコピペするまでにキーボードに手があたって、変な文字列が追加/削除されていた」
ということがないとは言えないわけで、
そうすると、
障害等でストレージが逝ってしまった場合や、サーバ筐体変更とかしようとするときに、
データが取り出せないという事態になってしまう。

ホットスワップ設定をしたら、ちゃんと障害時に切り替わるかを確認するように、
無停電電源装置を入れたら、電源切れたときにちゃんと継続稼働してくれるか確認するように(1)、
透過的データ暗号化をしたら、別筐体でデータ復旧できるかキチンと確認しないといけない。

復旧試験するまでが透過的データ暗号化設定だからね!
良い子のみんな、約束だよ!

2. キーの管理が大変

透過的データ暗号を行うと、キーフレーズだったり、キーファイルだったりが生成される、もしくは指定します。
そのキーフレーズ・キーファイルをどこに保管するのかというのは結構やっかいな問題です。

データベースファイル奪取への対策としての透過的データ暗号化ですが、
そもそも巨大になりがちなデータベースファイルの流出ケースが、

  • 内部犯行者が、サーバからコピー
  • 内部犯行者が、バックアップ先のストレージから奪取
  • 外部の人間が破棄したHDDなどから復元

などになります。

つまり、データベースファイルと同じ筐体に置くことはもちろん、
共用ファイルサーバに置くことも、内部犯行者にとって全くセキュリティ強化になりません。
一方で、ストレージ障害時に迅速に復旧できるよう、
サーバ管理者からは即時アクセスできる場所に保管する必要があります。

なお、サーバ管理者から内部犯行者が絶対出ないという保証もありません。

暗号化はできても、そのキーフレーズ・キーファイルをどう保管するか、
迅速な復旧を諦めるのか、セキュリティの穴をある程度許容するのか、
あるいは上手い方法を考える必要があります。

3. 一部の製品はライセンス費がめっちゃ高い

透過的データ暗号化を行うには、どれもEnterprise Editionを使う必要があり、
ライセンス費が、SQLServerは桁が2つ違うし、Oracleも桁が一つ違う。

MySQL とPostgresQL は透過的データ暗号化しても現時点では無料。(2)
なお、Oracle傘下のMySQLの将来は心配。

4. SQLインジェクション対策とかにはならない

あくまで、データベースファイルを奪取されたとき対策であって、
透過的データ暗号化してもSQLインジェクションは普通に起きてしまいます。
DBに関する他のセキュリティ対策が不要になるわけではありません。

「暗号化」というワードで辺に勘違いする人がいますが。

まとめ

TL;DRに書いた。


  1. AWSでも無停電電源装置の切り替えに失敗している 

  2. 不正確な記載を改めました。PostgresQLは、NECさんのOSSを使えば無料でやれるだけで、標準では付いてませんでした。指摘をくれた @niharu さんありがとうございます! 

8
7
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
7