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

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

IT現場の道先案内人 Key Conductors

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

エンドポイントセキュリティ 2015/07/01

前回の寄稿から随分と空いてしまいました。
RDBMSに触れる機会が全くなくなりインストールや設定などが面倒で今の会社に元プロがいるからお願いして実行結果だけ欲しいなぁと思いつつも…ようやく重い腰を上げました。

さて、「"データベース暗号"は本当に必要なのか?」では、これまでに<データベース暗号>の概要と法制面の側面から必要性をお伝えしてきました。

今回は、実際にRDBMSの透過暗号機能(TDE)を使ってデータの暗号化を行い、暗号データを見てみます。この記事を通して<データベース暗号>を少しでも身近に感じていただければと思います。

※本記事ではOracle Databaseを用いている都合上、固有の単語や文字列が表れます。
※本記事内の実行結果は表示の都合上、整形しています。
※本記事では簡素化するためにコマンドやSQL文を省略しているものもあります。

データベースの暗号を確認してみよう!

この記事で作業した構成

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

この記事で作業した構成
今回、確認した環境(構成)
TNSNAMES.ORAとかの設定が面倒なのでSSHで直接操作

RDBMSベンダーが提供する透過暗号は、ネイティブのSQLクライアントでは復号化されたデータが出力されるか、そもそも権限がなければアクセスできない設計になっています。

そのため、「証明しろ」と言われても、その場で簡単に証明することはできません。

この記事では、Oracle Database の Transparent Data Encryption を使ってデータが実際に暗号化されていることを確認していきます。

記事内にSQL文や実行結果などがあり、見慣れない方には不親切な表示になってしまっていますが、太字だけでも追っていくと、なんとなく繋がりがわかると思います。

結果だけを見たい方は、後述する「4.実データを確認して暗号化されているか確認」の画像をみてください。
※ Oracle Databaseでは、12c から「Oracle Data Redaction」という暗号化せずにデータをマスキングして表示する機能も追加されています。
この記事で作成するテーブルと列

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

この記事で作成するテーブルと列
暗号化されているかを確認するために、今回は右表のような暗号カラムが含まれる簡単なテーブルを作成してみます。

ここでは、作成時のDDLを省略して済ませていますが暗号アルゴリズムを指定したテーブルの作成もできます。

1.暗号カラムを含むテーブルの作成

それでは、実際に暗号化するカラムを簡略指定してテーブルを作成します。文字型以外のデータ型も暗号化できますので、詳しくは、各RDBMSのマニュアルをご参照ください。

CREATE TABLE T2_E (
C1 VARCHAR2(11),
C2 VARCHAR2(30) ENCRYPT,
C3 VARCHAR2(30),
C4 CHAR(6) ENCRYPT
);

DBMS_METADATA.GET_DDL(※1)を使って実際に作成されているテーブルからDDLを取り出してみると、暗号アルゴリズムもしっかりと指定されていることがわかります。

  CREATE TABLE "SCOTT"."T2_E"
   (    "C1" VARCHAR2(11),
        "C2" VARCHAR2(30) ENCRYPT USING 'AES192' 'SHA-1',
        "C3" VARCHAR2(30),
        "C4" CHAR(6) ENCRYPT USING 'AES192' 'SHA-1'
   ) SEGMENT CREATION DEFERRED
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS LOGGING
  TABLESPACE "USERS"
※1 データディクショナリからテーブルや索引などをDDLとして取り出すOracle Databaseの関数

2.指定したカラムが暗号対象として定義されているかを確認

次に、dcore.bsq というコア部分に関わる定義ファイルがあり、この中身を覗いてみるとカラム暗号(乱数あり、乱数なし)などの識別番号が定義されています。

SHELL> vi $ORACLE_HOME/rdbms/admin/dcore.bsq
 
〜省略〜
/* 0x04000000 = 67108864 = Column is encrypted                         */ ← 乱数あり
/* 0x20000000 = 536870912 = Column is encrypted without salt       */ ← 乱数なし
〜省略〜

作成したテーブルに上述のプロパティが定義されているか確認してみます。
まず、確認するために作成したテーブルのオブジェクトIDを調べます。

SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OWNER = 'SCOTT' AND OBJECT_NAME = 'T2_E';
 
OBJECT_ID
------------
      93062
 
※オブジェクトIDは実行により結果が異なります。

調べたオブジェクトIDから作成したテーブルのプロパティを確認してみます。

SELECT NAME, PROPERTY FROM COL$ WHERE OBJ# = 93062;
 
NAME        PROPERTY
-----------  --------------------
C1             0
C2             67108864
C3             0
C4             67108864

