Table of Contents

Encryption in DataMiner

Note

DataMiner does not support having the Use FIPS compliant cryptographic algorithms Windows setting enabled. Having this option enabled will prevent DataMiner from starting up properly.

Passwords

In the context of a DataMiner System, we can distinguish between two types of passwords:

  • User passwords
  • Device passwords

User passwords

Passwords for external users in the DataMiner System are always managed by the User Directory (Active Directory, OpenLDAP, etc.). To verify password security requirements, we recommend that users consult their respective User Directory documentation.

For local DataMiner users, Windows will store the (hashed) password. The complexity and renewal policies in Windows apply to local DataMiner users.

The only exception to this is dataminer.services users (see Types of users). These users are fully managed by DataMiner. The passwords for these users are randomly generated (17 characters) and encrypted using the Blowfish algorithm (ECB mode, 308-bit key) before being stored.

Device passwords (tokens)

All password encryption in DataMiner is done through the Blowfish algorithm (ECB mode). A 308-bit key is used for the encryption.

DataMiner encrypts the following secrets using this technique:

  • Password parameters
  • Credential libraries
  • Database passwords
  • Element passwords
  • Replication passwords

In-transit encryption

Here we can distinguish several communication flows:

DataMiner Cube

Starting from DataMiner 10.5.10/10.6.0, Cube uses gRPC over HTTPS by default to communicate with DataMiner.

Prior to this, Cube will communicate with the DataMiner backend over .NET Remoting by default. This is encrypted using the Rijndael (256-bit key, CBC mode) algorithm. The encryption key is negotiated over a 2048-bit RSA-secured communication channel. It is also possible to configure DataMiner so gRPC is used instead of .NET Remoting.

From DataMiner 10.5.0 [CU12]/10.6.0/10.6.3 onwards, when Cube connects to a DMA that is connected to dataminer.services (i.e., a DMA of which the hostname ends with .dataminer.services), gRPC is always used, even if a different connection type has been specified in the Cube settings.

DataMiner web apps and API

By default, the DataMiner web apps (Dashboards, Monitoring, etc.) are served over HTTP, which is unencrypted. Starting from DataMiner 10.2.1/10.3.0, the webpages are also served over HTTPS using a self-signed certificate. We recommend that you properly configure HTTPS and disable HTTP to ensure all traffic is encrypted.

Inter-DataMiner

Starting from DataMiner 10.5.10/10.6.0, DataMiner Systems consisting of multiple DataMiner nodes use gRPC over HTTPS for the inter-node communication.

Older versions of DataMiner use a .NET Remoting channel by default for the inter-node communication. This channel is encrypted using the Rijndael algorithm (256-bit key, CBC mode). The encryption key is negotiated over a 2048-bit RSA-secured communication channel. It is also possible to configure DataMiner to use gRPC instead of .Net Remoting.

Data acquisition

Depending on the type of device, DataMiner supports different communication protocols:

Protocol Description
SSH DataMiner supports a broad list of SSH cipher, host key algorithms and key exchange algorithms. For more information, see SSH support in DataMiner.
SNMP We recommend interfacing with SNMP devices by using SNMPv3, which provides authentication and privacy.
HTTP(S) We recommend interfacing with devices or APIs over HTTPS, which uses TLS encryption.
TCP/IP DataMiner can poll devices over a TLS-encrypted TCP/IP channel. See Enabling TLS encryption.

Storage as a Service

For DataMiner Systems configured to use STaaS, all communication between DataMiner and the database is TLS-encrypted by default, since it makes use of the the connection towards dataminer.services.

Cassandra

For DataMiner Systems configured to use a Cassandra database, it is possible to enable TLS encryption between DataMiner and the Cassandra cluster. Please refer to the official Cassandra documentation on enabling TLS encryption.

We recommend changing the default Cassandra credentials.

Note

For more information, see Securing the Cassandra general database.

OpenSearch

For DataMiner Systems configured to use an OpenSearch database, we recommend enabling HTTPS. Please refer to the official OpenSearch documentation on enabling TLS encryption.

Note

For more information, see Securing the OpenSearch database.

Elasticsearch

For DataMiner Systems configured to use an Elasticsearch database, we recommend enabling HTTPS. Please refer to the official Elasticsearch documentation on enabling TLS encryption.

Note

For more information, see Securing the Elasticsearch database.

NATS

DataMiner relies on NATS for some inter-process communication. Prior to DataMiner 10.6.0/10.6.1, this NATS traffic is not yet encrypted by default.

Please refer to Securing NATS to learn how to set up TLS for NATS.

Encryption at rest

DataMiner only encrypts passwords at rest, all other data is not encrypted by default. This behavior is not configurable in DataMiner.

Note

To encrypt all data on disk, you can enable Windows BitLocker.

Storage as a Service

DataMiner Storage as a Service (STaaS) makes use of existing secure storage solutions of Microsoft Azure, which means that all data is encrypted at rest.

Cassandra

If you are using Cassandra enterprise edition, we recommend enabling the transparent_encryption_options, effectively encrypting all your database data at rest. This option is not available in Apache Cassandra, so we recommend enabling disk encryption on the operating system level for this.

OpenSearch

OpenSearch does not have the option to encrypt data at rest. For this reason, we recommend enabling disk encryption on the operating system level.

ElasticSearch

ElasticSearch does not have the option to encrypt data at rest. For this reason, we recommend enabling disk encryption on the operating system level.

Improve this page