# ROS2 보안 아키텍처 개요

#### 보안 아키텍처 기본 구성

ROS2의 보안 아키텍처는 DDS(Datat Distribution Service) 계층 위에서 동작하며, DDS Security 플러그인과 ROS2 보안 옵션을 통합하여 구현된다. DDS Security는 접근 제어, 인증, 암호화 등 보안을 위한 기초적 메커니즘을 제공하며, ROS2는 이 위에 **패키지** 또는 **툴링** 형태로 추가 기능을 제공한다. 이를 흔히 SROS2(Secure ROS2)라고 부르며, 아래와 같은 3가지 주요 영역에 중점을 둔다.

1. **인증(Identity Authentication)**
   * 통신 당사자(Participant)가 신뢰할 수 있는 주체인지 판별
   * 인증서, 키 등 보안 자격 증명(Credentials)을 사용
2. **액세스 제어(Access Control)**
   * 메시지 Publish/Subscribe 권한 관리
   * ROS2 종단 간 통신 토픽/서비스에 대한 권한 검사
3. **암호화(Cryptography)**
   * DDS Participant 간 메시지 암호화
   * 메시지 기밀성과 무결성 보장

이러한 보안 아키텍처의 목표는 네트워크 상에서 ROS2 노드들이 안전하게 통신하도록 하는 것이며, DDS Security 스펙 내의 플러그인을 활용하여 유연하게 구축 가능하다.

#### DDS Security 플러그인 개념

DDS Security는 여러 플러그인으로 구성되어 있다. 각 플러그인은 DDS 통신에 필요한 보안 기능(인증, 권한, 암호화 등)을 담당하고 있으며, 이것이 ROS2 노드들 간 통신에 적용된다.

* **인증 플러그인(Authenticaton Plugin)** 인증서나 키 등을 확인해 DDS Participant의 신뢰성을 검증한다.
* **액세스 제어 플러그인(Access Control Plugin)** ROS2 보안 정책 파일(permissions.xml 등)에 정의된 권한을 해석하고, 각 Participant가 특정 토픽 또는 서비스에 Publish/Subscribe할 수 있는지 판단한다.
* **암호화 플러그인(Cryptographic Plugin)** DDS Writer(메시지 송신자)와 DDS Reader(메시지 수신자) 사이에서 메시지를 암호화/복호화하여 기밀성과 무결성을 보장한다.

ROS2는 이러한 DDS Security 플러그인을 **추상화된 인터페이스**로 연동해 사용하기 때문에, 하위 DDS 구현(Vendor)에 구애받지 않고 보안 구성을 표준화된 형태로 적용할 수 있다.

#### 보안 아티팩트(Artifacts)와 디렉터리 구조

ROS2 보안 기능을 활성화하려면, 각 노드는 보안에 필요한 파일과 디렉터리 구조를 정확히 갖추어야 한다. 이를 보통 “보안 아티팩트(artifacts)”라고 부르며, 다음과 같은 요소를 포함한다.

1. **정체성(Identity) 인증서**
   * Participant가 누구인지 식별하기 위한 X.509 인증서
   * Identity CA(Certificate Authority)가 서명한 인증서와 개인 키(Private Key) 필요
2. **권한(Permissions) 파일**
   * ROS2 노드(Participant)가 사용할 수 있는 토픽, 서비스 등에 대한 권한(policy) 선언
   * Permissions CA가 서명한 XML 형식의 policy 파일
3. **Governance 파일**
   * 전체 시스템에서 공통으로 준수해야 할 보안 정책(암호화 수준, 인증 방식, 로깅 등)을 명시
   * DDS Security에서 요구하는 형식으로 작성

일반적으로 보안 아티팩트는 특정 디렉터리 구조 하에 배치되며, ROS2 런타임은 이 디렉터리를 탐색하여 보안을 초기화한다. 예를 들어, 노드 이름 혹은 Participant의 이름에 따라 디렉터리 경로가 분기되고, 각 경로 하위에 `governance.xml`, `permissions.xml`, `certs/` 등이 존재한다.

#### 보안 영역(Security Enclave)

ROS2에서는 **보안 영역(Security Enclave)** 개념이 도입되어, 서로 동일한 보안 설정을 공유해야 하는 노드들을 하나의 영역(Enclave)으로 묶어 관리할 수 있다. 보안 영역은 아래와 같은 특징이 있다.

