Page tree
Skip to end of metadata
Go to start of metadata

Overview

The objective of this page is to help an OPC-UA developer understand the different security layers that are available, and help him to get a practical overview in some of this topics, such as certificate handling. There follows a brief overview of OPC-UA's means of security, studying the different available options. In addition, some practical guidelines are provided in order to help the developer make use of this security options.

OPC-UA Security in Brief

OPC-UA security is based on x509 certificates (described in more detail below in the Certificates section). The OPC-UA specification provides security at different levels.

  • Clients can only create sessions with trusted servers. Servers only accept sessions from trusted clients. This is the most basic level of OPC-UA security and is intrinsic to the protocol. The word 'trust' here is in the context of trusted x509 certificates, whereby a Certificate Authority (CA) grants application certificates to a client and server and, if both client and server are correctly configured, then each trusts the other. More on certificates and trust trees below.

 

  • Session traffic can be signed, signed and encrypted or neither. The x509 application certificates can be used to create secure communications channels between clients and servers. Servers publish descriptions of their endpoints, each endpoint description details the session channel security settings. Connecting clients must be capable of setting up channels adhering to the endpoint security requirements.
Session traffic encryption option

Description

unsigned and unencryptedAttackers can eavesdrop on client/server traffic and modify the traffic (a man-in-the-middle style attack). Traffic may be modified to try and corrupt the client/server nodes; make them crash for example.
signed and unencrytedAttackers can eavesdrop on messages but not modify them. More accurately, message contents are signed at their source node (i.e. client/server) and then verified using that signature at their destination. Messages which fail this verification (e.g. messages which have been modified by a man-in-the-middle) will be identified as such and rejected.
signed and encryptedAs above plus the message contents are encrypted using the private key to prevent eavesdropping. The target node can un-encrypt the contents using the other node's public key (exchanged at session initiation, described later).

 

  • Clients can pass a token to the server which identifies a user. This is the basic means by which a server can constrain user access to the address space of the OPC Server within a session - e.g. Alice can call method reset(), however Bob cannot. The specification states only that a token should be passed, the details of how the token is consumed server-side is implementation specific. From the point of view of CERN, relying on server implementations from diverse 3rd parties, this requires special attention. More on this below. Note also that the user token forms the basis of auditing.

Certificates

Every OPC-UA application, client or server, must have it's own, unique, x509 certificate composed of a public and private key. Efficient administration of these certificates is important for the smooth running of large scale OPC-UA application deployments such as is envisaged at CERN. Certificates are usually generated by CAs (Certificate Authorities). CAs can range in complexity from local self-signed authorities to centrally managed corporate CAs. Also, there is the possibility that the certificate was not generated by CA, being in this case a self-signed certificate.

X.509

An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate.

An X.509 certificate contains information about the identity to which a certificate is issued and the identity that issued it. Standard information in an X.509 certificate includes:

 

  • Version – which X.509 version applies to the certificate (which indicates what data the certificate must include)
  • Serial number – the identity creating the certificate must assign it a serial number that distinguishes it from other certificates
  • Algorithm information – the algorithm used by the issuer to sign the certificate
  • Issuer distinguished name – the name of the entity issuing the certificate (usually a certificate authority)
  • Validity period of the certificate – start/end date and time
  • Subject distinguished name – the name of the identity the certificate is issued to
  • Subject public key information – the public key associated with the identity

 

  • Extensions (optional, but some extensions are compulsory for OPC-UA valid certificates)

(Reference)

Secure Sockets Layer (SSL)

SSL is a cryptographic protocol, designed to provide communication security over the Internet. It makes use of X509 certificates and hence asymmetric cryptography. This provides tools that allow for data/message confidentiality and message authentication codes for message integrity.
To produce and manage these X509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates.

When the final server and client try to establish a connection, they do an exchange of information in order to verify each other's identity. This is usually referred to as hand-shaking procedure, in which both the client and the server have to exchange the public parts of their certificates in order to check if the connection is secure.

SSL Hand-Shake protocol

The Hand-Shake protocol is a set of message exchanges between the client and server before normal communications begin, it allows both the server and client to verify whether the communication channel is secure and whether they “trust” each other. The figure below describes the series of steps of this communication.

Trust

The term 'trust' in the context of certificates is described here in order to facilitate understanding of the subsequent points regarding certificate management. Certificate authorities control a tree of trust, each node in the tree being a certificate. 

In the diagram above the client and server certificates have been signed by (parent) certificates, Certificate 1 and Certificate 2 respectively. Certificate 1 and Certificate 2 in turn have both been signed by the CERN CA Root Certificate. Applications trusting the CERN CA root certificate can be said to trust all certificates under the CERN CA root certificate hierarchy.

Note also in the diagram above that Certificate 1 has signed 2 child certificates. Applications needing to limit the scope of their trust to only Certificate 1 or its children should trust only Certificate 1.

OPC-UA applications generally specify trust via a 'trusted certificates' directory, incoming certificates are deemed trustworthy or otherwise by a software process which compares the incoming certificate against the contents of the directory. If the directory contains either a) A copy of the incoming certificate itself or b) A copy of the signing certificate (i.e. higher up the trust tree) then the certificate is trusted. Some examples:

  • A client that which trusts any application under the CERN CA trust tree should have a copy of the CERN CA certificate in this folder.
  • A server which should trust only a single application should have only the certificate of the trusted application in this folder.

Lifecycle

Certificates are created, after which they can expire or be renewed, they can also be revoked.

Expiry. A certificate which has passed its expiry date is not a valid certificate and thus will be rejected from any application (including applications which trusted the certificate prior to expiry). Certificates should be renewed before they expire.

Revocation: A CA maintains a revocation list containing certificates that are no longer to be trusted (a certificate may be added to the list, for example, in the event of it having been compromised). OPC-UA applications should refer to the CA revocation list to check whether received certificates have been revoked. OPC-UA applications which self-manage certificates (i.e. do not use a central CA) can maintain and reference their own local revocation list.

Certificate types

In this section, an overview on the different kind of certificates will be provided. The certificates will be of one type or another depending on who is the issuer (signer) of this certificate.

Self-signed

Using a collection of freely available tools, such as OpenSSL, anyone can create and sign x509 certificates. This is especially useful during development phase or very small scale roll-outs; the developer can simply create unique certificates for all OPC-UA applications and manually manage trust by copying the public piece of these certificates into each application's 'trusted certificates' directory. In this case trust is essentially micro-managed manually: The developer defines the entries of every application's trust list one at a time (by copying in each trusted application's certificate to the target trust list). For smaller deployments this solution is tenable. As the scale of the deployment increases however, the amount of effort required to manage every application's trust lists increases too, plus the overhead of managing new certificate creation, renewal/expiry and revocation.

Taking expiry for example in this self-managed certificates problem scenario: A certificate will be valid on creation (typically for 12 months) after which it expires. The OPC-UA application is installed and setup - with a valid certificate - and works smoothly for 12 months then the certificate expires, thereby becoming invalid. Failure to renew the certificate may result in the client/server failing to communicate.

Local Certificate Authority

A central Certificate Authority provides more efficient macro-management compared to using self-signed certificates. A central Certificate Authority for OPC-UA applications should provide (at least) the following roles:

  1. Certificate creation.
  2. Certificate signing.
  3. A root certificate (i.e. such that applications can specify trust for this root, thereby implicitly stating that they trust other certificates signed by the CA).
  4. Certificate renewal.
  5. Certificate expiry reminders (which could start with automated emails, say, 3 months before a certificate is due to expire).
  6. Certificate revocation and making a revocation list available to all parties/software concerned.
Objective

The idea is to have a hierarchy in which the developer is his own root certification authority. For this example, I will call my certification authority Opc Support.

The public part of this certificate will be provided to the different external servers and clients (the servers and clients that will communicate with the servers and clients created by the developer), and this way the certificates signed by the CA will be automatically trusted if Opc Support is trusted. The following figure shows how the process of generating new certificates, for client or servers would work:

The different formats used in this process are the following:

  • KEY: File that contains the private key of a certificate. The extension .key is to denote that it is a private key, but the format is PEM format.
  • PEM: Most common format used by the certificates. This format is often used with different extensions, such as .pem, .crt, .cer and .key. It is compulsory to use this format to sign, and that is why we use it in the CA certificate (the one that will sign the server and client certificates)
  • DER: Different format, which is binary based. Usually comes with the extensions .der or .cer. This is the standard format used in OPC UA, so the clients and servers will be expecting certificates in this format. This is the reason why the final generated certificates, and also the certificate authority need to use this format.
Certificate Generation

The following OpenSSL commands will generate the certificates for the setup explained in the previous section.
The OpenSSL library often comes preinstalled in Linux machines, as for example in the CERN’s scientific Linux versions. On Linux, most of the commands require admin permissions in order to work properly. On windows, the library can be downloaded from the OpenSSL webpage.

1)      Generate private key of the certificate authority Opc Support. The key will have a length of 2048, which is the most common option (more secure than 1024 and less computationally intensive than 4096). It will also be password protected (option –des3)

         openssl genrsa -des3 -out OpcSupport.key 2048

         Note: This is the private key of the certificate authority, and it will be used to sign certificates. It is critical that it is stored in a safe place, any certificates signed with this will be trusted by all servers/clients.

