대규모 IoT 프로비저닝 촉진

새로운 장치를 설계하거나 기존 장치를 IoT용으로 개조하려는 경우 IoT 장치를 클라우드 서비스에 온라인으로 가져오는 IoT 프로비저닝을 고려해야 합니다. IoT 프로비저닝 설계에서는 장치가 클라우드에 안전하게 연결할 수 있도록 디지털 ID, 클라우드 엔드포인트 및 네트워크 자격 증명을 구성하는 네트워크 커미셔닝 및 자격 증명 프로비저닝 메커니즘 모두에 대한 사용자 경험과 보안에 영향을 미치는 결정을 내려야 합니다.

대규모 IoT 프로비저닝을 수행하기 위해 고객은 여러 문제 도메인에 걸쳐 있는 장치에서 지원하는 프로토콜을 통해 필요한 자격 증명을 푸시할 수 있는 맞춤형 도구 및 소프트웨어 애플리케이션을 구축하고 유지 관리하는 경우가 많습니다. IoT 프로비저닝 도메인에는 다음이 포함됩니다.

• 고객이 상황별 매개변수를 정의할 수 있는 메커니즘을 제공하는 네트워크 시운전
• 실제 장치에 자격 증명 및 구성을 할당하는 자격 증명 프로비저닝 그리고
• 인증, 권한 부여 및 기기 관리를 가능하게 하는 클라우드 측 구성 데이터를 설정하는 클라우드 프로비저닝

이 세 가지 프로비저닝 도메인은 모두 멋진 고객 사용자 경험을 위해 조화롭게 작동해야 합니다.

예를 들어, 모바일 운영자는 휴대폰 사용자가 처음 연결할 때 구성 데이터 및 정책 설정을 프로비저닝합니다. 이것은 SIM 카드가 장치 ID를 나타내는 모바일 장치 사용자에게 많은 시간이 걸리지 않는 간단하고 잘 알려진 프로세스입니다. 수백만 개의 IoT 장치를 프로비저닝하려는 고객, 특히 OEM(Original Equipment Manufacturer)에게는 상황이 매우 다르고 어려워집니다.

이 기사를 통해 자체 IoT 배포와 관련된 위험을 피하거나 완화하는 방법을 배우고 Amazon Web Services(AWS)와 같은 클라우드 플랫폼을 통해 제공되는 IoT 서비스가 어떻게 이러한 목표를 달성하는 데 도움이 되는지 간단한 예를 통해 이해할 수 있습니다. IoT 프로비저닝 목표.

필요한 경우 네트워크 커미셔닝에 대한 접근 방식

결국 IoT 장치는 IoT 솔루션의 허브인 중앙 서비스에 연결하고 통신합니다. 해당 허브에 도달하려면 IoT 장치가 네트워크 매체에 연결되어야 합니다. 매체는 이더넷과 같은 유선 또는 Wi-Fi와 같은 무선 전송이 될 수 있습니다. 매체에 따라 허브에 도달하는 데 성공하기 위해 결합해야 하는 매체를 장치에 알려줄 사람이 필요합니다. 예를 들어 셀룰러를 사용하면 SIM 카드에 의해 정의되었기 때문에 네트워크에 연결하도록 장치에 알릴 필요가 없습니다. 반면에 Wi-Fi 네트워크에 연결하려면 Wi-Fi 액세스 포인트 이름과 암호를 알아야 하고 이러한 세부 정보를 장치에 알릴 수 있어야 합니다. 네트워크에 연결하기 위해 구성이 필요한 장치에 중점을 둘 것입니다.

고객이 IoT 네트워크에 가입하는 데 사용해온 여러 가지 메커니즘이 있습니다. 오늘날 대부분의 모든 사람이 스마트폰을 가지고 있고 대부분의 모든 스마트폰에 Bluetooth가 있으므로 Bluetooth를 통한 구성이 보편화되었습니다. 그러나 그것이 연결되는 유일한 수단은 아닙니다. IoT 장치의 일부 Wi-Fi 모듈은 사용자가 더 큰 네트워크 구성을 입력할 수 있는 간단한 웹 페이지를 개발할 수 있는 액세스 포인트가 될 만큼 충분히 스마트합니다. 비 소비자 장치의 경우 직렬 또는 microSD를 통해 구성하는 것이 여전히 일반적입니다. 스마트폰 애플리케이션의 도움으로 Bluetooth 구성이 표준이 되었습니다. 이러한 스마트폰 앱은 이 문서의 뒷부분에서 알게 될 장치 클라우드 프로비저닝에 도움을 줄 수도 있습니다.

