Compartir a través de

Planeamiento de la solución de comprobación de Verified ID de Microsoft Entra

  • Artículo

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

Si aún no lo ha hecho, le sugerimos que revise la introducción a la arquitectura de Id. verificada por Microsoft Entra. También puede revisar el artículo Planeamiento de una solución de emisión de Verified ID de Microsoft Entra.

Ámbito de la guía

Este contenido abarca los aspectos técnicos de la planeación de una solución de comprobación de credenciales verificables (VC) mediante productos y servicios de Microsoft. La solución interactúa con un sistema de confianza, donde actualmente se admite web DID. Web DID es una infraestructura de clave pública centralizada.

Las tecnologías complementarias que no son específicas de las soluciones de comprobación quedan fuera del ámbito. Por ejemplo, los sitios web se usan en una solución de comprobación de credenciales verificable, pero la planeación de una implementación de sitios web no se trata en detalle.

A medida que planee la solución de comprobación, debe tener en cuenta qué funcionalidad empresarial se está agregando o modificando. También debe tener en cuenta qué funcionalidades de TI se pueden reutilizar y qué funcionalidades se deben agregar para crear la solución. Debe tener en cuenta qué formación es necesaria para las personas involucradas en el proceso empresarial, así como para las personas que brindan asistencia a los usuarios finales y al personal de la solución. Estos artículos no se abordan en este contenido. Se recomienda revisar el Marco de buena arquitectura de Microsoft Azure para obtener más información sobre estos artículos.

Componentes de la solución

Como parte del plan para una solución de comprobación, tiene que 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.

Diagrama de los componentes de una solución de comprobación.

Servicio de Id. verificada por Microsoft Entra

En el contexto de una solución de comprobador, el servicio de Id. verificada por Microsoft Entra es la interfaz entre los componentes de Microsoft de la solución y el sistema de confianza. El servicio facilita el conjunto de claves a Key Vault y 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 acceso e identidad (IAM) para los recursos de Azure que forman parte de la solución. Cada inquilino de Microsoft Entra usa el servicio de Id. verificada por Microsoft Entra multiinquilino y emite un único documento DID que representa el comprobador. Si tiene varios usuarios de confianza que usan el servicio de comprobación, todos usan el mismo DID 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

Diagrama de los componentes de una solución de comprobación, con Azure Key Vault resaltado.

El servicio de Azure Key Vault almacena las claves del comprobador, que se generan al habilitar el servicio de emisión de Id. verificada por Microsoft Entras. Las claves se usan para proporcionar la seguridad de los mensajes. Cada comprobador tiene un único conjunto de claves que se usa para firmar, actualizar y recuperar credenciales de verificación. Este conjunto de claves se usa cada vez que entrega una solicitud de comprobación. Actualmente, el conjunto de claves de Microsoft usa la criptografía de curva elíptica (ECC) SECP256k1. Estamos explorando otros esquemas de firma criptográfica que adoptará la comunidad DID más amplia.

Request Service API

Diagrama de los componentes de una solución de comprobación, con Request Service API resaltada.

Las interfaces de programación de aplicaciones (API) ofrecen 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

Diagrama de los componentes de una solución de comprobación, con el sistema de confianza resaltado.

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

Aplicación Microsoft Authenticator

Diagrama de los componentes de una solución de comprobación, con la aplicación Microsoft Authenticator resaltada.

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.

Usuario de confianza

Diagrama de los componentes de una solución de comprobación, con los componentes del usuario de confianza resaltados.

Front end 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 interno o de acceso público para habilitar experiencias de usuario final que requieren 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, que permite a un usuario final recuperar o desbloquear su cuenta a través de un mecanismo de autoservicio. El tercero es para acceder a recursos y aplicaciones de alto valor, específicamente para casos de uso de negocio a negocio en los que se proporciona acceso a personas que trabajan para otras empresas.

Incorporación de cuentas

