Planifique su solución de verificación de identidad verificada de Microsoft Entra

Visión general

El servicio Microsoft Entra Verified ID (Microsoft Entra VC) le permite confiar en las pruebas de identidad de usuario sin expandir el límite de confianza. Con Microsoft Entra VC, crea cuentas o federa con otro proveedor de identidades. Cuando una solución implementa un intercambio de comprobación mediante credenciales verificables, permite a las aplicaciones solicitar credenciales que no están enlazadas a un dominio específico. Este enfoque facilita la solicitud y comprobación de credenciales a escala.

Si aún no lo ha hecho, revise la visión general de la arquitectura de Microsoft Entra Verified ID. Consulte también Planifique su solución de emisión de ID verificada de Microsoft Entra.

Ámbito de la guía

En este contenido se tratan los aspectos técnicos del planeamiento de una solución de verificación de credenciales verificable mediante productos y servicios de Microsoft. La solución interactúa con un sistema de confianza, donde actualmente se admite DID Web. DID Web es una infraestructura de clave pública centralizada.

Las tecnologías auxiliares que no son específicas de las soluciones de verificación están fuera del ámbito. Por ejemplo, los sitios web se usan en una solución de comprobación de credenciales verificables, pero el planeamiento de una implementación de sitios web no se trata con detalle.

A medida que planee la solución de verificación, debe tener en cuenta qué funcionalidad empresarial se va a agregar o modificar. También debe tener en cuenta qué funcionalidades de TI se pueden reutilizar y qué funcionalidades se deben agregar para crear la solución. Tenga en cuenta también qué formación se necesita para las personas implicadas en el proceso empresarial y las personas que apoyan a los usuarios finales y al personal de la solución. Estos temas no se tratan en este contenido. Para más información, consulte Microsoft Azure Well-Architected Framework.

Componentes de la solución

Como parte del plan de una solución de comprobación, debe habilitar las interacciones entre el comprobador, el sujeto y el emisor. En este artículo, los términos usuario de confianza y comprobador se usan indistintamente. En el diagrama siguiente se muestran los componentes de la arquitectura de comprobación.

Servicio de Identificación Verificada de Microsoft Entra

En el contexto de una solución de comprobador, el servicio Microsoft Entra Verified ID es la interfaz entre los componentes de Microsoft de la solución y el sistema de confianza. El servicio aprovisiona la clave establecida en Key Vault, aprovisiona el identificador descentralizado (DID).

Inquilino de Microsoft Entra

El servicio requiere un inquilino de Microsoft Entra que proporcione 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 arrendatario de Microsoft Entra utiliza el servicio multiarrendatario de ID Verificado de Microsoft Entra y emite un único documento DID que representa al verificador. Si tiene varias partes dependientes utilizando su servicio de verificación, todas usan el mismo DID de comprobador. El DID comprobador proporciona punteros a la clave pública que permite a los sujetos y emisores validar los mensajes que proceden del usuario de confianza.

Azure Key Vault

El servicio Azure Key Vault almacena las claves de comprobador, que se generan al habilitar el servicio de emisión de identificadores comprobados de Microsoft Entra. Las claves se usan para proporcionar seguridad de mensajes. Cada comprobador tiene un único conjunto de claves que se usa para firmar, actualizar y recuperar credenciales de verificación. La Identificación verificada utiliza este conjunto de claves cada vez que atiendes una solicitud de verificación. Actualmente, el conjunto de claves de Microsoft usa criptografía de curva elíptica (ECC) SECP256k1. También se evalúan otros esquemas de firma criptográfica adoptados por la comunidad DID más amplia.

API de servicio de solicitud

Las interfaces de programación de aplicaciones (API) proporcionan a los desarrolladores un método para abstraer las interacciones entre los componentes de la solución para ejecutar operaciones de comprobación.

Sistema de confianza

Microsoft Entra Verified ID admite actualmente DID Web como sistema de confianza, donde el documento DID se hospeda en el servidor web emisor.

Aplicación Microsoft Authenticator

