第3回はデータベースの暗号化について取り上げる。まず、データベースの暗号化について真っ先に頭に浮かぶとすると、そもそも暗号化することで何のメリットがあるのだろうか? パフォーマンスへの影響はどれくらいあるのだろうか? という疑問があるに違いない。今回は、その疑問を明確に解消できる方法を具体的に説明していきたい。
第3回はデータベースの暗号化について取り上げる。まず、データベースの暗号化について真っ先に頭に浮かぶとすると、そもそも暗号化することで何のメリットがあるのだろうか? パフォーマンスへの影響はどれくらいあるのだろうか? という疑問があるに違いない。今回は、その疑問を明確に解消できる方法を具体的に説明していきたい。
■データベース暗号化の意義
事を起こすには必ず理由があるように、データベースを暗号化する、しなければならない理由もある。その背景となる脅威については、Think ITの記事で詳細に触れているので一度目を通してほしいが、データベースの暗号化によって防ぐことができる脅威は、盗聴と盗難だ。具体的に、Oracle Databaseで考えてみると、
ネットワークアナライザのようなソフトウェアでパケットを覗き見られたとしても、USBメモリでデータファイルをコピーして持ち出されたとしても、暗号化されていれば当然そのデータを見ることはできない。実際に、暗号化されていないハードディスクを修理に出した後に顧客情報が漏えいしてしまったという事件もある。情報漏洩対策としては、暗号化、認証やアクセス制御など複数のセキュリティ対策の組み合わせで実施されるべきものではあるが、その中でも暗号化は保険的な最後の砦としてその役割は非常に重い。
■暗号化はアクセスコントロールではない
よくデータベースの暗号化というと、下の図のようにユーザーごとにデータが暗号化されるようなイメージを持たれるかもしれない。これは本来暗号化で行うべきものでない。第1回に紹介しているがデータベースにはアクセスコントロールの機能が備わっており、この機能で誰にどのデータを見せるかということを定義することが正しい使い方である。暗号化が防ぐことができる脅威は、データの盗聴と盗難ということを忘れないで欲しい。
暗号化はアクセスコントロールではない
■Oracle Advanced Security Option (ASO)
Oracle Advanced Securityは、データベースの暗号化に特化したオプションだ。上記で示した脅威に対して、Oracle Advanced Securityでは、それぞれ暗号化することで対応が可能である。今回は、特にネットワークの暗号化と格納データの暗号化の特徴と方法について説明していく。
Oracle Advanced Security
■ネットワークの暗号化
ネットワークの暗号化は、9i以前からある最も早く実装された機能である。設定方法もsqlnet.oraファイルに追記するだけという非常に簡単な設定なので、既存環境にも導入がし易い。以下は、Oracle Net Managerを使用した設定の例だが、使用するのはこの暗号化のタグの画面のみである。
Oracle Net Manager
クライアントごとに個々に設定もすることができるが、もっとも簡単かつ管理が楽になるのはサーバー側の設定で、暗号化タイプ「必要」、暗号化シード(※オプションなので入力の必要はなし)、使用可能なメソッド 「AES 128、192、256」のいずれかを選択した設定だ。この場合は接続するクライアントは必ず暗号化通信が求められる設定になるので、漏れなく暗号化をさせることができる。また、以下の2文をサーバー側のsqlnet.oraに直接追記しても良い。※Oracle Net Managerで暗号化シードが要求される場合は、直接sqlnet.oraに追記する
SQLNET.ENCRYPTION_SERVER = required
SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)
暗号化通信の設定はこれで完了だ。OTNにもチュートリアルがあるので参考にしてほしい。通信で使用する暗号鍵はセッション開始時に自動的に生成されるため、特に事前に暗号鍵を用意して管理する必要はない。また、通信の暗号化はパフォーマンスへの影響はない。わずかなこの設定だけで、従来通りにデータベースを使用することができ、かつ、暗号化通信を両立することができるのだ。
■格納データの暗号化
次に格納データの暗号化だが、Oracle Databaseの機能の歴史を紐解いていくと、PL/SQL暗号化ツールキットというストアドプログラムが9i以前から実装されている。古くは、DBMS_OBFUSCATION_TOOLKIT、10gからはDBMS_CRYPTOというパッケージが実装されており、このパッケージを明示的にコールしてアプリケーション側に暗号化、復号処理を実装する。ただ、このパッケージでの暗号化は大きな問題がある。一つは、パフォーマンス劣化が大きいという点、アプリケーション側の修正が必要となる点である。特にパフォーマンス劣化の影響は大きく、コンプライアンス上どうしても業務データを暗号化しなければならない等の要件の場合に限って使用されることが多く、格納データ自体の暗号化は普及していなかった。
しかし、新たに10gR2から実装されたTransparent Data Encryption(TDE)は、上記の課題を大きく解決した機能である。
Transparent Data Encryption
このTDEの特徴は、暗号処理はすべてデータベース側で実行されるということだ。アプリケーションは従来通りのSQLをデータベースに実行し、データベース側で暗号/復号化処理を行ってアプリケーションへ送信する。アプリケーションのプログラムを修正する必要はない。また、パフォーマンスもデータベース側で暗号化に最適化されたアーキテクチャを実装することによって、飛躍的な向上を実現している。 さらに11gR1からは、TDE 表領域暗号化という機能が実装された。
TDE表領域暗号化
この機能は、表領域自体を暗号化しておき、その中に入る表や索引、パッケージといったオブジェクトはすべて暗号化されるというものである。表領域は、最終的には物理的なデータファイルに属するわけだが、そのデータファイルそのものが暗号化されていると捉えて良い。物理的なOracleのファイルとしては、REDOログファイル、UNDO表領域やTEMP表領域のファイルがあるが、それらもすべて暗号化されている。暗号化/復号のタイミングだが、データファイルの場合、DBWR(データベース・ライター)がDiskへ書き込み、サーバープロセスがDiskから読み込みの際に行われる。
また、表領域に格納したオブジェクトのサイズは変わらない(暗号化したとしても表のサイズは増加しない)、ほとんどすべてのデータ型 (BFILEのみ不可)含む表が暗号化可能といった制限の少ない柔軟な特徴を持っている。
気になる表領域暗号化のパフォーマンスについてだが、暗号化なしを1とした処理時間で相対的に比較すると、表領域暗号化の場合で1.2程度の影響で抑えることができる。これは従来のパッケージでは、5~10といった数倍となる数値から見ても、飛躍的に性能向上しているのが分かる。
これは、比較的にDisk I/Oが多く発生するバッチ処理のようなトランザクションの場合だが、キャッシュヒット率を高く保って運用されるOLTP処理の場合、Disk I/Oの比率が少なくなるので、パフォーマンスへの影響はより低く抑えることができることが分かっている。
では、実際に表領域暗号化の設定だが、データが入っている既存のデータベースに表領域暗号化を使用する場合を仮定して説明する。手順としては以下となる。
1)Oracle Walletを作成し、マスターキーを格納
sqlnet.oraにWalletを作成するロケーションを記述
ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE)
(METHOD_DATA = (DIRECTORY = /home/home/wallet)))
SQL*Plusから、SYSユーザーで以下のコマンドを実行してマスターキーを作成
※パスワードは任意
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "password";
2)Oracle Walletをオープン
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "password";
※1)でマスターキー作成直後は不要。データベースが再起動した場合など、起動時には1回かならずオープンする
3)CREATE TABLESPCE~で新規の暗号化表領域を作成
ENCRYPTION USINGで、暗号アルゴリズムを指定し(デフォルトはAES128)、ENCRYPTキーワードを追記する
例)
CREATE TABLESPACE SECURE_TBL
DATAFILE '/u02/oradata/orcl/secure01.dbf' SIZE 100M
ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
4)ALTER TABLE ~ MOVEで表を移動
例)customers表を3)で作成した表領域に移動
ALTER TABLE CUSTOMERS MOVE TABLESPACE SECURE_TBL;
5)既存の表領域を削除
暗号化されていない既存の表領域を完全に削除する(shredコマンド等)
手順としては以上となる。OTNに列と表領域暗号のチュートリアルがあるので参考にしてほしい。今回は、ディスクの空き容量があると仮定してALTER TABLE MOVEコマンドを使用したが、datapumpでデータを抜き出すという方法やSQL Loader等でデータを挿入する方法などいくつか考えられる。表領域暗号化は、既存の表領域を暗号化に変更することができないので、新規作成してデータロードする、そのロード時に暗号化されてデータが格納されるという流れになる。
さて、ここまでは表領域暗号化の特徴や設定について紹介してきた。特に暗号化の性能への影響は表領域暗号化で大きく改善したといえる。しかし、さらにその影響を限りなくゼロにまで近づける衝撃的な機能が実装された。AES-NIである。次はこのAES-NIと表領域暗号化を組み合わせたゼロ・インパクトの暗号化を説明する。
■AES-NI (Advanced Encryption Standard New Instruction)
AES-NIとは、簡単に言ってしまえば、CPUにAES暗号アルゴリズムの演算ロジックを命令セットとして準備しておき、暗号化/復号処理をソフトウェアではなく、命令セットを呼び出すことにより直接プロセッサー側で演算処理をさせることができる機能だ。これは、Intel Xeonプロセッサーの5600番台から搭載されており、標準となっている暗号アルゴリズムAESを使用する際には、暗号処理を高速化するための強力な武器となる。 実際にIntelが公開しているホワイトペーパーを見てほしいが、その効果は絶大だ。 Oracle Database 11gR2 (11.2.0.2)の表領域暗号化からAES-NIに対応しているが、ホワイトペーパー (PDF)に含まれている検証結果は以下になる。
AES-NIとTDE 表領域暗号化
このテストケースは、100万行を空のテーブルにINSERT処理(30回)、510万行をテーブルからSELECT処理した場合、X5570(AES-NIなし)とX5680(AES-NIあり)での性能値を測定したものである。INSERT処理は暗号化、SELECT処理は復号の性能を意味している。
結果は、暗号化で10倍、復号で8倍高速化を実現したという衝撃的なものだ。 従来の表領域暗号化でもパフォーマンスへの影響を抑え高速化を実現していたが、AES-NIと組み合わせることで飛躍的な向上を実現することができることが分かったのだ。 ではもう少し具体的に、暗号化なしと比較した場合、OLTP系のトランザクション、CPUの使用率など、詳細なデータを取得すべく検証した結果をご紹介しよう。
■AES-NI + TDE表領域暗号化の検証結果
検証に使用したハードウェアは、Intel Xeon 5600 6core×2、Memory 24GB、HDD 300G。 ソフトウェアは、Oracle Linux 5 x86_64、Oracle Database Enterprise Edition 11.2.0.2、patch(10080579)。AES-NIを使用する際には、11.2.0.2にこのパッチを適用する必要がある。そして前述に紹介した手順で表領域暗号化を作成した。
(1)バッチ処理における暗号化性能
テストケースは、1 レコードあたり1MBのデータを、以下の3種類の表に100万回(1GB)のINSERT処理を行った場合の処理時間を計測した。(Direct Path Writeでバッファキャッシュを経由しない、暗号化なしの場合を相対処理時間と1とする。)
(2)バッチ処理における復号性能
1GBのデータが格納されている、以下の3つの表をテーブル・フルスキャンした場合の処理時間を計測した。 (Direct Path Readでバッファキャッシュは使用しない、暗号化なしの場合を相対処理時間と1とする)
AES-NIなしの場合、約20%程度の処理時間増が認められたが、AES-NIありの場合、わずか3%まで短縮された。
(3)OLTP処理における暗号化/復号性能
JpetstoreのアプリケーションをOLTP処理のトランザクションと仮定し、バッファキャッシュとDisk I/Oが同時に発生する一般的なアプリケーション(※キャッシュヒット率が高い)の場合、暗号化/復号処理がアプリケーションの性能にどう影響するかを計測した。 黄線(暗号化なし)と赤線(AES-NI)がほぼ同じ曲線つまり、同等の性能を担保できているといえる。
(4)AES-NIを使用した場合のCPUへの影響
1GBのデータを暗号化する場合、AES-NIを使用した場合と使用しない場合、CPUの使用率にどのくらいの違いがあるかを計測した。 AESの演算処理をソフトウェア側で実行するより、AES-NIによるプロセッサー側で実行したほうがCPU使用率を低く抑えられる。つまりCPUを効率的に使用しているということがわかる。
本検証結果を見てもらった通り、AES-NIを使用したTDE表領域暗号化はパフォーマンスが飛躍的に向上した。つまり、暗号化することにおけるパフォーマンスは心配無用、バッチ処理やOLTP処理であっても、限りなくゼロ・インパクトを実現することができるといえる。また、サイジングの面から考えると、暗号化する際のCPUやディスクの見積もりに関しても、そもそも表領域暗号化は暗号化によるオブジェクトのサイズ増はなし、AES-NIは従来よりもCPUを効率的に使用することができるので、暗号化だからといって過度のリソースを増強する必要はない。そして、暗号化すべきデータの選択においては、機密情報が少しでも含まれているオブジェクトはそのまま暗号化されている表領域へ。さらにスキーマの保有するオブジェクトをすべて暗号化するということも、今回の性能検証から現実的なソリューションとなってきたともいえる。
データベースの暗号化は、データベースのセキュリティの要件として、既に紹介したアクセスコントロール、監査も含めて是非検討してもらいたい重要な要件のひとつであると申しておきたい。
※本検証における詳細な解説は、以下をご参照頂きたい
最終回は、今年から新たにデータベース・セキュリティ製品に加わったOracle Database Firewallについて紹介する。2010年も猛威を振るったSQLインジェクション対策の切り札としてのSQLブロッキング、オーバーヘッドのないロギングを実現するモニタリングなどデータベースを最前線で防御することができる機能に触れることにするのでご期待頂きたい。
■関連資料