대규모 기기 자격 증명 프로비저닝에 대한 접근 방식

장치 자격 증명 프로비저닝 프로세스는 업계 전반에 걸쳐 계속해서 고도로 파편화되어 있으며 조만간 통합될 전망이 없습니다. 대부분의 IoT 중앙 집중식 시스템은 암호화된 전송을 위한 TLS(전송 계층 보안) 1.2 연결을 강력하게 제안하거나 요구합니다. 이 연결은 전송 중 암호화로 알려진 보다 최근이고 아마도 유창하게 알려졌습니다. 오늘날 대부분의 IoT 배포는 PKI(공개 키 인프라)를 사용하므로 이 문서의 나머지 부분에서는 PKI를 사용한다고 가정합니다. 어떤 경우든 각 장치는 고유한 식별 개인 키와 인증서를 소유해야 합니다.

클라우드(또는 서비스 엔드포인트)로 세션을 생성하려면 TLS 1.2에 개인 키와 x.509 인증서(또는 자격 증명)가 필요합니다. 참고:Java 웹 토큰 또는 JWT와 같은 일부 기술에는 유사한 문제가 있지만 여기에서는 논의되지 않습니다. DNA와 같은 개인 키는 개별 장치에만 알려야 하므로 다른 장치와 공유해서는 안 됩니다. 운전 면허증과 같은 x.509 인증서는 CSR(Certificate Signing Request)을 제공하여 확인 가능한 인증 기관(CA)에서 발급합니다. CSR을 제공하는 것은 여권을 받기 위한 증거로 지문이 포함된 출생 증명서와 기타 통과한 테스트의 증거를 국가의 여권 발급 기관에 전달하는 것과 크게 다르지 않습니다. 이 문서 전체에서 x.509 인증서를 자격 증명이라고 하며 기기에 고유한 개인 키가 있다는 가정 하에

TLS 1.2에 대한 자세한 내용은 이 기사의 범위를 벗어납니다. 그러나 장치가 개인 키를 보호해야 하는 이유를 이해할 수 있도록 약간의 정보를 제공하기에 충분한 정보만 제공합니다. TLS 1.2 연결 프로세스 동안 일련의 교환이 발생하여 장치가 해당 ID인 개인 키의 소유자임을 증명합니다. 장치는 인증에 사용하려는 x.509 인증서의 실제 소유자임을 증명해야 합니다. 장치가 연결될 때 IoT 서비스가 장치 자격 증명을 신뢰하려면 해당 개인 키가 있어야 합니다. 이제 악의적인 사용자가 해당 키를 손에 넣으면 보안 모델이 무너진다는 것을 알 수 있습니다. 어떤 대가를 치르더라도 IoT 성의 키를 보호하세요!

IoT를 배포하는 대부분의 사람들과 마찬가지로 이러한 자격 증명을 대규모로 프로비저닝하는 방법을 결정해야 합니다. 간략하게 검토하려면 각 기기에 다음이 있어야 합니다.

• 기기를 나타내는 고유하고 변경할 수 없는 개인 키입니다. 이상적으로는 병렬 및 기타 지능형 공격으로부터 보호하기 위해 개인 키는 물리적으로 보호되어야 하며 기본 프로그램 메모리에 로드할 수 없어야 합니다.
• 애플리케이션 또는 IoT 서비스와 관련된 자격증명

개인 키 및 자격 증명 프로비저닝에 대한 선택에 따라 물류가 다르며, 일부는 클라우드 프로비저닝과 분리되어 있고 다른 일부는 클라우드 프로비저닝에 의존합니다.

• 집적 회로 보안 모듈(일반적으로 암호화 기능이 있음)은 독립형이거나 SiP(System-In-Package), SoM(System-On-Module) 또는 SoC(System-On-Chip) 설계에 참여합니다. 다음 행동 중 하나가 있는 경우:

• • 수동으로 프로비저닝되거나 자체 생성되는 개인 키 또는 신뢰 루트가 있는 보안 모듈입니다.
  • 이전 항목 외에도 보안 모듈은 사전 프로비저닝된 x.509 인증서 형식의 자격 증명을 제공합니다.

• 가입자 식별 모듈(SIM), 내장 SIM(eSIM) 및 통합 SIM(iSIM) 기술은 설계자가 셀룰러 네트워크와 통신하기 위한 셀룰러 ID로 사용하는 하드웨어를 제공합니다. 자격 증명 프로비저닝은 일반적으로 MNO(모바일 네트워크 사업자) 공급자, MVNO(모바일 가상 네트워크 공급자) 또는 타사에 따라 다릅니다. 통신을 위해 셀룰러 모듈을 사용하는 경우 이것이 귀하의 선택입니다.
• 제조 중 하드웨어 보안 모듈(HSM)과 함께 특수 보안 플래시가 있을 수 있는 장치 플래시 세그먼트에 대한 맞춤형 자동화 장치 자격 증명
• 특수 보안 플래시(또는 비보안 플래시, 일반적으로 프로토타이핑 중이지만 플릿 프로비저닝에는 권장되지 않음)에 대한 개인 키 및 자격 증명을 수동으로 프로비저닝합니다.

TLS 1.2 실행은 암호화 요구 사항으로 인해 컴퓨팅 집약적인 활동이며, 이는 특히 설계에 마이크로컨트롤러를 사용하는 경우 컴퓨팅 구성 요소 선택에 영향을 줍니다. 특수 IC에는 일반적으로 개인 키가 주 메모리에 로드되지 않도록 하는 동시에 호스트 프로세서가 TLS 1.2 작업에 주기를 적용하지 않도록 하는 암호화 루틴이 포함됩니다.

하드웨어에 대한 접근 방식은 하드웨어 설계에 따라 다릅니다. 하드웨어 설계를 위한 우아한 솔루션을 선택하면 대규모 프로비저닝이 확실히 간소화되지만 컴퓨팅, 암호화 모듈, 수학 공동 처리 및 플래시에 대한 다른 구성 요소 설계 선택에 영향을 미치기 때문에 하드웨어 설계 수명 주기 초기에 구성 요소를 선택해야 합니다. 확실히 대규모 장치의 경우 수동으로 프로비저닝하고 싶지 않을 것이며 사전 프로비저닝된 장치는 제조, 운영 및 고객 경험 관점에서 가장 적은 마찰을 생성하는 경향이 있습니다.

IoT 기기 프로비저닝에는 클라우드 및 기기 오케스트레이션이 필요합니다.

IoT 장치 프로비저닝을 성공적으로 수행하려면 하드웨어 및 소프트웨어 설계와 장치 수명 주기 전반에 걸쳐 장치를 관리하는 방법에 영향을 미치는 클라우드 및 장치 프로비저닝 오케스트레이션이 필요합니다.

IoT 서비스 관점에서 관련 구성 개체를 생성하려면 자격 증명 프로비저닝 선택과 일치하는 프로세스가 필요합니다. 장치가 IoT 서비스에 연결되면 IoT 서비스는 장치를 인식(인증)하고 특정 장치 동작을 활성화(권한 부여)하며 특정 컨텍스트에서 장치를 작동 및 관리(장치 관리)할 수 있어야 합니다.

인증을 위해 IoT 서비스에는 자격 증명의 지문이 있어야 하므로 장치가 자격 증명을 IoT 서비스에 연결하고 보낼 때 IoT 서비스가 구성 개체와 물리적 연결을 연결할 수 있습니다. AWS IoT의 경우 IoT 서비스가 수신 연결을 인식할 수 있도록 하는 자격 증명을 등록합니다. 장치가 개인 키에 액세스할 수 있어야 하는 TLS 핸드셰이크(IoT 서비스는 그렇지 않음)는 자격 증명이 개인 키와 함께 장치에서 전송되었음을 보장합니다. 그렇기 때문에 기기의 개인 키를 보호하는 것이 매우 중요합니다.

권한 부여를 위해 IoT 서비스는 최소 IoT 서비스 액세스 권한을 부여하는 연결에 규칙을 적용해야 합니다. 최소 IoT 서비스 액세스는 장치가 운영 의무를 수행하는 데 필요한 리소스만 사용하도록 제한하는 것을 의미합니다. 예를 들어 AWS 고객은 자격 증명의 구성 객체와 관련된 IoT 정책을 생성합니다.

장치 관리의 경우 구성 개체에 메타데이터를 적용하여 장치 또는 집합의 그룹 또는 집계를 명확하게 지정하려고 할 것입니다. IoT를 사용하면 수천, 수만, 수백만 개의 장치를 관리해야 합니다. 각 장치를 개별적으로 관리하는 것은 비현실적입니다. 개조 또는 리팩토링이 어려울 수 있으므로 미리 계획하여 장치 구성에 메타데이터를 적용하십시오. AWS IoT의 경우 IoT Device Management 사례를 주도하는 사물 유형 및 사물 그룹 구성 객체를 생성합니다.

규모에 따른 기기 클라우드 프로비저닝에 대한 접근 방식

모든 IoT 배포는 장치 프로비저닝과 관련하여 다르지만 적절한 메커니즘에 대한 결정에 영향을 줄 강력한 메커니즘 세트를 구동할 수 있도록 하드웨어 공급업체, IoT 애플리케이션 및 운영 컨텍스트 간에 충분히 차별화됩니다. 일반적으로 대량 등록, 주문형 등록 및 지연 등록의 세 가지 접근 방식이 있습니다. 다음 방법은 모두 모든 IoT 장치에 고유한 개인 키와 인증서 쌍이 있거나 가질 것으로 예상합니다.

일괄 등록

대량 등록을 사용하면 IoT 서비스에 등록하려는 자격 증명 집합이 장치를 현장에 배포하기 전에 알고 있습니다. 자격 증명 목록을 얻은 후에는 자격 증명을 대량 등록 프로세스로 보냅니다. 대량 등록 프로세스는 자격 증명을 등록한 다음 IoT 집합을 관리하는 데 사용하는 IoT 서비스의 관련 관리 개체와 자격 증명을 조정합니다. 대량 등록은 사용자 정의가 필요할 수 있지만 IoT 서비스 제공업체는 일반적으로 고객에게 대량 등록 프로세스를 제공합니다. 예를 들어 AWS는 AWS IoT Core 서비스의 일부로 AWS IoT 대량 등록 프로세스와 AWS SDK를 사용한 사용자 지정 처리를 제공합니다. ThingPress라는 오픈 소스 프로젝트는 특정 가져오기 사용 사례를 처리합니다.

주문형 등록

온디맨드 장치 등록을 사용하면 페어링된 자격 증명이 있는 물리적 장치 세트가 현장에 장치를 배포하기 전에 알 수 없습니다. 장치가 현장에 배포된 후 장치의 전원을 켭니다. 온디맨드의 경우 연결 서브루틴은 자격 증명 발급자에 대한 참조가 IoT 서비스에 등록되었는지 확인합니다. IoT 서비스에 사용자가 실제로 발급자의 소유자인지 확인하는 강력한 메커니즘이 있는 한, 즉 발급자 ID(PKI에서 발급자의 개인 키)가 있는 경우 발급자가 제공한 정보를 안심할 수 있습니다. 자격 증명. 그런 다음 서브루틴은 자동으로 자격 증명을 등록하고 관련 관리 개체를 만듭니다. 예를 들어 AWS에는 프로비저닝 템플릿을 사용하는 Just-In-Time-Provisioning(JITP)과 완전히 사용자 지정할 수 있는 메커니즘을 제공하는 Just-In-Time-Registration(JITR)이라는 두 가지 온디맨드 디바이스 등록 메커니즘이 있습니다.

지연 등록

지연 등록을 사용하면 현장에 배포하기 전에 물리적 장치 집합이나 페어링된 자격 증명을 알 수 없습니다. 이 경우 디바이스에는 디바이스 외부로 개인 ID를 전송하지 않고도 IoT 서비스가 확인할 수 있는 알려진 변경할 수 없는 ID(일반적으로 보호된 개인 키)가 있습니다.

오늘날, 지연 등록에는 클레임, 승인된 모바일 장치 및 승인된 ID 목록의 세 가지 메커니즘이 있습니다. 첫 번째 경우에 장치는 자격 증명 발급자에게 클레임을 보내고 발급자는 토큰으로 응답하며 장치는 토큰을 사용하여 인증서를 발급하기 위해 직접 웹 서비스 API를 호출합니다. 두 번째 경우에 장치는 휴대폰과 함께 작동합니다. 휴대폰은 사용자 이름 및 암호와 같은 모바일 자격 증명을 사용하고 발급자는 토큰으로 응답하고 휴대폰은 토큰을 장치에 보내고 장치는 다음을 사용합니다. API를 직접 호출하기 위한 토큰입니다. 세 번째 경우에는 공개 키 목록이 될 수 있는 승인된 목록과 장치가 CSR을 사용하여 IoT 서비스에 대한 직접 API 호출을 수행합니다. 그런 다음 CSR에서 파생된 공개 키를 승인된 목록과 비교한 다음 일치 항목이 있을 때 인증서를 장치에 프로비저닝합니다. 예를 들어 AWS Fleet 프로비저닝은 클레임 및 스마트폰 기반 프로비저닝 메커니즘을 제공하고 오픈 소스 프로젝트 IoT Provisioning Secret-Free는 클레임을 사용하여 지연 등록 메커니즘을 제공하며 AWS 파트너 1nce는 AWS Marketplace를 통해 간소화된 셀룰러 프로비저닝 경험을 제공합니다.

나에게 적합한 기기 프로비저닝 선택

자신에게 적합한 장치 프로비저닝을 선택한다는 것은 하드웨어 설계, 소프트웨어 설계, 제조 및 장치 수명 주기 작업에 맞는 장치 자격 증명 및 장치 클라우드 프로비저닝 방식을 찾는 것을 의미합니다. 하드웨어 설계는 개별 장치 ID 및 자격 증명 파일을 정의하고 저장하는 방법을 정의합니다. 소프트웨어 설계는 장치 인증에 영향을 미칩니다. 제조는 비밀이 생성 및 저장되거나 식별되는 조건에 영향을 미치며 인증 지문이 IoT 서비스에 반영되는 방식에 영향을 미칩니다.

제품 설계를 수행할 때 일반적으로 훨씬 앞서 결정되는 하드웨어 설계를 반영하는 물리적 하드웨어에 대한 자격 증명 프로비저닝을 수행하기로 결정하는 방법은 특정 유형의 클라우드 프로비저닝 프로세스에 대한 근본적인 중심축을 만듭니다. 또한 자체 제조를 수행하지 않는 경우 제품 구성을 위해 계약 제조업체를 사용하게 됩니다. 계약 제조에는 많은 이점이 있지만 제조 라인에서 개인 키 및 인증서와 같은 장치 비밀 생성을 포함하여 제조 프로세스의 많은 측면을 제어할 수 없습니다. 과잉 생산, 복제 및 기타 공격 벡터와 같은 위험은 고용 중인 계약 제조업체와 직접 관련될 수 있습니다. 따라서 밤에 편안하게 잠을 잘 수 있도록 많은 신뢰가 필요합니다.