Microsoft Authenticator es la aplicación móvil. Authenticator organiza las interacciones entre el usuario, el servicio Microsoft Entra VC y el contrato usado para emitir credenciales verificables. Actúa como una cartera digital en la que el titular del VC almacena el VC, incluida la clave privada del sujeto del VC. Authenticator es también el mecanismo que se usa para presentar las credenciales verificables para su comprobación.

Usuario de confianza (RP)

Interfaz web

El front-end web del usuario de confianza usa la API Request Service para comprobar las VC mediante la generación de vínculos profundos o códigos QR que consume la cartera del sujeto. En función del escenario, el front-end puede ser un sitio web accesible públicamente o interno para habilitar experiencias de usuario final que requieran comprobación. Sin embargo, los puntos de conexión a los que accede la cartera deben ser accesibles públicamente. En concreto, controla el redireccionamiento a la cartera con parámetros de solicitud específicos.

Lógica de negocios

Puede crear una nueva lógica, o usar una ya existente que sea específica del usuario de confianza y mejorarla con la presentación de credenciales verificables.

Diseños específicos del escenario

A continuación se muestran ejemplos de diseños para satisfacer casos de uso específicos. El primero corresponde a la incorporación de cuentas, que se usa para reducir el tiempo, los costos y los riesgos asociados a la incorporación de nuevos empleados. El segundo es para la recuperación de cuentas, lo que permite a un usuario final recuperar o desbloquear su cuenta mediante un mecanismo de autoservicio. La tercera es acceder a recursos y aplicaciones de alto valor, específicamente para casos de uso de negocio a negocio en los que se concede acceso a personas que trabajan para otras empresas.

Incorporación de cuentas

Las credenciales verificables se pueden usar para habilitar la incorporación más rápida reemplazando algunas interacciones humanas. Las credenciales verificables se pueden usar para incorporar empleados, alumnos, ciudadanos u otros usuarios para que accedan a los servicios. Por ejemplo, en lugar de que un empleado necesite ir a una oficina central para activar un distintivo de empleado, puede usar un VC para comprobar su identidad para activar un distintivo que se entrega a ellos de forma remota. En lugar de que un ciudadano reciba un código que tenga que canjear para acceder a los servicios gubernamentales, puede usar una credencial verificable para demostrar su identidad y obtener acceso.

Otros elementos

Portal de incorporación: se trata de un front-end web que organiza las llamadas de Request Service API para la presentación y validación de credenciales verificables, y la lógica para incorporar cuentas.

Lógica personalizada o flujos de trabajo: lógica específica con pasos específicos de la organización antes y después de actualizar la cuenta de usuario. Algunos ejemplos pueden incluir flujos de trabajo de aprobación, otras validaciones, registro, notificaciones, etc.

Sistemas de identidad de destino: repositorios de identidades específicos de la organización con los que el portal de incorporación tiene que interactuar durante la incorporación de los sujetos. Los sistemas que se van a integrar se determinan en función de los tipos de identidades que desea incorporar con la validación de VC. Entre los escenarios comunes de comprobación de identidades para la incorporación se incluyen:

• External Identities que Microsoft Entra ID incorpora mediante API para emitir invitaciones de negocio a negocio (B2B) o asignación de administración de derechos a paquetes.

• Las identidades de los empleados, las cuales en los sistemas de identidad centralizados ya se incorporan a través de sistemas de recursos humanos (RRHH). En este caso, la comprobación de identidad podría integrarse como parte de las fases existentes de flujos de trabajo de RR. HH.

Consideraciones de diseño

• Emisor: la incorporación de cuentas es una buena opción para un servicio de revisión de identidades externas como emisor de las credenciales verificables. Algunos ejemplos de comprobaciones para la incorporación son: verificación de vitalidad, validación de documentos emitidos por el gobierno, o dirección o confirmación de número de teléfono, entre otros.

• Almacenar atributos de VC: siempre que sea posible, no almacene atributos de los VCs en el almacén específico de la aplicación. Tenga especial cuidado con los datos personales. Si esta información es necesaria para flujos específicos dentro de las aplicaciones, considere la posibilidad de solicitar que la VC recupere las notificaciones a petición.