* 하나의 보안 영역 내에서는 동일한 인증서와 권한 설정을 공유한다.
* 노드의 실제 이름(Secure Node Name)과 상관없이, 보안 영역 디렉터리에 배치된 보안 아티팩트만 일치하면 영역 내 다른 노드들과 안전하게 통신할 수 있다.
* 보안 영역을 적절히 분리/통합해 관리함으로써, 여러 노드 그룹 간 상이한 보안 정책을 적용할 수 있다.

#### 암호화와 키 분배

ROS2 보안에서 핵심이 되는 부분은 암호화를 통해 통신 데이터를 보호하는 것이다. DDS Security 암호화 플러그인은 **세션 키(Session Key)** 기반으로 암호화를 수행하는데, 다음과 같은 흐름으로 동작한다.

1. **인증서 교환**: 각 Participant는 인증서를 교환하여 상대가 신뢰할 수 있는 주체임을 확인한다.
2. **세션 키 생성**: 인증에 성공하면, Participant 간 안전한 채널을 통해 세션 키를 생성한다.
3. **메시지 암호화**: DDS Writer가 세션 키로 메시지를 암호화해 전송한다. DDS Reader는 세션 키로 이를 복호화한다.

이때 사용되는 암호 알고리즘은 정책에 따라 다를 수 있으며, 보통 AES-GCM 등 블록 암호 방식을 사용한다. 세션 키 교환 과정에서 **비대칭 키**(예: RSA, ECC)가 사용되고, 이후 실제 데이터 암호화 시에는 **대칭 키**(AES 등)가 활용된다.

예를 들어, 세션 키를 $\mathbf{k}$라 하고, 송신하는 메시지 $\mathbf{m}$을 AES-GCM으로 암호화한 결과를 $\mathbf{c}$라 할 때,

$$
\mathbf{c} = \text{AES-GCM}(\mathbf{k}, \mathbf{m})
$$

형태로 표현할 수 있다. 이 $\mathbf{c}$가 DDS RTPS(Real-Time Publish-Subscribe) 프로토콜 상에서 전송되고, 수신 측은 동일한 $\mathbf{k}$로 복호화한다.

#### SROS2와 보안 아티팩트 자동 생성

ROS2 보안을 활성화하려면, 앞서 언급한 인증서와 권한, 거버넌스 파일이 필요하다. 이를 사람이 일일이 작성하는 것은 번거롭기 때문에, **SROS2**(Secure ROS2)에서는 이를 자동화하는 명령줄 도구를 제공한다. 대표적으로 다음과 같은 과정을 통해 보안 아티팩트를 생성할 수 있다.

1. **키 스토어(Key Store) 생성**
   * 보안 아티팩트를 저장할 디렉터리(키 스토어)를 생성한다.
   * 키 스토어에는 루트 CA, 노드별 CA, 정책 파일 등을 배치한다.
2. **거버넌스(Governance) 파일 생성**
   * 암호화 유형, 로깅, 액세스 제어 방식 등 전반적인 시스템 보안 정책이 담긴 파일이다.
   * 보통 `governance.xml`로 명명하며, SROS2 CLI 도구가 기본 템플릿을 제공한다.
3. **권한(Permissions) 파일 생성**
   * 노드(Participant)가 접근 가능한 토픽/서비스 및 그 동작 권한을 명세한다.
   * 보통 `permissions.xml`로 명명하며, SROS2 CLI 도구가 기본 구조를 생성해 준 후 필요에 맞게 수정한다.

아래 예시는 SROS2 CLI를 활용해 키 스토어와 보안 아티팩트를 생성하는 일반적인 절차를 보여준다.

```bash
# 1. 키 스토어 디렉터리를 생성한다
ros2 security create_keystore my_secure_workspace

# 2. 특정 노드 이름(예: my_secure_node)에 대한 보안 아티팩트를 생성한다
ros2 security create_key my_secure_workspace my_secure_node

# 3. 거버넌스/권한 파일 템플릿을 자동 생성한다
ros2 security generate_artifacts --policy my_policy_file.xml my_secure_workspace my_secure_node
```

각 명령이 성공적으로 실행되면, `my_secure_workspace/` 디렉터리 내부에 필요한 인증서와 정책 파일이 자동으로 생성된다. 이후 생성된 XML 파일(`governance.xml`, `permissions.xml`)을 직접 열어서, 시스템 요구 사항이나 네트워크 정책에 맞도록 편집해야 한다.

#### ROS2 런타임에서 보안 활성화

ROS2에서 보안을 활성화하기 위해서는, 실행 시점에 다음과 같은 환경 변수를 세팅하거나 ROS2 파라미터를 지정해 주어야 한다.

