前回のコラムでは、通信データを確認した結果、デフォルトの状態では平文であることを確認しました。今回は、GoldenGate の暗号化設定を行い、通信の暗号化がされるかどうかを確認していきます。

データ暗号化方式

GoldenGate のセキュリティ機能の内容は、以下のマニュアルの記載を参照します（2017年8月にOracle GoldenGate 12.3 がリリースされていますが、下記では今回の検証環境のバージョンである 12.2 のマニュアルを記載します）。暗号化の手順もマニュアルに記載されています。

GoldenGate のデータ暗号化（証跡ファイル内、TCP/IP間のデータを暗号化する方法）には、以下の２つの方式が用意されています。

今回は、Oracle GoldenGate 12c 以降で提供されている、「マスター・キーとウォレット方式を使用したデータ暗号化」を行ってみましょう^{（※1）}。

「マスター・キーとウォレット方式を使用したデータ暗号化」では、証跡ファイルを暗号化する鍵を暗号化する、という鍵ラップと呼ばれるプロセスを行っています。まず、証跡ファイルを暗号化する鍵が一時的に生成されます。その証跡ファイル鍵を暗号化するための鍵をマスター・キーと呼びます。このマスター・キーを格納する場所を、ウォレットと呼びます。マスター・キーを利用する際、つまり、証跡ファイルを暗号化、復号化する際にはウォレットをオープンする必要があります。ちなみに、マスター・キーは、ランダムなビットの連続として生成され、デフォルトでは、256 bitの長さを持ちます^{（※2）}。一方、証跡ファイルを暗号化する鍵は、AES 128/196/256 bit、もしくは Blowfish のいずれかから選択します^{（※3）}。以降、設定手順の中で、パラメータ・ファイルに暗号の種類や、鍵長を指定する箇所がありますが、マスター・キーではなく、証跡ファイルを暗号化する鍵の設定を指しています。なお、ネットワーク間のデータを暗号化する場合は、マスター・キーに基づいた暗号関数を使用してセッション鍵を生成し、このセッション鍵により暗号化されます。

図4. マスター・キーとウォレット方式を使用したデータ暗号化
※「Oracle GoldenGateの導入Tips（GG12.1.2.0.1）」（Oracle Technology Network）をもとに作成

ウォレットの作成とマスター・キーの追加

ソース・システムでウォレットを作成し、それを GoldenGate 環境内の他のシステムにコピーする手順は以下です。

それでは、上記手順に従って、実際に試してみましょう。

1. GGSCIでCREATE WALLETコマンドを使用して、マスター・キー・ウォレットを作成

まず、ソース側のデータベースサーバにログインし、GGSCI^{（※4）}からマスター・キー・ウォレットを作成します。

[oracle@gg1 gghome_1]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 12.2.0.1.1 OGGCORE_12.2.0.1.0_PLATFORMS_151211.1401_FBO
Linux, x64, 64bit (optimized), Oracle 12c on Dec 12 2015 02:56:48
Operating system character set identified as UTF-8.

Copyright (C) 1995, 2015, Oracle and/or its affiliates. All rights reserved.



GGSCI (gg1.intellilink) 1> create wallet

Created wallet at location 'dirwlt'.

Opened wallet at location 'dirwlt'.

2. GGSCIでADD MASTERKEYコマンドを使用して、マスター・キーをウォレットに追加

続いて、マスター・キーを作成します。GGSCI で、ADD MASTERKEY コマンドを発行します。

GGSCI (gg1.intellilink) 2> add masterkey

Master key 'OGG_DEFAULT_MASTERKEY' added to wallet at location 'dirwlt'.

GGSCI (gg1.intellilink) 3> info masterkey
Masterkey Name:                 OGG_DEFAULT_MASTERKEY
Creation Date:                  Fri Jun 16 14:16:52 2017

Version:        Creation Date:                  Status:
1               Fri Jun 16 14:16:52 2017        Current

3. INFO MASTERKEYコマンドを発行して、追加した鍵が現在のバージョンであることを確認

