IoT(사물 인터넷) 보안 아키텍처

시스템을 디자인하고 아키텍처를 설계할 때 해당 시스템에 대한 잠재적 위협을 파악하고, 그에 따라 적절한 방어 수단을 추가해야 합니다. 처음부터 보안을 염두에 두고 제품을 설계하는 것이 매우 중요합니다. 공격자가 시스템을 손상시킬 수 있는 방법을 파악하면 처음부터 적절한 위협 완화 조치를 수행할 수 있기 때문입니다.

보안은 위협 모델에서 출발

Microsoft는 오래전부터 제품에 위협 모델을 사용해 왔으며 회사의 위협 모델링 프로세스를 외부에 공개했습니다. 이 모델링은 가장 걱정스러운 위협을 즉시 파악하는 데서 그치지 않고 예상치 못한 이점까지 제공합니다. 예를 들어 개발 팀 외부 사람들과 공개 토론을 할 수 있는 기회를 제공하며, 공개 토론을 통해 제품에 대한 새로운 아이디어를 얻고 제품을 개선할 수 있습니다.

위협 모델링의 목표는 공격자가 시스템을 손상시킬 수 있는 방법을 파악하여 적절한 위협 완화 조치를 취하는 것입니다. 위협 모델링을 사용하면 설계 팀은 시스템 배포 이후가 아닌 시스템 설계 시에 적절한 위협 완화 조치를 고민해야 합니다. 배포 이후에 현장의 수많은 디바이스에 보안 기능을 추가하기란 실현 불가능하고, 오류가 많고, 고객이 위험에 노출됩니다.

많은 개발 팀이 고객에게 필요한 시스템 기능을 파악하는 일은 잘하고 있습니다. 그러나 누군가가 시스템을 악용할 수 있는 불분명한 방법을 파악하기는 쉽지 않습니다. 개발 팀은 위협 모델링을 통해 공격자가 어떤 이유로 어떤 행동을 하는지 파악할 수 있습니다. 위협 모델링은 시스템의 보안 설계 결정에 대해 토론하고, 그 과정에서 보안에 영향을 주는 설계 요소를 변경하는 체계적인 프로세스입니다. 위협 모델은 간단한 문서에 불과하지만, 지식의 연속성을 유지하고, 배운 내용을 보존하고, 새 팀이 신속하게 업무에 적응하도록 도와줍니다. 마지막으로, 위협 모델링의 결과로 보안의 또 다른 측면을 생각해 볼 수 있습니다. 예를 들어 보안과 관련하여 고객에게 무엇을 약속할 것인지 생각해 볼 수 있습니다. 이러한 약속을 위협 모델링과 함께 사용하여 IoT(사물 인터넷) 솔루션에 대해 조사하고 테스트할 수 있습니다.

위협 모델링 수행 시기

위협 모델링은 디자인 단계에 통합될 때 가장 큰 가치를 제공합니다. 설계할 때 유연하게 설계를 변경하여 위협 요소를 제거할 수 있습니다. 설계상의 위협 요소를 제거하는 것이 원하는 결과입니다. 나중에 보안 기능을 추가하고, 테스트하고, 최신 상태를 유지하는 것보다는 설계 시에 위협 요소를 제거하는 것이 훨씬 간단합니다. 아무 때나 위협 요소를 제거할 수 있는 것이 아닙니다. 제품이 완성될수록 위협 요소를 제거하기가 점점 어려워지며, 결국 개발 초기에 위협 모델링을 수행하는 것보다 훨씬 많은 노력과 훨씬 많은 대가가 필요합니다.

위협 모델링에 대한 고려 사항

솔루션 전체를 살펴보고 다음 영역에 집중해야 합니다.

  • 보안 및 개인 정보 보호 기능
  • 오류 시 보안과 관련이 있는 기능
  • 트러스트 경계를 건드리는 기능

위협 모델링을 수행하는 사람

위협 모델링은 여느 프로세스와 다르지 않습니다. 솔루션의 여느 구성 요소처럼 위협 모델 문서를 다루고 유효성을 검사하는 것이 좋습니다. 많은 개발 팀이 고객에게 필요한 시스템 기능을 파악하는 일은 잘하고 있습니다. 그러나 누군가가 시스템을 악용할 수 있는 불분명한 방법을 파악하기는 쉽지 않습니다. 개발 팀은 위협 모델링을 통해 공격자가 어떤 이유로 어떤 행동을 하는지 파악할 수 있습니다.

위협 모델링을 수행하는 방법

위협 모델링 프로세스는 다음 네 단계로 구성됩니다.

  • 애플리케이션 모델링
  • 위협 요소 열거
  • 위협 완화
  • 완화 조치 유효성 검사

프로세스 단계

위협 모델을 만들 때 다음 세 가지 규칙을 염두에 두어야 합니다.

  1. 참조 아키텍처로 다이어그램을 만듭니다.

  2. 너비 우선으로 시작합니다. 개요를 살펴보고, 시스템 전체를 이해하고, 심층적으로 분석합니다. 이 방법을 통해 올바른 위치에서 심층 분석을 수행할 수 있습니다.

  3. 프로세스를 따라가지 말고, 프로세스를 주도하세요. 모델링 단계에서 문제가 발견되어 살펴보고 싶다면 그렇게 하세요! 이 단계를 반드시 따를 필요가 없습니다.

