Deployment without Application Servers
Deployment with Application Servers
Deployment with Separate Application, Database and BI Servers
High Availability (HA)
Native, built-in high availability can be fine tuned and adapted for different scenarios
Communications Protocol & Cypher
Web interface uses HTTPS over port 443 by default. Port can be changed in settings if needed.
Agents connect to master node over HTTPS (443 by default). Same encryption settings as in #1. Also agents connect using proprietary protocol on port 10000 (if no Application Servers deployed). Encryption information for port 10000:
Master communicates with Miner nodes over multiple ports with different encryption settings. All communication between nodes should happen over private secure network. Only Master (and Application Server nodes if any) should be exposed to public.
Ports Used for Miners:
Same ports as in #3, with addition of Elasticsearch on port 9200 (HTTPS).
Miners communicate with Mining DB node only over 9200 port (Elasticsearch, HTTPS), access control is IP-based, i.e., Mining DB Node servers request only from Master Node or Miner Nodes.
Application servers communicate with Master Node using the following ports:
Ports Used for Application Servers:
Application servers receive agent connection on even ports in range 10000 - 11000, same encryption settings as in #2 for port 10000.
Agent ↔ Server Connection
Master ↔ Child Node Connection
Recorded user behavior data can be stored on the endpoint in some circumstances (for example when the agent is offline). For this type of data envelope encryption(RSA+AES) is used(with the server public key used as key encryption key). Agent generates random AES key material, keeps it unencrypted in memory only. When encrypted data is written to disk, AES key is encrypted with server's public key and written alongside data.
Configuration caches don't contain any sensitive information and are being read by the client itself. Basic symmetric encryption with hardcoded key is used to discourage tampering/reverse-engineering.
Data is transmitted to the server using secure TLS channel. Certificate pinning of both parties can be enabled.
Unencrypted data transmitted by agent is processed by server and written to disk. Data at rest is not encrypted on the server side. It is expected that some disk-level encryption solutions are used on the hypervisor level.
Encrypted data with encrypted key is transmitted to the server using secure TLS channel. Server decrypts AES data encryption key with its private key. Encrypted data is decrypted using AES.
There is an option to use full end-to-end encryption for sensitive data such as emails, keystrokes and screen recordings.
In this case, the same envelope encryption method is used, but the server does not have a private key to decrypt data. AES encryption key is generated by the agent process and encrypted with configured RSA public key.
Encrypted sensitive data and encrypted AES encryption key is sent to server.
Server writes encrypted data alongside encrypted data encryption key to disk.
Viewer of encrypted data provides private key for decryption.
Server reads encrypted data and encrypted encryption key from disk. Server decodes data encryption key using provided private key. Decrypted key is stored in memory only. Server decrypts data using decrypted key and sends to the viewer. Afterwards decrypted key and data are trashed in server memory.
The agent reads the RSA public key used for Key Encryption Key (KEK) from specific location on disk. There is no limitation for the numbers of KEKs used in the system. It can be per-endpoint KEK or per-department KEK or any other method (Possibility to integrate with third-party KMS solutions).
The agent generates a random AES key used for data encryption (Data Encryption Key – DEK).
AES data encryption key (DEK) is encrypted (wrapped) using RSA encryption key (KEK).
Data is encrypted with AES key (DEK).
Encrypted data and wrapped DEK are transferred to the server. Since the DEK is encrypted (wrapped), server cannot decrypt the data.
Private part of the KEK is protected with a passphrase (encrypted) and stored on the server. (Possibility to integrate with third-party KMS solutions).
When the viewer attempts to view the data, they should supply a passphrase of corresponding KEK private part.
When passphrase is provided, server decrypts the wrapped DEK using the KEK private part and supplied passphrase.
After the DEK is unwrapped (decrypted), data can be decrypted.
Decrypted data is sent to the viewer,
There is no automated key management now.
Keys should be distributed to the endpoints and put into specific locations.
Server configuration is performed through database directly, no web interface available.
Integration with third-party key management solutions is possible in the future.
insert into encryption_kek(pub_datafile, priv_datafile, priv_encrypted)
NOTE: In multi-node deployments, PEM files should be distributed across all nodes.
Currently OCR functionality is not supported if end-to-end encryption is used. However, support might be added using the following procedure:
*Support for storing and searching of encrypted textual data is on our roadmap and will be available soon.