* `ROS_SECURITY_STRATEGY=Enforce`
  * 보안을 활성화하고, 필요한 아티팩트가 없을 경우 노드가 실행되지 않도록 강제한다.
* `ROS_SECURITY_KEYSTORE=PATH`
  * 키 스토어(보안 아티팩트가 위치한 디렉터리)의 경로를 지정한다.
* `ROS_SECURITY_ENABLE=true`
  * 보안 기능을 켠다.

예를 들어,

```bash
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_KEYSTORE=$HOME/my_secure_workspace
export ROS_SECURITY_ENABLE=true
```

이와 같이 환경 변수를 설정한 후에 ROS2 노드를 실행하면, ROS2 런타임은 해당 키 스토어 디렉터리에서 거버넌스/권한/인증서 파일을 검색하여 DDS Security 플러그인을 초기화한다.

#### 보안 디렉터리 구조 예시

ROS2 보안을 활성화하기 위해서는, 보안 아티팩트(인증서, 권한 파일, 거버넌스 파일 등)가 특정 디렉터리 구조로 배치되어야 한다. 이 디렉터리 구조는 ROS2가 내부적으로 DDS Security 플러그인을 초기화할 때 활용한다. 일반적으로 아래와 같은 방식으로 구성된다.

```
my_secure_workspace/
 ├── governance.xml
 ├── permissions.xml
 ├── certs/
 │    ├── identity_ca.cert.pem
 │    ├── identity_ca.key.pem
 │    ├── permissions_ca.cert.pem
 │    ├── permissions_ca.key.pem
 │    ├── ...
 └── my_secure_node/
      ├── identity.cert.pem
      ├── identity.key.pem
      ├── permissions.p7s
      └── ...
```

* **`governance.xml`**: DDS Security에서 요구하는 거버넌스(Governance) 설정 파일로, 전체 보안 정책(암호화 방안, 로깅 여부 등)을 정의한다.
* **`permissions.xml`**: 노드(Participant) 권한을 기술한 XML 원본 파일이며, CA(permissions\_ca)로부터 서명된 `permissions.p7s`로 변환되어 실제 활용된다.
* `certs/`: CA와 관련된 인증서와 키가 존재한다.
* `identity_ca.cert.pem`, `identity_ca.key.pem`: ID 인증을 위한 CA와 개인키
  * `permissions_ca.cert.pem`, `permissions_ca.key.pem`: 권한(permissions) 서명용 CA와 개인키
* `my_secure_node/`: 특정 Participant(노드)의 인증서와 키를 저장하는 디렉터리
* `identity.cert.pem`: 노드가 사용할 X.509 인증서
  * `identity.key.pem`: 노드가 사용할 개인 키
* `permissions.p7s`: CA(permissions\_ca)가 서명한 권한(permissions) 정보

이 구조는 ROS2에서 “보안 영역(Security Enclave)” 단위로 구분될 수 있으며, 노드 이름이나 네임스페이스에 따라 디렉터리 위치를 달리 설정할 수도 있다.

#### 노드 이름과 보안 관련성

ROS2에서 노드 이름, 네임스페이스는 DDS Participant의 식별자와 직접적으로 연결된다. 보안 아티팩트를 로드할 때, DDS Security 플러그인은 내부적으로 Participant 이름과 디렉터리 경로를 매칭한다. 이때 다음과 같은 주의 사항이 있다.

1. **정확한 매칭**
   * ROS2가 DDS Participant 이름을 생성할 때, 노드 이름과 네임스페이스를 결합한 문자열이 사용된다.
   * 생성된 Participant 이름이 디렉터리 구조와 일치하지 않으면, 보안 아티팩트를 불러오지 못한다.
2. **와일드카드 사용**
   * 특정 시나리오에서는 Participant 이름이 유동적으로 바뀔 수 있다.
   * 이 경우, SROS2에서 디렉터리 경로에 와일드카드(\*)를 사용해 유연하게 적용할 수 있다.
3. **Alias 기법**
   * Participant가 반드시 실제 노드 이름과 같을 필요는 없다.
   * 고정된 Participant 이름을 사용하면서, 노드 레벨에서는 다른 이름을 쓸 수도 있다.
   * 다만 권장 방식은 아니다. 실제 노드 이름과 Participant 이름이 불일치하면, 디버깅 시 혼동이 생길 수 있다.

#### 분산 시스템에서의 키 스토어 관리

