Editar

Restricción de comunicaciones entre servicios

Azure
Microsoft Entra ID
Azure App Service

Este escenario de ejemplo restringe las comunicaciones entre dos servicios de back-end de Azure en los niveles de la aplicación y de la red. Las comunicaciones solo pueden fluir entre servicios que lo permiten de manera explícita, respetando el principio de privilegios mínimos. En este ejemplo se usa Azure App Service para hospedar los servicios, aunque puede usar técnicas similares para las aplicaciones de Azure Functions.

Las restricciones de las comunicaciones entre servicios son solo una parte de una estrategia de seguridad general basada en una planeación cuidadosa, modelado de riesgos y ciclo de vida de desarrollo de seguridad. La planeación general de la seguridad debe incorporar requisitos empresariales, de cumplimiento, normativos y otros no funcionales.

Posibles casos de uso

Aunque el escenario actual se centra en las restricciones de red, muchas organizaciones ahora adoptan un modelo de seguridad de Confianza cero en el que se da por supuesto que hay una vulneración, por lo que la capa de redes tiene una importancia secundaria.

Architecture

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

Descargue un archivo de Visio de esta arquitectura.

Flujo de datos

El diagrama muestra las comunicaciones restringidas del servicio A al servicio B. La autorización basada en tokens restringe el acceso en el nivel de aplicación y los puntos de conexión de servicio restringen el acceso en el nivel de red.

Autenticación basada en tokens

Una biblioteca compatible con OpenID Connect (OIDC), como la biblioteca de autenticación de Microsoft (MSAL) admite este flujo de credenciales de cliente basado en tokens. Para obtener más información, consulte Escenario: Aplicación de demonio que llama a las API web y la aplicación de ejemplo para el escenario de demonio.

  1. Tanto el servicio A como el servicio B se registran en Microsoft Entra ID. El servicio A tiene credenciales de cliente, ya sea como secreto compartido o como certificado.
  2. El servicio A puede usar sus propias credenciales de cliente para solicitar un token de acceso para el servicio B.
  3. Microsoft Entra ID proporciona un token de acceso con un público del servicio B o una notificación aud.
  4. El servicio A inserta el token como un token de portador en el encabezado de autorización HTTP de una solicitud que se envía al servicio B, de acuerdo con la especificación de uso de tokens de portador de OAuth 2.0.
  5. El servicio B valida el token para asegurarse de que la notificación aud coincide con la aplicación del servicio B.

El servicio B usa uno de los métodos siguientes para asegurarse de que solo los clientes permitidos específicamente puedan obtener acceso; en este caso, el servicio A:

  • Valida la notificación de appid de token. El servicio B puede validar la notificación appID del token, que identifica qué aplicación registrada en Microsoft Entra ha solicitado el token. El servicio B comprueba explícitamente la notificación en una lista de autores de llamada de control de acceso conocidos.

  • Comprueba los roles del token. Del mismo modo, el servicio B puede comprobar una notificación de roles específica en el token entrante para asegurarse de que el servicio A tiene permisos de acceso explícitos.

  • Requiere la asignación de usuario. El propietario o el administrador del servicio B también puede configurar Microsoft Entra ID para que exija la asignación de usuarios, de modo que solo las aplicaciones que tienen permisos explícitos para la aplicación de servicio B puedan obtener un token para el servicio B. Por tanto, el servicio B no necesita comprobar si hay roles específicos, a menos que la lógica de negocios lo requiera.

    Para configurar un requisito de asignación de usuarios para tener acceso al servicio B, haga lo siguiente:

    1. En Microsoft Entra ID, habilite la asignación de usuarios en el servicio B.
    2. Exponga al menos un rol de aplicación del servicio B al que el servicio A pueda solicitar permiso. El elemento AllowedMemberTypes de este rol debe incluir Application.
    3. Solicite permiso de aplicación para el servicio A para el rol expuesto del servicio B.
      1. En la sección Permisos de API del registro de aplicación del servicio A, seleccione Agregar un permiso y, a continuación, seleccione la aplicación del servicio B en la lista.
      2. En la pantalla Solicitud de permisos de API, seleccione Permisos de aplicación, ya que esta aplicación de back-end se ejecuta sin un usuario con sesión iniciada. Seleccione el rol expuesto del servicio B y, a continuación, seleccione Agregar permisos.
    4. Otorgue consentimiento de administrador a la solicitud de permisos de la aplicación del servicio A. Solo un propietario o administrador del servicio B puede dar su consentimiento a la solicitud de permisos del servicio A.

Puntos de conexión del servicio

La mitad inferior del diagrama de arquitectura muestra cómo restringir las comunicaciones entre servicios en el nivel de red:

  1. La aplicación web del servicio A usa la integración de redes virtuales regionales para enrutar todas las comunicaciones salientes a través de una dirección IP privada dentro del intervalo IP de la subred de integración.
  2. El servicio B tiene puntos de conexión de servicio que permiten las comunicaciones entrantes solo de las aplicaciones web en la subred de integración del servicio B.