위협

위협 모델의 네 가지 핵심 요소는 다음과 같습니다.

  • 프로세스(웹 서비스, Win32 서비스, *nix 디먼 등). 이 영역에서 기술적 드릴다운이 불가능한 경우 일부 복잡한 엔터티(예: 필드 게이트웨이 및 센서)를 추상화할 수 있습니다.

  • 데이터 저장소(구성 파일 또는 데이터베이스처럼 데이터가 저장되는 모든 장소)

  • 데이터 흐름(애플리케이션의 요소 사이에서 데이터가 이동하는 위치)

  • 외부 엔터티(시스템과 상호 작용하지만 애플리케이션의 제어를 받지 않는 모든 것. 예: 사용자 및 위성 피드)

아키텍처 다이어그램의 모든 요소는 다양한 위협에 노출되며, 이 문서에서는 STRIDE 니모닉을 사용합니다. STRIDE 요소에 대한 자세한 내용은 Threat Modeling Again, STRIDE를 참조하세요.

애플리케이션 다이어그램의 여러 요소는 특정 STRIDE 위협을 따릅니다.

  • 프로세스는 STRIDE를 따릅니다.
  • 데이터 흐름은 TID를 따릅니다.
  • 데이터 저장소는 TID를 따르며, 경우에 따라 데이터 저장소가 로그 파일인 경우에는 R을 따릅니다.
  • 외부 엔터티는 SRD를 따릅니다.

IoT의 보안

연결된 특수 디바이스는 잠재적 상호 작용 노출 영역 및 상호 작용 패턴이 매우 많으며, 이러한 디바이스에 대한 디지털 액세스를 보호하기 위해 프레임워크를 제공하는 방법을 고려해야 합니다. 여기서 "디지털 액세스"라는 용어는 디바이스 직접 상호 작용을 통해 수행되고 물리적 액세스 제어를 통해 액세스 보안이 제공되는 작업과 구분하기 위해 사용되었습니다. 예를 들어 디바이스를 문에 자물쇠가 달린 방에 비유할 수 있습니다. 소프트웨어 및 하드웨어를 사용하는 물리적 액세스를 거부할 수는 없지만 물리적 액세스가 시스템 간섭으로 이어지지 않도록 조치를 수행할 수 있습니다.

상호 작용 패턴을 살펴보듯이, “디바이스 제어” 및 “디바이스 데이터”도 똑같은 수준에서 살펴보겠습니다. “디바이스 제어”는 모든 당사자가 디바이스 상태 또는 디바이스의 환경 상태를 변경하거나 영향을 줄 목적으로 디바이스에 제공하는 모든 정보로 분류할 수 있습니다. “디바이스 데이터”는 디바이스가 모든 당사자에게 내보내는 상태 및 관찰된 환경 상태에 대한 정보로 분류할 수 있습니다.

보안 모범 사례를 최적화하기 위해 위협 모델링 연습의 일환으로 일반적인 IoT 아키텍처를 여러 구성 요소/영역으로 나누는 것이 좋습니다. 이러한 영역은 이 섹션 전체에 자세히 설명되어 있으며 다음 내용이 포함됩니다.

  • 디바이스
  • 현장 게이트웨이
  • 클라우드 게이트웨이
  • 권한 부여.

영역은 솔루션의 세그먼트를 나누는 대로와 같으며, 영역마다 고유의 데이터 및 인증/권한 부여 요구 사항이 있습니다. 영역은 손상을 격리하고 하는 하위 신뢰 영역이 상위 신뢰 영역에 영향을 미치지 않게 제한하는 데 사용됩니다.

각 영역은 신뢰 경계에 의해 구분되며, 다음 다이어그램에 빨간색 점선으로 표시된 것이 신뢰 경계입니다. 한 소스에서 다른 소스로 데이터/정보가 전환됨을 나타냅니다. 이 전환 과정에서 데이터/정보의 스푸핑, 변조, 거부, 정보 공개, 서비스 거부 및 권한 상승(STRIDE)이 발생할 수 있습니다.

IoT 보안 영역

각 경계 내에 설명된 구성 요소 역시 STRIDE가 적용되며, 솔루션의 360도 위협 모델링이 가능합니다. 다음 섹션에서는 각 구성 요소와 특정 보안 우려 및 필요한 해결 방법에 대해 좀 더 자세히 설명하겠습니다.

다음 섹션에서는 이러한 영역에서 일반적으로 볼 수 있는 표준 구성 요소에 대해 설명합니다.

디바이스 영역

