Log In
Home
02/22/2022
Offline
Hy community
We are currently implementing a companion specification for our product to move forward with OPC UA. The most unclear point concerns security, and neither the reference documentation, the used SDK, nor the companion specification contain clear recommendations.
used documentations:
https://opcfoundation.org/wp-c…..ise-EN.pdf
https://reference.opcfoundatio…..docs/4.8.2
https://www.bsi.bund.de/Shared…..&v=10
-> The BSI criticized the lack of “documentation – security best practices/recommended settings” in 2016 and also in the 2022 analysis. And me to 😉
and a lot of google research
Roles & Permisions:
– the specification defines some well-known-roles with suggested permissions, but without any example.
– I have checked some other specifications of companions but none contains any information on this point. Is this point completely handed over to the user / manufacturer?
– Based on the suggested permissions, there are also some server-node related points in the address space. are there any recommendations which role should be able to get server diagnostic informations, edit users and roles, change pubsub-configurations… I cannot imagine that such a comprehensive definition as OPC UA with Companion Specification has no standard recommendations in the area of security. Most users and machine builders are not security experts…
– the whell-known-roles from the specification are limited to people. however, this does not correspond to a real application, because in our scenario, processes (MES, ERP, SAP, cloud services) and devices (e.g. HMI, gateway, other machines) from us as well as from third-party manufacturers would be in use at the customer and communicating with each other. What are the recommendations there?
Users:
– are there also some well-known-users (and not only humans) that should be implemented and assign with the right role (for example own MES, third-party MES, HMI)
– is it a good practice to disable the anonymous loging in case of companion specifications conformity (we will prevent unencrypted communication)? there are several PLC and other OPC UA device-manufacturer doing this.rn- should anonymus users have read-only access (the recommendation is just “very limitted access”) or should the visible area also be restricted to some server-nodes parts and/or to the other nodes in the address space?
Best regards
Patrick
05/30/2017
Offline
1) In UA the text refers to the Well Known Roles required for an action. For example, from Part 12:
https://reference.opcfoundatio…..cs/7.8.2.2
For PullManagement, this Method shall be called from an authenticated SecureChannel and from a Client that has access to the CertificateAuthorityAdmin Role, the ApplicationSelfAdmin Privilege, or the ApplicationAdmin Privilege (see 7.2).
For PushManagement, this Method shall be called from an authenticated SecureChannel and from a Client that has access to the SecurityAdmin Role (see 7.2).
In Part 5
https://reference.opcfoundatio…../docs/7.16
Since this information is security-related, it shall be restricted to authorized users, such as users who have the SecurityAdmin role, defined in OPC 10000-18.
If a node does not have specific requirements then it is up to the implementer to decide what is appropriate.
2) In OPC UA anonymous is not really anonymous if application authentication is enabled (which you appear to always use). If you have communication between apps that is not initiated by a human then it may make sense to rely on application authentication instead of creating a special user. The identity mapping rules defined in Part 18 allow Roles to be assigned to application certificates in addition to or instead of users.
IOW – always disabling anonymous is not a good idea.
02/22/2022
Offline
Randy Armstrong said
2) In OPC UA anonymous is not really anonymous if application authentication is enabled (which you appear to always use). If you have communication between apps that is not initiated by a human then it may make sense to rely on application authentication instead of creating a special user. The identity mapping rules defined in Part 18 allow Roles to be assigned to application certificates in addition to or instead of users.
IOW – always disabling anonymous is not a good idea.
Hi
thanks for the comment.
I think in our scenario we will have a mix of them:
– Own applications (HMI, MES) with integrated user and access-management system. I agree that application authentication will be the best solution regarding to developement, scalability and product live cycle.
– Third party diagnostic applications (for example UaExpert, vendor specific PLC IDE) used for developement and diagnostics. Wouldn’t specific applications and roles be a better solution, since we don’t know which applications will be used in the next 10 years and we can’t distribute all possible application certificates?
– Third party applicatins (MES) with integrated user and access-management system. Same problem as with the diagnostic tools. And we want to restrict some areas to license data outside of the Companion specification. Based on this recommendation (https://opcfoundation.org/foru…..-ua-nodes/) special roles would be the best solution.
Our problem with the security issue is that a search using the keywords “role, roles, user, authenticated, restricted” returns >2000 hits within the reference documentation. Some of these restrictions are probably solved in the used SDK (this is currently not 100% clear for us). On the other hand, the freedom to define a suitable implementation could be a curse and a blessing. That’s why the question for “best practices”, so we are not completely wrong.
Best regards
Patrick
05/30/2017
Offline
1) If you are deploying OPC UA with security for more than 10 or so nodes you need to manage certificates and trust lists centrally with a GDS. This would allow you to adapt to changes as new applications are added to the mix.
2) Even if use username/password credentials these credentials need to be managed over time. Especially if you expect multiple employees to share admin passwords.
3) The question of best practices depend on requirements and available infrastructure.
If someone has no infrastructure restrictions the best practice recommendations are:
1) Use a GDS to manage certificates and trust lists;
2) Map applications to roles (via their ApplicationUri) with identity mapping rules for app-to-app communication;
3) Use tokens with centralized identity management for human users;
4) Map system roles/groups in the user tokens to server specific roles with identity mapping rules.
Of course, as soon as people have infrastructure restrictions they need to adopt less ideal configuration.
1 Guest(s)
Usage Policy