Secure Your Aternity on-premise Deployment (Getting Started)

When you configure servers to use Secure Sockets Layer (SSL) encryption, this ensures that access to the server is secure and that data is protected. Use this article to learn about the general workflow for securing your deployment and to navigate to the more detailed procedures.
Aternity secured components
Important Notes:
  • Aternity requires x509 PEM certificates (base64 encoded)

  • For all certificates, the SSL Certificate Common Name (CN) should match the request hostname (the address of the host via which clients access servers).

  • All Aternity components, except for the Dashboard Server, are secured using a Java keystore (JKS). The Java keystore must contain the host’s private key, the matching signed certificate, and the certificate for the Certificate Authority (CA) that signed it.

  • The Dashboard Server is secured with plain files, stored in the host file system. Dashboard Server requires the host's private key, a matching signed certificate, and, optionally, a certificate chain file. The chain file is a concatenation of all of the certificates that form the certificate chain for the server certificate.

# To Do This... Do This...
1

To secure your connection, you must create an SSL certificate first. Having trustful certificates is critical for establishing a secure HTTPS connection.

Once you have certificates and keys, you can configure SSL encryption (HTTPS).

  • How to generate certificates for Aternity Dashboard Server, read here.

  • How to generate certificates for Aternity Docker Components Server, as well as for Aternity Management Server, Data Warehouse Server, and Aggregation Server, read here.

2

To secure user access to the Aternity Management Server

Perform the steps provided in the article Secure Aternity Management Server with SSL Encryption (HTTPS)

3

To secure user access to the Aternity Dashboard Server and Aternity Dashboard Gateway Server

Perform the steps provided in the article Secure Aternity Dashboard Server with SSL Encryption (HTTPS)

4

To secure user access to the Data Warehouse Server and Aggregation Server as well as communication between Aggregation Server and Agent.

Perform the steps provided in the article Secure Data Warehouse Server and Aggregation Server with SSL Encryption (HTTPS)

5

To secure communication between Agent and Aggregation Server

Perform the steps provided in the article Secure Your Aternity Agent with SSL Encryption (HTTPS)

6

To secure user access to the Aternity Docker Components Server

Perform the steps provided in the article Secure Aternity Docker Components Server with SSL Encryption (HTTPS)

6

You may want to periodically change passwords on the servers in your Aternity installation, for security reasons and to comply with a corporate policy.

Change passwords on the servers in your Aternity installation.

Aternity's security extends to both the server side and the Agent for End User Devices installed on your end user devices, applying a broad set of methods across all access points in the system.

Aternity offers secure connections to monitored devices and to users of the system
Tip

For details about end user privacy, see how Aternity stores PII (personally identifiable information).

Additional Security Settings

Route Port Description

Agent for End User Devices collects and sends data to Aternity

443

The files (DLLs and EXEs) of the Agent for End User Devices are digitally signed to ensure no tampering. It also uses several anti-hack security measures, including ASLR (randomizing memory addresses), DEP (validating code is run from expected locations) and SEH (ensuring only valid exception handlers).

When sending data, the Agent reports securely to Aternity via HTTPS. The Agent uses TLS 1.2 on devices with .NET 4.5 or later.

Agent setup

N/A

The Agent setup package is digitally signed to guarantee the files are genuine.

Secure installation of the Agent for End User Devices
Aternity Recorder

N/A

The Aternity Recorder located on a monitored device is only active when you gather data to create custom activities, and even then, it is only active on that device for the limited time during the actual recording, with the explicit approval and interaction of the user on that device for that time.

Alternatively, for maximum security, you can configure the setup of the Agent for End User Devices to exclude the Recorder entirely from all monitored devices. If you create your own custom activities, which require the Recorder to find the start and end events of an activity, you can designate a specific device to perform those recordings for that time.

Access to Aternity (local user or SSO)

443

Aternity on-premise users access securely via HTTPS (learn more).

Optionally, for complete control of the security of signing in, you can deploy SSO. Single Sign-On (SSO) brings the most secure access to Aternity by bypassing Aternity's sign in screen, and authenticating with your enterprise's chosen identity provider (IdP) just once using passwords, two-factor authentication (2FA), or even biometrics. Every time you access Aternity as an SSO user, it automatically reroutes you securely to the IdP, and then after authentication, it routes you back to your Aternity home page as a signed in user. SSO uses the secure SAML 2.0 protocol to delegate the entire authentication process to the IdP.

Learn more.

REST API queries

443

Analysts can send REST API queries to view Aternity data directly via HTTPS (port 443).

For details on configuring HTTPS for your REST API queries, see the steps below.

Automatic emails

25 outbound

Configure the connection of your Aternity on-premise to your enterprise email server, as the route to send automatic email notifications.

Learn more.

Automatic timeout

By default Aternity has an automatic timeout, logging you out if the session has been idle for more than 3.5 hours.

Aternity's extensions security permissions include:

Security Aspects Description

Aternity Chrome extension (Agent)

The addon does NOT send any info to any website. Aternity only collects data from end user devices for further performance analysis. It does not perform any outside communication for any site.

Add Aternity extensions to your white list or do not deploy them at all (by disabling the Chrome Extension Policy monitor prior to deploying the Agent). Note that it will cause losing most Chrome monitoring capabilities.

Aternity Chrome extension (WAC)

The addon does NOT send any info to any website. Aternity allows creating activities for further performance analysis. It does not perform any outside communication for any site.

Aternity Chrome extension permissions

management: The permission is used for communicating with the WAC extension

nativeMessaging: The permission is used for exchanging messages with native applications, for communicating with the Agent

webNavigation: The permission is used for receiving notifications about the status of navigation requests on fly, for measuring web pages loading time.

webRequest: The permission is used for observing and analyzing traffic info, for measuring network times during web pages loading time.

Tabs: The permission is used for managing the state of all frames in all tabs, and providing tab events so that they can be used when creating activities.

idle: The permission is used for detecting any change in the device's idle state.

Host Permission (URL patterns): Aternity requires permissions to all websites to detect the usage.