디바이스 환경은 디바이스 주위의 직접적 물리 공간으로, 디바이스에 대한 물리적 액세스 및/또는 “로컬 네트워크” 피어-투-피어 디지털 액세스가 가능합니다. “로컬 네트워크”는 고유하고 공용 인터넷으로부터 분리된(하지만 잠재적으로 공용 인터넷과 연결된) 네트워크로 간주되며, 디바이스의 피어-투-피어 통신을 허용하는 모든 단거리 무선 기술이 포함됩니다. 로컬 네트워크를 흉내 내는 모든 네트워크 가상화 기술은 포함되지 않으며 두 디바이스가 피어 투 피어 통신 관계에 들어가야 하는 경우 공용 네트워크 공간을 통해 통신해야 하는 공용 연산자 네트워크는 포함되지 않습니다.

현장 게이트웨이 영역

현장 게이트웨이는 통신 인에이블러로 작동하고 잠재적으로 디바이스 제어 시스템 및 디바이스 데이터 처리 허브 역할을 하는 디바이스 어플라이언스 또는 범용 서버 컴퓨터 소프트웨어입니다. 현장 게이트웨이 영역에는 현장 게이트웨이 자체와 여기에 연결된 모든 디바이스가 포함됩니다. 이름에서 알 수 있듯이, 전용 데이터 처리 시설 외부에서 수행되는 필드 게이트웨이 작업은 일반적으로 위치에 바인딩되고, 잠재적으로 물리적 침입 가능성이 있고, 운영 중복성이 제한됩니다. 현장 게이트웨이는 누군가가 그 기능을 알고 있지만 만지고 파괴할 수 있는 것이라고 말할 수 있습니다.

현장 게이트웨이는 액세스 및 정보 흐름을 관리하는 활성 역할이 있다는 점에서, 다시 말해서 애플리케이션 주소 지정 엔터티이자 네트워크 연결 또는 세션 터미널이라는 점에서 단순한 트래픽 라우터와 다릅니다. 한편, NAT 디바이스 또는 방화벽은 명시적인 연결 또는 세션 터미널이 아니고 이를 통과하는 연결 또는 세션을 라우팅(또는 차단)하므로 현장 게이트웨이로 간주되지 않습니다. 현장 게이트웨이에는 두 개의 고유한 표면 영역이 있습니다. 하나는 해당 영역에 연결된 디바이스와 면하고 있고 영역 내부를 나타내는 반면, 다른 하나는 모든 외부 당사자와 면하고 있으며 영역 가장자리입니다.

클라우드 게이트웨이 영역

클라우드 게이트웨이는 여러 사이트에서 공용 네트워크 공간을 통해 디바이스 또는 현장 게이트웨이로, 일반적으로 클라우드 기반 제어 및 데이터 분석 시스템 방향으로 원격 통신을 가능하게 하는 혼합 시스템입니다. 경우에 따라 클라우드 게이트웨이가 태블릿 또는 휴대폰 같은 터미널에서 특수 디바이스로의 액세스를 즉시 허용할 수 있습니다. 지금 설명하는 문맥에서 “클라우드”는 연결된 디바이스 또는 현장 게이트웨이와 같은 사이트에 바인딩되지 않은 전용 데이터 처리 시스템을 말합니다. 또한 클라우드 영역에서, 운영 조치는 특정 물리적 액세스를 방지하지만 반드시 “퍼블릭 클라우드” 인프라에 공개되지는 않습니다.

클라우드 게이트웨이는 잠재적으로 네트워크 가상화 오버레이에 매핑되어 클라우드 게이트웨이 및 모든 연결된 디바이스 또는 현장 게이트웨이를 다른 네트워크 트래픽으로부터 분리할 수 있습니다. 클라우드 게이트웨이 자체는 디바이스 제어 시스템도 아니고 디바이스 데이터를 처리하거나 스토리지하는 시설도 아닙니다. 이러한 시설은 클라우드 게이트웨이와 상호 작용합니다. 클라우드 게이트웨이 영역은 모든 현장 게이트웨이 그리고 해당 게이트웨이에 직접적으로 또는 간접적으로 연결된 디바이스와 함께 클라우드 게이트웨이 자체를 포함합니다. 영역의 가장자리는 모든 외부인이 통신하는 고유한 노출 영역입니다.

서비스 영역

현재 문맥에서 “서비스”는 데이터 수집 및 분석과 명령 및 제어를 위해 현장 또는 클라우드 게이트웨이를 통해 디바이스와 상호 작용하는 모든 소프트웨어 구성 요소 또는 모듈로 정의됩니다. 서비스는 중재자입니다. 서비스는 ID 하에서 게이트웨이 및 기타 하위 시스템에 대해 활동하고, 데이터를 저장 및 분석하고, 데이터 정보 또는 일정에 따라 자체적으로 디바이스에 명령을 실행하고, 권한이 부여된 최종 사용자에게 정보와 제어 기능을 공개합니다.

정보 디바이스와 특수 디바이스의 비교

PC, 스마트폰 및 태블릿은 주로 대화형 정보 디바이스입니다. 스마트폰과 태블릿은 배터리 수명을 최대화하기 위해 명시적으로 최적화됩니다. 사람과 즉시 상호 작용하지 않을 때 또는 음악을 재생하거나 소유자를 특정 위치로 안내하는 경우처럼 서비스를 제공하지 않을 때에는 부분적으로 기능이 꺼집니다. 시스템의 관점에서 이러한 정보 기술 디바이스는 주로 사람에 대한 프록시 역할을 합니다. 작업을 제안하는 “사람 작동기”이자 입력을 수집하는 “사람 센서”입니다.

