CygNet OPC UA Server Security

Security is integral to OPC UA. OPC UA supports a sophisticated security model that ensures the authentication of users, authentication of client and servers, and the integrity of communication channels and shared data. The OPC UA standard requires that all network endpoints communicate over a secure connection. The CygNet OPC UA Server provides security via data encryption, user authentication, and application authentication, ensuring secure transmission of CygNet data to the OPC UA client.

See the following subsections for more information:

• OPC UA Certificates
• OPC UA Client User Authentication
• OPC UA Server Application Authentication
• Transport Channel Security
• CygNet Bridge API Access
• CygNet Security Considerations
• CygNet OPC UA Server Password Encryption

OPC UA Certificates

Security in OPC UA is handled using certificates. Each OPC UA server instance and OPC UA client instance must provide a trusted certificate to identify itself in order to establish a secure connection. OPC UA uses the X.509 certificate standard, which defines a standard public key format, by signing and encrypting the OPC UA messages to validate integrity and providing application identification to ensure trustworthiness.

The default CygNet OPC UA Server certificates store is C:\ProgramData\Weatherford\CygNetOpcUaServer\Certificates.

OPC UA Client User Authentication

An OPC UA client must provide appropriate user credentials (username and password) to establish an OPC UA session. These user credentials must resolve to a valid user identity to authenticate against Windows Active Directory on the CygNet Bridge API server. User credentials are passed through to CygNet Bridge to authenticate against the Client Login API. There will be one Bridge session per user identity in CygNet OPC UA Server. ACS permissions are enforced per-user in CygNet according to the end-user's Windows userid.

Trusted Certificates

If the OPC UA client fails to authenticate with the OPC UA server, you might see a message in the OPC UA log indicating that a client certificate is untrusted. The client certificate will be rejected if it isn’t in the trusted folder, so it should be added to the trusted folder before attempting to connect.

The Certificates folder locations can be overridden in the CygNetOpcUaServer.Config.xml file. See Security Configuration for more information about this option.

OPC UA user authentication is described in OPC 10000-2: OPC UA Specification Part 2: Security Model, Section 4.9.

OPC UA Server Application Authentication

Application authentication is achieved via trusted certificates. An OPC UA client provides a trusted certificate and the OPC UA server has that certificate in its trusted certificate store (e.g., C:\ProgramData\Weatherford\CygNetOpcUaServer\Certificates\Trusted). There is no user identity associated with the client’s session, so all access to CygNet Bridge (and CygNet) will be using the OPC UA server identity configured (and encrypted) in the OPC UA configuration file. See Configuring the CygNet OPCUA Server for more information about configuring the OPC UA server credentials and CygNet OPC UA Server Password Encryption below for more information about password encryption.

OPC UA application authentication is described in OPC 10000-2: UA Specification Part 2: Security Model, Section 4.10.

Transport Channel Security

Both server and clients authenticate against each other before communicating data over transport layers, where messages are encrypted and signed end-to-end, ensuring highly secure communication channels.

CygNet Bridge API Access

Since the CygNet OPC UA Server communicates with CygNet Bridge API, the BRDGAPI/ACCESS security event must be configured in the CygNet ACS. The OPC UA server requires that all user identities (both client identities and the server identity) have the BRDGAPI/ACCESS event configured.

Note that the OPC UA client identity is only required in the CygNet ACS when using User Authentication. If using Application Authentication only, the server identity is required, and all OPC UA clients will have access to the same data that the server identity is allowed.

See CygNet Bridge API (BRDGAPI) Security for more information about the BRDGAPI/ACCESS security event.

CygNet Security Considerations

Note the following items regarding CygNet ACS permissions for the OPC UA Server identity for alarms, subscriptions, and browsing nodes.

Alarms

• To control which alarms are exposed in the OPC UA Server, the CygNet ACS permissions for the OPC UA Server identity are used. This is the identity specified in the CygNetBridgeUsername configuration file element.
• All OPC UA clients will have access to the alarms exposed by the OPC UA Server identity’s ACS permissions.

Real-time value subscriptions

• The CygNet ACS permissions of the client’s identity are checked at the time the subscription is established. Denied permissions will return the error BadNotFound.
• If the OPC UA client session is established using an X509 certificate for authentication, then the OPC UA Server identity’s ACS permissions are used for determining access to the CygNet current values.
• If the OPC UA client session is established using user credentials, then the client user identity’s ACS permissions are used for determining access to the CygNet current values.
• Changes to a client user’s ACS permissions will only affect new subscriptions. Existing subscriptions will not be affected, and will continue to publish new real-time values for that subscription.
• The OPC UA Server will need to be restarted in order to force the new ACS permissions to take effect, for existing OPC UA client session subscriptions.

Browsing nodes in the CygNet address space

• When the CygNet address space is built using the CygNet OPC UA Server model builder script (GenerateCygNetModel.ps1), all CygNet facilities and points that the configured OPC UA Server identity has permission to read will be included in the address space.
• Consequently, when browsing the address space using a client application such as the Matrikon OPC UA Explorer, all facilities and points included in the address space will be viewable regardless of the permissions of the logged-in user session.
• An attempt to subscribe to a real-time value for a point for which the current user has no permissions to read will return the error BadNotFound.
• Reading facility and point property values through the OPC UA Server’s Read service will enforce the ACS permissions for that client’s user identity.

CygNet OPC UA Server Password Encryption

Best practice recommends that the OPC UA server password be saved in an encrypted format in the CygNet OPC UA Server configuration file.

This is accomplished by starting the server with an "-encrypt" parameter, which will start the server in a special mode used only for password encryption and nothing else.

When running the encryption routine, the server will look for the <CygNetBridgePassword> element in the CygNetOpcUaServer.Config.xml file and will replace it with a <CygNetBridgePasswordEncrypted> element that contains a 64-bit encoded string as its value. The server will also generate a second element called <CygNetEncryptionKeyPath>, which points to the location of a generated key file that is used by the server anytime the encrypted password needs to be decrypted (i.e., whenever the server needs to supply the unencrypted password to CygNet Bridge). This key file can be moved to a secure location, such as to a flash drive, and the <CygNetEncryptionKeyPath> in the configuration file must be updated accordingly.

See the <CygNetBridgePassword> element in the CygNetOpcUaServer.Config.xml file for more information.

To encrypt the CygNet Bridge password

The CygNet OPC UA Server supports a command-line interface to start the server and encrypt the CygNet Bridge password:

1. Open a Command Prompt window.
2. Navigate to the directory where the server executable is installed: C:\Program Files\Weatherford\CygNetOpcUa\CygNetOpcUaServer
3. Type the following command:

CygNetOpcUaServer -encrypt

4. The CygNet OPC UA Server will stop after the encryption routine is completed.