스마트매뉴팩터링(Smart Manufactruing), IIoT의 핵심 인터페이스로 OPC UA가 주목 받고 있다. OPC UA는 폭넓은 적용 범위와 유연한 구조로 산업표준으로 자리잡고 있다. OPC UA의 보안 기준 및 데이터 암호화에 적용된 기본 개념에 대해 알아보도록 한다.
광역화, 세분화되는 네트워크 환경 속에서 시스템 보안 문제는 이제 자동화 업계에서도 중요한 이슈가 되고 있다. 인더스트리얼4.0, IIoT, 스마트매뉴팩터링, 스마트팩토리(Smart Factory)등 다양한 분야의 핵심 인터페이스로 주목받고 있는 OPC 역시 OPC 파운데이션(Foundation)을 주축으로 폭 넓은 연구와 검토를 통해 최신의 보안 정책을 적용하기 위해 꾸준히 변화하고 있다.
OPC UA는 초기 OPC 표준인 OPC 클래식(Classic)과 다양한 면에서 차별화된 개념과 기능을 제공한다. 즉 생산 현장에서부터 MES, ERP레벨을 연결하면서 IoT, 클라우드(Cloud)에 이르는 다양한 계층과 서비스 통합 인터페이스로 사용되고 있다.
OPC UA는 OPC 클래식과는 전혀 다른 보안 정책을 제공하고 있다.
OPC Classic과 OPC UA의 Security
OPC UA가 OPC Classic과 대별되는 차이점은 윈도우(Windows)에 국한하지 않는 다양한 OS 지원 여부, 다양한 플랫폼 간 통신 지원 여부, 임베디드 시스템 혹은 디바이스부터 모바일, 엔터프라이즈 시스템, 클라우드에 이르기까지의 폭 넓은 시스템 플랫폼 지원, 내부적으로는 객체지향 모델링 지원으로 확장 가능한 구조라는 점이다. 이런 배경으로 보안(Security)에 대해서도 많은 변화와 차이를 보이고 있다.
OPC Foundation에서는 마이크로소프트 윈도우의 COM/DCOM을 기반으로 하고 있는 OPC Classic에 대한 보안의 정의를 별도로 하고 있지 않다. 다만 COM/DCOM 레이어 설정에 관한 사항 정도만을 포함하고 있다. 관련 문서들도 모두 윈도우의 DCOM에 기반한 보안 설정 및 기능에 관한 것들이 대부분이다.
OPC Classic Security에 대한 이슈들의 대부분은 DCOM과 TCP간의 데이터 액세스 제한과 관련된 것들이 대부분이다.
요약하면 OPC Classic의 보안은 윈도우의 DCOM 기반 사용자와 사용자에 대한 권한부여 방식으로 설정된다. 이러한 이유로 윈도우 이외의 OS 시스템이 혼재된 경우 설정이 어렵다는 한계가 있다.
물론 이를 위한 서드 파티(3rd party)의 솔루션들이 있기는 하지만 OPC Classic을 적용하는 경우는 거의 없다고 볼 수 있다. 또 DCOM과 TCP간 데이터 액세스가 각종 보안 정책으로 엄격히 제한되는 경우가 많아 실제 이에 관한 보안 이슈들이 많이 제기되고 있다.
OPC Foundation에서는 OPC UA의 보안에 대한 표준 정의를 제공하고 있다. OPC UA 표준은 특정 OS나 커뮤니케이션 트랜스포트(communication transport) 등에 국한되지 않기 때문에 이에 대한 보안도 트랜스포트 레이어(transport layer) 상위 단계를 정의하고 있다.
OPC UA는 TCP와 OPC UA사이에 새로운 트랜스포트 레이어가 추가될 수 있다. 이 때 OPC UA의 보안은 애플리케이션(application)의 변경 없이도 간편하게 보안 표준이 적용될 수 있도록 디자인되어 있다.
이는 은행 등의 금융계통에서 사용되는 방식과 유사한 것으로, 높은 수준의 보안 모델로 평가되고 있다.
OPC UA 시스템 간 메시지 서명 (Data flow Signing)
OPC UA를 설정해 본 적이 있다면 OPC UA가 서버(Server)와 클라이언트(Client로 구성되어 있다는 것을 파악했을 것이다. 조금 더 깊게 알고 있다면 OPC UA의 보안이 인증(certification)방식이라는 것, 그리고 X.509 certificate standard를 적용하고 있다는 것까지도 알고 있을 것이다.
여기서는 OPC UA의 보안이 적용하고 있는 X.509 certificate 표준이 일반표준키(standard public key) 방식이라는 것과 OPC UA에 어떻게 적용되고 있는지 간단하게 설명하도록 한다.
메시지 서명(The signing of the data flow)은 전송/수신 메세지의 변경이 불가능함을 의미한다. 즉, 서명을 위해서는 메시지 수신자에 의해 재생성된 암호화 서명(a cryptographic signature)이 필요한데 암호화된 데이터는 오직 메시지 수신자만이 암호를 통해 복호화 할 수 있다.
좀 간단하게 설명하면, OPC UA 애플리케이션들은 고유한 개인 키(private key)를 사용해 메시지 서명과 해시(hash, 메시지를 읽기 난해한 형태로 만드는 수학적 알고리즘)를 구성하게 된다.
해시 처리 된 서명 메시지는 이에 상응하는 공인키 인증서(public key certification)에 의해 검증된다. 검증이 확인된 메시지는 안전한 애플리케이션으로부터 전송된 것으로 인증된다.
만일 전달 과정에서 메시지가 변경됐다면(아마도 해킹 등과 같은 보안 공격에 의한), 메시지의 서명과 해시는 일치하지 않게 된다. 이로써 도중에 변경됐다는 것을 알 수 있다.
OPC UA OPC UA 시스템 간의 Data flow(메시지) Encryption(암호화)
개인 키(private key)를 통해 메시지가 올바른 어플리케이션에서 생성된 것이라는 보증이 되듯, 공개 키(public key)도 메시지를 암호화하기 위해 사용될 수 있다. 공개 키로 메시지가 암호화 되면 오직 상응하는 개인 키로만 메시지를 복호화 할 수 있다.
만일 해커가 공개 키의 복사본을 가지고 있다 해도 그 공개 키로는 복호화를 할 수 없다는 점이 이 방식의 핵심이다. 만일 인증(certification) 발행자가 불분명하거나 불완전한 인증으로 메시지 서명이나 암호/복호화가 진행된다면 신뢰할 수 없는 통신임을 확신할 수 있다.
OPC UA의 인증은 어떤 어플리케이션의 정보인지, 어떤 어플리케이션의 인증인지, 언제 발행됐는지, 누가 발행했는지, 언제까지 유효한 지 등 모든 사항들을 제공한다.
이 같은 내용은 신뢰할 수 있는 커뮤니케이션의 기본 컨셉이다. 정리하면 OPC UA 어플리케이션이 연결되면 OPC UA 인증의 한 요소인 공개 키를 교환한다. 이 때 자기의 개인 키는 꼭 쥐고 있으며 이를 통해 메시지의 사인과 암호, 복호화가 가능하다는 것이다.
인증을 통한 신뢰 방식이 미미하고 사소한 것이라고 생각할 지 모른다. 하지만 한 어플리케이션이 신뢰할 수 있는 다른 어플리케이션과 연결하고 통신하기 위한 최선의 수단이다. 결국 닫힌 문은 당신이 상대방에게 키를 주기 전까지는 열리지 않는다는 점에서는 의미가 크다고 할 수 있을 것이다.
[참조]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