[기고문]OPC UA vs OPC Classic 보안

광역화, 세분화되는 네트워크 환경 속에서 시스템 보안 문제는 이제 자동화 업계에서도 중요한 이슈가 되고 있다. Industrial 4.0, IIoT, Smart Manufacturing, Smart Factory 등의 다양한 분야의 핵심 인터페이스로 주목받고 있는 OPC 역시 OPC Foundation을 주축으로 폭넓은 연구와 검토를 통해 최신의 보안 정책을 적용하기 위해 꾸준히 변화하고 있다.

초기 OPC 표준인 OPC Classic과 다양한 면에서 차별화된 개념과 기능을 제공하면서 생산 현장에서부터 MES, ERP레벨을 연결하면서 IoT, Cloud에 이르는 다양한 계층과 서비스 통합 인터페이스로 사용되고 있는 OPC UA는 OPC Classic과는 전혀 다른 보안 정책을 제공하고 있는데 이번 연재에서는 OPC UA의 보안 특징에 관해 설명하고자 한다.

OPC Classic과 OPC UA의 Security
OPC UA가 OPC Classic과 대별되는 차이점에 대해서는 지난번에 설명한 바와 같이 Windows에 국한하지 않는 다양한 OS 지원 여부, 다양한 플랫폼 간의 통신 지원 여부, 임베디드 시스템 혹은 디바이스부터 모바일, 엔터프라이즈 시스템, 클라우드에 이르기까지의 폭넓은 시스템 플랫폼 지원 및 내부적으로는 객체지향 모델링을 지원으로 확장이 가능한 구조라는 점을 배경으로 Security(보안)에 대해서도 많은 변화와 차이를 보이고 있다
 
OPC Foundation에서는 Microsoft Windows의 COM/DCOM을 기반으로 하고 있는 OPC Classic에 대한 보안에 대한 정의를 따로 하고 있지는 않으며, COM/DCOM 레이어 설정에 관한 사항 정도만을 포함하고 있고 관련 문서들도 모두 Windows의 DCOM에 기반한 보안 설정 및 기능에 관한 것들이 대부분이다. (OPC Classic Security에 대한 이슈들의 대부분은 DCOM과 TCP간의 데이터 액세스 제한과 관련된 것들이 대부분이다). 요약하면 OPC Classic의 보안은 Windows의 DCOM 기반의 사용자와 사용자에 대한 권한부여 방식으로 설정되며, 이러한 이유로 Windows 이외의 OS 시스템이 혼재된 경우 설정이 어렵다는 한계가 있다. 물론 이를 위한 3rd party의 솔루션들이 있기는 하지만 OPC Classic을 적용하는 경우는 거의 없다고 볼 수 있다. 또한 DCOM과 TCP간의 데이터 액세스가 각종 보안 정책으로 엄격히 제한되는 경우가 많아 실제 이에 관한 보안 이슈들이 많이 제기되고 있다.

한편, OPC Foundation에서는 OPC UA의 보안에 대한 표준 정의를 제공하고 있다. OPC UA 표준은 특정 OS나 communication transport 등에 국한되지 않기 때문에 이에 대한 보안도 transport layer 상위 단계를 정의하고 있다. OPC UA는 그림에서 보듯 TCP와 OPC UA사이에 새로운 transport 레이어가 추가될 수 있는데, 이때 OPC UA의 Security는 application의 변경 없이도 간편하게 Security 표준이 적용될 수 있도록 디자인되어 있으며, 이는 은행 등의 금융계통에서 사용되는 방식과 유사한 것으로, 높은 수준의 보안 모델로 평가되고 있다.

 

OPC UA 시스템 간의 메시지 서명 (Data flow Signing)
OPC UA를 설정해 본 적이 있다면 OPC UA가 Server와 Client로 구성되어 있다는 것과 그것보다 조금 더 깊게 알고 있다면 OPC UA의 Security가 certification방식이라는 것, 그리고 X.509 certificate standard를 적용하고 있다는 것까지도 알고 있을 것이다. 여기서는 OPC UA의 security가 적용하고 있는 X.509 certificate 표준이 standard public key 방식이라는 것과 OPC UA에 어떻게 적용되고 있는지 간단하게 설명하도록 한다.

메시지 서명 (The signing of the data flow)은 전송/수신 메세지의 변경이 불가능함을 의미한다. 즉, 서명을 위해서는 메시지 수신자에 의해 재생성된 암호화 서명(a cryptographic signature)이 필요한데, 암호화된 데이터는 오직 메시지 수신자만이 암호를 통해 복호화 할 수 있다.

좀 간단하게 설명하면, OPC UA Application들은 고유한 private key를 사용하여 메시지 서명과 hash(메시지를 읽기 난해한 형태로 만드는 수학적 알고리즘)를 구성하게 된다. 이렇게 hash처리 된 서명된 메시지는 이에 상응하는 public key certification(공인키 인증서)에 의해서 검증되는데 검증이 확인된 메시지는 안전한 애플리케이션으로부터 전송된 것으로 인증된다. 만일 전달 과정에서 메시지가 변경되었다면 (아마도 해킹 등과 같은 보안 공격에 의한), 메시지의 서명과 hash는 일치하지 않게 되며 이로써 도중에 변경되었음을 알 수 있다.

 
OPC UA OPC UA 시스템 간의 Data flow(메시지) Encryption(암호화)
private key를 통해 메시지가 올바른 애플리케이션에서 생성된 것이라는 보증이 되듯, public key도 메시지를 암호화하기 위해 사용될 수 있다. Public key로 메시지가 암호화되면 오직 상응하는 private key로만 메시지를 복호화할 수 있다. 만일 해커가 public key의 복사본을 가지고 있다 해도 그 public key로는 복호화를 할 수 없다는 점이 이 방식의 핵심이며, 만일 certification 발행자가 불분명하거나 불완전한 certification으로 메시지 서명이나 암호/복호화가 진행된다면 신뢰할 수 없는 통신임을 확신할 수 있다. OPC UA의 certification은 어떤 애플리케이션의 정보인지, 어떤 애플리케이션의 certification인지, 언제 발행되었는지, 누가 발행했는지, 언제까지 유효한지 등 모든 사항들을 제공한다.

위에서 언급한 내용은 신뢰할 수 있는 커뮤니케이션의 기본 컨셉으로서, 다시 정리하면, OPC UA 애플리케이션이 연결되면 OPC UA certification의 한 요소인 public key를 교환하는데 이때 자기의 Private key는 꼭 쥐고 있으며, 이를 통해 메시지의 사인과 암호, 복호화가 가능하다는 것이다.
Certification을 통한 신뢰방식이 미미하고 사소한 것이라고 생각할 지 모르지만, 한 애플리케이션이 신뢰할 수 있는 다른 애플리케이션과 연결하고 통신하기 위한 최선의 수단이며, 결국 닫힌 문은 당신이 상대방에게 키를 주기 전까지는 열리지 않는다는 점에서는 의미가 크다고 할 수 있을 것이다.  

참조 : Software Toolbox Technical Blog, OPC Foundation

브릿지웨어 이영주부장
-  Intellution Korea (1996~2002) : Application Engineer / Industrial Automation software
-  GE Digital (2002~2017) : Application Engineer / Industrial Automation software, Smart Factory
-  BridgeWare (2019~ ): OPC Training / Product Manager