Planificación de la solución de emisión de Verified ID de Microsoft Entra
Es importante planear la solución de emisión para que, además de generar las credenciales, tenga una vista completa del impacto de la solución en la arquitectura y el negocio. Si aún no lo ha hecho, le recomendamos consultar la introducción a la arquitectura de Id. verificada por Microsoft Entra para obtener información básica.
Ámbito de la guía
Este artículo aborda los aspectos técnicos del planeamiento de una solución de emisión de credenciales verificables. La solución de Microsoft para credenciales verificables sigue los estándares Verifiable Credentials Data Model 1.0 y Decentralized Identifiers (DID) V1.0 de World Wide Web Consortium (W3C), por lo que puede interoperar con servicios que no son de Microsoft. Aun así, los ejemplos de este contenido reflejan la pila de soluciones de Microsoft para las credenciales verificables.
Quedan fuera del ámbito de este contenido los artículos relacionados con tecnologías complementarias que no son específicas de las soluciones de emisión. Por ejemplo, se usan sitios web en una solución de emisión de credenciales verificables, pero la planeación de la implementación de un sitio web no se trata en detalle.
Componentes de la solución
Como parte del plan de la solución de emisión, debe diseñar una solución que permita las interacciones entre el emisor, el usuario y el comprobador. En el diagrama siguiente se muestran los componentes de la arquitectura de emisión.
Arquitectura de la solución de emisión de credenciales verificables de Microsoft
Inquilino de Microsoft Entra
Un requisito previo para ejecutar el servicio de Id. verificada por Microsoft Entra es que se hospede en un inquilino de Microsoft Entra. El inquilino de Microsoft Entra proporciona un plano de control de Administración de identidades y acceso (IAM) para los recursos de Azure que forman parte de la solución.
Cada inquilino usa el servicio multiinquilino Microsoft Entra Verified ID y tiene un identificador descentralizado (DID). El DID proporciona una prueba de que el emisor posee el dominio incorporado en el DID. El firmante y el comprobador usan el DID para validar el emisor.
Servicios de Microsoft Azure
El servicio de Azure Key Vault almacena las claves del emisor, que se generan al iniciar el servicio de emisión de Id. verificada de Microsoft Entra. Las claves y los metadatos se usan para ejecutar operaciones de administración de credenciales y proporcionar seguridad para los mensajes.
Cada emisor tiene un único conjunto de claves que se usa para la firma, la actualización y la recuperación. Este conjunto de claves se usa para cada emisión de una credencial verificable que se genere.
El servicio de Id. verificada por Microsoft Entra se usa para almacenar definiciones y metadatos de credenciales, en concreto, las definiciones de reglas y visualización de las credenciales.
Las definiciones de visualización determinan cómo se mostrarán las notificaciones en la cartera del titular y también incluyen la personalización de marca y otros elementos. La definición de pantalla se puede traducir a varios idiomas. Consulte Procedimiento para personalizar las credenciales verificables.
Las reglas son un modelo definido por el emisor que describe las entradas requeridas de una credencial verificable. Las reglas también definieron orígenes de entrada de confianza y la asignación de notificaciones de entrada a notificaciones de salida almacenadas en la credencial verificable. Según el tipo de atestación definida en la definición de reglas, las notificaciones de entrada pueden proceder de distintos proveedores. Las notificaciones de entrada pueden provenir de un proveedor de identidades OIDC, de una id_token_hint o de notificaciones autoafirmadas durante la emisión mediante la entrada de un usuario en la cartera.
- Entrada: subconjunto del modelo en el archivo de reglas para el consumo del cliente. El subconjunto debe describir el conjunto de entradas, dónde se obtienen las entradas y el punto de conexión al que se va a llamar para obtener una credencial verificable.
Servicio de Id. verificada por Microsoft Entra
El servicio de Id. verificada por Microsoft Entra permite emitir y revocar credenciales verificables en función de su configuración. El servicio:
Proporciona el identificador descentralizado (DID). Cada emisor tiene un solo DID por inquilino.
Aprovisiona conjuntos de claves para Key Vault.
Almacena los metadatos de configuración utilizados por el servicio de emisión y Microsoft Authenticator.
Proporciona la interfaz de API de REST para los front-end web emisores y comprobadores
Sistema de confianza
Actualmente, Microsoft Entra Verified ID admite la Web como DID Web de sistema de confianza. El documento DID se hospeda en el servidor web de los emisores.
Aplicación Microsoft Authenticator
Microsoft Authenticator es la aplicación móvil. El autenticador organiza las interacciones entre el usuario, el servicio de Microsoft Entra Verified ID y el contrato que se usa para emitir VC. Actúa como una cartera digital en la que el titular de la credencial verificable almacena la credencial en cuestión, incluida la clave privada de su firmante. Authenticator es también el mecanismo que se usa para presentar las credenciales verificables para su comprobación.
Lógica de negocios de la emisión
La solución de emisión incluye un front-end web donde los usuarios solicitan una credencial verificable, un almacén de identidades y otro almacén de atributos donde obtener los valores para las notificaciones sobre el firmante y otros servicios de back-end.
Un front-end web sirve las solicitudes de emisión a la cartera del firmante mediante la generación de vínculos profundos o códigos QR. En función de la configuración del contrato, podrían necesitarse otros componentes a fin de satisfacer los requisitos para crear una credencial verificable.
Estos servicios proporcionan funciones auxiliares que no tienen que integrarse necesariamente con el servicio de emisión de Microsoft Entra Verified ID. Esta capa normalmente incluye lo siguiente:
Se usan uno o varios servicios compatibles con Open ID Connect (OIDC) para obtener los id_tokens necesarios para emitir la credencial verificable. Los sistemas de identidad existentes, como Microsoft Entra ID o Azure AD B2C, pueden proporcionar el servicio compatible con OIDC, al igual que soluciones personalizadas como Identity Server.
Almacenes de atributos: los almacenes de atributos pueden estar fuera de los servicios de directorio y proporcionar los atributos necesarios para emitir una credencial verificable. Por ejemplo, un sistema de información para alumnos podría proporcionar notificaciones sobre los títulos obtenidos.
Servicios adicionales de nivel intermedio que contienen reglas de negocio para búsquedas, validación, facturación y cualquier otra comprobación en tiempo de ejecución, así como los flujos de trabajo necesarios para emitir credenciales.
Para obtener más información sobre cómo configurar el front-end web, consulte el tutorial Configuración de Microsoft Entra ID para emitir credenciales verificables.
Consideraciones sobre el diseño de credenciales
Los casos de uso específicos determinan el diseño de credenciales. El caso de uso determina:
Los requisitos de interoperabilidad
la manera en que los usuarios tienen que demostrar su identidad para obtener su credencial verificable
Las notificaciones necesarias en las credenciales
si es necesario revocar las credenciales
Casos de uso de las credenciales
Mediante el servicio de Id. verificada por Microsoft Entra, estos son los casos de uso de credenciales más comunes:
Verificación de identidad: se emite una credencial en función de varios criterios. Esto puede incluir varios criterios, como la comprobación de la autenticidad de documentos emitidos por el gobierno, como un pasaporte o un permiso de conducir, y la asociación de la información de dicho documento con otra información, por ejemplo:
Una foto del usuario
Una comprobación de vida
Este tipo de credencial es una buena opción para escenarios de incorporación de identidades de nuevos empleados, asociados, proveedores de servicios, alumnos y otras instancias en las que la comprobación de la identidad es esencial.
Prueba de relación laboral o pertenencia: se emite una credencial para demostrar una relación entre el usuario y una institución. Este tipo de credencial es una buena opción para acceder a aplicaciones de negocio a negocio de acoplamiento flexible, como minoristas que ofrecen descuentos a empleados o alumnos. Uno de los valores principales de las credenciales verificables es su portabilidad: una vez que se ha emitido una credencial verificable, el usuario puede usarla en muchos escenarios.
Para conocer más casos de uso, consulte Casos de uso de credenciales verificables (w3.org).
Interoperabilidad de las credenciales
Como parte del proceso de diseño, investigue los esquemas, los espacios de nombres y los identificadores específicos del sector con los que puede alinearse para maximizar la interoperabilidad y el uso. Encontrará ejemplos en Schema.org y en el grupo de trabajo sobre notificaciones y credenciales de DIF.
Tenga en cuenta que los esquemas comunes constituyen un área en la que todavía surgen estándares. Un ejemplo de este tipo de esfuerzo es el grupo de trabajo sobre las credenciales verificables para la educación. Le recomendamos que investigue y que realice su contribución a los estándares emergentes en el sector al que pertenece su organización.
Tipo de credencial y atributos
Después de establecer el caso de uso de una credencial, debe determinar el tipo de credencial y los atributos que se incluirán. Los comprobadores pueden leer las notificaciones en la credencial verificable que presentan los usuarios.
Todas las credenciales verificables deben indicar el tipo en la definición de reglas. El tipo de credencial diferencia un esquema de credenciales verificables de otras credenciales y garantiza la interoperabilidad entre emisores y comprobadores. Para indicar un tipo de credencial, debe proporcionar uno o varios tipos de credenciales a los que responda la credencial. Cada tipo es una cadena única. A menudo, se usa un URI para garantizar la unicidad general. El URI no tiene que ser direccionable. Se tratará como una cadena. Por ejemplo, una credencial de diploma emitida por Contoso University puede declarar los siguientes tipos:
| Tipo | Propósito |
|---|---|
https://schema.org/EducationalCredential |
Declara que los diplomas emitidos por Contoso University contienen atributos definidos por el objeto EducationaCredential de schema.org. |
https://schemas.ed.gov/universityDiploma2020 |
Declara que los diplomas emitidos por Contoso University contienen atributos definidos por el Departamento de Educación de Estados Unidos. |
https://schemas.contoso.edu/diploma2020 |
Declara que los diplomas emitidos por Contoso University contienen atributos definidos por Contoso University. |
Además de los estándares y los esquemas específicos del sector que podrían aplicarse a sus escenarios, tenga en cuenta los siguientes aspectos:
Minimice la información privada: cumpla los casos de uso con la cantidad mínima necesaria de información privada. Por ejemplo, una credencial verificable empleada para sitios web de comercio electrónico que ofrece descuentos a empleados y alumnos puede cumplirse si se presenta la credencial solamente con las notificaciones de nombre y apellidos. No se necesita información adicional, como la fecha de contratación, el puesto, el departamento, etc.
Priorice las notificaciones abstractas: las notificaciones deben satisfacer las necesidades y, al mismo tiempo, minimizar los detalles. Por ejemplo, una notificación denominada "ageOver" con valores discretos como 13, 21, 60 es más abstracta que una notificación de fecha de nacimiento.
Planee la revocabilidad: se recomienda definir una notificación de índice para habilitar mecanismos que permitan buscar y revocar credenciales. Como máximo, puede definir una notificación de índice por contrato. Es importante tener en cuenta que los valores de las notificaciones indexadas no se almacenan en el back-end; solo se almacena un hash del valor de notificación. Para obtener más información, consulte Revocación de una credencial verificable emitida previamente.
Para conocer otras consideraciones sobre los atributos de las credenciales, consulte la especificación Verifiable Credentials Data Model 1.0 (w3.org).
Planeación de los atributos de calidad
Planeación del rendimiento
Al igual que sucede con cualquier solución, debe planear el rendimiento. Las principales áreas de interés son la latencia, el rendimiento, el almacenamiento y la escalabilidad. Durante las fases iniciales de un ciclo de publicación, el rendimiento no debería ser una preocupación. Aun así, cuando la adopción de la solución de emisión conlleva que se emitan muchas credenciales verificables, la planeación del rendimiento podría convertirse en una parte crítica de la solución.
A continuación se indican las áreas que debe tener en cuenta al planear el rendimiento:
El servicio de emisión de Microsoft Entra Verified ID se implementa en las regiones Oeste de Europa, Norte de Europa, Oeste de EE. UU. 2, Centro-oeste de EE. UU., Australia y Japón de Azure. Si el inquilino de Microsoft Entra reside en la UE, el servicio Microsoft Entra Verified ID también está en la UE.
Para limitar la latencia, implemente el sitio web de front-end de emisión y el almacén de claves en la región indicada anteriormente.
Modelo basado en el rendimiento:
El servicio de emisor está sujeto a los límites de servicio de Azure Key Vault.
En el caso de Azure Key Vault, cada emisión de credencial verificable consta de tres operaciones de firma:
Una para la solicitud de emisión desde el sitio web
Una para la credencial verificable que se crea
Una para la descarga del contrato
No es posible regular el límite de ancho de banda, pero se recomienda leer la Guía de las limitaciones de Azure Key Vault.
Si planea una importante implementación e incorporación de credenciales verificables, considere la posibilidad de procesar en lotes la creación de credenciales verificables para asegurarse de no superar los límites.
Como parte del plan de rendimiento, determine qué supervisará para comprender mejor el rendimiento de la solución. Además de la supervisión de los sitios web del nivel de aplicación, tenga en cuenta lo siguiente al definir la estrategia de supervisión de emisión de credenciales verificables:
Para mejorar la escalabilidad, considere la posibilidad de implementar métricas para los siguientes elementos:
Definición de las fases lógicas del proceso de emisión Por ejemplo:
Solicitud inicial
Mantenimiento del código QR o del vínculo profundo
Búsqueda de atributos
Llamadas al servicio de emisión de Id. verificada por Microsoft Entra
Credencial emitida
Defina métricas basadas en las fases:
Recuento total de solicitudes (volumen)
Solicitudes por unidad de tiempo (rendimiento)
Tiempo invertido (latencia)
Para supervise Azure Key Vault y Storage, siga este vínculo:
Supervisión de los componentes usados para la capa de lógica de negocios
Planeación de la confiabilidad
Para planear la confiabilidad, se recomienda lo siguiente:
Después de definir los objetivos de disponibilidad y redundancia, use las siguientes guías para entender cómo puede alcanzar sus objetivos:
Para el front-end y la capa empresarial, la solución se puede manifestar de numerosas maneras. Al igual que sucede con cualquier solución, asegúrese de que las dependencias que identifique sean resistentes y estén supervisadas.
En el caso excepcional de que el servicio de emisión de Microsoft Entra Verified ID, los servicios de Azure Key Vault dejarán de estar disponibles, al igual que la solución.
Planeación del cumplimiento
Su organización podría tener necesidades de cumplimiento específicas relacionadas con el sector, el tipo de transacciones o el país o región en el que opera.
Residencia de los datos: el servicio de emisión de Id. verificada por Microsoft Entra se implementa en un subconjunto de regiones de Azure. El servicio solo se usa para las funciones de proceso. No se almacenan valores de credenciales verificables en los sistemas de Microsoft. Aun así, como parte del proceso de emisión, se envían y se usan datos personales al emitir credenciales verificables. El uso del servicio de credenciales verificables no debería afectar a los requisitos de residencia de datos. Si almacena información personal como parte de la verificación de identidad, debe guardarse en una región y de una manera acordes con los requisitos de cumplimiento. Para obtener instrucciones relacionadas con Azure, visite el sitio web del Centro de confianza de Microsoft.
Revocación de las credenciales: determine si su organización necesita revocar las credenciales. Por ejemplo, es posible que un administrador tenga que revocar las credenciales cuando un empleado abandone la empresa. Para obtener más información, consulte Revocación de una credencial verificable emitida previamente.
Credenciales a punto de expirar: Determine cómo expiran las credenciales. Por ejemplo, si emite una credencial verificable como prueba de que se está en posesión de un permiso de conducir, podría expirar al cabo de unos años. Otras máquinas virtuales pueden tener una validez más corta para asegurarse de que los usuarios vuelvan periódicamente para actualizar su VC.
Planeación de las operaciones
Al planear las operaciones, es fundamental que elabore un esquema que se usará para solucionar problemas, crear informes y distinguir los diferentes clientes que admita. Además, si el equipo de operaciones es responsable de ejecutar la revocación de las credenciales verificables, ese proceso debe estar bien definido. Todos los pasos del proceso deben estar correlacionados para que pueda determinar qué entradas del registro se pueden asociar a cada solicitud de emisión única. Para la auditoría, se recomienda capturar cada intento de emisión de credenciales de forma individual. En concreto:
Genere identificadores de transacción únicos a los que los clientes y los ingenieros de soporte técnico puedan hacer referencia según sea necesario.
Diseñe un mecanismo para correlacionar los registros de las transacciones de Azure Key Vault con los identificadores de transacción de la parte emisora de la solución.
Si ofrece un servicio de verificación de identidad que emite credenciales verificables en nombre de varios clientes, realice la supervisión y la mitigación por identificador de cliente o de contrato para los informes orientados al cliente y la facturación.
Si ofrece un servicio de verificación de identidad que emite credenciales verificables en nombre de varios clientes, use el identificador de cliente o de contrato para los informes orientados al cliente, la facturación, la supervisión y la mitigación.
Planear la seguridad
Como parte de las consideraciones de diseño centradas en la seguridad, se recomiendan los siguientes elementos:
Para la administración de claves:
Cree una instancia de Key Vault dedicada para la emisión de credenciales verificables. Limite los permisos de Azure Key Vault al servicio de emisión de Id. verificada por Microsoft Entra y a la entidad de servicio del sitio web de front-end del servicio de emisión.
Azure Key Vault emite credenciales a los clientes; trátelo como un sistema con privilegios elevados. Se recomienda que ninguna identidad humana tenga permisos permanentes en el servicio Azure Key Vault. Los administradores deberían tener únicamente acceso Just-In-Time a Key Vault. Si le interesa conocer más procedimientos recomendados par el uso de Azure Key Vault, consulte Línea base de seguridad de Azure para Key Vault.
Para la entidad de servicio que representa el sitio web de front-end de emisión:
Defina una entidad de servicio dedicada para autorizar el acceso a Azure Key Vault. Si el sitio web está en Azure, se recomienda usar una identidad administrada de Azure.
Trate la entidad de servicio que representa el sitio web y el usuario como un límite de confianza único. Aunque es posible crear varios sitios web, hay un solo conjunto de claves para la solución de emisión.
Para el registro y la supervisión de seguridad, se recomiendan los siguientes elementos:
Habilite el registro y las alertas de Azure Key Vault para realizar un seguimiento de las operaciones de emisión de credenciales, los intentos de extracción de claves y los cambios de permisos, así como para supervisar y enviar alertas para los cambios de configuración. Encontrará más información en Habilitación del registro de Key Vault.
Archive los registros en sistemas de Administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel, para la retención a largo plazo.
Para mitigar los riesgos de suplantación de identidad, use lo siguiente:
Comprobación de DNS para ayudar a los clientes a identificar la personalización de marca del emisor.
Nombres de dominio que tengan significado para los usuarios finales.
Personalización de marca de confianza que el usuario final reconozca.
Mitigue los riesgos de denegación de servicio distribuido (DDoS) y de agotamiento de los recursos de Key Vault. Cada solicitud que desencadena una solicitud de emisión de credenciales verificables genera operaciones de firma de Key Vault que se acumulan dentro los límites del servicio. Para proteger el tráfico, se recomienda incorporar una autenticación o CAPTCHA antes de generar solicitudes de emisión.
Para obtener instrucciones sobre cómo administrar el entorno de Azure, se recomienda revisar Azure Cloud Security Benchmark y Protección de entornos de Microsoft Entra ID. Estas guías proporcionan procedimientos recomendados para administrar los recursos subyacentes de Azure, incluidos Azure Key Vault, Azure Storage, sitios web y otros servicios y funcionalidades relacionados con Azure.
Consideraciones adicionales
Cuando complete la prueba de concepto, recopile toda la información y la documentación que haya generado y considere la posibilidad de anular la configuración del emisor.
Para obtener más información sobre la implementación y el funcionamiento de Key Vault, consulte Procedimientos recomendados para usar Key Vault. Para obtener más información sobre cómo proteger entornos de Azure con Active Directory, consulte Protección de entornos de Azure con Microsoft Entra ID.
Pasos siguientes
Introducción a la arquitectura