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

Key Strategies

Key Strategies

If Dynamic Data Masking uses multiple signed certificates to perform the handshake with database clients, you must configure a simple port strategy or an advanced port strategy in the
cfg/ddm.security
file.
By default, the standard Java implementation chooses the first alias it finds in the keystore for which there is a private key and a key of the right type for the chosen cipher suite. The selected alias does not necessarily correspond to the requested domain, which can cause certificate errors.
To overcome this limitation, you can configure a simple port strategy or an advanced port strategy that map each SSL host and port combination in Dynamic Data Masking to a specific alias. Each alias corresponds to a key entry with a private key and signed certificate in the keystore that Dynamic Data Masking uses for the SSL handshake with the client.
The following image shows the keystrategies configuration section of the
cfg/ddm.security
file:
Alias names must be unique for all keystores. If you do not give unique alias names, Dynamic Data Masking uses the key entry with the first found matching alias to handshake with the client.
You do not need to configure the keystrategy section when you have not configured the Dynamic Data Masking Server with a keystore, or when a keystore configured in the Dynamic Data Masking Server contains only one signed certificate.
If you have not configured the Dynamic Data Masking Server with a keystore, Dynamic Data Masking uses the self-signed certificate generated in the default Dynamic Data Masking keystore file
cfg/ddm.jceks
. This certificate is associated with the reversed alias name
ddm_self_signed
. Do not use this alias name in any other keystores.
In this scenario, the Dynamic Data Masking Server provides the self-signed certificate to the client.
If you have configured the Dynamic Data Masking Server with one keystore, defined in the file
jvm.params
or
cfg/ddm.security
, that contains only one signed certificate, Dynamic Data Masking uses that certificate.
The following table describes the keystore strategy requirements for both the Dynamic Data Masking Server and the administrative tools:
Dynamic Data Masking Server
Administrative Tools
Keystore or Keystores
Dynanic Data Masking Server SSL Functionality
Truststore or Truststores
Dynamic Data Masking Administrative Tools SSL Functionality
not set
Provides the self-signed certificate to the SSL client. The key strategy is not relevant.
not set
Accepts any certificate. Can connect.
set with certificates
Provides to SSL client:
  • If you have not configured a port strategy, provides the first found signed certificate.
  • If you have configured a port strategy, provides a signed certificate associated with an alias mapped to a specific SSL port.
not set
Accepts any certificate. Can connect.
not set
Provides the self-signed certificate to SSL client. Key strategy is not relevant.
set with certificates
Cannot connect, because the Dynamic Data Masking Server has no matching private key.
set with certificates
Must have a configured port strategy. Provides to SSL client a signed certificate associated with an alias mapped to a specific SSL port.
set with certificates
Can connect, but the Dynamic Data Masking Server must have matching private key.

0 COMMENTS

We’d like to hear from you!