EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

データベース・セキュリティの実装 第3回 データベースの暗号化とパフォーマンスの両立

edited by DB Online   2011/11/09 00:00

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に対応しているが、ホワイトペーパーに含まれている検証結果は以下になる。

AES-NIとTDE 表領域暗号化
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とする。)

  •  暗号化なしの表
  •  TDE(表領域暗号化)に格納された表 + AES-NI をON
  •  TDE(表領域暗号化)に格納された表 + AES-NIをOFF

 グラフを見ると、従来のAES-NIない場合でも処理時間増はわずかであったが、AES-NIを使用するとほぼゼロになった。

 (2)バッチ処理における復号性能

 1GBのデータが格納されている、以下の3つの表をテーブル・フルスキャンした場合の処理時間を計測した。 (Direct Path Readでバッファキャッシュは使用しない、暗号化なしの場合を相対処理時間と1とする)

  •  暗号化なしの表
  •   TDE(表領域暗号化)に格納された表 + AES-NI をON
  •  TDE(表領域暗号化)に格納された表 + AES-NIをOFF

 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を効率的に使用することができるので、暗号化だからといって過度のリソースを増強する必要はない。そして、暗号化すべきデータの選択においては、機密情報が少しでも含まれているオブジェクトはそのまま暗号化されている表領域へ。さらにスキーマの保有するオブジェクトをすべて暗号化するということも、今回の性能検証から現実的なソリューションとなってきたともいえる。

 データベースの暗号化は、データベースのセキュリティの要件として、既に紹介したアクセスコントロール、監査も含めて是非検討してもらいたい重要な要件のひとつであると申しておきたい。

 ※本検証における詳細な解説は、以下をご参照頂きたい。
 【セミナー動画/資料】データベースの暗号高速化テクノロジー「AES-NI」とその活用方法とは

 最終回は、今年から新たにデータベース・セキュリティ製品に加わったOracle Database Firewallについて紹介する。2010年も猛威を振るったSQLインジェクション対策の切り札としてのSQLブロッキング、オーバーヘッドのないロギングを実現するモニタリングなどデータベースを最前線で防御することができる機能に触れることにするのでご期待頂きたい。

関連資料

 ・Oracle Advanced Security|オラクルエンジニア通信
 ・ユーザー・アカウントおよびセキュリティの管理|オラクルエンジニア通信

 ※この記事はoracletech.jpからの転載です。



著者プロフィール

  • oracletech.jp編集部(オラクルテックジェイピーヘンシュウブ)

    oracletech.jpは、オラクル・データベースと関連製品をお使いいただいている皆様、開発に携わっているエンジニアの皆様、オラクル製品を販売いただいている皆様すべてにとって有益な情報源となることを目指しています。 エンタープライズ系ITを中心に、製品情報や技術情報からテクノロジー・トレンド、キャンペーンやイベント/セミナー情報まで多岐にわたります。日本オラクルの社員だけでなく、外部の有識者やフリーランス・ライターを含む幅広い執筆陣により"ベンダー発"の枠を脱したコンテンツ発信を目指します。 好奇心が、エンジニア人生を豊かにする。 oracletech.jp

バックナンバー

連載:oracletechアーカイブス!
All contents copyright © 2007-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5