Cybersecurity: Use OPC UA client and server with scope restriction

The Goal

Production machines are really different one from the other but any machine has a controller (or more) that can be a target during a cyber attack, so how to protect our production? Sometimes we just need to protect the exchange of the data between the controller and the network LAN and we know that this communication will be just over OPC UA.

OPC UA securedOPC UA secured

Overview of the used setup

The idea is to take one or more machine OPC UA servers which are/can be unrestricted and or unencrypted and share just the necessary data of the ctrlX Data Layer over a tailored made OPC UA server. Here there are the devices used and the IP addresses involved.

Test LayoutTest Layout

Equipment used

The test has been done with:

  • ctrlX CORE installed system apps release 2.02 (from 1.20 is good)
    • XF10 set to, XF51 set to:
    • Apps: OPC UA Client and OPC US Server 2.02 (from 1.20 is good)
  • A good and updated OPC UA test client, the "famous" one is good otherwise also UA.TestClient will fit perfectly
  • IndraControl XM22 as unrestricted open OPC UA server
Share the OPC UA data and restrict the permissions
Step 1: Connect OPC UA client to the server(s)

To test this feature we connect the ctrlX CORE OPC UA app to the servers in the network. The steps are the following:

  1. Add a new OPC UA client
  2. Insert the connections parameters of the OPC UA server and make the device persistent
  3. Adjust the parameters, save and press on connect, if it is successfully the dialog will show "CONNECTED"
  4. Check that the data are present on the ctrlX Data Layer

OPC UA ClientOPC UA Client

Connections ParametersConnections Parameters

Connections Parameters AdjustingConnections Parameters Adjusting

Device ConnectedDevice Connected

Data Layer OPC UA ClientData Layer OPC UA Client

To automate the client connection and disconnection please give a look to this guide: Connect OPC UA client to MLC and Siemens S7 OPC UA server. 

Step 2: Setup ctrlX OPC UA server and run the "Test" client to check the settings.

We can tune the server to support (or not) various security standards. we have to navigate trough "OPC UA -> Server", click on the edit button, tune the server and then save.

Go to the edit buttonGo to the edit button

OPC UA Server SettingsOPC UA Server Settings

Now it's time to check the connectivity with your favourite test client. We have to:

  1. Open the tool and check the connection, trust the certificate of the ctrlX CORE. The first connection try will fail.
  2. In ctrlX CORE we have to navigate to: "Settings -> Certificates -> OPC UA server" and trust the certificate of the test client.
  3. We can retry and now use the functionality. Use your ctrlX CORE credentials with full access. Standard is "boschrexroth".

Trust OPC UA CertificateTrust OPC UA Certificate

Trust OPC UA Certificate Server SideTrust OPC UA Certificate Server Side

The client has now full access to the ctrlX CORE OPC UA server and then to the end-device server. Now we are going to restrict it.

Step 3: Restrict the OPC UA access introducing a scope and a user

To restrict the access to the ctrlX Data Layer our developers have introduced something really cool called scopes. In the scopes we can grant to some users special access for some node or subnodes of the ctrlX Data Layer. To implement this feature in the current setup we need to make the following setups:

  1. Create a scope with the right capabilities which involves the nodes that we want keep free or with a certain restriction.
  2. Create a user with OPC UA server permission and the permission introduced by the scope.
  3. Use the user credential to access to the ctrlX Data Layer.

Let's start with the scopes. We need to go to settings and then ctrlX Data Layer. In datalayer/security/scopes we can create a scope with the following structure:

Scope exampleScope example

As we can see we can specify a lot of subnodes with the needed capability. We need an identifier and a name. The name will be displayed in the permission list to give to the user the scope capabilities. Here there the scope we're going to use. The user will see just what is behind the selected none with just read capabilities.

"identifier": "datalayer.restriction",
"name": "MyRestrictedPermissions",
"description": "Write what you want",
"permissionsR": [


Scope implementationScope implementation

 We insert now an user which is named "service" which will have just the following capabilities:

Sever PermissionsSever Permissions

Datalayer PermissionDatalayer Permission

Accessing with the "service" credentials we're able to access just to the right nodes with the right permissions.

Final resultFinal result

  Have fun 😎

Hello, I am Mauro a ctrlX DEVELOPR at night and an Application Engineer during the day 😎 . Ask me anything about ctrlX AUTOMATION but my best topics are IoT, AI, SDK and Communication!
Must Read