Marco de modelo de aplicaciones seguras

Microsoft está introduciendo un marco seguro y escalable para autenticar asociados del proveedor de soluciones en la nube (CSP) y proveedores de Panel de control (CPV) a través de la arquitectura de autenticación multifactor (MFA) de Microsoft Azure. Los asociados de CSP y los proveedores de Panel de control pueden confiar en el nuevo modelo para elevar la seguridad de las llamadas de integración de api del Centro de partners. Esto ayuda a todas las partes, incluidos microsoft, asociados de CSP y proveedores de Panel de control a proteger sus datos de infraestructura y clientes frente a los riesgos de seguridad.

Ámbito

Este artículo se aplica a los siguientes asociados:

• Panel de control Proveedores (CPV) son proveedores de software independientes que desarrollan aplicaciones para que los asociados de CSP los usen para integrarse con las API del Centro de partners. Un CPV no es un asociado de CSP con acceso directo al panel o las API del asociado. Son las empresas que desarrollan aplicaciones (normalmente aplicaciones web) que permiten a los CSP vender sus productos a través de un marketplace unificado.
• Proveedores indirectos de CSP y partners directos de CSP que usan el id. de aplicación y la autenticación de usuario y se integran directamente con las API del Centro de partners.

Desarrollo seguro de aplicaciones

En el proceso de realizar pedidos para productos de Microsoft en nombre de CSP, las aplicaciones de Marketplace de los CPV interactúan con las API de Microsoft para realizar pedidos y aprovisionar recursos para los clientes.

Algunas de estas API incluyen:

• API del Centro de partners que implementan operaciones comerciales, como la realización de pedidos y la administración de ciclos de vida de las suscripciones.
• API de Microsoft Graph que implementan la administración de identidades para los inquilinos de CSP y los inquilinos del cliente de CSP.
• API de Azure Resource Manager (ARM) que implementan la funcionalidad de implementación de Azure.

Los asociados de CSP están capacitados con privilegios delegados para actuar en nombre de sus clientes al llamar a las API de Microsoft. Los privilegios delegados permiten a los asociados de CSP completar escenarios de compra, implementación y soporte técnico para sus clientes.

Las aplicaciones de Marketplace están diseñadas para ayudar a los asociados de CSP a enumerar sus soluciones para los clientes. Para ello, las aplicaciones de Marketplace deben suplantar privilegios de asociado de CSP para llamar a las API de Microsoft.

Dado que los privilegios de asociado de CSP son altos y proporcionan acceso a todos los clientes del asociado, es importante comprender cómo se deben diseñar estas aplicaciones para resistir los vectores de explotación de seguridad. Los ataques de seguridad en estas aplicaciones confidenciales pueden poner en peligro los datos de los clientes. Por lo tanto, las concesiones de permisos y la suplantación de privilegios de asociados deben diseñarse para seguir el principio de privilegios mínimos. Los siguientes principios y procedimientos recomendados garantizan que las aplicaciones de Marketplace sean sostenibles y puedan resistir los riesgos.

Principios de seguridad para la suplantación de credenciales

• Las aplicaciones de Marketplace no deben almacenar credenciales de asociados de CSP.

• Las contraseñas de usuario asociado de CSP no deben compartirse.

• Las claves de aplicación web del inquilino del asociado de CSP no deben compartirse con Panel de control Proveedores.

• Una aplicación de Marketplace debe presentar la identidad de la aplicación junto con la información del asociado, en lugar de usar solo credenciales de asociado al realizar llamadas que suplantan una identidad de asociado de CSP.

• El acceso a una aplicación de Marketplace debe basarse en el principio de privilegios mínimos y articular claramente en los permisos.

• La autorización de una aplicación de Marketplace debe dinamizarse en varias credenciales.

• Las credenciales de aplicación y las credenciales de asociado deben proporcionarse conjuntamente para obtener acceso.

  Importante

  Es importante que no haya un único punto de compromiso.

