はじめに

Oracle GoldenGate (以下 GoldenGate) は、国内外で多くの導入実績を持つ、データレプリケーションのための製品です。柔軟な構成を取れることが強みで異機種・異OS間でのデータ移行や、データ連携などに用いられています。

• ※ GoldenGate の製品紹介、概要説明は、こちらのページをご覧ください。
  http://www.intellilink.co.jp/business/platform/oracle_goldengate

私は、2010年頃から数年間、GoldenGate の製品検証、本番環境へのインプリメンテーション、GoldenGate を利用したデータベース移行に携わっていました。Oracle 社が GoldenGate Software 社を買収したのは2009年頃です。製品としては買収直後で情報が少なかったこともあり、インプリメント時にはいろいろと苦労することが多く、検証環境でトラブルシューティングや機能検証に明け暮れていました。

で、調べた以上、その内容を誰かに知ってほしいと思い、自分の部署向けに検証結果をまとめて情報共有していたのですが、そのときのタイトルが、「ゴー！ゴー！GoldenGate」でした（コラムのタイトルはここから来ています）。

現在、セキュリティコンサルティング業務に従事しています。いまさらながら、GoldenGate の機能を確認したので、紹介してみよう、というのが本コラムの趣旨になります。すぐに役に立つ、ということは少ないかも知れませんが、読んでいただければ幸いです。

GoldenGate は、更新差分のデータを通信することでデータの同期を行います。取得した変更レコードをディスク上の証跡ファイル（Trail File）と呼ばれる一覧のファイルに格納します。証跡ファイルは（暗号化しないデフォルトのままだと）、バイナリデータを含むものの、ファイルシステム上で、view, cat などのOSコマンドを使って、わりと簡単にデータは確認できます^（※1）。

OSコマンドで証跡ファイルの中身が読めるなら、それを転送している通信データだって、そりゃ見えるだろう、と思っていたのですが、「レプリケーション製品だし、もしかしたら、通信時は読めないようになっているのかも…」とも考えられるし、ちょっとモヤモヤ…。

というわけで、実際に「通信しているデータの中身が見えるのか」、そして、「本当に暗号化されているのか」を確かめてみました。

何を暗号化するのか

GoldenGate の一般的な構成を図１に示します。ソース側がGoldenGate のデータ更新元、ターゲット側が更新データの適用先となります。マスターとレプリカ、という言い方もしますね。

図1. GoldenGate の一般的な構成

GoldenGate で発生するデータでは、以下の２つが、暗号化の対象となります。

上記の暗号化の対象について、説明します。

(1) ディスクに保存される証跡ファイルのデータ

GoldenGate は、取得した変更レコードをディスク上の証跡ファイル（Trail File）と呼ばれるファイルに格納します。一般的には、ソース・システム、ターゲット・システムにそれぞれ配置されます。ソース側をLocal Trail, ターゲット側にある証跡ファイルを Remote Trail と呼ぶことが有ります。

(2) TCP/IPネットワークを通じて送信されるデータ

証跡ファイルを、ソース・システムから、ターゲット・システムに送る際のデータを指します。データの内容は、(1)と同一になります。
ソース・システムで更新が発生するたび、Local Trail（ソース側の証跡ファイル）に追記され、Data Pumpと呼ばれるプロセス^（※2）により、差分データがターゲット・システムへ送られます。

本コラムでは、（2）の通信の暗号化に関して確認していきます。
もちろん、証跡ファイル自体を暗号化する方法もありますので、そちらについては以下の製品ドキュメントを参照してください。

• Oracle GoldenGate 12c Release 2 (12.2)のオンライン・ドキュメン ト・ライブラリ
  https://docs.oracle.com/cd/E74358_01/gg-winux/index.html

暗号化前のデータを見てみよう

ではでは、実際に暗号化前のデータを見てみましょう。今回は図2 の環境で検証してみます。GoldenGate のコンポーネントの構成は、図１と同様です。ソース側にCaptureプロセス, Data Pumpプロセス を用意し、ターゲット側にReplicatプロセス を用意します。なお、お手軽な仮想環境で作っています。以降、本コラムで紹介する機能や設定は、実際の環境においても同等に動作するものだと考えられますが、動作がサポートされる構成での検証ではありませんので、その点はご注意下さい。

図2. 検証環境の構成

では、ソース側のデータベースサーバにアクセスし、試験用テーブル（TEST_TABLE）にデータを入れてみます。

SQL> desc test_table
名前 		NULL?		型
----------------------------------------- -------- ----------------------------
C1 		NUMBER	
C2 		VARCHAR2(10)

SQL> insert into test_table values ( 1, 'Not Secure' );
1行が作成されました。

SQL> commit; 

コミットが完了しました。

これが差分データとして、GoldenGate では、前述したLocal Trail（ソース側の証跡ファイル）に格納されています。そして、証跡ファイルの在り処なのですが、デフォルトでは、GoldenGate のインストールディレクトリ配下にある「dirdat」というサブディレクトリに格納されます^（※3）。
証跡ファイルのファイル名は、「任意の２文字」＋「シークエンス番号」で構成されています。ここでは、証跡ファイルの名称の任意の文字を「aa」としています。その内容を cat コマンドでみてみましょう。

