X.509 인증서를 사용하여 ID 인증
IoT Hub는 X.509 인증서를 사용하여 디바이스를 인증합니다. X.509 인증을 사용하면 TLS(전송 계층 보안) 표준 연결 설정의 일부로 IoT 디바이스를 인증할 수 있습니다.
X.509 CA(인증 기관) 인증서는 다른 인증서에 서명할 수 있는 디지털 인증서입니다. 디지털 인증서는 IETF의 RFC 5280 표준에 규정된 인증서 형식 표준을 준수하는 경우 X.509 인증서로 간주됩니다.
X.509 CA 기능은 CA(인증 기관)를 사용하여 IoT Hub에 대한 디바이스 인증을 사용하도록 설정합니다. 초기 디바이스 등록 프로세스와 디바이스 제조 중 공급망 물류를 간소화합니다.
인증 및 권한 부여
인증은 사용자 자신이 누구인지 증명하는 프로세스입니다. 인증은 IoT Hub에 대한 사용자 또는 디바이스의 ID를 확인합니다. 이 프로세스는 AuthN으로 축약되는 경우가 많습니다.
권한 부여는 IoT Hub에서 인증된 사용자 또는 디바이스에 대한 권한을 확인하는 프로세스입니다. 액세스할 수 있는 리소스 및 명령과 해당 리소스 및 명령으로 수행할 수 있는 작업을 지정합니다. 권한 부여는 AuthZ로 축약되는 경우가 많습니다.
X.509 인증서는 권한 부여가 아닌 IoT Hub의 인증에만 사용됩니다. Microsoft Entra ID 및 공유 액세스 서명과 달리 X.509 인증서를 사용하여 권한을 사용자 지정할 수 없습니다.
인증서 인증 유형
X.509 인증서를 사용하여 인증서 지문 또는 CA(인증 기관)를 IoT Hub에 업로드하여 IoT Hub로 디바이스를 인증할 수 있습니다.
X.509 CA 서명 - 이 옵션은 프로덕션 시나리오에 권장되며 이 문서의 핵심입니다.
디바이스에 CA 서명 X.509 인증서가 있는 경우 디바이스를 등록하기 전에 서명 체인의 루트 또는 중간 CA 인증서를 IoT Hub에 업로드합니다. 디바이스에는 신뢰 인증서 체인에 확인된 X.509 CA가 포함된 X.509 인증서가 있습니다. 디바이스가 연결되면 전체 인증서 체인을 제공하고 IoT 허브는 X.509 CA를 알고 있으므로 이에 대한 유효성을 검사할 수 있습니다. 여러 디바이스가 동일한 확인된 X.509 CA에 대해 인증할 수 있습니다.
X.509 자체 서명됨
디바이스에 자체 서명된 X.509 인증서가 있는 경우 인증을 위해 IoT Hub에 인증서 버전을 제공합니다. 디바이스를 등록할 때 디바이스 X.509 인증서의 해시인 인증서 지문을 업로드합니다. 디바이스가 연결되면 인증서를 제시하고 IoT 허브는 알고 있는 해시에 대해 인증서의 유효성을 검사할 수 있습니다.
Important
X.509 CA(인증 기관) 인증을 사용하는 디바이스에 대한 다음 기능은 아직 일반 공급 되지 않으며 미리 보기 모드를 사용하도록 설정해야 합니다.
- HTTPS, Websocket을 통한 MQTT 및 Websocket 프로토콜을 통한 AMQP
- 파일 업로드(모든 프로토콜)
이러한 기능은 일반적으로 X.509 지문 인증을 사용하는 디바이스에서 사용할 수 있습니다.
X.509 인증 적용
추가 보안을 위해 디바이스 및 모듈에 대한 SAS 인증을 허용하지 않도록 IoT Hub를 구성할 수 있으며, X.509는 유일하게 허용되는 인증 옵션으로 남습니다. 현재 이 기능은 Azure Portal에서 사용할 수 없습니다. 구성하려면 IoT Hub 리소스 속성에서 disableDeviceSAS 및 disableModuleSAS를 true로 설정합니다.
az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true
X.509 CA 인증서 인증의 이점
IoT에는 연결하는 모든 디바이스에 대해 고유한 ID가 필요합니다. 인증서 기반 인증의 경우 이러한 ID는 인증서 형식입니다.
각 디바이스에서 고유 인증서를 제공하는 유효하지만 비효율적인 방법은 인증서를 미리 생성하고 모든 공급망 파트너에게 해당 프라이빗 키를 제공하는 것입니다. 이 매서드는 신뢰를 확보하기 위해 극복해야 할 다음과 같은 과제가 있습니다.
프라이빗 키를 절대 공유하지 않는 PKI 모범 사례를 무시하는 것 외에 디바이스 프라이빗 키를 공급망 파트너와 공유해야 하므로 공급망에 대한 신뢰를 구축하는 비용이 높아집니다. 정기적인 보안 감사와 같은 디바이스 프라이빗 키와 프로세스를 수용하기 위한 보안실과 같은 시스템이 필요합니다. 둘 다 공급망에 비용을 추가합니다.
공급망의 디바이스를 안전하게 고려하고 나중에 디바이스 사용 중지를 통해 배포에서 관리하는 작업은 모든 키-디바이스 쌍에 대한 일대일 작업이 됩니다. 이 관계는 그룹의 개념이 프로세스에 명시적으로 기본 제공되지 않는 한 디바이스의 그룹 관리를 배제합니다. 따라서 보안 프로세스 및 디바이스 수명 주기 관리는 운영에 큰 부담이 됩니다.
X.509 CA 인증서 인증은 인증서 체인을 사용하여 이러한 언급한 과제에 대한 세련된 솔루션을 제공합니다. 인증서 체인은 최종 중간 CA에서 디바이스에 서명할 때까지 CA에서 중간 CA에 서명하고 이어서 다른 중간 CA에 서명하는 등의 방식으로 수행됩니다. 인증서 체인은 CA 인증서와 해당 다운스트림 디바이스 간에 일대다 관계를 만듭니다. 이 관계를 통해 X.509 CA 인증서를 한 번 등록하여 여러 디바이스를 IoT Hub에 등록할 수 있습니다.
X.509 CA 인증은 공급망 물류도 간소화합니다. 일반적인 디바이스 제조 흐름에는 여러 단계와 보유자가 필요합니다. 인증 기관을 사용하여 각 보유자를 디바이스 프라이빗 키로 맡기지 않고 암호화 신뢰 체인에 서명할 수 있습니다. 각 보유자는 제조 흐름의 해당 프로세스 단계에서 디바이스에 서명합니다. 전반적인 결과물은 신뢰할 수 있는 암호화 체인을 사용하며 책임 소재가 내장된 최적의 공급망입니다.
이 프로세스는 디바이스에서 고유한 프라이빗 키를 보호할 때 가장 높은 보안을 제공합니다. 이를 위해 프라이빗 키를 내부적으로 생성할 수 있는 HSM(하드웨어 보안 모듈)을 내부적으로 사용하는 것이 좋습니다.
Azure IoT Hub DPS(Device Provisioning Service)를 사용하면 디바이스 그룹을 허브에 쉽게 프로비전할 수 있습니다. 자세한 내용은 자습서: 등록 그룹을 사용하여 여러 X.509 디바이스 프로비전을 참조하세요.
X.509 인증서 흐름
이 섹션에서는 다음 단계를 포함하여 X.509 CA 인증서를 사용하여 IoT Hub에 연결하는 디바이스를 인증하는 방법을 설명합니다.
- X.509 CA 인증서를 가져옵니다.
- X.509 CA 인증서를 사용하여 디바이스에 서명합니다.
- X.509 CA 인증서를 IoT Hub에 등록합니다.
- X.509 CA로 서명된 디바이스를 인증합니다.
- 손상된 경우 디바이스 인증서를 해지합니다.
X.509 CA 인증서 가져오기
X.509 CA 인증서는 각 디바이스에 대한 인증서 체인 맨 위에 있습니다. 사용 방법에 따라 구매하거나 만들 수 있습니다.
프로덕션 환경의 경우 전문 인증서 서비스 공급자로부터 X.509 CA 인증서를 구매하는 것이 좋습니다.
테스트를 위해 자체 서명된 X.509 CA 인증서를 만들 수도 있습니다. 테스트를 위한 인증서를 만드는 방법에 대한 자세한 내용은 테스트를 위한 인증서 만들기 및 업로드를 참조하세요. 프로덕션 환경에는 자체 서명된 인증서를 권장하지 않습니다.
X.509 CA 인증서를 획득하는 방법에 관계없이, 항상 해당 프라이빗 키를 비밀리에 유지하고 보호하도록 하세요.
인증서 구매
CA 인증서를 구입하면 디바이스가 연결될 때 잘 알려진 루트 CA를 신뢰할 수 있는 타사로 사용하여 IoT 디바이스의 적법성을 보증할 수 있다는 장점이 있습니다. 디바이스가 타사 제품 또는 서비스와 상호 작용하는 열린 IoT 네트워크의 일부인 경우 이 옵션을 선택합니다.
X.509 CA 인증서를 구매하려면 루트 인증서 서비스 공급자를 선택합니다. 루트 CA 공급자는 퍼블릭/프라이빗 키 쌍을 만드는 방법과 해당 서비스에 대한 CSR(인증서 서명 요청)을 생성하는 방법을 안내합니다. CSR은 인증 기관의 인증서를 신청하는 공식적인 프로세스입니다. 이러한 구입의 결과물은 기관 인증서로 사용하기 위한 인증서입니다. X.509 인증서의 보편성을 감안할 때 이 인증서는 IETF의 RFC 5280 표준에 맞는 올바른 형식을 갖추었을 가능성이 높습니다.
자체 서명된 인증서 만들기
자체 서명된 X.509 CA 인증서를 만드는 프로세스는 루트 인증 기관과 같은 타사 서명자가 필요하지 않다는 점을 제외하면 인증서 구매와 비슷합니다.
이 옵션은 기관 인증서를 구매할 준비가 될 때까지 테스트를 위해 선택할 수 있습니다. 또한 디바이스가 IoT Hub 외부의 타사 서비스에 연결되지 않는 경우 프로덕션에서 자체 서명된 X.509 CA 인증서를 사용할 수 있습니다.
신뢰할 수 있는 인증서 체인에 디바이스 서명
X.509 CA 인증서의 소유자는 마지막 중간 CA가 디바이스 인증서에 서명할 때까지 다른 중간 CA에 서명할 수 있는 중간 CA에 암호화 방식으로 서명할 수 있습니다. 그 결과 신뢰할 수 있는 인증서 체인이라고 하는 연속된 인증서 체인이 생성됩니다. 이 신뢰 위임은 양육권 체인을 설정하고 서명 키 공유를 방지하기 때문에 중요합니다.
체인에 있는 인증서의 이러한 연속은 인증 기관의 논리적 전달을 나타냅니다. 많은 공급망은 모든 업스트림 CA 인증서를 수신하는 동안 각 중간 CA가 체인에 로그인되는 이 논리적 인계를 따릅니다. 마지막 중간 CA는 마침내 각 디바이스에 서명하고 체인의 모든 기관 인증서를 디바이스에 삽입합니다.
디바이스 인증서(리프 인증서라고도 함)에는 Azure IoT Hub에서 IoT 디바이스를 등록할 때 사용되는 디바이스 ID ()로 설정된 CN(CN=deviceId일반 이름)이 있어야 합니다. 이 설정은 인증에 필요합니다.
X.509 인증을 사용하는 모듈의 경우 모듈의 인증서에 CN=deviceId/moduleId와 같은 CN(일반 이름) 형식이 지정되어 있어야 합니다.
디바이스에 서명하는 경우와 같이 인증서 체인을 만드는 방법을 알아보세요.
IoT Hub에 X.509 CA 인증서 등록
X.509 CA 인증서를 IoT Hub에 등록합니다. 이 인증서를 사용하여 디바이스를 인증합니다. X.509 CA 인증서는 해당 인증서 체인에 CA가 있는 모든 디바이스를 인증할 수 있습니다. X.509 CA 인증서 등록은 인증서 파일 업로드 및 소유 증명 설정을 포함하는 2단계 프로세스입니다.
업로드 프로세스에서는 인증서를 포함하는 파일이 업로드됩니다. 이 파일에 프라이빗 키는 절대 포함하지 않아야 합니다.
소유 증명 단계에는 CA 인증서를 실제로 소유하고 있는지 확인하기 위해 사용자와 IoT Hub 간의 암호화 챌린지 및 응답 프로세스가 포함됩니다. 소유권을 자동으로 또는 수동으로 확인하도록 선택할 수 있습니다. 수동 확인을 위해 IoT Hub는 CA 인증서의 프라이빗 키로 서명하는 임의 챌린지를 생성합니다. 권장 사항에 따라 프라이빗 키를 비밀로 유지하고 보호한 경우 사용자만 이 단계를 완료할 수 있는 지식을 알 수 있습니다. 프라이빗 키를 비밀로 유지하는 것이 이 방법에서 신뢰를 유지하는 기반입니다. 챌린지에 서명한 후 결과를 포함하는 파일을 업로드하여 확인을 완료합니다.
CA 인증서를 등록하는 방법을 알아봅니다.
X.509 CA 인증서로 서명된 디바이스 인증
X.509 CA 인증서가 등록되고 신뢰할 수 있는 인증서 체인으로 서명된 디바이스를 사용하는 마지막 단계는 디바이스 인증입니다. X.509 CA 서명된 디바이스가 연결되면 유효성 검사를 위해 인증서 체인을 업로드합니다. 이 정보를 사용하여 IoT Hub는 두 단계 프로세스로 디바이스를 인증합니다.
먼저 IoT Hub는 내부 일관성을 위해 인증서 체인의 유효성을 암호화하여 검사합니다. 그런 다음, IoT Hub는 디바이스에 소유 증명 챌린지를 발급합니다. IoT Hub는 디바이스에서 성공적인 소유 증명 응답을 받으면 디바이스를 인증된 것으로 선언합니다. 이 선언에서는 디바이스의 프라이빗 키가 보호되며 해당 디바이스만 이 챌린지에 성공적으로 응답할 수 있다고 가정합니다. 프라이빗 키를 보호하기 위해 디바이스에서 HSM(하드웨어 보안 모듈)과 같은 보안 칩을 사용하는 것이 좋습니다.
IoT Hub에 디바이스가 성공적으로 연결되면 인증 프로세스가 완료되며, 제대로 설정된 것입니다. 디바이스가 연결될 때마다 IoT Hub는 TLS 세션을 다시 협상하고 디바이스 X.509 인증서를 확인합니다.
디바이스 인증서 철회
IoT Hub는 인증서 기반 인증을 사용하여 디바이스를 인증할 때 인증 기관에서 인증서 해지 목록을 확인하지 않습니다. 잠재적으로 손상된 인증서로 인해 IoT Hub에 연결하지 못하도록 차단해야 하는 디바이스가 있는 경우 ID 레지스트리에서 디바이스를 사용하지 않도록 설정합니다. 자세한 내용은 디바이스 사용 안 함 또는 삭제를 참조하세요.
예제 시나리오
Company-X는 전문 설치를 위해 설계된 Smart-X-Widget을 만듭니다. Company-X는 제조와 설치를 모두 아웃소싱합니다. Factory-Y는 Smart-X-Widget을 제조하고 Technician-Z는 이를 설치합니다. Company-X는 설치를 위해 Smart-X-Widget을 Factory-Y에서 Technician-Z로 직접 배송한 다음, Company-X의 IoT Hub 인스턴스에 직접 연결하려고 합니다. 이를 위해 Company-X는 자동 연결을 위해 Smart-X-Widget을 준비하기 위해 몇 가지 일회성 설정 작업을 완료해야 합니다. 이 엔드 투 엔드 시나리오에는 다음 단계가 포함됩니다.
X.509 CA 인증서 가져오기
IoT Hub에 X.509 CA 인증서 등록
신뢰할 수 있는 인증서 체인에 디바이스 서명
디바이스 연결
이러한 단계는 자습서: 테스트를 위한 인증서 만들기 및 업로드에 설명되어 있습니다.
인증서 가져오기
Company-X는 퍼블릭 루트 인증 기관에서 X.509 CA 인증서를 구매하거나 자체 서명된 프로세스를 통해 인증서를 만들 수 있습니다. 두 옵션은 모두 공개/프라이빗 키 쌍을 생성하고 공개 키를 인증서에 서명하는 두 가지 기본 단계를 수반합니다.
이러한 단계를 수행하는 방법에 대한 자세한 내용은 서비스 공급자마다 다릅니다.
IoT Hub에 인증서 등록
Company-X는 Smart-X-Widget을 연결할 때 인증을 수행하는 IoT Hub에 X.509 CA를 등록해야 합니다. 이 일회성 프로세스를 통해 Smart-X-Widget 디바이스의 수를 인증하고 관리할 수 있습니다. CA 인증서와 디바이스 인증서 간의 일대다 관계는 X.509 CA 인증 방법을 사용할 때의 주요 이점 중 하나입니다. 대안은 각각의 모든 Smart-X-Widget 디바이스에 대한 개별 인증서 지문을 업로드합니다. 이에 따라 운영 비용이 추가됩니다.
X.509 CA 인증서 등록은 인증서를 업로드한 다음, 소유 증명을 제공하는 두 단계 프로세스입니다.
인증서 업로드
X.509 CA 인증서 업로드 프로세스는 CA 인증서를 IoT Hub에 업로드하는 것입니다. IoT Hub에는 인증서를 파일로 제공해야 합니다.
인증서 파일은 어떠한 경우에도 프라이빗 키를 포함하지 않아야 합니다. PKI(공개 키 인프라)를 관리하는 표준의 모범 사례에 따르면 Company-X의 프라이빗 키에 대한 지식은 Company-X 내에만 있어야 합니다.
소유 증명
X.509 CA 인증서는 디지털 인증서와 마찬가지로 도청의 위험이 있는 공개 정보입니다. 따라서 도청은 인증서를 가로채서 자체 인증서로 업로드하려고 할 수 있습니다. 이 예에서 IoT Hub는 Company-X에서 업로드한 CA 인증서가 실제로 Company-X에 속하는지 확인해야 합니다. 이를 위해 PoP(소유 증명) 흐름을 통해 Company-X에서 인증서를 실제로 소유하고 있음을 증명하도록 Company-X에 요구합니다.
소유 증명 흐름의 경우 IoT Hub는 회사 X가 프라이빗 키를 사용하여 서명할 난수를 생성합니다. Company-X에서 PKI 모범 사례를 따르고 프라이빗 키를 보호한 경우에만 소유 증명 챌린지에 올바르게 응답할 수 있습니다. 소유 증명 챌린지에 대한 응답이 성공하면 IoT Hub는 X.509 CA 인증서 등록을 진행합니다.
IoT Hub의 소유 증명 챌린지에 대한 응답이 성공하면 X.509 CA 등록이 완료됩니다.
신뢰할 수 있는 인증서 체인에 디바이스 서명
이 예제에서 인증서 기반 인증은 모든 Smart-X-Widget에서 고유한 디바이스 인증서를 소유해야 함을 의미합니다. Company-X는 각 디바이스에 대해 개별 인증서/키 쌍을 만드는 대신 CA 인증서를 사용하고 각 디바이스에 대한 신뢰의 인증서 체인을 만들기로 결정합니다.
이 예에서 Company-X는 Factory-Y에 서명하고 다음으로 Factory-Y가 Technician-Z에 서명하고 마지막으로 Smart-X-Widget에 서명합니다.
다음 다이어그램에서는 Smart-X-Widget 예에서 신뢰할 수 있는 인증서 체인이 함께 제공되는 방법을 보여 줍니다.
- Company-X는 Smart-X-Widget과 물리적으로 상호 작용하지 않습니다. Factory-Y의 중간 CA 인증서에 서명하여 신뢰할 수 있는 인증서 체인을 시작합니다.
- 이제 Factory-Y에는 Company-X의 서명이 있는 자체 중간 CA 인증서가 있습니다. 이러한 항목의 복사본을 각 디바이스에 전달합니다. 또한 중간 CA 인증서를 사용하여 Technician-Z의 중간 CA 인증서 및 Smart-X-Widget 디바이스 인증서에 서명합니다.
- 이제 Technician-Z에는 Factory-Y의 서명이 있는 자체 중간 CA 인증서가 있습니다. 이러한 항목의 복사본을 각 디바이스에 전달합니다. 또한 중간 CA 인증서를 사용하여 Smart-X-Widget 디바이스 인증서에 서명합니다.
- 모든 Smart-X-Widget 디바이스에는 이제 고유한 자체 디바이스 인증서와 공급망 전체에서 상호 작용한 각 중간 CA 인증서의 공개 키 및 서명 복사본이 있습니다. 이러한 인증서와 서명은 원래 Company-X 루트로 다시 추적할 수 있습니다.
CA 인증 방법은 디바이스 제조 공급망에 안전한 책임을 부여합니다. 인증서 체인 프로세스로 인해 체인에 있는 모든 멤버의 작업이 암호화 방식으로 기록되고 확인될 수 있습니다.
이 프로세스는 고유한 디바이스 공개/프라이빗 키 쌍이 독립적으로 만들어지고 프라이빗 키가 디바이스 내에서 항상 보호된다는 가정에 종속됩니다. 다행히도 보안 실리콘 칩이 내부적으로 키를 생성하고 프라이빗 키를 보호할 수 있는 HSM(하드웨어 보안 모듈) 형태로 존재합니다. Company-X는 이러한 보안 칩 중 하나를 Smart-X-Widget의 구성 요소 BOM(제품 구성 정보)에 추가하기만 하면 됩니다.
디바이스 인증
X.509 CA 인증에 맞게 제조된 디바이스에는 고유한 디바이스 인증서 및 각 제조 공급망의 인증서 체인이 갖추어져 있습니다. 디바이스 연결은 처음이더라도 인증서 체인 업로드 및 소유 증명의 2단계 프로세스에서 수행됩니다.
이 예제에서 각 Smart-X-Widget은 Factory-Y 및 Technician-Z X.509 CA 인증서와 함께 고유한 디바이스 인증서를 업로드한 다음 IoT Hub의 소유 증명 챌린지에 응답합니다.
IoT Hub는 Company-X에서 미리 등록된 X.509 CA 인증서를 사용하여 업로드된 인증서 체인이 내부적으로 일관되고 X.509 CA 인증서의 유효한 소유자가 체인을 시작했는지 확인합니다. X.509 CA 등록 프로세스와 마찬가지로 IoT Hub는 소유 증명 챌린지-응답 프로세스를 사용하여 체인, 즉 디바이스 인증서가 업로드하는 디바이스에 속하는지 확인합니다. 응답이 성공하면 IoT Hub가 디바이스를 인증된 것으로 받아 들이고 연결을 허용하도록 트리거합니다.
신뢰의 기반은 디바이스 프라이빗 키를 포함하여 프라이빗 키를 보호하는 데 있습니다. 따라서 디바이스 개인 키를 보호하기 위한 HSM(하드웨어 보안 모듈) 형식의 보안 실리콘 칩의 중요성과 체인의 인증서에서 프라이빗 키를 공유하지 않는 전반적인 모범 사례를 충분히 강조할 수 없습니다.
다음 단계
Device Provisioning Service를 사용하여 등록 그룹을 통해 여러 X.509 디바이스를 프로비전합니다.
X.509 인증서를 구성하는 필드에 대한 자세한 내용은 X.509 인증서를 참조하세요.
루트 CA 인증서 또는 하위 CA 인증서가 있고 이를 IoT Hub에 업로드하려는 경우 해당 인증서를 소유하고 있는지 확인해야 합니다. 자세한 내용은 자습서: 테스트를 위한 인증서 만들기 및 업로드를 참조하세요.