Azure IoT Edge에서 인증서를 사용하는 방법 이해

적용 대상: IoT Edge 1.5

IoT Edge는 다양한 용도로 다양한 형식의 인증서를 사용합니다. 이 문서에서는 IoT Edge가 Azure IoT Hub 및 IoT Edge 게이트웨이 시나리오에서 인증서를 사용하는 방법을 설명합니다.

요약

IoT Edge는 이러한 핵심 시나리오에서 인증서를 사용합니다. 링크를 사용하여 각 시나리오에 대해 자세히 알아봅니다.

필수 조건

• 공개 키 암호화, 키 쌍 및 공개 키와 프라이빗 키가 데이터를 암호화하거나 암호 해독하는 방법에 대한 기본적인 이해가 필요합니다. IoT Edge가 공개 키 암호화를 사용하는 방법에 대한 자세한 내용은 공개 키 암호화 및 X.509 공개 키 인프라 이해를 참조하세요.
• IoT Edge가 IoT Hub와 어떻게 관련되는지에 대한 기본적인 이해가 필요합니다. 자세한 내용은 Azure IoT Edge 런타임 및 아키텍처 이해를 참조하세요.

단일 디바이스 시나리오

IoT Edge 인증서 개념을 알아보려면 EdgeGateway 라는 IoT Edge 디바이스가 ContosoIotHub라는 Azure IoT Hub에 연결되는 시나리오를 상상해 보십시오. 이 예제에서 모든 인증은 대칭 키 대신 X.509 인증서 인증을 사용합니다. 이 시나리오에서 신뢰를 구축하려면 IoT Hub 및 IoT Edge 디바이스가 인증되었는지 다음과 같이 확인해야 합니다. "이 디바이스는 정품이고 유효한가요?" 및 "IoT Hub의 ID가 정확한가요?". 시나리오의 예는 다음과 같습니다.

이 문서에서는 각 질문에 대한 답변을 설명한 다음 이후 섹션에서 예제를 확장합니다.

디바이스에서 IoT Hub ID 확인

EdgeGateway는 실제 ContosoIotHub와 통신하고 있는지 어떻게 확인하나요? EdgeGateway가 클라우드와 대화하면 엔드포인트 ContosoIoTHub.Azure-devices.NET 연결됩니다. 엔드포인트가 인증되었는지 확인하려면 IoT Edge에서 ID(식별)를 표시하기 위해 ContosoIoTHub가 필요합니다. ID는 EdgeGateway가 신뢰하는 기관에서 발급해야 합니다. IoT Hub ID를 확인하기 위해 IoT Edge 및 IoT Hub는 TLS 핸드셰이크 프로토콜을 사용하여 IoT Hub의 서버 ID를 확인합니다. 다음 다이어그램에서는 TLS 핸드셰이크를 보여 줍니다. 일부 세부 사항은 간단하게 유지하기 위해 제외됩니다. TLS 핸드셰이크 프로토콜에 대한 자세한 내용은 Wikipedia에서 TLS 핸드셰이크를 참조하세요.

이 경우 암호화 알고리즘의 정확한 세부 정보를 알 필요가 없습니다. 중요한 점은 알고리즘이 서버에 공개 키와 쌍을 이루는 프라이빗 키가 있는지 확인하는 것입니다. 이 검사는 인증서 발표자가 인증서를 복사하거나 도용하지 않았음을 증명합니다. 얼굴이 사진과 일치하는 사진 ID를 생각해 보세요. 누군가가 ID를 도용하는 경우 얼굴은 고유하기 때문에 사용할 수 없습니다. 암호화 키의 경우 키 쌍은 관련이 있고 고유합니다. 얼굴과 사진 ID를 일치시키는 대신 암호화 알고리즘은 키 쌍을 사용하여 ID를 확인합니다.

이 시나리오에서 ContosoIotHub는 다음 인증서 체인을 보여 줍니다.