2)      Generate the OpcSupport X509 certificate, the command below specifies a validity period of 360 days, and using a configuration file that can be seen later in this section to overwrite some OpenSSL default generation options. This is very important since the OPC UA specification needs extra parameters  (extensions) to          be filled in order to make the certificates standard, and these are defined in the config file This parameters are keyUsage, extendedKeyUsage and authorityKeyIdentifier.

 openssl req -x509 -new -nodes -key OpcSupport.key -days 360 -out OpcSupport.pem -config openssl.cfg -extensions v3_req

 After entering this command the user will be prompted to fill several details regarding the certificate.

 This certificate will be used to sign our custom certificates later.  Also, since for this example the OpcSupport certificate acts as the CA, the public part of this certificate (OpcSupport.pem) will be provided to several clients/servers, as it is the root of our trust chain.

3)      Generate the private key for our custom server, also with a size of 2048 and password protected.

 openssl genrsa -des3 -out server.key 2048

4)     Generate a certificate request with the server private key. This request will be signed by our certificate authority in the next step. The user will be prompted again to fill the details for the certificate.

 openssl req -new -key server.key -out server.csr

5)      Generates the server certificate (server.der) signed by the CA Certificate (Opc Support). This will use again the same config file, and we specify that it should use the extensions from the section v4_req of that config file.

 openssl x509 -req -in server.csr -CA OpcSupport.pem -CAkey OpcSupport.key -CAcreateserial -out server.der -outform der -days 360 -extfile openssl.cfg -extensions v4_req

The configuration file used by the steps 2 and 5 is the following:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
default_md = sha1

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = CH
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Geneve
localityName = Locality Name (eg, city)
localityName_default = Meyrin
organizationName = Organization name
organizationName_default = CERN
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = EN ICE
commonName = Common name
commonName_default = Opc Support
commonName_max = 64
emailAddress = Email Address
emailAddress_default = opc.support@cern.ch

[ v3_req ]
# Extensions to add to a certificate request (CA)
basicConstraints = CA:TRUE
keyUsage = nonRepudiation, digitalSignature, digitalSignature, keyCertSign
extendedKeyUsage = serverAuth, clientAuth, codeSigning
subjectAltName=email:opc.support@cern.ch
authorityKeyIdentifier = issuer

[ v4_req ]
# Extensions to ass to a certificate request (final node)
basicConstraints = CA:FALSE
keyUsage = nonRepudiation
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = email:opc.support@cern.ch, URI:urn:PCEN33040:UnifiedAutomation:UaServerCpp
authorityKeyIdentifier = issuer

The section [req_distinguished_name] defines the default values of the different standard attributes used by open SSL certificates, while the section [ v3_req ] and [ v4_req ] defines the extensions needed by the OPC UA specification (the values must be different for a signing CA than for a final node if we want to prevent the final node to be able to sign other certificates), for the CA and the final node respectively. Obviously the values of the different items should be changed according to the case, this is just an example.

After this the only thing left to do is to trust your root certificate authority (OpcSupport in this example) with the servers and clients, so all the subsequent certificates that it signs are trusted.

Future Consideration - Automated Application Certificate Management

In the future, if this is considered as the default solution, this must be automated in some way. One solution should be provided, either a virtual machine with everything ready for the automatic generation of the CA and the scripts, or some kind of web service, similar to what CERN CA offers.

Corporate Certificate Authority

Note that using a CA (as opposed to self-signed certificates) clearly divide the roles and responsibilities as regards application administration and certificate administration, providing a clear interface for certificate management. Fortunately CERN has its own CA, managed by the IT department (in fact the CA is used for much more than OPC-UA applications) with clearly defined policies and practices

Here is the workflow from the specification (part4 v1.01) for OPC-UA application as regards application certificates:


The current state of affairs as regards certificate creation is the following: CERN CA site can 'manually' generate certificates by following the steps in a certificate creation wizard. The problem with this is that the certificates for OPC UA don't have the same requirements as other applications, and a few extra parameters are needed in order to make the certificate conform to the OPC UA especification. These parameters (or extensions) are not supported by the CERN CA web service, and therefore the developers can't use this for their clients and servers at the moment.

The CERN CA provides (via HTTP) a revocation list plus a copy of the certificate used to sign all certificate requests. For OPC-UA applications trusting all applications identified by valid CERN certificates, these 2 pieces of information are sufficient. Note that the revocation list and signing certificate should be cached in a local directory and refreshed periodically to handle the case of applications being unable to reach the CERN-CA site.

These applications would then require the following:

  1. Configuration for the CERN-CA URL for the revocation list
  2. Configuration for the CERN-CA URL for the signing certificate (at the top of the chain of trust)
  3. Configuration for the local directory (or just hardcoded to be relative to the application install directory)
  4. A daemon thread with poll period configuration to refresh the local cache
Future Consideration - Automated Application Certificate Creation

In future, if this is the default solution chosen, an automatic service should provide certificates following the OPC UA standards. Also, it would be even better if we provided a separate web service, in a different section of CERN CA, that generated OPC UA compilant certificates after asking for the needed information to the user. (visible from the protected production network and the general purpose network) for certificate creation and renewal. OPC-UA applications could wrap these services to simplify the steps on the user side - the installer could wrap certificate creation and the application itself could wrap renewal. Initially, however, it is probably better to have a well known, well documented process which the user should carry out at the CERN-CA site.

Session Channel Encryption

Client interrogate servers to determine the endpoints it exposes and the security setup per endpoint. For a client to establish a session with a server it must first create a secure channel with the server which complies with the endpoint security requirements. The OPC-UA specification states that it is possible that message signing/encryption could be carried out with a certificate other than the application certificate. For simplicity, I suggest that the x509 certificate used for application identity is also used for message signing and encryption, the cost of this simplicity being that an attacker could use an application's compromised certificate to read/modify intra-session messages). 

From the OPC specification here is the workflow of a client setting up a secure channel prior to starting a session with a server endpoint:

Encryption Options

OPC-UA server implementations should allow for endpoint security configuration. Administrators should be able to stop the server, edit the security constraints of endpoints and restart the server. Note that if servers are able to specify any of the security options above then client applications must be capable of handling all options.

User Access Control and Auditing

The term auditing here is taken in the sense of OPC server implementations recording who did what and when. Essentially this is a logging task, whereby each request to an OPC-UA server is logged against the user identified by the user token passed to the server from the client. Ideally, since the semantic content of audit logs is the same, all audit log files could be written in a consistent format.

The term 'access control' here is taken to mean allowing users access to data and functions according to their role. Note as a comparison to OPC-Classic, the possibility of access control is a new feature of the OPC-UA specification: OPC Classic delegated all security to the DCOM layer - an OPC Classic client which could access the server could access all of the server. The OPC-UA specification mandates that clients pass a user identity token to the server, however, what the server does with that token is implementation specific. CERN depends on OPC Server implementations from multiple vendors who, from the specification, are free consume that token to implement access control however they see fit.This can be problematic for CERN: on the one hand CERN would like to use standard COTS software, on the other hand in order to have a common means of auditing and access control across all OPC-UA applications in the organisation, the software has to tie in at some level with CERN infrastructure.

The diagram below is taken from the OPC-UA specification (section 4 v1.01) and shows the client/server workflow for creating a session. Note the ActivateSession request sending the user ID token to the server.

See OPC-UA specification: section 4 (services)

  • 7.36 describes the UserIdentityToken (username/password, X509 certificate, WS token including Kerberos tickets)
  • 7.10 Endpoint Description describes how the server returns, in response to a GetEndpoints() call, a description of the UserIdentityToken types a server endpoint accepts.
  • 5.6.3.2 the ActivateSession call passes the client UserIdentityToken to the server is the request.

 

CERN's BE-CO department have the RBAC (Role Based Access Control) system which allows configuration of access control as follows:

  • An entire application's exposed API (data/functions) is listed  - subsets (called property groups) are then created from the entire list, the same item can appear in multiple property groups.
  • Users are assigned roles (a user can have multiple roles)
  • Roles can access certain property groups.

Identifying the User at the Client

