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

적용 대상: IoT Edge 1.4

Important

IoT Edge 1.4는 지원되는 릴리스입니다. 이전 릴리스에 있는 경우 IoT Edge 업데이트를 참조하세요.

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

Important

간결함을 위해 이 문서는 IoT Edge 버전 1.2 이상에 적용됩니다. 버전 1.1의 인증서 개념은 비슷하지만 몇 가지 차이점이 있습니다.

• 버전 1.1의 디바이스 CA 인증서 이름이 Edge CA 인증서로 변경되었습니다.
• 버전 1.1의 워크로드 CA 인증서는 사용 중지되었습니다. 버전 1.2 이상에서 IoT Edge 모듈 런타임은 인증서 체인에서 중간 워크로드 CA 인증서 없이 Edge CA 인증서에서 직접 모든 서버 인증서를 생성합니다.

요약

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

행위자	목적	인증서
IoT Edge	올바른 IoT Hub와 통신하는지 확인	IoT Hub 서버 인증서
IoT Hub	요청이 적법한 IoT Edge 디바이스에서 온 것인지 확인	IoT Edge ID 인증서
다운스트림 IoT 디바이스	올바른 IoT Edge 게이트웨이와 통신하는지 확인	Edge CA에서 발급한 IoT Edge Hub edgeHub 모듈 서버 인증서
IoT Edge	새 모듈 서버 인증서에 서명합니다. 예: edgeHub	에지 CA 인증서
IoT Edge	요청이 적법한 다운스트림 디바이스에서 온 것인지 확인	IoT 디바이스 ID 인증서

필수 조건

• 공개 키 암호화, 키 쌍, 그리고 공개 키와 프라이빗 키가 데이터를 암호화하거나 해독하는 방법에 대한 기본적인 이해가 있어야 합니다. 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 핸드셰이크를 참조하세요.

참고 항목

이 예에서 ContosoIoTHub는 IoT Hub 호스트 이름 ContosoIotHub.Azure-devices.NET을 나타냅니다.

이 경우 암호화 알고리즘의 정확한 세부 정보를 알 필요가 없습니다. 알고리즘은 서버가 공개 키와 쌍을 이루는 프라이빗 키를 소유하도록 보장한다는 점을 이해하는 것이 중요합니다. 인증서 제시자가 인증서를 복사하거나 도용하지 않았음을 확인합니다. 예를 들어, 사진이 있는 신분증을 사용하는 경우 얼굴이 신분증의 사진과 일치합니다. 누군가가 사용자의 ID를 도용하면 사용자의 얼굴은 독특하고 복제하기 어렵기 때문에 ID를 식별에 사용할 수 없습니다. 암호화 키의 경우 키 쌍은 관련이 있고 고유합니다. 얼굴을 사진 ID와 일치시키는 대신 암호화 알고리즘은 키 쌍을 사용하여 ID를 확인합니다.

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

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

Windows 인증서 저장소:

Ubuntu 인증서 저장소:

디바이스에서 Baltimore CyberTrust 루트 인증서를 확인할 때 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가 인증서를 확인하는 데 사용하는 것입니다.

팁

IoT Hub는 IoT Edge 디바이스를 등록할 때 두 개의 지문이 필요합니다. 모범 사례는 만료 날짜가 다른 두 개의 서로 다른 디바이스 ID 인증서를 준비하는 것입니다. 이렇게 하면 한 인증서가 만료되더라도 다른 인증서는 여전히 유효하며 만료된 인증서를 회전할 시간을 줍니다. 그러나 하나의 인증서만 등록에 사용할 수도 있습니다. 디바이스를 등록할 때 기본 지문과 보조 지문 모두에 대해 동일한 인증서 지문을 설정하여 단일 인증서를 사용합니다.

예를 들어, 다음 명령을 사용하여 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의 지문과 일치하는 것을 볼 수 있습니다.

요약하면 ContosoIotHub는 EdgeGateway가 IoT Hub에 등록된 지문과 일치하는 유효한 IoT Edge 디바이스 ID 인증서를 제시하기 때문에 EdgeGateway를 신뢰할 수 있습니다.

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

참고 항목

이 예에서는 등록 그룹으로 프로비전될 때 IoT Edge에서 X.509 CA 인증을 지원하는 Azure IoT Hub DPS(Device Provisioning Service)를 다루지 않습니다. DPS를 사용하여 CA 인증서 또는 중간 인증서를 업로드하면 인증서 체인이 확인된 다음 디바이스가 프로비전됩니다. 자세한 내용은 DPS X.509 인증서 증명을 참조하세요.

Azure Portal에서 DPS는 SHA256 지문이 아닌 인증서에 대한 SHA1 지문을 표시합니다.

DPS는 SHA256 지문을 IoT Hub에 등록하거나 업데이트합니다. openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256 명령을 사용하여 지문을 확인할 수 있습니다. 등록되면 IoT Edge는 IoT Hub에서 지문 인증을 사용합니다. 디바이스가 다시 프로비전되고 새 인증서가 발급되면 DPS는 새 지문으로 IoT Hub를 업데이트합니다.

IoT Hub는 현재 IoT Edge에서 직접 X.509 CA 인증을 지원하지 않습니다.

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

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

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

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

이제 IoT Edge와 IoT Hub 간의 간단한 상호 작용을 잘 이해했습니다. 그러나 IoT Edge는 다운스트림 디바이스 또는 기타 IoT Edge 디바이스에 대한 게이트웨이 역할을 할 수도 있습니다. 이러한 통신 채널도 암호화되고 신뢰할 수 있어야 합니다. 복잡성이 추가되었기 때문에 다운스트림 디바이스를 포함하도록 예 시나리오를 확장해야 합니다.

