제13부 보안
13.4 운영 보안 — 격리·업데이트·비밀 관리
13.4.1 이 장에서 배우는 것 / 선수 지식
13.2·13.3은 미들웨어 층의 대책이었다. 그런데 13.1.8의 방어 계층 표에서 보았듯, 네트워크 격리(②)가 비용 대비 효과가 가장 크다. SROS 2 도입이 어려운 조직도 네트워크 분리와 시스템 강화는 할 수 있고, 그것만으로도 위험이 크게 준다.
이 장은 ROS 2 밖의 보안 — 네트워크, OS, 배포, 비밀 관리, 그리고 운영 절차를 다룬다. 로봇이 결국 네트워크에 연결된 리눅스 컴퓨터라는 사실에서 오는 문제들이다.
배우는 것:
- 네트워크 격리 — 분리·통제·원격 접근.
- 시스템 강화 — OS 수준.
- 비밀 관리 — 키·자격 증명.
- 소프트웨어 갱신 — 패치와 그 딜레마.
- 물리 보안 — 포트·저장매체.
- 감시와 대응 — 이상을 알아채기.
- 점검 목록 — 배포 전 확인.
선수 지식: 13.1(위협 모델), 3.9(네트워크), 4.7(소스 빌드·워크스페이스), 6.9(진단), 11.3(기록·프라이버시), 14.8(배포 — 함께 읽으면 좋다).
정직: 이 장은 개념과 판단 원칙을 다루며, 특정 제품·설정의 권장을 하지 않는다. 조직의 IT·보안 정책이 우선하며, 규제 대상 시스템은 보안 전문가의 설계·검토를 받아야 한다. 도구·명령의 세부는 배포판 의존이다
(확인 필요). 이 환경에서 검증하지 않았다(목차 3). 142차가ROS_AUTOMATIC_DISCOVERY_RANGE의 실제 효과를 실행 확인했다 — 13.4.2를 보라.
13.4.2 네트워크 격리
가장 효과적인 첫 조치다.
| 조치 | 효과 |
|---|---|
| 전용 VLAN·물리 분리 | 도달 범위 축소 |
| 방화벽 규칙 | 필요한 포트만 |
| 무선 보안 | 강한 인증·암호화 |
| 개발망 분리 | 개발 설정 유출 방지 |
| VPN | 원격 접근 통제 |
| 세그먼트 분할 | 침해 확산 제한 |
견해: "로봇 도메인에 누가 접근할 수 있는가"를 네트워크로 먼저 답하라. ROS 2의 디스커버리는 도달 가능한 모든 곳으로 퍼지므로(3.3.5), 네트워크 도달 범위가 곧 보안 경계가 된다. 이것을 좁히는 것이 가장 비용이 낮고 확실하다.
견해: 개발망과 운영망을 분리하라. 개발망에는 보안이 꺼진 시스템·디버그 설정·테스트 키가 있다. 이것이 운영망과 연결되면 가장 약한 고리가 전체 보안 수준이 된다.
ROS 2 특유의 고려:
| 항목 | 설명 |
|---|---|
ROS_DOMAIN_ID 분리 | 보안 수단이 아님 — 편의일 뿐 |
| 멀티캐스트 범위 | 라우터 넘어가지 않게(3.3.5) |
| Discovery Server | 참여 지점 통제 가능(3.10) |
ROS_AUTOMATIC_DISCOVERY_RANGE | 범위 제한(확인 필요) |
실행 확인(142차,
ros:jazzy-ros-base).ROS_AUTOMATIC_DISCOVERY_RANGE의 실제 효과를 세 값으로 재현했다(talker+listener, 같은 컨테이너) —OFF는 같은 호스트 안에서도 디스커버리를 완전히 막았다(listener 로그가 4초 넘게 완전히 비어 있음, "I heard"가 단 한 줄도 안 출력됨).LOCALHOST·SUBNET(기본값과 동등)은 정상적으로 통신됐다(즉시 "I heard: [Hello World: 1]"부터 순서대로 수신). "범위 제한"이라는 서술은 정확하다 —OFF는 이름과 달리 "제한"이 아니라 "전면 차단"에 가깝다는 것도 함께 확인했다(정적 피어 설정이나 Discovery Server 없이는 전혀 아무도 못 찾는다). 목차 3.
함정:
ROS_DOMAIN_ID를 보안 수단으로 착각하지 말라. 도메인 ID는 누구나 바꿔 설정할 수 있으므로, 접근 통제가 아니라 트래픽 분리 편의다. 1.5.8에서 다룬 그대로다.
견해: Discovery Server(3.10)가 보안 관점에서도 유용하다. 참여자가 서버를 통해서만 서로를 찾게 하면, 서버 접근을 통제하는 것으로 그래프 참여를 통제할 수 있다. 다만 이것은 인증이 아니므로 SROS 2를 대체하지 않는다.
13.4.3 원격 접근
필요하지만 위험한 경로다.
| 항목 | 원칙 |
|---|---|
| SSH 키 인증 | 암호 인증 비활성 |
| 최소 권한 계정 | root 직접 로그인 금지 |
| VPN 경유 | 직접 노출 금지 |
| 다중 인증 | 가능하면 |
| 세션 로깅 | 누가 무엇을 했나 |
| 접근 시간 제한 | 필요 시에만 |
| 포트 노출 최소 | 인터넷 직접 노출 금지 |
견해: "로봇에 SSH 포트를 인터넷에 열어 두는 것"이 가장 흔하고 위험한 실수다. 원격 지원을 위해 임시로 열고 잊는 경우가 많다. VPN이나 아웃바운드 연결 기반 원격 지원을 쓰고, 인바운드 노출을 피한다.
견해: 원격 조작(teleoperation)은 원격 접근과 다르게 다뤄야 한다. 사람이 실시간으로 로봇을 움직이는 경로는 영향이 가장 크므로, 강한 인증·세션 관리·연결 상실 시 즉시 정지(14.2.6)가 필수다. 명령 지연·끊김이 안전 문제가 되기도 한다.
함정: 원격 접근 계정·키를 사람이 떠난 뒤에도 남겨 두는 경우가 많다. 계정·키의 생애주기 관리를 절차로 두라.
13.4.4 시스템 강화
| 항목 | 조치 |
|---|---|
| 불필요한 서비스 제거 | 공격면 축소 |
| 최소 설치 | 기본 이미지 축소 |
| 사용자 권한 최소화 | ROS를 root로 실행하지 않기 |
| 파일 권한 | 키·설정 보호 |
| 자동 로그인·기본 암호 | 제거 |
| 커널·시스템 설정 | 배포판 지침 |
| 디스크 암호화 | 물리 탈취 대비 |
| 감사 로깅 | 시스템 이벤트 |
견해: "ROS 노드를 root로 실행"이 흔한데, 대개 불필요하다. 실시간 우선순위·장치 접근을 위해 root를 쓰는 경우가 있는데,
limits.conf(12.2.5)와 udev 규칙(6.1.8)으로 대체 가능하다. root 실행은 침해 시 피해를 키운다.
견해: 디스크 암호화는 로봇에서 판단이 갈린다. 물리적 탈취 위험이 있으면 가치가 크지만, 무인 부팅에서 키를 어떻게 제공할 것인가라는 문제가 생긴다. 이 설계는 보안 전문가와 논의할 사항이다.
함정: 개발용 편의 설정이 이미지에 남는다 — 기본 암호, sudo 무암호, 열린 디버그 서비스, 개발용 인증서. 운영 이미지 빌드를 개발 환경과 분리하고(14.8), 점검 목록으로 확인한다(13.4.8).
13.4.5 비밀 관리
키·자격 증명을 어떻게 다룰 것인가.
| 비밀 | 예 |
|---|---|
| SROS 2 개인키 | 신원(13.2.3) |
| SSH 키 | 접근 |
| 클라우드·API 자격 증명 | 플릿 서버·원격 서비스 |
| 무선 자격 증명 | 네트워크 |
| DB·서비스 암호 | 내부 시스템 |
| 원칙 | 설명 |
|---|---|
| 소스 저장소에 넣지 않는다 | 이력에 영원히 남음 |
| 로그에 남기지 않는다 | 1.11.8 |
| 로봇별 고유 자격 증명 | 하나 유출 시 범위 제한 |
| 최소 권한 | 그 로봇에 필요한 것만 |
| 회전 절차 | 주기적 교체 |
| 폐기 절차 | 침해·폐기 시 |
함정: 저장소에 커밋된 비밀은 지워도 이력에 남는다. 발견 즉시 해당 자격 증명을 무효화해야 하며, 커밋을 되돌리는 것만으로는 부족하다. 커밋 전 검사 도구를 CI에 넣는 것(4.10)이 예방책이다.
함정: 로그·bag에 비밀이 들어간다(1.11.8·11.3.9). 디버그 로그에 토큰을 출력하거나, 설정 전체를 로깅하면 그것이 기록에 남고 분석을 위해 공유된다. 로깅 시 민감 필드를 제외하는 규칙이 필요하다.
견해: "로봇마다 다른 자격 증명"이 규모에서 중요해진다. 모든 로봇이 같은 키를 쓰면 하나가 침해될 때 전체가 영향을 받고, 폐기하면 전체를 교체해야 한다. 프로비저닝 시 로봇별로 발급하는 구조가 표준적 방법이며, 이는 배포 파이프라인 설계(14.8)의 일부다.
13.4.6 소프트웨어 갱신
보안 패치는 필요하지만 로봇에서는 딜레마가 있다.
| 딜레마 | 설명 |
|---|---|
| 검증된 조합 | 로봇은 특정 버전 조합에서 검증됨 |
| 갱신 시 재검증 | 비용 |
| 미갱신 시 취약점 누적 | 위험 증가 |
| 무인 운영 | 갱신 실패 시 복구 어려움 |
| 대응 | 설명 |
|---|---|
| 보안 패치와 기능 갱신 분리 | 위험 차등 |
| 단계적 배포 | 일부 → 전체(14.9) |
| 롤백 가능한 구조 | A/B 파티션 등(14.8) |
| 회귀 시험 자동화 | 재검증 비용 감소(14.6) |
| 취약점 추적 | 무엇이 영향받는가 |
| 오프라인 갱신 경로 | 네트워크 없는 환경 |
견해: "갱신하지 않는 것"이 안전하다는 생각은 시간이 갈수록 틀려진다. 알려진 취약점이 누적되고, 대응 수단이 없어진다. 정기적 갱신 절차와 그것을 감당할 자동 시험을 갖추는 것이 장기적으로 안전하다.
견해: 롤백 가능성이 갱신 정책의 전제다. 갱신이 실패하거나 문제를 일으켰을 때 되돌릴 수 없으면, 팀은 갱신을 두려워하게 되고 결국 안 하게 된다. 롤백 구조가 곧 갱신 빈도를 결정한다(14.8).
함정: 의존성의 취약점을 추적하지 않으면 무엇을 갱신해야 할지 모른다. 어떤 패키지·버전을 쓰는지 목록(SBOM 성격)을 유지하면(14.7), 취약점 공지가 나왔을 때 영향 범위를 판단할 수 있다.
정직: 로봇의 갱신 정책은 안전 검증과 얽힌다. 안전 관련 기능이 있는 시스템에서는 갱신이 재검증을 요구할 수 있으며, 그 판단은 안전·규제 요구와 전문가의 영역이다.
13.4.7 물리 보안과 감시
| 물리 조치 | 설명 |
|---|---|
| 포트 비활성·봉인 | USB·디버그 포트 |
| 케이스 잠금 | 접근 제한 |
| 저장매체 암호화 | 탈취 대비 |
| 부팅 보호 | 승인된 소프트웨어만(확인 필요: 플랫폼) |
| 개조 탐지 | 물리적 접근 흔적 |
견해: 로봇은 사람이 접근할 수 있는 곳에서 운영된다는 점이 IT 서버와 다르다. 데이터센터의 서버와 달리 공용 공간의 로봇은 물리적으로 만질 수 있다. USB 포트 하나가 열려 있으면 많은 대책이 우회될 수 있다.
감시:
| 감시 항목 | 수단 |
|---|---|
| 인증 실패 | 보안 로그(13.3) |
| 예상치 못한 참여자 | 그래프 감시 |
| 비정상 명령 패턴 | 애플리케이션 검증(13.1.9) |
| 시스템 이벤트 | OS 감사 로그 |
| 접근 기록 | SSH·원격 세션 |
| 무결성 변화 | 파일 검사 |
견해: "예상치 못한 노드가 그래프에 나타났는가"를 감시하는 것이 ROS 2 특유의 유용한 지표다. 알려진 노드 목록과 비교해 낯선 참여자를 진단으로 경보하면(6.9), 침해의 초기 신호를 포착할 수 있다.
견해: 감시는 대응 절차가 있을 때만 의미가 있다. 경보가 울려도 아무도 안 보거나 조치가 없으면 소용없다. 누가·무엇을 할지 정해 두는 것이 감시 설계의 일부다.
13.4.8 배포 전 점검 목록
개발 편의 설정이 운영에 새는 것을 막는다.
| # | 확인 |
|---|---|
| 1 | 기본 암호·자동 로그인 제거 |
| 2 | 불필요한 서비스·포트 비활성 |
| 3 | SSH 암호 인증 비활성·키만 |
| 4 | root 직접 로그인 금지 |
| 5 | 개발용 인증서·테스트 키 제거 |
| 6 | 디버그 인터페이스·서비스 제거 |
| 7 | 로그 레벨이 운영 수준(1.11.4) |
| 8 | allow_unauthenticated_participants=false(13.3.4) |
| 9 | ROS_SECURITY_STRATEGY=Enforce(13.2.6) |
| 10 | 릴리스 빌드(12.6.8) |
| 11 | 로봇별 고유 자격 증명 |
| 12 | 인증서 유효기간 확인 |
| 13 | 방화벽 규칙 적용 |
| 14 | 시계 동기 설정(7.7.6) |
| 15 | 기록 대상에 민감정보 없음(11.3.9) |
| 16 | 갱신·롤백 경로 동작 확인 |
견해: 이 점검을 자동화하라. 사람이 목록을 읽고 확인하는 방식은 규모가 커지면 실패한다. 이미지 빌드 후 자동 검사 스크립트로 만들면(14.8), 매번 확실히 수행된다.
견해: "운영 이미지와 개발 이미지를 다른 파이프라인으로"가 근본 해법이다. 같은 이미지를 설정만 바꿔 쓰면 실수가 생긴다. 운영 이미지에는 개발 도구가 처음부터 들어가지 않게 빌드하는 것이 확실하다.
13.4.9 사고 대응 준비
침해가 의심될 때 무엇을 할 것인가.
| 단계 | 조치 | 목적·비고 |
|---|---|---|
| 1 | 안전 확보 | 로봇 정지·물리적 격리 |
| 2 | 네트워크 분리 | 확산 차단 |
| 3 | 증거 보존 | 로그·디스크 이미지·메모리 덤프 (확인 필요: 사내 절차) |
| 4 | 범위 파악 | 다른 로봇도 감염됐나 |
| 5 | 자격 증명 무효화 | 키·인증서·계정 |
| 6 | 복구 | 알려진 정상 이미지로 재설치 |
| 7 | 원인 분석 | 11.1.8 |
| 8 | 재발 방지 | 대책 수립·적용 |
견해: 1번이 로봇 보안의 특징이다. IT 침해 대응은 대개 시스템 격리부터 시작하지만, 로봇은 물리적으로 움직이므로 안전 확보가 먼저다. 침해된 로봇이 계속 동작하게 두면 물리적 피해가 생길 수 있다.
견해: "증거 보존과 복구는 상충한다"는 점을 미리 알아 두라(11.1.5의 "재부팅 유혹"과 같은 구조). 빨리 복구하려고 재설치하면 원인 분석이 불가능해진다. 최소한의 증거를 확보한 뒤 복구하는 절차를 정해 둔다.
정직: 본격적인 사고 대응은 전문 영역이다. 여기 제시한 것은 준비의 개념 틀이며, 규제 대상이거나 피해가 큰 사고는 보안 전문가·법무·규제 기관 관련 절차를 따라야 한다.
13.4.10 함정 카탈로그
| # | 함정 | 증상 | 대처 |
|---|---|---|---|
| 1 | ROS_DOMAIN_ID를 보안으로 착각 | 무방비 | 네트워크·SROS 2 |
| 2 | 개발망·운영망 연결 | 약한 고리 | 분리 |
| 3 | SSH를 인터넷에 노출 | 상시 공격 대상 | VPN·아웃바운드 |
| 4 | root로 ROS 실행 | 피해 확대 | 최소 권한 |
| 5 | 기본 암호·개발 설정 잔존 | 취약 | 자동 점검 |
| 6 | 비밀을 저장소에 커밋 | 이력에 영구 | 무효화·CI 검사 |
| 7 | 로그·bag에 비밀 | 유출 | 필드 제외 |
| 8 | 모든 로봇 동일 자격 증명 | 확산 | 로봇별 발급 |
| 9 | 갱신 회피 | 취약점 누적 | 절차·자동 시험 |
| 10 | 롤백 불가 | 갱신 기피 | 구조 확보 |
| 11 | 의존성 목록 없음 | 영향 판단 불가 | 목록 유지 |
| 12 | USB·디버그 포트 개방 | 우회 | 비활성·봉인 |
| 13 | 감시만 하고 대응 없음 | 무의미 | 절차 정의 |
| 14 | 침해 시 로봇 계속 동작 | 물리적 피해 | 안전 확보 우선 |
| 15 | 성급한 복구 | 원인 불명 | 증거 보존 |
| 16 | 퇴사자 계정·키 잔존 | 접근 유지 | 생애주기 관리 |
13.4.11 체크포인트
- 네트워크 격리가 비용 대비 효과가 큰 이유는?
- "네트워크 도달 범위가 곧 보안 경계"라는 말의 근거는?
ROS_DOMAIN_ID가 보안 수단이 아닌 이유와, Discovery Server의 보안적 유용성·한계는?- 원격 접근의 일곱 원칙과, 가장 흔한 위험한 실수는?
- 원격 조작을 원격 접근과 다르게 다뤄야 하는 이유는?
- 시스템 강화 여덟 항목과, root 실행을 피하는 대체 수단은?
- 비밀 다섯 종류와 관리 여섯 원칙을 말할 수 있는가.
- 저장소에 커밋된 비밀을 발견했을 때의 조치는?
- 로그·bag에 비밀이 들어가는 경로와 예방은?
- 로봇별 고유 자격 증명이 규모에서 중요한 이유는?
- 갱신의 딜레마 네 가지와 대응 여섯 가지를 말할 수 있는가.
- "롤백 구조가 갱신 빈도를 결정한다"의 의미는?
- 로봇의 물리 보안이 IT 서버와 다른 점은?
- ROS 2 특유의 유용한 감시 지표는 무엇인가.
- 배포 전 점검 열여섯 항목 중 다섯 이상을 들 수 있는가. 자동화를 권하는 이유는?
- 사고 대응 여덟 단계와, 1번이 로봇에서 특별한 이유는?
- 증거 보존과 복구가 상충하는 상황에서의 원칙은?
다음 장 13.5는 제13부의 마지막 — 보안의 비용이다. 무엇을 지불하고 무엇을 얻는지, 그리고 어디까지 할 것인지 판단하는 방법.