Oracle TDE 表領域暗号化③｜鍵の管理：失えばデータは二度と戻らない

TDEで暗号化したデータは、鍵（ウォレット）がなければ二度と読めません。これは攻撃者だけの話ではありません。

正規の管理者であるあなた自身も、鍵を失えば、自分のデータを永久に取り戻せなくなります。

試しに、鍵を閉じた状態で暗号化表を読んでみます。

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "********";   -- 鍵（ウォレット）を閉じる
SQL> SELECT * FROM plain_mig;   -- 暗号化表を読んでみる
SELECT * FROM plain_mig
*
1行でエラーが発生しました。:
ORA-28365: ウォレットがオープンしていません

わずか1コマンドで、自分のデータが読めなくなりました。

TDE運用で本当に難しいのは「暗号化すること」ではなく、その先の「鍵を、失わず・盗まれずに管理し続けること」です。

第3回では、TDEを本番で運用するときに必ずぶつかる3つの場面を実機で検証します。

• 移行：すでに平文で動いているDBを、止めずに暗号化する
• ウォレットファイル（ewallet.p12）はいつ必要か：常に置いておくのか、開くときだけでいいのか
• 復旧：ウォレットファイルを失ったとき、本当に元に戻せるのか

この記事について

本記事は、Oracle Database 19c の TDE 表領域暗号化を実機で検証する連載の第3回です。 第1回（設計と基本構築）・第2回（守れる範囲・守れない範囲）に続く、運用フェーズにあたります。

連載の全体マップ:

想定読者:

• TDEを導入したい／導入したが、既存DBへの移行や鍵の運用に不安がある方
• 「ウォレットファイルは常にサーバに置いておく必要があるのか？」を知りたい方
• TDEのバックアップ・DR設計を具体的に詰めたい方

前提知識:

• 第1回の内容（ウォレット・マスター鍵・キーストアのオープン状態）
• SQL*Plus・Linux の基本操作

第1回がまだの方は、先に「設計と基本構築」を読むと、本記事の鍵の話がつながります。

検証環境

第1回で構築した、ソフトウェアキーストア（FILE方式・PASSWORDウォレット）の環境をそのまま使います。

ライセンス前提: TDE（表領域暗号化）は Oracle Enterprise Edition ＋ Advanced Security オプションの機能です。Standard Edition (SE2) では利用できません。本連載はこの前提で構築しています。

1. 稼働中の本番DBを、止めずに暗号化する — オンライン暗号化移行

TDEの解説は「最初から暗号化した表領域を作る」前提のものが多くあります。

でも現実には、すでに平文で何年も動いているDBに後からTDEを入れたい、というケースがほとんどです。

ここで問題になるのが「本番は止められない」ことです。素朴なやり方は「新しく暗号化した表領域を作り、データを丸ごと移し替える」方法。でもこれは、移し替えのあいだサービスを止めなければなりません。表領域が大きいほど、現実的でなくなります。

そこで使うのが オンライン暗号化 です。 ユーザーが読み書きしているのと並行して暗号化でき、アプリを止めずに移行できます。

本当に止めずに移行できるのか、実機で確かめます。平文がディスクから漏れている状態を作り、サービスを止めずに暗号化します。 そのあと、漏れが消えたか・データが欠けていないかを順に確認します。

before：平文表領域に機密データがある状態

第1回で作った平文表領域 plain_ts に、移行検証用の機密データ（氏名・カード番号）を追加しておきます。

SQL> CREATE TABLE plain_mig (id NUMBER, name VARCHAR2(40), card VARCHAR2(25)) TABLESPACE plain_ts;
SQL> INSERT INTO plain_mig VALUES (1,'PLAINTEXT-LEAK-MIGRATE','4111-1111-1111-1111');
SQL> INSERT INTO plain_mig VALUES (2,'PLAINTEXT-LEAK-TANAKA','4111-2222-3333-4444');
SQL> COMMIT;
SQL> ALTER SYSTEM CHECKPOINT;

データファイルを直接 grep すると、当然まだ丸見えです。なお plain_ts には第1回で作った hr_secret_plain（PLAINTEXT-LEAK-0614）も同居しているので、grep はそれも一緒に拾います。まずヒット件数、次に中身を見ます。

$ strings /u01/app/oracle/oradata/ORCL19U/plain_ts01.dbf | grep -c -E 'PLAINTEXT-LEAK|4111-1111|4111-2222'
6

$ strings /u01/app/oracle/oradata/ORCL19U/plain_ts01.dbf | grep -E 'PLAINTEXT-LEAK|4111-1111|4111-2222'
PLAINTEXT-LEAK-0614
4111-1111-1111-1111
PLAINTEXT-LEAK-TANAKA
4111-2222-3333-4444
PLAINTEXT-LEAK-MIGRATE
4111-1111-1111-1111

6件ヒット（第1回の hr_secret_plain ＋ 今回の plain_mig）。氏名もカード番号も平文です。

止めずに暗号化する

表領域を稼働させたまま、1行で暗号化します。

SQL> ALTER TABLESPACE plain_ts ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
SQL> ALTER SYSTEM CHECKPOINT;

暗号化されたか確認します。

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE tablespace_name='PLAIN_TS';

TABLESPACE_NAME                ENC
------------------------------ ---
PLAIN_TS                       YES

ENCRYPTED=YES になりました（v$encrypted_tablespaces にも ts#7 AES256 として登録されます）。サービスは一切止めていません。

after：同じ grep で、もう抜けない

$ strings /u01/app/oracle/oradata/ORCL19U/plain_ts01.dbf | grep -c -E 'PLAINTEXT-LEAK|4111-1111|4111-2222'
0

6件 → 0件。 平文がディスクから消えました。plain_ts ごと暗号化したので、同居する両テーブル（第1回の hr_secret_plain も）まとめて守られたわけです。表領域暗号化は、表領域内の全テーブルに一括で効きます。

データは欠けていないか

暗号化は「正規利用では読めるが、盗んでも読めない」状態を作るものです。正規のSELECTでは、これまでどおり平文が返らないと意味がありません。

SQL> SELECT * FROM plain_mig;

        ID NAME                       CARD
---------- -------------------------- -------------------------
         1 PLAINTEXT-LEAK-MIGRATE     4111-1111-1111-1111
         2 PLAINTEXT-LEAK-TANAKA      4111-2222-3333-4444

ディスクを直接見れば暗号文（grep しても何も出ない）／DB経由でだけ平文が読める。移行でデータが欠けることなく、「盗難には強く・正規利用には透明」が両立しました。

TDE暗号化時の注意点

オンライン暗号化で押さえておくのは、暗号化中だけ一時的にデータファイルが2つになることです。これは「元のファイルをその場で1ブロックずつ書き換える」やり方ではなく、Oracle が内部で、暗号化版のデータファイルを別名で作り、完成後に元の名前へ自動で差し替えます。

これは実機で確認できます。暗号化の最中だけ、データファイルのあるディレクトリを覗くと…

$ ls /u01/app/oracle/oradata/ORCL19U/      # ← 暗号化の最中だけ
... enc_obs01.dbf  enc_obs01.dbf_new ...

元の enc_obs01.dbf の隣に、enc_obs01.dbf_new（暗号化版） が現れています。Oracleはこの _new を作り終えてから、元のファイル名へ差し替えます。完了後は enc_obs01.dbf 1つに戻ります。

暗号化にかかる時間は表領域のデータ量しだいです（本番の大きな表領域なら数分以上かかることも）。今回は小さな検証用表領域なので一瞬で終わり、上の一覧はディレクトリを0.1秒間隔で監視して記録しました。普通に ls を1回打っても、出ているのは一瞬です。

この「新しいファイルを作って差し替える」しくみから、2つの注意点が出てきます。

• 表領域サイズ相当の空き領域が必要：暗号化中は元＋ _new の2ファイルが共存するため。足りないと ORA- でエラー
• パスは変わらない：暗号化コマンドに FILE_NAME_CONVERT = ('元パス','新パス') を付けない限り、出来上がりのファイル名・パスは元と同じ（付ければ別ディスクへ出力先を変えられる）

そしてこのしくみのおかげで、差し替え後のデータファイルには古い平文ブロックが残りません（最初から暗号化版として作られるため。実機で grep しても何も出ません）。

補足（暗号化が及ばない“物理の痕跡”）：暗号化されるのは、いま使っているデータファイル（論理）の中身までです。そのファイルが暗号化前に置かれていた HDD/SSD 上の場所には、OSがそこを別データで上書きするまで古い平文ブロックが残ることがあります（オンライン／オフライン問わず）。だから退役した HDD/SSD・廃棄メディアは、別途セキュア消去か物理破壊が必要で、暗号化はこの物理の痕跡までは消しません。消し方はメディアで変わり、HDDは dd／shred での上書き、SSDはウェアレベリングで dd が物理セルに当たらないことがあるため hdparm のATA Secure Erase やドライブの crypto-eraseを使うのが確実です。

2. ウォレットファイルを移動しても動くのか — メモリかファイルか、実機で確かめる

ここからが本記事のいちばん大事なところです。TDEを運用していると、こんな疑問が出てきます。

