Implementación de la seguridad de red de API y protección contra amenazas

Completado

Las directivas de autenticación y autorización controlan quién puede llamar a las API. Los controles de seguridad de red abordan un riesgo diferente, lo que impide un consumo excesivo, bloquea las solicitudes de ubicaciones no autorizadas y reduce la superficie expuesta a ataques de la propia puerta de enlace. Estas capas funcionan junto con las directivas de identidad, no en lugar de ellas.

Filtrado de solicitudes por dirección IP

La directiva ip-filter permite o bloquea las solicitudes en función de la dirección IP de origen del autor de llamada o del rango de Enrutamiento entre dominios sin clase (CIDR). Evalúa la solicitud durante el procesamiento de entrada, antes de que se produzca cualquier enrutamiento o reenvío back-end.

Utilice una lista de permitidos cuando los socios de Contoso Retail se conecten desde intervalos IP fijos conocidos.

<inbound>
  <ip-filter action="allow">
    <address>203.0.113.0/24</address>
    <address>198.51.100.5</address>
  </ip-filter>
  <base />
</inbound>

Con action="allow", API Management acepta solicitudes solo de las direcciones enumeradas y los intervalos CIDR y rechaza todo lo demás con una 403 Forbidden respuesta. Con action="deny", se bloquean las solicitudes de las direcciones enumeradas y se permiten todas las demás direcciones IP de origen.

En el caso del producto de Contoso Retail destinado a partners, una lista de permitidos con los rangos de direcciones IP de salida de los partners restringe quién puede acceder al punto de conexión de entrada de la pasarela; incluso los usuarios que dispongan de una clave de suscripción válida se rechazan si su dirección IP de origen no figura en la lista.

Note

La ip-filter directiva evalúa la dirección IP tal como la ve API Management. Si los autores de llamadas llegan a la puerta de enlace a través de un proxy o una puerta de enlace NAT, API Management ve la dirección IP del proxy, no la dirección IP del cliente de origen. Tenga en cuenta esto al definir la lista de permitidos: agregue el intervalo IP de salida del proxy en lugar de direcciones de cliente internas individuales.

Aplicación de controles de cuota y limitación de velocidad

Las directivas de limitación de frecuencia y cuotas controlan el consumo de los usuarios. Tres políticas complementarias abordan diferentes horizontes temporales y contrarrestan estrategias clave.

La rate-limit directiva restringe las llamadas por suscripción en un breve período de tiempo:

<inbound>
  <rate-limit calls="100" renewal-period="60" />
  <base />
</inbound>

En este ejemplo se permiten 100 llamadas por ventana de 60 segundos por suscripción. Cuando un autor de llamada supera el límite, API Management devuelve 429 Too Many Requests. El contador se restablece automáticamente al final de cada período de renovación. Aplique esta directiva en el ámbito del producto para aplicar límites coherentes en todos los suscriptores del producto.

La rate-limit-by-key directiva aplica la limitación de velocidad basada en una clave de contador personalizada, cualquier expresión que se evalúe como una cadena que identifique al autor de la llamada:

<inbound>
  <rate-limit-by-key calls="30"
                     renewal-period="60"
                     counter-key="@(context.Request.IpAddress)" />
  <base />
</inbound>

Utilice rate-limit-by-key cuando quienes llaman no usan claves de suscripción o cuando desea aplicar una restricción secundaria basada en la dirección IP, independientemente de la identidad de suscripción. Puede generar la clave del contador a partir de una reclamación de un token web JSON (JWT), un valor de encabezado o cualquier otro atributo de la solicitud al que se pueda acceder a través del contexto de la expresión de la directiva.

La quota directiva aplica el número total de llamadas o los límites de ancho de banda durante un período más largo:

<inbound>
  <quota calls="10000" bandwidth="40960" renewal-period="2592000" />
  <base />
</inbound>

En este ejemplo se limita cada suscripción a 10 000 llamadas o 40 MB de datos transferidos por período de 30 días (2592 000 segundos). Cuando se agota la cuota, los llamantes reciben una 403 Forbidden respuesta hasta que se renueva el período.

La distinción entre rate-limit y quota refleja dos riesgos de consumo diferentes:

• rate-limit evita el abuso de picos de tráfico, es decir, que un autor de llamada sature la API con una gran cantidad de solicitudes en un breve lapso de tiempo.
• quota aplica límites de uso contractual, lo que garantiza que un suscriptor no supere su compromiso mensual de volumen.

Para Contoso Retail, aplique rate-limit en el ámbito del producto para proteger los sistemas backend frente a los picos de tráfico y quota en el mismo ámbito, para imponer asignaciones mensuales por suscripción que se alineen con los niveles de contrato de los socios.

Integración de API Management con Azure Virtual Network

El filtrado IP y la limitación de velocidad funcionan en el nivel de aplicación en un gateway accesible públicamente. La integración de red virtual (red virtual) adopta un enfoque más fundamental: quitar o restringir el propio punto de conexión público para que solo los usuarios de redes privadas puedan acceder a la puerta de enlace.

API Management admite dos modos de integración de red virtual:

El modo externo implementa API Management en una subred de red virtual mientras se mantiene una dirección IP orientada al público. La puerta de enlace acepta solicitudes de Internet y también puede comunicarse con recursos internos de red virtual, como las API de back-end que se ejecutan en máquinas virtuales, entornos de App Service o clústeres de Azure Kubernetes Service. Use el modo externo cuando los socios necesiten acceder a la API a través de Internet, pero los servicios back-end deban permanecer privados en la VNet, inaccesibles directamente desde fuera de la red virtual.

El modo interno implementa API Management completamente dentro de la red virtual sin ningún punto de conexión público. La puerta de enlace y el plano de administración solo son accesibles desde dentro de la red virtual o desde redes locales conectadas a través de VPN o Azure ExpressRoute. No se expone ninguna dirección IP pública. Utilice el modo interno cuando tanto los autores de las llamadas como los servicios de back-end se encuentren en redes privadas y nunca sea necesario acceder a la pasarela a través de la red pública de Internet. El modo interno proporciona el aislamiento de red más seguro de las dos opciones.

Important

Las funcionalidades de red virtual varían según el nivel. La inyección de VNet (aislamiento completo: sin dirección IP pública en la puerta de enlace) solo está disponible en los niveles Desarrollador, Premium (clásico) y Premium v2. Standard v2 solo admite la integración de VNet (solo conectividad saliente a backends privados; el punto de conexión sigue siendo accesible públicamente desde Internet). Los puntos de conexión privados (aislamiento de entrada sin inyección de red virtual completa) están disponibles en Developer, Basic, Standard, Standard v2, Premium y Premium v2. Seleccione un nivel que coincida con los requisitos de aislamiento antes de la implementación: cambiar los niveles después de la implementación inicial no es una operación sencilla.

Los puntos de conexión privados proporcionan una ruta de acceso de entrada alternativa para las instancias de nivel Premium. Un punto de conexión privado asigna a la puerta de enlace de API Management una dirección IP privada dentro de una red virtual sin insertar toda la instancia en la red virtual. Los clientes de la red virtual (o las redes conectadas) llegan a la puerta de enlace a través de la red troncal de Azure mediante esa dirección IP privada, mientras que la configuración de API Management permanece sin cambios. Esto resulta útil cuando se necesita acceso privado de entrada a una instancia existente sin migrar a una implementación de red virtual completa.

Para Contoso Retail, el modelo adecuado depende de quién consume la API:

• APIs destinadas a socios a las que los socios externos deben acceder a través de Internet: el modo externo con filtrado IP y limitación de velocidad proporciona aislamiento de back-end mientras se mantiene la puerta de enlace accesible públicamente.
• API de carga de trabajo de IA internas que solo utilizan los servicios propios de Contoso: el modo interno o un punto de conexión privado eliminan por completo la exposición pública, de modo que solo las aplicaciones de la red privada de Contoso pueden acceder a la pasarela.

Los controles de red reducen la superficie expuesta a ataques disponible para un posible atacante antes de que se apliquen las directivas de identidad. Junto con la autenticación y la autorización, crean una defensa estratificada en la que los solicitantes deben llegar desde la ubicación correcta, poseer la identidad correcta y permanecer dentro de los límites de consumo antes de que cualquier solicitud llegue al back-end.