The user ID token types a client can pass to a server are:

  1. The 'anonymous' token: Useless for auditing and access control.
  2. A username/password: This is the simplest solution, already supported in PVSS v3.10. However, the username/password is at the OPC-UA driver level and therefore the account detail is per application rather than per logged in user. The username/password would have to reference a service account rather than the account of the user.
  3. x509 certificate: Note that this is not the certificate which identifies a user but a certificate identifying a user account.
  4. WS-Security compliant tokens: Various forms of user identity fit into this category, one interesting case is Kerberos tickets. CERN has an existing Kerberos infrastructure (managed by the IT department) which could be used as part of a system providing access control on a per-logged-in-user level. Logged in CERN users can request a Kerberos ticket from the infrastructure  - a ticket unique to the user - which can then be passed to the server. A server which can 'speak Kerberos' could then use this ticket to resolve the user's identity for auditing and logging. At time of writing, PVSS v3.10 does not support sending Kerberos tickets.

Verifying the User and Their Access Rights at the Server

Regardless of the type of user ID token used, auditing and verifying user commands requires a means of verifying the user's identity from the token. This requires some form of integration into CERN infrastructure holding account information - the server would send the user token (for example username and password) to some service and receive a true or false, either this is a valid account or not.

Furthermore constraining access rights based on the user requires that not only is the user token verified but additionally command requests are compared against a known 'grid' of access rights. These access rights are CERN specific information and would have to be configured via some (yet to be decided) CERN application and published for consumption by OPC Servers. The grid of access rights could be something along the lines of the following:

¿ Role ¿
¿ Node ID in OPC-UA Server namespace ¿

Observer

Controller

Expert

Object property A

R

R/W 

R/W 

Object B

R

R/W 

R/W 

A Critical Function C

-

-

R/W 

The full process for validating a user's right to execute a given command (read/write) against a given node could be something along the lines of:
Note that for initial implementations, the above diagram with connections to CERN Kerberos and LDAP servers, is probably overkill. Note, however, that the basic blocks of Authentication, Role Mapping and Authorisation should feature in initial implementations however the implementations could be stubbed or substituted with simplified means such as regular expression based access maps stored on the local disk etc.

In order to have Role Based Access across all OPC-UA Server implementations, 3 approaches have been envisaged: Full implementation by the OPC-UA vendors, a library which CERN builds and provides to vendors and finally a method whereby role based access is completely abstracted out of any vendor implementation and into a proxy OPC-UA server.

1. Vendor specific (Black Box)

CERN specifies requirements and provides these to OPC-UA server vendors. Contents of the specification would have to include (at least)

  • The type (or types) of ID tokens servers must be able to handle.
  • The means of resolving user ID tokens to CERN accounts. For example in the case of username/password tokens, how should this information be used? From an administration point of view servers having their own internalised list of usernames and password is untenable. The usernames and password could be sent to a CERN service for verification and account resolution, however it is a risk to expose account logins to 3rd party software.
  • For the purposes of access control, servers must also have some means of configuration whereby requested commands plus user ID are compared against an access control 'grid' to verify whether the requested command is permissible. In a non-trivial case the contents of the grid would be dynamic and therefore servers would have to query some external CERN service.
  • A description of how commands should be audited (i.e. how should it appear in a logfile). This could, in fact vary per vendor, however a consistent approach to auditing would reduce the perceived complexity of the OPC-UA scene.

Pro

Con

CERN does not carry out any software development. Effort is in the specification/testing role. Note development will be required to provide the access grid contents.

Smaller OPC Server vendors (CAEN/ISEG/Wiener for example) could be persuaded to implement OPC servers subject to CERN specific requirements but probably not larger vendors (Siemens, Schneider etc). This would result in custom implementations rather than standard COTS implementations - a possible support problem in the long term.

CERN does not carry out maintenance in regards how the OPC Server implementation uses the user ID tokens (maintenance will still be required to provide the access grid)

Implementations between vendors are unlikely to be the same, more likely are varying interpretations of the specification (for example on behaviour in the event of a user ID having insufficient rights for a command).

 

Security requirement changes are done at the pace and price of the vendor. From experience the speed of OPC software delivery can be rather slow.

2. CERN User Access Library Embedded in 3rd Party OPC Servers

One possibility to help address the problem of different vendors providing slightly differing server implementations regarding the use of user ID tokens and access grids etc is for CERN to provide a library (or libraries - cross platform potentially) encapsulating the process of verifying user accounts from tokens passed in from the client and verifying access rights using some (CERN created) access grid. this library would perform audit logging and access rights verification. Note that 3rd party vendors would have to compile this library into their OPC Server builds.

Pro