ROS2가 주로 적용되는 환경은 로보틱스, IoT 등의 분산 시스템이다. 보안 아티팩트를 각 장치(에지 디바이스, 로봇 컨트롤러 등)에 개별적으로 배포해야 하는데, 이때 키 스토어를 어떻게 관리·분배할지가 중요한 과제가 된다.

* **오프라인 관리**
  * 인터넷이나 외부 네트워크에 직접 연결되지 않은 환경에서, USB 메모리 등으로 키 스토어를 물리적으로 전달하는 방식
  * 보안상 안전하지만, 업데이트나 새 노드 추가 시 번거로움
* **중앙 집중식 관리**
  * CA와 SROS2 도구를 중앙 서버에 두고, 각 노드가 온라인으로 연결될 때 보안 아티팩트를 자동 발급받는 구조
  * 노드 프로비저닝(provisioning) 절차가 간편하지만, 중앙 서버가 장애를 일으키면 시스템 전체가 영향을 받을 수 있음
* **온디맨드(Over the Air) 업데이트**
  * 무선 네트워크를 통해, 주행 중인 로봇이나 디바이스에 보안 아티팩트를 동적으로 업데이트
  * 반드시 안전한 채널을 마련해야 하며, OTA(Over the Air) 업그레이드 시점에 통신 암호화를 유지해야 함

이처럼 키 스토어의 생성, 배포, 업데이트 과정을 어떻게 설계하느냐가 ROS2 보안 아키텍처 전반의 신뢰도에 직결된다.

#### 보안 정책 설계 전략

ROS2 보안 아키텍처를 온전히 구현하기 위해서는, 단순히 인증서와 권한 파일만 준비하는 것에서 끝나지 않고, 시스템의 요구사항에 맞는 **보안 정책**을 설계해야 한다. 이를 위해 다음과 같은 사항들을 고려하는 것이 좋다.

1. **네트워크 토폴로지 분석**
   * ROS2 시스템이 동작하는 네트워크 환경이 유선인지 무선인지, 외부 네트워크와 어떤 식으로 연결되는지 등을 분석한다.
   * 네트워크 스니핑(sniffing), IP 스푸핑(spoofing) 등 발생 가능성이 높은 공격 벡터를 식별하고, 보안 정책에서 대응 방안을 마련한다.
2. **노드·토픽·서비스별 중요도 구분**
   * 예컨대 센서 데이터와 로봇 제어 명령은 기밀성 요구 수준이 다를 수 있다.
   * 고가치 토픽(예: 제어 명령, 비전 영상)은 반드시 암호화/무결성 검증이 필요할 수 있지만, 저가치 토픽(예: 로그 데이터)은 선택적으로 암호화를 적용할 수도 있다.
   * 권한 파일(permissions.xml)에서 세분화된 권한 설정이 필요하다.
3. **암호화 수준(Encryption Level)**
   * DDS Security에서 지원하는 암호 알고리즘이나 키 길이를 선택한다.
   * AES-128, AES-256과 같은 블록 암호 알고리즘 사용 시 성능과 보안 수준 간 적절한 균형을 찾는다.
   * RTOS(Real-Time Operating System)나 임베디드 환경에서는 연산 리소스가 제한적이므로, 과도한 암호화 설정은 실시간성을 저해할 수 있다.
4. **토픽 우선순위(QoS)와 보안의 관계**
   * ROS2 QoS(품질 정책) 설정 중에서 Reliable/Best-Effort, Keep Last/Keep All 등이 보안 플러그인의 암호화·무결성 검증 성능에 영향을 줄 수 있다.
   * 예: Reliable 정책으로 설정된 토픽이 많으면, 암호화/복호화 오버헤드가 네트워크 전체 성능에 영향을 준다.
5. **추가 방어 기법 연계**
   * DDS Security 플러그인만으로는 완벽한 방어가 어려울 수 있다. 예: 운영체제 보안, 방화벽 설정, VPN, IDS(Intrusion Detection System) 등과 연계 필요.
   * 로컬 네트워크 내부라 하더라도, 내부 사용자의 실수나 내부 공격자를 대비해야 한다.

#### RTPS 보안과 인터옵(interoperability)

ROS2는 DDS RTPS(Real-Time Publish-Subscribe) 프로토콜을 기반으로 한다. RTPS의 보안 확장 기능을 활성화하면, 암호화·권한 검사가 RTPS 세션 수준에서 이뤄진다. 이를 통해 **서로 다른 DDS 벤더**(eProsima Fast DDS, RTI Connext, Eclipse Cyclone DDS 등)가 제공하는 DDS Security 구현이 상호 운영(interop) 가능하도록 설계되었다.

