2 デプロイメントの保護

Microservices RESTベースのサービス・インタフェースは、HTTPまたはHTTPSのどの基底プロトコルが使用されているかには関係ありません。それらの動作は、セキュアなプロトコルまたはセキュアでないプロトコルのどちらを使用して発行された場合も同じです。

デプロイメントを保護するには、Oracle GoldenGate Microservicesを使用して最初にデプロイメントを設定するときに、セキュリティ構成でセキュリティを有効化する必要があります。セキュリティ・ロールが割り当てられた管理者は、デフォルトのMAセキュリティ・プロファイルの詳細を変更して、セキュアな操作の様々な側面を制御できます。セキュリティ・ユーザー・ロールの詳細は、『Oracle GoldenGate Microservices Architectureの使用』ユーザーの追加方法(19c)に関する項を参照してください。

MAのデフォルト・セキュリティ構成は、高中のセキュリティ・レベルに設定されています。MAデプロイメントのセキュリティを有効にすることで、インバウンド通信およびアウトバウンド通信の両方からのデフォルトの調整済セキュリティ・プロファイルが有効になります(クライアントおよびサーバーのウォレット・ロケーション(WRL)を除く)。

デプロイメントを保護するには、既存のウォレットおよび証明書を使用するか、新しいウォレットおよび証明書を作成します。詳細は、Oracle GoldenGate Microservices Architectureの使用セキュアなデプロイメントとセキュアでないデプロイメントの設定を参照してください。

2.1 自己署名ルート証明書の作成

セキュア・モードでは、管理コールやデータ・トランスポートを含むOracle GoldenGate MAとの通信はTLS証明書を使用して保護されます。証明書は購入することもテスト目的で自作することもできます。

本番環境では、商用証明書を使用するようにお薦めします。テスト環境では、orapkiまたはOpenSSLを使用して、独自の自己署名証明書を作成することもできます。

Oracle GoldenGateのセキュア・デプロイメントごとに、Oracle GoldenGateサービス用のサーバー証明書と、別のリモート・デプロイメントとの通信を保護するためにDistribution ServerやReceiver Serverで使用されるクライアント証明書の2つの証明書が必要になります。すべての証明書が同じルート認証局(rootCA)によって署名されていることが重要です。rootCAはトラストポイントです。デプロイメント全体のすべての証明書に対して1つのルート認証局(rootCA)のみを使用します。Oracle GoldenGateがデプロイされたサーバーごとに、特定のサーバー証明書を1つ用意します。

既存のルート証明書を適用するか、OGG_HOME/binディレクトリのorapkiを使用できます。『Oracle Databaseセキュリティ・ガイド』orapkiユーティリティに関する項を参照してください。

orapkiを使用してルート証明書を作成する方法を次の例で示します。

  1. ウォレットと証明書を格納するディレクトリを作成します。たとえば、~/wallet_directoryです。
  2. 自動ログイン・ウォレットを作成します。この例では、ウォレット名としてroot_caを使用します。
    orapki wallet create -wallet ~/wallet_directory/root_ca -auto_login -pwd welcome123
  3. orapkiコマンドで自己署名(ルート・ユーザー)証明書を作成するには、 -sign_alg sha256オプションを指定します。
  4. orapkiウォレットの場合:
    add -wallet ~/wallet_directory/root_ca -dn "CN=RootCA" -keysize 2048 -self_signed -validity 7300 -pwd welcome123 -sign_alg sha256
  5. 証明書を.pemファイルにエクスポートします。
    orapki wallet export -wallet ~/wallet_directory/root_ca -dn "CN=RootCA" -cert ~/wallet_directory/rootCA_Cert.pem -pwd welcome123
ウォレットの作成が完了しました。

2.2 サーバー証明書の作成