• Correlación de atributos de VC con sistema de back-end: al definir los atributos del VC con el emisor, establezca un mecanismo para correlacionar la información en el sistema de back-end tras la presentación de la credencial verificable por parte del usuario. El mecanismo normalmente utiliza un identificador único con restricción temporal en el contexto de su RP en combinación con las reclamaciones que recibe. He aquí algunos ejemplos:

  • Nuevo empleado: cuando el flujo de trabajo de RR. HH. llega al punto en el que se requiere la verificación de identidad, el RP puede generar un vínculo con un identificador único con un plazo determinado. A continuación, el RP lo envía a la dirección de correo electrónico del candidato en el sistema de RR. HH. Este identificador único debe ser suficiente para correlacionar información como firstName, lastName de la solicitud de comprobación de VC al registro de RR. HH. o a los datos subyacentes. Los atributos de la credencial verificable se pueden usar para completar los atributos de usuario en el sistema de RR. HH. o para validar la precisión de los atributos de usuario sobre el empleado.

  • Identidades externas : invitación: cuando se invita a un usuario externo al sistema de destino, el RP puede generar un vínculo con un identificador único que represente la transacción de invitación. Este vínculo se puede enviar a la dirección de correo electrónico del usuario externo. Este identificador único debe ser suficiente para correlacionar la solicitud de comprobación de VC con el registro de invitación o los datos subyacentes y continuar con el flujo de trabajo de aprovisionamiento. Los atributos de la credencial verificable se pueden usar para validar o completar los atributos de usuario externos.

  • Identidades externas - Autoservicio: Cuando las identidades externas se registran en el sistema de destino a través del autoservicio (por ejemplo, una aplicación B2C), los atributos en la VC se pueden usar para rellenar los atributos iniciales de la cuenta de usuario. Los atributos de VC también se pueden usar para averiguar si ya existe un perfil.

• Interacción con los sistemas de identidad de destino: la comunicación entre el front-end web y los sistemas de identidad de destino debe protegerse como un sistema altamente privilegiado, ya que puede crear cuentas. Conceda a la interfaz web los roles con los menores privilegios posibles. Algunos ejemplos son:

  • Para crear un nuevo usuario en Microsoft Entra ID, el sitio web del usuario de confianza puede usar una entidad de servicio a la que se conceda el ámbito User.ReadWrite.All de MS Graph para crear usuarios, y el ámbito UserAuthenticationMethod.ReadWrite.All para restablecer su método de autenticación.

  • Para invitar usuarios a Microsoft Entra ID mediante la colaboración B2B, el sitio web del usuario de confianza puede usar una entidad de servicio a la que se conceda el ámbito User.Invite.All de MS Graph para crear invitaciones.

  • Si el RP se ejecuta en Azure, use Identidades administradas para llamar a Microsoft Graph. El uso de identidades administradas elimina los riesgos asociados a la administración de credenciales de entidades de servicio en archivos de código o de configuración. Para más información sobre las identidades administradas, vaya a Identidades administradas para recursos de Azure.

Acceso a aplicaciones de alto valor dentro de organizaciones

Las credenciales verificables se pueden usar como otra prueba para acceder a aplicaciones confidenciales dentro de la organización. Por ejemplo, las credenciales verificables también se pueden usar para proporcionar a los empleados acceso a aplicaciones de línea de negocio basadas en la obtención de criterios específicos, como una certificación.

Otros elementos

Front-end web del usuario de confianza: se trata del front-end web de la aplicación que se mejora mediante las llamadas de Request Service API para la presentación y validación de credenciales verificables, en función de los requisitos empresariales.

La lógica de autorización de acceso de usuario es la capa lógica de la aplicación que autoriza el acceso de los usuarios. Se optimiza para utilizar los atributos de usuario en la VC y tomar decisiones de autorización.

Otros servicios y dependencias de back-end: representa el resto de la lógica de la aplicación, que normalmente no se ve afectada por la inclusión de la verificación de identidad a través de credenciales verificables.

Consideraciones de diseño

