GoldenGate Security Configuration

GoldenGate Security Configuration

When implementing GoldenGate, security is often ignored. However, as a complete GoldenGate system, basic security settings are still necessary, such as password encryption. GoldenGate has the following five Security Options:

? Password Encryption)

? Trail File Encryption)

? Network Transmission Encryption (TCP/IP Encryption)

? Command Authentication)

? Trusted Connection)

Here we will talk about the first three security options. The remaining two items will be discussed in future topics.

Password Encryption, Trail file encryption, and network transmission encryption all support AES-128, AES-192 and AES-256 encryption algorithms, password encryption and network transmission encryption also support Blowfish encryption algorithms, trail file encryption also supports byte replacement encryption.

Password Encryption

Password Encryption refers to the encryption of the password of the database account, so that the password of the database account will not appear in plaintext in the configuration file, thus ensuring the security of the account. Because the account assigned to GoldenGate has a lot of permissions, it is also necessary to protect it. You must generate a key file before encrypting the password. In fact, this step is not necessary. You can use the default GoldenGate key for encryption, but there are many restrictions on using the default key:

1. Only Blowfish can be used for encryption.

2. Only bytes can be replaced for Trail file encryption.

3. Network Transmission encryption is not available

Therefore, you usually need to generate your own key file. Two steps are required to generate a key file:

1. Use the keygen tool to generate a key.

2. Create a file named ENCKEYS in the installation directory of GoldenGate and store the generated key in the file.

The procedure is as follows:

# Generate a key. 128 indicates that the length of the generated key is 128 bits, and 3 indicates that three keys are generated. [Ggate @ ogg_s current] $./keygen 128 3 0x345ceb2da1_dc2f75b0514484fcab42   0xD8A1B350AF392A75C52EE540B169B267   0x7CE77B73BD5F783A15AD783DDFD6B80C   # Store the key in a file with one key per line [Ggate @ ogg_s current] $ cat ENCKEYS # Key-name Key-value PASSWDKEY 0x345ceb2da1_dc2f75b0514484fcab42 TRAILKEY 0xD8A1B350AF392A75C52EE540B169B267 TCPIPKEY 0x7CE77B73BD5F783A15AD783DDFD6B80C

After the key file is configured, We can encrypt the password of the database account.

GGSCI (ogg_s) 1> encrypt password OGG123 ENCRYPTKEY PASSWDKEY Encrypted password: Encrypted Algorithm used: AES128

The operation must be performed in the GGSCI console, and PASSWDKEY is the key name we Just configured. The default encryption algorithm used here is the AES-128. If you use the default GoldenGate key, the encryption algorithm is Blowfish:

GGSCI (ogg_s) 2> encrypt password OGG123 ENCRYPTKEY DEFAULT Using default key...   Encrypted password: aacaaaaaaaaagacarardmendjhiifg Algorithm used: BLOWFISH

We can try DBLOGIN to verify that the password that has been encrypted can be used properly:

GGSCI (ogg_s) 3> dblogin userid ogg, PASSWORD encrypted, ENCRYPTKEY PASSWDKEY Successfully logged into database.

After the OGG account successfully connects to the database, it indicates that the password with a password can work properly. Next, modify the Extract or Replicat configuration file. You can modify the content of the USERID line as follows:

... SETENV (Oracle_HOME =/u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SID = ggtest) -- Userid ogg, PASSWORD OGG123 Userid ogg, PASSWORD secret, ENCRYPTKEY PASSWDKEY EXTTRAIL/data/ggate/dirext/ggtest/ea ...

After the Replicat process obtained by Extract is started, the password encryption configuration is completed.

Trail file encryption

To encrypt a Trail file, the data parsed by the Extract process is stored in the trail file in encrypted form (note that the entire trail file is not encrypted ). When data is not encrypted, it is stored in the trail file in plain text (this is not nonsense, huh, huh ). Open the trail file to observe the data:

 

You can also use the logdump tool to conveniently observe the data:

If it is encrypted, the data is garbled:

Using the logdump tool, you can only observe garbled data:

This ensures data security. Trail file encryption is suitable for scenarios with high data security requirements. There are two main usage modes of Trail file encryption:

Usage mode 1:

Usage mode 2:

