Microsoft Entra Verified ID 발급 솔루션 계획
자격 증명을 발급하는 것 외에 솔루션이 아키텍처 및 비즈니스에 미치는 영향을 전체적으로 파악할 수 있도록 발급 솔루션을 계획하는 것이 중요합니다. 아직 보지 않으셨다면, 기본 정보를 위해 Microsoft Entra Verified ID 아키텍처 개요를 보는 것을 권장합니다.
지침의 범위
이 문서에서는 VC(확인 가능한 자격 증명) 발급 솔루션에 대한 계획의 기술적 측면을 설명합니다. 확인 가능한 자격 증명에 대한 Microsoft 솔루션은 W3C(World Wide Web 컨소시엄) 확인 가능한 자격 증명 데이터 모델 1.0 및 DID(탈중앙화 식별자) V1.0 표준을 따르므로 Microsoft가 아닌 타사 서비스와 상호 운용할 수 있습니다. 그러나 이 콘텐츠의 예제에는 확인 가능한 자격 증명에 대한 Microsoft 솔루션 스택이 반영됩니다.
발급 솔루션과 관련이 없는 지원 기술을 다루는 항목은 이 콘텐츠에서 자세히 다루지 않습니다. 예를 들어 웹 사이트는 확인 가능한 자격 증명 발급 솔루션에서 사용되지만 웹 사이트 배포 계획은 자세히 다루지 않습니다.
솔루션의 구성 요소
발급 솔루션에 대한 계획의 일부로 발급자, 사용자 및 검증 도구 간의 상호 작용을 가능하게 하는 솔루션을 디자인해야 합니다. 다음 다이어그램에서는 발급 아키텍처의 구성 요소를 보여 줍니다.
Microsoft VC 발급 솔루션 아키텍처
Microsoft Entra 테넌트
Microsoft Entra 확인된 ID를 호스트하려면 Microsoft Entra 테넌트에 액세스해야 합니다. Microsoft Entra 테넌트는 솔루션의 리소스 부분에 대한 IAM(ID 및 액세스 관리) 컨트롤 플레인을 제공합니다.
각 테넌트에는 다중 테넌트 Microsoft Entra Verified ID 서비스가 사용되고 DID(탈중앙화 식별자)가 있습니다. DID는 발급자가 DID에 통합된 도메인을 소유한다는 증명을 제공합니다. DID는 주체와 검증자가 발급자의 유효성을 검증하는 데 사용됩니다.
Microsoft Azure 서비스
Azure Key Vault 서비스는 Microsoft Entra Verified ID 발급 서비스를 시작할 때 생성되는 발급자 키를 저장합니다. 키와 메타데이터는 자격 증명 관리 작업을 실행하고 메시지 보안을 제공하는 데 사용됩니다.
각 발급자마다 서명, 업데이트, 복구에 사용되는 단일 키 집합이 있습니다. 이 키 집합은 생성되는 모든 확인 가능한 자격 증명의 모든 발급에 사용됩니다.
Microsoft Entra Verified ID 서비스는 자격 증명 메타데이터 및 정의를 저장하는 데 사용됩니다. 특히 자격 증명에 대한 규칙 및 표시 정의를 저장하는 데 사용됩니다.
디스플레이 정의에 따라 클레임이 소유자의 전자지갑에 표시되는 방식이 결정되고 여기에는 또한 브랜딩 및 기타 요소가 포함됩니다. 표시 정의는 여러 언어로 지역화할 수 있습니다. 확인 가능한 자격 증명을 사용자 지정하는 방법을 참조하세요.
규칙은 확인 가능한 자격 증명의 필수 입력을 기술하는 발급자 정의 모델입니다. 규칙은 또한 신뢰할 수 있는 입력 원본을 정의하고 VC에 저장된 출력 클레임에 대한 입력 클레임 매핑을 정의합니다. 규칙 정의에 정의된 증명 형식에 따라 입력 클레임은 다른 공급자에서 발생할 수 있습니다. 입력 클레임은 OIDC ID 공급자, id_token_hint 또는 전자 지갑의 사용자 입력을 통해 발행하는 동안 자체 어설션 클레임에서 발생할 수 있습니다.
- 입력 – 클라이언트 사용에 대한 규칙 파일에 있는 모델의 하위 집합입니다. 하위 집합은 입력 세트, 입력을 가져올 위치, 확인 가능한 자격 증명을 얻기 위해 호출할 엔드포인트를 설명해야 합니다.
Microsoft Entra Verified ID 서비스
Microsoft Entra Verified ID 서비스를 사용하면 구성에 따라 VC를 발급하고 해지할 수 있습니다. 서비스:
DID(탈중앙화 식별자)를 프로비전합니다. 각 발급자에는 테넌트당 단일 DID가 있습니다.
Key Vault에 키 집합을 프로비저닝합니다.
발급 서비스 및 Microsoft Authenticator에서 사용하는 구성 메타데이터를 저장합니다.
발급자 및 검증 도구 웹 프런트 엔드에 대한 REST API 인터페이스를 제공합니다.
신뢰 시스템
Microsoft Entra Verified ID는 현재 DID 문서가 발급자 웹 서버에서 호스트되는 신뢰 시스템인 DID 웹으로 웹을 지원합니다.
Microsoft Authenticator 애플리케이션
Microsoft Authenticator는 모바일 애플리케이션입니다. 인증자는 사용자, Microsoft Entra Verified ID 서비스 및 VC 발급에 사용되는 계약 간의 상호 작용을 오케스트레이션합니다. 이 애플리케이션은 VC 주체의 프라이빗 키를 포함하여 VC 소유자가 VC를 저장하는 디지털 지갑 역할을 합니다. Authenticator는 검증을 위해 VC를 제공하는 데 사용되는 메커니즘이기도 합니다.
발급 사업 논리
발급 솔루션에는 사용자가 VC, ID 저장소 및 기타 특성 저장소를 요청하여 주체 및 기타 백 엔드 서비스에 대한 클레임 값을 가져오는 웹 프런트 엔드가 포함됩니다.
웹 프런트 엔드는 딥 링크 또는 QR 코드를 생성하여 주체의 지갑에 발급 요청을 제공합니다. 계약의 구성에 따라 VC를 만들기 위한 요구 사항을 충족하려면 다른 구성 요소가 필요할 수 있습니다.
이러한 서비스는 Microsoft Entra Verified ID 발급 서비스와 통합하지 않아도 되는 지원 역할을 제공합니다. 이 계층에는 일반적으로 다음이 포함됩니다.
OIDC(Open ID Connect) 규격의 서비스 또는 서비스들은 VC를 발급하는 데 필요한 id_tokens를 가져오는 데 사용됩니다. Microsoft Entra ID 또는 Azure AD B2C 같은 기존 ID 시스템은 ID 서버와 같은 사용자 지정 솔루션과 마찬가지로 OIDC 규격 서비스를 제공할 수 있습니다.
특성 저장소 – 특성 저장소는 디렉터리 서비스 외부에 있을 수 있으며 VC 발급에 필요한 특성을 제공합니다. 예를 들어 학생 정보 시스템은 취득한 학위에 대한 클레임을 제공할 수 있습니다.
추가 중간 계층 서비스 - 자격 증명을 발급하는 데 필요한 조회, 유효성 검사, 청구 및 기타 런타임 검사와 워크플로에 대한 비즈니스 규칙을 포함합니다.
웹 프런트 엔드 설정에 대한 자세한 내용은 확인 가능한 자격 증명을 발급하도록 Microsoft Entra ID 구성 자습서를 참조하세요.
자격 증명 디자인 고려 사항
특정 사용 사례에 따라 자격 증명 디자인이 결정됩니다. 사용 사례에 따라 다음이 결정됩니다.
상호 운용성 요구 사항
사용자가 VC를 가져오기 위해 ID를 증명해야 하는 방식
자격 증명에 필요한 요구 사항
자격 증명을 철회해야 하는 경우
자격 증명 사용 사례
Microsoft Entra Verified ID에서 가장 일반적인 자격 증명 사용 사례는 다음과 같습니다.
ID 검증: 자격 증명이 여러 조건에 따라 발급됩니다. 여권 또는 운전면허증과 같은 정부 발행 문서의 신뢰성을 확인하고 해당 문서의 정보를 다음과 같은 다른 정보와 상호 연결하는 것이 여러 기준에 포함될 수 있습니다.
사용자의 셀피
실재성 검증
이러한 종류의 자격 증명은 ID 검증이 필수적인 새 직원, 파트너, 서비스 공급자, 학생 및 기타 인스턴스의 ID 온보딩 시나리오에 적합합니다.
고용/멤버 자격 증명: 사용자와 기관 간의 관계를 증명하기 위해 자격 증명이 발급됩니다. 이러한 종류의 자격 증명은 직원 또는 학생에게 할인을 제공하는 소매점과 같이 느슨하게 결합된 B2B 애플리케이션에 액세스하는 데 적합합니다. VC의 주요 값 중 하나는 이식성입니다. 발급되면 사용자는 여러 시나리오에서 VC를 사용할 수 있습니다.
더 많은 사용 사례는 Verifiable Credentials Use Cases (w3.org)(확인 가능한 자격 증명 사용 사례(w3.org))를 참조하세요.
자격 증명 상호 운용성
디자인 프로세스의 일부로 상호 운용성 및 사용량을 최대화하는 데 적합한 산업별 스키마, 네임스페이스, 식별자를 조사합니다. 예제는 Schema.org 및 DIF - Claims and Credentials Working Group(DIF - 클레임 및 자격 증명 작업 그룹)에서 확인할 수 있습니다.
공통 스키마는 표준이 계속 등장하고 있는 영역입니다. 이러한 작업의 한 가지 예는 교육용 확인 가능한 자격 증명 태스크 포스입니다. 조직의 업계에서 새로 등장하는 표준을 조사하고 기여하는 것이 좋습니다.
자격 증명 형식 및 특성
자격 증명에 대한 사용 사례를 설정한 후에는 자격 증명 형식과 자격 증명에 포함할 특성을 결정해야 합니다. 검증 도구는 사용자가 제공하는 VC에서 클레임을 읽을 수 있습니다.
모든 확인 가능한 자격 증명은 해당 규칙 정의에서 해당 형식을 선언해야 합니다. 자격 증명 형식은 확인 가능한 자격 증명 스키마를 다른 자격 증명과 구별하고 발급자와 검증자 간의 상호 운용성을 보장합니다. 자격 증명 형식을 나타내려면 자격 증명이 충족하는 하나 이상의 자격 증명 형식을 제공합니다. 각 형식은 고유한 문자열입니다. 종종 URI는 전역 고유성을 보장하는 데 사용됩니다. URI는 주소를 지정할 필요가 없습니다. 문자열로 처리됩니다. 예를 들어, Contoso University에서 발급한 졸업장 자격 증명은 다음 형식을 선언할 수 있습니다.
| 유형 | 목적 |
|---|---|
https://schema.org/EducationalCredential |
Contoso University에서 발급한 졸업장에 schema.org EducationaCredential 개체가 정의한 속성이 포함됨을 선언합니다. |
https://schemas.ed.gov/universityDiploma2020 |
Contoso University에서 발급한 졸업장에 미국 교육부가 정의한 속성이 포함됨을 선언합니다. |
https://schemas.contoso.edu/diploma2020 |
Contoso University에서 발급한 졸업장에 Contoso University가 정의한 속성이 포함됨을 선언합니다. |
시나리오에 적용할 수 있는 산업별 표준과 스키마 외에도 다음 측면을 고려해야 합니다.
개인 정보 최소화: 필요한 최소한의 개인 정보를 사용하여 사용 사례를 충족합니다. 예를 들어 직원과 졸업생에게 할인을 제공하는 전자상거래 웹 사이트에 사용되는 VC는 자격 증명에 성과 이름 클레임만 제공하여 충족할 수 있습니다. 채용 날짜, 직위, 부서와 같은 추가 정보는 필요하지 않습니다.
추상 클레임 선호: 각 클레임은 세부 정보를 최소화하면서 요구 사항을 충족해야 합니다. 예를 들어 13, 21, 60 등의 불연속 값을 포함하는 "ageOver"라는 클레임은 생년월일 클레임보다 더 추상적입니다.
해지 가능성 계획: 자격 증명을 찾아 해지할 수 있는 메커니즘을 사용하도록 인덱스 클레임을 정의하는 것이 좋습니다. 계약당 하나의 인덱스 클레임을 정의하도록 제한됩니다. 인덱싱된 클레임의 값은 백엔드에 저장되지 않으며, 클레임 값의 해시만 저장된다는 점에 유의해야 합니다. 자세한 내용은 이전에 발급한 확인 가능한 자격 증명 해지를 참조하세요.
자격 증명 특성에 대한 다른 고려 사항은 Verifiable Credentials Data Model 1.0 (w3.org)(확인 가능한 자격 증명 데이터 모델 1.0(w3.org)) 사양을 참조하세요.
품질 특성 계획
성능 계획
모든 솔루션과 마찬가지로 성능을 계획해야 합니다. 중점적으로 다루는 핵심 영역은 대기 시간 및 확장성입니다. 릴리스 주기의 초기 단계에서는 성능이 문제가 되지 않습니다. 그러나 발급 솔루션을 채택하여 확인 가능한 자격 증명이 많이 발급되면 성능 계획이 솔루션의 중요한 부분이 될 수 있습니다.
다음 섹션에서는 성능을 계획할 때 고려해야 할 영역에 대해 설명합니다.
Microsoft Entra 확인된 ID 발급 서비스는 서유럽, 북유럽, 미국 서부 2, 미국 중서부, 오스트레일리아 및 일본 Azure 지역에 배포됩니다. Microsoft Entra 테넌트가 EU 내에 있는 경우 Microsoft Entra Verified ID 서비스도 EU에 배포됩니다.
대기 시간을 제한하려면 이전에 지정한 지역에 발급 프런트엔드 웹사이트 및 키 자격 증명 저장소를 배포합니다.
처리량 기반 모델:
발급자 서비스에는 Azure Key Vault 서비스 제한 사항이 적용됩니다.
Azure Key Vault의 경우 다음과 같은 세 가지 서명 작업이 각 VC 발급에 포함됩니다.
웹사이트에서의 발급 요청 하나
VC 생성에 관련된 하나
계약 다운로드용 한 개
제한을 제어할 수는 없지만 Azure Key Vault 제한 지침을 읽어 보는 것이 좋습니다.
VC의 대규모 롤아웃 및 온보딩을 계획하고 있다면 제한을 초과하지 않도록 VC 만들기를 일괄 처리하는 것이 좋습니다.
성능 계획의 일부로 솔루션의 성능을 보다 잘 이해하기 위해 모니터링할 항목을 결정합니다. 애플리케이션 수준 웹 사이트 모니터링 외에도 VC 발급 모니터링 전략을 정의할 때 다음 사항을 고려하세요.
스케일링 성능을 위해 다음 항목에 대한 메트릭을 구현하는 것이 좋습니다.
발급 프로세스의 논리적 단계를 정의합니다. 예시:
초기 요청
QR 코드 또는 딥 링크 서비스
특성 조회
Microsoft Entra Verified ID 발급 서비스 호출
발급된 자격 증명
단계에 따라 메트릭을 정의합니다.
총 요청 수(볼륨)
시간 단위당 요청(처리량)
소요된 시간(대기 시간)
다음 링크를 사용하여 Azure Key Vault를 모니터링합니다.
비즈니스 논리 계층에 사용되는 구성 요소를 모니터링합니다.
안정성 계획
안정성을 계획하려면 다음을 수행하는 것이 좋습니다.
가용성 및 중복성 목표를 정의한 후 다음 가이드를 사용하여 목표를 달성하는 방법을 파악하세요.
프런트 엔드 및 비즈니스 계층의 경우 솔루션은 여러 가지 방법으로 매니페스트할 수 있습니다. 모든 솔루션과 마찬가지로 식별되는 종속성에 대해 종속성이 복원력 있고 모니터링되는지 확인합니다.
드문 경우지만 Microsoft Entra Verified ID 발급 서비스 또는 Azure Key Vault 서비스를 사용할 수 없게 되면 전체 솔루션을 사용할 수 없게 됩니다.
규정 준수 계획
조직에는 산업, 트랜잭션 유형, 작업 국가/지역과 관련된 특정 규정 준수 요구 사항이 있을 수 있습니다.
데이터 보존: Microsoft Entra Verified ID 발급 서비스는 Azure 지역의 하위 집합에 배포됩니다. 이 서비스는 컴퓨팅 함수에만 사용됩니다. Microsoft는 확인 가능한 자격 증명의 값을 Microsoft 시스템에 저장하지 않습니다. 그러나 VC를 발급할 때 발급 프로세스의 일부로 개인 데이터가 전송되고 사용됩니다. VC 서비스 사용은 데이터 보존 요구 사항에 영향을 주지 않아야 합니다. ID 확인의 일부로 개인 정보를 저장하는 경우 규정 준수 요구 사항을 충족하는 방식과 지역에 저장해야 합니다. Azure 관련 지침은 Microsoft 보안 센터방문하세요.
자격 증명 철회: 조직에서 자격 증명을 철회해야 하는지 결정합니다. 예를 들어 직원이 퇴사하는 경우 관리자가 자격 증명을 해지해야 할 수 있습니다. 자세한 내용은 이전에 발급한 확인 가능한 자격 증명 해지를 참조하세요.
자격 증명 만료: 자격 증명이 만료되는 방식을 결정합니다. 예를 들어 운전 면허증을 증명하기 위해 VC를 발급하는 경우 몇 년 후에 VC가 만료될 수 있습니다. 다른 VC는 사용자가 정기적으로 돌아와 VC를 업데이트하도록 보장하기 위해 더 짧은 유효 기간을 가질 수 있습니다.
작업 계획
작업을 계획할 때는 지원하는 다양한 고객의 문제 해결, 보고, 구분에 사용할 스키마를 개발하는 것이 중요합니다. 또한 운영 팀이 VC 해지 실행을 담당하는 경우 해당 프로세스를 정의해야 합니다. 고유한 각 발급 요청과 연결할 수 있는 로그 항목을 확인할 수 있도록 프로세스의 각 단계를 상호 연결해야 합니다. 감사를 위해 각 자격 증명 발급 시도를 개별적으로 캡처하는 것이 좋습니다. 특별한 사항
고객과 지원 엔지니어가 필요에 따라 참조할 수 있는 고유한 트랜잭션 ID를 생성합니다.
Azure Key Vault 트랜잭션 로그와 솔루션 발급 부분의 트랜잭션 ID를 상호 연결하는 메커니즘을 고안합니다.
여러 고객을 대신하여 VC를 발급하는 신원 확인 서비스인 경우, 고객 대면 보고와 청구를 위해 고객 ID나 계약 ID별로 모니터링하고 문제를 완화합니다.
여러 고객을 대신하여 VC를 발급하는 ID 검증 서비스인 경우 고객 관련 보고 및 청구, 모니터링, 완화를 위해 고객 또는 계약 ID를 사용합니다.
보안 계획
보안에 중점을 둔 디자인 고려 사항의 일부로 다음 항목을 수행하는 것이 좋습니다.
키 관리에 대해:
VC 발급을 위한 전용 Key Vault를 만듭니다. Microsoft Entra Verified ID 발급 서비스 및 발급 서비스 프런트 엔드 웹 사이트 서비스 주체로 Azure Key Vault 권한을 제한합니다.
Azure Key Vault를 권한이 높은 시스템으로 처리합니다. Azure Key Vault는 고객에게 자격 증명을 발급합니다. 사용자 ID에는 Azure Key Vault 서비스에 대한 권한이 없도록 하는 것이 좋습니다. 관리자는 Key Vault에 한 번만 액세스하면 됩니다. Azure Key Vault 사용에 대한 자세한 모범 사례는 Key Vault에 대한 Azure 보안 기준을 참조하세요.
발급 프런트 엔드 웹 사이트를 대표하는 서비스 원장:
Azure Key Vault에 대한 액세스 권한을 부여하는 전용 서비스 주체를 정의합니다. 웹 사이트가 Azure에 있는 경우 Azure 관리 ID를 사용하는 것이 좋습니다.
웹 사이트와 사용자를 나타내는 서비스 주체를 단일 신뢰 경계로 처리합니다. 여러 웹 사이트를 만드는 것이 가능하지만 발급 솔루션에 대한 키 집합은 하나뿐입니다.
보안 로깅 및 모니터링의 경우 다음 항목을 권장합니다.
Azure Key Vault의 로깅 및 경고를 사용하도록 설정하여 자격 증명 발급 작업, 키 추출 시도, 권한 변경을 추적하고 구성 변경에 대한 경고를 모니터링하고 보냅니다. 자세한 내용은 Key Vault 로깅을 사용하도록 설정하는 방법을 참조하세요.
장기 보존을 위해 Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 시스템에 로그를 보관합니다.
다음을 사용하여 스푸핑 위험을 완화합니다.
고객이 발급자 브랜딩을 식별하는 데 도움이 되는 DNS 검증.
최종 사용자에게 의미 있는 도메인 이름.
최종 사용자가 인식하는 신뢰할 수 있는 브랜딩.
DDOS(분산형 서비스 거부) 및 Key Vault 리소스 소모 위험을 완화합니다. VC 발급 요청을 트리거하는 모든 요청은 서비스 제한에 따라 발생하는 Key Vault 서명 작업을 생성합니다. 발급 요청을 생성하기 전에 인증 또는 captcha를 통합하여 트래픽을 보호하는 것이 좋습니다.
Azure 환경 관리에 대한 지침은 Microsoft cloud 보안 벤치마크 및 Microsoft Entra ID를 사용하여 Azure 환경 보호를 참조하세요. 이러한 가이드는 Azure Key Vault, Azure Storage, 웹 사이트, 기타 Azure 관련 서비스 및 기능을 포함하여 기본 Azure 리소스 관리에 대한 모범 사례를 제공합니다.
기타 고려 사항
POC를 완료하면 생성된 모든 정보 및 설명서를 수집하고 발급자 구성을 삭제하는 것이 좋습니다.
Key Vault 구현 및 운영에 대한 자세한 내용은 Key Vault 사용에 대한 모범 사례를 참조하세요. Microsoft Entra ID를 사용하여 Microsoft Entra 테넌트 보안에 대한 자세한 내용은 위임된 관리 및 격리된 환경소개를 참조하세요.