• Objetivo: el objetivo del escenario determina qué tipo de credencial y emisor se necesita. Entre los escenarios típicos se incluyen:

  • Autorización: en este escenario, el usuario presenta la VC para tomar una decisión de autorización. Las credenciales verificables diseñadas para probar la finalización de un entrenamiento o tener una certificación específica son una buena opción para este escenario. Los atributos de VC deben contener información específica que permita tomar decisiones de autorización y auditar. Por ejemplo, la credencial verificable (VC) se utiliza para certificar que la persona está capacitada y puede acceder a aplicaciones financieras de carácter confidencial. La lógica de la aplicación puede comprobar la notificación del departamento para obtener una autorización específica y usar el id. de empleado con fines de auditoría.

  • Confirmación de la comprobación de identidad: en este escenario, el objetivo es confirmar que la misma persona que se incorporó inicialmente es realmente la que intenta acceder a la aplicación de alto valor. Una credencial de un emisor de comprobación de identidad sería una buena opción. La lógica de la aplicación debe validar que los atributos del VC se alinean con el usuario que inició sesión en la aplicación.

• Comprobación de la revocación: al usar credenciales verificables para acceder a recursos confidenciales, es habitual comprobar el estado de la credencial con el emisor original y denegar el acceso a las credenciales revocadas. Al trabajar con los emisores, asegúrese de que la revocación se describe explícitamente como parte del diseño de su escenario.

• Experiencia del usuario: al usar las máquinas virtuales para acceder a recursos confidenciales, hay dos patrones que puede tener en cuenta.

  • Autenticación paso a paso: los usuarios inician la sesión con la aplicación con mecanismos de autenticación existentes. Los usuarios deben presentar un VC para operaciones específicas de alto valor dentro de la aplicación, como aprobaciones de flujos de trabajo empresariales. Esto es una buena opción para escenarios en los que estas operaciones de alto valor son fáciles de identificar y actualizar dentro de los flujos de aplicación.

  • Establecimiento de sesión: los usuarios deben presentar un VC como parte del inicio de la sesión con la aplicación. Presentar un VC es una buena opción cuando la naturaleza de toda la aplicación es de alto valor.

Acceso a aplicaciones fuera de los límites de la organización

Las credenciales verificables también se pueden usar por partes confiables que deseen conceder acceso o beneficios basándose en la membresía o relación laboral con una organización diferente. Por ejemplo, un portal de comercio electrónico puede ofrecer ventajas como descuentos a empleados de una empresa determinada, estudiantes de una institución determinada, etc.

La naturaleza descentralizada de las credenciales verificables permite este escenario sin establecer relaciones de federación.

Otros elementos

Front-end web del usuario de confianza: se trata del front-end web de la aplicación que se mejora mediante las llamadas de Request Service API para la presentación y validación de credenciales verificables, en función de los requisitos empresariales.

Lógica de autorización de acceso de usuario: capa lógica de la aplicación que autoriza el acceso de los usuarios y que se mejora para consumir los atributos de usuario dentro de la credencial verificable para tomar decisiones de autorización.

Otros servicios y dependencias de back-end: representa el resto de la lógica de la aplicación, que normalmente no se ve afectada por la inclusión de la verificación de identidad a través de credenciales verificables.

Consideraciones de diseño

• Objetivo: el objetivo del escenario determina qué tipo de credencial y emisor se necesita. Entre los escenarios típicos se incluyen:

  • Autenticación: en este escenario, un usuario debe tener posesión de una credencial verificable para demostrar el empleo o su relación con una organización determinada. En este caso, el usuario de confianza debe configurarse para aceptar las credenciales verificables emitidas por las organizaciones de destino.

  • Autorización: en función de los requisitos de la aplicación, las aplicaciones pueden consumir los atributos de VC para las decisiones de autorización específicas y la auditoría. Por ejemplo, si un sitio web de comercio electrónico ofrece descuentos a los empleados de las organizaciones de una ubicación determinada, pueden validar la idoneidad del descuento en función de la notificación de país o región en el VC (si está presente).

