| Oracle®Fusion Middleware Oracle GoldenGate環境の保護 12c (12.3.0.1) E98561-01 |
|
 前 |
 次 |
Oracle GoldenGateのネットワークを保護する方法を学習します。
トピック:
親トピック: マイクロサービス・アーキテクチャの保護
ネットワーク接続のMA構成は配列またはネットワーク・アクセス制御リスト(ACL)の形式を使用します。
各ACL仕様は、最小限、APC仕様が指定アドレスからのクライアント接続を許可するか拒否するかを示す許可文で構成されます。ACL仕様は順番に処理され、指定アドレスが適格と認定され次第終了します。指定アドレスが適格と認定されない場合、プロセスは次のACL仕様を続けます。接続を要求しているクライアントのアドレスが適格と認定されると、ACL権限は接続が「許可」または「拒否」のいずれであるかを決定します。ACL仕様が接続を要求しているクライアントのアドレスを適格と認定していない場合、デフォルトの解決方法の「許可」が仮定され、クライアントは接続を許可されます。構成内のACLは次の構文形式を使用します。
ipACL := '[' aclSpec [, aclSpec] ']' aclSpec := "permission" : [ "deny" | "allow" ] [, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ] ipv4Address := '"' decimal '.' decimal '.' decimal '.' decimal '"' ipv4MappedAddress := '"' 'ff::' decimal '.' decimal '.' decimal '.' decimal '"' ipv6Address := '"' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal '"'
インバウンド接続リクエストは、ネットワーク・インタフェース上で受信された後に一様に処理されます。ネットワーク・インタフェースの構成がアドレッシングの形式を決定します。たとえば、IPv6インタフェースに表示されるアドレスがIPv6アドレスとして表示されます。IPv6構成でIPv4マッピングが指定されている場合、IPv4クライアントのアドレスはIPv6アドレス空間にマップされます。IPv4インタフェースに表示されるアドレスは、マップされていないIPv4アドレスとして表示されます。ACLの適格認定はアドレスの適格認定に焦点をあてており、ホスト環境内のすべてのアダプタは一意のアドレスを持っているため、追加のインタフェース情報は必要ありません。
ネットワーク・インタフェースのホットフェイルオーバーをサポートするホストの場合、アダプタのMACアドレスへのネットワークIPアドレスのフェイルオーバーおよび再割当はアプリケーションに対して透過的です。
例2-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" } ]
IPv6ループバック・アドレス(IPV6アドレスに:1で表される127.0.0.1)からのクライアント接続を許可し、マップされていないIPv4アドレス192.0.2.253からのクライアント接続を許可し、IPv6アドレス2001:db8:85a3:0:0:8a2e:370:7334からのクライアント接続を許可し、マップされたIPv4アドレスff::192.0.2.254からのクライアント接続を拒否します。
"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" } ]
親トピック: ネットワーク
ネットワーク接続構成を指定する方法について学習します。
アダプタ・クラスは、ネットワークのリスニング・アドレス構成を取得し、ネットワーク構成に基づいてリスニング・ポートを確立するロジックと実装をカプセル化するために使用されます。実際のネットワーク接続情報は、ソフトウェア通信アーキテクチャ(SCA)のネットワーク接続仕様で取得されます。ScaNetworkSpecクラスの説明で、ScsNetworkSpecのインスタンスは、ScaSharedContextから取得したネットワーク構成情報を表しています。ScaNetworkSpecは個別のネットワーク仕様を処理します。ただし、完全なSCAネットワーク仕様は、3形式のいずれかを使用して、複数のネットワーク構成を定義できます。複数ネットワークとは、ホストがマルチホームである環境に複数のネットワーク・インタフェースが構成されている場合です。たとえば、異なるネットワーク・インタフェース・アダプタを介して異なるアドレスで接続リクエストを処理する場合などです。
NetworkConnectionSpecs自体は、serviceListeningPort構成要素に関連付けられた配列のメンバーです。たとえば、serviceListeningPort構成エントリを使用すると、SCAネットワーク仕様では、次の構文形式のいずれかをとることができます。
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インスタンスの配列を定義します。アドレスまたはネットワーク・インタフェースのいずれかに基づいて、異なるネットワーク構成を指定できます。
例2-2の例
次の単純化されたホストのネットワーク・インタフェース構成を使用すると
$/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
次の仕様が導かれます。
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" }
これらの形式は、次のように記述されています。
ALLインタフェース上のすべてのANYアドレスでポート9000をリスニングします。
アドレス192.0.2.254のポート9000のみをリスニングします。
server1関連アドレスのポート9000をリスニングします。
インタフェースeth1関連アドレスのポート9000をリスニングし、マップされたIPV4を使用してIPV4アドレス接続を受け入れます。
インタフェースlo関連アドレスのポート9000をリスニングし、ポート9000アドレス192.0.2.39でIPV4アドレスのみを受け入れ、インタフェースeth1に関連付けられたアドレスのポート9000でIPV6アドレスのみを受け入れます。
このクラス内にカプセル化されたロジックのほとんどで、ネットワーク・インタフェース・アダプタを識別する名前またはアドレスに基づいたネットワーク・インタフェース・アダプタの選択が処理されます。インタフェースは、要求されたアドレスに基づいて検索できます。
複数のアダプタを指定すると、各ScaNetworkSpecがアダプタのサブセットのみに解決されることを意味します。優先順位処理により、プラットフォームのネットワーキング・インタフェースがマッピング・サブセット・インタフェースのマッチングをサポートする場合に、最後のScaNetworkSpecのANYアドレスとALLインタフェースをプール仕様として指定できます。
親トピック: ネットワーク
プロキシ・サーバーを構成する方法を学習します。
プロキシ構成は、デプロイメントのネットワーク内で様々なMAサーバーへのアクセスを仲介します。
MAでは、1つまたは複数のプロキシサーバーがMAサーバーへのアクセスを仲介するネットワーク環境で、適切かつ準拠した動作を行う必要があります。
構成
初期構成は、単純にプロキシ検出を有効にするか無効にするかを宣言しています。通常はデフォルトで有効化されていますが、/config/network/proxyDetailsで無効化できます。enable句は次のようになります。
{
"network" : {
"proxyEnabled": true,
"proxyDetails": {
"proxyACLEnabled": true,
"proxyACL": [
{ "permission": "deny", "address": "192.0.2.254" },
{ "permission": "allow", "address": "192.0.2.254", "trusted": false },
{ "permission": "allow", "address": "ANY", "trusted": true }
],
"urlMappingEnabled": true,
"urlMapping": [
]
}
}
}
プロキシACL仕様
プロキシACL仕様の構成は、ネットワークIP ACL仕様と似ています。違いは、各エントリが環境内のプロキシ・サーバーのアクセス制御を定義し、信頼指標を含む点です。各ACL仕様は、最小限、ACL仕様がプロキシ・サーバーの指定アドレスを介してプロキシされたクライアント接続を許可するか拒否するかを示す許可文で構成されます。ACL仕様は順番に処理され、指定アドレスが適格と認定され次第終了します。指定アドレスが適格と認定されない場合、プロセスは次のACL仕様を続けます。接続を要求しているクライアントのアドレスが適格と認定されると、ACL権限は、接続が許可されるか拒否されるかを決定します。ACL仕様が接続を要求しているクライアントのアドレスを適格と認定していない場合、デフォルトの解決方法の「許可」が使用され、クライアントは接続を許可されます。構成内のACLは次の形式をとることがあります。
ipACL := '[' aclSpec> [, aclSpec] ']' aclSpec := "permission" : [ "deny" | "allow" ] [, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ] ipv4Address := '"' decimal '.' decimal '.' decimal '.' decimal '"' ipv4MappedAddress := '"' 'ff::' decimal '.' decimal '.' decimal '.' decimal '"' ipv6Address := '"' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal '"'
例2-3 プロキシの例
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" } ]
IPv6ループバック・アドレス(IPV6アドレスに:1で表される127.0.0.1)からのクライアント接続を許可し、マップされていないIPv4アドレス192.0.2.253からのクライアント接続を許可し、IPv6アドレス2001:db8:85a3:0:0:8a2e:370:7334からのクライアント接続を許可し、マップされたIPv4アドレスff::192.0.2.254からのクライアント接続を拒否します。
"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" } ]
親トピック: ネットワーク
リバース・プロキシ・サーバーを構成する方法を学習します。
リバース・プロキシによって、Oracle GoldenGate MAデプロイメントに関連付けられた様々なマイクロサービスに対して1つのアクセス先を使用できるようになります。
プロキシ・サーバーはご使用の環境設定やネットワーク要件に応じて構成できます。リバース・プロキシはオプションですが、マイクロサービスへの容易なアクセスが保証されセキュリティが強化されるため推奨します。
リバース・プロキシ・サポート
Oracle GoldenGateMAはリバース・プロキシを使用するように構成できます。Oracle GoldenGate MAにはReverseProxySettingsと呼ばれるアプリケーションが含まれ、これによってリバース・プロキシ・サーバーの構成ファイルが生成されます。たとえば、Administration Serverがhttps://goldengate.example.com:9001にあり、Distribution Serverがhttps://goldengate.example.com:9002にあるとします。リバース・プロキシを使用すると、1つのアドレス(たとえば、https://goldengate.example.com)ですべてのマイクロサービスにアクセスできます。
ReverseProxySettingsアプリケーションには、2つの追加のパラメータがあります(Oracle GoldenGateバージョン12.3.0.1以降の場合)。-P: Service Managerアカウントのパスワード。
-u: 使用するService Managerアカウントの名前。
これらの値は、Service Managerへの接続時に使用されます。認証が有効になっている場合は必須です。
前提条件
MAでリーバース・プロキシ・サービスを使用する必要がある場合は、Nginxを使用してください。これは、無料のオープン・ソースの高性能HTTPサーバーおよびリバース・プロキシであり、IMAP/POP3プロキシ・サーバーでもあります。Oracle GoldenGateのMAには、Nginxリバース・プロキシを構成するためのユーティリティが付属しています。
Nginxのインストール: Oracle Linuxでは、Nginxをインストールするコマンドは次のとおりです。
yum —y install nginx
Nginxのインストール方法の詳細は、Nginxリバース・プロキシのインストールに関する説明を参照してください
JREバージョンがJRE 8であることを確認します。
Oracle GoldenGate MAをインストールします。
1つ以上のアクティブなMAデプロイメントを作成します。
Nginxベースのリバース・プロキシの構成例
Oracle GoldenGate MAインストールには、$OGG_HOME/lib/utl/reverseproxy/ディレクトリにReverseProxySettingsアプリケーションが含まれます。–helpコマンドを使用するとアプリケーションで使用できるオプションのリストが表示されます。
$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings --help
Usage: proxysettings [options] service-manager-url
Options:
-o, --output Output file name (default is ogg.conf)
-l, --log Log file name (default is no logging)
-t, --type Proxy server type (default is nginx)
-s, --no-ssl Configure without SSL
-h, --host Virtual host name for reverse proxy
-p, --port Reverse proxy port number (defaults to 80 or 443)
-?, --help Display usage information
-v, --version Display version
次の手順に従ってリバース・プロキシを構成します。
Nginxの設定ファイルを作成するには:
$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings -u admin id -P admin password -o ogg.conf http://localhost:9100
sudo mv ogg.conf /etc/nginx/conf.d/
次のコマンドを使用して、Nginx用の自己署名証明書を作成します。
sudo sh /etc/ssl/certs/make-dummy-cert /etc/nginx/ogg.pem
次のコマンドを使用して、新しい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
rootとして、Nginxと新しい構成を再ロードします。
sudo nginx -s reload
Curlを使用して、リバース・プロキシが機能していることを確認します。
curl -sv http://localhost/services/v2
{"$schema":"api:version","catalog":{"links":[
{"href":"http://localhost/service s/v2/metadata-catalog","rel":"canonical"}]},"isLatest":true,"lifecycle":"active","links":[
{"href":"http://localhost/services/v2","mediaType":"application/js on","rel":"canonical"},
{"href":"http://localhost/services/v2","mediaType":"app lication/json","rel":"self"}],"version":"v2"}
注意:
ターゲットのService Managerに関連付けられたデプロイメントが変更される場合は、Nginx構成ファイルを再生成および再ロードする必要があります。親トピック: ネットワーク