Las credenciales verificables se pueden usar para permitir una incorporación más rápida, ya que se reemplazan 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 tenga que ir a una oficina central para activar un distintivo de empleado, puede usar una credencial verificable que compruebe su identidad para activar un distintivo que se le entregue 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.

Diagrama que muestra el escenario de incorporación de cuenta.

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 o flujos de trabajo personalizados: lógica específica con pasos específicos de la organización antes y después de actualizar la cuenta de usuario. Por ejemplo, flujos de trabajo de aprobación, validaciones adicionales, registros, 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 quiere incorporar con la validación de credenciales verificables. Entre los escenarios comunes de verificació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.

  • Identidades de empleado, que en sistemas de identidad centralizados ya se incorporan a través de sistemas de recursos humanos (RR. HH.). En este caso, la verificación de identidad podría integrarse como parte de las fases existentes de los 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. Entre los ejemplos de comprobaciones para la incorporación se incluyen: comprobación de identidad, validación de documentos emitidos por el Gobierno, confirmación de direcciones o números de teléfono, etc.

  • Almacenamiento de atributos de credenciales verificables: siempre que sea posible, no almacene atributos de las credenciales verificables 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 del atributo de credenciales verificables con sistemas back-end: al definir los atributos de la credencial verificable con el emisor, establezca un mecanismo para correlacionar la información en el sistema back-end después de que el usuario presente la credencial verificable. Normalmente, se usa un identificador único con límite de tiempo en el contexto del usuario de confianza en combinación con las notificaciones que recibe. He aquí algunos ejemplos:

    • Nuevo empleado: cuando el flujo de trabajo de RR. HH. alcanza el punto en el que se requiere la revisión de identidades, el usuario de confianza puede generar un vínculo con un identificador único con límite de tiempo. 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 la credencial verificable con el registro de RR. HH. o 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 la credencial verificable 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 mediante el autoservicio (por ejemplo, una aplicación B2C), los atributos de la credencial verificable se pueden usar para rellenar los atributos iniciales de la cuenta de usuario. Los atributos de la credencial verificable también se pueden usar para averiguar si ya existe un perfil.

  • Interacción con sistemas de identidad de destino: la comunicación de servicio a servicio entre el front-end web y los sistemas de identidad de destino debe protegerse como sistema con privilegios elevados, ya que puede crear cuentas. Conceda al front-end web los roles con menos privilegios posibles. Estos son algunos ejemplos:

    • 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 usuario de confianza 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 ¿Qué son las identidades administradas de recursos de Azure?

Acceso a aplicaciones de alto valor dentro de las organizaciones

Las credenciales verificables se pueden usar como prueba adicional para acceder a aplicaciones confidenciales dentro de una 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.

Diagrama de los componentes de una solución de comprobación, con otros elementos incluidos.

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 modifica mediante la inclusión de pruebas de identidad a través de credenciales verificables.

Consideraciones de diseño

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

    • Autorización: en este escenario, el usuario presenta la credencial verificable para tomar una decisión de autorización. Las credenciales verificables diseñadas para la prueba de finalización de un entrenamiento o de posesión de una certificación específica son una buena opción para este escenario. Los atributos de las credenciales verificables deben contener información específica que favorezcan las decisiones de autorización y la auditoría. Por ejemplo, la VC se usa para certificar que la persona esté entrenada y pueda acceder a aplicaciones financieras confidenciales. 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 verificació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 revocación: Cuando se usan VC para acceder a recursos confidenciales, es habitual comprobar el estado de la VC con el emisor original y denegar el acceso a las VC revocadas. Al trabajar con los emisores, asegúrese de que la revocación se analice explícitamente como parte del diseño del escenario.

  • Experiencia del usuario: Cuando se usan credenciales verificables 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 mediante los mecanismos de autenticación existentes. Los usuarios tienen que presentar una credencial verificable para operaciones específicas de alto valor dentro de la aplicación, como aprobaciones de flujos de trabajo de negocio. Se trata de una buena opción para escenarios en los que estas operaciones de gran valor son fáciles de identificar y actualizar dentro de los flujos de la aplicación.

    • Establecimiento de sesión: Los usuarios deben presentar una credencial verificable como parte del inicio de una sesión con la aplicación. Esto 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