Con

Audit and access control functionality would be consistent across vendor implementations.

The OPC servers will not be standard: Vendors will be required to make special 'CERN' builds which delegate audit/access to the CERN library.

Changes to the library could be implemented quickly and in close collaboration with CERN's OPC Server user community.

Whilst changes to the library could be made quickly, the vendors would still have to create new builds incorporating it.

 

The blame game: Having an OPC Server made partly of CERN components and partly of 3rd party vendor components introduces the possibility that each blames the other for faults occurring in the whole application (crashes, memory leaks etc).

3. Proxying 3rd Party OPC-UA Servers with a CERN OPC-UA Audit and Access Server

The major problem with the two possibilities for consistent audit and access control above are that they violate the principal of using COTS software. In either case, the vendor is effectively creating a 'CERN build' of their OPC server, increasing the chances of support headaches over the long term. To address this, audit and access control could be removed entirely from the vendor OPC server implementations and this functionality put in to a proxy server sitting between the OPC-UA clients and the vendors' servers. In this case clients do not communicate with the 3rd party OPC servers but instead clients communicate with a (CERN built) OPC-UA proxy server which in turn communicates with the 3rd party OPC.

All the user ID token validation and comparing requested commands with an access grid is handled by the proxy server. If the proxy server deems that the current user is allowed to perform the requested command then the command is passed to the target OPC Server, otherwise the client is sent a rejection message.

Logically, the Client/Server setup will be as follows:

Note that OPC-UA does not intrinsically provide support proxy/redundancy support, however the notion of OPC-UA server federation is supported by the specification: the specification quotes (Part 4 - section 6.3 on redundancy) "OPC UA does not provide redundancy, it provides the data structures and services by which redundancy may be achieved in a standardized manner." Every command between the client and target OPC-UA server would be inspected by the proxy server. Note that the proxy server should be transparent - the client should issue all commands as if it has a direct connection to the target server. Implementing this in the proxy server is non-trivial: Subscriptions created and edited by clients, for the purpose of monitoring data in the target servers, must be replicated by the proxy server - so the proxy server must support a subscription from the client, create a mirror subscription with the target server and reflect updates from the target server back to the client.

Pro

Con

Vendor OPC-UA servers do not need to contain any functionality specific to the CERN environment.

With a proxy server sitting between the client and the target server then at least the following consideration must be well catered for:
- Performance: Introducing an extra link between the client and server will likely have an impact on performance. This should be as small as possible.
- Fail over: The proxy must provide high availability of proxy servers, most likely by running redundant nodes, with the ability to seamlessly fail-over from a current node to a redundant node.

Audit logs will be consistent

Development overhead. The proxy server must be developed and tested.

Access behaviour (e.g. the message the client receives in the case of refusal for a command) will be consistent.

Maintenance overhead. The proxy servers must be maintained.

Changes to the security access grid can be implemented and deployed without any delays arising from 3rd party vendors.

 

Having a proxy server between clients and target servers can be leveraged to provide a standard means (i.e. throughout CERN) of redundancy. COTS servers need not provide redundancy functionality

 

Conclusions

Certificates

Of the 3 different options analyzed, only 2 of them are viable (Corporate CA or Local CA), leaving the self-signed certificates only viable as a temporal solution in the development phase of servers and clients.

Creation, renewal and revocation should not be handled manually independently of what method we choose in the end, administration of self-signed certificates will most likely become chaotic and unreliable with certificates quietly expiring. Initially the manual interface is sufficient, but later there are several options to be considered, all of them providing a "Certificate Manager" functionality:

  • Self developed web service or application for managing the certificates using a local certification authority.
  • Virtual machine provided with different scripts in order to handle the certificate managing using a local certification authority (most likely a temporal solution).
  • Web service or application for managing the certificates using CERN as the certification authority.

Auditing and Access Control

The openness of the specification on this point is a problem for a large organisation, like CERN, which depends on a variety of implementers. Relying on all vendors to implement auditing and access control in a cohesive manner (or indeed at all) is unrealistic. To provide cohesive auditing and access control CERN would need to take control of this functionality: Either by (a)'injecting' the desired functionality into vendor implementations in the form a CERN built library, vendor implementations pass all commands through it or (b) removing it entirely by putting CERN built proxy OPC-UA servers between the clients and vendor servers, these proxy servers log and inspect commands before passing them on (or not) to the vendor servers. Note that CERN effort in either case will be non-trivial and imply long term maintenance commitment.