• Comprobación de la revocación: al usar credenciales verificables para acceder a recursos confidenciales, es habitual comprobar el estado de la credencial con el emisor original y denegar el acceso a las credenciales revocadas. Al trabajar con los emisores, asegúrese de que la revocación se describe explícitamente como parte del diseño de su escenario.

• Experiencia del usuario: los usuarios pueden presentar un VC como parte del inicio de la sesión con la aplicación. Normalmente, las aplicaciones también proporcionan un método alternativo para iniciar la sesión para dar cabida a los casos en los que los usuarios no tienen máquinas virtuales.

Recuperación de cuentas

Las credenciales verificables se pueden usar como un enfoque para la recuperación de cuentas. Por ejemplo, cuando un usuario necesita recuperar su cuenta, podría acceder a un sitio web que les requiera presentar un VC e iniciar un restablecimiento de credenciales de Microsoft Entra llamando a las API de MS Graph, como se muestra en el diagrama siguiente.

Nota:

Aunque el escenario descrito en esta sección es específico para recuperar cuentas de Microsoft Entra, este enfoque también se puede usar para recuperar cuentas en otros sistemas.

Otros elementos

Portal de cuentas: front-end web que organiza las llamadas API para la presentación y validación de VC. Esta orquestación puede incluir llamadas de Microsoft Graph para recuperar cuentas en el identificador de Entra de Microsoft.

Lógica o flujos de trabajo personalizados: lógica con pasos específicos de la organización antes y después de actualizar la cuenta de usuario. La lógica personalizada puede incluir flujos de trabajo de aprobación, otras validaciones, registro, notificaciones, etc.

Microsoft Graph: expone las API de transferencia de estado representacional (REST) y las bibliotecas cliente para acceder a los datos de Microsoft Entra que se usan para realizar la recuperación de cuentas.

Directorio empresarial de Microsoft Entra: la entidad de Microsoft Entra que contiene las cuentas que se crean o se actualizan a través del portal de administración de cuentas.

Consideraciones de diseño

Correlación de atributos de VC con Microsoft Entra ID: al definir los atributos de la credencial verificable en colaboración con el emisor, asegúrese de acordar sobre las afirmaciones que identifican al usuario. Por ejemplo, si el proveedor de verificación de identidad (IDV) verifica la identidad antes de incorporar a los empleados, asegúrese de que las afirmaciones del VC emitido se puedan comparar con los sistemas internos. Estas afirmaciones pueden ser un número de teléfono, una dirección o una fecha de nacimiento. El RP puede solicitar información no encontrada en el VC como parte de este proceso, como los últimos cuatro dígitos de su número de seguro social (SSN).

Rol de las máquinas virtuales con funcionalidades de restablecimiento de credenciales de Microsoft Entra existentes: El identificador de Microsoft Entra tiene una funcionalidad integrada de autoservicio de restablecimiento de contraseña (SSPR). Las credenciales verificables se pueden usar para proporcionar otra manera de recuperarse en los casos en los que los usuarios no tienen acceso o pierden el control del método SSPR. En escenarios en los que el usuario ha perdido tanto el equipo como el móvil, el usuario puede volver a obtener un VC de un emisor de credenciales de identidad y presentarlo para recuperar su cuenta de manera remota.

Del mismo modo, puede usar un VC para generar un pase de acceso temporal que permita a los usuarios restablecer sus métodos de autenticación de MFA sin una contraseña.

Autorización: cree un mecanismo de autorización como un grupo de seguridad que el RP comprueba antes de continuar con la recuperación de credenciales. Por ejemplo, solo los usuarios de grupos específicos pueden ser aptos para recuperar una cuenta con un VC.

Interacción con el identificador de Entra de Microsoft: la comunicación de servicio a servicio entre el front-end web y el identificador de Microsoft Entra debe protegerse como un sistema con privilegios elevados, ya que puede restablecer las credenciales de los empleados. Conceda a la interfaz web los roles con los menores privilegios posibles. Algunos ejemplos son:

• Conceda al sitio web del usuario de confianza la capacidad de usar una entidad de servicio a la que se le haya concedido el ámbito UserAuthenticationMethod.ReadWrite.All de MS Graph para restablecer los métodos de autenticación. No conceda User.ReadWrite.All, lo que permite crear y eliminar usuarios.

• Si el RP se ejecuta en Azure, use Identidades administradas para llamar a Microsoft Graph. El uso de identidades administradas elimina los riesgos asociados con la administración de credenciales de entidades de servicio en archivos de código o de configuración. Para más información, consulte Identidades administradas para recursos de Azure.

Planear la administración de identidades

A continuación se muestran algunas consideraciones sobre IAM al incorporar VC a los usuarios de confianza. Las partes confiables suelen ser aplicaciones.

Autenticación

• El sujeto de una credencial verificable debe ser una persona.

• Un humano tiene la VC en su cartera y debe presentarla interactivamente. No se admiten flujos no interactivos, como "en nombre de".

Autorización

• Una presentación correcta de la credencial verificable se puede considerar una puerta de autorización general por sí misma. Los atributos de VC también se pueden consumir para tomar decisiones de autorización específicas.

• Determine si un VC expirado tiene significado en la aplicación; si es así, compruebe el valor de la exp reclamación (la hora de expiración) del VC como parte del proceso de autorización. Un ejemplo en el que la expiración no es relevante es requerir un documento emitido por el gobierno, como una licencia de conducir para validar si el sujeto tiene más de 18 años. La notificación de fecha de nacimiento es válida, incluso si la credencial verificable ha expirado.

• Determine si un VC revocado tiene significado para la decisión de autorización.

  • Si no es relevante, omita la llamada para comprobar la API de estado (que está activada de forma predeterminada).

  • Si es pertinente, agregue el control adecuado de excepciones en la aplicación.

Perfiles de usuario

Puede usar la información de las credenciales verificables presentadas para crear un perfil de usuario. Si desea consumir atributos para crear un perfil, tenga en cuenta los siguientes elementos.

• Cuando se emite la credencial verificable, contiene una instantánea de los atributos en el momento de la emisión. Las VC pueden tener largos períodos de validez, por lo que es necesario determinar la antigüedad de los atributos que aceptará como suficientemente nuevos para usarse como parte del perfil.

• Si es necesario presentar un VC cada vez que el sujeto inicia una sesión con el RP, considere usar el resultado de la presentación del VC para crear un perfil de usuario no persistente con los atributos. Un perfil de usuario no persistente ayuda a reducir los riesgos de privacidad asociados al almacenamiento de propiedades de usuario en reposo. Es posible que la aplicación necesite guardar localmente los atributos del sujeto. Si es así, guarde solo las reclamaciones que necesita tu aplicación. No guarde toda la VC.

• Si la aplicación requiere un almacén de perfiles de usuario persistente:

  • Considere la posibilidad de usar la sub reclamación como un identificador inmutable del usuario. Se trata de un atributo único opaco que será constante para un par sujeto/RP de confianza determinado.

  • Definir un mecanismo para eliminar el perfil de usuario de la aplicación. Debido a la naturaleza descentralizada del sistema de identificadores comprobados de Microsoft Entra, no hay ningún ciclo de vida de aprovisionamiento de usuarios de la aplicación.

  • No almacene las notificaciones de datos personales devueltas en el token de la VC.

  • Almacene solo las notificaciones necesarias para la lógica del usuario de confianza.

Planeación del rendimiento

Al igual que sucede con cualquier solución, debe planear el rendimiento. Las áreas de enfoque incluyen latencia, rendimiento y escalabilidad. Durante las fases iniciales de un ciclo de versión, el rendimiento no debe ser un problema. Sin embargo, cuando la adopción de la solución da lugar a que se comprueben muchas credenciales verificables, el planeamiento del rendimiento puede convertirse en una parte fundamental de la solución.

Los siguientes elementos proporcionan áreas que se deben tener en cuenta al planear el rendimiento:

• El servicio de emisión de identificadores comprobados de Microsoft Entra se implementa en las regiones oeste de Europa, Norte de Europa, Oeste de EE. UU. 2 y Centro-oeste de EE. UU. de Azure. Para limitar la latencia, despliegue su interfaz de verificación (sitio web) y el almacén de claves en la región más cercana.