Los usuarios de confianza que quieren conceder acceso o ventajas en función de la relación de pertenencia o empleo de una organización diferente también pueden usar las credenciales verificables. Por ejemplo, un portal de comercio electrónico puede ofrecer ventajas, como descuentos a los empleados de una empresa determinada, alumnos de una institución determinada, etc.

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

Diagrama de los componentes de una solución de comprobación que muestra cómo el acceso tiene lugar desde fuera del límite de confianza.

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 modifica mediante la inclusión de pruebas de identidad a través de credenciales verificables.

Consideraciones de diseño

  • Objetivo: El objetivo del escenario determina qué tipo de credencial y emisor son necesarios. 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 la 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 cada aplicación, las aplicaciones pueden consumir los atributos de la credencial verificable para las decisiones de autorización detalladas y la auditoría. Por ejemplo, si un sitio web de comercio electrónico ofrece descuentos a los empleados de las organizaciones en una ubicación determinada, se puede validar en función de la notificación del país/región en la VC (si existe).

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

  • Experiencia del usuario: Los usuarios pueden presentar una credencial verificable como parte del inicio de una sesión con la aplicación. Normalmente, las aplicaciones también proporcionan un método alternativo para iniciar la sesión para permitir los casos en los que los usuarios no tienen credenciales verificables.

Recuperación de cuentas

Las credenciales verificables se pueden usar como enfoque para la recuperación de cuentas. Por ejemplo, cuando un usuario tiene que recuperar su cuenta, puede acceder a un sitio web que requiere que presente una credencial verificable e inicie un restablecimiento de credenciales de Microsoft Entra mediante una llamada a las API de MS Graph, como se muestra en el diagrama siguiente.

Nota:

Aunque el escenario que se describe 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.

Diagrama de los componentes de una solución de comprobación, que muestra el escenario de recuperación de la cuenta.

Otros elementos

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

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 y otras validaciones, registros, 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 la recuperación de cuentas.

Directorio empresarial de Microsoft Entra: Es el inquilino de Microsoft Entra que contiene las cuentas que se crean o actualizan a través del portal de cuentas.

Consideraciones de diseño

Correlación de atributos de VC con Microsoft Entra ID: Al definir los atributos de la VC en colaboración con el emisor, asegúrese de aceptar las notificaciones que identifiquen al usuario. Por ejemplo, si el proveedor de comprobación de identidades (IDV) comprueba la identidad antes de incorporar a los empleados, asegúrese de que el VC emitido incluya notificaciones que se puedan comparar con sistemas internos. Puede tratarse de 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 credenciales verificables con funcionalidades existentes de restablecimiento de credenciales de Microsoft Entra: Microsoft Entra ID 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 entregar una VC desde un emisor de prueba de identidad y presentarlo para recuperar su cuenta de forma remota.

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

Autorización: Cree un mecanismo de autorización, como un grupo de seguridad, que el usuario de confianza compruebe 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 una credencial verificable.

Interacción con Microsoft Entra ID: La comunicación de servicio a servicio entre el front-end web y Microsoft Entra debe protegerse como un sistema con privilegios elevados, dado que puede restablecer las credenciales de los empleados. Conceda al front-end web los roles con menos privilegios posibles. Estos son algunos ejemplos:

  • 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, que permite crear y eliminar usuarios.

  • Si el usuario de confianza 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 los recursos de Azure.

Planeación de la administración de identidades

A continuación se muestran algunas consideraciones sobre IAM al incorporar VC a los usuarios de confianza. En general, los usuarios de confianza son aplicaciones.

