Connext DDS Secure로 전환해야 하는 이유

"보안은 볼트로 고정되는 것이 아니라 내장되어야 합니다." 진실. 당신은 그것을 들었습니다. 나도 들었어. 실제로 IIoT가 빠르게 현실화되면서 이 말이 너무 반복되고 있어, 실효성 없이 긴박감을 주는 진부한 표현이 될까 걱정된다. 하지만 왜 보안은 처음부터 볼트로 고정되어 있습니까? 그 이유를 이해하면 그것을 피하는 데 도움이 됩니까? 나는 희망한다. 경제적인 이유부터 규제, 교육 및 기술적인 이유에 이르기까지 많은 이유가 있으며 이 블로그 게시물에서 자세히 설명할 수 없습니다(자세한 내용은 IISF 참조).

어떤 경우에는 위협 환경, 관련 위험 및 보안 고려 사항이 시스템 아키텍처를 개발하는 동안 잘 고려되지 않았습니다. 다른 경우에는 기존 시스템이 완전히 다른 위협과 함께 완전히 다른 조건에서 작동하도록 용도가 변경됩니다. 보안 분석가는 종종 그러한 노력을 무시하며 이해할 만합니다. 그러나 상위 수준의 관리는 일반적으로 효율성과 고성능 기능에 더 높은 우선 순위를 부여하면서 시장의 힘에 의해 결정을 내리도록 유도됩니다. 아마도 보안은 기본 시스템을 가동하면 걱정할 수 있는 오버헤드일 것입니다. 또는 시스템이 "에어 갭"이 될 것이라고 생각할 수도 있습니다. 그러나 시스템을 재설계하는 비용으로 인해 보안을 고려하기에는 너무 늦은 시점일 것입니다. 따라서 기본 시스템을 실행한 후 나중에 보안을 추가하여 최선을 다할 것입니다. 많은 경우 나중에 보안을 추가하는 프로세스가 제대로 정의되지 않았거나 알려진 모범 사례가 있는 경우 제대로 따르지 않습니다. 그렇다면 IIoT의 실망스러운 보안 상태에 대해 왜 놀라야 합니까?

보안 엔지니어링의 과제 중 하나는 시스템의 비즈니스 기능 및 성능에 대한 오버헤드를 최소화하면서 오류, 실수 또는 악의로 인한 보안 위협에 대해 수용 가능한 보호를 제공하는 아키텍처를 고안하는 것입니다. 이는 쉬워 보이지만 실제로는 달성하기가 매우 어렵습니다. 특히 시스템이 더욱 복잡해지고 상호 의존적이 되고 더 크고 다양한 그룹의 사람들이 이를 실현하기 위해 노력함에 따라 더욱 그렇습니다. 특히 IIoT 시스템의 경우 보안 위협 및 관련 위험이 매우 빠르게 변화하는 환경에서 상호 운용성, 성능, 확장성, 탄력성, 안전 및 규정 준수의 광범위한 제약 내에서 보안 조치를 고려해야 합니다. 이러한 고려 사항은 DDS 보안 사양 및 RTI의 Connext® DDS Secure 개발에서 활발하게 논의되고 고려되었습니다.

이미 DDS 사용자이거나 DDS를 평가하고 있다면 RTI Connext DDS Secure를 반드시 고려해야 합니다. 다음에서는 Connext DDS Secure가 설계자와 엔지니어가 보안 위험 및 성능 요구 사항을 기반으로 보안과 성능의 올바른 균형을 찾을 수 있도록 하는 보안 구성을 허용하는 방법에 대해 설명합니다. 또한 환자 결과를 크게 개선하기 위해 임상 환경을 안전하게 통합하는 것을 목표로 하는 연구 프로젝트의 예를 제공할 것입니다.

DDS 보안이 귀하의 사용 사례에 적합합니까?

RTI 엔지니어는 일반적으로 경험적 법칙을 사용하여 DDS를 기반으로 고객 시스템을 설계하는 것이 실제로 의미가 있는지 또는 다른 연결 프레임워크를 사용하는 것이 더 나은지 확인합니다(이 주제에 대한 자세한 기술 논의는 IICF 참조). 일반적으로 다음 5개 질문 중 3개 이상에 대한 대답이 "예"인 경우 DDS는 기존의 다른 연결 프레임워크 중에서 시스템에 가장 적합한 프레임워크입니다.

<올>

시스템이 잠시 작동을 멈추면 큰 문제입니까?

지난 2주 동안 "밀리초" 또는 "마이크로초"라고 말한 적이 있습니까?

10명 이상의 소프트웨어 엔지니어가 있습니까?

데이터를 한 곳이 아닌 여러 곳으로 보내고 있습니까(예:클라우드 또는 데이터베이스)?

새로운 IIoT 아키텍처를 구현하고 있습니까?