• El acceso debe estar restringido a una audiencia o API específica.

• El acceso debe identificar el propósito de la suplantación.

• Los permisos de acceso para una aplicación de Marketplace deben estar limitados a tiempo. Los asociados de CSP deben poder renovar o revocar el acceso a la aplicación de Marketplace.

• Los procesos de control o corrección rápidos deben estar en vigor para controlar los riesgos de las credenciales de la aplicación de Marketplace.

• Todas las cuentas de usuario deben usar la autenticación en dos fases (2FA).

• El modelo de aplicación debe ser descriptivo para las disposiciones de seguridad adicionales, como el acceso condicional a un mejor modelo de seguridad.

Identidad y conceptos de la aplicación

Aplicaciones multiinquilino

Una aplicación multiinquilino suele ser una aplicación de software como servicio (SaaS). Puede configurar la aplicación para que acepte inicios de sesión desde cualquier inquilino de Microsoft Entra configurando el tipo de aplicación como multiinquilino en el panel de Azure. Los usuarios de cualquier inquilino de Microsoft Entra podrán iniciar sesión en su aplicación después de dar su consentimiento para usar su cuenta con su aplicación.

Para obtener más información sobre la creación de una aplicación multiinquilino, consulte Inicio de sesión de cualquier usuario de Microsoft Entra mediante el patrón de aplicación multiinquilino.

Marco de consentimiento

Para que un usuario inicie sesión en una aplicación en microsoft Entra ID, la aplicación debe representarse en el inquilino del usuario, lo que permite a la organización hacer cosas como aplicar directivas únicas cuando los usuarios de su inicio de sesión de inquilino en la aplicación. Para una aplicación de inquilino único, este registro es sencillo: es el que se produce al registrar la aplicación en el panel de Azure.

Para una aplicación multiinquilino, el registro inicial de la aplicación reside en el inquilino de Microsoft Entra usado por el desarrollador. Cuando usuarios de otro inquilino inician sesión en la aplicación por primera vez,Microsoft Entra les pide que den su consentimiento a los permisos solicitados por ella. Si dan su consentimiento, se crea una representación de la aplicación denominada entidad de servicio en el inquilino del usuario y el proceso de inicio de sesión puede continuar. También se crea una delegación en el directorio que registra el consentimiento del usuario a la aplicación.

La experiencia de consentimiento se ve afectada por los permisos solicitados por la aplicación. Microsoft Entra ID admite dos tipos de permisos, solo aplicación y delegado.

• El permiso de solo aplicación se concede directamente a la identidad de la aplicación. Por ejemplo, puede conceder permiso a una aplicación para leer la lista de usuarios de un inquilino, independientemente de quién haya iniciado sesión en la aplicación.
• El permiso delegado concede a una aplicación la capacidad de actuar como un usuario que ha iniciado sesión para un subconjunto de las cosas que el usuario puede hacer. Por ejemplo, puede conceder a una aplicación el permiso delegado para leer el calendario del usuario que ha iniciado sesión.

Algunos permisos son consentidos por un usuario normal, mientras que otros requieren el consentimiento de un administrador de inquilinos. Para obtener más información sobre el marco de consentimiento de Microsoft Entra, consulte Descripción de las experiencias de consentimiento de aplicaciones de Microsoft Entra.

• Ámbitos, permisos y consentimiento en el punto de conexión v2.0 de Azure Active Directory
• Descripción del consentimiento del usuario y del administrador

Flujo de tokens de autorización abierta de aplicaciones multiinquilino (OAuth)

En un flujo de autorización abierta de aplicación multiinquilino (OAuth), la aplicación se representa como una aplicación multiinquilino en el inquilino del asociado de CPV o CSP.

Para acceder a las API de Microsoft (API del Centro de partners, API de Graph, etc.), los asociados de CSP deben iniciar sesión en la aplicación y dar su consentimiento para permitir que la aplicación llame a las API en su nombre.

