제로 트러스트: 시스템에서 하드웨어로

Created on October 16, 2026

2026   ·   zero-trust   robotics   hardware-security   attestation   industrial-AI   trustworthy-AI   korean

View count

English version: Zero Trust: From the System Down into the Hardware

왼쪽은 방패로 보호되는 서버와 클라우드 네트워크, 오른쪽은 관절마다 잠금 검문 지점을 단 pick-and-place 로봇 팔

보안에서의 제로 트러스트(Zero Trust)는 다양한 도구들과 연계되는 인공지능 및 에이전틱 서비스에서 더 많은 관심을 받고 있는데요, 이제는 거의 상식처럼 쓰이는 말이 된 것 같아요. “아무것도 믿지 말고, 항상 확인하라.” 사내망 안에 있다고 믿어 주지 않고, 요청마다 누가 무엇을 하려는지 확인하고, 필요한 만큼만 권한을 주는 방식입니다. 다만 이 원칙을 따라 내려가다 보면 어느 지점에서 멈추는 곳이 있습니다. 바로 장치의 경계입니다.

지난 글에서는 하드웨어 격리(TEE) 위에 시스템 설계를 쌓아 올리는 이야기를 했는데요, 이번에는 반대 방향입니다. 네트워크와 시스템 단위에서 쓰이던 제로 트러스트를 장치 안쪽, 로봇의 관절까지 끌고 내려가면 무엇이 달라지는지 정리해 보았습니다. 예로 드는 것은 컨베이어로 들어오는 부품을 비전으로 인식해 집어 트레이에 놓는, 가장 평범한 pick-and-place 로봇 셀이에요.

제로 트러스트가 멈추는 곳

ZTA의 기준 문서인 NIST SP 800-207은 주체를 사용자뿐 아니라 애플리케이션과 비인격 개체로, 자원을 장치와 인프라 구성 요소까지로 정의합니다. 자원의 예로 IoT 액추에이터를 들기도 합니다.1 원칙만 보면 로봇 제어기가 관절에 보내는 명령도 제로 트러스트의 대상이라고 볼 수 있겠죠.

그런데 실제 참조 구조와 성숙도 모델로 가 보면 이야기가 조금 달라집니다.

문서 기본 단위 장치 내부 처리
NIST SP 800-207 (2020) 주체(사람, 앱, 비인격 개체), 자원(IoT 액추에이터 포함) 게이트웨이 뒤를 암묵적 신뢰 구간으로 허용
CISA ZTMM v2.0 (2023) 네트워크에 연결된 장치 장치 내부 부품 간 통신 미포함
미 국방부 ZT for OT (2025.11) OT 비인격 개체, 퍼듀 0~2 계층 인증서 미지원 장치는 예외 처리, 무기체계 내부 OT 구성 요소는 다루지 않음
KISA OT 제로트러스트 안내서 (2025.12) 퍼듀 모델 기반 설비 네트워크 실시간성, 가용성 우선, 장치 내부는 구체화되지 않음

정리하면 제로 트러스트는 원칙상 하드웨어 내부를 배제하지 않지만, 장치 안의 부품 사이에서 신원, 인가, 집행을 어떻게 할지 정한 표준은 아직 없는 것 같아요. 칩 수준 보안 연구를 검토한 최근 문헌도 SoC와 NoC 보안 연구 45건 가운데 제로 트러스트 원칙을 모두 충족한 사례가 없었고, 특히 세션 단위 인가, 세분화된 접근 제어, 지속 검증이 부족하다고 보고했습니다.2