追加した鍵の情報を確認します。確認の際、バージョンを指定する必要があります。新規インストールの場合、バージョンは「１」です。「Status」 が「Current」 になっていること、暗号化鍵のハッシュ値（項目としては、「Key Hash (SHA1)」が該当します。）を確認しておきます。

GGSCI (gg1.intellilink) 5> info masterkey version 1
Masterkey Name:                 OGG_DEFAULT_MASTERKEY
Creation Date:                  Fri Jun 16 14:16:52 2017
Version:                        1
Renew Date:                     Fri Jun 16 14:16:52 2017
Status:                         Current
Key Hash (SHA1):                0x536E3A7EA59EB13440EEE539A9FFD4A8E596DDFD

4. 他のすべてのOracle GoldenGateシステムにウォレットをコピー

今回の構成では、１対１構成ですので、鍵はソース側で作成しましたので、ソース側から、ターゲット側に送付します。まず、ウォレットの格納先の確認をします。通常、ウォレットはGoldenGateのインストールディレクトリ内にある dirwlt というサブディレクトリに格納されています。

GGSCI (gg1.intellilink) 6> exit
[oracle@gg1 gghome_1]$ cd dirwlt/
[oracle@gg1 dirwlt]$ ls
cwallet.sso
[oracle@gg1 dirwlt]$ ls -ltr
合計 4
-rw-r-----. 1 oracle oinstall 685  6月 16 14:16 cwallet.sso

cwallet.sso が、作成されたウォレットであり、マスター・キーが格納されています。これをターゲット側に格納します。今回の検証では、 scp コマンドでターゲット側に転送します。転送先には、ソース側と同様に、dirwltを指定します。本検証の構成では、GoldenGate のインストールディレクトリは、ソース側もターゲット側も同じ構成としています。

[oracle@gg1 dirwlt]$ scp cwallet.sso oracle@gg2:/`pwd`
oracle@gg2's password: 
cwallet.sso                                   100%  685     0.7KB/s   00:00    
[oracle@gg1 dirwlt]$ 
（ターゲット側にログイン）
[oracle@gg2 gghome_1]$ ls dirwlt/
cwallet.sso

ターゲット側にウォレットが転送されていることを確認できました。

5. ウォレットをコピーした各システム上で、VERSIONオプションを指定してINFO MASTERKEYコマンドを発行

それでは、転送した鍵が問題ないかどうか、ターゲット側で INFO MASTERKEY コマンドを実行してみましょう。VERSION には記録しておいたバージョン番号を指定します（今回は新規インストールなので「1」を指定します）。各ウォレットで、「Status」 が「Current」 になっていることを確認し、暗号化鍵のハッシュ値を記録しておいたコピー元の値と比較します。ソース側、ターゲット側のウォレットで、同じ鍵バージョンとハッシュ値が表示される必要があります。

[oracle@gg2 gghome_1]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 12.2.0.1.1 OGGCORE_12.2.0.1.0_PLATFORMS_151211.1401_FBO
Linux, x64, 64bit (optimized), Oracle 12c on Dec 12 2015 02:56:48
Operating system character set identified as UTF-8.

Copyright (C) 1995, 2015, Oracle and/or its affiliates. All rights reserved.



GGSCI (gg2.intellilink) 1> info masterkey version 1

ERROR: Must perform OPEN WALLET command first.

おっとと。ウォレットの説明の際に記載しましたが、利用する前にはオープンする必要がありました。まずは、ウォレットをオープンしましょう。

GGSCI (gg2.intellilink) 2> open wallet 

Opened wallet at location 'dirwlt'.

GGSCI (gg2.intellilink) 3> 

GGSCI (gg2.intellilink) 3> info masterkey version 1
Masterkey Name:                 OGG_DEFAULT_MASTERKEY
Creation Date:                  Fri Jun 16 14:16:52 2017
Version:                        1
Renew Date:                     Fri Jun 16 14:16:52 2017
Status:                         Current
Key Hash (SHA1):                0x536E3A7EA59EB13440EEE539A9FFD4A8E596DDFD

