データパイプラインの強化：Oracle GoldenGateセキュリティ実践ガイド

このようなシナリオを想像してください：会社の年次セキュリティ監査の際、ペネトレーションテストの報告書に赤線が引かれた重大な指摘が現れます——「ポート 7809 において平文データの送信が検出されました。」このポートはまさに、あなたの OGG Manager プロセスが稼働しているものです。さらに悪いことに、顧客の重要データを含む Trail ファイルのディレクトリが、誰でも読み取り可能な状態であることが判明します。これは単なる監査の不合格ではなく、重大なデータ漏洩リスクです

Oracle GoldenGate（OGG）はデータレプリケーション分野におけるスイスアーミーナイフであり、強力、安定、かつ高効率です。しかし、データはソースとターゲット間で平文で転送され、パスワードを含む設定ファイルも暗号化されていません。これは、データセキュリティに非常に敏感な現代において、非常に危険です。

この記事は理論的な議論ではなく、完全なOGGセキュリティ強化の実践ガイドです。この記事では、広く利用されているOGGクラシックモードに焦点を当てます。データ同期を担当するデータエンジニア、OGG運用担当者、Oracle DBA、あるいはデータパイプラインのセキュリティをレビューする必要があるコンプライアンス監査担当者であれ、この記事を読めば、すぐに実践できる完全なOGGセキュリティ強化策を手に入れることができます。

データフロー図。ソース（Extract）とターゲット（Replicat）サーバー間のネットワーク接続に鍵のアイコンがあり、SSL/TLS暗号化を象徴しています。ディスク上の証跡ファイルにも鍵のアイコンが付いています。

1. OGGセキュリティリスクの全景：脆弱性はどこ？

強化に着手する前に、まずリスクを明確に特定しなければなりません。セキュリティ設定が施されていないOGG環境には、主に以下のようないくつかの脆弱な攻撃対象領域が存在します。

ネットワーク転送リスク：これが最も中心的なリスクです。ソースのExtract/PumpからターゲットのCollectorプロセスへのデータフロー（つまりTrailファイルの内容）は、デフォルトで平文です。ネットワークスイッチにアクセス権を持つ者や、スニッフィングツールを使用する者なら誰でも、取引記録や顧客情報などの業務データを容易に傍受し、再構築できてしまいます。
静的データ（Data-at-Rest）のリスク：OGGはディスク上に2種類の重要なデータを永続化します。Trailファイルとパスワードファイルです。
- Trailファイル：暗号化されていないTrailファイルは、サーバーのファイルシステムが侵害された場合、攻撃者はその中のすべての変更データを直接読み取ることができます。
- パスワードストレージ：古いENCRYPT PASSWORDコマンドは非常に脆弱で、暗号化されたパスワードは容易に復号できてしまいます。現代のOGGではCredential Storeの使用が推奨されていますが、これを設定しないと、同様に保護されていないWalletファイルに依存することになります。
IDと権限のリスク：便宜のため、多くの実装者がOGGのデータベースユーザーにDBA権限を付与してしまいます。これは巨大なセキュリティホールです。万が一OGGプロセス自体が悪用された場合、攻撃者はデータベースの最高制御権を手に入れることになります。
鍵管理のリスク：暗号化の根幹は鍵です。Trailファイルやパスワードの暗号化に使用されるMASTERKEYが適切に保管されていない場合（例えば、スクリプトにハードコーディングされたり、安全でない場所に保存されたりしている場合）、すべての暗号化対策は無意味になります。

これらのリスクポイントを明確にすれば、一つずつ防御線を築くことができます。

2. 動的防御 - 転送チャネルのSSL/TLS暗号化を有効にする

OGGのTCP/IP通信チャネルにSSL/TLSを追加することは、ネットワーク盗聴を防ぐための第一かつ最も重要な防御線です。これにより、ExtractからReplicatまでのすべてのデータが暗号化され、中間者による解読が容易でなくなります。

中心的な設定方針：SSL/TLS接続はクライアント（Extract/Pump）から開始され、サーバー（Manager）が応答します。したがって、Pump側でアウトバウンドの暗号化オプションを設定し、Manager側で暗号化された接続を受け入れるための自身のID情報（Wallet）を設定する必要があります。

