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)
DataMiner encrypts the following secrets:
- Password parameters
- Credentials from the Credentials Library
- Database passwords
- Element passwords
- Replication passwords
Prior to DataMiner 10.6.10/10.7.0, all password encryption in DataMiner is done through the Blowfish algorithm (ECB mode), using a 308-bit key.
From DataMiner 10.6.10/10.7.0 onwards, credential secrets stored by DataMiner (e.g., SNMPv3 passphrases, HTTP tokens, username/password credentials, and database passwords managed through the Credentials Library) are stored as authenticated ciphertext using AES-256 in CBC mode combined with HMAC-SHA-256 (Encrypt-then-MAC). The per-node encryption keys are protected with the Windows Data Protection API (DPAPI) under LocalMachine scope, so an offline copy of the key file cannot be opened on a different host.
In-transit encryption
Here we can distinguish several communication flows:
- DataMiner Cube
- DataMiner web apps and API
- Inter-DataMiner
- Data acquisition
- Storage: Storage as a Service or Cassandra and OpenSearch/Elasticsearch
- NATS
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.
Credentials at rest
From DataMiner 10.6.10/10.7.0 onwards, credential secrets are no longer stored in the legacy Library.xml file, but as authenticated ciphertext (AES-256-CBC with HMAC-SHA-256) in the system storage itself. In a dedicated clustered storage or STaaS setup, they are kept separately from the data that references them. On systems with storage per DMA, which have no such centralized storage, the secrets are stored in EncryptedSecret.xml files in the C:\Skyline DataMiner\Security\Credentials folder instead. In all cases, the encryption keys remain on the node itself, in an encryptors.bin file in the C:\Skyline DataMiner\Security\Encryption folder, wrapped with the Windows Data Protection API (DPAPI) under LocalMachine scope, so it cannot be read on another host.
Because DPAPI binds the encryption keys to the host that produced them, restoring a DataMiner Agent on a different machine requires a DMS backup password. When this password has been configured, a full DataMiner backup contains a passphrase-wrapped envelope (backup_encryptors.bin) that is sealed with PBKDF2-HMAC-SHA-256 (100,000 iterations, 32-byte salt) and AES-256-CBC with HMAC-SHA-256, so that the encryption material can travel between hosts without exposing the keys in plain text. For more information, see Backing up a DataMiner Agent and Restoring a DMA using the DataMiner Taskbar Utility.
Important
Store the DMS backup password securely outside DataMiner (for example, in a password manager). If it is lost, encrypted credentials in any backup taken with that password can no longer be recovered on a clean host. In a multi-node cluster, a peer DataMiner Agent can re-synchronize the encryption material to a restored node, but this should not be relied upon as a substitute for a properly configured DMS backup password.
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.