간단한 온도 센서부터 내부에 부품 수천 개가 들어가는 복잡한 공장 생산 라인까지 다양한 특수 디바이스가 있습니다. 이러한 디바이스는 용도가 훨씬 한정적이며, 사용자 인터페이스를 제공하더라도 대부분 물리적 세계의 자산과 상호 작용하도록 범위가 한정되거나 물리적 세계의 자산과 통합됩니다. 환경적 상황을 측정 및 보고하고, 밸브를 조절하고, 서보를 제어하고, 소리로 알림을 전달하고, 조명을 조절하는 등 여러 작업을 수행합니다. 정보 디바이스가 너무 일반적이어서, 너무 비싸서, 너무 커서 또는 너무 약해서 사용할 수 없는 작업에 특수 디바이스가 사용됩니다. 목적이 구체적인 만큼 기술적 디자인과 프로덕션 및 예정된 수명 기간의 가용 예산도 명확합니다. 이러한 두 요소가 결합되어 가용 운영 에너지 예산, 실제 설치 공간, 그에 따라 사용 가능한 스토리지, 컴퓨팅 및 보안 기능이 제한됩니다.

자동화된 또는 원격으로 제어 가능한 디바이스에서 무언가가 “잘못되면”, 예를 들어 물리적 결함 또는 제어 로직에 결함이 있으면 계획적인 무단 침입과 조작으로 이어집니다. 생산 로트가 파괴되고, 건물에서 절도나 화재가 발생하고, 사람이 다치거나 사망에 이를 수 있습니다. 이러한 사고는 누군가가 훔친 신용 카드를 한도까지 사용하는 것과는 피해 규모의 차원이 다릅니다. 전자 상거래 또는 은행 업무 시나리오에서는 물건을 옮기는 디바이스 그리고 최종적으로 물건을 옮기는 명령으로 이어지는 센서 데이터의 보안 기준이 더 높아야 합니다.

디바이스 제어 및 디바이스 데이터 상호 작용

연결된 특수 디바이스는 잠재적 상호 작용 노출 영역 및 상호 작용 패턴이 매우 많으며, 이러한 디바이스에 대한 디지털 액세스를 보호하기 위해 프레임워크를 제공하는 방법을 고려해야 합니다. 여기서 "디지털 액세스"라는 용어는 디바이스 직접 상호 작용을 통해 수행되고 물리적 액세스 제어를 통해 액세스 보안이 제공되는 작업과 구분하기 위해 사용되었습니다. 예를 들어 디바이스를 문에 자물쇠가 달린 방에 비유할 수 있습니다. 소프트웨어 및 하드웨어를 사용하는 물리적 액세스를 거부할 수는 없지만 물리적 액세스가 시스템 간섭으로 이어지지 않도록 조치를 수행할 수 있습니다.

상호 작용 패턴을 살펴보듯이, “디바이스 제어” 및 “디바이스 데이터”도 똑같은 수준에서 살펴보면서 위협 모델링을 수행하겠습니다. “디바이스 제어”는 모든 당사자가 디바이스 상태 또는 디바이스의 환경 상태를 변경하거나 영향을 줄 목적으로 디바이스에 제공하는 모든 정보로 분류할 수 있습니다. “디바이스 데이터”는 디바이스가 모든 당사자에게 내보내는 상태 및 관찰된 환경 상태에 대한 정보로 분류할 수 있습니다.

Azure IoT 참조 아키텍처에 대한 위협 모델링 수행

Microsoft는 이전에 설명한 프레임워크를 사용하여 Azure IoT에 대한 위협 모델링을 수행합니다. 다음 섹션에서는 Azure IoT 참조 아키텍처의 구체적인 예를 통해 IoT에 대한 위협 모델링을 수행하고 확인된 위협을 해결하는 방법을 보여 드리겠습니다. 이 예제에서는 네 가지 주요 영역을 식별합니다.

  • 디바이스 및 데이터 원본
  • 데이터 전송
  • 디바이스 및 이벤트 처리
  • 프레젠테이션

Azure IoT 위협 모델링

다음 다이어그램은 Microsoft Threat Modeling Tool에서 사용되는 데이터 흐름 다이어그램 모델을 사용하여 Microsoft의 IoT 아키텍처를 개략적으로 보여 줍니다.

MS Threat Modeling Tool을 사용하여 Azure IoT 위협 모델링

아키텍처가 디바이스와 게이트웨이 기능을 분리하고 있는 것을 잘 보세요. 이 방법을 통해 사용자가 보다 안전한 게이트웨이 디바이스를 활용할 수 있습니다. 사용자가 보안 프로토콜을 사용하여 클라우드 게이트웨이와 통신할 수 있습니다. 이러한 통신에는 일반적으로 높은 처리 오버헤드가 필요하며 자동 온도 조절기 같은 네이티브 디바이스가 자체적으로 제공할 수 있습니다. Azure 서비스 영역에서는 Azure IoT Hub 서비스가 클라우드 게이트웨이를 나타나는 것으로 가정합니다.

