By Darek Kominek – SME MatrikonOPC
As a technology that revolutionized how we access control automation data, OPC has become the de facto standard for open data connectivity. With such broad acceptance, however, comes the responsibility for vendors to ensure effective safety is built into their OPC products to protect their customers' sensitive data. In other words, just as modern cars need to provide safety devices such as airbags, anti-lock brakes and seatbelts for passenger safety, OPC Servers need to implement data-safety mechanisms that protect data by controlling who gets access to it and what they can do with it.
The first generation of OPC, referred to as "OPC Classic," made open-connectivity a reality, but faced connectivity and network IT security issues due to its reliance on Microsoft's DCOM architecture for its underlying communications. This focused users' and vendors' attention on higher-level network issues, such as how to make OPC work in firewalled environments and what to do when cross-domain usernames/passwords did not match. This overshadowed the importance of implementing security within the OPC Servers and, as a consequence, the vast majority of OPC Classic implementations did little to control what an OPC client could do once it connected to an OPC Server. In the car analogy, this would amount to worrying more about road infrastructure and border crossing security than about the safety of the people being transported by the cars. To address this, the OPC Foundation released an OPC security specification focused on enabling OPC Servers to be aware of what users were trying to connect to an OPC Server and to subsequently use that information to control what connected OPC clients were allowed to do, but few vendors bothered to implement it in their OPC Servers.
The release of the OPC Foundation's next generation OPC standard called OPC Unified Architecture (OPC UA) provides a platform-independent design that makes OPC Classic DCOM issues a thing of the past and makes enterprise-wide data connectivity easier than ever. While a lot of work went into ensuring the integrity of OPC UA communications between UA Clients and UA Servers, the question remains: What safety measures are vendors building into their OPC products to protect the OPC data itself? The answer, based on the OPC products in the market, is it depends. While the vast majority of vendors only focus on the IT security aspects dealing with secure data exchange between OPC Clients and OPC servers, they implement virtually no safeguards to protect what OPC data is available to different users, or what they can do with the data they have access to.
Fortunately, there are exceptions. MatrikonOPC recognized the need for providing users with complete OPC security early on and, as a result, all of its servers comply with the OPC Foundation's OPC security specification. To make this security truly effective, MatrikonOPC also took the extra step of fully integrating the security information the OPC specification provides to the OPC Server to allow it to enforce OPC data access and usage down to the per-user-per-tag levels.
With the dawn of the OPC UA era and its ability to deliver true enterprise-wide ease of data access, all data on any OPC Server an OPC Client connects to is by default accessible to that OPC Client. The potential benefits of such ease of access are great, but so are the risks if access to sensitive or critical data is not properly controlled. As with all safety and security solutions, a balance must be struck between the safety features built into the products and the way people use them.
In OPC, this means people need to follow safe OPC connectivity practices while OPC vendors need to build appropriate safety mechanisms into their products. In the car analogy, drivers need to do their part by driving defensively, but car manufacturers must do their part as well. After all, in a world where car seatbelts, airbags, antilock brakes and crumple zones are all proven ways of protecting cars' precious cargo, would you drive your family in a vehicle without any protection? Didn't think so. Why not do the same for your OPC Data?
Darek has over 15 years' experience developing industrial software, designing and integrating OPC architectures, and running training courses in every corner of the world. Darek began working with OPC soon after the first OPC specifications were released in the 1990s. To date, he has taught thousands of control professionals about OPC best practices. His main interest is in helping people best leverage technology to resolve increasingly complex control automation challenges.
Darek often works with the OPC Foundation to help spread the message about OPC UA and OPC Classic, he writes articles on the topic, and regularly presents both in person and on the web about the advantages of OPC and how to use it safely and reliably.