Para más información, consulte Configuración de las restricciones de acceso de Azure App Service.

Componentes

En este escenario se usan los siguientes servicios de Azure:

  • Azure App Service hospeda tanto al servicio A como al servicio B, lo que permite la escalabilidad automática y la alta disponibilidad sin tener que administrar la infraestructura.
  • Microsoft Entra ID es el servicio de administración de identidades y acceso basado en la nube que autentica los servicios y habilita la autorización basada en tokens de OAuth 2.0.
  • Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Azure Virtual Network permite que los recursos, como las máquinas virtuales (VM) de Azure, se comuniquen de manera segura entre sí, con Internet y con redes locales.
  • Los puntos de conexión de servicio de Azure ofrecen conectividad directa y segura a los servicios de Azure a través de una ruta optimizada en la red troncal de Azure; además, solo permiten el acceso desde el intervalo de direcciones IP de origen privado en la subred de integración.
  • La biblioteca de autenticación de Microsoft (MSAL) es una biblioteca compatible con OIDC que permite a un servicio capturar tokens de acceso de Microsoft Entra ID mediante un flujo de credenciales de cliente.

Alternativas

Hay varias alternativas para el escenario de ejemplo.

Identidad administrada

En lugar de registrarse como una aplicación con Microsoft Entra ID, el servicio A podría usar una identidad administrada para capturar un token de acceso. La identidad administrada libera a los operadores de tener que administrar las credenciales de un registro de aplicaciones.

Mientras que una identidad administrada permite que el servicio A recupere un token, no proporciona un registro de aplicación de Microsoft Entra. Para que otros servicios soliciten un token de acceso para el servicio A, este aún necesita un registro de aplicación de Microsoft Entra.

No se puede asignar una identidad administrada a un rol de aplicación a través de Azure Portal; solo es posible a través de la línea de comandos de Azure PowerShell. Para más información, consulte Asignación de acceso de identidad administrada a un rol de aplicación mediante PowerShell.

Azure Functions

Puede hospedar los servicios en Azure Functions, en lugar de App Service. Para restringir el acceso en el nivel de red mediante la integración de redes virtuales regionales, debe hospedar las aplicaciones de funciones en un plan de App Service o un plan Premium. Para obtener más información, vea las opciones de red de Azure Functions.

Autenticación y autorización integradas de App Service

Por diseño, este escenario coloca el código de autorización con el resto de la lógica de negocios al validar tokens como parte del código de la aplicación. La autenticación y autorización integradas de App Service, o Easy Auth, también puede realizar la validación básica de los tokens antes de enviar una solicitud a un servicio. Después, el servicio depende de la infraestructura de hospedaje para rechazar las solicitudes no autorizadas.

Para configurar la autenticación y autorización de App Service, establezca el comportamiento de autorización en Iniciar sesión con Microsoft Entra ID. Esta configuración valida los tokens y restringe el acceso a solo los tokens válidos.

La desventaja de usar Easy Auth es que el servicio pierde la protección de autenticación y autorización si se transfiere a otra parte. Mientras que la autenticación y autorización de App Service funcionan para escenarios simples, los requisitos de autorización complejos deben usar una lógica integrada en el código de la aplicación.

Puntos de conexión de servicio frente a puntos de conexión privados

En este escenario se usan puntos de conexión de servicio en lugar de puntos de conexión privados porque solo los puntos de conexión de servicio permiten restringir el acceso a una aplicación web desde una subred determinada. No se admite el filtrado de tráfico entrante en los puntos de conexión privados a través de grupos de seguridad de red (NSG) o mediante restricciones de acceso de App Service. Todos los servicios con línea de visión de red pueden comunicarse con el punto de conexión privado de una aplicación web. Esto limita la utilidad del punto de conexión privado para bloquear el tráfico en el nivel de red.

Consideraciones

  • La integración de redes virtuales regionales de App Service ofrece una única subred de integración para cada plan de App Service. Todas las aplicaciones web del mismo plan se integran con la misma subred y comparten el mismo conjunto de direcciones IP salientes privadas. Los servicios de recepción no pueden distinguir de qué aplicación web se origina el tráfico. Si necesita identificar la aplicación web de origen, debe implementar las aplicaciones web en planes de App Service independientes, cada uno con su propia subred de integración.

  • Cada instancia de trabajo de un plan de App Service ocupa una dirección IP privada independiente dentro de la subred de integración. Para planificar la escala, asegúrese de que la subred de integración sea lo suficientemente grande como para acomodar la escala prevista.

Optimización de costos

Los precios de este escenario dependen de la infraestructura y requisitos específicos. Microsoft Entra ID tiene niveles Gratis hasta Premium, en función de las necesidades. Los costos de Azure App Service u otros hosts varían según los requisitos específicos de escala y seguridad, tal y como se describe en Alternativas y Consideraciones.

Para calcular los costos de su escenario, consulte la Calculadora de precios de Azure.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Pasos siguientes