“データベース暗号”は本当に必要なのか?<3>

IT・IT製品TOP > Key Conductors > 片岡 裕紀(トライポッドワークス株式会社) > “データベース暗号”は本当に必要なのか?<3>
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

“データベース暗号”は本当に必要なのか?<3>

エンドポイントセキュリティ 2014/06/12

前回までの「“データベース暗号”は本当に必要なのか?」

“データベース暗号”は本当に必要なのか?<1>

“データベース暗号”は本当に必要なのか?<2>

 前回までの「“データベース暗号”は本当に必要なのか?」では、データベース暗号の触りと法制面、ガイドラインなどから必要性を紐解いてきました。

 本稿では、<データベース暗号> の技術的な側面を紹介していきます。

暗号化すべきデータは何だろう?

 繰り返しになってしまいますが個人情報保護法や各種ガイドラインなどからデータベースで暗号化するデータは、主に下記のようなものが挙げられます。(医療や金融業界になると他にも多くの機密情報があり候補も増えるかもしれません。)

氏名、住所、電話番号、携帯電話番号、Eメールアドレス、クレジットカード番号、ログインID、パスワード
 
その他、個人が特定できる、または、間接的に特定できる可能性のあるデータが対象になるでしょう。

 ここで注意すべきは、過剰に暗号対象を増やし過ぎないことです。
 対象が増えるとテーブル設計、再設計が複雑になるうえにSQL文のJOIN句などのレスポンスに影響を与えてしまいSQL文の改修が発生することもあります。また、RDBMSのパース処理やディスクI/Oが発生することでレスポンスが悪くなってしまいます。
 僕の経験ではRDBMSの性能は、アプリケーションから発行されているSQL文やテーブル設計を見直すことで大きく改善されることも少なくはありませんでした。

 このことを踏まえて暗号化する対象は、法律、または、ガイドラインを遵守するために保護する必要のある最低限のデータに留めることが大事です。

<データベース暗号>ってどんな種類があるの?

 みなさんは <データベース暗号> と聞いて、どのような種類を想像するでしょうか?
<データベース暗号> といっても実質的には暗号化する対象(範囲)により種類が大きく異なってきます。

<データベース暗号>の主な種類

1.

ディスク暗号
⇒ RDBMSがデータを書き込むハードディスクを暗号化する。
 

2.

ボリューム/パーティション暗号
⇒ RDBMSがデータを書き込むボリューム、または、パーティションだけ暗号化する。
 

3.

テーブル(または、表領域)暗号
⇒ RDBMSがデータを書き込むテーブル(または、表領域)を暗号化する。
 

4.

カラム(列)暗号
⇒ RDBMSがデータを書き込む特定のカラム(列)だけを暗号化する。
 

データベース暗号の種類イメージ

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

データベース暗号の種類イメージ
RDBMSが書き込むストレージ領域(もしくは、範囲)のイメージ

 ご覧のとおり、幾つかありますが僕のなかでは<データベース暗号>といえば、「カラム暗号」と「テーブル暗号」になります。

カラム暗号の手法

 本稿では、「4.カラム暗号」について触れていきます。カラム暗号は、主に2つの手法があります。テーブル暗号にも表領域の割り当てなどノウハウがあると思います。

カラム暗号の手法

1.

関数暗号

2.

透過型暗号

■1.関数暗号

 関数暗号は2005年以前から提供されている手法です。関数暗号にもアプリケーション(クライアント)で実装される方法とデータベースエンジンで提供されるものがあります。
 いずれも、プログラムから発行される更新系SQL(INSERT/UPDATE)に含まれる対象カラムの数だけ修正が必要になり、既存プログラムの改修が大変になります。逆に復号するときは、照会SQL(SELECT)で復号関数を指定する必要があります。

>例:普通の挿入SQL文
INSERT INTO T1 ( C1, C2, C3, C4 ) VALUES ( 10001, 'CLARK', 'MANAGER','2013-01-01' );

>例:暗号関数を使った挿入SQL文
INSERT INTO T1 ( C1, C2, C3, C4 ) VALUES ( 10001, 'CLARK',ENC('MANAGER'), '2013-01-01' );

>例:復号関数を使った照会SQL文
SELECT  DEC(C3) FROM T1;

 下図は、ストアドファンクション内の文字列の動きを表したイメージです。関数の呼び出しで引数に含まれる値が関数内で暗号化され、これはプログラム関数でも同じことが云えます。

ストアドファンクション内の動きを表したイメージ

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

ストアドファンクション内の動きを表したイメージ

この例だと、INSERT文でSF_FUNC関数が呼び出され、引数が関数内で暗号化されてデータベースに挿入されます。

 関数暗号は、現実的にカラムだけが対象になります。現在では、後述する「透過型暗号」が主流になってきており、関数暗号という選択肢は、よほどの事情がない限り採用されないはずです。

■2.透過型暗号

 前述の「関数暗号」と比較して透過型暗号は比較的、採用が容易です。RDBMSベンダが提供する <データベース暗号> の機能はデータベースエンジンで行われるため、テーブルやカラムを透過的に暗号/復号化することができます。
 もちろん、データベースで暗号化する対象のテーブルやカラムを再定義しなければなりませんがアプリケーションは普通の更新系SQL文を発行するだけで内部的に暗号化されます。また、参照SQLで内部的に復号化されて返却されます。

※過去にお客様が心配にしていたことは、DBサーバーの負荷とレスポンスです。容易でないことは知っていますが、もしも、ステージングなどの検証環境がある場合は、平文環境と暗号環境で1億件〜5億件ほどのランダムデータを更新、照会するプログラムによる性能計測をお薦めします。
>暗号カラムを含むテーブル作成SQL文例(テーブル定義更新でも指定可能) ※Oracle Databaseの場合
CREATE TABLE T1 (
C1 NUMBER(7),
C2 NUMBER(7) ENCRYPT USING 'AES256' SALT,
C3 VARCHAR2(20) ENCRYPT USING 'AES256' NO SALT,
C4 TIMESTAMP
);

 暗号/復号は透過的に行われるため、クライアントプログラムで発行されるSQL文の変更は基本的には必要ありません。

暗号アルゴリズムは何を選べばいいの?

 次に暗号アルゴリズムの話になります。※本来は暗号アルゴリズムだけではなく「暗号鍵」の「キーマネジメント(鍵管理)」がとても重要になりますが記事にまとめられないため、機会があれば寄稿します。

 暗号アルゴリズムの話には必ず、NIST(National Institute of Standards and Technology:アメリカ国立標準技術研究所)の FIPS 140-1/FIPS 140-2 が現れます。

 日本国内では、これをベースに CRYPTREC(Cryptography Research and Evaluation Committees)の推奨する暗号アルゴリズムがあり、この「CRYPTREC」が推奨する暗号リストは「電子政府における調達のために参照すべき暗号のリスト」にまとめられています。

3-key Triple DES....

Data Encryption Standard を3回行っている暗号アルゴリズム

AES......................

Advanced Encryption Standard

 <データベース暗号> では、上述の2つを知っていると概ね大丈夫だと思います。これらの内、暗号アルゴリズムは、AESの192-bitか256-bitをお薦めします。システムによっては、ハッシュ関数(一方向性)など他のアルゴリズムも候補に挙がるのかもしれませんが僕の経験ではありませんでした。

 一般的に暗号アルゴリズムを後で変更する場合、既に暗号化したデータを再度、暗号化しなければなりません。そのため、将来的に耐えうる、そして、信頼できる、また、国が推奨する暗号アルゴリズムを選定しておくことが重要です。

 ここまで <データベース暗号> の種類〜アルゴリズムまで寄稿しました。それぞれが、とても難しい内容で僕自身も全てを知っているわけではありません。ただ、今回の内容ではキーワードとして下記のことだけを記憶に留めて頂けると幸いです。

もしも、<データベース暗号>を実装するなら....

暗号対象は法制面、ガイドラインの要件に留める

カラムやテーブル暗号の主流は「透過型暗号」

暗号アルゴリズムは「AES」の192ビットか256ビット

 次回も引き続き技術的な情報と各RDBMSベンダの対応状況をご紹介できればと思います。

CRYPTREC
電子政府推奨暗号の安全性を評価・監視し、暗号技術の適切な実装法・運用法を調査・検討するプロジェクトです。
http://www.cryptrec.go.jp/

NIST(National Institute of Standards and Technology:アメリカ国立標準技術研究所)
http://www.nist.gov/

2013年から FIPS 140-3 を制定中
http://csrc.nist.gov/groups/ST/FIPS140_3/index.html

PCI DSS 3.0(2013年11月)
https://www.pcisecuritystandards.org/security_standards/documents.php

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30007290


IT・IT製品TOP > Key Conductors > 片岡 裕紀(トライポッドワークス株式会社) > “データベース暗号”は本当に必要なのか?<3>

このページの先頭へ

キーマンズネットとは
1978年、福岡県出身。2004年にプログラマとしてITベンチャーに転身。RDBMS向けの<国産>セキュリティ ソフトウエア開発とプレセールスを経験。その後、少しだけ経営を携わり、2010年12月にトライポッドワークス株式会社へ入社。

ページトップへ