디바이스 및 데이터 원본/데이터 전송

이 섹션에서는 이전에 설명한 아키텍처를 위협 모델링이라는 렌즈를 통해 살펴보고, 내재된 문제 중 일부를 어떻게 해결할 수 있는지 개략적으로 설명하겠습니다. 이 예제에서는 위협 모델의 핵심 요소를 중점적으로 살펴보겠습니다.

  • 프로세스(내부에서 제어 가능한 프로세스 및 외부 항목 모두)
  • 통신(데이터 흐름이라고도 함)
  • 스토리지(데이터 스토리지라고도 함)

프로세스

Azure IoT 아키텍처에서 설명한 각 범주에서, 이 예제는 데이터/정보가 존재하는 프로세스, 통신 및 스토리지 단계에서 다양한 위협을 완화하려고 시도합니다. 다음에서는 “프로세스” 범주의 가장 일반적인 위협을 개략적으로 설명한 다음 이러한 위협을 가장 적절하게 완화하는 방법에 대한 개요를 설명합니다.

스푸핑(S): 공격자가 소프트웨어 또는 하드웨어 수준에서 디바이스의 암호화 키 자료를 추출한 다음 이 키 자료를 빼낸 디바이스의 ID를 사용하여 다른 물리적 또는 가상 디바이스에서 시스템에 액세스할 수 있습니다. 모든 TV를 켜고 끌 수 있어서 사람들이 장난을 치기 위한 도구로 많이 구입하는 원격 리모콘이 대표적인 예입니다.

서비스 거부(D): 무선 주파수를 방해하거나 와이어를 절단하여 디바이스의 정상 작동 또는 통신을 불가능하게 만들 수 있습니다. 예를 들어 감시 카메라의 자체 전원 또는 네트워크 연결을 고의적으로 끊으면 감시 카메라가 데이터를 전혀 보고하지 않습니다.

변조(T): 공격자가 디바이스에서 실행되는 소프트웨어의 일부 또는 전체를 대체할 수 있으며 키 자료 또는 키 자료가 들어 있는 암호화 기능을 불법 프로그램이 사용할 수 있는 경우에는 대체된 소프트웨어가 해당 디바이스의 실제 ID를 활용할 수 있게 됩니다. 예를 들어 공격자가 추출한 키 자료를 활용하여 통신 경로의 디바이스에서 데이터를 가로채고 데이터를 표시하지 않게 한 후 훔친 키 자료를 사용하여 인증된 잘못된 데이터로 바꿔 놓을 수 있습니다.

정보 공개(I): 디바이스가 조작된 소프트웨어에서 실행되는 경우 조작된 소프트웨어가 권한 없는 사람에게 데이터를 유출할 수 있습니다. 예를 들어 공격자가 추출한 키 자료를 활용하여 디바이스와 컨트롤러 사이 또는 현장 게이트웨이와 클라우드 게이트웨이 사이의 통신 경로에 키 자료 자체를 삽입하여 정보를 빼돌릴 수 있습니다.

권한 상승(E): 특정 기능을 수행하는 디바이스가 강제로 다른 기능을 수행할 수 있습니다. 예를 들어 절반만 열리도록 프로그래밍된 밸브가 끝까지 열리도록 속일 수 있습니다.

구성 요소 위협 마이그레이션 위험 구현
디바이스 S 디바이스에 ID를 할당하고 디바이스 인증 디바이스 또는 디바이스 일부를 다른 디바이스로 대체합니다. 올바른 디바이스와 통신하고 있는지 어떻게 알 수 있을까요? TLS(전송 계층 보안) 또는 IPSec을 사용하여 디바이스를 인증합니다. 전체 비대칭 암호화를 처리할 수 없는 PSK(미리 공유한 키)를 해당 디바이스에서 사용할 수 있도록 인프라가 지원해야 합니다. Azure AD, OAuth를 활용하세요.
TRID 디바이스에 변조 방지 메커니즘을 적용합니다. 예를 들어 디바이스에서 키와 기타 암호화된 자료를 추출하는 것이 어렵거나 불가능하게 만듭니다. 누군가가 디바이스를 변조(물리적 간섭)할 위험은 남아 있습니다. 디바이스가 변조되지 않았는지 확인하려면 어떻게 해야 할까요? 가장 효과적인 해결 방법은 TPM(신뢰할 수 있는 플랫폼 모듈) 기능입니다. 이 기능을 사용하면 특별한 온칩 회로에 키를 저장할 수 있습니다. 이 온칩 회로에 저장된 키는 읽기는 불가능하고 해당 키를 사용하는 암호화 작업에만 키 공개 없이 사용할 수 있습니다. 디바이스의 메모리 암호화. 디바이스의 키 관리. 코드에 서명.
E 디바이스의 액세스 제어. 권한 부여 체계. 디바이스가 외부 원본 또는 심지어 손상된 센서의 명령에 따라 개별 작업을 수행할 수 있도록 허용하면 공격이 작업을 수행할 수 있습니다. 만약 허용하지 않으면 공격이 작업에 액세스할 수 없습니다. 디바이스에 권한 부여 체계 사용
현장 게이트웨이 S 클라우드 게이트웨이(인증서 기반, PSK, 클레임 기반 등)에 대해 필드 게이트웨이를 인증합니다. 누군가가 현장 게이트웨이를 스푸핑할 수 있다면 현장 게이트웨이가 모든 디바이스로 제공될 수 있습니다. TLS RSA/PSK, IPSec, RFC 4279. 디바이스의 모든 일반적인 키 스토리지 및 증명 문제를 해결하는 가장 좋은 방법은 TPM 사용입니다. WSN(무선 센서 네트워크)을 지원하기 위한 IPSec용 6LowPAN 확장 기능입니다.
TRID 변조로부터 현장 게이트웨이 보호(TPM?) 클라우드 게이트웨이가 현장 게이트웨이와 통신 중이라고 믿게 만드는 스푸핑 공격은 정보 공개 및 데이터 변조로 이어질 수 있습니다. 메모리 암호화, TPM 사용, 인증.
E 현장 게이트웨이에 대한 액세스 제어 메커니즘