次に示すステップは、root_caという名前のルート証明書を使用してサーバー証明書を作成する方法の例です。
  1. ウォレットと証明書を格納するディレクトリを作成します。たとえば、~/wallet_directoryです。
  2. 自動ログイン・サーバー・ウォレットを作成します。
    orapki wallet create -wallet ~/wallet_directory/$(hostname) -auto_login -pwd welcome123* 
    要求されたら、サーバーのパスワードを入力します。
  3. 証明書署名リクエスト(CSR)をサーバーのウォレットに追加します。
    orapki wallet add -wallet ~/wallet_directory/$(hostname) -dn "CN=$(hostname)" -keysize 2048 -pwd welcome123
  4. CSRを.pemファイルにエクスポートします。
    orapki wallet export -wallet ~/wallet_directory/$(hostname) -dn "CN=$(hostname)" -request ~/wallet_directory/servername_req.pem -pwd welcome123
  5. CSRを使用して、サーバーまたはクライアントの署名証明書を作成し、ルート証明書を使用して署名します。一意のシリアル番号を各証明書に割り当てます。
    orapki cert create -wallet ~/wallet_directory/root_ca -request ~/wallet_directory/servername_req.pem -cert ~/wallet_directory/servername_Cert.pem -serial_num 20 -validity 375  -sign_alg sha256
  6. ルート証明書をクライアントまたはサーバーのウォレットに信頼できる証明書として追加します。
    orapki wallet add -wallet ~/wallet_directory/$(hostname) -trusted_cert -cert ~/wallet_directory/rootCA_Cert.pem -pwd welcome123
  7. サーバーまたはクライアント証明書をユーザー証明書としてクライアントまたはサーバーのウォレットに追加します。
    orapki wallet add -wallet ~/wallet_directory/$(hostname) -user_cert -cert ~/wallet_directory/servername_Cert.pem  -pwd welcome123  
ウォレットの作成が完了しました。

2.3 Distribution Serverユーザー証明書の作成

オプションとして、クライアント証明書を使用するか、Distribution ServerのデプロイメントとReceiver Serverのデプロイメントに共通するユーザー名とパスワードを使用できます。

この証明書はルート証明書によっても署名されます。これによって共通のトラスト・ポイントが提供されます。サーバーは、同じルート証明書で署名されたすべての証明書をサーバーの証明書と見なすためです。証明書を作成するには、OGG_HOME/binディレクトリ内のorapkiを使用します。orapkiの詳細は、『Oracle Databaseセキュリティ・ガイド』orapkiユーティリティに関する項を参照してください。
次に示すステップは、Distribution Severユーザー証明書を作成する方法の例です。
  1. ウォレットと証明書を格納するディレクトリを作成します。たとえば、~/wallet_directoryです。
  2. 自動ログイン・クライアント・ウォレットを作成します。この例では、ウォレット名としてdist_clientを使用します。
    orapki wallet create -wallet ~/wallet_directory/dist_client -auto_login -pwd welcome123
  3. CSRをウォレットに追加します。
    orapki wallet add -wallet ~/wallet_directory/dist_client -dn "CN=dist_client" -keysize 2048 -pwd welcome123
  4. CSRを.pemファイルにエクスポートします。
    orapki wallet export -wallet ~/wallet_directory/dist_client -dn "CN=dist_client" -request ~/wallet_directory/dist_client_req.pem -pwd welcome123
  5. CSRを使用して、サーバーまたはクライアントの署名証明書を作成し、ルート証明書を使用して署名します。一意のシリアル番号を各証明書に割り当てます。
    orapki cert create -wallet ~/wallet_directory/root_ca -request ~/wallet_directory/dist_client_req.pem -cert ~/wallet_directory/dist_client_Cert.pem -serial_num 30 -validity 375 -pwd welcome123
  6. ルート証明書を信頼できる証明書としてクライアントまたはサーバーのウォレットに追加します。
    orapki wallet add -wallet ~/wallet_directory/dist_client -trusted_cert -cert ~/wallet_directory/rootCA_Cert.pem -pwd welcome123
  7. サーバーまたはクライアント証明書をユーザー証明書としてクライアントまたはサーバーのウォレットに追加します。
    orapki wallet add -wallet ~/wallet_directory/dist_client -user_cert -cert ~/wallet_directory/dist_client_Cert.pem -pwd welcome123 
ウォレットの作成が完了しました。

2.4 信頼できる証明書

wss通信プロトコルは、Oracle GoldenGate Microservices ArchitectureのTLSを使用したセキュアな通信のニーズを満たすために、Distribution PathのDistribution Serverで使用されます。

TLS接続には2つのタイプがあります。また、TLSを使用するには、証明書のトラスト・チェーンに対する特定の要件があります。

Distribution ServerとReceiver Server

Distribution ServerとReceiver Serverの両方に証明書が必要です。Distribution Serverは、アウトバウンド・セクションのクライアント・ウォレットの場所にある証明書を使用します。そのウォレットの場所は、deployment_home/etc/confdeploymentConfiguration.datファイルで確認できます。