* **미준수 벤더와의 통신**
  * 일부 DDS 구현체가 DDS Security 표준을 완전하게 따르지 않는 경우, RTPS 보안 협상이 실패하여 통신이 불가능할 수 있다.
  * 따라서 ROS2 보안 기능을 사용하려면, DDS 벤더가 Security 프로파일을 지원하는지 반드시 확인해야 한다.
* **멀티 벤더 환경에서의 유연성**
  * ROS2는 추상화 계층(RMW, ROS Middleware Interface)을 통해 다양한 DDS 벤더를 교체 가능하도록 설계되었다.
  * 보안 활성화 시에도, 특정 벤더 종속성을 최소화하려면 DDS Security 표준에 충실하게 설정해야 한다.

#### 보안 성능 이슈

암호화와 무결성 검증 과정에서는 CPU나 메모리 같은 시스템 리소스가 추가로 소모된다. 특히 대규모 토픽(영상 스트리밍, 3D 포인트 클라우드 등)을 암호화할 경우, 성능 저하가 발생할 수 있다. 이러한 문제를 완화하기 위한 접근 방식은 다음과 같다.

1. **하드웨어 가속**
   * CPU가 AES-NI와 같은 암호화 가속 기능을 제공한다면, 이를 활용해 처리량을 높일 수 있다.
   * GPU나 FPGA에서 암호 연산을 가속하는 방안도 가능하지만, ROS2에서의 표준 지원 여부는 DDS 벤더별로 상이하다.
2. **선별적 암호화**
   * 모든 토픽을 일괄적으로 암호화하기보다, 기밀성이 높은 데이터에만 암호화를 적용한다.
   * “암호화하지 않은 토픽을 공격자가 가로챈다 해도, 시스템 안정성에 치명적이지 않다”고 판단되면 무결성 확인만 적용하거나, 아예 보안을 해제할 수도 있다.
3. **메시지 크기 최적화**
   * ROS2 메시지 구조를 단순화하여, 암호화해야 할 데이터 양을 줄인다.
   * 예: 비전 데이터는 압축 후에 퍼블리시하거나, 필요한 메타데이터만 우선 전송하고 원본은 다른 채널로 전송.
4. **QoS 튜닝**
   * Reliable 대신 Best-Effort 방식을 사용하는 토픽은 재전송이 적으므로, 보안 처리 부담이 상대적으로 줄어드는 경우가 있다.
   * 단, 중요한 제어 신호나 미션 크리티컬 데이터는 Reliable 모드가 일반적이므로, 신중한 균형이 필요하다.

#### mermaid로 보는 ROS2 보안 데이터 흐름

아래 다이어그램은 간단한 ROS2 보안 데이터 흐름을 나타낸 예시다.