操作手順（OGG 19c/21cの場合）:

鍵と証明書の準備：ソースとターゲットのサーバー上で、それぞれ信頼されたCA（認証局）によって署名された証明書を準備するか、テスト用にorapki/opensslを使用して自己署名証明書を生成します。サーバー証明書、秘密鍵、およびCAルート証明書を各サーバーのOracle Walletにインポートし、必ず自動ログインWallet（cwallet.sso）を生成してください。
ターゲット側のManagerプロセスパラメータの設定： ターゲット側のManagerのパラメータファイル（mgr.prm）で、Walletの場所を指定するだけです。Managerプロセスは起動時にこのWalletを自身のID情報として自動的にロードし、暗号化接続リクエストに応答します。

-- MGR.PRM on Target Server
PORT 7809
ACCESSRULE, PROG *, IPADDR 192.168.1.100, ALLOW

ACCESSRULE：これはネットワークレベルのアクセス制御であり、Managerに接続できるクライアントのIPアドレスを制限するために使用します。セキュリティを強化するための第一の関門です。
ソース側のExtract/Pumpプロセスパラメータの設定: ソース側のデータ送信プロセス（通常はPump）のパラメータファイルで、RMTHOSTOPTIONSを使用して暗号化接続を開始します。

-- PUMP.PRM on Source Server
RMTHOST target.example.com, MGRPORT 7809, TCPIP_PROCESSNAME C1
-- RMTHOSTOPTIONSはクライアントが暗号化接続を開始するための重要なパラメータです
RMTHOSTOPTIONS ( \
        KEYSTORE <path_to_your_source_wallet_directory> , \
        -- この別名の作成方法は「パスワードストレージの暗号化」の章で詳しく説明します
        KEYSTORE_PASSWORD_ALIAS pump_wallet_pwd , \
        ENCRYPTIONLEVEL REQUIRED \
    )
RMTTRAIL /u01/app/ogg/dirdat/rt

RMTHOST: ターゲットサーバーとポートを定義します。
RMTHOSTOPTIONS: アウトバウンド接続のセキュリティオプションを指定するための複合パラメータです。
KEYSTORE: ソース証明書とターゲットのCA証明書を含むWalletディレクトリを指します。
KEYSTORE_PASSWORD_ALIAS: ソースのCredential StoreでWalletのパスワードに設定した別名を指します。
- ENCRYPTIONLEVEL REQUIRED: これが暗号化を強制する核心部分です。このプロセスがリモートホストに暗号化方式で接続しなければならないことを宣言し、さもなければ失敗して終了します。

上記の設定を完了し、ManagerとPumpプロセスを再起動すれば、OGGのデータパイプラインはSSL/TLSによって保護された状態になります。

3. 静的防御 - ディスク上の機密データを暗号化する

ネットワーク転送が保護されたら、次のステップはディスク上に保存されたデータの安全性を確保することです。

1. Trailファイルの暗号化

OGGでは、MASTERKEYを使用してディスクに書き込まれるTrailファイルを透過的に暗号化できます。Extract/Pumpが書き込む際に自動的に暗号化され、Replicatが読み取る際に自動的に復号されます。

設定方法：ExtractまたはPumpのパラメータファイルにENCRYPTTRAILパラメータを追加します。

-- PUMP.PRM on Source Server
ENCRYPTTRAIL AES256, KEYNAME mymasterkey1
RMTTRAIL /u01/app/ogg/dirdat/rt

ENCRYPTTRAIL AES256: AES-256アルゴリズムを使用して暗号化することを指定します。これは現在推奨されている強度基準です。
- KEYNAME mymasterkey1: 暗号化に使用するMASTERKEYを指定します。これにより、鍵のローテーション管理が可能になります。

2. パスワードストレージの暗号化 (Credential Store)

OGG 12.3c以降、Credential Storeが唯一推奨される管理方法です。これにより、すべてのパスワード（データベースユーザー、Walletパスワードなど）が単一の暗号化されたファイルに一元管理されます。