로봇 안으로 들어가 보면 이 상황이 꽤 구체적으로 보이는데요, 협동로봇과 서보 시스템에서 널리 쓰는 EtherCAT의 일반 프레임은 FCS, 즉 CRC로만 보호됩니다. CRC는 우발적인 비트 오류를 잡는 장치이지, 누군가 의도적으로 만든 프레임을 걸러 내는 장치가 아니거든요. 셀 경계에는 방화벽과 인증서가 있고 티치펜던트에는 로그인이 있지만, 제어기에서 관절로 가는 지령 하나하나에는 아직도 “같은 버스에 있으니 믿는다”는 전제가 적용될 수 있습니다. 제로 트러스트가 가장 경계하는 바로 그 전제입니다. 단위 자체가 ‘제어기’이기 때문인데, 사실 이 안에도 이제는 복잡한 단위 구성이 많아서 단일 하드웨어라고 부르기 애매한 상황이 되어 버린 것 같아요.

이미 있는 하드웨어 구성 기술

다행히 하나의 기계 안에서 부품끼리 서로를 검증하는 기술은 다른 분야에서 이미 쓰이고 있습니다. 이름이 ‘제로 트러스트’가 아닐 뿐이에요.

분야 사례 로봇 내부 관점의 의미
차량 내부망 AUTOSAR SecOC(절단 MAC, 신선도 값), MACsec, 게이트웨이 ECU 한 기계 안의 메시지 인증과 망 분리
서버, 칩 DMTF SPDM, TCG DICE, OCP Caliptra 부품 신원과 펌웨어 상태 증명
센서 MIPI Camera Security(SPDM 기반 이미지 센서 인증) 센서 단위 인증 세션
서보 드라이브 Siemens SINAMICS 보안칩, Rockwell Kinetix(CIP Security), B&R ACOPOS M4(OPC UA FX) 드라이브 단위 신원과 채널 보호
로봇 관절 ADI 보안 인증 IC 적용 예시(제어기와 관절 상호 인증, 세션 암호화) 관절 단위 상호 인증 구현 예
필드버스 EtherCAT 대칭키 페어링(시나리오 3), ETG.1800 보안 프로파일 초안(2026.9), CANsec 로봇 내부 버스 보안 표준화 진행

이 사례들을 놓고 보면, 로봇 내부 제로 트러스트는 새 보안 기술을 처음부터 만드는 일이라기보다 ZTA의 논리 구성 요소(정책 결정 지점 PDP, 정책 집행 지점 PEP, 정책 정보 지점 PIP)를 하나의 복합 장치인 로봇 안에 다시 배치하는 일에 가깝다고 봅니다. 이미 있는 부품 신원, 증명, 메시지 인증 기술을 관절의 실시간 제약에 맞게 엮는 것이구요. 물론 “필드 수준에서는 하드웨어 강제 규칙으로 충분하고, 과도한 인증서 처리는 피해야 한다”는 EtherCAT 진영의 반론도 있습니다.3 그래서 모든 것을 한 번에 바꾸기보다, 핵심 명령부터 선택적으로 적용해 보는 단계적 접근이 설득력이 있다고 생각합니다.

IT의 제로 트러스트와 다른 점

그럼 IT에서 쓰던 제로 트러스트와는 무엇이 다를까요? 같은 원칙이라도 로봇 안으로 들어오면 단어의 뜻이 꽤 바뀝니다.

구분 IT 환경 ZTA 로봇 내부 ZTA
자원 데이터, 서비스 액추에이터 동작, 파라미터, 펌웨어, 작업 프로그램
접근의 의미 읽기, 쓰기, 실행 동작 여부, 동작 범위(위치, 속도, 힘), 동작 시점
판단 주기 세션 단위(분) 작업 단위(분)와 제어 주기 단위(ms 이하)로 이원화
거부 시 결과 요청 실패 안전 상태 전이(감속, 보호정지), 정지 방식 자체가 위험 요소
신원 계정, 인증서 부품 고유 신원, 장착 위치(축), 펌웨어 측정값
정책 근거 조직 IAM, 데이터 등급 로봇 사양, 안전 설정, 작업지시(MES), 정비지시(ERP)
통신 IP 네트워크 비IP 실시간 필드버스(EtherCAT, CAN)
가용성 일시 중단 허용 생산 중단과 안전 문제로 직결, 외부 PDP 의존 곤란