[oracle@gg1 ~] $ export OGG_HOME=/u01/app/oracle/product/12.1.0/gghome_1  #インストールディレクトリ
[oracle@gg1 ~] $ cd $OGG_HOME/dirdat # インストールディレクトリ配下のdirdatディレクトリに移動
[oracle@gg1 dirdat]$ ls　# 今回の対象の証跡ファイルは、「aa000000001」
aa000000000 aa000000001　
[oracle@gg1 dirdat]$ cat aa000000001 | strings # cat コマンドの結果をstrings コマンドで表示可能な文字だけにする
>uri:gg1:intellilink::u01:app:oracle:product:12.1.0:gghome_1:E16
./dirdat/aa0000000017
1681704
,............................................
Linux1
gg1.intellilink2
4.1.12-61.1.18.el7uek.x86_643
"#2 SMP Fri Nov 4 15:48:30 PDT 20164
x86_642
GGDB12
ggdb13
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production PL/SQL Release 12.1.0.2.0 - Production
CORE	12.1.0.2.0	Production
TNS for Linux: Version 12.1.0.2.0 - Production NLSRTL Version 12.1.0.2.0 - Production
12.1.0.2.09
GMT3
?Version 12.2.0.1.1 OGGCORE_12.2.0.1.0_PLATFORMS_151211.1401_FBO4
GGDB1Z
TEST.TEST_TABLE
AAAWdIAAGAAAADbAAA
16842646
7.6.1293Z
Not SecureT
AAAWdIAAGAAAADbAAB
16846096
5.4.1577Z

文字化けしているものの、データ領域に関しては、部分的に内容を確認することが出来ます。表示された情報から、対象のテーブル名「TEST_TABLE」や、挿入したデータ、「Not Secure」を確認することができます。
次にネットワーク上を通る、GoldenGate のデータを、パケットキャプチャ分析ツールを使い、確認してみましょう。同じネットワーク上に存在する Windows 仮想マシンから、GoldenGate の通信データを覗いてみました^(※4)。ここでは、WireShark（http://wireshark.org）を利用しています。

図3. デフォルトの通信データをキャプチャした結果

先ほど、証跡ファイルを確認してわかったように、デフォルトではデータ部分は暗号化されておらず、そのままデータ送信するため、当然ながら、通信データも平文であることを確認できました。

今回のまとめ

証跡ファイルそのものを暗号化していないデフォルト状態のままでは、GoldenGate のデータは丸見えの状態であることが確認できました。あぶないですね。
次回のコラムでは、暗号化オプションを使って、通信の暗号化が行えることを確認します。

補足

（※1）データは確認できます

もちろん、アクセス権限を適切に設定していれば、誰でも見られるわけではありません。oracle ユーザーや root 等の特権ユーザーを奪われた場合、今回のコラムで確認したように OSコマンドで、データが丸見えになります。

（※2）Data Pumpと呼ばれるプロセス

GoldenGate で登場する Data Pump プロセスと、Oracle Database のユーティリティーである Data Pump Export/Import とは別物です。ややこしいですね。
ちなみに、GoldenGate の主要プロセスグループである、Captureプロセス, Data Pumpプロセス, Replicatプロセス の名称は、それぞれ最大８文字まで指定することができます。

（※3）dirdat

GoldenGate のインストールディレクトリには、dirprm, dirwlt といった、「dirxxx」 という命名規則のサブディレクトリが自動的に作成されます。それぞれ、パラメーター・ファイルや暗号鍵を格納する等、GoldenGate で利用するファイルの格納先として使われます。この中でも、dirdat は、証跡ファイルを格納する場所です。
ちなみに、証跡ファイルを格納する場所は dirdat 以外にも指定する場合があります。例えば、GoldenGate のインストールディレクトリの容量が少ない場合が挙げられます。GoldenGate は差分データしか扱わないとはいえ、更新量が多いシステムではその増加容量がインストールディレクトリの容量を枯渇させる可能性があります。このような場合は、証跡ファイルの格納先を別途、容量が潤沢なディレクトリを指定したほうが良いでしょう。
また、ソース・システムが Real Application Clusters （RAC）構成の場合にも注意が必要です。ソース用の証跡ファイルを各ノードからアクセスする必要があるからです。このような場合、証跡ファイルの格納先として、インストールディレクトリではなく、共有ディスク上を指定する必要があります。

（※4）通信データを覗いてみました

今回、Oracle VM Virtualbox という仮想化ソフトウェアを使い、Linux マシンを2台、Windows マシンを1台、構築しています。Linux マシン2台に Oracle Database およびGoldenGate の環境がそれぞれ構築しました。Windows マシンには、WireShark をインストールしています。Windows マシンのネットワークアダプターのオプションを、プロミスキャスモードにすることで、データを傍受することが出来ます。

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当 チーフコンサルタント
佐藤 雄一（CISSP、Ph.D.）

以下、Oracle系資格を保有
・ORACLE MASTER Platinum Oracle Database 12c
・Oracle GoldenGate 12c Certified Implementation Specialist

• セキュリティサービス
• Oracle関連サービス