• Modelo basado en el rendimiento:

  • La capacidad de comprobación de VC está sujeta a límites de servicio de Azure Key Vault.

  • Cada comprobación de una credencial verificable requiere una operación de firma de Key Vault.

  • No puedes controlar la limitación; sin embargo, consulte la guía de limitación de Azure Key Vault para comprender cómo la limitación podría afectar al rendimiento.

Plan de confiabilidad

Para planear mejor la alta disponibilidad y la recuperación ante desastres, tenga en cuenta los siguientes elementos:

• El servicio microsoft Entra Verified ID se implementa en las regiones oeste de Europa, Norte de Europa, Oeste de EE. UU. 2 y Centro-oeste de EE. UU., Australia y Japón. Considere la posibilidad de implementar los servidores web compatibles y las aplicaciones auxiliares en una de esas regiones, específicamente en las que espera que se origine la mayoría del tráfico de validación.

• Revise e incorpore los procedimientos recomendados de disponibilidad y redundancia de Azure Key Vault a medida que diseñe los objetivos de disponibilidad y redundancia.

Planear la seguridad

A medida que diseñe para la seguridad, tenga en cuenta lo siguiente:

• Todos los usuarios de confianza de un solo inquilino tienen el mismo límite de confianza, ya que comparten el mismo DID.

• Defina una entidad de servicio dedicada para un sitio web que acceda a Key Vault.

• Solo el servicio Microsoft Entra Verified ID y las entidades de servicio del sitio web deben tener permisos para usar Key Vault para firmar mensajes con la clave privada.

• No asigne permisos administrativos de identidad humana a Key Vault. Para más información sobre los procedimientos recomendados de Key Vault, consulte Línea de base de seguridad de Azure para Key Vault.

• Consulte Protección de entornos de Azure con microsoft Entra ID para conocer los procedimientos recomendados para administrar los servicios auxiliares de la solución.

• Mitigue los riesgos de suplantación de identidad mediante:

  • Implementación de la comprobación de DNS para ayudar a los clientes a identificar la marca del emisor.

  • Use dominios significativos para los usuarios finales.

• Mitigue los riesgos de denegación de servicio distribuido (DDoS) y de limitación de recursos de Key Vault. Cada solicitud de presentación de credenciales verificables genera operaciones de firma de Key Vault que se acumulan dentro de los límites del servicio. Proteja el tráfico mediante la incorporación de autenticación alternativa o captcha antes de generar solicitudes de emisión.

Planeación de las operaciones

A medida que planee las operaciones, capture cada intento de validación de credenciales como parte de la auditoría. Use esa información para auditar y solucionar problemas. Además, considere la posibilidad de generar identificadores de transacción únicos (ID) a los que los clientes y los ingenieros de soporte técnico pueden hacer referencia si es necesario.

Como parte del planeamiento operativo, considere la posibilidad de supervisar lo siguiente:

• Para escalabilidad:

  • Monitorear los fallos en la validación de VC como parte de las métricas de seguridad de extremo a extremo de las aplicaciones.

  • Supervise la latencia de un extremo a otro de la comprobación de credenciales.

• Para confiabilidad y dependencias:

  • Supervise las dependencias subyacentes usadas por la solución de comprobación.

  • Siga la supervisión y las alertas de Azure Key Vault.

• Para seguridad:

  • Habilite el registro de Key Vault para realizar un seguimiento de las operaciones de firma y supervisar y alertar sobre los cambios de configuración. Consulte Cómo habilitar el registro en Key Vault para obtener más información.

  • Archivar registros en sistemas de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel para la retención a largo plazo.

Pasos siguientes

Más información sobre la arquitectura de soluciones de VC

• Introducción al servicio de Id. verificada por Microsoft Entra

• Planifica la solución de emisión de identificadores verificados de Microsoft Entra

Implementación de credenciales verificables

• Introducción al identificador comprobado de Microsoft Entra

• Introducción a las credenciales verificables

Preguntas más frecuentes