가장 크게 달라지는 것은 두 가지라고 생각합니다. 첫째, ‘접근’이 데이터가 아니라 물리 동작이 됩니다. 문서를 읽는 권한이 아니라 “J3 관절을 지금 초당 90도 이하로 움직일 권한”이 정책의 대상이 되는 거죠. 둘째, 거부 자체가 위험이 될 수 있습니다. IT에서 요청을 거부하면 사용자가 에러 화면을 보고 끝나지만, 로봇이 지령을 거부해 급정지하면 들고 있던 공작물이 날아가거나 중력축이 떨어질 수 있거든요. 이 차이를 감안하면 로봇 내부 제로 트러스트는 “기본 불신, 최소 권한, 지속 검증”이라는 원칙은 그대로 두되, 판단과 집행 지점을 로봇 안으로 내리고, 접근의 의미를 물리 동작으로 다시 정의하고, 판단 주기를 작업 단위와 제어 주기 단위로 나누는 작업이 필요해 보입니다.

지령 하나마다 확인할 것

관절이 제어기에게서 지령을 받을 때, 제로 트러스트 관점에서 확인할 항목은 다음 여섯 가지 정도로 나눠 볼 수 있을 것 같아요.

확인 항목 확인 내용 수단 확인 시점
출처 진정성 등록된 제어기의 지령 여부 세션 키 기반 MAC(SecOC 방식) 제어 주기마다
신선도 재전송, 지연 지령 여부 카운터 또는 타임스탬프 제어 주기마다
송신자 상태 제어기 펌웨어와 설정의 정상 여부 측정 부팅, 부품 증명(DICE, SPDM) 기동 시, 변경 시, 주기적 재증명
권한 이 주체의 이 축, 이 동작 요청 가능 여부 PDP가 발급한 권한 증표 작업 시작, 모드 전환, 이벤트 발생 시
물리적 범위 지령값의 허용 범위 내 여부 축별 위치, 속도, 토크 범위 비교 제어 주기마다
안전 맥락 현재 동작 가능 상황 여부 운전 모드, 인에이블 장치, 안전 제어기 상태 상태 변화 시

이 가운데 ‘물리적 범위’를 따로 둔 데에는 이유가 있는데요, 인증만으로는 막기 어려운 공격이 이미 여럿 보고되어 있기 때문입니다.

  • 인증된 주체의 위장: SROS2 키스토어를 탈취하면 정상 참여자로 인증된 상태에서 제어 명령을 주입할 수 있음4
  • 그럴듯한 범위 안의 변조: 산업용 로봇 제어기 분석에서 1축 PID 이득만 바꿔 2mm 미만의 궤적 오차를 만듦5
  • 정상 데이터 재생: 악성 작업 코드를 올리면서 상위 감시 시스템에는 녹화해 둔 정상 데이터를 보여 준 사례가 있음6

인증은 “누가 보냈는가”에 답할 뿐, “보낸 내용이 말이 되는가”에는 답하지 않거든요. 그래서 관절이 권한 증표에 적힌 범위와 지령값을 직접 비교하는 단계가 필요하다고 봅니다. 방향도 한쪽만은 아닙니다. 서보 버스 중간자 실험에서는 명령을 떨어뜨리고 가짜 상태 응답을 돌려보내는 공격도 시연됐습니다.7 지령(제어기에서 관절로)과 상태(관절에서 제어기로) 양쪽을 모두 인증 대상으로 두는 것이 바람직해 보입니다.

같은 모양의 관절 여섯 개

로봇 안의 신원 문제는 생각보다 까다로운데요, 6축 로봇에서 J4~J6처럼 같은 기종 드라이브가 여러 개 들어가는 경우가 많은데, 지금 버스 수준의 식별자(EtherCAT의 제조사, 제품 코드, 일련번호 같은 값)는 평문이라 복제가 쉽고, 같은 기종끼리 케이블이 바뀌어도 알아채기 어렵습니다. 그래서 “이 부품이 진품인가”, “펌웨어가 정상인가”, “이 부품이 정말 J3 자리에 있는가”라는 세 질문을 따로 다뤄 보는 것도 의미가 있을 듯 합니다.

