Table of Contents

Search

  1. Preface
  2. Introduction to Dynamic Data Masking Administration
  3. Authentication
  4. Security
  5. Connection Management
  6. JDBC Client Configuration
  7. ODBC Client Configuration
  8. Access Control
  9. Logs
  10. High Availability
  11. Server Control
  12. Performance Tuning
  13. Troubleshooting
  14. Appendix A: Database Keywords

Administrator Guide

Administrator Guide

Keystore Configuration

Keystore Configuration

To configure SSL communication in Dynamic Data Masking, copy keystores from the target database to the Dynamic Data Masking Server. Usually you can copy the database keystores without modifying them. After you copy the keystores to the Dynamic Data Masking Server installation, configure the
cfg/ddm.security
file to set the keystore parameters.
If a database certificate contains information that limits the area where you can use the certificate, you might have to change the installation. For example, if a certificate is valid only on the database host, you can install Dynamic Data Masking on the same host. Then you can copy the database keystore as-is to the Dynamic Data Masking Server.
Dynamic Data Masking can use one key password for each keystore to read key entries. Dynamic Data Masking tries to read as many key entries as possible using the given key password, and skips entries with another key password. If you do not specify the parameter
keyPassword
in the
cfg/ddm.security
file, Dynamic Data Masking tries to read all of the key entries using an empty password and then the keystore password. If all tries fail, Dynamic Data Masking logs a message that it cannot use that keystore.
The
storePassword
and
keyPassword
parameters can be the same. For example, the following image shows the keystore configuration section of the
cfg/ddm.security
file:
The following table describes the keystore properties that you configure in the keystore section of the
cfg/ddm.security
file:
Parameter Name
Description
Required
Default Value
storeType
Type of keystore, for example JKS, JCEKS, or PKCS12.
Yes
storeFile
Path to the keystore file.
No
storePassword
Password for the keystore.
No
keyPassword
Key password to read key entries in the keystore.
No
provider
Name of the specific security provider that works with the keystore.
No
encrypted
If set to "true," Dynamic Data Masking encrypts unencrypted passwords at run-time.
No
false
preferred
If set to "true," Dynamic Data Masking loads the preferred keystore first, before any other keystores.
No
false
At run time, Dynamic Data Masking loads keystores and searches aliases in the following order:
  1. The preferred keystore, specified in the
    cfg/ddm.security
    file.
  2. Keystores specified using the Java Virtual Machine system property command-line options, for example in the file
    jvm.params
    .
    • javax.net.ssl.keyStore
    • javax.net.ssl.keyStoreType
    • javax.net.ssl.keyStorePassword
    • javax.net.ssl.keyStoreProvider
    • javax.net.ssl.keyPassword
    the key password
    javax.net.ssl.keyPassword
    is not a standard Java Virtual Machine option.
  3. A keystore of the Java Virtual Machine, if any.
  4. Other keystores specified in the
    cfg/ddm.security
    file.
You can configure Dynamic Data Masking to read database credentials and signed certificates from the same custom keystore.
If you configure a custom security provider, for example CyberArk, to work with the keystore, the security provider must support reading key entries from the keystore. Otherwise, Dynamic Data Masking is not able to get signed certificates from the keystore to perform the SSL handshake with the clients.
If you use one key password to create all key entries in the keystore, Dynamic Data Masking can load all signed certificates at run time. Otherwise, if you use different key passwords to create key entries, Dynamic Data Masking will reads as many key entries as possible using one specified key password and skips key entries with another key password.
If you do not want to mistakenly store database credentials and signed certificates in the same keystore, do not specify the <storeName> parameter in the keystore configuration section of the
cfg/ddm.security
file. If you do not specify the <storeName> parameter, that store is unavailable for selection when you configure a database in the
Add Database
form.
Dynamic Data Masking internally manages the default keystore file,
cfg/ddm.jceks
. Do not change the default keystore, for example by importing certificates to the default keystore. Do not specify the default keystore in the
cfg/ddm.security
file.

0 COMMENTS

We’d like to hear from you!