ウォレットファイル（ewallet.p12）は、常にサーバ上のその場所に存在しないとダメなのか？ それとも、ウォレットをオープンする瞬間だけあればいいのか？

これはただの好奇心ではありません。答えによって、次の2つが変わります。

• 何を盗まれると危ないのか（守るべき対象）
• 鍵を普段は外しておく運用が成り立つか（USBなど着脱式の媒体に置く構成）

どちらも、実際の運用に直結する問いです。

仮説

ウォレットを開くとき、Oracleはウォレットファイルを読んで、マスター鍵をメモリ（SGA）に乗せます。もしそうなら、こうなるはずです。

1. 開いたあとはファイルを消しても、稼働中は復号できる（鍵はメモリにある）
2. KEYSTORE CLOSE すると、鍵がメモリから消えて読めなくなる
3. ファイルが無いと、開き直す（再起動を含む）ことはできない

これを実際に試して確かめます。

今回の環境は自動ログイン（cwallet.sso）なしの PASSWORD ウォレットなので、退避するのは ewallet.p12 だけで済みます。

Phase 1：ファイルを消しても、稼働中は読めるか

オープン中のまま、ウォレットファイルを別の場所へ退避します。

$ ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/      # ← 退避前
合計 8
-rw-------. 1 oracle oinstall 3993 ... ewallet.p12               ← 稼働用（これから退避する）
-rw-------. 1 oracle oinstall 2553 ... ewallet_<timestamp>.p12   ← 自動バックアップ（別名）

$ mkdir -p /home/oracle/tde_filetest
$ mv /u01/app/oracle/admin/orcl19u/wallet/tde/ewallet.p12 /home/oracle/tde_filetest/   # 稼働用を退避

$ ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/      # ← 退避後
合計 4
-rw-------. 1 oracle oinstall 2553 ... ewallet_<timestamp>.p12   ← バックアップだけ。稼働用 ewallet.p12 は消えた

合計 8 → 4、ewallet.p12（3993バイト）が消えました。 残るのは名前の違う自動バックアップ ewallet_<timestamp>.p12 だけです。 この状態で、ウォレットの状態と暗号化表が読めるかを確認します。

SQL> SELECT status, wallet_type FROM v$encryption_wallet;

STATUS               WALLET_TYPE
-------------------- --------------------
OPEN                 PASSWORD

SQL> SELECT * FROM plain_mig;

        ID NAME                       CARD
---------- -------------------------- -------------------------
         1 PLAINTEXT-LEAK-MIGRATE     4111-1111-1111-1111
         2 PLAINTEXT-LEAK-TANAKA      4111-2222-3333-4444

ファイルが無いのに STATUS=OPEN のまま、暗号化表が読めます。 さらに、バッファキャッシュを空にして「ディスクから読み直す」状況にしても、

SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;   -- ディスクから読み直す状況を作る
SQL> SELECT * FROM plain_mig;

        ID NAME                       CARD
---------- -------------------------- -------------------------
         1 PLAINTEXT-LEAK-MIGRATE     4111-1111-1111-1111
         2 PLAINTEXT-LEAK-TANAKA      4111-2222-3333-4444

やはり読めます。 これで「稼働中はウォレットファイルがなくてもいい。マスター鍵はメモリ（SGA）に乗っていて、そこで復号している」とはっきりしました。

補足（公式の裏付け）：表領域暗号化では、復号した平文ブロックがSGAのバッファキャッシュにキャッシュされます（Oracle公式 Advanced Security Guide のTDE FAQ：「TDE tablespace encryption improves performance by caching unencrypted data in memory in the SGA buffer cache.」）。だから FLUSH BUFFER_CACHE で消えるのはこの平文コピーで、再読込ではディスクの暗号文をメモリ常駐の鍵で復号し直すため読めます。裏返せば、稼働中はメモリ上に平文がある＝SGAを抜かれれば中身が見える、という脅威にもつながります。

Phase 2：閉じると消える／ファイル無しでは再オープンできない

次に、ウォレットを閉じます。

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "********";   -- ウォレットを閉じる
SQL> SELECT * FROM plain_mig;
SELECT * FROM plain_mig
*
1行でエラーが発生しました。:
ORA-28365: ウォレットがオープンしていません

CLOSE した瞬間に読めなくなりました（鍵がメモリから消えた）。

なお、CLOSE で読めなくなるのは暗号化した表領域だけで、DB（インスタンス）自体は動き続けます（今回は SYSTEM/SYSAUX を暗号化していないため）。もし SYSTEM まで暗号化していたら、CLOSE の影響は桁違い（DBが回らなくなる）です。
SYSTEM まで暗号化した環境で実際に何が起きるか（ウォレットが開かないと startup が MOUNT で止まります）は、別記事「ORA-28365 で startup が MOUNT で停止する」で実機検証しています。