IoT 플릿에 대한 사설 CA를 관리하지 않는 경우 사전 프로비저닝된 자격 증명이 적합할 수 있습니다. 사전 프로비저닝된 자격 증명은 초기에 약간의 추가 비용이 들 수 있지만 운영 비용을 크게 줄이는 것으로 나타났습니다. 자체 사설 CA를 관리해야 하는 경우 일부 하드웨어 회사는 구성이 테이프 아웃 시 수행되는 사전 프로비저닝된 자격 증명을 제공합니다. 즉, 계약 제조업체는 장치의 비밀에 대해 알지 못합니다. 그렇지 않으면 장치에 변경할 수 없는 개인 키 또는 재현 가능한 자체 생성 개인 키`가 있고 IoT 서비스에 참여하여 일정 수준의 증명 후에 자격 증명을 배포할 수 있는 지연 스타일 프로비저닝에 의존할 수 있습니다. 기기에 변경 불가능한 개인 키가 없는 불행한 상황에 처한 경우에도 개인 키와 자격 증명을 플래시에 직접 프로비저닝할 수 있지만 이는 그다지 권장되지 않습니다.

하드웨어 설계와 달리 소프트웨어 설계는 더 유연하며 장치 개발 및 수명 주기 전반에 걸쳐 변경될 수 있습니다(무선 펌웨어 업데이트 생각). 고객에게 새 장치 배치를 배송할 때마다 장치 클라우드 프로비저닝 프로세스에 의존해야 합니다. 소프트웨어 설계와 마찬가지로 프로비저닝 설계에는 진화하는 소프트웨어 요구 사항에 따라 유연성이 필요할 수 있습니다. 필요한 구성 및 사용자 지정 범위는 새 장치 또는 추가 장치 집합을 배포할 때 사용할 장치 클라우드 프로비저닝 프로세스를 주도합니다.

장치 수명 주기 운영 요구 사항은 장치 클라우드 프로비저닝에 필요한 유연성 수준을 주도합니다. 더 구체적으로 말하면, AWS IoT 디바이스 클라우드 프로비저닝을 위한 대부분의 프로세스는 사물 유형 및 사물 그룹과 같은 관리 객체의 자동 생성을 가능하게 하지만 프로세스에 등록 시간 동안 사용자 지정 상호 운용성이 필요한 경우 Just-In-Time- 더 깊은 사용자 정의를 허용하는 프로비저닝.

마지막으로, 장치 수명 주기를 볼 때 장치의 유용성 전반에 걸쳐 인간 소유자를 변경할 수 있는 기회를 고려하십시오. 개인 키 측면에서 장치 ID는 변경되지 않을 수 있지만 장치를 "공장 상태"로 이동하기 위해 이전 소유자의 인증서를 더 이상 사용하지 않을 수 있습니다. 새 소유자가 장치를 새 네트워크에 위임하고 모바일 애플리케이션을 사용하여 프로비저닝할 때 그 때 새 인증서를 프로비저닝해야 할 수 있습니다. 그러면 수명 주기 역학이 이러한 요구 사항을 수반해야 합니다.

결론

이 기사 전체에서 우리는 오늘날 목격할 가능성이 높은 IoT 프로비저닝 상황에 대해 논의했습니다. 마찬가지로, 달성하려는 것과 고객이 즐기기를 원하는 결과에 따라 많은 선택이 있다는 것을 목격했습니다. 모든 것과 마찬가지로 보안은 프로비저닝을 뒷받침합니다. 프로비저닝은 모든 장치가 고유하고 식별 가능한 개인 키 및 인증서 쌍을 갖는 것으로 시작됩니다. 선택한 자격 증명 프로비저닝 접근 방식은 디바이스 클라우드 프로비저닝 선택의 중심점을 만듭니다. 새로운 설계를 수행하는 경우 보안 요소 및 보안 엔클레이브와 같은 강화된 하드웨어 보안 솔루션을 자세히 살펴보고 장치 클라우드 프로비저닝을 단순화해야 합니다. 기존 설계를 발전시키거나 재작업하는 경우 선택이 훨씬 더 제한적으로 보일 수 있지만 IoT 용량으로 장치를 연결하는 옵션은 여전히 ​​있습니다. 마지막으로, 예제와 일화를 통해 AWS IoT가 당사의 실리콘 파트너 솔루션과 잘 짝을 이루는 디바이스 클라우드 프로비저닝 솔루션을 제공했음을 목격할 수 있었습니다. 이제 안전하게 위임되고 프로비저닝된 IoT 장치를 구축할 때입니다!