Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID

La seguridad es un concepto importante cuando se registra una aplicación en Microsoft Entra ID y es una parte crítica de su uso empresarial en la organización. Cualquier configuración incorrecta de la aplicación puede provocar tiempo de inactividad o situaciones de riesgo. Dependiendo de los permisos que se agregan a una aplicación, puede haber consecuencias en toda la organización.

Dado que las aplicaciones seguras son esenciales para la organización, cualquier tiempo de inactividad debido a problemas de seguridad puede afectar a la empresa o a algún servicio crítico del que depende esta. Por lo tanto, es importante asignar tiempo y recursos para asegurarse de que las aplicaciones siempre permanezcan en un estado correcto y seguro. Se recomienda realizar una evaluación periódica de la seguridad y el mantenimiento de las aplicaciones, de forma muy similar a una evaluación del modelo de amenazas de seguridad para el código. Para obtener una perspectiva más amplia de la seguridad de organizaciones, consulte el Ciclo de vida de desarrollo de seguridad (SDL).

En este artículo se describen los procedimientos recomendados de seguridad para las siguientes propiedades y escenarios de aplicación:

• Tipo de identidad
• Credenciales
• URI de redirección
• Configuración de flujo implícito
• URI de identificador de aplicación (también conocido como URI de identificador)
• Versión del token de acceso
• Bloqueo de instancia de aplicación
• Propiedad de la aplicación

Tipo de identidad

Es probable que aquí obtenga información sobre los procedimientos recomendados de seguridad para aplicaciones de Microsoft Entra , también conocidos como registros de aplicaciones o objetos de aplicación. Sin embargo, hay otro tipo de identidad que se puede usar para acceder a recursos protegidos por Entra, denominados identidades administradas para recursos de Azure.

Las identidades administradas de Azure son seguras de forma predeterminada y requieren poco o ninguna sobrecarga o mantenimiento continuo. Considere la posibilidad de usar una identidad administrada en lugar de una aplicación de Microsoft Entra para la identidad de la aplicación si se cumplen todas las siguientes opciones:

• El servicio se ejecuta en la nube de Azure.
• La aplicación no necesita iniciar sesión de los usuarios
• La aplicación no necesita actuar como recurso en un flujo de token (no es una API web).
• La aplicación no necesita funcionar en varios inquilinos.

Tenga en cuenta que las identidades administradas se pueden usar para acceder a recursos fuera de Azure, incluido Microsoft Graph.

En el resto de este artículo se tratan las prácticas recomendadas de seguridad para las propiedades de los registros de aplicaciones de Entra.

Credenciales (incluidos certificados y secretos)

Las credenciales son una parte vital de una aplicación cuando se usa como cliente confidencial. En la página Certificados y secretos de la aplicación en Azure Portal, se pueden agregar o quitar credenciales.

Tenga en cuenta las siguientes instrucciones relacionadas con certificados y secretos:

• Use una identidad administrada como credencial siempre que sea posible. Se recomienda encarecidamente, ya que las identidades administradas son la opción más segura y no requieren ninguna administración de credenciales en curso. Siga estas instrucciones para configurar una identidad administrada como credencial. Sin embargo, esta opción solo puede ser posible si el servicio en el que se usa la aplicación se ejecuta en Azure.
• Si el servicio en el que se usa la aplicación no se ejecuta en Azure, pero se ejecuta en otra plataforma que ofrece administración automatizada de credenciales, considere la posibilidad de usar una identidad de esa plataforma como credencial. Por ejemplo, un flujo de trabajo de acciones de GitHub se puede configurar como una credencial, lo que elimina la necesidad de administrar y proteger las credenciales de la canalización de acciones de GitHub. Tenga cuidado con este enfoque y configure solo las credenciales federadas a partir de plataformas de confianza. Una aplicación solo es tan segura como la plataforma de identidad que ha configurado como una credencial.
• Si no es posible usar una identidad administrada u otro proveedor de identidades externo seguro, use las credenciales de certificado. No use credenciales de contraseña, también conocidas como secretos. Aunque es conveniente usar secretos de contraseña como credenciales, las credenciales de contraseña a menudo se administran mal y se pueden comprometer fácilmente.
• Si se debe usar un certificado en lugar de una identidad administrada, almacene ese certificado en un almacén de claves seguro, como Azure Key Vault.
• Si se debe usar un certificado en lugar de una identidad administrada, use un certificado de una entidad de certificación (CA) de confianza en lugar de un certificado autofirmado. Configure una directiva para exigir que los certificados provengan de emisores de confianza. Sin embargo, si no es posible usar una entidad de certificación de confianza, los certificados autofirmados son preferibles a las contraseñas.
• Configure las directivas de administración de aplicaciones para controlar el uso de secretos limitando sus duraciones o bloqueando su uso por completo.
• Si una aplicación solo se usa como cliente público o instalado (por ejemplo, aplicaciones móviles o de escritorio instaladas en el equipo del usuario final), asegúrese de que no haya credenciales especificadas en el objeto de aplicación.
• Revise las credenciales que se usan en las aplicaciones para comprobar su estado de uso y su fecha de expiración. Las credenciales sin usar de una aplicación pueden provocar una vulneración de la seguridad. Sustituya las credenciales con frecuencia y no comparta credenciales entre aplicaciones. Se recomienda no tener muchas credenciales en una aplicación.
• Supervise las canalizaciones de producción para asegurarse de que no haya credenciales de ningún tipo que se confirmen en repositorios de código. Credential Scanner es una herramienta de análisis estático que se puede usar para detectar credenciales (y otro contenido confidencial) en el código fuente y la salida de compilación.