계층 생성 시점 발급 주체 수단 정책에서의 쓰임
개체 신원 제조 부품 제조사 IDevID(IEEE 802.1AR), DICE DeviceID 진품 여부, 출처 확인
상태 신원 부팅마다 부품 자체(DICE 계층 유도) DICE Alias 인증서, SPDM 측정값 펌웨어 정상 여부 확인
역할 신원 설치, 교체 통합업체 또는 소유자 CA LDevID(IEEE 802.1AR) 정책의 대상 이름(R01/J3)

여기서 DICE가 MCU급 관절에 잘 맞는다고 보는 이유가 있습니다. DICE는 펌웨어 측정값으로 다음 단계의 키를 유도하므로, 펌웨어가 바뀌면 키도 바뀝니다. 별도의 측정 보고를 주고받지 않아도 상태 변화가 드러나는 셈이에요. 역할 신원을 따로 두는 이유는 정책 관리 때문입니다. 정책은 “J3에 MOVE를 허용한다”처럼 역할로 쓰는데, 관절을 교체하면 개체 신원은 바뀌어도 역할 신원은 새 부품에 다시 발급되므로 정책을 고칠 필요가 없거든요. 다만 역할 신원을 발급하기 전에 그 부품이 정말 그 축에 달려 있는지를 버스 연결 순서, 모터와 엔코더의 전자 명판, 감속 상태의 단일 축 미소 구동 같은 방법으로 확인하는 절차가 함께 필요할 것 같습니다.

로봇 전체의 증명은 IETF RATS 아키텍처의 복합 장치(composite device) 모델로 묶어 볼 수 있습니다.8 제어기가 리드 증명자가 되어 관절, 그리퍼, 카메라의 증거를 모으고, 제어기 보안 영역의 검증기가 제조사나 자산관리 셸(AAS)이 제공한 기준값과 대조하는 구조입니다. 라우터 섀시가 슬롯마다 꽂힌 카드를 대표해 증명하는 방식을 로봇에 옮겨 온 것에 가깝다고 봅니다.

판단은 위에서, 집행은 아래에서

관절 MCU가 1 kHz 제어 주기마다 속성 기반 정책 전체를 평가할 수 있을까요? 현실적으로는 어렵겠죠. 그래서 판단은 위에서 풍부하게, 집행은 아래에서 단순하게 하는 2단계 구조를 생각해 볼 수 있습니다.

  • 느린 경로(작업, 이벤트 단위): 작업 시작, 모드 전환, 정비 진입, 이상 징후 같은 사건이 생기면 제어기 보안 영역의 PDP가 속성을 모아 정책을 평가하고 관절마다 권한 증표를 발급함, 수십 ms에서 수 초가 걸려도 무방함
  • 빠른 경로(제어 주기 단위): 관절 PEP는 지령 프레임마다 MAC 확인, 신선도 확인, 증표 범위와의 비교만 수행함

권한 증표에는 수신 관절, 지령을 보낼 수 있는 주체, 허용 동작, 위치와 속도와 토크 범위, 작업 ID와 운전 모드, 유효 시간, 세션 키 식별자를 담고 PDP가 서명합니다. 관절 입장에서는 정책 언어를 해석할 필요 없이 숫자 몇 개만 비교하면 되는 셈이죠. 공개된 명령 단위 MAC 연구 가운데에는 처리에 평균 7.9 ms가 걸려 1 kHz 제어 주기에 맞지 않는 결과도 있으므로, MCU의 하드웨어 암호 가속기를 전제로 시제품 단계에서 실측해 보는 것도 의미가 있을 듯 합니다.

flowchart TB
    subgraph UP["상위 시스템"]
        MES["MES<br/>작업지시 서명"]
        ERP["ERP/CMMS<br/>정비지시 서명"]
        AAS["AAS<br/>부품 신원, 기준값"]
    end
    subgraph RB["로봇 내부"]
        PDP["제어기 보안 영역(TEE)<br/>PDP, 검증기, 키 관리"]
        MC["모션 태스크"]
        J["관절 J1~J6<br/>PEP: MAC, 신선도, 범위 비교"]
        SAF["안전 제어기<br/>STO, SS1, SLS"]
    end
    MES --> PDP
    ERP --> PDP
    AAS --> PDP
    PDP -- "느린 경로: 권한 증표 발급" --> J
    MC -- "빠른 경로: 지령 + 신선도 + MAC" --> J
    J -- "상태 + MAC" --> MC
    PDP -. "신뢰 저하 시 보호정지 요청" .-> SAF
    SAF -- "안전 기능(최종 판단)" --> J

그림 1. 로봇 내부 제로 트러스트의 2단계 집행 구조(안), 드래그로 이동, 스크롤로 확대

정책 자체도 한 사람이 쓰는 것이 아닌데요, 부품이 견딜 수 있는 한계는 제조사가, 셀의 위험성 평가 결과는 통합업체가, 역할과 정비 절차는 소유자가, 지금 할 작업은 MES가 알고 있습니다. 그래서 정책을 제조사, 통합업체, 소유자, 작업의 네 층위로 나누고 층위마다 서명 주체를 달리한 뒤, 실제 허용 권한은 네 층위의 교집합으로 정하는 방안을 고려해 볼 수 있습니다. 어느 층위에서든 거부가 나오면 거부가 되는 구조구요. 사람 단위의 상시 권한도 MES 작업지시와 ERP 정비지시에 연결된 한시 권한으로 바꾸면, 정비지시에 없는 축의 파라미터는 엔지니어 계정으로도 바꿀 수 없게 됩니다.

보안은 좁히기만 한다

로봇에서 제로 트러스트를 이야기할 때 가장 조심해야 할 부분은 안전 기능과의 관계라고 생각합니다. 원칙은 단순하게 정리해 볼 수 있습니다. 보안 계층은 동작 범위를 좁힐 수만 있고, 넓힐 수는 없습니다.

  • 안전 기능의 독립 유지: STO, SS1, SLS 같은 안전 기능과 안전 설정은 보안 정책과 분리하고 기능안전 인증 범위를 바꾸지 않음
  • 보안 범위의 위치: 보안 PEP의 범위는 안전 한계 안쪽의 더 좁은 동적 범위로 둠
  • 정지 방식의 단계화: 위반 프레임 하나에 곧바로 STO를 걸지 않고 이전 유효 지령 유지, 감속, SS1 순서처럼 단계를 정의함
  • 비상 구출 수단 유지: 수동 브레이크 해제 같은 구출 수단은 보안 인가 대상에서 제외하거나 물리적 수단으로 유지함

네트워크 장애는 조금 더 미묘합니다. 제로 트러스트의 기본값은 ‘확인되지 않으면 거부’인데, 이를 그대로 적용하면 MES와의 연결이 끊기는 순간 모든 지령이 거부되어 급정지가 일어날 수 있습니다. 그리고 급정지는 그 자체로 위험이죠. 그래서 통신 두절을 예외가 아니라 설계 조건으로 두고, 장애가 생겨도 위험하지 않은 쪽으로 수렴하도록(Fail Safe) 보안과 안전을 함께 설계하는 것이 필요해 보입니다. 연결이 끊긴 동안에는 새 권한을 주지 않고 이미 발급된 증표의 범위와 유효 시간 안에서만 움직이며, 증표가 만료되면 사이클 종료 위치에서 멈추는 식입니다. 케이블 단선 같은 장애와 재밍이나 위조 프레임 같은 공격 의심 상황을 구분해 기록하고, 공격이 의심되면 재증명과 관리자 확인을 거쳐야 복귀하도록 하는 것도 고려해 볼 만합니다.

마지막으로 PDP가 있는 제어기 자체가 장악되는 경우가 남는데요, 공격자가 권한 증표를 스스로 발급할 수 있기 때문입니다. 여기서 TEE 이야기가 다시 등장합니다. PDP를 제어기의 일반 실행 영역과 분리된 TEE나 별도 보안 MCU에 두고, 증표 발급에 MES 작업지시 서명 같은 외부 입력을 요구하고, 통합업체가 서명한 상한을 관절에 직접 저장해 두면, PDP가 발급한 증표라도 그 상한을 넘으면 관절이 거부하게 됩니다. 단일 지점이 뚫려도 상위 층위의 한계와 안전 한계는 유지되는 구조라고 볼 수 있겠죠.

아직 비어 있는 곳

그럼 지금 구현은 어디까지 와 있을까요? 현재 구현을 둘러보면 보호 단위가 ‘제어기’와 ‘드라이브 장치’에 머물러 있는 것 같아요. 로봇 제조사들은 제어기 단위로 IEC 62443-4-2 인증을 받기 시작했고, 서보 드라이브 일부는 보안칩과 채널 암호화를 갖췄습니다. 하지만 그 사이를 오가는 지령 하나하나가 허용된 것인지를 따지는 계층은 아직 비어 있고, 축 단위, 동작 단위 인가와 실행 중 재증명은 공개 구현을 찾기 어렵습니다. 안전 통신(FSoE, PROFIsafe)은 우발 오류는 잡지만 의도적 위조 방어는 하위 계층에 맡기고, ROS 2의 SROS2는 기본 비활성인 데다 키를 탈취당하면 정상 주체로 위장할 수 있습니다.

표준 쪽은 움직이고 있는데요, EtherCAT 보안 프로파일(ETG.1800)이 2026년 9월 회원 검토 초안으로 나왔고, AAS Part 4는 속성 기반 접근 제어를 담았습니다. 규제도 다가오고 있습니다. EU 기계규정이 2027년 1월, 사이버 복원력법(CRA)이 2027년 12월부터 적용되고, ISO 10218-1:2025에도 로봇 안전에 영향을 주는 범위의 사이버보안 요구가 들어갔구요. 로봇과 산업 기기를 수출하는 입장에서는 이 흐름을 미리 따라가 보는 편이 유리할 것 같습니다.

제로 트러스트의 원칙은 바뀌지 않는다고 생각합니다. 바뀌는 것은 그 원칙이 적용되는 단위입니다. 사용자에서 장치로, 장치에서 부품으로, 그리고 요청에서 지령 하나로 내려가는 거죠. 그 과정에서 ‘접근’은 데이터가 아니라 움직임이 되고, ‘거부’는 에러가 아니라 안전한 정지 방식의 문제가 됩니다. 시스템에서 시작한 제로 트러스트가 하드웨어 안쪽까지 내려가려면, 보안과 안전, 그리고 실시간 제어를 한 테이블에 올려놓고 설계하는 작업이 필요해 보입니다. 물리보안, Physical AI 등에서는 이 컨셉도 유효할 수 있을 것 같아요.

참고 문헌

  1. NIST, SP 800-207 Zero Trust Architecture (2020-08); DoD CIO, Zero Trust for Operational Technology (2025-11) ↩

  2. Butka, Bobda, The Future of Zero-Trust Secured Hardware, Journal of Hardware and Systems Security (2026) ↩

  3. EtherCAT Technology Group, Explanatory Notes on the Certification of EtherCAT Cybersecurity Capabilities (2026-04) ↩

  4. Sakib 외, Supply Chain Exploitation of Secure ROS 2 Systems, arXiv 2511.00140 ↩

  5. Quarta 외, An Experimental Security Analysis of an Industrial Robot Controller, IEEE S&P 2017 ↩

  6. Pu 외, CORMAND2, Engineering (2024) ↩

  7. Jiménez Naharro 외, Hardware Vulnerabilities in Robotic Actuators, Electronics (2025) ↩

  8. IETF, RFC 9334 Remote ATtestation procedureS (RATS) Architecture (2023-01); TCG, DICE Architectures ↩

공유 LinkedIn X Facebook 이메일