About security

Starting from the 2023 R2 release, Historian is secure by default. This means that any client connecting to Historian for data storage or retrieval must be trusted by the server. There are several methods to establish a trust relationship between the client and server.

The preferred method involves using the AVEVA SMS system management server. When all nodes are configured with SMS, proper trust is established among all nodes under the same SMS. Historian can join SMS, and any client node can also join SMS, ensuring that all nodes share the same certificate and trust is automatically established.

If configuring SMS is not desired, an alternative method is to use a common root certificate installed across all systems. In this scenario, Historian will have the root certificate, which can be used to configure Historian. Each client will also have the same certificate, thereby establishing trust automatically.

Another option, if neither certificates nor SMS are used, is for Historian to create its own self-signed certificate during configuration. This self-signed certificate is bound to the Historian processes. Users can then take this certificate and install it on all nodes attempting to connect to Historian. Trust will be established between nodes because they share the same certificate.

If none of these certificates are present, communication will fail, resulting in a secure exception due to the lack of established trust. While there is an option to bypass this by choosing an untrusted connection in some cases, it is mandatory for clients unless they are developed using SDKs that allow bypassing the trust requirement. Applications such as data replay or OMI must have a trust relationship; otherwise, they cannot communicate.

The Historian Management Console (within the Operations Control Management Console) adds an additional layer of authorization to restrict access to functions affecting the state of the Historian to only authorized users. For example, you can grant a Windows user account access to start and stop Historian services by assigning it the Historian Power Users role, or by adding it to the aaPowerUsers Windows user group. For more information, see Add users and assign roles.

Note: Some Historian components require Windows and SQL Server logins.

For more information on configuring user rights assignments for local security policies, see the Microsoft documentation.

Security for AVEVA Historian is managed using the following tools:

• Microsoft SQL Server Management Studio.
  Use this application to manage access to the SQL Server and databases.

• Windows Local Users & Groups MMC snap-in.
  Use this to manage permissions on the Historian and for the OData/REST web service interface. You can also use it as an alternative to configuring permissions within the database when using Windows authentication.

  For more information, see Manage logins.

• ArchestrA Change Network Account utility.
  Use this utility to modify the Windows login for the Historian services on remote servers. For example, if you are configuring an AppEngine to send data to a remote Historian, this utility is used to choose the Windows user account with which to connect to the server.