URI de redirección

Es importante mantener actualizados los URI de redireccionamiento de su aplicación. En la opción de Autenticación de la aplicación en Azure Portal, debe seleccionar una plataforma para la aplicación y, a continuación, puede definir la propiedad URI de redirección.

Tenga en cuenta las siguientes instrucciones para los URI de redireccionamiento:

• Mantener la propiedad de todos los URI. Un fallo en la propiedad de uno de los URI puede poner en peligro las aplicaciones.
• Asegúrese de que todos los registros DNS se actualicen y supervisen de forma periódica en busca de cambios.
• No use direcciones URL de carácter comodín ni esquemas de URI que no sean seguros, como http o URN.
• Mantenga la lista pequeña. Recorte los URI innecesarios. Si es posible, actualice las direcciones URL del esquema HTTP al HTTPS.

Configuración de flujo implícito

Los escenarios que necesitan un flujo implícito ahora pueden usar el flujo de código de autorización para reducir el riesgo de compromiso asociado a un uso incorrecto del flujo implícito. En la opción de Autenticación de la aplicación en Azure Portal, debe seleccionar una plataforma para la aplicación y, a continuación, puede definir la propiedad Tokens de acceso (usados para flujos implícitos).

Tenga en cuenta las instrucciones siguientes relacionadas con el flujo implícito:

• Compruebe si necesita un flujo implícito. No use un flujo implícito a menos que sea expresamente necesario.
• Si la aplicación se configuró para recibir tokens de acceso mediante flujo implícito, pero no las usa de forma activa, desactive la configuración para protegerla contra un uso incorrecto.
• Use aplicaciones independientes para escenarios de flujos implícitos válidos.

URI de identificador de aplicación (también conocido como URI de identificador)

La propiedad URI de AppId de la aplicación especifica el URI único global que se usa para identificar la API web. Es el prefijo del valor de ámbito en las solicitudes a Microsoft Entra. También es el valor de la notificación de audiencia (aud) en los tokens de acceso v1.0. Para las aplicaciones multiinquilino, el valor también debe ser único globalmente. También se conoce como URI de identificador. En Exponer una API para la aplicación en Azure Portal, se puede definir la propiedad URI AppId.

Procedimientos recomendados para definir el cambio de URI del identificador de aplicación en función de si la aplicación se emite tokens de acceso v1.0 o v2.0. Si no está seguro de si una aplicación está emitiendo tokens de acceso v1.0, compruebe el requestedAccessTokenVersion del manifiesto de la aplicación . Un valor de null o 1 indica que la aplicación recibe tokens de acceso v1.0. Un valor de 2 indica que la aplicación recibe tokens de acceso v2.0.

En el caso de las aplicaciones que se emiten tokens de acceso v1.0, solo se deben usar los URI predeterminados. Los URI predeterminados son api://<appId> y api://<tenantId>/<appId>. - Configure la restricción en las nonDefaultUriAdditiondirectivas de administración de aplicaciones para aplicar este procedimiento recomendado para futuras actualizaciones de las aplicaciones de su organización.

En el caso de las aplicaciones que se emiten tokens de acceso v2.0, use las instrucciones siguientes al definir el URI del identificador de aplicación:

• Se recomiendan los esquemas de URI api o https. Establezca la propiedad en los formatos admitidos para evitar colisiones de URI en la organización. No use caracteres comodín.
• Use un dominio comprobado de su organización.
• Se recomienda llevar a cabo un inventario de los URI de su organización para mantener la seguridad.

Se admiten los siguientes formatos de URI de identificador de aplicación basados en esquemas HTTP y API. Reemplace los valores de marcador de posición como se describe en la lista que sigue a la tabla.

Identificadores de aplicación admitidos Formatos de URI	Ejemplos de URI de id. de aplicación
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi
api://<string>.<verifiedCustomDomainOrInitialDomain>/<string>	api://contoso.com/productsapi

• <appId>: propiedad de identificador de aplicación (appId) del objeto de aplicación.
• <string>: valor de cadena para el host o el segmento de trazado de API.
• <tenantId>: GUID generado por Azure para representar el inquilino dentro de Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, donde <tenantInitialDomain> es el nombre de dominio inicial que el creador del inquilino especificó durante la creación del inquilino.
• <verifiedCustomDomain>: un dominio personalizado verificado configurado para el inquilino de Microsoft Entra.

Nota