{% @mermaid/diagram content="flowchart LR
A\[ROS2\nNode1] -->|"Publish (암호화)"| B\[ROS2\nMiddleware\nLayer]
B --> C{DDS\nSecurity\nPlugin}
C -->|세션 키 생성/관리| D\[ROS2\nNode2]
D -->|"Subscribe (복호화)"| B" %}

1. 노드1이 DDS Security에 의해 보호된 토픽을 Publish하면, 내부적으로 세션 키를 이용해 암호화가 수행된다.
2. 미들웨어 계층을 통해 데이터를 전송할 때, DDS Security 플러그인이 해당 메시지에 대한 암호화·무결성 검증 정보를 추가한다.
3. 노드2에서 메시지를 수신할 때 역시 DDS Security 플러그인이 복호화 과정을 거친 후, 노드2 애플리케이션 레이어에서 평문 데이터를 읽을 수 있게 된다.

#### 보안 로깅과 감사(Auditing)

ROS2 보안 아키텍처를 운용하면서, 통신을 시도하는 노드(Participant)가 허가된 주체인지, 허가되지 않은 접근 시도가 있었는지 등을 로깅하고 추적할 수 있어야 한다. DDS Security 표준은 **Logging & Auditing** 기능을 제공하지만, 그 구체적인 구현 수준과 사용 방법은 DDS 벤더별로 차이가 있다. 일반적으로 다음과 같은 로깅 포인트들이 고려된다.

1. **인증 시도 기록**
   * DDS Participant가 새로 연결될 때, 해당 인증서가 CA에 의해 유효한지 검사한 결과
   * 인증 실패 원인(예: 인증서 만료, 서명 불일치 등)
2. **액세스 거부 기록**
   * 권한(permissions.xml)에 정의되지 않은 토픽/서비스에 접근하려는 시도가 있었는지 여부
   * 노드가 보안 정책을 위반하는 경우, 이를 감지하고 기록
3. **암호화 상태 확인**
   * 세션 키 교환이 정상적으로 완료되었는지, 세션 키의 유효 기간이 만료되지 않았는지
   * 암호화 오버헤드 측정이나 성능 문제 발생 시점 기록

이러한 로깅 정보는 운영자가 **보안 이벤트를 실시간** 혹은 사후 분석으로 확인하고, 필요 시 오탐(false positive)·오경보(false alarm)를 조정할 수 있도록 도와준다. 더불어 **감사(Audit) 데이터**를 장기 보관함으로써, 보안 사고가 발생했을 때 원인을 역추적할 수 있다.

#### 고급 보안 구성: 토픽별 미세 제어

기본적으로 ROS2의 DDS Security는 노드(Participant) 단위로 권한을 설정한다. 그러나 대규모 시스템에서 일부 토픽만 엄격히 보호하거나, 특정 노드 내에서도 토픽별로 보안 수준을 달리 적용해야 할 때가 있다. 이를 위해 다음과 같은 방식을 활용할 수 있다.

1. **permissions.xml의 세분화**
   * 권한 파일에서 각 토픽에 대해 Publish/Subscribe 권한을 명시적으로 구분한다.
   * 예: 토픽 `/camera/image_raw`는 암호화를 필수로 지정, `/diagnostics`는 암호화 옵션을 off 등.
2. **멀티 노드 분할**
   * 단일 프로세스 안에서 여러 노드를 구동하기보다, 보호 수준이 필요한 노드를 별도 프로세스로 실행해 별도 보안 영역(Secure Enclave)에 할당한다.
   * 이렇게 하면 하이 레벨 보안이 필요한 노드와 일반 노드를 물리적으로(프로세스 관점에서) 분리할 수 있다.
3. **DDS 보안 분할(Partition, Domain)**
   * DDS 레벨에서 Domain을 다르게 설정하거나, Partition QoS를 활용해 보안 적용 범위를 나눈다.
   * 특정 Domain/Partition은 보안을 요구하고, 다른 Domain/Partition은 보안 비활성화 상태로 운영 가능.

이와 같이 “토픽별·노드별 맞춤 보안”을 구성하면, 불필요한 암호화 오버헤드를 줄이면서도 민감 데이터는 철저히 보호할 수 있다.

#### 배포 시나리오 예시

ROS2 보안 아키텍처는 실제 산업 현장에서 다양한 형태로 배포된다. 예시로, 자율주행 로봇과 모니터링 서버 간 보안 통신 시나리오를 들어보자.

1. **로봇(에지 디바이스) 측**
   * 내장 SoC(Board)에서 ROS2 노드를 실행한다.
   * 카메라 토픽 `/camera/image_raw`, LiDAR 토픽 `/lidar/scan` 등 민감 센서 데이터는 강력한 암호화를 적용한다.
   * 로봇 내에서 동작하는 노드끼리는 내부적으로 동일한 보안 영역을 공유하되, 외부 통신(예: 무선)에 대해서만 인증 절차를 강화한다.
2. **모니터링 서버 측**
   * 원격지(클라우드 or 사내 데이터센터)에 위치한 ROS2 노드가 로봇 센서 데이터를 Subscribe한다.
   * 서버는 복수의 로봇에서 올라오는 데이터를 수신해야 하므로, 다수 Participant에 대한 권한(permissions.xml)이 하나의 키 스토어에 모여 있다.
   * 서버는 방화벽 뒤에 위치하고, DDS 보안 외에도 VPN이나 IPSec 같은 추가 네트워크 보안을 적용할 수 있다.
3. **키 스토어 동기화**
   * 로봇과 서버 간 키 스토어 동기화는 초기 설치 시 오프라인(USB, SD 카드) 방식으로 진행한다.
   * 추가로 로봇이 현장에 새로 투입되면, 중앙 키 스토어에 등록하고 SROS2 명령을 통해 CA에서 인증서와 권한 파일을 발급받는다.

이러한 시나리오에서 ROS2 보안 아키텍처의 유연성이 돋보이며, DDS Security 표준 기능을 활용해 전체 시스템의 기밀성과 무결성을 보장할 수 있다.