4 ネットワーク
Oracle GoldenGateのネットワークを保護する方法を学習します。
この章では、ネットワーク・アクセス制御やネットワーク接続アダプタなどのエンドポイント保護と、リバース・プロキシを構成して使用するステップについて説明します。
トピック:
- ネットワーク・アクセス制御
ネットワーク接続のMA構成は配列またはネットワーク・アクセス制御リスト(ACL)の形式を使用します。 - ネットワーク接続アダプタ
ネットワーク接続構成を指定する方法について学習します。 - Oracle GoldenGate MicroservicesにアクセスするためのNGINXを使用したリバース・プロキシの構成
- ネットワーク通信
MAサーバーは、リクエストがサーバーに送信されたときにクライアントに送信されるすべてのレスポンス・メッセージの発信元です。
親トピック: マイクロサービス・アーキテクチャの保護
4.1 ネットワーク・アクセス制御
ネットワーク接続のMA構成は配列またはネットワーク・アクセス制御リスト(ACL)の形式を使用します。
構成可能なACLはすべて、ACL仕様の配列として表されます。JSON構成では、この配列は次の形式になります。
aclArray := '[' <aclSpec> [, <aclSpec>] ']'
特定の側からのアクセスが除外されたり、特定の側からのアクセスが許可される場合があります。Oracle GoldenGateでは、「Application」ネットワーク設定を調整して、アクセス・ポイントのブラック・リストまたはホワイト・リストを作成できます。同様に、特定のネットワーク・アダプタのみで配布パスを機能させる必要がある場合があります。これはOracle GoldenGateで実現可能です。
各ACL仕様は、少なくとも、ACL仕様が指定アドレスからのクライアント接続を許可するか拒否するかを示す許可文で構成されます。ACL仕様は順番に処理され、指定アドレスが適格と認定され次第終了します。指定アドレスが適格と認定されない場合、プロセスは次のACL仕様を続けます。接続を要求しているクライアントのアドレスが適格と認定されると、ACL権限は接続が「許可」または「拒否」のいずれであるかを決定します。ACLの指定内容によって接続をリクエストしているクライアントのアドレスが適格と判断された場合は、デフォルトの解決方法の「許可」が仮定され、クライアントは接続を許可されます。構成内のACLでは、次の構文形式が使用されます。
ipACL := '[' aclSpec [, aclSpec] ']'
aclSpec := "permission" : [ "deny" | "allow" ] [, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ]
RFC 4291で説明されているように、ipACLはIPv4アドレス、ipv6アドレス、IPv4マップ済アドレスを使用できます。
インバウンド接続リクエストは、ネットワーク・インタフェース経由で受信された後に一様に処理されます。ネットワーク・インタフェースの構成がアドレッシングの形式を決定します。たとえば、IPv6インタフェースに表示されるアドレスがIPv6アドレスとして表示されます。IPv6構成でIPv4マッピングが指定されている場合、IPv4クライアントのアドレスはIPv6アドレス空間にマップされます。IPv4インタフェースに表示されるアドレスは、マップされていないIPv4アドレスとして表示されます。ACLの適格認定はアドレスの適格認定に焦点をあてており、ホスト環境内のすべてのアダプタは一意のアドレスを持っているため、追加のインタフェース情報は必要ありません。
ネットワーク・インタフェースのホットフェイルオーバーをサポートするホストの場合、アダプタのMACアドレスへのネットワークIPアドレスのフェイルオーバーおよび再割当はアプリケーションに対して透過的です。
例4-1 例
192.0.2.254から発生したクライアント接続を拒否します。
"ipACL" : [ { "permission" : "deny", "address" : "192.0.2.254" } ]
明示的にすべてのクライアント接続を許可します。最初のACPはデフォルトですべてのアドレスを適格と認定します。2番目のACLは処理されません。
"ipACL" : [ { "permission" : "allow" },
{ "permission" : "deny", "address" : "192.0.2.254" } ]
127.0.0.1からのクライアント接続を許可しますが、IPv6アドレッシング用に構成されたインタフェースに表示される192.0.2.254からの接続を拒否します。
"ipACL" : [ { "permission" : "allow", "address" : "127.0.0.1" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
例4-2 例
"ipACL" : [ { "permission" : "allow", "address" : "::1" },
{ "permission" : "allow", "address" : "192.0.2.254" },
{ "permission" : "allow", "address" : "2001:db8:85a3:0:0:8a2e:370:7334" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
例4-3 例
REST APIコールの使用
{
"$schema":"api:standardResponse",
"links":[
{
"href":"http://localhost:11000/services/v2/deployments/Local/services/adminsrvr",
"mediaType":"application/json",
"rel":"canonical"
},
{
"href":"http://localhost:11000/services/v2/deployments/Local/services/adminsrvr",
"mediaType":"application/json",
"rel":"self"
}
],
"messages":[
]
}
例4-4 例
cURLの使用:
curl -s -k -u ggsca:ggsca -X GET https://abc.us.oracle.com:9100/services/v2/deployments/depl_01/services/adminsrvr | json_reformat
curl -s -k -u ggsca:ggsca -X PATCH https://abc.us.oracle.com:9100/services/v2/deployments/depl_01/services/adminsrvr' -H Cache-Control: no-cache' -d @"admin_2.json" |
json_reformat
-- 8< -- File Content from admin.json -------
{"config": {
"network": {
"ipACL": [
{
"address": "10.196.9.33 ",
"permission": "allow"
},
{
"address": "10.90.136.97",
"permission": "allow"
},
{
"address": "10.209.243.80",
"permission": "deny"
}
],
"serviceListeningPort": 9101
}
}
}
例4-5 例
oggServiceConfig
の使用:-- Check initial configuration
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca --path /network
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca --path /network/ipACL
-- Modify Service Properties
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca --path /network/ipACL --value '[{ "permission" : "allow", "address" : "10.196.9.33 " },{ "permission" : "allow", "address" : "10.90.136.97" },{ "permission" : "deny", "address" : "10.209.243.80" } ]'
Current value of "/network/ipACL" for "depl_01/adminsrvr" is <not defined>.
Setting new value and restarting service.
New value of "/network/ipACL" for "depl_01/adminsrvr" is
-- Check final configuration
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca --path /network
oggServiceConfig https://abc.us.oracle.com:9100 depl_01 adminsrvr --user ggsca --password ggsca --path /network/ipACL
[
{
"address": "10.196.9.33 ",
"permission": "allow"
},
{
"address": "10.90.136.97",
"permission": "allow"
},
{
"address": "10.209.243.80",
"permission": "deny"
}
]
ipACL := '[' aclSpec [, aclSpec] ']'
aclSpec := "permission" : [ "deny" | "allow" ]
[, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ]
親トピック: ネットワーク
4.2 ネットワーク接続アダプタ
ネットワーク接続構成を指定する方法について学習します。
ネットワーク接続アダプタとしてのNetwork Interface Use Controlは、内部実装クラスの名前です。ホストがマルチホームの環境で構成されているネットワーク・インタフェースが複数ある場合、そのネットワーク・インタフェースは複数ネットワークと呼ばれます。たとえば、異なるネットワーク・インタフェース・アダプタを介して異なるアドレスの接続リクエストを処理する場合などです。
NetworkConnectionSpecs
自体は、serviceListeningPort
構成要素に関連付けられた配列のメンバーです。たとえば、serviceListeningPort
構成エントリを使用すると、ネットワーク仕様では、次の構文形式のいずれかを採用できます。
1. portValue | portValueString
2. networkSpec
3. '[' networkSpec [, networkSpec ...] ']'
ネットワーク仕様では、次の構文を使用できます。
portValue := [1234567890]+
portValueString := '"' portValue '"'
networkSpec := '{' portSpec [, ipaddressSpec | nameSpec] [, interfaceSpec] [, networkOptionSpec] '}'
portSpec := "port" : portValue | portValueString
ipaddressSpec := "address" : ipv4Address | ipv6Address | "ANY"
nameSpec := '"' :alphanum: '"'
interfaceSpec := "interface" : '"' :alphanum: '"'
networkOptionSpec := "options" : IPV4_ONLY | IPV6_ONLY
仕様がどのような形式であっても、内部表現は3番目の形式に正規化されます。
1. portValue | portValueString == networkSpec
2. portValue == '{' "port" : portValue '}'
3. portValueString == '[' '{' "port" : portValueString '}' ']'
最初の形式は、portValue
またはportValueString
のみが提供される既存のネットワーク・ポート仕様との互換性を保持します
2番目の形式は、networkSpec
を単一の値として割り当てます。この形式は、引き続き単一のネットワーク仕様を定義するのみで、ネットワークの値およびオプションを識別する際の制御と柔軟性が向上します
3番目の形式は、networkSpec
インスタンスの配列を定義します。アドレスまたはネットワーク・インタフェースのいずれかに基づいて、異なるネットワーク構成を指定できます。
例4-6 例
次の単純化されたホストのネットワーク・インタフェース構成を使用すると
$/sbin/ip addr show
lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:3e:52:6e:27 brd ff:ff:ff:ff:ff:ff
inet 192.0.2.39/21 brd 10.240.111.255 scope global eth0
inet6 2001:db8:85a3:0:0:8a2e:370:6666 brd ff02::1 scope link eth0
eth1: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:3e:1f:99:bc brd ff:ff:ff:ff:ff:ff
inet 192.0.2.98/21 brd 10.100.99.98 scope link eth1
inet6 2001:db8:85a3:0:0:8a2e:370:7334 brd ff02::1 scope link eth1
inet6 2001:db8:85a3:0:0:8a2e:370:6666
次の仕様が導かれます。
1. "serviceListeningPort: "9000"
2. "serviceListeningPort: 9000
3. "serviceListeningPort: { "port" : 9000 }
4. "serviceListeningPort: { "port" : "9000" }
5. "serviceListeningPort: { "port" : "9000", "address" : "192.0.2.254" }
6. "serviceListeningPort: { "port" : "9000", "name" : "server1" }
7. "serviceListeningPort: { "port" : "9000", "interface" : "eth1"}
8. "serviceListeningPort: [
{ "port" : "9000", "interface" : "lo" }
{ "port" : "9000", "address" : "192.0.2.39", "option" : "IPV4_ONLY" }
{ "port" : "9000", "interface" : "eth1", "option" : "IPV6_ONLY" }
これらの形式は、次のように記述されます。
- フォーム1-4
-
ALL
インタフェース上のANY
アドレスでポート9000をリスニングします。 - フォーム5
-
アドレス192.0.2.254のポート9000のみをリスニングします。
- フォーム6
-
server1
関連アドレスのポート9000をリスニングします。 - フォーム7
-
インタフェース
eth1
関連アドレスのポート9000をリスニングし、マップされたIPV4を使用してIPV4アドレス接続を受け入れます。 - フォーム8
-
インタフェース
lo
関連アドレスのポート9000をリスニングし、ポート9000アドレス192.0.2.39でIPV4アドレスのみを受け入れ、インタフェースeth1
に関連付けられたアドレスのポート9000でIPV6アドレスのみを受け入れます。
このロジックのほとんどで、ネットワーク・インタフェース・アダプタの識別名またはアドレスに基づいてネットワーク・インタフェース・アダプタの選択が処理されます。インタフェースは、要求されたアドレスに基づいて検索できます。
複数のアダプタを指定すると、各ネットワーク仕様がアダプタのサブセットにのみ解決されるようになります。優先順位処理により、プラットフォームのネットワーキング・インタフェースがマッピング・サブセット・インタフェースのマッチングをサポートする場合に、最後のネットワーク仕様のANY
アドレスとALL
インタフェースをプール仕様として指定できます。
親トピック: ネットワーク
4.3 Oracle GoldenGate MicroservicesにアクセスするためのNGINXを使用したリバース・プロキシの構成
ポート番号を使用せずにOracle GoldenGate MicroservicesにアクセスするためのNGINXを使用したリバース・プロキシ・サービスの構成方法について学習します。
リバース・プロキシを使用すると、デプロイメント内の単一のポート(443)を使用してマイクロサービスにアクセスできます。これにより、セキュアでないデプロイメントでマイクロサービスのURLをカプセル化できます。
ノート:
リバース・プロキシはオプションですが、マイクロサービスへの容易なアクセスが保証され、セキュリティも強化されるためにお薦めします。ループバック・アドレスのセキュアでないデプロイメントでマイクロサービスを実行し、NGINXインストールを使用してHTTPリバース・プロキシで前面に表示できます。
Oracle GoldenGate Classicから、リバース・プロキシを使用して構成されているマイクロサービス環境に証跡ファイルを送信する場合は、SOCKSPROXY
オプションを指定してOracle GoldenGate ClassicからポンプExtractを使用します。Oracle GoldenGate MicroservicesからClassic Architectureに証跡ファイルを送信する場合は、Distribution Service構成でogg
プロトコルを使用します。
Oracle GoldenGateの管理のClassicからMAへの接続およびMAからClassicへの接続を参照してください。
リバース・プロキシ・サポート
Oracle GoldenGate Microservices Architectureは、リバース・プロキシを使用するように構成できます。Oracle GoldenGate MAには、ReverseProxySettings
というスクリプトが含まれています。このスクリプトにより、NGINXリバース・プロキシ・サーバー専用の構成ファイルが生成されます。
たとえば、管理サービスがhttp://goldengate.example.com:9001
にあり、分散サービスがhttp://goldengate.example.com:9002
にあるとします。リバース・プロキシを使用すると、すべてのマイクロサービスに1つのアドレスから簡単にアクセスできます。たとえば、分散サービスの場合はhttp://goldengate.example.com/distsrvr
になります。このURLは、サービスごとに異なります。また、ポートごとではなく名前ごとのものになります。
これらのオプションは、ReverseProxySettings
ユーティリティを実行して使用できます。このユーティリティで使用可能なオプションは次のとおりです。
-
-o
または--output
-
出力ファイル名。デフォルトのファイル名は
ogg.conf
です。 -
-P
または--password
-
Service Managerアカウントのパスワード。
-
-l
または--log
-
ログ・ファイル名を指定し、ロギングを開始します。デフォルトではロギングしません。
-
--trailOnly
-
インバウンドの証跡データ専用に構成します。
-
-t
または--type
-
プロキシ・サーバーのタイプ。デフォルトはNginxです。
-
-s
または--no-ssl
-
SSLなしで構成します。
-
-h
または--host
-
リバース・プロキシの仮想ホスト名。
-
-p
または--port
-
リバース・プロキシのポート番号。デフォルトは80または443です。
-
-?
または--help
-
使用方法の情報を表示します。
-
-u
または--user
-
使用するService Managerアカウントの名前
-
-v
または--version
-
バージョンを表示します。
これらの値は、Service Managerへの接続時に使用されます。認証が有効になっている場合は必須です。
前提条件
MAでは、任意のリバース・プロキシ・サービスを使用できます。次の例では、その他のリバース・プロキシ・サービスを構成するための手順と、対象プロキシ・サーバーのドキュメントを示します。
次の前提条件では、NGINXリバース・プロキシを構成するための最小要件に関する詳細を示します。NGINXを使用しない場合でも、目的の環境とリバース・プロキシに対して同様の要件が必要になることがあります。対象のリバース・プロキシのドキュメントを参照してください。
-
NGINXをインストールします。Oracle LinuxへのNGINX Webサーバーおよびプロキシのインストールを参照してください。Oracle Linuxの場合、NGINXをインストールするコマンドは次のとおりです。
yum —y install NGINX
-
JREのバージョンがJRE 8以降であることを確認します。
-
Oracle GoldenGate MAをインストールします。
-
1つ以上のアクティブなMAデプロイメントを作成します。
-
Oracleユーザーに
sudo
権限があることを確認します。 -
NGINXインストール・ディレクトリ・パスを含めるように
PATH
環境変数を構成します。
NGINXリバース・プロキシの構成
Oracle GoldenGate MAのインストールには、ReverseProxySettings
ユーティリティが含まれています。ReverseProxySettings
ユーティリティは、$OGG_HOME/lib/utl/reverseproxy
ディレクトリにあります。ReverseProxySettings
ユーティリティで使用できる追加のコマンドを確認するには、--help
オプションを指定してユーティリティを実行します。
$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings --help
NGINX証明書を信頼できる証明書として分散サービスのクライアント・ウォレットに追加するには、信頼できる証明書を参照してください。
-
NGINXリバース・プロキシ用の構成ファイルを生成するには、ReverseProxySettingsユーティリティの場所に移動します:
cd $OGG_HOME/lib/utl/reverseproxy
-
ReverseProxySettingユーティリティを実行します。
ReverseProxySettings -u adminuser -P adminpwd -o ogg.conf http://localhost:9100
このコード・スニペットでは、
adminuser
はデプロイメント・ユーザー名、adminpwd
はデプロイメントへのログインに使用されるデプロイメント・ユーザー・パスワードです。 -
既存のNGINX構成を、MAデプロイメントの
ReverseProxySetting
ユーティリティを使用して生成された構成に置き換えます。sudo mv ogg.conf /etc/nginx/conf.d/nginx.conf
ただし、このNGINX構成は、
events
セクションがなくhttp
内にmap
およびserver
セクションが含まれていないと完成ではありません。オプションで、デフォルトの
nginx.conf
ファイルを使用することや、次のようなinclude
文を追加して、生成されたogg.conf
を追加することができます。include /etc/nginx/conf.d/ogg.conf;
この場合は、他の
servers
セクションをコメント・アウトする必要があります。 -
NGINXの自己署名証明書を生成します。
sudo sh /etc/ssl/certs/make-dummy-cert /etc/nginx/ogg.pem
リバース・プロキシを経由する配布パスの場合は、有効な証明書を使用する必要があります。デプロイメントでの受信リクエストの処理に使用されているのと同じ証明書を指定することをお薦めします。そうしないと、パスの起動は、分散サービスにおいて次のエラーで失敗します。
2019-03-26T11:26:00.324-0700 ERROR| ERROR OGG-10351 Oracle GoldenGate Distribution Service for Oracle: Generic error -1 noticed. Error description - Certificate validation error: Unacceptable certificate from test00abc: application verification failure. (A4)
-
NGINX構成を検証します。
sudo NGINX -t
コマンドが正常に実行された場合、出力は次のようになります。NGINX: the configuration file /etc/NGINX/NGINX.conf syntax is ok NGINX: configuration file /etc/NGINX/NGINX.conf test is successful
-
新しい構成でNGINXをリロードします。
sudo NGINX -s reload
構成ファイルに対する変更がロードされていない場合は、プロキシを停止して再起動します。
-
NGINXが正常に設定された後にマイクロサービスにアクセスできるかどうかをテストするには、Webブラウザを開きます。
-
次のように、ポート番号443を使用してサービス・マネージャのプロキシURLを入力します。
http://dc.example.com:443
これにより、サービス・マネージャのログイン・ページが開き、そこから他のマイクロサービスにもアクセスできます。マイクロサービスに直接アクセスする場合は、以前に生成された
ogg.conf
ファイルの指定に従って、そのマイクロサービスのプロキシURLを入力できます。
NGINXリバース・プロキシの構成に関するこのビデオも参照してください。
SSL終端
TLSベースの接続を使用するリバース・プロキシとオリジン・サーバーの間にセキュアでない接続がある場合、その接続はリバース・プロキシSSL終端と呼ばれます。
ノート:
SSL終端では、リバース・プロキシとオリジン・サーバー間の接続はセキュアでありません。
ただし、SSLブリッジングもサポートされています。ここでは、クライアントとリバース・プロキシ間の接続が保護され、リバース・プロキシとオリジン・サーバー間の接続も保護されています。
親トピック: ネットワーク
4.4 ネットワーク通信
MAサーバーは、リクエストがサーバーに送信されたとき、クライアントに送信されるすべてのレスポンス・メッセージの発信元です。
MAサーバーは、プロキシとして作動することや、他のアプリケーションで生成されたレスポンス・メッセージのトンネリングをサポートすることはありません。セキュリティ保護されたネットワーク通信には、TLS 1.2またはDTLS (Datagram Transport Layer Security)ライブラリを使用します。MAのOracleプラットフォームはOracle SSLツールキット(NZ)を使用し、これにはOracle Walletが統合されています。
異種プラットフォームでは、利用可能な場面でOracle SSLツールキットを使用します。
親トピック: ネットワーク