루트 CA(인증 기관)는 Baltimore CyberTrust 루트 인증서입니다. DigiCert는 이 루트 인증서에 서명하며 널리 신뢰할 수 있으며 많은 운영 체제에 저장됩니다. 예를 들어, Ubuntu와 Windows 모두 기본 인증서 저장소에 이를 포함합니다.

Windows 인증서 저장소:

Ubuntu 인증서 저장소:

디바이스가 Baltimore CyberTrust Root 인증서를 확인하는 경우 이미 OS에 있습니다. EdgeGateway 관점에서 ContosoIotHub의 인증서 체인은 OS가 신뢰하는 루트 CA에 의해 서명되므로 인증서는 신뢰할 수 있습니다. 이 인증서를 IoT Hub 서버 인증서라고 합니다. IoT Hub 서버 인증서에 대한 자세한 내용은 IoT Hub의 TLS(전송 계층 보안) 지원을 참조하세요.

요약하면 EdgeGateway는 다음과 같은 이유로 ContosoIotHub ID를 확인하고 신뢰할 수 있습니다.

• ContosoIotHub는 IoT Hub 서버 인증서를 제공합니다.
• 서버 인증서는 OS 인증서 저장소에서 신뢰됩니다.
• ContosoIotHub의 공개 키로 암호화된 데이터는 ContosoIotHub에서 해독할 수 있으므로 프라이빗 키를 소유하고 있음을 증명할 수 있습니다.

IoT Hub는 IoT Edge 디바이스 ID를 확인합니다.

ContosoIotHub는 EdgeGateway와 통신하고 있는지 어떻게 확인하나요? IoT Hub는 mTLS(상호 TLS)를 지원하므로 클라이언트 인증 TLS 핸드셰이크 중에 EdgeGateway의 인증서를 확인합니다. 간단히 하기 위해 다음 다이어그램의 몇 가지 단계를 건너뜁니다.

이 경우 EdgeGateway는 IoT Edge 디바이스 ID 인증서를 제공합니다. ContosoIotHub의 관점에서 제공된 인증서의 지문이 해당 레코드와 일치하는지, EdgeGateway에 제시된 인증서와 쌍을 이루는 프라이빗 키가 있는지 확인합니다. IoT Hub에서 IoT Edge 디바이스를 프로비전할 때 지문을 제공합니다. IoT Hub는 지문을 사용하여 인증서를 확인합니다.

예를 들어 다음 명령을 사용하여 EdgeGateway에서 ID 인증서의 지문을 가져옵니다.

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

이 명령은 인증서 SHA256 지문을 출력합니다.

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

IoT Hub에 등록된 EdgeGateway 디바이스의 SHA256 지문 값을 보면 EdgeGateway의 지문과 일치하는 것으로 표시됩니다.

요약하자면, EdgeGateway는 IoT Hub에 등록된 지문과 일치하는 지문이 있는 유효한 IoT Edge 디바이스 ID 인증서를 제공하므로 ContosoIotHub는 EdgeGateway를 신뢰합니다.

인증서 빌드 프로세스에 대한 자세한 내용은 X.509 인증서를 사용하여 Linux에서 IoT Edge 디바이스 만들기 및 프로비전을 참조하세요.

모듈 ID 작업을 위한 인증서 사용

인증서 확인 다이어그램에서는 IoT Edge에서 인증서만 사용하여 IoT Hub와 통신하는 것처럼 보일 수 있습니다. IoT Edge에는 여러 모듈이 있습니다. IoT Edge는 인증서를 사용하여 메시지를 보내는 모듈의 모듈 ID를 관리합니다. 모듈은 인증서를 사용하여 IoT Hub에 인증하지 않지만 IoT Edge 모듈 런타임에서 생성하는 프라이빗 키에서 파생된 SAS 키를 사용합니다. 이러한 SAS 키는 디바이스 ID 인증서가 만료되더라도 변경되지 않습니다. 인증서가 만료되면 edgeHub 는 계속 실행되지만 모듈 ID 작업만 실패합니다.

SAS 키는 비밀에서 파생되고 IoT Edge는 사람이 개입할 위험 없이 키를 관리하므로 모듈과 IoT Hub 간의 상호 작용은 안전합니다.

IoT Edge를 게이트웨이로 사용하는 중첩된 디바이스 계층 구조 시나리오

이제 IoT Edge와 IoT Hub 간의 간단한 상호 작용을 이해했습니다. 그러나 IoT Edge는 다운스트림 디바이스 또는 다른 IoT Edge 디바이스의 게이트웨이 역할을 할 수도 있습니다. 이러한 통신 채널은 암호화되고 신뢰할 수 있어야 합니다. 복잡성이 더해지므로 다운스트림 디바이스를 포함하도록 예제 시나리오를 확장해 보겠습니다.

IoT Hub ContosoIotHub에 연결되는 부모 IoT Edge 디바이스 EdgeGateway에 연결되는 TempSensor라는 일반 IoT 디바이스를 추가합니다. 이전과 마찬가지로 모든 인증은 X.509 인증서 인증을 사용합니다. 이 시나리오에서는 "TempSensor 디바이스가 합법적인가요?" 및 "EdgeGateway의 ID가 올바른가요?"라는 두 가지 질문을 제기합니다. 시나리오는 다음과 같습니다.

디바이스에서 게이트웨이 ID 확인

TempSensor는 정품 EdgeGateway와 통신하고 있는지 어떻게 확인하나요? TempSensor가 EdgeGateway와 통신하려고 할 때 TempSensor에서 ID를 표시하려면 EdgeGateway가 필요합니다. ID는 TempSensor가 신뢰하는 기관에서 발급해야 합니다.

흐름은 EdgeGateway가 ContosoIotHub와 통신할 때와 동일합니다. TempSensor 및 EdgeGateway는 TLS 핸드셰이크 프로토콜을 사용하여 EdgeGateway의 ID를 확인합니다. 두 가지 중요한 세부 정보가 있습니다.

• 호스트 이름 특이성: EdgeGateway에서 제공하는 인증서는 TempSensor가 EdgeGateway에 연결하는 데 사용하는 것과 동일한 호스트 이름(도메인 또는 IP 주소)에 발급되어야 합니다.
• 자체 서명된 루트 CA 특이성: EdgeGateway에서 제공하는 인증서 체인이 OS 기본 신뢰할 수 있는 루트 저장소에 없을 가능성이 높습니다.

자세한 내용을 이해하기 위해 먼저 EdgeGateway에서 제공하는 인증서 체인을 살펴보겠습니다.

호스트 이름 특이성

인증서 일반 이름 CN = edgegateway.local은 체인의 맨 위에 나열됩니다. edgegateway.local은 edgeHub의 서버 인증서 일반 이름입니다. 또한 edgegateway.local은 TempSensor 및 EdgeGateway가 연결된 로컬 네트워크(LAN 또는 VNet)에 있는 EdgeGateway의 호스트 이름입니다. 이는 192.168.1.23과 같은 개인 IP 주소이거나 다이어그램과 같은 FQDN(정규화된 도메인 이름)일 수 있습니다. edgeHub 서버 인증서는 IoT Edge config.toml 파일에 정의된 hostname 매개 변수를 사용하여 생성됩니다. edgeHub 서버 인증서와 Edge CA 인증서를 혼동하지 마세요. Edge CA 인증서 관리에 대한 자세한 내용은 IoT Edge 인증서 관리를 참조하세요.

TempSensor가 EdgeGateway에 연결되면 TempSensor는 호스트 이름 edgegateway.local을 사용하여 EdgeGateway에 연결합니다. TempSensor는 EdgeGateway에서 제공한 인증서를 확인하고 인증서 일반 이름이 edgegateway.local인지 확인합니다. 인증서 일반 이름이 다른 경우 TempSensor는 연결을 거부합니다.

EdgeGateway가 자체 호스트 이름에 대해 알려야 하는 이유는 무엇인가요?

EdgeGateway에는 네트워크의 다른 클라이언트가 어떻게 연결할 수 있는지 알 수 있는 신뢰할 수 있는 방법이 없습니다. 예를 들어, 개인 네트워크에는 EdgeGateway를 10.0.0.2 또는 example-mdns-hostname.local로 나열하는 DHCP 서버 또는 mDNS 서비스가 있을 수 있습니다. 그러나 일부 네트워크에는 edgegateway.local을 EdgeGateway의 IP 주소 10.0.0.2에 매핑하는 DNS 서버가 있을 수 있습니다.

이 문제를 해결하기 위해 IoT Edge는 config.toml에 구성된 호스트 이름 값을 사용하고 이에 대한 서버 인증서를 만듭니다. edgeHub 모듈에 요청이 오면 올바른 인증서 CN(일반 이름)이 있는 인증서를 제시합니다.

IoT Edge에서 인증서를 만드는 이유는 무엇인가요?

이 예에서 인증서 체인에 iotedged workload ca edgegateway가 있음을 알 수 있습니다. Edge CA(이전 버전 1.1에서는 디바이스 CA로 알려짐)라는 IoT Edge 디바이스에 존재하는 CA(인증 기관)입니다. 이전 예의 Baltimore CyberTrust 루트 CA와 마찬가지로 Edge CA는 다른 인증서를 발급할 수 있습니다. 가장 중요한 것은 이 예에서도 edgeHub 모듈에 서버 인증서를 발급합니다. 그러나 IoT Edge 디바이스에서 실행되는 다른 모듈에 인증서를 발급할 수도 있습니다.

디바이스에 발급자 인증서가 있으면 위험하지 않나요?

Edge CA는 연결이 제한적이거나 신뢰할 수 없거나 비용이 많이 들거나 연결이 없는 솔루션을 사용할 수 있도록 설계되었지만 동시에 인증서 갱신에 대한 엄격한 규정 또는 정책이 있습니다. Edge CA가 없으면 IoT Edge(특히 edgeHub)가 작동할 수 없습니다.

프로덕션에서 Edge CA를 보호하려면:

• EdgeCA 프라이빗 키를 TPM(신뢰할 수 있는 플랫폼 모듈)에 넣습니다. 프라이빗 키가 일시적으로 생성되고 TPM을 떠나지 않는 방식으로 하는 것이 좋습니다.
• Edge CA가 롤업되는 PKI(공개 키 인프라)를 사용합니다. 이는 손상된 인증서의 갱신을 사용하지 않도록 설정하거나 거부하는 기능을 제공합니다. PKI는 노하우(저렴한 비용)가 있거나 상용 PKI 공급자를 통해 고객 IT에서 관리할 수 있습니다.

자체 서명된 루트 CA 특이성

edgeHub 모듈은 모든 수신 트래픽을 처리하여 IoT Edge를 구성하는 중요한 구성 요소입니다. 이 예에서는 Edge CA에서 발급한 인증서를 사용하고 이 인증서는 자체 서명된 루트 CA에서 발급합니다. 루트 CA는 OS에서 신뢰하지 않으므로 TempSensor가 이를 신뢰할 수 있는 유일한 방법은 디바이스에 CA 인증서를 설치하는 것입니다. 이는 체인을 신뢰해야 하는 클라이언트에 루트를 배포해야 하는 트러스트 번들 시나리오라고도 합니다. 트러스트 번들 시나리오는 디바이스에 액세스하고 인증서를 설치해야 하기 때문에 번거로울 수 있습니다. 인증서를 설치하려면 계획이 필요합니다. 스크립트를 사용하거나, 제조 중에 추가하거나, OS 이미지에 미리 설치할 수 있습니다.

이러한 모든 개념을 적용하면 TempSensor는 주소와 일치하는 인증서를 제공하고 인증서가 신뢰할 수 있는 루트에서 서명했기 때문에 정품 EdgeGateway와 통신하고 있음을 확인할 수 있습니다.

인증서 체인을 확인하려면 openssl 디바이스에서 를 사용할 수 있습니다. 이 예에서 연결을 위한 호스트 이름은 깊이 0 인증서의 CN과 일치하고 루트 CA는 일치합니다.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

openssl 명령에 대한 자세한 내용은 OpenSSL 설명서를 참조하세요.

기본적으로 /var/lib/aziot/certd/certs에 저장된 인증서를 검사할 수도 있습니다. 디렉터리에서 Edge CA 인증서, 디바이스 ID 인증서 및 모듈 인증서를 찾을 수 있습니다. openssl x509 명령을 사용하여 인증서를 검사할 수 있습니다. 예시:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

요약하면 TempSensor는 다음과 같은 이유로 EdgeGateway를 신뢰할 수 있습니다.

• edgeHub 모듈이 edgegateway.local에 대해 유효한 IoT Edge 모듈 서버 인증서를 표시했습니다.
• 에서 발급한 my_private_root_CA에서 인증서를 발급했습니다.
• 이 프라이빗 루트 CA는 이전에 신뢰할 수 있는 루트 CA로 TempSensor에도 저장됩니다.
• 암호화 알고리즘은 소유권 및 발급 체인을 신뢰할 수 있는지 확인합니다.

다른 모듈에 대한 인증서

다른 모듈은 Edge CA에서 발급한 서버 인증서를 가져올 수 있습니다. 예를 들어, 웹 인터페이스가 있는 Grafana 모듈입니다. Edge CA에서 인증서를 가져올 수도 있습니다. 모듈은 컨테이너에서 호스트되는 다운스트림 디바이스로 취급됩니다. 그러나 IoT Edge 모듈 런타임에서 인증서를 가져올 수 있는 것은 특별한 권한입니다. 모듈은 워크로드 API를 호출하여 구성된 Edge CA에 연결된 서버 인증서를 수신합니다.

게이트웨이는 디바이스 ID를 확인합니다.

EdgeGateway는 TempSensor와 통신하고 있는지 어떻게 확인하나요? EdgeGateway 는 TLS 클라이언트 인증 을 사용하여 TempSensor를 인증합니다.

시퀀스는 디바이스를 확인하는 ContosoIotHub 와 유사합니다. 그러나 게이트웨이 시나리오에서 EdgeGateway 는 ContosoIotHub 를 인증서 레코드의 원본으로 사용합니다. 또한 EdgeGateway는 클라우드에 연결되지 않은 경우 오프라인 복사 또는 캐시를 유지합니다.

요약하면 EdgeGateway는 다음과 같은 이유로 TempSensor를 신뢰할 수 있습니다.

• TempSensor 는 이름에 유효한 IoT 디바이스 ID 인증서 를 제공합니다.
• ID 인증서의 지문이 ContosoIotHub에 업로드된 지문과 일치합니다.
• 암호화 알고리즘은 소유권 및 발급 체인을 신뢰할 수 있는지 확인합니다.

인증서 및 관리를 가져올 수 있는 곳

대부분의 경우 사용자 고유의 인증서를 제공하거나 자동 생성된 인증서를 사용합니다. 예를 들어, Edge CA 및 edgeHub 인증서는 자동 생성됩니다.

그러나 가장 좋은 방법은 EST(보안 전송) 서버를 통해 등록을 사용하여 x509 인증서를 관리하도록 디바이스를 설정하는 것입니다. EST 서버를 사용하면 디바이스에서 인증서를 수동으로 처리하고 설치하지 않도록 할 수 있습니다. EST 서버 사용에 대한 자세한 내용은 Azure IoT Edge용 보안 전송을 통한 등록 서버 구성을 참조하세요.

인증서를 사용하여 EST 서버에도 인증할 수 있습니다. 이러한 인증서는 EST 서버에서 인증하여 다른 인증서를 발급합니다. 인증서 서비스는 부트스트랩 인증서를 사용하여 EST 서버를 인증합니다. 부트스트랩 인증서는 수명이 깁니다. 처음 인증하면 인증서 서비스가 EST 서버에서 ID 인증서를 요청합니다. ID 인증서는 동일한 서버에 대한 향후 EST 요청에 사용됩니다.

EST 서버를 사용할 수 없는 경우 PKI 공급자에게 인증서를 요청합니다. IoT Hub 및 IoT Edge 디바이스에서 인증서 파일을 수동으로 관리합니다. 자세한 내용은 IoT Edge 디바이스에서 인증서 관리를 참조하세요.

개념 증명 개발의 경우 테스트 인증서를 만듭니다. 자세한 내용은 IoT Edge 디바이스 기능을 테스트하기 위한 데모 인증서 만들기를 참조하세요.

IoT의 인증서

인증 기관

CA(인증 기관)에서 디지털 인증서를 발급합니다. CA는 인증서 소유자와 인증서 수신자 간에 신뢰할 수 있는 타사 역할을 합니다. 디지털 인증서는 수신자가 공개 키를 소유하고 있음을 증명합니다. 신뢰의 인증서 체인은 루트 인증서로 시작하며, 이는 당국이 발급하는 모든 인증서에 대한 신뢰의 기초입니다. 루트 인증서 소유자는 추가 중간 인증서(다운스트림 디바이스 인증서)를 발급할 수 있습니다.

루트 CA 인증서

루트 CA 인증서는 프로세스에 대한 신뢰의 루트입니다. 프로덕션 환경에서는 일반적으로 Baltimore, Verisign 또는 DigiCert와 같은 신뢰할 수 있는 상용 인증 기관에서 이 CA 인증서를 구입합니다. IoT Edge 디바이스에 연결하는 모든 디바이스를 제어하는 경우 회사 인증 기관을 사용할 수 있습니다. 두 경우 모두 IoT Edge에서 IoT Hub로의 인증서 체인은 루트 CA 인증서를 사용합니다. 다운스트림 IoT 디바이스는 루트 인증서를 신뢰해야 합니다. 루트 CA 인증서를 신뢰할 수 있는 루트 인증 기관 저장소에 저장하거나 애플리케이션 코드에 인증서 세부 정보를 제공합니다.

중간 인증서

보안 디바이스에 대한 일반적인 제조 프로세스에서 제조업체는 누출 또는 노출 위험 때문에 루트 CA 인증서를 직접 사용하는 경우는 거의 발생하지 않습니다. 루트 CA 인증서는 중간 CA 인증서를 하나 이상 만들고 디지털 서명을 합니다. 중간 인증서가 하나 또는 체인일 수 있습니다. 중간 인증서 체인이 필요한 시나리오는 다음과 같습니다.

• 제조업체 내 부서의 계층 구조
• 디바이스의 프로덕션에 순차적으로 참여하는 여러 회사
• 루트 CA를 구입하고 제조업체가 고객을 대신하여 디바이스에 서명할 수 있도록 서명 인증서를 파생하는 고객

제조업체는 이 체인의 끝에 있는 중간 CA 인증서를 사용하여 최종 디바이스에 배치된 Edge CA 인증서에 서명합니다. 제조 공장은 이러한 중간 인증서를 밀접하게 보호합니다. 엄격한 물리적 및 전자 프로세스는 사용을 제어합니다.

다음 단계

• IoT Edge 디바이스에 인증서를 설치하고 구성 파일에서 해당 인증서를 참조하는 방법에 대한 자세한 내용은 IoT Edge 디바이스에서 인증서 관리를 참조하세요.
• Azure IoT Edge 모듈 이해
• IoT Edge 디바이스를 투명 게이트웨이로 작동하도록 구성
• 이 문서에서는 인증서를 사용하여 IoT Edge 디바이스의 여러 구성 요소 간 또는 IoT Edge 디바이스와 다운스트림 디바이스 간의 연결을 보호하는 방법을 설명합니다. 인증서를 사용하여 IoT Edge 디바이스를 IoT Hub에 인증할 수도 있습니다. 이러한 인증 인증서는 다르므로 이 문서에서 설명하지 않습니다. 인증서를 사용하여 디바이스를 인증하는 방법에 대한 자세한 내용은 X.509 인증서를 사용하여 IoT Edge 디바이스 만들기 및 프로비저닝을 참조하세요.