両方のウォレット内の証明書は、相互に信頼されることが必要なため、その両方にClassic Architectureによって発行された商用証明書を用意するか、それぞれの自己署名証明書を相互に信頼する必要があります。

自己署名証明書の場合、次のうちのいずれかを選択できます。
  • 同じルート証明書で両方の証明書に署名します。

  • 相手側の証明書を信頼できる証明書としてローカル・ウォレットに追加します

次に、Distribution ServerとReceiver Serverの証明書の例を示します。
"distsrvr": {
        "$schema": "ogg:service",
        "config": {
            "network": {
                "serviceListeningPort": 9102
            },
            "authorizationDetails": {
                "common": {
                    "allow": [
                        "Digest",
                        "x-Cert",
                        "Basic"
                    ]
                }
            },
            "authorizationEnabled": true,
            "workerThreadCount": 24,
            "legacyProtocolEnabled": true,
            "taskManagerEnabled": true,
            "security": false,
   //The following is the outbound communication setup.
            "securityDetails": {
                "network": {
                    "outbound": {
                        "authMode": "client_server",
                        "crlEnabled": false,
                        "role": "client",
                        "wrl": "file:/u02/ogg/dpora12c/etc/ssl/740977c539e7",
                        "wrlPassword": ""
}

この例では、securityDetailsで始まるセクションが、アウトバウンド通信の設定に対応します。WRLの値が、ウォレットの場所を示しています。

Receiver Serverの場合、証明書はインバウンド・ウォレットの場所に対応するウォレット内なります。次の例で示すように、この場所は同じdeploymentConfiguration.datファイル内に記述されています。
…
  "recvsrvr" : {
     "$schema" : "ogg:service",
     "config" : {
        "authorizationDetails" : {
           "common" : {
              "allow" : [ "Basic", "x-Cert" ]
            }
         },
         "authorizationEnabled" : true,
         "legacyProtocolEnabled" : true,
         "network" : {
            "serviceListeningPort" : 10083
         },
         "security" : true,
         "securityDetails" : {
            "network" : {
               "common" : {
                 "authMode" : "clientOptional_server",
                  "blockSize" : 4096,
                  "cipherSuites" : [
                     "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
                     "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
                     "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
                     "TLS_RSA_WITH_AES_256_GCM_SHA384"
                  ],
                  "crlEnabled" : false,
                  "crlStore" : "file:",
                  "id" : "OracleSSL",
                  "protocolVersion" : "1_2_Or_1_1_Or_1_0_Or_3_0"
               },
               "inbound" : {
                  "role" : "server",
                  "wrl" : "file:/home/oracle/apps/OlnxSRCSSL/etc/ssl/OlnxSRC",
                  "wrlPassword" : ""
               },
               "outbound" : {
                  "role" : "client",
                  "wrl" : "file:/home/oracle/apps/OlnxSRCSSL/etc/ssl/oggdistclient",
                  "wrlPassword" : ""
               }

Distribution Serverでは、Receiver Serverの証明書で使用されているホスト名が適切にルーティングできない場合、そのホストの正しいIPアドレスで/etc/hostsファイルを更新する必要があります。Distribution Serverは、Receiver Serverからの証明書を受け入れると、このIPアドレスをReceiver Serverとの通信に使用するようになります。

Distribution ServerおよびReceiver Serverでのリバース・プロキシ(NGINX)の使用

Nginx証明書を信頼できる証明書としてDistribution Serverのクライアント・ウォレットに追加します。その他の作業は不要です。通常、Nginxで使用される証明書は自己署名されています。Classic Architectureによって発行されたものであれば、このステップを実行する必要はありません。

NGINX証明書のホスト名もルーティング可能なものであることが必要です。そうなっていない場合は、Distribution Serverで、そのホスト名の正しいIPアドレスを反映するように、/etc/hostsファイルを更新する必要があります。NGINX証明書に有効なホスト名が記述されていないときに、サブジェクト代替名レコードがある場合、そこに示されるDNS名がホスト名になります。たとえば:
…X509v3 Subject Alternative Name:
DNS:localhost, 
DNS:oggmp0802iad, 
DNS:oggmp0802iad.sub06261535551.wernervcnab.oraclevcn.com, 
DNS:127.0.0.1, IP Address:127.0.0.1…