CRA 시대의 EtherCAT, 실시간 제어와 사이버 보안 동시 구현
필드버스까지 확대되는 사이버 보안 요구
유럽 사이버복원력법(Cyber Resilience Act, CRA)이 산업 자동화 분야의 주요 이슈로 떠오르면서, 필드버 스와 산업용 이더넷 시스템에도 사이버보안 요구가 본격적으로 적용되고 있다. CRA는 유럽에서 판매되는 디지털 요소를 포함한 제품에 사이버보안 요건을 부과 한다. 여기에는 자동화 부품뿐 아니라, 해당 부품이 탑재된 기계와 시스템까지 포함된다.
이에 따라 산업용 통신 시스템도 더 이상 단순한 데이터 전송 수단으로만 볼 수 없게 됐다. 컨트롤러, I/O 모듈, 드라이브, 센서가 연결되는 필드버스 구간 역시 사이버보안 관점에서 검토해야 하는 대상이 된 것이다. 이러한 변화 속에서 EtherCAT의 구조적 특성은 사이버보안 요구를 평가할 때 중요한 근거가 된다.
EtherCAT은 표준 이더넷 프레임과 물리 계층을 사용 하지만, 실제 동작 방식은 일반적인 스위치 기반 이더넷 네트워크와 다르다.
기존 필드버스나 일부 산업용 이더넷 시스템은 셀 또는 존 단위로 외부 통신을 보호하는 방식을 택한다. 또다른 접근은 필드 디바이스마다 암호화와 인증 기능을 적용하는 것이다. 그러나 이러한 방식은 물리적으로 노출된 현장 네트워크에서는 한계가 있고, 인증서 관리와 유지보수 부담을 키울 수 있다. EtherCAT은 이와 달리 프로토콜 자체의 동작 구조와 ESC 하드웨어 처리 방식을 보안 평가의 핵심 요소로 본다.
일반 이더넷과 같아 보이지만, 구조는 다르다
EtherCAT은 산업용 이더넷 기술이다. 일반적으로 자동화 컨트롤러에 해당하는 MainDevice가 이더넷 프레임을 전송하고, 필드 디바이스인 SubDevice가 이를 처리한다.
일반 산업용 이더넷에서는 장치가 프레임을 받은 뒤 소프트웨어 스택에서 데이터를 처리한다. 반면 EtherCAT은 프레임이 장치를 통과하는 순간 필요한 데이터를 읽거나 쓰고, 그대로 다음 장치로 전달한다. 이를 ‘온더플라이 (on-the-fly) 처리’라고 한다.
<그림1> EtherCAT은 표준 이더넷 프레임 안에 EtherCAT 프로토콜과 데이터그램을 직접 포함해 처리한다.
이 과정에서 중요한 역할을 하는 것이 EtherCAT SubDevice Controller, 즉 ESC다. ESC는 소프트웨어가 아니라 하드웨어로 구현되며, 자체적으로 프레 임을 전송하지 못한다. 프레임 처리 과정에 소프트웨어 스택이 직접 개입하지 않기 때문에 공격 표면이 작아지고, 조작된 펌웨어가 통신 데이터를 임의로 바꾸기도 어렵다.
IP 미사용 구조의 보안 효과
EtherCAT의 또 다른 특징은 페이로드 데이터를 전송할 때 IP를 사용하지 않는다는 점이다. EtherCAT 프로토콜은 이더넷 프레임 안에 직접 포함되며, ISO-OSI 모델의 2계층에서 동작한다.
일반적인 악성코드나 네트워크 공격은 IP 계층을 통해 서브넷을 넘나드는 경우가 많다. 그러나 EtherCAT의 기본 통신은 IP 기반 라우팅에 의존하지 않는다. 이 때문에 IT 네트워크에서 흔히 고려하는 일부 공격 시나리오는 EtherCAT 세그먼트에서는 그대로 성립하기 어렵다.
또한 EtherCAT은 자체 EtherType을 사용한다. ESC는 수신된 프레임이 EtherCAT 프레임인지 즉시 식별하고, EtherCAT 프레 임이 아닌 데이터는 하드웨어 차원에서 폐기한다. 따라서 비(非) EtherCAT 프레임을 이용한 공격 경로는 구조적으로 제한된다.
<그림2> EtherCAT 세그먼트에 유입된 비(非) EtherCAT 프레임은 ESC 하드웨어에서 폐기되며, 일반 네트워크 프레임을 통한 공격 경로가 제한된다.
미사용 포트는 차단하고 장치 삽입은 감지
산업 현장에서는 케이블과 장치가 물리적으로 노출되는 경우가 많다. 따라서 필드버스 보안에서는 네트워크에 임의 장치를 연결 하거나, 기존 장치를 교체하는 상황도 고려해야 한다.
EtherCAT은 네트워크 시작 시 MainDevice가 연결된 SubDevice의 속성과 토폴로지를 확인할 수 있다. 적용 방식에 따라 장치 유형과 통신 속성뿐 아니라 펌웨어 버전, 일련번호까지 비교할 수 있다. 이를 통해 장치 추가, 토폴로지 변경, 장치 교체 여부를 확인할 수 있다.
사용하지 않는 포트를 차단할 수 있다는 점도 중요하다. therCAT SubDevice Controller는 다양한 토폴로지를 지원하 지만, 필요하지 않은 포트는 MainDevice가 비활성화할 수 있다. 이 경우 물리적으로 장치를 연결하더라도 논리적 통신은 형성되지 않는다.
장치 삽입 역시 전파 지연 시간의 변화로 감지할 수 있다. EtherCAT은 분산 클록의 정밀 동기화를 위해 프레임 전파 지연을 측정한다. 네트워크에 장치가 추가되면 신호 전파 시간이 달라지고, MainDevice는 이를 통해 토폴로지 변화를 확인할 수 있다.
<그림3> EtherCAT은 신호 전파 시간 변화를 통해 네트워크에 추가 장치가 삽입됐는지 감지할 수 있다.
제어 시스템 전체 보안과는 구분해야
다만 EtherCAT의 구조적 보안성이 제어 시스템 전체의 보안을 자동으로 보장한다는 뜻은 아니다. 대부분의 EtherCAT 제어 시스템은 상위 네트워크 연결용 이더넷 포트, USB 포트, 메모리 카드 슬롯 등 별도 인터페이스를 갖고 있다. EtherCAT 필드 디바이스 역시 유사한 추가 인터페이스를 포함할 수 있다.
이러한 인터페이스는 EtherCAT 네트워크 자체와 별개로 보호해야 한다. 즉 EtherCAT 세그먼트의 통신 구조가 보안상 이점을 제공하더라도, 컨트롤러나 상위 네트워크 연결부에 대한 보안 조치는 별도로 필요하다.
또한 EtherCAT의 일부 보안 기능은 MainDevice 구현 방식에 따라 달라진다. 모든 컨트롤러가 시작 과정에서 네트워크 변경 여부를 확인하거나, 사용하지 않는 포트를 기본적으로 비활성화하는 것은 아니다. 따라서 실제 시스템에서 요구되는 보안 수준을 충족하려면 적절한 MainDevice와 컨트롤러를 선택해야 한다.
이 접근은 IEC 62443의 위험 기반 보안 개념과도 맞닿아 있다. 모든 시스템에 동일한 보안 조치를 적용하기보다, 실제 애플리케이 션의 위험 수준과 예상 공격 강도에 따라 필요한 조치를 선택하는 방식이다.
IEC 62443 SL 2, 프로토콜 수정 없이 대응
EtherCAT은 일반적인 적용 시나리오에서 보안 전용 프로토콜 확장 없이도 IEC 62443-3-3 기준 Security Level 2 요구사항에 대응할 수 있는 구조적 특성을 갖는다. IEC 62443-3-3은 개별 부품이 아니라 시스템 차원의 보안 요구사항을 다루는 표준이다.
UL Solutions는 세 가지 대표적인 EtherCAT 적용 시나리오를 대상으로 운용 환경에서의 보안 기능을 평가했으며, 이 평가는 IEC 62443-3-3 기준 인증서 발행으로 이어졌다. Security Level 3 수준의 공격에 대응해야 하는 경우에도 SubDevice 하드웨어를 변경할 필요는 없으며, MainDevice와 구성 도구의 소프트웨어 확장으로 대응할 수 있다.
매우 높은 보안 요구가 있는 환경을 위해서는 선택적 암호화 방식도 제시되고 있다. ETG는 하위 호환성을 유지하면서, 필요한 데이터 전체 또는 일부를 보호할 수 있는 인증형 암호화 방식을 EtherCAT 표준에 추가하는 작업을 진행하고 있다. 이 방식은 인증서 없이 키를 배포할 수 있어, 인증서 만료와 갱신에 따른 관리 부담을 줄이는 방향을 목표로 한다.
필요한 만큼의 보안이 핵심
산업용 네트워크 보안에서 중요한 것은 모든 시스템에 동일한 수준의 보안 조치를 무조건 적용하는 것이 아니다. 실제 애플리케이션의 위험 수준과 예상 공격 강도에 맞춰 필요한 보안 조치를 적용하는 것이다.
CRA와 IEC 62443 모두 이러한 위험 기반 접근법과 맞닿아 있다. EtherCAT의 경우, 일반 이더넷과 다른 통신 구조와 ESC 기반 하드웨어 처리 방식이 보안 평가에서 중요한 요소로 작용한다.
필드버스 보안은 앞으로 자동화 시스템 설계에서 더 중요한 기준이 될 가능성이 높다. 특히 모션 제어, 드라이브, I/O, 센서가 하나의 네트워크로 연결되는 환경에서는 통신 성능뿐 아니라 보안 구조까지 함께 검토해야 한다. EtherCAT 사례는 산업용 통신 시스템을 일반 IT 네트워크 관점만으로 평가하기보다, 기술의 동작 구조와 적용 환경을 함께 봐야 한다는 점을 보여준다.
자료제공: EtherCAT Technology Group(www.ethercat.org)
