X.509 인증서 증명

이 문서에서는 X.509 인증서 증명을 사용하여 디바이스를 프로비저닝할 때 관련된 DPS(Device Provisioning Service) 개념에 대한 개요를 제공합니다. 이 문서는 배포를 위한 디바이스 준비에 관련된 모든 사람에게 적합합니다.

X.509 인증서는 하드웨어 보안 모듈 HSM에 저장할 수 있습니다.

팁

프로덕션의 디바이스에 X.509 인증서와 같은 비밀을 안전하게 저장하려면 디바이스에서 HSM을 사용하는 것이 좋습니다.

X.509 인증서

X.509 인증서를 증명 메커니즘으로 사용하면 프로덕션의 크기를 조정하고 디바이스 프로비전을 간소화할 수 있습니다. X.509 인증서는 일반적으로 체인의 각 인증서가 다음으로 높고, 그 다음으로 높은 등등의 우선 순위에 있는 인증서의 프라이빗 키로 서명되는 신뢰의 인증서 체인에 정렬되며, 자체 서명된 루트 인증서에서 종료됩니다. 이 방식을 사용하는 경우 신뢰할 수 있는 루트 CA(인증 기관)에서 생성한 루트 인증서에서 각각의 중간 CA를 거쳐 디바이스에 설치된 최종 엔터티 “리프” 인증서로의 위임된 신뢰 체인이 설정됩니다. 자세한 내용은 X.509 CA 인증서를 사용하여 디바이스 인증을 참조하세요.

인증서 체인은 종종 디바이스와 관련된 논리적 또는 물리적 계층 일부를 나타냅니다. 예를 들어, 제조업체는 다음과 같은 작업을 수행할 수 있습니다.

• 자체 서명된 루트 CA 인증서 발급
• 루트 인증서를 사용하여 각 공장에 대한 고유한 중간 CA 인증서 생성
• 각 공장 인증서를 사용하여 공장의 각 생산 라인에 대한 고유한 중간 CA 인증서 생성
• 마지막으로 생산 라인 인증서를 사용하여 해당 라인에서 제조된 각 디바이스에 대해 고유한 디바이스(최종 엔터티) 인증서 생성

자세한 내용은 IoT 업계의 X.509 CA 인증서에 대한 개념적 이해를 참조하세요.

루트 인증서

루트 인증서는 CA(인증 기관)를 나타내는 자체 서명된 X.509 인증서입니다. 인증서 체인의 종점 또는 트러스트 앵커입니다. 루트 인증서는 조직에서 자체적으로 발급하거나 루트 인증 기관에서 구입할 수 있습니다. 자세한 내용은 X.509 CA 인증서 얻기를 참조하세요. 또한 루트 인증서는 루트 CA 인증서라고도 합니다.

중간 인증서

중간 인증서는 루트 인증서(또는 해당 체인에 루트 인증서가 있는 다른 중간 인증서)에서 서명한 X.509 인증서입니다. 체인의 마지막 중간 인증서는 리프 인증서에 서명하는 데 사용됩니다. 또한 중간 인증서는 중간 CA 인증서라고도 합니다.

중간 인증서가 유용한 이유는 무엇인가요?

중간 인증서는 다양한 방법으로 사용됩니다. 예를 들어 중간 인증서를 사용하여 제품 라인, 디바이스를 구매하는 고객, 회사 부서 또는 공장별로 디바이스를 그룹화할 수 있습니다.

Contoso가 ContosoRootCert라는 루트 인증서를 사용하는 자체 PKI(공개 키 인프라)를 보유한 대기업이라고 가정해 보겠습니다. Contoso의 각 자회사에는 ContosoRootCert에서 서명한 자체 중간 인증서가 있습니다. 그러면 각 자회사에서 중간 인증서를 사용하여 각 디바이스에 대한 리프 인증서에 서명합니다. 이 시나리오에서 Contoso는 ContosoRootCert가 확인된 인증서인 단일 DPS 인스턴스를 사용할 수 있습니다. 각 자회사에 대한 등록 그룹을 가질 수 있습니다. 이렇게 하면 각 개별 자회사가 인증서 확인에 대해 걱정할 필요가 없습니다.

최종 엔터티 “리프” 인증서

리프 인증서 또는 최종 엔터티 인증서는 인증서 보유자를 식별합니다. 인증서 체인에는 루트 인증서와 0개 이상의 중간 인증서가 있습니다. 리프 인증서는 다른 인증서에 서명하는 데 사용되지 않습니다. 디바이스를 프로비전 서비스에 고유하게 식별하며, 때로는 디바이스 인증서라고도 합니다. 인증하는 동안 디바이스는 이 인증서와 관련된 프라이빗 키를 사용하여 서비스의 소유 챌린지 증명에 응답합니다.

개별 등록 또는 등록 그룹 항목에 사용되는 리프 인증서에는 CN(주체 일반 이름)이 등록 ID로 설정되어 있어야 합니다. 등록 ID는 DPS를 사용하여 디바이스 등록을 식별하며 디바이스가 등록되는 DPS 인스턴스(ID 범위)에 고유해야 합니다. 등록 ID는 영숫자 문자의 대/소문자를 구분하지 않는 문자열과 특수 문자인 '-', '.', '_', ':'입니다. 마지막 문자는 영숫자 또는 대시('-')여야 합니다. DPS는 최대 128자 길이의 등록 ID를 지원합니다. 그러나 X.509 인증서의 주체 일반 이름의 최대 길이는 64자입니다. 따라서 등록 ID는 X.509 인증서를 사용할 때 64자로 제한됩니다.

등록 그룹의 경우 주체 CN(일반 이름)은 IoT Hub에 등록된 디바이스 ID도 설정합니다. 디바이스 ID는 등록 그룹의 인증된 디바이스에 대한 등록 레코드에 표시됩니다. 개별 등록의 경우 등록 항목에서 디바이스 ID를 설정할 수 있습니다. 등록 항목에 설정되지 않은 경우 주체 CN(일반 이름)이 사용됩니다.

자세한 내용은 X.509 CA 인증서로 서명된 디바이스 인증을 참조하세요.

X.509 인증서를 사용하여 프로비전 서비스에 대한 디바이스 액세스 제어

프로비저닝 서비스는 X.509 증명 메커니즘으로 디바이스 액세스를 제어하는 데 사용할 수 있는 두 가지 등록 유형을 공개합니다.

• 개별 등록 항목은 특정 디바이스와 연결된 디바이스 인증서로 구성됩니다. 이러한 항목은 특정 디바이스에 대한 등록을 제어합니다.
• 등록 그룹 항목은 특정 중간 또는 루트 CA 인증서와 연결됩니다. 이러한 항목은 인증서 체인에 해당 중간 또는 루트 인증서가 있는 모든 디바이스에 대한 등록을 제어합니다.

DPS 인스턴스의 등록 항목 하나에만 인증서를 지정할 수 있습니다.

상호 TLS 지원

DPS 등록이 X.509 증명에 대해 구성된 경우 DPS에서 mTLS(상호 TLS)를 지원합니다.

DPS 디바이스 체인 요구 사항

디바이스가 등록 그룹을 사용하여 DPS를 통해 등록을 시도하는 경우 디바이스는 리프 인증서의 인증서 체인을 확인된 인증서로 보내야 합니다. 그렇지 않으면 인증이 실패합니다.

예를 들어 루트 인증서만 확인하고 중간 인증서를 등록 그룹에 업로드하면 디바이스는 리프 인증서에서 확인된 루트 인증서까지 인증서 체인을 제시해야 합니다. 이 인증서 체인에는 중간 인증서가 포함됩니다. DPS가 인증서 체인을 확인된 인증서로 트래버스할 수 없는 경우 인증이 실패합니다.

예를 들어, 디바이스에 다음 디바이스 체인을 사용하는 회사를 생각해 보세요.

이 예에서는 루트 인증서만 확인되고 intermediate2 인증서가 등록 그룹에 업로드됩니다.

프로비저닝하는 동안 디바이스에서 다음 디바이스 체인만 전송하면 인증에 실패합니다. DPS는 intermediate1 인증서의 유효성을 가정하여 인증을 시도할 수 없기 때문입니다.

프로비저닝하는 동안 디바이스에서 다음과 같이 전체 디바이스 체인을 전송하는 경우 DPS는 디바이스 인증을 시도할 수 있습니다.

인증서를 사용하는 DPS 작업 순서

디바이스가 프로비저닝 서비스에 연결되면 서비스는 디바이스(리프) 인증서로 시작하는 인증서 체인을 안내하고 해당 등록 항목을 찾습니다. 체인에서 찾은 첫 번째 항목을 사용하여 디바이스를 프로비전할지 여부를 결정합니다. 즉, 디바이스(리프) 인증서에 대한 개별 등록이 있으면 프로비전 서비스에서 해당 항목을 적용합니다. 디바이스에 대한 개별 등록이 없는 경우 서비스는 첫 번째 중간 인증서에 해당하는 등록 그룹을 찾습니다. 항목을 찾으면 해당 항목이 적용됩니다. 그렇지 않으면 다음 중간 인증서에 대한 등록 그룹을 찾고 루트에 체인을 따라 루트를 찾습니다.

이 서비스는 찾은 첫 번째 항목을 다음과 같이 적용합니다.

• 발견된 첫 번째 등록 항목을 사용할 수 있으면 서비스에서 해당 디바이스를 프로비전합니다.
• 발견된 첫 번째 등록 항목을 사용할 수 없으면 서비스에서 해당 디바이스를 프로비전하지 않습니다.
• 디바이스의 인증서 체인에 있는 인증서에 대한 등록 항목이 없으면 서비스에서 해당 디바이스를 프로비전하지 않습니다.

디바이스의 인증서 체인에 있는 각 인증서는 등록 항목에 지정할 수 있지만 DPS 인스턴스의 한 항목에만 지정할 수 있습니다.

이 메커니즘과 인증서 체인의 계층 구조는 개별 디바이스 및 디바이스 그룹에 대한 액세스를 제어하는 방법에 강력한 유연성을 제공합니다. 예를 들어 다음과 같은 인증서 체인이 있는 5개의 디바이스를 가정합니다.

• 디바이스 1: 루트 인증서 -> 인증서 A -> 디바이스 1 인증서
• 디바이스 2: 루트 인증서 -> 인증서 A -> 디바이스 2 인증서
• 디바이스 3: 루트 인증서 -> 인증서 A -> 디바이스 3 인증서
• 디바이스 4: 루트 인증서 -> 인증서 B -> 디바이스 4 인증서
• 디바이스 5: 루트 인증서 -> 인증서 B -> 디바이스 5 인증서

처음에는 루트 인증서에 대해 사용할 수 있는 단일 그룹 등록 항목을 만들어 5개 디바이스 모두에 대한 액세스를 사용하도록 설정할 수 있습니다. 나중에 인증서 B가 손상되는 경우 디바이스 4 및 디바이스 5가 등록되지 않도록 인증서 B에 대해 사용할 수 없는 등록 그룹 항목을 만들 수 있습니다. 나중에 디바이스 3이 여전히 손상되는 경우 해당 인증서에 대해 사용할 수 없는 개별 등록 항목을 만들 수 있습니다. 이렇게 하면 디바이스 3에 대한 액세스가 취소되지만, 디바이스 1 및 디바이스 2는 등록할 수 있습니다.