다음은 이 범주의 위협에 대한 몇 가지 예입니다.

스푸핑: 공격자가 소프트웨어 또는 하드웨어 수준에서 디바이스의 암호화 키 자료를 추출한 다음, 이 키 자료를 빼낸 디바이스의 ID를 사용하여 다른 물리적 또는 가상 디바이스에서 시스템에 액세스할 수 있습니다.

서비스 거부: 무선 주파수를 방해하거나 와이어를 절단하여 디바이스의 정상 작동 또는 통신을 불가능하게 만들 수 있습니다. 예를 들어 감시 카메라의 자체 전원 또는 네트워크 연결을 고의적으로 끊으면 감시 카메라가 데이터를 전혀 보고하지 않습니다.

변조: 공격자가 디바이스에서 실행되는 소프트웨어의 일부 또는 전체를 대체할 수 있으며, 키 자료 또는 키 자료가 들어 있는 암호화 기능을 불법 프로그램이 사용할 수 있는 경우에는 대체된 소프트웨어가 해당 디바이스의 실제 ID를 활용할 수 있게 됩니다.

변조: 빈 복도의 가시 스펙트럼 그림을 보여 주는 감시 카메라가 이러한 복도의 사진을 비추도록 변조될 수 있습니다. 연기 또는 화재 센서가 누군가가 그 아래에서 라이터를 대고 있다고 보고할 수 있습니다. 어느 경우든 디바이스가 기술적으로 시스템을 완전히 신뢰하겠지만 조작된 정보를 보고합니다.

변조: 공격자가 추출한 키 자료를 활용하여 통신 경로의 디바이스에서 데이터를 가로채고 데이터를 표시하지 않게 한 후 훔친 키 자료를 사용하여 인증된 데이터를 잘못된 데이터로 바꿔 놓을 수 있습니다.

변조: 공격자가 디바이스에서 실행되는 소프트웨어의 일부 또는 전체를 대체할 수 있으며 키 자료 또는 키 자료가 들어 있는 암호화 기능을 불법 프로그램이 사용할 수 있는 경우에는 대체된 소프트웨어가 해당 디바이스의 실제 ID를 활용할 수 있게 됩니다.

정보 공개: 디바이스가 조작된 소프트웨어에서 실행되는 경우 조작된 소프트웨어가 권한 없는 사람에게 데이터를 유출할 수 있습니다.

정보 공개: 공격자가 추출한 키 자료를 활용하여 디바이스와 컨트롤러 사이 또는 현장 게이트웨이와 클라우드 게이트웨이 사이의 통신 경로에 키 자료 자체를 삽입하여 정보를 빼낼 수 있습니다.

서비스 거부: 디바이스가 꺼지거나 통신이 불가능한 모드로 전환될 수 있습니다(많은 산업용 시스템에서 의도적으로 발생).

변조: 디바이스가 제어 시스템에 알려지지 않은 상태(알려진 보정 매개 변수를 벗어나는 상태)에서 작동하여 잘못 해석될 수 있는 데이터를 제공하도록 다시 구성될 수 있습니다.

권한 상승: 특정 기능을 수행하는 디바이스가 강제로 다른 기능을 수행할 수 있습니다. 예를 들어 절반만 열리도록 프로그래밍된 밸브가 끝까지 열리도록 속일 수 있습니다.

서비스 거부: 통신이 불가능한 상태로 디바이스가 전환될 수 있습니다.

변조: 디바이스가 제어 시스템에 알려지지 않은 상태(알려진 보정 매개 변수를 벗어나는 상태)에서 작동하여 잘못 해석될 수 있는 데이터를 제공하도록 다시 구성될 수 있습니다.

스푸핑/변조/부인: 보안이 설정되지 않으면(소비자 원격 제어가 가능한 경우는 거의 없음) 공격자가 디바이스 상태를 익명으로 조작할 수 있습니다. 모든 TV를 켜고 끌 수 있어서 사람들이 장난을 치기 위한 도구로 많이 구입하는 원격 리모콘이 대표적인 예입니다.

