Oracle® Fusion Middleware: Securing The Oracle Goldengate Environment
Oracle® Fusion Middleware: Securing The Oracle Goldengate Environment
Oracle® Fusion Middleware: Securing The Oracle Goldengate Environment
12c (12.3.0.1)
E91326-01
March 2018
Oracle Fusion Middleware Securing the Oracle GoldenGate Environment, 12c (12.3.0.1)
E91326-01
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,
license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.
Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-
specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the
programs, including any operating system, integrated software, any programs installed on the hardware,
and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be
responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
2 Network
2.1 Network Access Control 2-1
2.2 Network Connection Adapter 2-2
2.3 Proxy Support 2-4
2.4 Reverse Proxy Support 2-6
4 Communication Security
4.1 Certificate Access Control List 4-1
4.2 Transport Layer Security Protocols and Ciphers 4-2
4.3 TLS Certificate Revocation List Handling 4-4
4.4 HTTP Security and Cache Headers 4-7
iii
5.4 Creating Server and Deployment IDs 5-2
6 Securing Deployments
iv
13 Configuring GGSCI Command Security
13.1 Setting Up Command Security 13-1
13.2 Securing the CMDSEC File 13-3
15 Securing Manager
v
Audience
This guide is intended for the person or persons who are responsible for operating
Oracle GoldenGate and maintaining its performance. This audience typically includes,
but is not limited to, systems administrators and database administrators.
6
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.
7
Conventions
The following text conventions are used in this document:
Convention Meaning
boldface Boldface type indicates graphical user interface elements associated
with an action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for
which you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code
in examples, text that appears on the screen, or text that you enter.
8
Related Information
The Oracle GoldenGate Product Documentation Libraries are found at
Oracle GoldenGate
Oracle GoldenGate Application Adapters
Oracle GoldenGate for Big Data
Oracle GoldenGate Plug-in for EMCC
Oracle GoldenGate Monitor
Oracle GoldenGate for HP NonStop (Guardian)
Oracle GoldenGate Veridata
Oracle GoldenGate Studio
Additional Oracle GoldenGate information, including best practices, articles, and
solutions, is found at:
Oracle GoldenGate A-Team Chronicles
9
1
Introducing Oracle GoldenGate Security
Oracle GoldenGate includes many security features that provide varying levels of
security. Understanding the security features and the uses cases they cover are
important first steps when learning how to secure your environment.
There are two different architectures offered with Oracle GoldenGate:
1-1
Part I
Securing the Microservices Architecture
Use this part to secure your Microservices Architecture (MA) environment.
The MA service interfaces use the REST architectural style, within an HTTP
environment. As REST is a style that uses HTTP and not a distinct transfer
implementation, all the security related concerns and solutions applied to HTTP apply
equally to REST interfaces. This includes ensuring general security related to HTTP-
based requests, responses, sessions, cookies, headers and content as well as
addressing issues such as Cross Site Request Forgery, UI Redressing and delegated
authentication. TLS/SSL when enabled, ensures confidentiality and optionally integrity,
although typical configurations do not ensure bi-lateral integrity. Negotiating security
configurations can further specify identity validation, renegotiation, and revocation
requirements as allowed by Oracle security standards.
Communications Transport
All REST Service Interfaces and Data Conveyances may be conducted over the
following network transport:
• TCP is used for network communication.
• UDT is an additional protocol used for data conveyance. It is a high-performance,
UDP-based data transfer protocol, which transfers large datasets over high-speed
WAN.
• WebSockets 2.0 is a not a transport protocol but a pseudo-transport that enables a
server to send content to client without client solicitation, thereby enabling bi-
directional messaging over a persistent connection. It operates over HTTPS ports
simplifying network security management.
Communications Security
An MA server is the originator of all the response messages sent to the client when a
request is sent to the server. An MA server neither serves as a proxy nor supports
tunneling of response messages generated by other applications. Secured network
communications use Oracle approved TLS (Transport Layer Security) or DTLS
(Datagram Transport Layer Security) libraries. MA Oracle platforms uses the Oracle
SSL toolkit (NZ), which includes Oracle Wallet integration.
For non-Oracle platforms, the Oracle SSL toolkit is used where available. Where the
Oracle SSL Toolkit is not available, an alternate SSL toolkit is used.
All MA servers implement client and server authentication. However, client and server
authentication is only available when network security is configured and enabled. MA
servers can be configured with network security enabled but without using server or
client authentication.
MA Security Features
Learn about these MA security features:
• Connection Filtering: This is responsible for qualifying and filtering a candidate
connection based on connection policy specifications.
• Certificate Filtering: Similar to connection filtering, this feature enables qualifying
certificates as part of accepting or denying a connection request.
• Fall-back Constraints: Network security configuration within MA servers enables
you to configure and constrain the protocol version negotiation fall-back behavior
allowing them to control if and how the protocol versions are negotiated.
• IPv6 Support: Oracle GoldenGate network implementations support native IPv6
addressing standards.
• Session Management: MA Service Interfaces requests are REST and stateless,
which implies that no client application context it stored on the server between
requests. The application session state is entirely held by the client.
• User Credential Storage: MA implementations address this by using Oracle
Wallets and related identity management services to store security information.
Approved encryption technologies are configured to secure both stored and in-
flight user data. Stored data typically refers to file system files like capture data
trail files while in-flight data typically refers to data transmitted between peers over
a non-persistent communications channel.
• Single Page Applications (SPAs) and WebApp Security: If the initial connection
to the Service Manager uses the HTTPS protocol, then the browser connects using
SSL/TLS. If the server is configured to require the client to present a certificate,
the browser needs to be configured to present the appropriate client certificate.
• Cipher-suites: The cipher-suites for MA are configured during deployment. You
can change the value of the cipher-suite using the Server Manager REST
interfaces for each server. Alternatively, you can update then using either the MA
boostrap configuration override option or the command-line configuration override
options. The list of cipher-suites available to a user differs based on the
environment. This ensures that there is sufficient overlap to allow secure
communication at the required security level.
Both client and server platforms generally support more than one cipher-suite.
This increases the probability that the client and server can negotiate and agree
on a cipher-suite to use. The set of available cipher-suites on the server is dictated
by the NZ Toolkit (or alternate TLS/SSL toolkit). There are several cipher-suites
set as the default set and is dependent on the Java Runtime Environment
distributed with Oracle GoldenGate. The default set attempts to specify the most
common cipher-suites with the highest security protection and highest
performance. However, in practice you need to choose between high security and
high performance as these are competing attributes and there is a trade-off
between security and performance.
2
Network
Learn how to secure your network for Oracle GoldenGate.
Topics:
• Network Access Control (page 2-1)
The MA configuration of the network connection takes the form of an array or
network access control list (ACL).
• Network Connection Adapter (page 2-2)
Learn about how to specify your network connection configuration.
• Proxy Support (page 2-4)
Learn how to configure your proxy servers.
• Reverse Proxy Support (page 2-6)
Learn how to configure your reverse proxy servers.
Inbound connection request are processed uniformly after they are received over a
network interface. The network interface configuration dictates the form of addressing.
For example, addresses appearing on an IPv6 interface appears as IPv6 addresses. If
the IPv6 configuration specifies IPv4 mapping, then the IPv4 client's address is
mapped into the IPv6 addressing space. An address appearing on an IPv4 interface
appears as an unmapped IPv4 address. Since the ACL qualification focuses on
qualifying addresses and all adapters within the host environment have unique
addresses, no additional interface information is required.
2-1
Chapter 2
Network Connection Adapter
For hosts that support hot-fail over network interfaces, the fail-over and reassignment
of network IP address to adapter MAC addresses is transparent to the application.
Example 2-1 Examples
Deny client connections originating from 192.0.2.254.
"ipACL" : [ { "permission" : "deny", "address" : "192.0.2.254" } ]
Explicitly allow all client connections. The first ACP by default qualifies all addresses.
The second ACL is never processed.
"ipACL" : [ { "permission" : "allow" },
{ "permission" : "deny", "address" : "192.0.2.254" } ]
Allow client connections originating from 127.0.0.1, but deny connection originating
from 192.0.2.254 appearing on an interface configured for IPv6 addressing.
"ipACL" : [ { "permission" : "allow", "address" : "127.0.0.1" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Allow client connections originating from and IPv6 loopback address (127.0.0.1
represented as ::1 in IPV6 addressing), allow client connections originating from the
unmapped IPv4 address 192.0.2.253, allow client connections originating from IPv6
address 2001:db8:85a3:0:0:8a2e:370:7334 and deny client connections originating
from mapped IPv4 address 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" } ]
2-2
Chapter 2
Network Connection Adapter
The first form retains compatibility with existing network port specifications where only
the portValue or portValueString is provided.
The second form assigns the networkSpec as a single value. This form still only defines
a single network specification and allows greater control and flexibility in identifying
network values and options.
The third form defines an array of networkSpec instances. It allows you to specify
different network configurations based upon either address or network interface.
Example 2-2 Example
With the following simplified host network interface configuration:
$/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
2-3
Chapter 2
Proxy Support
Form 1 - 4
Listens on port 9000 on all ANY address over ALL interfaces.
Form 5
Listens on port 9000 on address 192.0.2.254 only.
Form 6
Listens on port 9000 on the address associates with server1.
Form 7
Listens on port 9000 on the address associates with interface eth1 and accepts IPV4
address connections using the mapped IPV4.
Form 8
Listens on port 9000 on the address associates with interface lo, on port 9000
address 192.0.2.39 accepting only IPV4 addresses, and on port 9000 with addresses
associated with interface eth1 accepting onlyIPV6 addresses.
Most of the logic encapsulated within this class handles selecting network interface
adapter based on the network interface adapter’s identifying name or the address. The
interface can be searched for based on the requested address.
Specifying multiple adapters means that each ScaNetworkSpec resolves to only a subset
of adapters. Precedence processing allows the specification of ANY address and ALL
interfaces for the last ScaNetworkSpec as a pool specification when the platform
networking interfaces support mapping sub-set interface matches
Configuration
The initial configuration is simply declaring whether proxy detection should be enabled
or disabled. Typically, it is enabled by default though you can disable it in /config/
network/proxyDetails. The enable clause is similar to:
{
"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": [
2-4
Chapter 2
Proxy Support
]
}
}
}
Explicitly allow all client connections. The first ACP by default qualifies all addresses.
The second ACL is never processed.
"ipACL" : [ { "permission" : "allow" },
{ "permission" : "deny", "address" : "192.0.2.254" } ]
Allow client connections originating from 127.0.0.1, but deny connection originating
from 192.0.2.254 appearing on an interface configured for IPv6 addressing.
"ipACL" : [ { "permission" : "allow", "address" : "127.0.0.1" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Allow client connections originating from and IPv6 loopback address (127.0.0.1
represented as ::1 in IPV6 addressing), allow client connections originating from the
unmapped IPv4 address 192.0.2.253, allow client connections originating from IPv6
address 2001:db8:85a3:0:0:8a2e:370:7334 and deny client connections originating
from mapped IPv4 address 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" } ]
2-5
Chapter 2
Reverse Proxy Support
These values are used when connecting to the Service Manager and are required
when authentication is enabled.
Prerequisites
If you need to use a reverse proxy service with MA, use Nginx. Its a free, open-source,
high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy
server.Oracle GoldenGate MA is shipped with a utility to configure Nginx reverse
proxy.
Here are the prerequisites for configuring Nginx-based reverse proxy:
• Install Nginx: For Oracle Linux, the command to install Nginx is:
yum —y install nginx
For more information about installing Nginx, see Installing Nginx Reverse Proxy
• Check the JRE version to be JRE 8.
• Install Oracle GoldenGate MA.
• Create one or more active MA deployments.
2-6
Chapter 2
Reverse Proxy Support
Options:
Note:
If the deployments associated with the target Service Manager change,
the Nginx configuration file must be re-generated and reloaded.
2-7
3
Authentication and Authorization
The MA security and authorization model declares and defines how communication
security (confidentiality and Integrity) and Authorization (authentication and
permissions) are configured and implemented.
All the security and authorization configurations and services are common to MA-
based servers. These servers authenticate, authorize, and secure access to command
and control, monitoring, data conveyance, and information service interfaces for the
MA.
The MA defines a model and infrastructure for building service-aware applications.
This model is not a generalized model, but one targeted at the current and future
Oracle GoldenGate products that need to operate and integrate into global, cloud-
based deployment environments. Oracle GoldenGate server programs are
implemented using the MA infrastructure. All security and configuration
implementations provided by the MA are common services.
• Authentication (page 3-1)
Learn how you can use identity authentication.
• Authorization (page 3-3)
Learn how you can use authorization modes.
• Authorization for WebSockets (page 3-4)
Learn how you can use WebSocket authorization.
• Error Codes (page 3-5)
Review the MA HTTP error codes.
• Cross Site Request Forgery (page 3-5)
Learn how to avoid client-side attacks.
3.1 Authentication
Learn how you can use identity authentication.
The goal of the authenticated identity design is to establish identity authentication
between users, an MA server or application, and an MA server. The authentication
design relies on either the validity of a certificate or of a user credential (username and
passphrase pair).
The MA servers publish REST service interfaces that enable users and applications to
request services including operational control over one or more MA deployments,
service administration, status and performance monitoring. The following illustration
depicts the relationship between the user, application, server, and database.
3-1
Chapter 3
Authentication
Type of Description
Authentication
3-2
Chapter 3
Authorization
1. Configure the database client Oracle Wallet, see Creating the Wallet and Adding a
Master Key (page 8-1).
2. Configure UTL_HTTP with TLS (SSL) for client-side authentication, see Using
UTL_HTTP.
3.2 Authorization
Learn how you can use authorization modes.
3-3
Chapter 3
Authorization for WebSockets
User Privileges
You can configure these security roles for users from the Administration Server, see
Setting Up Secure or Non-Secure Deployments.
Note:
These are authorization privileges and are not directly related to
authentication.
3-4
Chapter 3
Error Codes
401 Unauthorized
Returned in all cases when the presented credential is poorly formed or missing when
required. This includes incorrectly spelled or unregistered user names when
presented as part of an authorization credential. It does not apply to authorization
resources (404 errors).
403 Forbidden
Returned in all cases when the presented credential is well-formed, but is invalid or
does not have sufficient privileges to grant access to the underlying resource.
The full list is found in the Internet Engineering Task Force RFC 7231 standard at:
https://tools.ietf.org/html/rfc7231
3-5
Chapter 3
Cross Site Request Forgery
user or client authorization object. The attack is limited to the actions and resources
published by the attacked website.
Mode of Attack
A general mode of attack is for a malicious agent to cause a user’s browser to be
redirected to a malicious website. The malicious resource at this malicious site causes
the user’s browser to download a client-side script (JavaScript). This downloas causes
the user’s browser to issue a compromised request against a protected website that
the user has obtained prior authorization. The browser issues the compromised
request delivering both the malicious script’s request payload along with any
authorization cookies that are automatically conveyed with the request.
For example, the malicious website’s script instructs the user’s browser to request the
addition of a new user with a high security clearance. The request is issued to the
protected website along with current browser user’s current authorization cookie. This
cookie is delivered automatically and transparently with the malicious request. The
request with the valid user authorization is forged by a script that is retrieved from
different redirected malicious site and issues a malicious request under the
authorization context of the current browser user.
Other than the HTTP headers that are automatically set by the browser, the only HTTP
headers allowed to be explicitly set are the CORS-safelisted request-header (simple
header):
Accept
Accept-Language
Content-Language
Content-Type
Last-Event-ID
DPR
Save-Data
Viewport-Width
Width
No event listeners can be registered with a XMLHttpRequestUpload object nor are any
ReadableStream instances allowed or used in the request.
3-6
Chapter 3
Cross Site Request Forgery
Referer HTTP header – Included if the request is from a referred parent page. (Note
that Referer is misspelled in the Remote Function Call).
If a proxy or reverse proxy is between the requesting client and the target website,
then the proxy or reverse proxy must be configured to include the following extended
HTTP headers:
X-Forwarded-Host – The original hostname the request to which the request was
targeted (the proxy or reverse proxy host). The X-Forwarded-Host should replace the
Origin header on propagated requests, but contain the same information.
4. If neither the Origin header nor the X-Forwarded-Host HTTP headers exist, the
request is presumed not to be originating as a Cross Site Request. This places a
reliance on the compliance of the browser to support Cross Site Scripting (XSS)
policies.
Note:
Because of the reliance on the XSS policy support in the client, malicious
CSRF requests from general purpose non-browser clients (like cURL,
Wget, Python, Perl, and eNetcat) can not be protected against.
3-7
4
Communication Security
Communication security is the confidentiality and integrity of the information sent over
communications channels, such as TCP/IP-based networks.
Topics:
• Certificate Access Control List (page 4-1)
Learn how you can refine communication security.
• Transport Layer Security Protocols and Ciphers (page 4-2)
Review the supported security protocols.
• TLS Certificate Revocation List Handling (page 4-4)
Learn how to configure a revocation list.
• HTTP Security and Cache Headers (page 4-7)
Review the supported security and cache headers.
4-1
Chapter 4
Transport Layer Security Protocols and Ciphers
The regex syntax follows the ECMAScript definition. Defining a regular expression as a
JSON node value requires that the any meta symbols used (like \s) have the
\character escaped. You should take care when specifying name regular expression
patterns to ensure that only the full match with the intended target pattern is matched.
In the syntax, the patterns only full match with the intended target pattern CN=AdminClnt
not CN=AdminClnt1, CN=AdminClntOther, CN=OtherAdminClnt, or CCN=OtherAdminClnt
because the match pattern includes delimiter specifications that bound the pattern.
These patterns assume a standard distinguished name format that allows no
whitespace between the keyname and the value. The CN = AdminClnt non-standard
pattern would not match.
Example 4-1 Allow All Certificates Example
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\
\s*.*))$|\\s$)", "permission" : "deny" } ]
Or
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\
\s*.*))$|\\s$)", "scope" : "subject-name", "permission" : "deny" } ]
4-2
Chapter 4
Transport Layer Security Protocols and Ciphers
Your testing must ensure that all clients used for a particular TLS protocol version
support the TLS version being tested because verification of client support for TLS
version support is required. Diagnostically, the server log should be reviewed for the
handshake protocol processing. The log should contain the protocol version being
negotiated. If the client does not support the protocol version that the server is
configured for, the server terminates the connection. You may not see an error
message or indication overtly sent to the client that a protocol version failed. The
failure may appear to the client as a network connection rejection or a certificate failure
depending on how the client is set to handle the exception.
Note:
TLS protocols below the 1.0 version should not be used because of
documented security defects.
4-3
Chapter 4
TLS Certificate Revocation List Handling
ECC ciphers are based on the algebraic structure of elliptic curves over finite fields.
The elliptic curve discrete logarithm problem (ECDLP) assumes that finding the
discrete logarithm of a random elliptic curve element with respect to a publicly known
base point is infeasible. The benefit of ECC ciphers is that generally the key sizes are
smaller compared to non-ECC cipher equivalents.
4-4
Chapter 4
TLS Certificate Revocation List Handling
peer detects that an error occurred during certificate validation, but may not be
informed of the specific cause.
The actual CRL consists of prolog and identifies the issuer of the CRL followed by zero
or more entries. Each entry identifies a specific certificate by serial number along with
security information relating to the date of revocation, the signature algorithm, and
finger-print information.
For example:
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=CA/L=Redwood Shores/O=Oracle Corp/OU=Corporate Security/
OU=Deployment Security/CN=Deploy1
Last Update: Feb 22 19:20:34 2017 GMT
Next Update: Mar 24 19:20:34 2017 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:7C:A0:BB:FB:6F:75:70:4B:B4:95:18:54:9C:1F:88:2E:A1:1B:EF:E4
4-5
Chapter 4
TLS Certificate Revocation List Handling
NFoXDTE3MDMyNDE5MjAzNFowFTATAgIQABcNMTcwMjIyMTkyMDM0WqAwMC4wHwYD
VR0jBBgwFoAUfKC7+291cEu0lRhUnB+ILqEb7+QwCwYDVR0UBAQCAhABMA0GCSqG
SIb3DQEBCwUAA4ICAQCm5XVik0kmbnnx3ZCUu5kcOiSZY4LW8VZymMyPb2G4pN0h
D676OHjAyby8h2EVNecguF6PagrhWOAwbd8Dj2/eClQc8ETlKEhWIwBgGd3iaC01
K8xihbY0Ms7D9oqwu7RmDoWMebIyXGWsR5lpxb+77B5/QOIfEfoqfNOU3mLii94V
BCxnFC63cSnV4uHurMOj0CBBqeBqW5AoNVqQhlFp3yevPg/A0jKr0nrFFin27ATd
522LEAZAwAgyOVAzwLmGuXcZb6ZJZVT1NcgnCPb6kTyuLLXBUt5CLGVszpdSUABT
320d5jifYZfZqmAcBiSq86yM1oXtgyAvUFz2r3iRSaW3y5ZsAzrjPd2p1Q9fPEeM
eDNlCWWKCJIZWKGTf5nunfFKMCFjJFrUa73g7Ax5CR9IpjmHkgv3JY4xZe4QKEW7
VZzIZEn+HXhtmglna3b0P2q468ALDKuSbfVgBjQP72W+yK8dZ7w2t9HA6jBxOyu6
FtxyhpAy41mZLDN6L2N37A1wiVIPjykT/RcYSVZljSNkuum2dFZAmxxlF++9LHfU
afb069+pMRSJ/B0kgX2Fuh2PixsNwqPC6qVuoqe+NBahuBak8jJaZS2FFL5za95A
E73xPX5lFDyorbdOy0FT9CRaT6FWtjNl+e+5QC0m7rpX1fV1G2CN8iQ25SrIsw==
-----END X509 CRL-----
Typically, the CRL in compact form only includes the contents between the -----BEGIN
X509 CRL----- and -----END X509 CRL----- delimiters. All other data outside these
delimiters is ignored. You can embed a textual representation of the CRL in the CRL
file without affecting the function of the CRL.
The use of CRLs is configured for each MA server individually The CRL configuration
is composed of two properties:
/config/security/common/crlEnabled
Enables or disables CRL processing.
If, however, /config/security/common/crlEnabled is enabled (true), then the /config/
security/common/crlStore property must refer to a valid and well formed CRL.
/config/security/common/crlStore
When CRL processing is disabled (false), the remote participant's certificate is not
checked against a CRL. When this is the case, you don’t need to set the /config/
security/common/crlStore property.
A valid and well formed CRL file is either a PEM encoded CRL file that conforms to the
RFC2380 - Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile or an empty file.
The following is a sample excerpt declaring and defining CRL processing for a secured
server.
{
"config" : {
"security: {
"common" : {
"crlEnabled" : true,
"crlStore" : "file:/scratch/Tests.SCA/unittests/etc/ssl/RootCA/CAs/
Deploy1/CRLs/empty_CRL.pem"
}
}
}
}
The CRL file may be updated or replace by other, presumably more current, versions
while the server is running. Replacing the CRL file causes the next request CRL
lookup to use the newly updated file.
Regardless of how the /config/security/common/crlEnabled property is set, CRL
processing is disabled if the general security configuration of the server is disabled.
For example, the value of the /config/security property is false).
4-6
Chapter 4
HTTP Security and Cache Headers
One other configure setting that indirectly effects CRL processing is the /config/
securityDetails/network/common/authMode property. This property controls whether the
server requires the client to authenticate using a certificate or whether the server
accepts optionally presented certificate or whether the server will ignore any presented
client certificates. If a certificate is not required, not presented, or ignored by the
server, then CRL processing is not used.
Security Headers
The security headers that can be issue are:
Content-Security-Policy (CSP)
The CSP is included as a header in server responses and defines how the client
should handle the content sent by the server.
The default CSP header statement is:
Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'
• unsafe-eval:
• unsafe-inline:
X-Frame-Options
The X-Frame-Options is included as headers in server responses and signals the
client whether or not a user-agent should be allowed to render the content in an
<frame>, <iframe>, or <object>. Websites use<frame> and <iframe> to create mash-ups
or to embed part of one site. However, exposes the embedded site to Clickjack
attacks. This directive disallows the client from rendering the content as embedded
unless the content is from the same site (origin).
The default X-Frame-Options statement is:
X-Frame-Options: SAMEORIGIN
X-XSS-Protection
The X-XSS-Protection is included as a header in server responses and configure the
user-agent's built in XSS (Cross-Site-Security)protection. The options are to enable,
disable and can be combined with block and report.
4-7
Chapter 4
HTTP Security and Cache Headers
• mode=block: Block the server's response if the content script was injected as user
input.
• mode-report=url: Report the potential XSS attack to the designated URL. Only
supported by Chrome and WebKit.
X-Content-Type-Options
The default X-Content-Type-Options statement is:
X-Content-Type-Options: nosniff
Cache Headers
The supported cache headers are:
Cache-Control
The default Cache-Control statement is:
Cache-Control: no-cache, no-store, must-revalidate
Pragma
The default Pragma statement is:
Pragma: no-cache
Expires
The default Expires statement is:
Expires: 0
4-8
5
Server and Deployment Identities
You must uniquely identify MA servers and deployments using schemes.
In a Common-Named Multiple Server and Deployment configuration that has more
than one MA deployment within an environment access by a common name, each
server and deployment must be uniquely identifiable. This identity allows coordination
services, peers servers, and orchestration ecosystems to differentiate one deployment
and server from another when necessary.
Topics:
• Using a Universally Unique IDs Scheme (page 5-1)
Universally Unique IDs are synonymous with Globally Unique IDs (UUID/GUID).
• Using a Deterministically Calculated Unique ID Scheme (page 5-1)
A deployment’s identity can be deterministically calculated and be unique within a
local scope.
• Using an Explicit Naming Scheme (page 5-2)
You can use explicit naming to avoid the problem of guaranteed uniqueness to
administrators.
• Creating Server and Deployment IDs (page 5-2)
A serverID and deploymentID is required for each of your servers and deployments.
Deployment and server UUIDs are generated by default if you don’t define them.
UUID can be used to identify distinct deployments and even specific servers within a
deployment. The primary issue with UUIDs is that once generated, they can not be
regenerated. If the UUID value is lost, there is no way of deterministically recreating it.
This is an issue if the UUID is used in a distributed fashion and it is held as reference
to a specific deployment. If that deployment loses the value of it originally generated
UUID, there is no way of regenerating the UUID. You must take care when
safeguarding the UUID.
5-1
Chapter 5
Using an Explicit Naming Scheme
This would create a unique ID based on a combination of hardware and file system
signatures. For example, the calculated ID could be generated based on the MAC
Address of the network interface and the real absolute file system paths that make-up
the deployment. Any relocation of the deployment within the file system invalidates the
deterministic regeneration of the ID, as would any change in the network interface.
serverID
Each servers generates a unique ID during first start if it finds an absent or null server
ID. The server ID is then used to generate a short unique label that can be used as
name or tag in cases where the 3- character UUID is to long. Both the serverID and
short name are expected to be globally unique. It can be used to identify a server
without prefixing it with a deployment. The serverID is held in each server’s local
configuration context and only accessible by the owning server.
You can use the serverID to limit certain request or action targets to only the server.
For example, by including the serverID in server generated payloads, the server can
validated that it was the originator of the payload by comparing the presented serverID
with the held serverID.
"config" : {
"serverID": "96bc6cab-abb8-4a05-aeff-6d0d385262af"
"serverIDShortLabel": "lrxsq6u4SgWu/20NOFJirw"
}
deploymentID
The first server starting within a deployment generates a unique ID if it finds an absent
or null deployment ID. The deploymentID is a a containment ID and serves to identify a
group of related servers. The deploymentID is held in the deployment global
configuration context and is accessible by all servers within that deployment.
The deploymentID can be used to limit server requests or actions to only the servers
within the deployment. For example, by including the short label version of the
serverID in UDP/UDT data, a server can filter and qualify only the information that
originated from a server within its own deployment.
5-2
Chapter 5
Creating Server and Deployment IDs
"global": {
"deploymentID": "f1df4a18-d0a8-4ba1-9ad0-18da9458baef"
}
affiliateDeploymentIDs
You can update the global configuration using either a bootstrap configuration file or
the command-line overrides, for example:
$ bin/adminsrvr '{"global": { "affiliateDeploymentIDs":
["deafa2f6-6ee7-48b1-862a-97a9b6d5b9df"]}}'
5-3
6
Securing Deployments
You can choose to set up a secure or non-secure deployment. A secure deployment
involves making RESTful API calls and conveying trail data between the Distribution
Server and Receiver Server, over SSL/TLS. You can use your existing wallets and
certificates, or you can create new ones.
The instructions for securing deployments is in Setting Up Secure and Non-Secure
Deployments in Using the Oracle GoldenGate Microservices Architecture.
6-1
Part II
Securing Oracle GoldenGate
Use this part to secure your CA and MA environments.
Topics:
• Overview of Security Options (page 7-1)
You can use these security features to protect your Oracle GoldenGate
environment and the data that is being processed.
• Encrypting Data with the Master Key and Wallet Method (page 8-1)
To use this method of data encryption, you create a master key wallet and add a
master key to the wallet. This method works as follows, depending on whether the
data is encrypted in the trails or across TCP/IP:
• Encrypting Data with the ENCKEYS Method (page 9-1)
To use this method of data encryption, you configure Oracle GoldenGate to
generate an encryption key and store the key in a local ENCKEYS file.
• Managing Identities in a Credential Store (page 10-1)
Learn how to use an Oracle GoldenGate credential store to maintain encrypted
database passwords and user IDs and associate them with an alias.
• Encrypting a Password in a Command or Parameter File (page 11-1)
Learn how to encrypt a database password that is to be specified in a command or
parameter file.
• Populating an ENCKEYS File with Encryption Keys (page 12-1)
Learn how to use an ENCKEYS file.
• Configuring GGSCI Command Security (page 13-1)
You can establish command security for Oracle GoldenGate to control which users
have access to which Oracle GoldenGate functions.
• Using Target System Connection Initiation (page 14-1)
Learn how to initiate passive and alias connections between your source and
target systems.
• Securing Manager (page 15-1)
You can use the Manager parameter, ACCESSRULE, to set security access rules for
Manager. It allows GGSCI access from a remote host if you are using passive
Extract or Director.
7
Overview of Security Options
You can use these security features to protect your Oracle GoldenGate environment
and the data that is being processed.
7-1
Chapter 7
1 Advanced Encryption Standard (AES) is a symmetric-key encryption standard that is used by governments and other
organizations that require a high degree of data security. It offers three 128-bit block-ciphers: a 128-bit key cipher, a 192-bit key
cipher, and a 256-bit key cipher. To use AES for any database other than Oracle on a 32-bit platform, the path to the lib sub-
directory of the Oracle GoldenGate installation directory must be set with the library path variable. For different platforms the
library path variable is different. For Linux it is LD_LIBRARY_PATH. For IBM i and AIX it is LIBPATH, SHLIB_PATH variable for
Solaris and the PATH variable on Windows. Not required for 64-bit platforms.
2 Blowfish encryption: A keyed symmetric-block cipher. The Oracle GoldenGate implementation of Blowfish has a 64-bit block
size with a variable-length key size from 32 bits to 256 bits.
7-2
8
Encrypting Data with the Master Key and
Wallet Method
To use this method of data encryption, you create a master key wallet and add a
master key to the wallet. This method works as follows, depending on whether the
data is encrypted in the trails or across TCP/IP:
• Each time Oracle GoldenGate creates a trail file, it generates a new encryption
key automatically. This encryption key encrypts the trail contents. The master key
encrypts the encryption key. This process of encrypting encryption keys is known
as key wrap and is described in standard ANS X9.102 from American Standards
Committee.
• To encrypt data across the network, Oracle GoldenGate generates a session key
using a cryptographic function based on the master key.
Oracle GoldenGate uses an auto-login wallet (file extension .sso), meaning that it is an
obfuscated container that does not require human intervention to supply the necessary
passwords.
Encrypting data with a master key and wallet is not supported on the DB2 for i, DB2
z/OS, or NonStop platforms.
Topics:
• Creating the Wallet and Adding a Master Key (page 8-1)
• Specifying Encryption Parameters in the Parameter File (page 8-2)
• Renewing the Master Key (page 8-3)
• Deleting Stale Master Keys (page 8-4)
WALLETLOCATION directory_path
2. Create a master-key wallet with the CREATE WALLET command in GGSCI.
8-1
Chapter 8
Specifying Encryption Parameters in the Parameter File
3. Open the wallet after it has been created with the OPEN WALLET command i.
4. Add a master key to the wallet with the ADD MASTERKEY command.
5. Issue the INFO MASTERKEY command to confirm that the key you added is the
current version. In a new installation, the version should be 1.
6. Issue the INFO MASTERKEY command with the VERSION option, where the version is
the current version number. Record the version number and the AES hash value
of that version.
INFO MASTERKEY VERSION version
7. Copy the wallet to all of the other Oracle GoldenGate systems.
8. Issue the INFO MASTERKEY command with the VERSION option on each system to
which you copied the wallet, where the version is the version number that you
recorded. For each wallet, make certain the Status is Current and compare the
AES hash value with the one that you originally recorded. All wallets must show
identical key versions and hash values.
INFO MASTERKEY VERSION version
8-2
Chapter 8
Renewing the Master Key
• BLOWFISH uses Blowfish encryption with a 64-bit block size and a variable-
length key size from 32 bits to 128 bits. Use AES if supported for the platform.
Use BLOWFISH for backward compatibility with earlier Oracle GoldenGate
versions, and for DB2 z/OS and DB2 for i. AES is not supported on those
platforms.
2. Use the DECRYPTTRAIL parameter for a data pump if you want trail data to be
decrypted before it is written to the output trail. Otherwise, the data pump
automatically decrypts it, if processing is required, and then reencrypts it before
writing to the output trail. (Replicat decrypts the data automatically without any
parameter input.)
DECRYPTTRAIL
Note:
You can explicitly decrypt incoming trail data and then re-encrypt it again for
any output trails or files. First, enter DECRYPTTRAIL to decrypt the data, and
then enter ENCRYPTTRAIL and its output trail specifications. DECRYPTTRAIL must
precede ENCRYPTTRAIL. Explicit decryption and re-encryption enables you to
vary the AES algorithm from trail to trail, if desired. For example, you can use
AES 128 to encrypt a local trail and AES 256 to encrypt a remote trail.
Alternatively, you can use the master key and wallet method to encrypt from
one process to a second process, and then use the ENCKEYS method to
encrypt from the second process to the third process.
Unless the wallet is maintained centrally on shared storage (as a shared wallet), the
updated wallet must be copied to all of the other systems in the Oracle GoldenGate
configuration that use that wallet. To do so, the Oracle GoldenGate must be stopped.
This procedure includes steps for performing those tasks in the correct order.
1. Stop Extract.
STOP EXTRACT group
2. On the target systems, issue the following command for each Replicat until it
returns At EOF.
SEND REPLICAT group STATUS
3. On the source system, stop the data pumps.
STOP EXTRACT group
4. On the target systems, stop the Replicat groups.
8-3
Chapter 8
Deleting Stale Master Keys
Note:
If you are using a shared wallet, go to step 12 (page 8-4). If you are
using a wallet on each system, continue to the next step.
9. On the source system, issue the following command, where version is the new
version of the master key. Make a record of the hash value.
INFO MASTERKEY VERSION version
10. Copy the updated wallet from the source system to the same location as the old
wallet on all of the target systems.
11. On each target, issue the following command, where version is the new version
number of the master key. For each wallet, make certain the Status is Current and
compare the new hash value with the one that you originally recorded. All wallets
must show identical key versions and hash values.
INFO MASTERKEY VERSION version
12. Restart Extract.
8-4
Chapter 8
Deleting Stale Master Keys
Note:
For Oracle GoldenGate deployments using a shared wallet, the older
versions of the master key should be retained after the master key is
renewed until all processes are using the newest version. The time to wait
depends on the topology, latency, and data load of the deployment. A
minimum wait of 24 hours is a conservative estimate, but you may need to
perform testing to determine how long it takes for all processes to start using
a new key. To determine whether all of the processes are using the newest
version, view the report file of each Extract immediately after renewing the
master key to confirm the last SCN that was mined with the old key. Then,
monitor the Replicat report files to verify that this SCN was applied by all
Replicat groups. At this point, you can delete the older versions of the master
key.
Note:
DELETE MASTERKEY marks the key versions for deletion but does not
actually delete them.
8-5
Chapter 8
Deleting Stale Master Keys
4. Review the messages returned by the DELETE MASTERKEY command to ensure that
the correct versions were marked for deletion. To unmark any version that was
marked erroneously, use the UNDELETE MASTERKEY VERSION version command before
proceeding with these steps. If desired, you can confirm the marked deletions with
the INFO MASTERKEY command.
5. When you are satisfied that the correct versions are marked for deletion, issue the
following command to purge them from the wallet. This is a permanent deletion
and cannot be undone.
PURGE WALLET
Next steps:
• If the wallet resides on shared storage, you are done with these steps.
• If there is a wallet on each system and you cannot stop the Oracle
GoldenGate processes, repeat the preceding steps on each Oracle
GoldenGate system.
• If there is a wallet on each system and you can stop the Oracle GoldenGate
processes, continue with these steps to stop the processes and copy the
wallet to the other systems in the correct order.
6. Stop Extract.
STOP EXTRACT group
7. In GGSCI, issue the following command for each data pump Extract until each
returns At EOF, indicating that all of the data in the local trail has been processed.
SEND EXTRACT group STATUS
8. Stop the data pumps.
STOP EXTRACT group
9. On the target systems, issue the following command for each Replicat until it
returns At EOF.
SEND REPLICAT group STATUS
10. Stop the Replicat groups.
8-6
9
Encrypting Data with the ENCKEYS
Method
To use this method of data encryption, you configure Oracle GoldenGate to generate
an encryption key and store the key in a local ENCKEYS file.
This method makes use of a permanent key that can only be changed by regenerating
the algorithm, see Populating an ENCKEYS File with Encryption Keys (page 12-1).
The ENCKEYS file must be secured through the normal method of assigning file
permissions in the operating system.
This procedure generates an AES encryption key and provides instructions for storing
it in the ENCKEYS file.
Topics:
• Encrypting the Data with the ENCKEYS Method (page 9-1)
• Decrypting the Data with the ENCKEYS Method (page 9-2)
• Examples of Data Encryption using the ENCKEYS Method (page 9-3)
9-1
Chapter 9
Decrypting the Data with the ENCKEYS Method
Note:
RMTHOST is used unless the Extract is in a passive configuration.
3. If using a static Collector with data encrypted over TCP/IP, append the following
parameters in the Collector startup string:
-KEYNAME keyname
-ENCRYPT algorithm
The specified key name and algorithm must match those specified with the KEYNAME
and ENCRYPT options of RMTHOST.
9-2
Chapter 9
Examples of Data Encryption using the ENCKEYS Method
Note:
The algorithm specified with ENCRYPTTRAIL can vary from trail to trail. For
example, you can use AES 128 to encrypt a local trail and AES 256 to
encrypt a remote trail.
9-3
Chapter 9
Examples of Data Encryption using the ENCKEYS Method
In this example, the encrypted data must be decrypted so that data pump 1pump can
perform work on it. Therefore, the DECRYPTTRAIL parameter is used in the parameter file
of the data pump. To re-encrypt the data for output, the ENCRYPTTRAIL parameter must
be used after DECRYPTTRAIL but before the output trail specification(s). If the data pump
did not have to perform work on the data, the DECRYPTTRAIL and ENCRYPTTRAIL
parameters could have been omitted to retain encryption all the way to Replicat.
Example 9-1 Extract Parameter File
EXTRACT capt
USERIDALIAS ogg
DISCARDFILE /ogg/capt.dsc, PURGE
-- Do not encrypt this trail.
EXTTRAIL /ogg/dirdat/bb
TABLE SALES.*;
-- Encrypt this trail with AES-192.
ENCRYPTTRAIL AES192
EXTTRAIL /ogg/dirdat/aa
TABLE FIN.*;
9-4
10
Managing Identities in a Credential Store
Learn how to use an Oracle GoldenGate credential store to maintain encrypted
database passwords and user IDs and associate them with an alias.
It is the alias, not the actual user ID or password, that is specified in a command or
parameter file, and no user input of an encryption key is required. The credential store
is implemented as an autologin wallet within the Oracle Credential Store Framework
(CSF).
Another benefit of using a credential store is that multiple installations of Oracle
GoldenGate can use the same one, while retaining control over their local credentials.
You can partition the credential store into logical containers known as domains, for
example, one domain per installation of Oracle GoldenGate. Domains enable you to
develop one set of aliases (for example ext for Extract, rep for Replicat) and then
assign different local credentials to those aliases in each domain. For example,
credentials for user ogg1 can be stored as ALIAS ext under DOMAIN system1, while
credentials for user ogg2 can be stored as ALIAS ext under DOMAIN system2.
The credential store security feature is not supported on the DB2 for i, DB2 z/OS, and
NonStop platforms. For those platforms and any other supported platforms, see
Encrypting a Password in a Command or Parameter File (page 11-1).
Topics:
• Creating and Populating the Credential Store (page 10-1)
• Specifying the Alias in a Parameter File or Command (page 10-2)
Where:
• userid is the user name. Only one instance of a user name can exist in the
credential store unless the ALIAS or DOMAIN option is used.
10-1
Chapter 10
Specifying the Alias in a Parameter File or Command
• password is the password. The password is echoed (not obfuscated) when this
option is used. For security reasons, it is recommended that you omit this
option and allow the command to prompt for the password, so that it is
obfuscated as it is entered.
• alias is an alias for the user name. The alias substitutes for the credential in
parameters and commands where a login credential is required. If the ALIAS
option is omitted, the alias defaults to the user name. If you do not want user
names in parameters or command input, use ALIAS and specify a different
name from that of the user.
• domain is the domain that is to contain the specified alias. The default domain
is Oracle GoldenGate.
For more information about the commands used in this procedure and additional
credential store commands, see Reference for Oracle GoldenGate.
1 Syntax elements required for USERIDALIAS vary by database type. See Reference for Oracle
GoldenGate for more information.
10-2
11
Encrypting a Password in a Command or
Parameter File
Learn how to encrypt a database password that is to be specified in a command or
parameter file.
This method takes a clear-text password as input and produces an obfuscated
password string and a lookup key, both of which can then be used in the command or
parameter file. This encryption method supports all of the databases that require a
login for an Oracle GoldenGate process to access the database.
Depending on the database, you may be able to use a credential store as an
alternative to this method. See Managing Identities in a Credential Store (page 10-1).
Topics:
• Encrypting the Password (page 11-1)
• Specifying the Encrypted Password in a Parameter File or Command
(page 11-2)
Where:
• password is the clear-text login password. Do not enclose the password within
quotes. If the password is case-sensitive, type it that way.
• algorithm specifies the encryption algorithm to use:
– AES128 uses the AES-128 cipher, which has a key size of 128 bits.
– AES192 uses the AES-192 cipher, which has a key size of 192 bits.
– AES256 uses the AES-256 cipher, which has a key size of 256 bits.
– BLOWFISH uses Blowfish encryption with a 64-bit block size and a variable-
length key size from 32 bits to 128 bits. Use AES if supported for the
platform. Use BLOWFISH for backward compatibility with earlier Oracle
GoldenGate versions, and for DB2 z/OS and DB2 for i. AES is not
supported on those platforms.
• ENCRYPTKEY key_name specifies the logical name of a user-created encryption
key in the ENCKEYS lookup file. The key name is used to look up the actual key
in the ENCKEYS file. Using a user-defined key and an ENCKEYS file is required for
AES encryption. To create a key and ENCKEYS file, see Populating an
ENCKEYS File with Encryption Keys (page 12-1).
11-1
Chapter 11
Specifying the Encrypted Password in a Parameter File or Command
11-2
Chapter 11
Specifying the Encrypted Password in a Parameter File or Command
1 Syntax elements required for USERID vary by database type. See Reference for Oracle GoldenGate for
more information.
2 This is the shared secret.
Where:
• user is the database user name for the Oracle GoldenGate process or (Oracle
only) a host string. For Oracle ASM, the user must be SYS.
• password is the encrypted password that is copied from the ENCRYPT PASSWORD
command results.
• algorithm specifies the encryption algorithm that was used to encrypt the
password: AES128, AES192, AES256, or BLOWFISH. AES128 is the default if the default
key is used and no algorithm is specified.
• ENCRYPTKEY keyname specifies the logical name of a user-created encryption key in
the ENCKEYS lookup file. Use if ENCRYPT PASSWORD was used with the KEYNAME keyname
option.
• ENCRYPTKEY DEFAULT directs Oracle GoldenGate to use a random key. Use if ENCRYPT
PASSWORD was used with the KEYNAME DEFAULT option.
11-3
Chapter 11
Specifying the Encrypted Password in a Parameter File or Command
11-4
12
Populating an ENCKEYS File with
Encryption Keys
Learn how to use an ENCKEYS file.
You must generate and store encryption keys when using the security features:
• ENCRYPTTRAIL (see Encrypting the Data with the ENCKEYS Method (page 9-1))
Where:
• key_length is the encryption key length, up to 256 bits (32 bytes).
Example:
KEYGEN 128 4
12-1
Chapter 12
Creating and Populating the ENCKEYS Lookup File
3. Save the file as the name ENCKEYS in all upper case letters, without an extension, in
the Oracle GoldenGate installation directory.
4. Copy the ENCKEYS file to the Oracle GoldenGate installation directory on every
system. The key names and values in all of the ENCKEYS files must be identical, or
else the data exchange will fail and Extract and Collector will abort with the
following message:
GGS error 118 – TCP/IP Server with invalid data.
12-2
13
Configuring GGSCI Command Security
You can establish command security for Oracle GoldenGate to control which users
have access to which Oracle GoldenGate functions.
Note:
The GGSCI program is only available in the Oracle GoldenGate CA.
For example, you can allow certain users to issue INFO and STATUS commands, while
preventing their use of START and STOP commands. Security levels are defined by the
operating system's user groups.
To implement security for Oracle GoldenGate commands, you create a CMDSEC file in
the Oracle GoldenGate directory. Without this file, access to all Oracle GoldenGate
commands is granted to all users.
Note:
The security of the GGSCI program is controlled by the security controls of the
operating system.
Topics:
• Setting Up Command Security (page 13-1)
• Securing the CMDSEC File (page 13-3)
Where:
• command_name is a GGSCI command name or a wildcard, for example START or
STOP or *.
13-1
Chapter 13
Setting Up Command Security
3. Save the file as CMDSEC (using upper case letters on a UNIX system) in the Oracle
GoldenGate home directory.
The following example illustrates the correct implementation of a CMDSEC file on a UNIX
system.
Except for the preceding rule, all users in dpt1 are granted
STATUS * dpt1 * YES
all STATUS commands.
The following incorrect example illustrates what to avoid when creating a CMDSEC file.
13-2
Chapter 13
Securing the CMDSEC File
The order of the entries in Table 13-2 (page 13-2) causes a logical error. The first rule
(line 1) denies all STOP commands to all members of group dpt2. The second rule (line
2) grants all STOP commands to user Chen. However, because Chen is a member of the
dpt2 group, he has been denied access to all STOP commands by the second rule, even
though he is supposed to have permission to issue them.
The proper way to configure this security rule is to set the user-specific rule before the
more general rule(s). Thus, to correct the error, you would reverse the order of the two
STOP rules.
13-3
14
Using Target System Connection Initiation
Learn how to initiate passive and alias connections between your source and target
systems.
When a target system resides inside a trusted intranet zone, initiating connections
from the source system (the standard Oracle GoldenGate method) may violate
security policies if the source system is in a less trusted zone. It also may violate
security policies if a system in a less trusted zone contains information about the ports
or IP address of a system in the trusted zone, such as that normally found in an Oracle
GoldenGate Extract parameter file.
In this kind of intranet configuration, you can use a passive-alias Extract
configuration. Connections are initiated from the target system inside the trusted zone
by an alias Extract group, which acts as an alias for a regular Extract group on the
source system, known in this case as the passive Extract. Once a connection
between the two systems is established, data is processed and transferred across the
network by the passive Extract group in the usual way.
1. An Oracle GoldenGate user starts the alias Extract on the trusted system, or an
AUTOSTART or AUTORESTART parameter causes it to start.
2. GGSCI on the trusted system sends a message to Manager on the less trusted
system to start the associated passive Extract. The host name or IP address and
port number of the Manager on the trusted system are sent to the less trusted
system.
3. On the less trusted system, Manager starts the passive Extract, and the passive
Extract finds an open port (according to rules in the DYNAMICPORTLIST Manager
parameter) and listens on that port.
14-1
Chapter 14
Configuring the Passive Extract Group
4. The Manager on the less trusted system returns that port to GGSCI on the trusted
system.
5. GGSCI on the trusted system sends a request to the Manager on that system to
start a Collector process on that system.
6. The target Manager starts the Collector process and passes it the port number
where Extract is listening on the less trusted system.
7. Collector on the trusted system opens a connection to the passive Extract on the
less trusted system.
8. Data is sent across the network from the passive Extract to the Collector on the
target and is written to the trail in the usual manner for processing by Replicat.
Topics:
• Configuring the Passive Extract Group (page 14-2)
• Configuring the Alias Extract Group (page 14-3)
• Starting and Stopping the Passive and Alias Processes (page 14-3)
• Managing Extraction Activities (page 14-4)
• Other Considerations when using Passive-Alias Extract (page 14-4)
Note:
The passive Extract group is only available in the Oracle GoldenGate CA.
To create an Extract group in passive mode, use the standard ADD EXTRACT command
and options, but add the PASSIVE keyword in any location relative to other command
options. Examples:
ADD EXTRACT fin, TRANLOG, BEGIN NOW, PASSIVE, DESC 'passive Extract'
ADD EXTRACT fin, PASSIVE, TRANLOG, BEGIN NOW, DESC 'passive Extract'
To configure parameters for the passive Extract group, create a parameter file in the
normal manner, except:
• Exclude the RMTHOST parameter, which normally would specify the host and port
information for the target Manager.
14-2
Chapter 14
Configuring the Alias Extract Group
Note:
The alias Extract group is only available in the Oracle GoldenGate CA.
To create an Extract group in alias mode, use the ADD EXTRACT command without any
other options except the following:
ADD EXTRACT group
, RMTHOST {host_name | IP_address}
, MGRPORT port
[, RMTNAME name]
[, DESC 'description']
The RMTHOST specification identifies this group as an alias Extract, and the information
is written to the checkpoint file. The host_name and IP_address options specify the name
or IP address of the source system. MGRPORT specifies the port on the source system
where Manager is running.
The alias Extract name can be the same as that of the passive Extract, or it can be
different. If the names are different, use the optional RMTNAME specification to specify the
name of the passive Extract. If RMTNAME is not used, Oracle GoldenGate expects the
names to be identical and writes the name to the checkpoint file of the alias Extract for
use when establishing the connection.
Error handling for TCP/IP connections is guided by the TCPERRS file on the target
system. It is recommended that you set the response values for the errors in this file to
RETRY. The default is ABEND. This file also provides options for setting the number of
retries and the delay between attempts. For more information about error handling for
TCP/IP and the TCPERRS file, see Administering Oracle GoldenGate.
14-3
Chapter 14
Managing Extraction Activities
or,
STOP EXTRACT alias_group_name
The command is sent to the source system to start or stop the passive Extract group.
Do not issue these commands directly against the passive Extract group. You can
issue a KILL EXTRACT command directly for the passive Extract group.
When using the Manager parameters AUTOSTART and AUTORESTART to automatically start
or restart processes, use them on the target system, not the source system. The alias
Extract is started first and then the start command is sent to the passive Extract.
14-4
15
Securing Manager
You can use the Manager parameter, ACCESSRULE, to set security access rules for
Manager. It allows GGSCI access from a remote host if you are using passive Extract
or Director.
The ACCESSRULE parameter controls connection access to the Manager process and the
processes under its control. You can establish multiple rules by specifying multiple
ACCESSRULE statements in the parameter file and control their priority. To establish
priority, you can either list the rules in order from most important to least important, or
you can explicitly set the priority of each rule with the PRI option.
You must specify one of the following options:
IPADDR, login_ID, or PROGRAM
For example, the following access rules have been assigned explicit priority levels
through the PRI option. These rules allow any user to access the Collector process
(the SERVER program), and in addition, allow the IP address 122.11.12.13 to access
GGSCI commands. Access to all other Oracle GoldenGate programs is denied.
ACCESSRULE, PROG *, DENY, PRI 99
ACCESSRULE, PROG SERVER, ALLOW, PRI 1
ACCESSRULE, PROG GGSCI, IPADDR 122.11.12.13, PRI 1
Another example, the following access rule grants access to all programs to the user
JOHN and designates an encryption key to decrypt the password. If the password
provided with PASSWORD matches the one in the ENCKEYS lookup file, connection is
granted.
ACCESSRULE, PROG *, USER JOHN, PASSWORD OCEAN1, ENCRYPTKEY lookup1
For information about the ACCESSRULE options, see Reference for Oracle GoldenGate
15-1