La aplicación obtiene acceso a los recursos del asociado, como Graph y las API del Centro de partners, mediante concesiones de consentimiento y OAuth.

Creación de una aplicación multiinquilino

Una aplicación multiinquilino debe cumplir los siguientes requisitos:

• Debe ser una aplicación web con un identificador de aplicación y una clave secreta.
• Debe tener desactivado el modo de autenticación implícito.

Además, se recomienda cumplir estos procedimientos recomendados:

• Use un certificado para la clave secreta.
• Habilite el acceso condicional para aplicar restricciones de intervalo IP. Esto puede requerir que se habilite más funcionalidad en el inquilino de Microsoft Entra.
• Aplique directivas de vigencia del token de acceso para la aplicación.

Al adquirir un token, se debe presentar el identificador de la aplicación y la clave secreta. La clave secreta puede ser un certificado.

La aplicación se puede configurar para llamar a varias API, incluidas las API de Azure Resource Manager. A continuación se muestra el conjunto mínimo de permisos necesarios para las API del Centro de partners:

• Permisos delegados de Id. de Microsoft Entra: acceso al directorio como usuario que ha iniciado sesión
• Permisos delegados de las API del Centro de partners: Acceso

La aplicación captura el consentimiento del asociado

Una aplicación multiinquilino debe adquirir el consentimiento de los asociados y usar el consentimiento y conceder para realizar más llamadas a las API del Centro de partners. El consentimiento se adquiere a través de un flujo de código de autenticación de OAuth.

Para adquirir consentimiento, los CPV o los asociados de CSP deben crear un sitio web de incorporación que pueda aceptar una concesión de código de autenticación de Microsoft Entra ID.

Para más información, consulte Autorización del acceso a aplicaciones web de Azure Active and Directory mediante el flujo de concesión de código de OAuth 2.0.

Estos son los pasos para que una aplicación multiinquilino capture el consentimiento del asociado de CSP junto con un token reutilizable para realizar llamadas a las API del Centro de partners.

Siga estos pasos para adquirir el consentimiento del asociado.

1. Cree una aplicación web de incorporación de asociados que pueda hospedar un vínculo de consentimiento para que el asociado haga clic para aceptar el consentimiento de la aplicación multiinquilino.
2. El asociado de CSP hace clic en el vínculo de consentimiento. Por ejemplo: https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
3. La página de inicio de sesión de Microsoft Entra explica los permisos que se concederán a la aplicación en nombre del usuario. El asociado de CSP puede decidir usar las credenciales del Agente de administración o del Agente de ventas para iniciar sesión y aprobar el consentimiento. La aplicación tiene permisos basados en el rol de usuario que se usa para iniciar sesión.
4. Una vez concedido el consentimiento, Microsoft Entra ID crea una entidad de servicio de la aplicación multiinquilino de CPV en el inquilino del asociado de CSP. La aplicación recibe concesiones de OAuth para actuar en nombre del usuario. Estas concesiones permiten que la aplicación multiinquilino llame a las API del Centro de partners en nombre del asociado. En este momento, la página de inicio de sesión de Microsoft Entra redirige a la aplicación web de incorporación de asociados. La aplicación web recibe un código de autorización de Microsoft Entra ID. La aplicación web de incorporación de asociados debe usar el código de autorización junto con el identificador de aplicación y la clave secreta para llamar a la API de tokens de id. de Entra de Microsoft para obtener un token de actualización.
5. Almacene de forma segura el token de actualización. El token de actualización forma parte de las credenciales de asociado que se usan para obtener acceso a las API del Centro de partners en nombre del asociado. Una vez adquirido el token de actualización, cifrelo y almacénelo en un almacén de claves secretas, como el almacén de claves de Azure.

Flujo de llamadas de solicitud de token

Las CPV o la aplicación del asociado de CSP deben adquirir un token de acceso antes de realizar llamadas a las API del Centro de partners. Estas API se representan en la dirección URL https://api.partnercenter.microsoft.comdel recurso .