ハッシュ値が一致したことを確認できました。転送は問題なかったようです。

さて、次はパラメータの変更です。TCP/IP間のデータを暗号化する場合、Data Pumpプロセスのパラメータ・ファイルで、RMTHOSTOPTIONSパラメータのENCRYPTオプションを使用します。構文は次のとおりです。

RMTHOSTOPTIONS ENCRYPT {AES128 | AES192 | AES256 | BLOWFISH}

前述したように、利用する暗号化アルゴリズムを選択する必要があります。本検証では、AES128 を利用します。

パラメータ・ファイルでの暗号化パラメータの指定

では、変更前に現在のパラメータを見てみましょう。GGSCI 上から view コマンドを使って見てみます。今回、Data Pump プロセスの名称は、「D1」としています^{（※5）}。

GGSCI (gg1.intellilink) 2> view param d1

EXTRACT D1
PASSTHRU
RMTHOST 192.168.56.102, MGRPORT 7809
RMTTRAIL ./dirdat/aa
TABLE test.*;

それでは、暗号化オプションを付けてみましょう。GGSCI 上から、edit コマンドを発行し、パラメータ・ファイルを編集します。パラメータの編集結果を GGSCI上より、 view コマンドで確認します。

GGSCI (gg1.intellilink) 3> edit param d1
（編集します）
GGSCI (gg1.intellilink) 11> view param d1

EXTRACT D1
PASSTHRU
RMTHOST 192.168.56.102, MGRPORT 7809
RMTHOSTOPTIONS ENCRYPT AES128
RMTTRAIL ./dirdat/aa
TABLE test.*;

このあと、パラメータを反映させるため、Data Pump プロセスを再起動する必要があります。再起動が終われば、準備は完了です。まずは停止してみましょう。

GGSCI (gg1.intellilink) 38> stop d1
Sending STOP request to EXTRACT D1 ...
Request processed.

GGSCI (gg1.intellilink) 43> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT STOPPED D1 00:00:00 00:00:02
EXTRACT RUNNING E1 00:00:00 00:00:04

INFO ALL コマンドで、各プロセスのステータスを確認できます。Data Pump プロセスである「D1」が STOPPED となり、停止したこと確認出来ました。続いて、起動してみましょう。

GGSCI (gg1.intellilink) 49> start d1
Sending START request to MANAGER ...
EXTRACT D1 starting

GGSCI (gg1.intellilink) 50> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING D1 00:00:00 00:00:41
EXTRACT RUNNING E1 00:00:00 00:00:02

Data Pump プロセスである「D1」が RUNNING となり、起動したこと確認出来ました。もし、RUNNING とならない場合、編集したパラメータ・ファイルに不備があったと考えられますので、スペルミスなどがないか、確認して下さい。

暗号化の確認

それでは、通信データは暗号化されるのか、確認してみましょう。ソース側にデータを挿入してみます。

SQL> insert into test_Table values ( 5, 'Secure' ); 

1行が作成されました。

SQL> commit;

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

さて、データは暗号化されているでしょうか。キャプチャしたデータを見てみましょう。

図5. 暗号化したデータをキャプチャした結果

図5 において、青色で網掛けした部分がデータ部分です。前回、確認した際と異なり、読み取れるデーはなく、挿入したデータ「Secure」があるかどうかは、判別できないようになりました。 ということで、ENCRYPT オプションを入れることにより、GoldenGate で通信しているデータが、無事に暗号化されていることがわかりました。設定としては、意外と簡単ですね。

今回のまとめ

紹介したように、いくつかの簡単な設定手順で、GoldenGate の通信暗号化ができ、キャプチャした結果でも暗号化されていることが確認できました。このように、GoldenGate 間の通信では、GoldenGate 側で暗号化の設定を入れる必要があります。一方、当然ですが、Oracle Database において、クライアントとサーバ間のネットワークを移動するデータを暗号化するには、Oracle Database 側で設定します^{（※5）}。2016年に「政府機関の情報セキュリティ対策のための統一基準（通称、政府統一基準）」が更新され、「7.2.4 データベース」の項と、具体的なデータベースのセキュリティ対策に言及した内容が新規に追加されました。その中には情報漏えいの防止を目的として、「暗号化」も対策として含まれています。攻撃は常に弱いところから狙われます。そのため、データベース側の設定だけでなく、GoldenGate のようなデータベースの連携機能部分も忘れずに暗号化の設定を入れることで、データベース全体のセキュリティを確保する必要があるかと思います。