GGSCIにログインし、Credential Storeを作成する: bash GGSCI> ADD CREDENTIALSTORE このコマンドは、OGGのdircrdディレクトリに自動ログインのOracle Walletを作成します。
データベースユーザーの資格証明を追加する:
```
GGSCI> ALTER CREDENTIALSTORE ADD USER ogg_user@TNS_ALIAS PASSWORD "your_db_password" ALIAS ogg_db_user
```
これで、GLOBALSファイルやDBLOGINコマンドで、平文のユーザー名とパスワードの代わりにUSERIDALIAS ogg_db_userを使用できるようになります。
データベースユーザーの資格情報を追加します:
```
GGSCI> ALTER CREDENTIALSTORE ADD USER wallet_user PASSWORD "your_wallet_password" ALIAS pump_wallet_pwd
```
これがRMTHOSTOPTIONS内のKEYSTORE_PASSWORD_ALIASパラメータが参照する別名です。ソースとターゲットの両方で、それぞれのWalletパスワードに対応する別名を作成してください。

Credential Storeを使用することで、すべての機密パスワードを脆弱なテキストベースのパラメータファイルから移動させることができます。

4. Oracle WalletとMASTERKEYの管理

すべての暗号化対策の安全性は、最終的に鍵自体の安全性に依存します。

Oracle Walletの比喩的な図。安全な保管庫が「MASTERKEY」を保持し、それが「Trail Files」と「Password Store」に接続され、それらを保護していることを示しています。

MASTERKEYはOGGによって生成され、Oracle Wallet内に安全に保管されます。

MASTERKEYのライフサイクル管理:

初期MASTERKEYの作成: これが最初のステップです。初期設定時にMASTERKEYを作成しなければなりません。

GGSCI> CREATE WALLET
GGSCI> CREATE MASTERKEY

OGG 19c以降では、CREATE MASTERKEYは（Walletが存在しない場合）自動的にWalletを作成します。このコマンドはデフォルトのMASTERKEYを作成します。

鍵のローテーション（新バージョンのMASTERKEYの追加）: セキュリティのベストプラクティスでは、定期的な鍵のローテーションが求められます。OGGでは、これは既存の鍵を「更新」するのではなく、ADD MASTERKEYコマンドを使用して、完全に新しい、独立した名前を持つMASTERKEYを新バージョンとして追加することによって行います。追加されると、この新しい鍵がデフォルトのアクティブな鍵となり、それ以降に生成されるすべてのデータの暗号化に使用されます。

-- "my_new_key_q3_2025" という名前の新しいMASTERKEYを追加する
GGSCI> ADD MASTERKEY my_new_key_q3_2025```
古い`MASTERKEY`（例えば、初期のデフォルトキーや他の名前付きキー）はWallet内に完全に保持されます。OGGは十分に賢く、暗号化されたTrailファイルを読み取る際に、そのファイルがどのバージョンの鍵で暗号化されたかを自動的に識別し、対応する鍵を使用して復号します。これにより、鍵のローテーションプロセスが履歴データの読み取りに影響を与えることなく、スムーズな移行が実現します。

* **Walletのバックアップ**:
**これが最も重要な点です**。`cwallet.sso`ファイルにはあなたの`MASTERKEY`が含まれています。**もしこのファイルが紛失または破損し、バックアップがない場合、それによって暗号化されたすべてのTrailファイルは永久に読み取れなくなります**。データベースのアーカイブログと同様に、`cwallet.sso`ファイルを標準のバックアップ・リカバリプロセスに組み込んでください。

### 5. 最小権限の原則 - きめ細かなアクセス制御

クラシックモードでは、手動のSQL `GRANT`文を使用して、OGGプロセスが必要とする最小限のデータベース権限セットを設定します。`DBA`ロールの付与は絶対に禁止されるべき危険な操作です。

* **Classic Extract（キャプチャ）プロセスについて**:
Extractは、データベースに接続し、REDOログを読み取り（Logminer経由）、一貫性のあるデータを取得するためにフラッシュバッククエリを実行する権限が必要です。

```sql
-- Classic Extractの最小権限の例
CREATE USER OGG_EXT IDENTIFIED BY <password>;
GRANT CONNECT, RESOURCE TO OGG_EXT;
GRANT SELECT ANY TABLE TO OGG_EXT;
GRANT FLASHBACK ANY TABLE TO OGG_EXT;
GRANT EXECUTE ON DBMS_LOGMNR TO OGG_EXT;
GRANT SELECT ON V_$DATABASE TO OGG_EXT;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO OGG_EXT;
ALTER USER OGG_EXT QUOTA UNLIMITED ON <users_tablespace>;

