- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
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.
Equipment used
The test has been done with:
- ctrlX CORE installed system apps release 2.02 (from 1.20 is good)
- XF10 set to 192.168.1.1, XF51 set to: 192.168.2.1
- 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:
- Add a new OPC UA client
- Insert the connections parameters of the OPC UA server and make the device persistent
- Adjust the parameters, save and press on connect, if it is successfully the dialog will show "CONNECTED"
- Check that the data are present on the ctrlX Data Layer
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.
Now it's time to check the connectivity with your favourite test client. We have to:
- Open the tool and check the connection, trust the certificate of the ctrlX CORE. The first connection try will fail.
- In ctrlX CORE we have to navigate to: "Settings -> Certificates -> OPC UA server" and trust the certificate of the test client.
- We can retry and now use the functionality. Use your ctrlX CORE credentials with full access. Standard is "boschrexroth".
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:
- Create a scope with the right capabilities which involves the nodes that we want keep free or with a certain restriction.
- Create a user with OPC UA server permission and the permission introduced by the scope.
- 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:
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": [
"opcuaclient/device1/i=85/ns=2;s=Logic/ns=2;s=Application/ns=2;s=Application.testUA/**"
]
}
We insert now an user which is named "service" which will have just the following capabilities:
Accessing with the "service" credentials we're able to access just to the right nodes with the right permissions.
Have fun 😎