질문 1에 대한 대답이 예라면 엄격한 가용성 및 내결함성 요구 사항이 있는 것입니다. DDS는 완전한 P2P 운영(따라서 단일 실패 지점이 없음)과 소유권, 내구성, 활성 및 마감 QoS 정책을 포함한 여러 관련 매개변수를 포함하여 이러한 요구 사항에 크게 도움이 되는 기능을 이미 제공합니다. 또한 DDS 보안은 DDS 도메인 분리, DDS 참가자 인증, DDS 주제 발행 또는 구독 권한 부여, 데이터가 미들웨어에서 상위 수준 애플리케이션으로 전달되기 전에 DDS 메시지 인증을 허용합니다. 이러한 기능을 통해 일부 DOS(서비스 거부) 공격의 영향을 방지 및/또는 크게 완화할 수 있습니다. 이러한 기능은 네트워크, OS 및 응용 프로그램 수준에서 적절한 액세스 제어 조치와 함께 DDS 기반 시스템에서 잠재적인 DoS 공격에 대해 더 큰 보호를 제공합니다.

질문 2에 대한 대답이 예라면 상당한 실시간 요구 사항이 있을 가능성이 있습니다. 이러한 경우 위험 및 성능 요구 사항을 기반으로 DDS 시스템의 보안을 미세 조정할 수 있습니다. 예를 들어, 공공 장소에 있는 센서의 온도 판독값이 암호화되어 기밀로 전송되는 것은 신경 쓰지 않을 수 있지만 해당 판독값의 신뢰성에는 관심이 있을 수 있습니다. DDS 보안을 사용하면 애플리케이션 코드를 변경하지 않고도 이러한 구성을 정의하고 시행할 수 있습니다.

질문 3에 대한 긍정적인 대답은 다소 큰 소프트웨어 프로젝트의 서로 다른 측면에서 각각 작업하는 소프트웨어 개발 팀 간의 상호 운용성 비용을 최소화하기를 원한다는 것을 의미합니다. DDS의 데이터 중심 설계를 통해 소프트웨어 팀은 데이터 처리 API를 반드시 노출할 필요 없이 어떤 데이터(즉, 유형 및 주제)를 배포해야 하고 어떻게(즉, QoS 설정을 사용하여) 배포해야 하는지에 대해 동의할 수 있습니다. 마찬가지로 내장 플러그인(예:도메인 거버넌스 및 참가자 권한 파일)에 대한 DDS 보안 구성을 통해 데이터 배포에 대한 보안 정책을 정의할 수 있습니다. 이러한 명시적 정책은 데이터 모델과 DDS 도메인을 보호하려는 방법을 기반으로 생성됩니다. 이러한 정책은 보안 엔지니어와 시스템 설계자가 독립적으로 검토할 수 있으며 애플리케이션 코드를 변경하지 않고도 위험 분석 및 성능 요구 사항에 따라 재조정할 수 있습니다.

질문 4에 대한 긍정적인 대답은 훨씬 더 효율적인 데이터 전달을 위해 멀티캐스트를 최대한 활용하기를 원한다는 것을 의미합니다. 멀티캐스트의 이점을 활용할 수 없는 TLS/DTLS와 같은 대중적인 전송 수준 솔루션과 달리 DDS Security는 멀티캐스트 지원이 내장되어 있어 보다 최적화된 데이터 전달 성능을 제공합니다.

질문 5에 대한 답이 긍정적이면 레거시 코드를 처리해야 하는 것에 대해 너무 걱정하지 않고 보안을 구축할 수 있습니다. 동시에 확장성, 상호 운용성 및 요구 사항 목록에 대한 공급업체 종속성을 피할 수 있습니다. DDS는 IIoT의 핵심 연결 기술 중 하나이며(자세한 내용은 IICF 참조) 공개적으로 사용 가능한 사양 집합을 기반으로 합니다. 또한 DDS Security는 인증, 권한 부여, 암호화, 데이터 태깅 및 로깅을 위한 표준화된 API와 함께 플러그형 아키텍처를 활용합니다. 이러한 기능은 데이터 배포를 위한 명시적이고 세분화된 보안 정책을 지원하는 것과 함께 DDS를 차세대 IIoT 시스템의 강력한 후보로 만들어 시스템 아키텍처에 보안을 추가하는 것이 아니라 설계할 수 있습니다.

이 모든 것이 흥미롭게 들리지만 DDS Security를 ​​사용하는 사람이 있습니까? 대답은 강한 예입니다. RTI Connext DDS Secure는 이미 많은 상업 및 정부 고객이 평가하고 사용하고 있습니다. 이러한 얼리 어답터로부터 받은 피드백을 제품 라인에 반영했습니다. DDS 보안 사양에 대한 추가 설명이나 업데이트가 필요한 경우 표준을 더욱 개선하기 위해 DDS 커뮤니티에 문제를 제기했습니다.

