Secure Communication

For communication, AspenTech Inmation Nodes use an optimized custom protocol on top of a TCP/IP networking stack. The secure communication channel between Nodes is ensured by default with the Transport Layer Security (TLS) encryption protocol together with Pre-Shared Keys (PSK) authentication, denoted TLS-PSK in this document and in the product.

The Encryption and authentication settings for Node to Node communication are configured in the Connection Objects (Downlink Connection object for the Parent Node and Uplink Connection object for Child Node).

The WebServer is the primary interface for communicating with the Node, used by System Config App for system configuration as well as by third-party web clients. While the WebServer supports both HTTP and HTTPS, enabling HTTPS from the outset is strongly recommended to ensure all traffic between clients and the Node is encrypted and protected.

HTTPS (HyperText Transfer Protocol Secure) is the secure variant of HTTP. It wraps the HTTP protocol inside a Transport Layer Security (TLS) session, providing three key properties:

The TLS handshake is the mechanism by which the client and server agree on a cipher suite, exchange or verify certificates, and establish a shared session key used for symmetric encryption of the subsequent data transfer.

A valid server certificate is required to enable HTTPS. Depending on the deployment. When a WebServer object is created, a self-signed certificate is created automatically and the WebServer’s properties are set to contain the certificate and its private key. A self-signed certificate, which requires clients to explicitly trust the certificate or the CA before the connection is accepted without a browser warning.

AspenTech Inmation connects with a MongoDB instance using a configurable authentication mechanism. The currently supported authentication types are:

Communication between the Node and MongoDB can be TLS encrypted by enabling the Secure Connections property for each Data store.

The AspenTech Inmation IP.21 integration uses gRPC over TLS to secure the communication channel between the IP.21 Server service and the IP.21 gRPC Datasource object. The IP.21 Server service runs on the same machine as the AspenTech InfoPlus.21 system and exposes a gRPC interface; the IP.21 gRPC Datasource object, typically installed on a separate Node, connects to this interface to receive replicated data. For a general overview of the IP.21 integration, see the IP.21 connectivity page.

In general, the AspenTech Inmation OPC UA client and OPC UA server support different communication security policies, user token policies, and application authentication methods as specified in the OPC UA standard. The supported security policies are:

These come with different supported key lengths and cryptographic algorithms. A security policy different from None ensures data integrity and privacy based on strong cryptographic algorithms.

After creating OPC UA Servers and Datasources, the Node service will create self-signed UA application instance certificates. The certificates can be recreated by the certificate management dialog, or by deleting the old certificates (private/public) and restarting the Node service.

For more information regarding Certificate Management in the AspenTech Inmation UA server see the OPC UA Server page.

AspenTech Inmation provides both an OPC Classic client to connect to external data sources, and an OPC Classic server to expose its data model via an OPC Classic interface to external clients. In a distributed setting based on DCOM, the standard DCOM security model applies which is not specific to AspenTech Inmation. The OPC Classic server does not implement the OPC security interfaces. For a secure operation in a productive system, use a dedicated network segment, allowing only required hosts/ports via strict firewall ACLs, and disable all unnecessary DCOM services. Run OPC services with least-privilege domain service accounts, enforce MFA for admin access through jump hosts, and keep Windows/DCOM hardening and patches current.

Communication to shopfloor devices, such as PLCs or Modbus devices, is typically not encrypted. For a secure operation in a productive system, use dedicated network segments (VLANs), block all non-required paths with strict firewall allowlists (only specific master-to-slave IPs, ports, and function codes), and prohibit direct IT/Internet reachability.

Using Lua script a variety of connection types can be established to data sources and sinks. This basically depends on the included Lua script libraries. The Node provides the LuaSec library to enable secure socket communication.