Microsoft Entra Verified ID 확인 솔루션 계획
Microsoft의 Microsoft Entra Verified ID(Microsoft Entra VC) 서비스를 사용하면 신뢰 범위를 확장하지 않고도 사용자 ID 증명을 신뢰할 수 있습니다. Microsoft Entra VC를 사용하면 계정을 만들거나 다른 ID 공급자와 페더레이션할 수 있습니다. 솔루션이 확인 가능한 자격 증명을 사용하여 확인 교환 구현하면 애플리케이션이 특정 도메인에 바인딩되지 않은 자격 증명을 요청할 수 있습니다. 이렇게 하면 대규모 자격 증명을 더 쉽게 요청하고 확인할 수 있습니다.
아직 검토하지 않은 경우 Microsoft Entra Verified ID 아키텍처 개요를 검토하는 것이 좋습니다. 또한 Microsoft Entra Verified ID 발급 솔루션 계획을 검토하려고 합니다.
지침의 범위
이 콘텐츠는 Microsoft 제품 및 서비스를 사용하여 확인 가능한 자격 증명 확인 솔루션을 계획하는 기술적 측면을 설명합니다. 이 솔루션은 현재 DID 웹이 지원되는 신뢰 시스템과 인터페이스합니다. DID 웹은 중앙 집중식 공개 키 인프라입니다.
확인 솔루션과 관련이 없는 지원 기술은 본 문서에서 다루지 않습니다. 예를 들어 웹 사이트는 확인 가능한 자격 증명 확인 솔루션에 사용되지만 웹 사이트 배포 계획은 자세히 다루지 않습니다.
확인 솔루션을 계획할 때 추가되거나 수정되는 비즈니스 기능을 고려해야 합니다. 또한 재사용할 수 있는 IT 기능과 솔루션을 만들기 위해 추가해야 하는 기능을 고려해야 합니다. 또한 업무 프로세스에 관련된 사람들과 솔루션의 최종 사용자 및 직원을 지원하는 사람들에게 어떤 교육이 필요한지도 고려합니다. 이러한 문서는 이 콘텐츠에서 다루지 않습니다. 이러한 문서를 다루는 정보는 Microsoft Azure Well-Architected Framework를 검토하는 것이 좋습니다.
솔루션의 구성 요소
확인 솔루션 계획의 일환으로 검증자, 주체 및 발급자 간의 상호 작용이 가능하도록 설정해야 합니다. 이 문서에서는 신뢰 당사자와 검증자는 같은 의미로 사용됩니다. 다음 다이어그램은 확인 아키텍처의 구성 요소를 보여줍니다.
Microsoft Entra Verified ID 서비스
검증자 솔루션의 컨텍스트에서 Microsoft Entra Verified ID 서비스는 솔루션의 Microsoft 구성 요소와 신뢰 시스템 간의 인터페이스입니다. 이 서비스는 키 집합을 Key Vault로 프로비전하고, DID(탈중앙화 식별자)를 프로비전합니다.
Microsoft Entra 테넌트
서비스에는 솔루션의 일부인 Azure 리소스에 대한 IAM(Identity and Access Management) 컨트롤 플레인을 제공하는 Microsoft Entra 테넌트가 필요합니다. 각 Microsoft Entra 테넌트는 다중 테넌트 Microsoft Entra Verified ID 서비스를 사용하며 검증자를 나타내는 단일 DID 문서를 발급합니다. 확인 서비스를 사용하는 신뢰 당사자가 여러 개 있는 경우 모두 동일한 검증자 DID를 사용합니다. 검증자 DID는 주체 및 발급자가 신뢰 당사자로부터 오는 메시지의 유효성을 검사할 수 있는 공개 키에 대한 포인터를 제공합니다.
Azure Key Vault
Azure Key Vault 서비스는 Microsoft Entra Verified ID 발급 서비스를 사용하도록 설정할 때 생성되는 검증자 키를 저장합니다. 이 키는 메시지 보안을 제공하는 데 사용됩니다. 각 검증자는 VC 서명, 업데이트 및 복구에 사용되는 단일 키 집합이 있습니다. 이 키 집합은 확인 요청을 처리할 때마다 사용됩니다. Microsoft 키 집합은 현재 ECC(타원 곡선 암호화) SECP256k1을 사용합니다. 당사는 더 광범위한 DID 커뮤니티에서 채택하는 다른 암호화 서명 스키마를 탐색하고 있습니다.
요청 서비스 API
API(애플리케이션 프로그래밍 인터페이스)는 개발자에게 솔루션 구성 요소 간의 상호 작용을 추상화하여 확인 작업을 실행하는 방법을 제공합니다.
신뢰 시스템
Microsoft Entra Verified ID는 현재 DID 문서가 발급자 웹 서버에서 호스트되는 신뢰 시스템으로 DID 웹을 지원합니다.
Microsoft Authenticator 애플리케이션
Microsoft Authenticator는 모바일 애플리케이션입니다. 인증자는 사용자, Microsoft Entra Verified ID 서비스 및 VC 발급에 사용되는 계약 간의 상호 작용을 오케스트레이션합니다. 이 애플리케이션은 VC 주체의 프라이빗 키를 포함하여 VC 소유자가 VC를 저장하는 디지털 지갑 역할을 합니다. Authenticator는 검증을 위해 VC를 제공하는 데 사용되는 메커니즘이기도 합니다.
RP(신뢰 당사자)
웹 프런트 엔드
신뢰 당사자 웹 프런트 엔드는 요청 서비스 API를 사용하여 주체의 전자 지갑이 사용하는 딥 링크 또는 QR 코드를 생성하여 VC를 확인합니다. 시나리오에 따라 프런트 엔드는 공개적으로 액세스할 수 있거나 확인이 필요한 최종 사용자 경험이 가능한 내부 웹사이트일 수 있습니다. 하지만, 지갑이 액세스하는 엔드포인트는 공개적으로 액세스할 수 있어야 합니다. 특히 특정 요청 매개변수를 사용하여 지갑으로의 리디렉션을 제어합니다.
비즈니스 논리
새 논리를 만들거나 신뢰 당사자와 관련된 기존 논리를 사용하고 VC 프레젠테이션을 통해 해당 논리를 향상시킬 수 있습니다.
시나리오별 디자인
다음은 특정 사용 사례를 충족하기 위한 디자인의 예입니다. 첫 번째는 계정 온보딩용이며, 새 직원 온보딩과 관련된 시간, 비용 및 위험을 줄이는 데 사용됩니다. 두 번째는 계정 복구용이며, 최종 사용자가 셀프 서비스 메커니즘을 사용하여 자신의 계정을 복구하거나 잠금 해제할 수 있습니다. 세 번째는 고가치 애플리케이션 및 리소스에 액세스하기 위한 것이며, 특히 다른 회사에서 근무하는 사람에게 액세스 권한이 부여되는 B2B(Business to Business) 사용 사례에 적합합니다.
계정 온보딩
확인 가능한 자격 증명을 사용하면 일부 사용자 상호 작용을 대체하여 온보딩 속도를 높일 수 있습니다. VC는 직원, 학생, 시민 또는 다른 사람이 서비스에 액세스하도록 온보딩하는 데 사용할 수 있습니다. 예를 들어 직원이 직원 배지를 활성화하기 위해 중앙 사무실에 가는 대신 자신의 신원을 확인하는 VC를 사용하여 원격으로 전달된 배지를 활성화할 수 있습니다. 시민이 정부 서비스에 액세스하기 위해 사용해야 하는 코드를 받는 대신 VC를 사용하여 자신의 신원을 증명하고 액세스 권한을 얻을 수 있습니다.
기타 요소
온보딩 포털: VC 프레젠테이션 및 유효성 검사에 대한 요청 서비스 API 호출과 계정을 온보딩하는 논리를 오케스트레이션하는 웹 프런트 엔드입니다.
사용자 지정 논리/워크플로: 사용자 계정을 업데이트하기 전과 후에 조직별 단계가 있는 특정 논리입니다. 예에는 승인 워크플로, 기타 유효성 검사, 로깅, 알림 등이 포함될 수 있습니다.
대상 ID 시스템: 온보딩 포털에서 주체를 온보딩하는 동안 상호 작용해야 하는 조직별 ID 리포지토리입니다. 통합할 시스템은 VC 유효성 검사를 사용하여 온보딩하려는 ID의 종류에 따라 결정됩니다. 온보딩을 위한 ID 검증의 일반적인 시나리오는 다음과 같습니다.
B2B(Business-to-Business) 초대 또는 패키지에 대한 권한 관리 할당을 발급하기 위해 API를 사용하여 Microsoft Entra ID가 탑재된 외부 ID입니다.
중앙 집중식 ID 시스템의 직원 ID는 HR(인사 관리) 시스템을 통해 이미 온보딩되어 있습니다. 이 경우 ID 검증은 기존 HR 워크플로 단계의 일부로 통합될 수 있습니다.
디자인 고려 사항
발급자: 계정 온보딩은 VC의 발급자로 외부 ID 증명 서비스에 적합합니다. 온보딩 확인의 예로는 활동성 검사, 정부에서 발급한 문서 유효성 검사, 주소 또는 전화번호 확인 등이 있습니다.
VC 특성 저장: 가능한 경우 앱별 저장소에 VC의 속성을 저장하지 않습니다. 특히 개인 데이터에 주의해야 합니다. 애플리케이션 내의 특정 흐름에 이 정보가 필요한 경우 필요에 따라 클레임을 검색하도록 VC에 요청하는 것이 좋습니다.
백 엔드 시스템과 VC 특성 상관 관계: 발급자를 사용하여 VC의 특성을 정의할 때 사용자가 VC를 제출한 후 백 엔드 시스템의 정보를 상호 연관시키는 메커니즘을 설정합니다. 일반적으로 RP 컨텍스트에서 시간 제한이 있는 고유 식별자를 수신한 클레임과 함께 사용합니다. 몇 가지 예:
신규 직원: HR 워크플로가 ID 확인이 필요한 지점에 도달하면 RP는 시간 제한이 있는 고유 식별자가 있는 링크를 생성할 수 있습니다. 그런 다음, RP는 이를 HR 시스템에 있는 후보 이메일 주소로 보냅니다. 이 고유 식별자는 VC 확인 요청의 firstName, lastName과 같은 정보를 HR 레코드 또는 기본 데이터와 상호 연관시키기에 충분해야 합니다. VC의 특성을 사용하여 HR 시스템에서 사용자 특성을 완성하거나 직원에 대한 사용자 특성의 정확성을 검증할 수 있습니다.
외부 ID - 초대: 외부 사용자가 대상 시스템에 초대되면 RP는 초대 트랜잭션을 나타내는 고유 식별자가 있는 링크를 생성할 수 있습니다. 이 링크는 외부 사용자의 이메일 주소로 전송될 수 있습니다. 이 고유 식별자는 VC 확인 요청을 초대 레코드 또는 기본 데이터와 상호 연결하고 프로비전 워크플로를 계속 진행하기에 충분해야 합니다. VC의 특성을 사용하여 외부 사용자 특성의 유효성을 검사하거나 완료할 수 있습니다.
외부 ID - 셀프 서비스: 외부 ID가 셀프 서비스(예: B2C 애플리케이션)를 통해 대상 시스템에 등록하는 경우 VC의 특성을 사용하여 사용자 계정의 초기 특성을 채울 수 있습니다. VC 특성을 사용하여 프로필이 이미 존재하는지 확인할 수도 있습니다.
대상 ID 시스템과의 상호 작용: 웹 프런트 엔드와 대상 ID 시스템 사이의 서비스 간 통신은 계정을 만들 수 있으므로 높은 권한이 있는 시스템으로 보호되어야 합니다. 웹 프런트 엔드에 가능한 최소 권한이 있는 역할을 부여합니다. 예는 다음과 같습니다.
Microsoft Entra ID에서 새 사용자를 만들기 위해 RP 웹 사이트는 MS Graph 범위
User.ReadWrite.All이 부여된 서비스 주체를 사용하여 사용자를 만들고 범위UserAuthenticationMethod.ReadWrite.All을 사용하여 인증 방법을 초기화할 수 있습니다.B2B 협업을 사용하여 Microsoft Entra ID에 사용자를 초대하기 위해 RP 웹 사이트는
User.Invite.All의 MS Graph 범위가 부여된 서비스 주체를 사용하여 초대를 만들 수 있습니다.RP가 Azure에서 실행되는 경우 관리 ID를 사용하여 Microsoft Graph를 호출합니다. 관리 ID를 사용하면 코드 또는 구성 파일에서 서비스 주체 자격 증명을 관리할 위험이 제거됩니다. 관리 ID에 대한 자세한 내용은 Azure 리소스에 대한 관리 ID를 참조하세요.
조직 내부의 고가치 애플리케이션에 액세스
확인 가능한 자격 증명은 조직 내부의 중요한 애플리케이션에 액세스하기 위한 추가 증명으로 사용할 수 있습니다. 예를 들어 VC를 사용하여 직원에게 인증과 같은 특정 기준을 달성하면 LOB(기간 업무) 애플리케이션에 대한 액세스 권한을 제공할 수도 있습니다.
기타 요소
신뢰 당사자 웹 프런트 엔드: 비즈니스 요구 사항에 따라 VC 프레젠테이션 및 유효성 검사를 위한 요청 서비스 API 호출을 통해 향상되는 애플리케이션의 웹 프런트 엔드입니다.
사용자 액세스 권한 부여 논리: 사용자 액세스 권한을 부여하고 VC 내에서 사용자 특성을 사용하여 권한 부여 결정을 내릴 수 있도록 향상된 애플리케이션의 논리 계층입니다.
기타 백 엔드 서비스 및 종속성: 애플리케이션의 나머지 논리를 나타내며, 일반적으로 VC를 통한 ID 증명을 포함해도 변경되지 않습니다.
디자인 고려 사항
목표: 시나리오의 목표에 따라 필요한 자격 증명 및 발급자의 종류가 결정됩니다. 일반적인 시나리오는 다음이 포함됩니다.
권한 부여: 이 시나리오에서 사용자는 권한 부여 결정을 내리기 위해 VC를 제시합니다. 학습 완료 또는 특정 인증 보유를 증명하기 위해 설계된 VC가 이 시나리오에 적합합니다. VC 특성은 권한 부여 결정 및 감사에 도움이 되는 세분화된 정보를 포함해야 합니다. 예를 들어, VC는 개인이 학습을 받았고 중요한 재무 앱에 액세스할 수 있음을 인증하는 데 사용됩니다. 앱 논리는 세분화된 권한 부여를 위해 부서 클레임을 확인하고 감사 목적으로 직원 ID를 사용할 수 있습니다.
ID 검증 확인: 이 시나리오에서 목표는 처음에 온보딩한 사람이 실제로 고가치 애플리케이션에 액세스하려고 시도하는 동일한 사람인지 확인하는 것입니다. ID 검증 발급자의 자격 증명이 적합할 것입니다. 애플리케이션 로직은 VC의 특성이 애플리케이션에 로그인한 사용자와 일치하는지 유효성을 검사해야 합니다.
해지 확인: VC를 사용하여 중요한 리소스에 액세스할 때는 원래 발급자와 VC의 상태를 확인하고 해지된 VC에 대한 액세스를 거부하는 것이 일반적입니다. 발급자와 작업할 때는 해지가 시나리오 디자인의 일부로 명시적으로 논의되었는지 확인합니다.
사용자 환경: VC를 사용하여 중요한 리소스에 액세스하는 경우 두 가지 패턴을 고려할 수 있습니다.
단계별 인증: 사용자는 기존 인증 메커니즘을 통해 애플리케이션으로 세션을 시작합니다. 사용자는 애플리케이션 내에서 특정 고가치 작업(예: 비즈니스 워크플로 승인)을 위한 VC를 제시해야 합니다. 애플리케이션 흐름 내에서 이러한 고가치 작업을 쉽게 식별하고 업데이트할 수 있는 시나리오에 적합합니다.
세션 설정: 사용자는 애플리케이션으로 세션을 시작하는 과정의 일부로 VC를 제시해야 합니다. VC를 제시하는 것은 전체 애플리케이션의 특성이 높은 가치인 경우에 적합합니다.
조직 경계 외부의 애플리케이션에 액세스
확인 가능한 자격 증명은 다른 조직의 고용 관계 또는 멤버 자격에 따라 액세스 또는 혜택을 부여하려는 신뢰 당사자도 사용할 수도 있습니다. 예를 들어 전자 상거래 포털은 특정 회사의 직원, 지정된 기관의 학생에 대한 할인 등과 같은 혜택을 제공할 수 있습니다.
확인 가능한 자격 증명의 탈중앙화 특성 덕분에 페더레이션 관계를 설정하지 않고도 이런 시나리오가 가능합니다.
기타 요소
신뢰 당사자 웹 프런트 엔드: 비즈니스 요구 사항에 따라 VC 프레젠테이션 및 유효성 검사를 위한 요청 서비스 API 호출을 통해 향상되는 애플리케이션의 웹 프런트 엔드입니다.
사용자 액세스 권한 부여 논리: 사용자 액세스 권한을 부여하고 VC 내에서 사용자 특성을 사용하여 권한 부여 결정을 내릴 수 있도록 향상된 애플리케이션의 논리 계층입니다.
기타 백 엔드 서비스 및 종속성: 애플리케이션의 나머지 논리를 나타내며, 일반적으로 VC를 통한 ID 증명을 포함해도 변경되지 않습니다.
디자인 고려 사항
목표: 시나리오의 목표에 따라 필요한 자격 증명 및 발급자의 종류가 결정됩니다. 일반적인 시나리오는 다음이 포함됩니다.
인증: 이 시나리오에서 사용자는 특정 조직과의 고용 또는 관계를 증명하기 위해 VC를 소유해야 합니다. 이 경우 대상 조직에서 발급한 VC를 허용하도록 RP를 구성해야 합니다.
권한 부여: 애플리케이션 요구 사항에 따라 애플리케이션은 세분화된 권한 부여 결정 및 감사를 위해 VC 특성을 사용할 수 있습니다. 예를 들어, 전자상거래 웹 사이트가 특정 위치에 있는 조직의 직원에게 할인을 제공하는 경우 VC(있는 경우)의 국가/지역 클레임을 기반으로 할인 자격의 유효성을 검사할 수 있습니다.
해지 확인: VC를 사용하여 중요한 리소스에 액세스할 때는 원래 발급자와 VC의 상태를 확인하고 해지된 VC에 대한 액세스를 거부하는 것이 일반적입니다. 발급자와 작업할 때는 해지가 시나리오 디자인의 일부로 명시적으로 논의되었는지 확인합니다.
사용자 환경: 사용자는 애플리케이션으로 세션을 시작하는 과정의 일환으로 VC를 제시할 수 있습니다. 일반적으로 애플리케이션은 사용자에게 VC가 없는 경우를 수용하기 위해 세션을 시작하는 대체 메서드도 제공합니다.
계정 복구
확인 가능한 자격 증명은 계정 복구를 위한 방식으로 사용할 수 있습니다. 예를 들어 사용자가 계정을 복구해야 하는 경우 다음 다이어그램과 같이 MS Graph API를 호출하여 VC를 제시하고 Microsoft Entra ID 자격 증명 재설정을 시작해야 하는 웹 사이트에 액세스할 수 있습니다.
참고 항목
이 섹션에서 설명하는 시나리오는 Microsoft Entra 계정 복구에만 적용되지만 이 방식은 다른 시스템의 계정을 복구하는 데에도 사용할 수 있습니다.
기타 요소
계정 포털: VC 프레젠테이션 및 유효성 검사를 위해 API 호출을 오케스트레이션하는 웹 프런트 엔드입니다. 이 오케스트레이션에는 Microsoft Entra ID의 계정을 복구하기 위한 Microsoft Graph 호출이 포함될 수 있습니다.
사용자 지정 논리 또는 워크플로: 사용자 계정을 업데이트하기 전과 후에 조직별 단계가 있는 논리입니다. 사용자 지정 논리에는 승인 워크플로, 기타 유효성 검사, 로깅, 알림 등이 포함될 수 있습니다.
Microsoft Graph: REST(Representational State Transfer) API와 클라이언트 라이브러리를 노출하여 계정 복구를 수행하는 데 사용되는 Microsoft Entra 데이터에 액세스합니다.
Microsoft Entra 엔터프라이즈 디렉터리: 계정 포털을 통해 만들어지거나 업데이트되는 계정이 포함된 Microsoft Entra 테넌트입니다.
디자인 고려 사항
Microsoft Entra ID와 VC 특성 상관 관계: 발급자와 협력하여 VC 특성을 정의할 때 사용자를 식별하는 클레임에 동의하는지 확인합니다. 예를 들어, IDV(ID 검증 공급자)가 직원을 온보딩하기 전에 ID를 확인하는 경우 발급된 VC에 내부 시스템과 일치할 수 있는 클레임이 포함되어 있는지 확인합니다. 이러한 클레임에는 전화번호, 주소 또는 생년월일이 포함될 수 있습니다. RP는 이 프로세스의 일부로 SSN(사회 보장 번호)의 마지막 4자리와 같이 VC에서 찾을 수 없는 정보를 요청할 수 있습니다.
기존 Microsoft Entra 자격 증명 초기화 기능을 갖춘 VC의 역할: Microsoft Entra ID에는 SSPR(셀프 서비스 암호 재설정) 기능이 기본 제공되어 있습니다. 확인 가능한 자격 증명은 사용자가 SSPR 방법에 액세스할 수 없거나 제어할 수 없는 경우 복구할 수 있는 또 다른 방법을 제공하는 데 사용될 수 있습니다. 사용자가 컴퓨터와 모바일을 모두 분실한 경우 사용자는 ID 증명 발급자로부터 VC를 다시 가져와 이를 제시하여 원격으로 계정을 복구할 수 있습니다.
마찬가지로 VC를 사용하여 임시 액세스 패스를 생성할 수 있습니다. 이것을 사용하면 사용자가 암호 없이 MFA 인증 방법을 재설정할 수 있습니다.
권한 부여: 자격 증명 복구를 진행하기 전에 RP가 확인하는 보안 그룹과 같은 권한 부여 메커니즘을 만듭니다. 예를 들어 특정 그룹의 사용자만 VC를 사용하여 계정을 복구할 수 있습니다.
Microsoft Entra ID와의 상호 작용: 웹 프런트 엔드와 Microsoft Entra ID 간의 서비스 간 통신은 직원의 자격 증명을 초기화할 수 있으므로 높은 권한의 시스템으로 보호되어야 합니다. 웹 프런트 엔드에 가능한 최소 권한이 있는 역할을 부여합니다. 예는 다음과 같습니다.
인증 방법을 재설정하는 MS Graph 범위
UserAuthenticationMethod.ReadWrite.All이 부여된 서비스 주체를 사용할 수 있는 기능을 RP 웹 사이트에 부여합니다. 사용자를 만들고 삭제할 수 있는User.ReadWrite.All은 부여하지 마세요.RP가 Azure에서 실행되는 경우 관리 ID를 사용하여 Microsoft Graph를 호출합니다. 관리 ID는 코드 또는 구성 파일에서 서비스 주체 자격 증명 관리와 관련된 위험을 제거합니다. 자세한 내용은 Azure 리소스에 대한 ID 관리를 참조하세요.
ID 관리 계획
다음은 VC를 신뢰 당사자에 통합할 때 IAM 고려 사항입니다. 신뢰 당사자는 일반적으로 애플리케이션입니다.
인증
VC의 주제는 사람이어야 합니다.
사용자는 전자 지갑에 VC를 가지고 있으며 대화형으로 VC를 제시해야 합니다. 위임과 같은 비대화형 흐름은 지원되지 않습니다.
Authorization
성공적인 VC 프레젠테이션은 그 자체로 정교하지 않은 권한 부여 게이트로 간주될 수 있습니다. VC 특성은 세분화된 권한 부여 결정에 사용될 수도 있습니다.
만료된 VC가 애플리케이션에서 의미가 있는지 확인합니다. 의미가 있으면 권한 부여 검사의 일환으로 VC의
exp클레임(만료 시간) 값을 확인합니다. 만료가 관련이 없는 한 가지 예는 주체가 18세를 초과하는지 확인하기 위해 운전면허증과 같은 정부 발행 문서를 요구하는 것입니다. VC가 만료된 경우에도 생년월일 클레임은 유효합니다.해지된 VC가 권한 부여 결정에 의미가 있는지 확인합니다.
관련이 없는 경우 상태 API 확인 호출을 건너뜁니다(기본적으로 켜져 있음).
관련이 있으면 애플리케이션에서 적절한 예외 처리를 추가합니다.
사용자 프로필
제시된 VC의 정보를 사용하여 사용자 프로필을 빌드할 수 있습니다. 특성을 사용하여 프로필을 빌드하려면 다음 항목을 고려하세요.
VC가 발급되면 발급 시 특성의 스냅샷이 포함됩니다. VC는 유효 기간이 길 수 있으며 프로필의 일부로 사용할 만큼 충분히 새로운 것으로 인정할 수 있는 특성의 보존 기간을 결정해야 합니다.
주체가 RP와의 세션을 시작할 때마다 VC를 제시해야 하는 경우에는 VC 프레젠테이션의 출력을 사용하여 특성이 있는 비영구적인 사용자 프로필을 빌드하는 것이 좋습니다. 비영구 사용자 프로필은 미사용 사용자 속성 저장과 관련된 개인 정보 보호 위험을 줄이는 데 도움이 됩니다. 애플리케이션은 주체의 특성을 로컬에 저장해야 할 수도 있습니다. 그렇다면 애플리케이션에 필요한 클레임만 저장합니다. 전체 VC를 저장하지 마세요.
애플리케이션에 영구적인 사용자 프로필 저장소가 필요한 경우:
sub클레임을 사용자의 변경이 불가능한 식별자로 사용하는 것이 좋습니다. 이는 지정된 주체/RP 쌍에 대해 일정한 불투명 고유 특성입니다.애플리케이션에서 사용자 프로필의 프로비전을 해제하는 메커니즘을 정의합니다. Microsoft Entra Verified ID 시스템의 탈중앙화 특성으로 인해 애플리케이션 사용자 프로비저닝 수명 주기가 없습니다.
VC 토큰에 반환된 개인 데이터 클레임을 저장하지 마세요.
신뢰 당사자의 논리에 필요한 클레임만 저장합니다.
성능 계획
모든 솔루션과 마찬가지로 성능을 계획해야 합니다. 주요 영역에는 대기 시간, 처리량 및 확장성이 포함됩니다. 릴리스 주기의 초기 단계에서는 성능이 문제가 되지 않습니다. 그러나 솔루션을 채택하여 확인 가능한 자격 증명이 많이 확인되면 성능 계획이 솔루션의 중요한 부분이 될 수 있습니다.
다음 항목은 성능을 계획할 때 고려해야 할 영역을 제공합니다.
Microsoft Entra Verified ID 발급 서비스는 서유럽, 북유럽, 미국 서부 2 및 미국 중서부 Azure 지역에 배포됩니다. 대기 시간을 제한하려면 가장 가까운 지역에 확인 프런트 엔드(웹 사이트)와 키 자격 증명 모음을 배포합니다.
처리량 기반 모델:
VC 확인 용량에는 Azure Key Vault 서비스 제한이 적용됩니다.
VC를 확인할 때마다 하나의 Key Vault 서명 작업이 필요합니다.
제한을 제어할 수는 없지만 제한이 성능에 미치는 영향을 이해할 수 있도록 Azure Key Vault 제한 지침을 읽어 보는 것이 좋습니다.
안정성 계획
고가용성 및 재해 복구를 위한 최상의 계획을 위해 다음 항목을 권장합니다.
Microsoft Entra Verified ID 서비스는 서유럽, 북유럽, 미국 서부 2, 미국 중서부, 오스트레일리아 및 일본 Azure 지역에 배포됩니다. 이러한 지역 중 한 곳(특히 대부분의 유효성 검사 트래픽이 발생할 것으로 예상되는 곳)에 지원 웹 서버 및 지원 애플리케이션을 배포하는 것이 좋습니다.
가용성 및 중복성 목표를 위해 설계하면서 Azure Key Vault 가용성 및 중복성의 모범 사례를 검토하고 결합합니다.
보안 계획
보안을 설계할 때 다음 사항을 고려합니다.
단일 테넌트의 모든 RP(신뢰 당사자)는 동일한 DID를 공유하기 때문에 동일한 신뢰 경계를 갖습니다.
Key Vault에 액세스하는 웹 사이트의 전용 서비스 주체를 정의합니다.
Microsoft Entra Verified ID 서비스 및 웹 사이트 서비스 주체만 Key Vault를 사용하여 프라이빗 키로 메시지에 서명할 수 있는 권한이 있어야 합니다.
사람 ID 관리 권한을 Key Vault에 할당하지 마세요. Key Vault 모범 사례에 대한 자세한 내용은 Key Vault에 대한 Azure 보안 기준을 참조하세요.
솔루션 지원 서비스 관리에 대한 모범 사례는 Microsoft Entra ID로 Azure 환경 보호를 검토합니다.
다음을 수행하여 스푸핑 위험을 완화합니다.
고객이 발급자 브랜딩을 식별하는 데 도움이 되는 DNS 확인을 구현합니다.
최종 사용자에게 의미 있는 도메인을 사용합니다.
DDOS(분산형 서비스 거부) 및 Key Vault 리소스 제한 위험을 완화합니다. 모든 VC 프레젠테이션 요청은 서비스 제한에 대해 누적되는 Key Vault 서명 작업을 생성합니다. 발급 요청을 생성하기 전에 대체 인증 또는 captcha를 통합하여 트래픽을 보호하는 것이 좋습니다.
작업 계획
작업을 계획할 때 감사의 일부로 자격 증명 유효성 검사의 각 시도를 캡처하도록 계획하는 것이 좋습니다. 이런 정보를 감사 및 문제 해결에 사용합니다. 또한 고객 및 지원 엔지니어가 필요한 경우 참조할 수 있는 고유한 트랜잭션 식별자(ID)를 생성하는 것이 좋습니다.
운영 계획의 일환으로 다음을 모니터링하는 것이 좋습니다.
확장성을 위해:
애플리케이션의 엔드투엔드 보안 메트릭의 일부로 실패한 VC 유효성 검사를 모니터링합니다.
자격 증명 확인의 엔드투엔드 대기 시간을 모니터링합니다.
안정성 및 종속성을 위해:
확인 솔루션에서 사용하는 기본 종속성을 모니터링합니다.
Azure Key Vault 모니터링 및 경고를 따릅니다.
보안을 위해:
Key Vault 대한 로깅을 사용하도록 설정하여 서명 작업을 추적하고 구성 변경 내용을 모니터링하고 경고합니다. 자세한 내용은 Key Vault 로깅을 사용하도록 설정하는 방법을 참조하세요.
장기 보존을 위해 Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 시스템에 로그를 보관합니다.
다음 단계
VC 솔루션 설계에 대해 자세히 알아보기
확인 가능한 자격 증명 구현