Authentication

  • 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 la credencial verificable también se pueden consumir para tomar decisiones de autorización detalladas.

  • Decida si una credencial verificable expirada tiene sentido en su aplicación; si es así, compruebe el valor de la notificación exp (la hora de expiración) de la credencial verificable como parte de las comprobaciones de autorización. Un ejemplo donde la expiración no es pertinente es cuando se exige un documento emitido por el Gobierno, como un permiso de conducir, para validar si el sujeto es mayor de 18 años. La notificación de fecha de nacimiento es válida, incluso si la credencial verificable ha expirado.

  • Determine si una credencial verificable revocada tiene sentido para la decisión de autorización.

    • Si no es pertinente, omita la llamada para comprobar la API de estado (que está activada de manera 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 quiere consumir atributos para crear un perfil, tenga en cuenta lo siguiente.

  • 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 una credencial verificable cada vez que el sujeto inicia una sesión con el usuario de confianza, considere la posibilidad de usar la salida de la presentación de la credencial verificable 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 las propiedades de usuario en reposo. Es posible que la aplicación tenga que guardar localmente los atributos del firmante. Si es así, guarde solo las notificaciones que necesita la 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 notificación sub como identificador inmutable del usuario. Se trata de un atributo único opaco que será constante para un par sujeto/RP de confianza determinado.

    • Defina un mecanismo para desaprovisionar el perfil de usuario de la aplicación. Debido a la naturaleza descentralizada del sistema Verified ID de Microsoft Entra, no hay ningún ciclo de vida de aprovisionamiento de usuarios en 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 la latencia, el rendimiento 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 se adopte una solución que conlleve la emisión de muchas credenciales verificables, la planeación del rendimiento puede 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 Id. verificada por Microsoft Entra se implementa en las regiones de Azure de Oeste de Europa, Norte de Europa, Oeste de EE. UU. 2 y Centro-oeste de EE. UU. Limite la latencia, implemente el front-end de verificación (sitio web) y el almacén de claves en la región más cercana.

  • Modelo basado en el rendimiento:

Planeación de la confiabilidad

Para planear mejor la alta disponibilidad y recuperación ante desastres, se recomienda lo siguiente:

  • El servicio Verified ID de Microsoft Entra se implementa en las regiones de Azure de 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 compatibles en una de esas regiones, específicamente en aquellas desde las que espera que se origine la mayor parte 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 para cumplir los objetivos de disponibilidad y redundancia.

Planear la seguridad

A medida que diseñe para cumplir con 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 de Id. verificada por Microsoft Entra y las entidades de servicio del sitio web deben tener permisos para usar Key Vault para firmar mensajes con la clave privada.

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

  • Revise Protección de entornos de Azure con Microsoft Entra para conocer los procedimientos recomendados para administrar los servicios compatibles de la solución.

  • Para mitigar los riesgos de suplantación de seguridad:

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

    • Use dominios que tengan significado 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. Para proteger el tráfico, se recomienda incorporar una autenticación alternativa o CAPTCHA antes de generar solicitudes de emisión.

Planeación de las operaciones

A medida que planee las operaciones, se recomienda que capture cada intento de validación de credenciales como parte de la auditoría. Use esa información para auditorías y solución de problemas. Además, considere la posibilidad de generar identificadores (Id.) de transacción únicos a los que los clientes e ingenieros de soporte técnico puedan hacer referencia de ser necesario.

Como parte del planeamiento operativo, considere supervisar lo siguiente:

  • Para la escalabilidad:

    • Supervise la validación de credenciales verificables con errores como parte de las métricas de seguridad de las aplicaciones de un extremo a otro.

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

  • Para la confiabilidad y las dependencias:

  • Para la seguridad:

    • Habilite el registro para Key Vault para hacer un seguimiento de las operaciones de firma, así como para supervisar y alertar sobre los cambios de configuración. Para más información, consulte 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.

Pasos siguientes

Más información sobre la arquitectura de las soluciones de credenciales verificables

Implementación de Verifiable Credentials

Preguntas más frecuentes