통신

디바이스 간, 디바이스와 필드 게이트웨이 간, 디바이스와 클라우드 게이트웨이 간의 통신 경로와 관련된 위협이 있습니다. 다음 표에는 디바이스/VPN의 개방형 소켓에 대한 몇 가지 지침이 나와 있습니다.

구성 요소 위협 마이그레이션 위험 구현
디바이스 IoT Hub TID 트래픽을 암호화하는 (D)TLS(PSK/RSA) 디바이스와 게이트웨이 간의 통신을 도청 또는 방해 프로토콜 수준에서 보안 설정 사용자 지정 프로토콜을 사용하는 경우 프로토콜을 보호하는 방법을 파악해야 합니다. 대부분의 경우 디바이스에서 IoT Hub로 통신이 발생합니다(디바이스에서 연결을 시작).
디바이스 간 TID 트래픽을 암호화하는 (D)TLS(PSK/RSA). 디바이스 간에 전송 중인 데이터 읽기. 데이터 변조. 새 연결로 디바이스를 오버로드 프로토콜 수준에서 보안 설정(MQTT/AMQP/HTTP/CoAP). 사용자 지정 프로토콜을 사용하는 경우 프로토콜을 보호하는 방법을 파악해야 합니다. DoS 위협의 해결 방법은 클라우드 또는 현장 게이트웨이를 통해 디바이스를 피어링하고 네트워크에 대해 클라이언트로만 작동하게 하는 것입니다. 피어링은 게이트웨이를 통해 조정된 후 피어 간의 직접 연결로 이어질 수 있습니다.
외부 엔터티 디바이스 TID 외부 엔터티를 디바이스에 강력하게 페어링 디바이스에 대한 연결 도청. 디바이스와의 통신 방해 외부 엔터티를 디바이스 NFC/Bluetooth LE에 안전하게 페어링. 디바이스(물리적)의 작업 패널 제어
현장 게이트웨이 클라우드 게이트웨이 TID 트래픽을 암호화하는 TLS(PSK/RSA). 디바이스와 게이트웨이 간의 통신을 도청 또는 방해 프로토콜 수준에서 보안 설정(MQTT/AMQP/HTTP/CoAP). 사용자 지정 프로토콜을 사용하는 경우 프로토콜을 보호하는 방법을 파악해야 합니다.
디바이스 클라우드 게이트웨이 TID 트래픽을 암호화하는 TLS(PSK/RSA). 디바이스와 게이트웨이 간의 통신을 도청 또는 방해 프로토콜 수준에서 보안 설정(MQTT/AMQP/HTTP/CoAP). 사용자 지정 프로토콜을 사용하는 경우 프로토콜을 보호하는 방법을 파악해야 합니다.

다음은 이 범주의 위협에 대한 몇 가지 예입니다.

서비스 거부: 제한된 디바이스는 네트워크의 인바운드 연결 또는 원치 않는 데이터그램을 능동적으로 수신할 때 일반적으로 DoS 위협에 노출되는데 공격자가 동시에 여러 연결을 열고 서비스를 제공하지 않거나 느리게 서비스를 제공할 수도 있으며 또는 디바이스가 원치 않는 트래픽으로 넘쳐날 수 있기 때문입니다. 두 경우 모두 디바이스가 네트워크에서 작동할 수 없게 만드는 효과적인 방법입니다.

스푸핑, 정보 공개: 제한된 디바이스와 특수 디바이스는 암호 또는 PIN 보호 같은 한 가지 보안 수단을 모든 곳에 적용하거나 신뢰할 수 있는 네트워크에 전적으로 의존하는 경우가 자주 있습니다. 다시 말해서 디바이스가 동일한 네트워크에 있으면 정보에 대한 액세스 권한을 부여하며, 해당 네트워크는 공유 키로만 보호되는 경우가 자주 있습니다. 즉, 디바이스 또는 네트워크의 공유 암호가 공개되면 디바이스를 제어하거나 디바이스에서 내보낸 데이터를 관찰할 수 있습니다.

스푸핑: 공격자가 브로드캐스트를 가로채거나 부분적으로 재정의하여 송신자(중간자)를 스푸핑할 수 있습니다.

변조: 공격자가 브로드캐스트를 가로채거나 부분적으로 재정의하여 잘못된 정보를 보낼 수 있습니다.

정보 공개: 공격자가 브로드캐스트를 도청하여 인증 없이 정보를 획득할 수 있습니다. 서비스 거부: 공격자가 브로드캐스트 신호 폭주를 유발하고 정보 배포를 거부할 수 있습니다.

스토리지

모든 디바이스 및 현장 게이트웨이는 일종의 스토리지(데이터를 큐에 대기시키는 임시 스토리지, OS(운영 체제) 이미지 스토리지)를 가지고 있습니다.