注意: SELECT ANY TABLE権限は強力です。可能な限り、これをレプリケートする必要のあるすべてのテーブルに対する正確なSELECT ON schema.table権限に置き換えるべきです。

Classic Replicat（適用）プロセスについて: Replicatは、データベースに接続し、ターゲットテーブルに対してDML（INSERT/UPDATE/DELETE）操作を実行する権限が必要です。

-- Classic Replicatの最小権限の例
CREATE USER OGG_REP IDENTIFIED BY <password>;
GRANT CONNECT, RESOURCE TO OGG_REP;
-- ターゲットスキーマのすべてのテーブルに対する正確なDML権限を付与
GRANT SELECT, INSERT, UPDATE, DELETE ON TGT_SCHEMA.TABLE1 TO OGG_REP;
GRANT SELECT, INSERT, UPDATE, DELETE ON TGT_SCHEMA.TABLE2 TO OGG_REP;
-- ... すべてのターゲットテーブルに権限を付与 ...
ALTER USER OGG_REP QUOTA UNLIMITED ON <data_tablespace>;

注意: ANY権限の付与は避けてください。最小化の原則を厳格に守り、Replicatがターゲット側で操作する必要のあるテーブルの権限のみを付与してください。

Oracleは、このタスクを簡素化するためのPL/SQLスクリプトとプロシージャを提供しています。

Capture（Extract）プロセスについて: データベースに接続し、dbms_goldengate_auth.grant_admin_privilegeプロシージャを使用します。

-- Integrated Extractの場合
EXEC dbms_goldengate_auth.grant_admin_privilege(grantee => 'ogg_capture_user', privilege_type => 'capture');

このプロシージャは、CREATE SESSION、SELECT ANY TRANSACTION、DBMS_LOGMNRに対するEXECUTEなど、Extractとして必要なすべての権限をユーザーに付与します。

Apply（Replicat）プロセスについて: 同様に、grant_admin_privilegeを使用します。

EXEC dbms_goldengate_auth.grant_admin_privilege(grantee => 'ogg_apply_user', privilege_type => 'apply');

これにより、ReplicatユーザーはDMLおよびDDL操作の実行、チェックポイントテーブルの管理などに必要な権限が付与されます。

Oracleが提供するAPIを使用することで、権限が過不足なく適切であることを保証し、機能要件とセキュリティ監査の最小権限の原則の両方を満たすことができます。

まとめ

セキュリティは一度きりのプロジェクトではなく、継続的な改善のプロセスです。あなたの設定を迅速に自己チェックしたり、新しい環境を展開する際に確認したりするのに便利な、簡潔なチェックリストを以下に示します。

セキュリティ領域	設定項目	推奨設定/ステータス	私の環境ステータス (自己記入)
	Pump/Extractアウトバウンド接続	`RMTHOSTOPTIONS`で`ENCRYPTIONLEVEL REQUIRED`を設定済み	`[ ]未設定 [ ]設定済み`
静的データ	Trailファイルの暗号化	`ENCRYPTTRAIL AES256`が有効	`[ ]未設定 [ ]設定済み`
	資格証明管理	Credential Storeを使用中（平文ではない）	`[ ]未使用 [ ]使用中`
鍵管理	MASTERKEY	作成済みでアクティブ	`[ ]未作成 [ ]作成済み`
	Oracle Wallet (`cwallet.sso`)	定期的なバックアッププロセスに組み込み済み	`[ ]未バックアップ [ ]バックアップ済み`
	鍵ローテーションポリシー	定義済み（例：12ヶ月ごとにローテーション）	`[ ]未定義 [ ]定義済み`
アクセス制御	DBユーザー権限（クラシックモード）	最小権限のSQL GRANTを使用（DBAではない）	`[ ]DBA権限 [ ]最小権限`

あなたのOracle GoldenGate環境を強化することは、企業の核となるデータ資産を保護する責任において不可欠な部分です。今日行う努力は、明日起こりうるデータセキュリティ災害を防ぐためのものです。この修正・検証済みのガイドが、明確なロードマップを提供できれば幸いです。