The difference between the two is that after the trail in Mode 1 is encrypted by the Extract process, the Pump process does not process any data and directly transmits the encrypted data to the target, after the target is decrypted, the data is applied to the target database. This mode is suitable for scenarios where the Pump process only performs transmission without performing operations such as data filtering and conversion. After the trail in Mode 2 is encrypted by the Extract process, the Pump process decrypts the trail and re-encrypts it. Then, the re-encrypted data is transmitted to the target, after the target is decrypted, the data is applied to the target database. This mode is suitable for scenarios where the Pump process needs to perform operations such as data filtering and conversion.

It is also very easy to configure the Trail file encryption. First, generate the key file (see the key file content in the password encryption section ). Then modify the Extract and Replicat configurations:

# Add ENCRYPTTRAIL content to the Extract process configuration file ... SETENV (ORACLE_SID = ggtest) Userid ogg, PASSWORD secret, ENCRYPTKEY PASSWDKEY ENCRYPTTRAIL AES128 KEYNAME TRAILKEY EXTTRAIL/data/ggate/dirext/jet2/ea DISCARDFILE/u01/app/oracle/product/ggate/current/dirrpt/EJET2.dsc, APPEND, MEGABYTES 500 FETCHOPTIONS FETCHPKUPDATECOLS ...

Note that the location of ENCRYPTTRAIL must be before EXTTRAIL. If ENCRYPTTRAIL is configured after EXTTRAIL, the Extract process can also work normally, but it does not encrypt the process.

# Add DECRYPTTRAIL content to the Replicat Process configuration file ... SHOWSYNTAX DYNSQL DBOPTIONS DEFERREFCONST DECRYPTTRAIL AES128 KEYNAME TRAILKEY MAP JET2. *, TARGET JET2 .*; ...

Here, you need to transfer the key file to the target database. Here is the usage of Mode 1. For Mode 2, you also need to configure the Pump process:

... DECRYPTTRAIL AES128 KEYNAME TRAILKEY RMTHOST ogg_t, MGRPORT 7809. ENCRYPTTRAIL AES128 KEYNAME TRAILKEY RMTTRAIL/data/ggate/dirrep/jet2/ ...

Here, the key used by DECRYPTTRAIL must be the key used by Extract, that is, the TRAILKEY. During re-encryption, ENCRYPTTRAIL can use another key, and of course the same key. However, it should be noted that if another key is used, the target Replicat process will also use this key.

Network Transmission Encryption

Network Transmission encryption, as the name implies, means that the Pump process encrypts the data during transmission and the target end receives the data for decryption. The difference between this and Trail file encryption mode 2 is that in the network transmission encryption scheme, trail is not encrypted, and encryption occurs during transmission, the MGR process decrypts the data after receiving the data and then writes it to the trail. Therefore, the target trail is not encrypted, and the decryption option does not need to be configured for the Replicat process. Of course, I think it is also possible to combine the Trail file encryption and network transmission encryption. Network Transmission encryption is suitable for transmission across data centers. For example, when performing disaster recovery, data is transmitted from data center A to data center B. During this period, data transmission must pass through the public network, which means data transmission is insecure, this solution ensures the security of data transmission. Even if no leased line is used, the security strength is acceptable.

To configure network transmission encryption, you only need to modify the configurations of the Pump process:

... Userid ogg, PASSWORD secret, ENCRYPTKEY PASSWDKEY RMTHOST ogg_t, MGRPORT 7809, ENCRYPT AES128 KEYNAME TCPIPKEY RMTTRAIL/data/ggate/dirrep/jet1/ ...

If Passive Extract requires the use of RMTHOSTOPTIONS for configuration, this will be discussed in future topics. Note that the configuration of the database account is indispensable, which is different from the usual Pump configuration. Otherwise, if the Pump process fails to run normally, an error similar to the following will be reported:

ERROR OGG-01453 Oracle GoldenGate Capture for Oracle, pjet1.prm: Database login information not specified in parameter file.

GoldenGate update loss

GoldenGate unidirectional table DML Synchronization

Oracle GoldenGate series: restoration principles of Extract processes

Oracle GoldenGate installation Configuration

OGG-01004 OGG-1296 error for Oracle goldengate

Oracle GoldenGate Quick Start Tutorial: Basic Concepts and configurations

Build a GoldenGate bidirectional replication environment from Oracle to Oracle