구성 요소 위협 마이그레이션 위험 구현
디바이스 스토리지 TRID 스토리지 암호화, 로그 서명 스토리지의 데이터(PII 데이터)를 읽고 원격 분석 데이터 변조. 큐에 대기 중이거나 캐시된 명령 제어 데이터 변조. 로컬 큐에 대기 중이거나 캐시 중에 구성 또는 펌웨어 업데이트 패키지가 변조되면 OS 및/또는 시스템 구성 요소의 손상으로 이어질 수 있음 암호화, MAC(메시지 인증 코드) 또는 디지털 서명. 가능하다면 리소스 ACL(액세스 제어 목록) 사용 권한을 통해 강력한 액세스 제어.
디바이스 OS 이미지 TRID OS 변조/OS 구성 요소 교체 읽기 전용 OS 파티션, 서명한 OS 이미지, 암호화
현장 게이트웨이 스토리지(데이터를 큐에 대기) TRID 스토리지 암호화, 로그 서명 스토리지의 데이터(PII 데이터)를 읽고, 원격 분석 데이터를 변조하고, 큐에 대기 중이거나 캐시된 명령 제어 데이터 변조. 로컬 큐에 대기 중이거나 캐시 중에 구성 또는 펌웨어 업데이트 패키지(디바이스 또는 현장 게이트웨이에 사용될)변조되면 OS 및/또는 시스템 구성 요소의 손상으로 이어질 수 있음 BitLocker
현장 게이트웨이 OS 이미지 TRID OS 변조/OS 구성 요소 교체 읽기 전용 OS 파티션, 서명한 OS 이미지, 암호화

디바이스 및 이벤트 처리/클라우드 게이트웨이 영역

클라우드 게이트웨이는 여러 사이트에서 공용 네트워크 공간을 통해 디바이스 또는 현장 게이트웨이로, 일반적으로 클라우드 기반 제어 및 데이터 분석 시스템 방향으로 원격 통신을 가능하게 하는 혼합 시스템입니다. 경우에 따라 클라우드 게이트웨이가 태블릿 또는 휴대폰 같은 터미널에서 특수 디바이스로의 액세스를 즉시 허용할 수 있습니다. 지금 설명하는 문맥에서 “클라우드”는 연결된 디바이스 또는 현장 게이트웨이와 같은 사이트에 바인딩되지 않은 전용 데이터 처리 시스템을 말하며, 운영 조치는 특정 물리적 액세스를 방지하지만 반드시 “퍼블릭 클라우드” 인프라에 노출되지는 않습니다. 클라우드 게이트웨이는 잠재적으로 네트워크 가상화 오버레이에 매핑되어 클라우드 게이트웨이 및 모든 연결된 디바이스 또는 현장 게이트웨이를 다른 네트워크 트래픽으로부터 분리할 수 있습니다. 클라우드 게이트웨이 자체는 디바이스 제어 시스템도 아니고 디바이스 데이터를 처리하거나 스토리지하는 시설도 아닙니다. 이러한 시설은 클라우드 게이트웨이와 상호 작용합니다. 클라우드 게이트웨이 영역은 모든 현장 게이트웨이 그리고 해당 게이트웨이에 직접적으로 또는 간접적으로 연결된 디바이스와 함께 클라우드 게이트웨이 자체를 포함합니다.

클라우드 게이트웨이는 대부분 서비스로 실행되는 맞춤 제작 소프트웨어이며 노출된 엔드포인트에 현장 게이트웨이 및 디바이스가 연결됩니다. 따라서 보안을 염두에 두고 설계해야 합니다. 이 서비스를 설계하고 구축하려면 SDL 프로세스를 따릅니다.

서비스 영역

제어 시스템(또는 컨트롤러)는 하나 또는 여러 디바이스를 제어하고, 프레젠테이션에 사용할 데이터를 수집/저장/분석하고, 이후에 제어에 사용할 목적으로 디바이스, 현장 게이트웨이 또는 클라우드 게이트웨이와 상호 작용하는 소프트웨어 솔루션입니다. 제어 시스템은 이 토론 범위에 포함되는 유일한 엔터티로 사용자와 즉시 상호 작용할 수 있습니다. 사용자가 디바이스를 끄거나 다른 속성을 변경할 수 있는 스위치처럼 디바이스의 중간 물리적 제어 표면은 예외이며, 디지털 방식으로 액세스할 수 있는 기능적으로 대체 가능한 제품이 없습니다.

중간 물리적 제어 표면은 동일한 기능을 원격으로 실행하거나 원격 입력과의 입력 충돌을 피할 수 있도록 제어 논리가 물리적 제어 영역의 기능을 제한하는 곳입니다. 이러한 중간 제어 표면은 개념적으로는 해당 디바이스가 병렬로 연결될 수 있는 다른 원격 제어 시스템과 동일한 기본 기능을 활용하는 로컬 제어 시스템에 연결됩니다. 클라우드 컴퓨팅에 대한 상위 위협은 CSA(Cloud Security Alliance) 페이지에서 확인할 수 있습니다.

추가 리소스

자세한 내용은 다음 항목을 참조하세요.

참고 항목

IoT 솔루션 가속기가 만든 솔루션의 보안을 설명하는 방법에 대한 자세한 내용은 IoT 배포 보안을 참조하세요.

IoT Hub 개발자 가이드의 IoT Hub에 대한 액세스 제어에서 IoT Hub 보안에 대해 자세히 알아보세요.