では、ファイルが無い状態で開き直そうとすると、

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********"
*
1行でエラーが発生しました。:
ORA-28367: ウォレットが存在しません

ORA-28367。開き直すにはウォレットファイルが要ります。仮説どおりの結果でした。

ついでに分かったこと: 同じディレクトリにタイムスタンプ付きのバックアップ（ewallet_<timestamp>.p12）があっても、自動では使われません。開き直すのに必要なのは、正しいファイル名 ewallet.p12 です。「とりあえずバックアップさえ残っていれば戻せる」は間違いで、正しい名前で正しい場所に戻す必要があります。

復旧（原状復帰）

ウォレットファイルを元の場所へ戻せば、再オープンできます。

$ ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/      # ← 戻す前
合計 4
-rw-------. 1 oracle oinstall 2553 ... ewallet_<timestamp>.p12   ← バックアップだけ（稼働用が無い）

$ mv /home/oracle/tde_filetest/ewallet.p12 /u01/app/oracle/admin/orcl19u/wallet/tde/   # 元の場所へ戻す

$ ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/      # ← 戻した後
合計 8
-rw-------. 1 oracle oinstall 3993 ... ewallet.p12               ← 稼働用が復活
-rw-------. 1 oracle oinstall 2553 ... ewallet_<timestamp>.p12   ← 自動バックアップ

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
SQL> SELECT * FROM plain_mig;

        ID NAME                       CARD
---------- -------------------------- -------------------------
         1 PLAINTEXT-LEAK-MIGRATE     4111-1111-1111-1111
         2 PLAINTEXT-LEAK-TANAKA      4111-2222-3333-4444

ファイルが無くても“読める”。でも鍵の更新はできない

ここまでで「ファイルが無くても、稼働中はデータを読める」と分かりました。 では、ファイルが無い状態で鍵を更新（ローテーション）しようとすると、どうなるでしょうか。

ウォレットファイルを退避したまま、マスター鍵の更新を試みます。

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "********" WITH BACKUP;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "********" WITH BACKUP
*
1行でエラーが発生しました。:
ORA-46624: ソース・キーストア・サービスが見つかりません

SET KEY ... WITH BACKUP は、今のウォレットファイル（ewallet.p12）を読んでバックアップを取り、新しい鍵を書き込む操作です。 その元になるファイルが無いため、ORA-46624 で失敗します（マスター鍵もデータも無傷のまま）。

ここで、ウォレットファイルが要る/要らないの線引きが、もう一段はっきりします。

• データを読む（復号）：ウォレットファイルが無くてもOK（鍵はメモリにある）
• 鍵をいじる（更新・ローテーション）：ウォレットファイルが必須（結果をファイルに永続化するため）

つまり「稼働中に“読む”だけならメモリで足りる。でも“鍵そのものをいじる”操作は、必ずファイルが要る」。これがTDEの鍵まわりの実際のところです。

結論：ウォレットファイルは「オープンの瞬間だけ」必要

実験をまとめると、こうなります。

この事実は、2つの設計判断に直結します。

① 守るべき対象が、サーバの状態で変わる

• 稼働中のサーバ：ウォレットファイルを盗まれても、それだけでは復号できない（パスワードも要る）。むしろ危ないのは「稼働中のメモリから平文データや鍵を読み出されること」に移る（特権OSユーザーやメモリダンプ経由。TDEは at-rest 専用で、ここは守りません）
• 停止中のサーバ・退役したディスク：危ないのはそのまま「ファイルを盗まれること」

「守るべき対象」がサーバの状態で変わる、というのは監査や対策を考えるうえで大事な視点です。

メモリ側は完全には防げません（稼働中は平文も鍵もRAMに置くしかないため）。できるのは”露出を減らす”ことです。いちばん効くのは最小権限：root・oracle・VM管理者を絞って監査し、メモリを読める人を減らす。加えて、HSMを使えば鍵をサーバの外に置けます（鍵はメモリに出ない。ただし平文データはメモリに残る）。あとはコアダンプ無効・スワップ暗号化で、平文がうっかりディスクへ漏れる口を塞ぎます。

② 鍵を普段は外す運用は“できる。ただし使い勝手と引き換え”

「開くときだけ鍵の媒体をつなぎ、普段は外しておく」という運用は、理屈の上では成り立ちます（稼働中はメモリで動くので）。セキュリティを上げたい場面では有効な手です。