IoT Hub ContosoIotHub에 연결되는 부모 IoT Edge 디바이스 EdgeGateway에 연결되는 TempSensor라는 일반 IoT 디바이스를 추가합니다. 이전과 마찬가지로 모든 인증은 X.509 인증서 인증으로 이루어집니다. Microsoft의 새로운 시나리오는 "TempSensor 디바이스가 합법적인가요?" 및 "EdgeGateway의 ID가 정확하나요?"라는 두 가지 새로운 질문을 제기합니다. 시나리오는 다음과 같이 설명할 수 있습니다.

팁

TempSensor는 시나리오의 IoT 디바이스입니다. TempSensor가 부모 EdgeGateway의 다운스트림 IoT Edge 디바이스인 경우 인증서 개념은 동일합니다.

디바이스에서 게이트웨이 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는 연결을 거부합니다.

참고 항목

간단히 하기 위해 예에서는 유효성이 검사되는 속성으로 주체 인증서 CN(일반 이름)을 보여 줍니다. 실제로 인증서에 SAN(주체 대체 이름)이 있는 경우 CN 대신 SAN이 유효성 검사됩니다. 일반적으로 SAN은 여러 값을 포함할 수 있으므로 인증서 보유자의 기본 도메인/호스트 이름과 대체 도메인을 모두 포함합니다.

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 디바이스에서 실행되는 다른 모듈에 인증서를 발급할 수도 있습니다.

Important

구성 없이 기본적으로 Edge CA는 처음 시작할 때 IoT Edge 모듈 런타임(빠른 시작 Edge CA)에 의해 자동으로 생성된 다음 edgeHub 모듈에 인증서를 발급합니다. 이 프로세스는 edgeHub가 서명된 유효한 인증서를 제시하도록 허용하여 다운스트림 디바이스 연결 속도를 높입니다. 이 기능이 없으면 edgeHub 모듈에 대한 인증서를 발급하기 위해 CA를 확보해야 합니다. 자동으로 생성된 빠른 시작 Edge CA 사용은 프로덕션에서 사용할 수 없습니다. 빠른 시작 Edge CA에 대한 자세한 내용은 빠른 시작 Edge CA를 참조하세요.

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

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 이미지에 미리 설치할 수 있습니다.

참고 항목

일부 클라이언트 및 SDK는 OS 신뢰할 수 있는 루트 저장소를 사용하지 않으므로 루트 CA 파일을 직접 전달해야 합니다.

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

인증서 체인을 확인하려면 TempSensor 디바이스에서 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에서 발급한 Edge CA에서 인증서를 발급했습니다.
• 이 프라이빗 루트 CA는 이전에 신뢰할 수 있는 루트 CA로 TempSensor에도 저장됩니다.
• 암호화 알고리즘은 소유권 및 발급 체인을 신뢰할 수 있는지 확인합니다.

다른 모듈에 대한 인증서

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

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

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

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

팁

IoT Edge 디바이스와 달리 다운스트림 IoT 디바이스는 지문 X.509 인증으로 제한되지 않습니다. X.509 CA 인증도 옵션입니다. 지문에서 일치하는 항목을 찾는 대신 EdgeGateway는 TempSensor 인증서가 ContosoIotHub에 업로드된 CA를 기반으로 하는지도 확인할 수 있습니다.

요약하면 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(인증 기관)는 디지털 인증서를 발급하는 엔터티입니다. 인증 기관은 인증서의 소유자와 받는 사람 간에 신뢰할 수 있는 제3자 역할을 합니다. 디지털 인증서는 인증서의 받는 사람에 대한 공개 키의 소유권을 인정합니다. 인증서 신뢰 체인은 초기에 루트 인증서가 발급되면서 작동합니다. 이는 기관에서 발급되는 모든 인증서에서 신뢰의 기반이 됩니다. 그런 다음 루트 인증서 소유자는 추가 중간 인증서(다운스트림 디바이스 인증서)를 발급할 수 있습니다.

루트 CA 인증서

루트 CA 인증서는 전체 프로세스에서 신뢰의 기반입니다. 프로덕션 시나리오에서 이 CA 인증서는 Baltimore, Verisign, DigiCert 등의 신뢰할 수 있는 상업용 인증 기관에서 구매한 인증서입니다. IoT Edge 디바이스에 연결하는 디바이스를 완전히 제어할 수 있어야 회사 수준 인증 기관을 사용할 수 있습니다. 두 경우 모두 IoT Edge에서 IoT Hub까지의 전체 인증서 체인이 이를 사용합니다. 다운스트림 IoT 디바이스는 루트 인증서를 신뢰해야 합니다. 루트 CA 인증서를 신뢰할 수 있는 루트 인증 기관 저장소에 저장할 수도 있고, 애플리케이션 코드에서 인증서 세부 정보를 제공할 수도 있습니다.

중간 인증서

보안 디바이스를 만들기 위한 일반적인 제조 프로세스에서 주로 유출 또는 노출의 위험으로 인해 루트 CA 인증서가 직접 사용되는 경우는 거의 없습니다. 루트 CA 인증서는 중간 CA 인증서를 하나 이상 만들고 디지털 서명을 합니다. 중간 인증서가 하나만 있을 수도 있고, 아니면 중간 인증서의 체인이 있을 수도 있습니다. 중간 인증서의 체인이 필요한 시나리오는 다음과 같습니다.

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

어떤 경우든 제조업체는 이 체인의 마지막에 중간 CA 인증서를 사용하여 최종 디바이스에 배치된 에지 CA 인증서에 서명합니다. 이러한 중간 인증서는 제조 공장에서 철저히 보호됩니다. 물리적 및 전자적으로 해당 사용에 대해 엄격한 프로세스를 거칩니다.

다음 단계

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