예:안전한 의료 기기 상호 운용성을 위한 DDS 보안

DDS 및 DDS 보안의 이점을 보여주는 흥미로운 예가 통합 임상 환경(ICE)의 맥락에서 나타납니다. ASTM F2761-09 표준에 정의된 ICE 프레임워크는 이기종 의료 기기를 통합하고 해당 활동을 조정하여 임상 워크플로를 자동화하는 접근 방식을 제공합니다. 높은 수준의 관점에서 ICE의 이면에 있는 아이디어는 기본적으로 또는 애프터마켓 어댑터를 사용하여 ICE 표준을 준수하는 의료 기기가 제조업체에 관계없이 다른 ICE 호환 기기와 상호 운용할 수 있도록 하는 것입니다. 올바르게 수행된다면 이 접근 방식은 환자 안전을 극적으로 개선할 수 있다는 약속이 있습니다. 알려진 예로는 수술실(OR)에서 중환자실(ICU)로 환자를 이송하거나 PCA(환자 조절 진통) 시스템에서 잘못된 경보를 줄이는 것이 있습니다. 이 두 가지 예에서 공급업체 간 장치 간 통신은 예방 가능한 의료 오류를 크게 줄입니다. OpenICE는 DDS를 기본 연결 메커니즘으로 사용하는 ICE 플랫폼의 오픈 소스 참조 구현입니다.

OpenICE – MD PnP Lab에서 개발한 다양한 유형의 의료 기기 간의 연결을 가능하게 합니다.

명시적인 보안 조치를 배포하지 않으면 ICE와 같은 의료 IIoT 플랫폼은 환자의 안전과 개인 정보를 위협할 수 있는 보안 공격에 취약합니다. 공격의 예는 공격자가 중간자(man-in-the-middle) 역할을 하는 다음 비디오에서 볼 수 있습니다. 그녀는 실제 산소 농도계 장치의 판독값을 마스킹하고 환자의 잠재적인 위독한 상태를 간호 스테이션에서 숨기려는 악의적인 의도로 잘못된 산소 농도계 판독값을 조작합니다.

전송 수준 보안이 ICE의 연결을 보호하기에 충분합니까?

이 백서의 더 자세한 공격 시나리오에서 설명한 것처럼 모든 통신이 암호화되고 전송 수준 보안(예:TLS/DTLS)으로 인증되지만 손상된 내부 장치는 여전히 시스템 전체에 피해를 줄 수 있습니다. 또는 게시할 수 없음은 세분화된 액세스 제어 없이 시행할 수 없습니다. DDS Security는 장치별로 세분화된 액세스 제어를 허용하여 이러한 중요한 유형의 내부 공격의 영향을 크게 완화합니다.

또한 위험을 기반으로 보안 조치를 미세 조정할 수 있다는 것은 리소스가 제한된 장치 또는 대역폭 또는 지연에 민감한 애플리케이션이 있는 대규모 ICE 또는 의료 IoT 시스템에 특히 중요합니다. 또한 이러한 미세 조정은 코드를 수정할 수 없거나 수정하는 데 비용이 너무 많이 들 수 있으므로 코드 베이스에 대한 변경이 있는 경우 최소한의 변경으로 이상적으로 발생해야 합니다. 위에서 언급했듯이 효율적이고 확장 가능한 검색 및 정보 교환에 매우 유용한 것으로 입증된 멀티캐스트 지원의 부족은 이러한 단점에 추가됩니다.

물론 TLS/DTLS 기반 솔루션을 전혀 사용해서는 안된다는 것은 아닙니다. RTI에는 특정 사용 사례에 더 적합하기 때문에 DDS와 함께 맞춤형 TLS 또는 DTLS 전송을 사용하는 고객이 이미 있습니다. RTI에서는 아키텍처 연구 중에 위험 및 성능 요구 사항을 기반으로 정보에 입각한 결정을 내리는 데 도움을 드릴 수 있습니다.

결론 및 참고 자료

특히 중요한 인프라용 애플리케이션을 개발하는 경우 RTI Connext DDS Secure와 이것이 기반으로 하는 표준인 OMG DDS Security를 ​​고려하는 것이 좋습니다. 다음 참조 자료가 유용할 수 있습니다.

[1] OMG DDS 보안 사양은 여기에서 찾을 수 있습니다.[2] IIRA(산업용 인터넷 참조 아키텍처)의 최신 버전은 여기에서 찾을 수 있습니다.[3] IICF(산업 인터넷 연결 프레임워크)는 여기에서 찾을 수 있습니다.[4] 산업 인터넷 보안 프레임워크(IISF)는 여기에서 찾을 수 있습니다.[5] 통합 임상 환경(ICE) 보호에 대한 정보는 이 문서에서 찾을 수 있습니다.