ただし、自動ログイン（cwallet.sso）なしの PASSWORD ウォレットだと、再起動のたびに媒体をつなぎ、手でウォレットを開く手間がかかります。逆に LOCAL 自動ログインを使うと「起動時にいつも鍵が要る」ので、この自由はなくなります。盗まれにくさを取るか、使い勝手を取るか。TDE運用でいちばん悩む選択が、ここに出ます。

3. ウォレットファイルを失ったら戻せるか — バックアップから復旧を試す

「リカバリテストができていないバックアップは、バックアップではない」。鍵がデータの生命線である以上、これは鍵にこそ当てはまります。

第1回の鍵階層図で見たとおり、ウォレットファイルを失えば、データは永久に復号できません（マスター鍵はその中にしか無いため）。そして冒頭で見たとおり、鍵を閉じる／失うだけで ORA-28365 です。だからウォレットファイルは、DBサーバとは別の場所へバックアップしておく必要があります。

ウォレットファイルを別ホストへオフサイト退避する

ウォレットファイルを、DBサーバとは別のホスト（NFSサーバ）へ転送します。 同じサーバに置いては、ホストごと失ったときに共倒れになるからです。

$ scp -p /u01/app/oracle/admin/orcl19u/wallet/tde/ewallet.p12 \
       oracle@nfs-node:/nfs_share/tde-wallet/orcl19u/      # 鍵の命綱を別ホスト(NFS)へ退避
ewallet.p12                          100% 3993     2.2MB/s   00:00

scp -p の -p はタイムスタンプを保持するオプション。ウォレットファイルの世代管理で「いつの鍵か」を追えるようにしておきます。これで、DBサーバが丸ごと失われても、鍵は別ホストに生き残ります。

バックアップから戻して、読めるか確かめる

鍵を失った状況を作り、バックアップから戻して復旧できることを確かめます。

復旧のしくみは Phase 2 で実証ずみです。ローカルの鍵を退避すると ORA-28365 で読めなくなり、正しいファイル名で戻して OPEN すれば読める。別ホスト（nfs-node）から scp で戻す場合も、戻す経路がリモートになるだけで、やることは同じです。

$ scp -p oracle@nfs-node:/nfs_share/tde-wallet/orcl19u/ewallet.p12 \
       /u01/app/oracle/admin/orcl19u/wallet/tde/      # 別ホストのバックアップから鍵を戻す
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
SQL> SELECT * FROM plain_mig;   -- 再び読めれば、バックアップが命綱として機能

DR設計で外してはいけない3点

実機検証から導かれる、鍵のDR設計の要点です。

本番化の補足: 検証では退避先を NFS 共有＋パスワード認証で代用しました。実運用では、専用の権限管理領域＋鍵認証にし、転送・保管を監査する設計にします。鍵の保管場所は、データと同じかそれ以上に守るべき対象です。

まとめ — 連載のおわりに

3回にわたって、Oracle TDE 表領域暗号化を、攻撃の前後を実際に見せる実機検証で見てきました。

• 第1回（守る）：データファイルを盗まれても strings で読めないことを before/after で証明。設計と基本構築
• 第2回（守れる範囲・守れない範囲）：暗号化済みなのに UNDO/TEMP・統計・AWR から情報漏洩する経路を実証。TDEの守備範囲を整理
• 第3回（運用）：止めずに移行できる／ウォレットファイルはオープンの瞬間だけ必要／鍵は別ホストへ世代バックアップ

本記事で実証した、鍵の管理の核心：

• 移行：オンライン暗号化で止めずに平文→AES256へ（ディスク上の平文が6件→0件に）。ただし「新ファイルを作って差し替える」しくみ＝空き領域が要る・退役ディスクは別途セキュア消去
• ウォレットファイルはいつ必要か：開く/起動の瞬間だけ必要。稼働中はメモリ（SGA）で動く。開き直すには必須
• DR：鍵を失えば永久喪失。別ホストへ・更新の都度・RMANとセットでバックアップする

TDEは「暗号化して終わり」の機能ではありません。鍵を生かし続ける運用があって初めて、「盗まれても読めない」と「自分はちゃんと読める」が両立します。この連載が、その運用設計の土台になれば幸いです。

連載①②③で、TDEの「守る・守らない・運用」を一通り実機で確かめました。続編の第4回では、SYSTEM・SYSAUX・UNDO・TEMPまで暗号化を広げ、統計・AWR経由の平文漏洩を防ぐbefore/afterを実測しています。その先は監査（標準監査・FGA）や Database Vault など、TDEと組み合わせるアクセス制御（誰に何を見せるか）へ進みます。