Table of Contents

Search

  1. About the Data Vault Administrator Guide
  2. Introduction to the Data Vault
  3. Data Vault Service Startup and Shutdown
  4. Data Vault Configuration
  5. Data Vault SSL Setup
  6. Data Vault ODBC Setup
  7. Data Vault Administration
  8. Data Repartitioning
  9. Partial Data Vault Copy
  10. Archived Data Migration
  11. Bulk File Uploader
  12. Data Vault Administration Tool
  13. Data Vault Logs
  14. User Account Privileges
  15. ssasql Command Line Program
  16. Data Vault Audit Log
  17. Sample Configuration Files

Data Vault Administrator Guide

Data Vault Administrator Guide

Data Vault SSL Setup Overview

Data Vault SSL Setup Overview

Data Vault uses TLS1.2 technology to secure communication between the Data Vault service and clients such as ODBC, JDBC, SSASQL, Data Archive, and more. To implement SSL, you can use either Certificate Authority (CA) certificates or self-signed certificates.
Secure Sockets Layer, or SSL, is a security technology that establishes an encrypted link between a server and client. The encrypted link ensures that data passed between the web server and browser remains private and secure.
Data Vault uses a successor of SSL called Transport Layer Security, or TLS, which is also commonly called SSL. When secured by TLS, connections between a client, for example a web browser, and a server, for example wikipedia.org, have one or more of the following properties:
  • A secure, private connection. TLS protocol uses symmetric cryptography to encrypt the transmitted data. The keys for the symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session. The server and client negotiate the details of which encryption algorithm, or cypher, and cryptographic keys to use before any data is transmitted. The negotiation of a shared secret is secure, because the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places themselves in the middle of the connection. Attackers cannot modify the communications during the negotiation without being detected.
  • Identification of the communicating parties. The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be optional, but it is generally required for at least one of the parties, typically the server.
  • Integrity during data transmission. Each message transmitted includes a message integrity check that uses a message authentication code to prevent undetected loss or alteration of the data during transmission.
  • A cipher suite. A cipher suite is a named combination of authentication, encryption, message authentication code (MAC), and key exchange algorithms. It is used to negotiate the security settings for a network connection using the TLS/SSL network protocol.
In previous versions of Data Vault, you enabled SSL by adding "SSL=1" to the [SERVER] section of the ssa.ini file. This implementation only handled data encryption. There was no server certificate authentication and no handshake. The SSL=1 flag is obsolete in version 6.4.3 HotFix 1 and later. Even if you set the SSL=1 parameter in ssa.ini, your data will not be encrypted.
The current SSL implementation uses TLS1.2 and server certificate validation to make a secured connection. To use encryption in Data Vault, you must have the required server certificate and use one of the following implementations:
  1. Using a certificate signed by a Certificate Authority:
    • CA root certificate at the client side and CA-signed server certificate at the server side.
  2. Using a self-signed certificate:
    • Self-signed certificate at both client side and as the server certificate.

0 COMMENTS

We’d like to hear from you!