Security

From UaCapabilities
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Introduction

Security is a fundamental aspect of OPC UA. It consists of several individual elements that are integrated in different layers of the OPC UA Framework.

UA fw Security.JPG

OPC UA Security is concerned with the authentication of clients and servers, the authorization of users, the integrity and confidentiality of their communications and the auditing of client server interactions. To meet this goal, security is integrated into all aspects of the design and implementation of OPC UA Servers and Clients. OPC UA security is based on industry standard security algorithms, yet is scalable to meet the environment and application requirements. Communication Layer Security is part of the Transport Mapping Capabilities; see Transport Mappings. The design and implementation of OPC UA’s security standard is based on proven standards. The resulting OPC UA security architecture permeates the application and communication layers atop the transport layer.

SecurityLayers.jpg

All activities in the application layer are based on a secure channel that is created in the communication layer. Applications rely upon it for secure communication in addition to application authentication. The secure channel is responsible for messages integrity, confidentiality and application authentication. The application layer manages user authentication and user authorization. Clients may pass a user identity token to the OPC UA Server. The Server verifies that this user is allowed to access and what resources it is authorized to use.
Note – The OPC UA Security Model is described in OPC UA Part 2.
The Secure Conversation Services and the security elements in Session Services are specified in OPC UA Part 4.
The communication layer security elements are specified in OPC UA Part 6.

Required Security Capabilities

Confidentiality, Integrity, and Authentication

Description
Security in the Communication Layer has to be supported as required for the supported Transport. This includes application authentication and secure communication.

  • The Server is obligated to minimally support user authentication with UserName/Password.
  • Clients have to support UserName/Password or X.509 certificates as required by the Server.

Usage Considerations
Security, including encryption, signing, and user authentication, is a core element for OPC UA applications and is therefore part of the OPC Foundation stacks.
OPC UA has defined profiles for lowest-level embedded solutions that will be secured by means outside the scope of OPC UA.


Advanced Security Capabilities

Application Authentication

URN:          https://opcfoundation.org/wiki/index.php/Security#Application_Authentication

Description
Application authentication allows OPC UA applications to identify each other. Each OPC UA application instance has a digital certificate (instance certificate) assigned that is exchanged during connection setup. The receiver of the certificate checks whether it trusts the certificate. This trust check is accomplished using the concept of TrustLists. TrustLists can be managed by vendor-specific means or by OPC UA Certificate Management.
If HTTPS is used, application authentication is not available. If authentication is required with this transport, it must be based on user credentials.

Usage Considerations

  • Ensures that a server only allows a trusted client to connect and that a client only communicates with trusted servers.
  • Requires that a PKI infrastructure is in place.
  • Not available with HTTPS transport.

Conformance Testing

Client Server

Application authentication is integral part of the security policies (except Security Policy - none).
It shall also be possible to configure for no application authentication, just user authentication and normal encryption/signing:

  • Configure Client application to accept all Server certificates
  • Certificates are just used for message security (signing and encryption)
  • User level is used for authentication

Application authentication is integral part of the security policies (except Security Policy - none).
It shall also be possible to configure for no application authentication, just user authentication and normal encryption/signing:

  • Configure Server application to accept all Client certificates
  • Certificates are just used for message security (signing and encryption)
  • User level is used for authentication

UserToken-X509

URN:          https://opcfoundation.org/wiki/index.php/Security#UserToken-X509

Description
Enable user authentication by means of a digital certificate (an X.509v3 identity token).

Usage Considerations

  • Must be issued to user and associated with a UA session
  • Requires that a PKI infrastructure is in place.

Conformance Testing

Client Server

Use of X.509v3 certificates to identify the Client user

Use of X.509v3 certificates to authenticate a user

UserToken-Kerberos

URN:          https://opcfoundation.org/wiki/index.php/Security#UserToken-Kerberos

Description
Enable user authentication by means of Kerberos tickets.

Usage Considerations

  • Requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.
  • Kerberos protocol messages are protected against eavesdropping and replay attacks.
  • Kerberos is the default authentication method for Windows and also available on most Linux platforms.

Conformance Testing

Client Server

Use of Kerberos tickets to identify the Client user

Use of Kerberos tickets to authenticate a user

User Impersonation

URN:          https://opcfoundation.org/wiki/index.php/Security#User_Impersonation

Description
Change the user identity associated with the session to a different user.

Usage Considerations

  • Enables a user to take ownership of a session with the aim to authorize the requested operation.
  • Often needed also when server acts as a client to other servers.

Conformance Testing

Client Server

Use the ActivateSession Service with a different user token to change the current user.

Support the ActivateSession Service with a different user token to change the current user.

User Authorization

URN:          https://opcfoundation.org/wiki/index.php/Security#User_Authorization

Description
Manage user roles to restrict or control OPC UA access to resources represented by a Server.
The way how users are managed and how authorization is actually performed (e.g. using role-based authorization) is outside the scope of OPC UA.

Usage Considerations

  • Restrict certain features to specialists.
  • Authorization can be as coarse-grained as allowing some users full access and others only read access. It can also be much finer grained such as allowing specific actions on specific resources by specific users or roles.

Conformance Testing

Client Server

<no specific requirement>

  • Provide means to administer users and their access permissions.
  • Expose user-specific permissions via the UserAccessLevel attribute.
  • Provide the configured authorization for the respective Services. E.g. reject writing values or calling methods if not allowed for the current user.