22 Encrypting Data with the Master Key and Wallet Method
To use this method of data encryption, you create a local master key wallet, add a master key to the wallet, and then use this master key for data encryption.
This method depends on whether the data is encrypted in the trails or across TCP/IP.
For the Classic Architecture, to encrypt data across the network,
Oracle GoldenGate generates a session key using a
cryptographic function based on the master key. However, the Distribution Server
ogg
protocol doesn't support this method.
Oracle GoldenGate uses an auto-login wallet (file
extension .sso
), which is an obfuscated container that does not
require human intervention to supply the necessary passwords.
Note:
Encrypting data with a master key and wallet is not supported on the NonStop platforms.With the master key and wallet method of encryption, you may need to perform the following tasks:
- Creating the Wallet and Adding a Master Key
- Specifying Encryption Parameters in the Parameter File
- Renewing the Master Key
- Deleting Stale Master Keys
Parent topic: Securing Oracle GoldenGate
22.1 Creating the Wallet and Adding a Master Key
The wallet is created in a platform-independent format. The wallet can be stored on a shared file system that is accessible by all systems in the Oracle GoldenGate environment. Alternatively, you can use an identical wallet on each system in the Oracle GoldenGate environment. If you use a wallet on each system, you must create the wallet on one system, typically the source system, and then copy it to all of the other systems in the Oracle GoldenGate environment. This must also be done every time you add, change, or delete a master key.
This procedure creates the wallet on the source system and then guides you through copying it to the other systems in the Oracle GoldenGate environment.
Parent topic: Encrypting Data with the Master Key and Wallet Method
22.2 Specifying Encryption Parameters in the Parameter File
This procedure adds the parameters that are required to support data encryption in the trails and across the network with the master key and wallet method.
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.
Parent topic: Encrypting Data with the Master Key and Wallet Method
22.2.1 Using SOCKS5 Proxy to Deliver Encrypted Data
The SOCKS5 protocol routes packets between a server and a client using a proxy server. The protocol establishes a TCP connection to another server on behalf of the client and then routes the traffic between the client and server, while hiding the identity of the client from the public network.
In Oracle GoldenGate, you can use SOCKS5 proxy to deliver data over the network with
the RMHOSTOPTIONS
parameter. See RMTHOSTOPTIONS
for details.
To create a SOCKS5 proxys with SSH tunneling to securely transmit data over the network, perform the following steps:
-
On Linux, a SOCKS5 proxy can be set up along with SSH tunneling using the following SSH command:
ssh –i private_key file -v –N –f –D listening IP Address:listening IP port GGCS Oracle User@GGCS IP Address socksproxy output file -N: No execution command on remote system -D: Dynamic Port Forwarding -i: Private Key File -f: Run the proxy process in the background -v: Verbose Mode -C: Compression
ssh -N -f -i opc_rsa.ppk -D 127.0.0.1:1080 opc@129.145.2.34 /tmp/ogg_socksproxy.log
RMTHOST 129.145.2.34, COMPRESS, MGRPORT 1021, SOCKSPROXY 127.0.0.1:1080
Parent topic: Specifying Encryption Parameters in the Parameter File
22.3 Renewing the Master Key
This procedure renews the master encryption key in the encryption-key wallet. Renewing the master key creates a new version of the key. Its name remains the same, but the bit ordering changes. As part of your security policy, you should renew the current master key regularly so that it does not get stale.
All renewed versions of a master key remain in the wallet until they are marked for deletion with the DELETE MASTERKEY
command and then the wallet is purged with the PURGE WALLET
command, see Deleting Stale Master Keys.
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 processes need to be stopped. This procedure includes steps for performing those tasks in the correct order.
Parent topic: Encrypting Data with the Master Key and Wallet Method
22.4 Deleting Stale Master Keys
This procedure deletes stale versions of the master key. Deleting stale keys should be part of the overall policy for maintaining a secure Oracle GoldenGate wallet. It is recommended that you develop a policy for how many versions of a key you want to keep in the wallet and how long you want to keep them.
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.
If the wallet is on central storage that is accessible by all Oracle GoldenGate installations that use that wallet, you need only perform these steps once to the shared wallet. You do not need to stop the Oracle GoldenGate processes.
If the wallet is not on central storage (meaning there is a copy on each Oracle GoldenGate system) you can do one of the following:
-
If you can stop the Oracle GoldenGate processes, you only need to perform the steps to change the wallet once and then copy the updated wallet to the other systems before restarting the Oracle GoldenGate processes.
-
If you cannot stop the Oracle GoldenGate processes, you must perform the steps to change the wallet on each system, making certain to perform them exactly the same way on each one.
These steps include prompts for both scenarios.
Parent topic: Encrypting Data with the Master Key and Wallet Method