I have several reactors in my batch process that are controlled day-to-day by my DeltaV DCS. Two of these reactors are used to produce a proprietary product which contain governmental information that cannot be shared in an OPC format. However, these reactors are also utilized to batch other products that are not proprietary in nature, and are currently accessed via OPC tunneling. The raw material and production parameters for the proprietary processes have been identified and documented when the product is batched and when it is not. We are at a lost. We wish to implement our OPC tools and opportunities, but we need to separate and eliminate the possibility of exposing the proprietary in our OPC data tunneling. Does anyone in our DeltaV Forum have any suggestions that help us to know how we can segregate this information.?
First, OPC tunneling removes the user-based security. The Tunneling application has its own user security access to the OPC server and as such all tunneled clients share the same user security. Tunneling solved Firewall port issues for OPC DA, but the compromise takes away individual security. OPC UA is now available on DeltaV 14 and should remove the need to use a tunneling wrapper. OPC DA clients can be wrapped in OPC UA if they are not natively available as such. With OPC UA, you can control the clients that can connect to the OPC Server, requiring them to authenticate using security certificates. You can also encrypt the data. Now that we have a new hammer, are we able to nail this problem? (Bad pun, I know). As you know, the DeltaV user security only prevents a user from having write access. Read access is pretty much open, and as long as you can connect to the server, you can ask for any data to be sent for you to consume. So, to me, I'm thinking the only way to secure the data during those proprietary data runs is to disconnect unapproved clients. If you altered the active certificate on the OPC Server, the clients using that certificate would by definition not have access. Clients with the new certificate would. Hmm. That sounds onerous and a manual process, subject to human error. I'm thinking this may be better solved one layer up in the data stack. That is, introduce a data broker that can manage data access more selectively than the OPC Server. Just putting out ideas, but if you had the DeltaV Data placed in a data lake and contextualized based on certain operational parameters, this layer would redirect the Unit data to a secure data set when data is proprietary, and that data set only available to specific client. Otherwise, the data goes to the Normal data set that is accessible by others. This would not require any changes in the DeltaV OPC layer since you'd be relying on a higher-level broker for security access. The Clients would be redirected to this new layer, and you would secure the DeltaV OPC Server from access by any outside entity, except your data broker. OPC UA could help immensely for this with the certificates. Bottom line, you cannot block access to any data via OPC DA as any connection can read any parameter. You could hide the data from the normal parameter, but if a user knows the path, they can ask for it. There is no way to block a read.
Andre Dicaire
In reply to Andre Dicaire: