제13부 보안

13.1 위협 모델 — ROS 2 그래프의 공격면

13.1.1 이 장에서 배우는 것 / 선수 지식

이 책은 지금까지 ROS 2의 개방성을 장점으로 설명해 왔다. 노드는 서로를 자동으로 발견하고(1.5), 누구나 토픽을 구독할 수 있고, ros2 topic pub으로 아무 명령이나 보낼 수 있다. 개발에서는 이것이 큰 생산성이다.

그 개방성이 그대로 공격면이다. 기본 설정의 ROS 2 네트워크에서는 같은 도메인에 접근할 수 있는 누구든 모든 데이터를 읽고, 모든 명령을 보내고, 어떤 노드도 사칭할 수 있다. 로봇이 물리적으로 움직이는 기계라는 점에서, 이것은 데이터 유출을 넘어 물리적 위해로 이어질 수 있다.

이 장은 무엇을 지켜야 하는지 정하는 작업 — 위협 모델링 — 을 다룬다. 대책(13.2~13.4)에 앞서 이것이 필요한 이유는, 모든 것을 지킬 수는 없고 무엇이 중요한지 정해야 자원을 쓸 수 있기 때문이다.

배우는 것:

• 기본 상태의 실제 — 무엇이 열려 있는가.
• 자산 식별 — 무엇을 지키는가.
• 위협 분류 — 체계적으로 나열하기.
• 공격면 — ROS 2 특유의 지점들.
• 위험 평가 — 우선순위 정하기.
• 경계 설계 — 신뢰 경계를 어디에 긋는가.
• 현실적 판단 — 무엇을 하지 않을 것인가.

선수 지식: 3.2(RTPS 전송), 3.3(디스커버리), 3.9(네트워크), 8.7(물리 안전 — 구분이 필요).

정직: 이 장은 방어 관점의 위협 식별을 다루며, 공격 기법이나 침투 방법을 제공하지 않는다. 또한 보안 인증·규제 준수(예: 사이버보안 규격)에 관한 조언을 제공하지 않는다 — 그 요구가 있는 시스템은 해당 표준과 보안 전문가의 판단을 따라야 하며, 이 책의 서술을 근거로 삼아서는 안 된다. 도구·기능의 세부는 버전 의존이다(확인 필요). 이 환경에서 검증하지 않았다(목차 3). 142차(121번째 회차)가 이 부(13.1·13.4·13.5)의 구체적 주장 몇 가지를 실행 확인했다 — 아래 각 절을 보라.

13.1.2 기본 상태의 실제

보안 설정 없이 ROS 2를 실행하면 무엇이 열려 있는가.

실행 확인(142차, ros:jazzy-ros-base). "노드 이름 중복 방지 없음"을 직접 재현했다 — 같은 이름(talker)의 노드 둘을 동시에 실행하면 ros2 node list가 이런 경고를 낸다: WARNING: Be aware that there are nodes in the graph that share an exact name, which can have unintended side effects. 하지만 경고뿐이다 — 어느 쪽도 거부되지 않고, 두 프로세스 다 정상적으로 계속 발행했다(Publishing: 'Hello World: N'이 두 로그에 독립적으로 계속 출력됨). "방지 없음"이 정확한 표현이다 — 탐지(경고)는 있지만 강제(차단)는 없다. 목차 3.

견해: "우리 로봇은 폐쇄망이라 괜찮다"는 판단을 신중하게 하라. 폐쇄망도 유지보수 노트북·무선 AP·USB·공급망을 통해 연결점이 생긴다. "네트워크 경계만으로 보호한다"는 전제가 깨지는 순간 아무 방어가 없다는 것이 문제다.

견해: 로봇의 특수성은 "출력이 물리적"이라는 점이다. 일반 IT 시스템의 침해는 데이터 문제로 끝나지만, 로봇은 움직이고 힘을 낸다. 그래서 위협 평가에서 물리적 결과를 명시적으로 고려해야 한다.

함정: 개발 환경의 편의 설정이 운영에 남는 경우가 흔하다. 디버깅을 위해 열어 둔 접근, 임시로 넣은 기본 암호, 개발용 인증서. 배포 점검 목록에 보안 항목을 넣는 것(4.7·13.4)이 예방책이다.

13.1.3 자산 식별

무엇을 지키는가를 먼저 정한다.

견해: 자산 목록의 첫 줄이 "물리적 제어"인 것이 로봇 보안의 특징이다. 다른 모든 자산보다 결과가 크므로, 명령 경로의 보호가 최우선이 된다. 데이터 암호화보다 "누가 /cmd_vel을 쓸 수 있는가" 가 먼저다.

견해: 자산에 따라 필요한 보호가 다르다. 명령 경로는 인증·인가(누가 보냈는가), 센서 데이터는 기밀성(누가 볼 수 있는가), 소프트웨어는 무결성(변조되지 않았는가). 하나의 대책이 모두를 해결하지 않는다.

13.1.4 위협 분류

체계적으로 나열하기 위해 분류를 쓴다(STRIDE 계열의 관점을 로봇에 적용).

로봇 특유의 위협:

견해: "센서 데이터 위조"가 로봇에서 특히 위험한 위협이다. 명령을 직접 보내지 않아도, 가짜 장애물·가짜 위치를 주입하면 로봇이 스스로 잘못 움직인다. 명령 경로만 보호하고 센서 경로를 열어 두면 이 우회가 가능하다.

견해: 안전 기능을 소프트웨어 스택 안에만 두면 보안 위협에 노출된다(8.7.7·12.1.6의 반복). 비상정지가 ROS 토픽으로만 동작한다면, 그 토픽을 막거나 위조하는 것으로 안전이 무력화된다. 독립적인 하드웨어 안전 경로가 보안 관점에서도 정당화된다.

정직: 서비스 거부는 완전히 막기 어렵다. 네트워크 자원·계산 자원은 유한하므로, 충분한 접근을 가진 상대는 가용성을 해칠 수 있다. 가용성 상실 시 안전 상태로 가는 설계(1.12.7·8.7.6)가 현실적 대응이다.

13.1.5 공격면 — ROS 2 특유의 지점

견해: 파라미터가 과소평가된 공격면이다. 속도 제한·안전 거리·감속도 같은 값을 바꿀 수 있으면, 명령을 보내지 않고도 로봇을 위험하게 만들 수 있다. 안전 관련 파라미터는 읽기 전용으로 선언하거나(1.9.5) 변경에 별도 통제를 두는 것이 좋다.

견해: 디스커버리 자체가 정보를 준다. ros2 node list·ros2 topic list만으로 시스템 구조·사용 중인 기능·소프트웨어 구성이 드러난다. 이것은 공격의 사전 단계를 쉽게 만든다. 네트워크 접근 제어가 첫 방어선인 이유다(13.4).

함정: 디버그 포트·서비스 인터페이스가 운영에 남는 경우가 흔하다. 개발 중 편의를 위해 만든 "노드 재시작 서비스"·"임의 명령 실행"이 운영에서 그대로 노출되면 강력한 공격 수단이 된다. 운영 빌드에서 제외하거나 인가를 요구하도록 한다.

13.1.6 위험 평가와 우선순위

모든 위협에 같은 자원을 쓸 수 없다.

전형적 우선순위(시스템에 따라 다름):

견해: "영향이 큰 것부터"가 로봇에서는 명확하다 — 물리적 위해를 만들 수 있는 경로가 최우선이다. 데이터 암호화를 먼저 하고 명령 경로를 열어 두는 것은 순서가 뒤바뀐 것이다.

견해: "수용"도 정당한 결정이다. 모든 위협을 막을 수는 없으므로, 평가 후 수용한 위험을 문서로 기록하는 것이 중요하다. 나중에 조건이 바뀌었을 때 재검토할 근거가 된다.

13.1.7 신뢰 경계

어디까지를 믿을 것인가를 정한다.

견해: "로봇 내부는 신뢰"가 흔한 초기 모델이며 대체로 합리적이다. 내부 노드 간에도 인증을 하면 보안은 강해지지만 복잡도·성능 비용이 크다(13.5). 먼저 외부 경계를 확실히 하고, 필요에 따라 내부를 세분화하는 순서가 실용적이다.

견해: 원격 조작 경로는 특별히 다뤄야 한다. 사람이 직접 로봇을 움직이는 경로는 영향이 가장 크므로, 강한 인증·세션 타임아웃·연결 상실 시 안전 정지가 필요하다. 14.2.6에서 다룬 통신 상실 대응이 보안 관점에서도 필수가 된다.

함정: 플릿 서버가 침해되면 여러 로봇이 동시에 영향을 받는다. 중앙 집중은 운영 효율을 주지만 단일 실패·침해 지점을 만든다. 서버 침해를 가정한 로봇 측 방어(명령 검증·물리적 제한·안전 회로)가 필요하다.

13.1.8 방어 계층

하나의 대책에 의존하지 않는다.

견해: ⑤가 최종 방어선이라는 점이 로봇 보안의 특징이다. 소프트웨어가 완전히 장악되어도, 기계적 속도 제한·독립 안전 회로·물리적 방책이 있으면 피해가 제한된다. 보안과 안전이 여기서 만난다.

견해: ②(네트워크 분리)가 비용 대비 효과가 가장 크다. SROS 2 도입은 노력이 크지만, 로봇 네트워크를 분리하고 접근을 통제하는 것은 상대적으로 쉽고 효과가 크다. 거기서 시작하는 것이 현실적이다.

13.1.9 애플리케이션 수준 방어

미들웨어 보안과 별개로, 코드에서 할 수 있는 것들이다.

// 입력 검증 예 — 명령 수신 시
void on_cmd_vel(const Twist::SharedPtr msg)
{
  if (!std::isfinite(msg->linear.x) || !std::isfinite(msg->angular.z)) {
    RCLCPP_WARN(get_logger(), "비유한 명령 거부");   // 감사 로그
    return;
  }
  if (std::abs(msg->linear.x) > kMaxLinear ||
      std::abs(msg->angular.z) > kMaxAngular) {
    RCLCPP_WARN(get_logger(), "범위 초과 명령 제한 적용");
    // 거부 또는 클램프 — 정책에 따라
  }
  // ...
}

견해: 입력 검증은 보안뿐 아니라 버그 방어이기도 하다. 잘못된 코드가 NaN을 보내는 것과 악의적 입력은 코드 입장에서 같다. 경계에서 검증하는 습관이 두 문제를 함께 줄인다.

견해: 최종 속도 제한을 제어 계층에서 강제하라(8.7.5). 상위 노드가 무엇을 보내든 하드웨어 인터페이스 직전에서 제한하면, 상위가 침해되거나 오작동해도 물리적 결과가 제한된다. 이것이 방어 계층 ④와 ⑤ 사이의 실용적 조치다.

견해: 감사 로그가 사후 대응의 근거다. 누가·언제·무슨 명령을 보냈는지 남으면, 사고 분석(11.1.8)과 원인 규명이 가능해진다. 다만 로그 자체의 무결성·기밀성도 고려해야 한다(11.3.9).

13.1.10 무엇을 하지 않을 것인가

현실적 판단이다.

견해: 개발 환경에 운영 수준 보안을 요구하면 개발이 마비된다. SROS 2를 켜면 디버깅 도구가 연결되지 않고, 노드를 하나 실행하기도 번거로워진다. 개발은 열어 두되 운영과 구분을 확실히 하고, 그 전환을 자동화(13.4)하는 것이 실용적이다.

견해: "보안을 나중에 추가한다"는 계획은 대체로 실패한다. 나중에 하려면 아키텍처를 바꿔야 하는 경우가 많다(경계 설계·키 배포·인가 모델). 위협 모델은 초기에 만들고, 대책 적용 시점은 단계적으로 두는 것이 절충이다.

정직: 이 책은 보안 컨설팅을 대체하지 않는다. 규제 요구가 있거나 공공·중요 인프라에 배치되는 시스템은 보안 전문가의 평가를 받아야 하며, 이 장은 그 대화를 준비하기 위한 개념 정리로 이해해야 한다.

13.1.11 함정 카탈로그

13.1.12 체크포인트

• 보안 설정 없는 ROS 2에서 열려 있는 능력 일곱 가지를 말할 수 있는가.
• "폐쇄망이라 괜찮다"는 판단의 위험은?
• 로봇 보안이 일반 IT 보안과 다른 핵심 지점은?
• 자산 아홉 가지와, 첫 줄이 "물리적 제어"인 이유는?
• 자산별로 필요한 보호(인증·기밀성·무결성)의 차이를 설명할 수 있는가.
• 위협 여섯 분류와 각각의 ROS 2 예를 들 수 있는가.
• 로봇 특유의 위협 다섯 가지와, "센서 데이터 위조"가 특히 위험한 이유는?
• 안전 기능이 소프트웨어에만 있으면 무엇이 문제인가.
• 서비스 거부에 대한 현실적 대응은?
• 공격면 여섯 지점과, 과소평가되는 것은?
• 위험 평가의 다섯 축과, "수용"이 정당한 결정인 이유는?
• 신뢰 경계 다섯 가지와, 가장 중요한 경계는?
• "로봇 내부는 신뢰"라는 초기 모델의 합리성과 한계는?
• 플릿 서버 침해를 가정한 로봇 측 방어가 필요한 이유는?
• 방어 다섯 계층과, 로봇에서 ⑤가 특별한 의미를 갖는 이유는?
• 애플리케이션 수준 방어 여덟 가지와, 입력 검증의 이중 효과는?
• "최종 속도 제한을 제어 계층에서"라는 조언의 근거는?
• 개발과 운영의 보안을 분리하라는 조언과, "나중에 추가한다"가 실패하는 이유는?

다음 장 13.2는 첫 번째 대책 — SROS 2를 다룬다. 키스토어·enclave·정책으로 노드에 신원과 권한을 부여하는 방법.