補足

（※1）「マスター・キーとウォレット方式を使用したデータ暗号化」を行ってみましょう

「マスター・キーとウォレット方式を使用したデータ暗号化」の場合、本文で紹介したように、証跡ファイルを暗号化するための鍵は毎回変わります。一方、「ENCKEYS方式を使用したデータ暗号化」の場合、GoldenGate の管理者が、GoldenGate で提供されている keygen コマンドを利用して作成された鍵を利用し、その暗号化するための鍵をパラメータ内で指定します。つまり、鍵を再作成し、パラメータを変更しない限り、同じ鍵を使って暗号化することになります。そのため、通信を盗聴された場合、「マスター・キーとウォレット方式を使用したデータ暗号化」は毎回、その内容を再度解読する手間がかかりますが、「ENCKEYS方式を使用したデータ暗号化」では、一度解読が済んでしまえば、同じ鍵を使って、全ての通信が解読される恐れがあります。

（※2）マスター・キーは、ランダムなビットの連続として生成され、デフォルトでは、256 bitの長さを持ちます

マスター・キーの名称は、デフォルトでは「OGG_DEFAULT_MASTERKEY」です。検証のログからも確認できます。もしマスター・キーの名称を変更したい場合は、「masterkeyname」パラメータを利用することで変更できるようです。

（※3）いずれかから選択します

GoldenGate の暗号化では、AESとBlowfish の２つが提供されていますが、どちらを選ぶべきでしょうか。
まず、Blowfish ですが、1993年に開発された暗号であり、ライセンスフリーな暗号化方式として広く使用されています。しかし、現在は電子政府推奨暗号リスト(CRYPTREC 暗号リスト)にはBlowfish は含まれておらず、「実際に解読されるリスクがある」ものと見なされています。
一方の Advanced Encryption Standard(AES)は、電子政府推奨暗号リストに含まれています。そのため、選択する暗号化アルゴリズムは、基本的には AES を選択することが望ましいと考えられます。しかし、GoldenGateのマニュアルより、特定のプラットフォーム（iSeries、z/OSおよびNonStopプラットフォーム）では、AESではなく、「Blowfishを使用する必要があります」との記載が存在するため、利用の際は、サポートされるプラットフォームの確認が必要になります。
なお、今回、紹介した「マスター・キーとウォレット方式を使用したデータ暗号化」は、残念ながら、iSeries、z/OSおよびNonStopプラットフォームでは使用できません。そのため、iSeries、z/OSおよびNonStopプラットフォームでの暗号化機能を利用する場合は、自動的に、「ENCKEYS方式を使用したデータ暗号化」かつ「Blowfish」という方式を選ぶことになります。GoldenGate の暗号化機能をご利用の際は、サポートされるプラットフォームをご確認ください。

（※4）GGSCI

Oracle GoldenGateソフトウェア・コマンド・インタフェースの略。その名の通り、GGSIは、GoldenGateのコマンド・インタフェースであり、ユーザは GGSCI を通して、コマンドを実行し、GoldenGate を操作します。

（※5）Oracle Database 側で設定します

ちなみにOracle Database の11gリリース1 以前は、Oracle Database の通信経路の暗号化は、Oracle Database Enterprise Edition に加え、Advanced Security Optionが必要でしたが、Oracle Database の11gリリース2 以降では、エディションに関係なく利用できるようになりました。Oracle Database をご利用の際は、エディション、オプションの有無にかかわらず、通信の暗号化は設定が可能ですので、基本的には設定しておくべき内容と言えるでしょう。

Writer Profile

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

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

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