Una aplicación CPV debe identificar qué cuenta de asociado debe suplantar para llamar a las API del Centro de partners basadas en el inicio de sesión federado o del producto. La aplicación recupera el token de actualización cifrado para ese inquilino del asociado del almacén de claves secretas. El token de actualización debe descifrarse antes de usarlo.

En el caso de los partners de CSP en los que solo haya un inquilino que dé su consentimiento, la cuenta de asociado hace referencia al inquilino del asociado de CSP.

El token de actualización es un token de varias audiencias. Esto significa que el token de actualización se puede usar para obtener un token para varias audiencias en función del consentimiento concedido. Por ejemplo, si se da consentimiento de asociado para las API del Centro de partners y las API de Microsoft Graph, el token de actualización se puede usar para solicitar un token de acceso para ambas API. El token de acceso tiene la concesión "en nombre de" y permite a una aplicación de Marketplace suplantar al asociado que consiente al llamar a estas API.

Se puede adquirir un token de acceso para una sola audiencia a la vez. Si una aplicación necesita acceder a varias API, debe solicitar varios tokens de acceso para la audiencia de destino. Para solicitar un token de acceso, la aplicación debe llamar a la API de tokens de identificador de Entra de Microsoft. Como alternativa, también podría usar authenticationContext.AcquireTokenAsync del SDK de Microsoft Entra y pasar la siguiente información:

• Dirección URL del recurso, que es la dirección URL del punto de conexión para que se llame a la aplicación. Por ejemplo, la dirección URL del recurso de la API del Centro de partners de Microsoft es https://api.partnercenter.microsoft.com.
• Credenciales de aplicación que constan del identificador de aplicación y la clave secreta de la aplicación web.
• El token de actualización

El token de acceso resultante permite a la aplicación realizar llamadas a las API que se mencionan en el recurso. La aplicación no puede solicitar un token de acceso para las API que no se concedieron permiso como parte de la solicitud de consentimiento. El valor del atributo UserPrincipalName (UPN) es el nombre de usuario de Microsoft Entra para las cuentas de usuario.

Más consideraciones

Acceso condicional

Cuando se trata de administrar los recursos en la nube, un aspecto clave de la seguridad en la nube es la identidad y el acceso. En un mundo de primera nube, primero en la nube, los usuarios pueden acceder a los recursos de su organización mediante varios dispositivos y aplicaciones desde cualquier lugar. Simplemente centrarse en quién puede acceder a un recurso ya no es suficiente. Para dominar el equilibrio entre seguridad y productividad, también debe tener en cuenta cómo se accede a un recurso. Mediante el acceso condicional de Microsoft Entra, puede abordar este requisito. Con el acceso condicional, puede implementar decisiones de control de acceso automatizadas para acceder a las aplicaciones en la nube en función de condiciones.

Para obtener más información, consulte ¿Qué es el acceso condicional en microsoft Entra ID?

Restricciones basadas en intervalos IP

Puede restringir los tokens que se van a emitir solo a un intervalo específico de direcciones IP. Esta característica ayuda a restringir el área expuesta de ataque solo a una red específica.

Autenticación multifactor

La aplicación de la autenticación multifactor ayuda a restringir las situaciones de peligro de credenciales mediante la aplicación de la comprobación de credenciales en dos o más formularios. Esta característica permite a Microsoft Entra ID validar la identidad del autor de la llamada a través de canales secundarios seguros, como el móvil o el correo electrónico, antes de emitir tokens.

Para más información, consulte Funcionamiento: Azure Multi.

Contenido relacionado

• Configuración de una nueva aplicación multiinquilino-
• Autorización del acceso a aplicaciones web de Microsoft Entra mediante el flujo de concesión de código OAuth 2.0
• Funcionamiento del consentimiento de la aplicación
• Referencia de API REST del Centro de partners