Si usa el esquema api://, se agrega un valor de cadena directamente después de "api://". Por ejemplo, api://<string>. Ese valor de cadena puede ser un GUID o una cadena arbitraria. Si agrega un valor GUID, debe coincidir con el identificador de la aplicación o con el identificador de inquilino. Si usa un valor de cadena, debe usar un dominio personalizado verificado o un dominio inicial del inquilino. La recomendación es usar api://<appId>.

Importante

El valor de URI del id. de aplicación no debe terminar con un carácter de barra diagonal "/".

Importante

El valor de URI del identificador de aplicación debe ser único en el inquilino.

Versión del token de acceso

Esta sección solo se aplica a las aplicaciones de recursos, es decir, aquellas que funcionan como audiencia en los tokens de acceso. Las aplicaciones de recursos suelen ser API web. Si una aplicación solo actúa como cliente (lo que significa que adquiere tokens para enviar a recursos como Microsoft Graph), esta sección no se aplica.

Las aplicaciones de recursos que han configurado URI de identificador personalizado deben usar el formato de token de acceso v2.0. Para comprobar si una aplicación debe usar tokens de acceso v2.0, examine la propiedad identifierUris en la página de manifiesto de Registro de aplicaciones de la aplicación.

Si hay algún valor configurado no en el formato api://{appId} o api://{tenantId}/{appId}, la aplicación debe usar tokens de acceso v2.0.

Para actualizar a los tokens de acceso v2.0, asegúrese primero de que la aplicación pueda manejar los atributos del token v2.0. A continuación, actualice la versión del token de acceso que la aplicación emite mediante el editor de manifiestos.

Una vez actualizada la configuración de la aplicación para usar tokens v2.0, asegúrese de que la lógica de validación de audiencia de la aplicación se modifica para aceptar solo su appId.

Bloqueo de propiedad de instancia de una aplicación

Cuando una aplicación tiene una entidad de servicio aprovisionada en un inquilino, un administrador de inquilinos puede personalizar esa entidad de servicio. Esto es cierto independientemente de si ese inquilino es el inquilino principal de la aplicación o un inquilino externo. Esas capacidades de personalización pueden permitir modificaciones que el propietario de la aplicación no esperaba, lo que provoca riesgos de seguridad. Por ejemplo, las credenciales se pueden agregar al principal de servicio, aunque normalmente deben pertenecer al desarrollador y propietario de la aplicación, que se encarga de controlarlas.

Para reducir este riesgo, las aplicaciones deben configurar el bloqueo de instancia de la aplicación. Al configurar el bloqueo de instancia de la aplicación, bloquee siempre todas las propiedades confidenciales disponibles. La configuración de esta propiedad es especialmente importante para las aplicaciones multiinquilino, es decir, aplicaciones usadas en varios inquilinos u organizaciones, pero también deben establecerla todas las aplicaciones.

Permisos

Es posible que sea necesario conceder permisos a la aplicación para acceder a los recursos protegidos o a las API. Al solicitar permisos, asegúrese siempre de lo siguiente:

• Siga los principios de privilegios mínimos . Solicite solo el permiso que concede el acceso menos permisivo necesario para realizar la acción que debe realizar la aplicación. Si llama a Microsoft Graph, use la documentación de API para identificar el permiso menos permisivo para una determinada llamada a la API. Revise periódicamente los permisos de la aplicación para comprobar si hay disponible una opción con menos privilegios. Si una aplicación ya no necesita un permiso, quítelo.
• Siempre que sea posible, use el acceso delegado en lugar del acceso solo a la aplicación.
• Revise los permisos y la documentación de consentimiento para asegurarse de que comprende los aspectos básicos de los permisos.

Configuración de la propiedad de la aplicación

Los propietarios pueden administrar todos los aspectos de una aplicación registrada. Es importante revisar de forma periódica la propiedad de todas las aplicaciones de la organización. Para obtener más información, consulte Revisiones de acceso de Microsoft Entra. En Propietarios de la aplicación en Azure Portal, se pueden administrar los propietarios de la aplicación.

Tenga en cuenta las siguientes instrucciones relacionadas con la especificación de propietarios de aplicaciones:

• La propiedad de la aplicación debe mantenerse en manos de un conjunto mínimo de personas de la organización.
• Un administrador debe revisar la lista de propietarios una vez cada pocos meses, para así asegurarse de que los propietarios siguen formando parte de la organización y, por tanto, deben continuar siendo propietarios de la aplicación.

Comprobación de las recomendaciones de Entra

La característica recomendaciones de Microsoft Entra ayuda a supervisar el estado del inquilino para que no tenga que hacerlo. Estas recomendaciones ayudan a garantizar que el inquilino esté en un estado seguro y correcto. A la vez, le ayudan a maximizar el valor de las características disponibles en Microsoft Entra ID. Revise periódicamente las recomendaciones activas de Microsoft Entra relacionadas con las propiedades de la aplicación o la configuración de la aplicación para mantener el ecosistema de aplicaciones en un estado correcto.