もう一度、定義ファイルを見てみましょう。

/* 0x04000000 = 67108864 = Column is encrypted                         */

実行結果から乱数ありの暗号カラムになっていることがわかります。
単純に暗号化といっても内部的には、このようにしっかりと定義されていることが理解できます。

ここまで(簡単にですが)実際の暗号カラムが含まれるテーブルを作成して定義などを確認してみました。

3.データを1行だけ挿入してデータを表示

次にデータを挿入して参照してみます。

INSERT INTO テーブル名 (C1, C2, C3, C4) VALUES ('10001', 'Tripod', 'Works', '99999');

表示すると、当然ですがデータは格納されています。

SELECT * FROM T2_E;
 
C1          C2                            C3                            C4
---------  -----------------------  -----------------------  --------
10001    Tripod                       Works                       99999

ここで「なんだ暗号化されていないじゃないか…」と思われる方もいるかもしれませんが前述のとおり透過的に復号化して出力されています。

4.実データのダンプファイルから暗号化されているか確認

それでは、これから暗号化されているのか確認を行ってみたいと思います。
トレースファイルで確認するためにファイル番号やブロック番号を確認します。

-- 普通のテーブル
SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(ROWID, 'SCOTT', 'T2') ABSOLUTE_FNO, DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) BLOCKNO, DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) ROWNUMBER FROM T2;
 
ABSOLUTE_FNO   BLOCKNO   ROWNUMBER
-------------------  ------------  ---------------
                      6            237                   0
 
-- 暗号化が含まれる方のテーブル
SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(ROWID, 'SCOTT', 'T2_E') ABSOLUTE_FNO, DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) BLOCKNO, DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) ROWNUMBER FROM T2_E;
 
ABSOLUTE_FNO   BLOCKNO   ROWNUMBER
-------------------  ------------  ---------------
                      6           229                    0
 
※上出力は実行環境によって異なります。

上述のファイル番号とブロック番号からトレースファイルを確認してみると暗号カラムを含むデータが実際に暗号化されていることを確認できます。

標準の方(ブロック番号:237の方)

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

標準の方(ブロック番号:237の方)
画像はファイルから対象の範囲を切り取ったものです。
画像内の赤文字を見てください。

標準のテーブル

暗号カラムの方(ブロック番号:229の方)

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

暗号カラムの方(ブロック番号:229の方)
画像はファイルから対象の範囲を切り取ったものです。
画像内の赤文字を見てください。

暗号カラムが含まれるテーブル

改めて挿入したデータをみてましょう。(暗号対象は、C2列とC4列です。)

INSERT INTO テーブル名 (C1, C2, C3, C4) VALUES ('10001', 'Tripod', 'Works', '99999');

いかがでしょうか?
この記事でいうところのブロック番号 229 のダンプデータで C2列の 'Tripod' と C4列の '99999' という文字列が読めないことから暗号化されているといえるでしょう。

Oracle Database や Microsoft SQL Server の透過暗号(TDE)は名前こそ長いですが設定自体は難しいものでもありませんので興味がある方は、是非、試してみてください。

親しみやすくなったけど気が抜けないデータベース暗号

透過暗号の移行プラン例

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

透過暗号の移行プラン例
この画像は一例です。

RDBMSベンダーが提供する透過暗号や3rdパーティ製の透過暗号製品では、多くの場合、本番環境と同じデータベースをステージング環境に作成、暗号化した後にダンプエクスポートなどのツールを使って本番環境に戻せば、それなりに時間はかかるけどスムーズに暗号環境へ移行することができます。

過去までの関数暗号では、アプリケーションに実装している関数を改修したりと手間が多かったのですが、透過暗号の登場で比較的容易になり、過去よりも親しみやすくなったといえるかもしれません。

ただ、透過暗号により受ける影響は、例えば、発行するSQL文による性能、テーブル構成による性能、一部データ型への影響などなど、皆無とは断言できませんので事前に調査してから実施する必要あることに変わりはありません。

最近では、マイナンバー対策にあわせて<データベース暗号>の需要も増えていると思います。データベースのセキュリティは、色々な意味でクリティカルな対策なので信頼できるパートナーに相談してから対策してください。

繰り返しになりますが、<データベース暗号>においては「性能劣化」が付きまといます。
概ね、1.2〜1.7倍程度を想定すれば良いと思いますが前述に挙げたもの含め、性能は様々な側面から影響を受けます。

しっかりと検証や性能測定などを実施して安心できる <データベース暗号> を行ってください。

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

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

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

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


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


30008035


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

このページの先頭へ

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

ページトップへ