現在地

ゴー!ゴー!GoldenGate ~GoldenGate のレプリケーションは暗号化されているのか?(後編)

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

データ暗号化方式

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

【参照】Oracle GoldenGateのセキュリティの構成

Oracle® Fusion Middleware Oracle GoldenGateの管理for Windows and UNIX 12c (12.2.0.1) E70111-04
https://docs.oracle.com/cd/E74358_01/gg-winux/GWUAD/GUID-E14F094A-A46B-4D31-857F-3916C0090875.htm#GUID-E14F094A-A46B-4D31-857F-3916C0090875

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

(1) マスター・キーとウォレット方式を使用したデータ暗号化
(2) ENCKEYS方式を使用したデータ暗号化

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

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

図4. マスター・キーとウォレット方式を使用したデータ暗号化

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

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

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

1. GGSCIでCREATE WALLETコマンドを使用して、マスター・キー・ウォレットを作成
2. GGSCIでADD MASTERKEYコマンドを使用して、マスター・キーをウォレットに追加
3. INFO MASTERKEYコマンドを発行して、追加した鍵が現在のバージョンであることを確認
4. 他のすべてのOracle GoldenGateシステムにウォレットをコピー
5. ウォレットをコピーした各システム上で、VERSIONオプションを指定してINFO MASTERKEYコマンドを発行

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

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コマンドを発行して、追加した鍵が現在のバージョンであることを確認

追加した鍵の情報を確認します。確認の際、バージョンを指定する必要があります。新規インストールの場合、バージョンは「1」です。「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システムにウォレットをコピー

今回の構成では、1対1構成ですので、鍵はソース側で作成しましたので、ソース側から、ターゲット側に送付します。まず、ウォレットの格納先の確認をします。通常、ウォレットは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. 暗号化したデータをキャプチャした結果

図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 の2つが提供されていますが、どちらを選ぶべきでしょうか。
まず、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