Redes y conectividad para las cargas de trabajo críticas en Azure

Las redes son un área fundamental para una aplicación crítica, dado el enfoque de diseño activo-activo distribuido globalmente recomendado.

En este área de diseño se exploran varios temas de topología de red en un nivel de aplicación, teniendo en cuenta la conectividad necesaria y la administración redundante del tráfico. Más concretamente, resalta las consideraciones críticas y las recomendaciones destinadas a informar al diseño de una topología de red global segura y escalable para una aplicación crítica.

Enrutamiento de tráfico global

El uso de varias marcas de implementación regionales activas requiere un servicio de enrutamiento global para distribuir el tráfico a cada stamp activo.

Azure Front Door, Azure Traffic Manager y Azure Standard Load Balancer proporcionan las funcionalidades de enrutamiento necesarias para administrar el tráfico global en una aplicación de varias regiones.

Como alternativa, se pueden considerar tecnologías de enrutamiento global de terceros. Estas opciones se pueden intercambiar casi sin problemas en para reemplazar o ampliar el uso de servicios de enrutamiento global nativos de Azure. Entre las opciones más populares se incluyen las tecnologías de enrutamiento por parte de los proveedores de CDN.

En esta sección se exploran las diferencias clave de los servicios de enrutamiento de Azure para definir cómo se puede usar cada uno para optimizar diferentes escenarios.

Consideraciones de diseño

• Un servicio de enrutamiento enlazado a una sola región representa un único punto de error y un riesgo significativo con respecto a las interrupciones regionales.

• Si la carga de trabajo de la aplicación abarca el control de cliente, como con aplicaciones cliente móviles o de escritorio, es posible proporcionar redundancia del servicio dentro de la lógica de enrutamiento de cliente.

  • Varias tecnologías de enrutamiento global, como Azure Front Door y Azure Traffic Manager, se pueden considerar en paralelo para la redundancia, con clientes configurados para conmutar por error a una tecnología alternativa cuando se cumplen determinadas condiciones de error. La introducción de varios servicios de enrutamiento global presenta complejidades significativas en torno al almacenamiento en caché perimetral y las funcionalidades de firewall de aplicaciones web, y la administración de certificados para la descarga SSL y la validación de aplicaciones para las rutas de acceso de entrada.
  • También se pueden considerar tecnologías de terceros, lo que proporciona resistencia de enrutamiento global a todos los niveles de errores de la plataforma Azure.

• La disparidad de funcionalidades entre Azure Front Door y Traffic Manager significa que si las dos tecnologías se colocan junto entre sí para la redundancia, se requiere una ruta de acceso de entrada o cambios de diseño diferentes para garantizar que se mantenga un nivel de servicio coherente y aceptable.

• Azure Front Door y Azure Traffic Manager son servicios distribuidos globalmente con redundancia y disponibilidad integradas en varias regiones.

  • Los escenarios hipotéticos de error de una escala lo suficientemente grande como para amenazar la disponibilidad global de estos servicios de enrutamiento resistente presentan un riesgo más amplio para la aplicación en términos de errores en cascada y correlacionados.
    • Los escenarios de error de esta escala solo se deben a servicios fundamentales compartidos, como Azure DNS o microsoft Entra ID, que sirven como dependencias de plataforma global para casi todos los servicios de Azure. Si se aplica una tecnología redundante de Azure, es probable que el servicio secundario también esté experimentando una falta de disponibilidad o un servicio degradado.
    • Es muy probable que los escenarios de error del servicio de enrutamiento global afecten significativamente a muchos otros servicios que se usan para los componentes clave de la aplicación a través de dependencias entre servicios. Incluso si se usa una tecnología de terceros, es probable que la aplicación esté en un estado incorrecto debido al impacto más amplio del problema subyacente, lo que significa que el enrutamiento a los puntos de conexión de la aplicación en Azure proporciona poco valor de todos modos.

• La redundancia del servicio de enrutamiento global proporciona mitigación para un número extremadamente pequeño de escenarios de error hipotéticos, donde el impacto de una interrupción global está restringido al propio servicio de enrutamiento.

  Para proporcionar redundancia más amplia a escenarios de interrupción global, se puede considerar un enfoque de implementación activo-activo multinube. Un enfoque de implementación activo-activo multinube presenta complejidades operativas significativas, que suponen riesgos de resistencia significativos, lo que probablemente supere mucho los riesgos hipotéticos de una interrupción global.

• En escenarios en los que el control de cliente no es posible, se debe tomar una dependencia en un único servicio de enrutamiento global para proporcionar un punto de entrada unificado para todas las regiones de implementación activas.

  • Cuando se usa de forma aislada, representan un único punto de error en un nivel de servicio debido a dependencias globales, aunque se proporcionen redundancia y disponibilidad integradas en varias regiones.
  • El Acuerdo de Nivel de Servicio proporcionado por el servicio de enrutamiento global seleccionado representa el SLO compuesto máximo alcanzable, independientemente del número de regiones de implementación que se consideren.

• Cuando el control de cliente no es posible, las mitigaciones operativas se pueden considerar para definir un proceso para migrar a un servicio de enrutamiento global secundario si una interrupción global deshabilita el servicio principal. La migración de un servicio de enrutamiento global a otro suele ser un proceso largo que dura varias horas, especialmente cuando se considera la propagación de DNS.

• Algunos servicios de enrutamiento global de terceros proporcionan un Acuerdo de Nivel de Servicio del 100 %. Sin embargo, el Acuerdo de Nivel de Servicio histórico y alcanzable proporcionado por estos servicios suele ser inferior al 100 %.

  • Aunque estos servicios proporcionan reparaciones financieras por falta de disponibilidad, resulta poco importante cuando el impacto de la falta de disponibilidad es significativo, como con escenarios críticos para la seguridad en los que la vida humana está en juego en última instancia. Por lo tanto, la redundancia tecnológica o las mitigaciones operativas suficientes deben considerarse incluso cuando el Acuerdo de Nivel de Servicio legal anunciado es del 100 %.

Azure Front Door

• Azure Front Door proporciona equilibrio de carga HTTP/S global y conectividad optimizada mediante el protocolo de difusión por proximidad con división TCP para aprovechar la red troncal global de Microsoft.

  • Se mantienen varias conexiones para cada uno de los puntos de conexión de back-end.
  • Las solicitudes de cliente entrantes se finalizan primero en el nodo perimetral más cercano al cliente de origen.
  • Después de cualquier inspección de tráfico necesaria, las solicitudes se reenvía a través de la red troncal de Microsoft al back-end adecuado mediante conexiones existentes o se sirven desde la caché interna de un nodo perimetral.
  • Este enfoque es eficaz para distribuir grandes volúmenes de tráfico a través de las conexiones de back-end.

• Proporciona una caché integrada que sirve contenido estático de nodos perimetrales. En muchos casos de uso, esto también puede eliminar la necesidad de una red de entrega de contenido (CDN) dedicada.

• Azure Web Application Firewall (WAF) se puede usar en Azure Front Door y, dado que se implementa en ubicaciones perimetrales de red de Azure en todo el mundo, todas las solicitudes entrantes entregadas por Front Door en inspeccionadas en el perímetro de la red.

• Azure Front Door protege los puntos de conexión de aplicación frente a ataques DDoS mediante Azure DDoS Protection Basic. Azure DDoS Standard proporciona funcionalidades de detección y protección adicionales y más avanzadas y se puede agregar como una capa adicional a Azure Front Door.

• Azure Front Door ofrece un servicio de certificado totalmente administrado. Habilita la seguridad de conexión TLS para los puntos de conexión sin tener que administrar el ciclo de vida del certificado.

• Azure Front Door Premium admite puntos de conexión privados, lo que permite que el tráfico fluya desde Internet directamente a redes virtuales de Azure. Esto eliminaría la necesidad de usar direcciones IP públicas en la red virtual para hacer que los back-end fueran accesibles a través de Azure Front Door Premium.

• Azure Front Door se basa en sondeos de estado y puntos de conexión de estado de back-end (DIRECCIONES URL) a los que se llama en intervalos para devolver un código de estado HTTP que refleja si el back-end funciona normalmente, con una respuesta HTTP 200 (OK) que refleja un estado correcto. En cuanto un back-end refleja un estado incorrecto, desde la perspectiva de un determinado nodo perimetral, ese nodo perimetral dejará de enviar solicitudes allí. Por lo tanto, los back-end incorrectos se quitan de forma transparente de la circulación del tráfico sin demora.

• Solo admite protocolos HTTP/S.

• Azure Front Door WAF y Application Gateway WAF proporcionan un conjunto de características ligeramente diferente, aunque admiten reglas integradas y personalizadas y se pueden establecer para que funcionen en modo de detección o en modo de prevención.

• El espacio ip de back-end de Front Door puede cambiar, pero Microsoft garantizará la integración con los intervalos IP de Azure y las etiquetas de servicio. Es posible suscribirse a intervalos IP de Azure y etiquetas de servicio para recibir notificaciones sobre los cambios o actualizaciones.

• Azure Front Door admite varias configuraciones de distribución de carga:

  • Basado en latencia: la configuración predeterminada que enruta el tráfico al back-end "más cercano" del cliente; en función de la latencia de la solicitud.
  • Basado en prioridad: útil para las configuraciones activas-pasivas, donde el tráfico siempre debe enviarse a un back-end principal a menos que no esté disponible.
  • Ponderado: aplicable a las implementaciones controladas en las que se envía un determinado porcentaje de tráfico a un back-end específico. Si varios back-end tienen asignados los mismos pesos, se usa el enrutamiento basado en latencia.

• De forma predeterminada, Azure Front Door usa el enrutamiento basado en latencia que puede provocar situaciones en las que algunos back-end obtienen mucho más tráfico entrante que otros, dependiendo de dónde se originen los clientes.

• Si el mismo back-end debe controlar una serie de solicitudes de cliente, la afinidad de sesión se puede configurar en el front-end. Usa una cookie del lado cliente para enviar solicitudes posteriores al mismo back-end que la primera solicitud, siempre que el back-end siga estando disponible.

Azure Traffic Manager

• Azure Traffic Manager es un servicio de redireccionamiento de DNS.

  • La carga real de la solicitud no se procesa, sino que Traffic Manager devuelve el nombre DNS de uno de los back-end que el grupo, en función de las reglas configuradas para el método de enrutamiento de tráfico seleccionado.
  • A continuación, el nombre DNS de back-end se resuelve en su dirección IP final a la que llama directamente el cliente.

• La respuesta DNS se almacena en caché y reutiliza el cliente durante un período de tiempo de vida (TTL) especificado y las solicitudes realizadas durante este período pasarán directamente al punto de conexión de back-end sin interacción de Traffic Manager. Elimina el paso de conectividad adicional que proporciona ventajas de costos en comparación con Front Door.

• Dado que la solicitud se realiza directamente desde el cliente al servicio back-end, se puede aprovechar cualquier protocolo compatible con el back-end.

• De forma similar a Azure Front Door, Azure Traffic Manager también se basa en sondeos de estado para comprender si un back-end es correcto y funciona normalmente. Si se devuelve otro valor o no se devuelve nada, el servicio de enrutamiento reconoce problemas continuos y detendrá el enrutamiento de solicitudes a ese back-end específico.

  • Sin embargo, a diferencia de Azure Front Door, esta eliminación de back-end incorrectos no es instantánea, ya que los clientes seguirán creando conexiones al back-end incorrecto hasta que expire el TTL de DNS y se solicite un nuevo punto de conexión back-end desde el servicio Traffic Manager.
  • Además, incluso cuando expire el TTL, no hay ninguna garantía de que los servidores DNS públicos respeten este valor, por lo que la propagación de DNS puede tardar mucho más en producirse. Esto significa que el tráfico puede seguir siendo enviado al punto de conexión incorrecto durante un período de tiempo sostenido.

Equilibrador de carga estándar de Azure

Recomendaciones de diseño

• Use Azure Front Door como servicio de enrutamiento de tráfico global principal para escenarios HTTP/S. Azure Front Door es muy recomendable para las cargas de trabajo HTTP/S, ya que proporciona enrutamiento de tráfico optimizado, conmutación por error transparente, puntos de conexión back-end privados (con la SKU Premium), almacenamiento en caché perimetral e integración con Web Application Firewall (WAF).

• En escenarios de aplicación en los que es posible el control de cliente, aplique la lógica de enrutamiento del lado cliente para considerar escenarios de conmutación por error en los que se produce un error en la tecnología de enrutamiento global principal. Dos o más tecnologías de enrutamiento global deben colocarse en paralelo para la redundancia agregada, si el Acuerdo de Nivel de Servicio único no es suficiente. La lógica de cliente es necesaria para enrutar a la tecnología redundante en caso de un error de servicio global.

  • Se deben usar dos direcciones URL distintas, con una aplicada a cada uno de los diferentes servicios de enrutamiento global para simplificar la experiencia general de administración de certificados y la lógica de enrutamiento para una conmutación por error.
  • Dé prioridad al uso de tecnologías de enrutamiento de terceros como servicio de conmutación por error secundario, ya que esto mitigará el mayor número de escenarios de error globales y las funcionalidades que ofrecen los proveedores líderes de la red CDN del sector permitirán un enfoque de diseño coherente.
  • También se debe tener en cuenta el enrutamiento directo a una sola marca regional en lugar de a un servicio de enrutamiento independiente. Aunque esto dará lugar a un nivel degradado de servicio, representa un enfoque de diseño mucho más sencillo.

En esta imagen se muestra una configuración redundante del equilibrador de carga global con conmutación por error de cliente mediante Azure Front Door como equilibrador de carga global principal.

• Aunque no se recomienda, en el caso de las cargas de trabajo HTTP que usan Azure Traffic Manager para la redundancia de enrutamiento global a Azure Front Door, considere la posibilidad de descargar web Application Firewall (WAF) a Application Gateway para el tráfico aceptable que fluye a través de Azure Front Door.
  • Esto introducirá un punto de error adicional a la ruta de acceso de entrada estándar, un componente de ruta crítica adicional para administrar y escalar, y también incurrirá en costos adicionales para garantizar la alta disponibilidad global. Sin embargo, simplificará considerablemente el escenario de error al proporcionar coherencia entre las rutas de acceso de entrada aceptables y no aceptables a través de Azure Front Door y Azure Traffic Manager, tanto en términos de ejecución de WAF como en puntos de conexión de aplicación privados.
  • La pérdida de almacenamiento en caché perimetral en un escenario de error afectará al rendimiento general y debe alinearse con un nivel aceptable de servicio o un enfoque de diseño mitigado. Para garantizar un nivel de servicio coherente, considere la posibilidad de descargar el almacenamiento en caché perimetral en un proveedor de RED CDN de terceros para ambas rutas de acceso.

Se recomienda tener en cuenta un servicio de enrutamiento global de terceros en lugar de dos servicios de enrutamiento global de Azure. Esto proporciona el nivel máximo de mitigación de errores y un enfoque de diseño más sencillo, ya que la mayoría de los proveedores de CDN líderes del sector ofrecen funcionalidades perimetrales en gran medida coherentes con las que ofrece Azure Front Door.

Azure Front Door

• Use el servicio de certificados administrados de Azure Front Door para habilitar las conexiones TLS y quite la necesidad de administrar los ciclos de vida de los certificados.

• Use el firewall de aplicaciones web (WAF) de Azure Front Door para proporcionar protección en el perímetro frente a vulnerabilidades de seguridad y vulnerabilidades web comunes, como la inyección de CÓDIGO SQL.

• Use la caché integrada de Azure Front Door para proporcionar contenido estático desde nodos perimetrales.

  • En la mayoría de los casos, esto también eliminará la necesidad de una red de entrega de contenido (CDN) dedicada.

• Configure los puntos de entrada de la plataforma de aplicaciones para validar las solicitudes entrantes mediante el filtrado basado en encabezados mediante X-Azure-IDFD para asegurarse de que todo el tráfico fluye a través de la instancia de Front Door configurada. Considere también la posibilidad de configurar el ACL de IP mediante etiquetas de servicio de Front Door para validar que el tráfico se origina desde el espacio de direcciones IP de back-end de Azure Front Door y los servicios de infraestructura de Azure. Esto garantizará que el tráfico fluya a través de Azure Front Door en un nivel de servicio, pero el filtrado basado en encabezados seguirá siendo necesario para garantizar el uso de una instancia de Front Door configurada.

• Defina un punto de conexión de mantenimiento TCP personalizado para validar las dependencias críticas de bajada dentro de una marca de implementación regional, incluidas las réplicas de la plataforma de datos, como Azure Cosmos DB en el ejemplo proporcionado por la implementación de referencia básica. Si una o varias dependencias son incorrectas, el sondeo de estado debe reflejarlo en la respuesta devuelta para que toda la marca regional se pueda sacar de la circulación.

• Asegúrese de que las respuestas de sondeo de estado se registran e ingieren todos los datos operativos expuestos por Azure Front Door en el área de trabajo global de Log Analytics para facilitar un receptor de datos unificado y una sola vista operativa en toda la aplicación.

• A menos que la carga de trabajo sea extremadamente sensible a la latencia, reparta el tráfico uniformemente en todos los stamps regionales considerados para usar los recursos implementados de forma más eficaz.

  • Para ello, establezca el parámetro "Confidencialidad de latencia (latencia adicional)" en un valor lo suficientemente alto como para satisfacer las diferencias de latencia entre las distintas regiones de los back-end. Asegúrese de una tolerancia aceptable para la carga de trabajo de la aplicación con respecto a la latencia general de solicitudes de cliente.

• No habilite la afinidad de sesión a menos que la aplicación lo requiera, ya que puede tener un impacto negativo en el equilibrio de distribución del tráfico. Con una aplicación totalmente sin estado, si se sigue el enfoque recomendado de diseño de aplicaciones críticas, cualquiera de las implementaciones regionales podría controlar cualquier solicitud.

Azure Traffic Manager

• Use Traffic Manager para escenarios que no son HTTP/S como reemplazo de Azure Front Door. Las diferencias de funcionalidad impulsarán diferentes decisiones de diseño para las funcionalidades de caché y WAF, y la administración de certificados TLS.

• Las funcionalidades de WAF deben tenerse en cuenta dentro de cada región para la ruta de acceso de entrada de Traffic Manager mediante App de Azure lication Gateway.

• Configure un valor TTL adecuado para optimizar el tiempo necesario para quitar un punto de conexión back-end incorrecto de la circulación en caso de que el back-end esté en mal estado.

• De forma similar a con Azure Front Door, se debe definir un punto de conexión de mantenimiento TCP personalizado para validar las dependencias críticas de bajada dentro de una marca de implementación regional, que debe reflejarse en la respuesta proporcionada por los puntos de conexión de mantenimiento.

  Sin embargo, para la consideración adicional de Traffic Manager se debe tener en cuenta la conmutación por error regional de nivel de servicio. por ejemplo, "legging de perro", para mitigar el posible retraso asociado a la eliminación de un back-end incorrecto debido a errores de dependencia, especialmente si no es posible establecer un TTL bajo para los registros DNS.

• Se debe tener en cuenta a los proveedores de CDN de terceros para lograr el almacenamiento en caché perimetral al usar Azure Traffic Manager como servicio de enrutamiento global principal. Cuando el servicio de terceros también ofrece funcionalidades de WAF perimetrales, debe tenerse en cuenta para simplificar la ruta de acceso de entrada y eliminar potencialmente la necesidad de Application Gateway.

Servicios de entrega de aplicaciones

La ruta de acceso de entrada de red para una aplicación crítica también debe tener en cuenta los servicios de entrega de aplicaciones para garantizar el tráfico de entrada seguro, confiable y escalable.

Esta sección se basa en recomendaciones de enrutamiento global mediante la exploración de las funcionalidades clave de entrega de aplicaciones, teniendo en cuenta los servicios pertinentes, como Azure Standard Load Balancer, App de Azure lication Gateway y Azure API Management.

Consideraciones de diseño

• El cifrado TLS es fundamental para garantizar la integridad del tráfico de usuario entrante a una aplicación crítica, con la descarga tls aplicada solo en el punto de entrada de una marca para descifrar el tráfico entrante. La descarga de TLS requiere la clave privada del certificado TLS para descifrar el tráfico.

• Un firewall de aplicaciones web proporciona protección contra vulnerabilidades de seguridad y vulnerabilidades web comunes, como inyección de código SQL o scripting entre sitios, y es esencial para lograr las aspiraciones de confiabilidad máxima de una aplicación crítica.

• Azure WAF proporciona protección integrada frente a las 10 vulnerabilidades principales de OWASP mediante conjuntos de reglas administradas.

  • También se pueden agregar reglas personalizadas para ampliar el conjunto de reglas administradas.
  • Azure WAF se puede habilitar en Azure Front Door, App de Azure lication Gateway o Azure CDN (actualmente en versión preliminar pública).
    • Las características que se ofrecen en cada uno de los servicios difieren ligeramente. Por ejemplo, waf de Azure Front Door proporciona limitación de velocidad, filtrado geográfico y protección contra bots, que aún no se ofrecen en el WAF de Application Gateway. Sin embargo, todos admiten reglas integradas y personalizadas y se pueden establecer para que funcionen en modo de detección o modo de prevención.
    • La hoja de ruta de Azure WAF garantizará que se proporcione un conjunto de características waf coherente en todas las integraciones de servicios.

• También se puede considerar que las tecnologías waf de terceros, como las NVA y los controladores de entrada avanzados dentro de Kubernetes, proporcionan protección de vulnerabilidades necesaria.

• La configuración óptima de WAF normalmente requiere un ajuste preciso, independientemente de la tecnología utilizada.

  Azure Front Door

• Azure Front Door solo acepta tráfico HTTP y HTTPS y solo procesará las solicitudes con un encabezado conocido Host . Este bloqueo de protocolo ayuda a mitigar los ataques volumétricos distribuidos entre protocolos y puertos, y los ataques de amplificación de DNS y intoxicación TCP.

• Azure Front Door es un recurso global de Azure, por lo que la configuración se implementa globalmente en todas las ubicaciones perimetrales.

  • La configuración de recursos se puede distribuir a gran escala para controlar cientos de miles de solicitudes por segundo.
  • Las actualizaciones de la configuración, incluidas las rutas y los grupos de back-end, son perfectas y no provocarán ningún tiempo de inactividad durante la implementación.

• Azure Front Door proporciona un servicio de certificado totalmente administrado y un método bring-your-own-certificate para los certificados SSL orientados al cliente. El servicio de certificados totalmente administrado proporciona un enfoque operativo simplificado y ayuda a reducir la complejidad en el diseño general realizando la administración de certificados dentro de una sola área de la solución.

• Azure Front Door rota automáticamente los certificados "administrados" al menos 60 días antes de la expiración del certificado para protegerse frente a los riesgos de certificados expirados. Si se usan certificados autoadministrados, los certificados actualizados deben implementarse más tarde de 24 horas antes de la expiración del certificado existente; de lo contrario, los clientes pueden recibir errores de certificado expirados.

• Las actualizaciones de certificados solo provocarán tiempo de inactividad si Azure Front Door cambia entre "Administrado" y "Usar su propio certificado".

• Azure Front Door está protegido por Azure DDoS Protection Basic, que se integra en Front Door de forma predeterminada. Esto proporciona supervisión del tráfico siempre activa, mitigación en tiempo real y también se defiende frente a inundaciones comunes de consultas DNS de nivel 7 o ataques volumétricos de nivel 3/4.

  • Estas protecciones ayudan a mantener la disponibilidad de Azure Front Door incluso cuando se enfrentan a un ataque DDoS. Los ataques de denegación de servicio distribuido (DDoS) pueden hacer que un recurso de destino no esté disponible al sobrecargarlo con tráfico ilegítimo.

• Azure Front Door también proporciona funcionalidades de WAF en un nivel de tráfico global, mientras que application Gateway WAF debe proporcionarse dentro de cada marca de implementación regional. Las funcionalidades incluyen conjuntos de reglas de firewall para protegerse frente a ataques comunes, filtrado geográfico, bloqueo de direcciones, limitación de velocidad y coincidencia de firmas.

  Equilibrador de carga de Azure

• La SKU de Azure Basic Load Balancer no está respaldada por un Acuerdo de Nivel de Servicio y tiene varias restricciones de funcionalidad en comparación con la SKU estándar.

Recomendaciones de diseño

• Realice la descarga de TLS en cuantos lugares como sea posible para mantener la seguridad, al tiempo que simplifica el ciclo de vida de administración de certificados.

• Use conexiones cifradas (por ejemplo, HTTPS) desde el punto donde se produce la descarga de TLS en los back-end de aplicaciones reales. Los puntos de conexión de aplicación no serán visibles para los usuarios finales, por lo que los dominios administrados por Azure, como azurewebsites.net o cloudapp.net, se pueden usar con certificados administrados.

• Para el tráfico HTTP(S), asegúrese de que las funcionalidades de WAF se aplican dentro de la ruta de acceso de entrada para todos los puntos de conexión expuestos públicamente.

• Habilite las funcionalidades de WAF en una sola ubicación de servicio, ya sea globalmente con Azure Front Door o regionalmente con App de Azure lication Gateway, ya que esto simplifica la configuración y optimiza el rendimiento y el costo.

  Configure WAF en modo de prevención para bloquear directamente los ataques. Use solo WAF en el modo de detección (es decir, solo registrar pero no bloquear solicitudes sospechosas) cuando la penalización de rendimiento del modo de prevención es demasiado alta. El riesgo adicional implícito debe entenderse completamente y alinearse con los requisitos específicos del escenario de carga de trabajo.

• Dé prioridad al uso de WAF de Azure Front Door, ya que proporciona el conjunto de características nativo de Azure más rico y aplica protecciones en el perímetro global, lo que simplifica el diseño general y impulsa más eficiencias.

• Use Azure API Management solo al exponer un gran número de API a clientes externos o a diferentes equipos de aplicaciones.

• Use la SKU de Azure Standard Load Balancer para cualquier escenario de distribución de tráfico interno dentro de cargas de trabajo de microservicio.

  • Proporciona un Acuerdo de Nivel de Servicio del 99,99 % cuando se implementa en Availability Zones.
  • Proporciona funcionalidades críticas, como diagnósticos o reglas de salida.

• Use Azure DDoS Network Protection para ayudar a proteger los puntos de conexión públicos hospedados dentro de cada red virtual de aplicación.

Almacenamiento en caché y entrega de contenido estático

El tratamiento especial del contenido estático, como imágenes, JavaScript, CSS y otros archivos, puede tener un impacto significativo en la experiencia general del usuario, así como en el costo total de la solución. El almacenamiento en caché de contenido estático en el perímetro puede acelerar los tiempos de carga del cliente, lo que da lugar a una mejor experiencia del usuario y también puede reducir el costo del tráfico, las operaciones de lectura y la potencia informática en los servicios back-end implicados.

Consideraciones de diseño

• No todo el contenido que una solución pone a disposición a través de Internet se genera dinámicamente. Las aplicaciones sirven tanto a recursos estáticos (imágenes, JavaScript, CSS, archivos de localización, etc.) como a contenido dinámico.
• Las cargas de trabajo con contenido estático al que se accede con frecuencia se benefician considerablemente del almacenamiento en caché, ya que reduce la carga en los servicios back-end y reduce la latencia de acceso al contenido para los usuarios finales.
• El almacenamiento en caché se puede implementar de forma nativa en Azure mediante Azure Front Door o Azure Content Delivery Network (CDN).
  • Azure Front Door proporciona funcionalidades de almacenamiento en caché perimetrales nativas de Azure y características de enrutamiento para dividir el contenido estático y dinámico.
    • Al crear las reglas de enrutamiento adecuadas en Azure Front Door, /static/* el tráfico se puede redirigir de forma transparente al contenido estático.
  • Los escenarios de almacenamiento en caché más complejos se pueden implementar mediante el servicio Azure CDN para establecer una red de entrega de contenido completa para volúmenes de contenido estáticos significativos.
    • Es probable que el servicio Azure CDN sea más rentable, pero no proporciona las mismas funcionalidades avanzadas de enrutamiento y firewall de aplicaciones web (WAF) que se recomiendan para otras áreas de un diseño de aplicación. Sin embargo, ofrece mayor flexibilidad para integrarse con servicios similares de soluciones de terceros, como Akamai y Verizon.
  • Al comparar los servicios de Azure Front Door y Azure CDN, se deben explorar los siguientes factores de decisión:
    • Se pueden realizar reglas de almacenamiento en caché necesarias mediante el motor de reglas.
    • Tamaño del contenido almacenado y el costo asociado.
    • Precio al mes para la ejecución del motor de reglas (se cobra por solicitud en Azure Front Door).
    • Requisitos de tráfico saliente (el precio difiere según el destino).

Recomendaciones de diseño

• Contenido estático generado, como copias de tamaño de archivos de imagen que nunca o solo cambian rara vez, también puede beneficiarse del almacenamiento en caché. El almacenamiento en caché se puede configurar en función de los parámetros de dirección URL y con una duración de almacenamiento en caché variable.
• Separe la entrega de contenido estático y dinámico a los usuarios y entregue contenido relevante de una memoria caché para reducir la carga en los servicios back-end para optimizar el rendimiento de los usuarios finales.
• Dada la recomendación segura (área de diseño de red y conectividad ) para usar Azure Front Door con fines globales de enrutamiento y firewall de aplicaciones web (WAF), se recomienda priorizar el uso de funcionalidades de almacenamiento en caché de Azure Front Door a menos que existan brechas.

Integración de redes virtuales

Una aplicación crítica normalmente abarcará los requisitos para la integración con otras aplicaciones o sistemas dependientes, que podrían hospedarse en Azure, en otra nube pública o en centros de datos locales. Esta integración de aplicaciones se puede llevar a cabo mediante puntos de conexión accesibles públicamente e Internet, o redes privadas a través de la integración de nivel de red. En última instancia, el método por el que se logra la integración de aplicaciones tendrá un impacto significativo en la seguridad, el rendimiento y la confiabilidad de la solución, y afectará fuertemente a las decisiones de diseño dentro de otras áreas de diseño.

Una aplicación crítica se puede implementar dentro de una de las tres configuraciones de red generales, lo que determina cómo se puede producir la integración de aplicaciones en un nivel de red.

1. Aplicación pública sin conectividad de red corporativa.
2. Aplicación pública con conectividad de red corporativa.
3. Aplicación privada con conectividad de red corporativa.

En esta sección se exploran estos escenarios de integración de red, la capa en el uso adecuado de Azure Virtual Networks y los servicios de red de Azure circundantes para garantizar que se cumplan los requisitos de integración de forma óptima.

Consideraciones de diseño

Sin redes virtuales

• El enfoque de diseño más sencillo es no implementar la aplicación dentro de una red virtual.

  • La conectividad entre todos los servicios de Azure considerados se proporcionará por completo a través de puntos de conexión públicos y la red troncal de Microsoft Azure. La conectividad entre los puntos de conexión públicos hospedados en Azure solo atravesará la red troncal de Microsoft y no pasará por la red pública de Internet.
  • La conectividad a cualquier sistema externo fuera de Azure la proporcionará la red pública de Internet.

• Este enfoque de diseño adopta "identidad como perímetro de seguridad" para proporcionar control de acceso entre los distintos componentes de servicio y la solución dependiente. Esto puede ser una solución aceptable para escenarios que son menos sensibles a la seguridad. Todos los servicios de aplicación y las dependencias son accesibles a través de un punto de conexión público y los deja vulnerables a vectores de ataque adicionales orientados a obtener acceso no autorizado.

• Este enfoque de diseño tampoco es aplicable a todos los servicios de Azure, ya que muchos servicios, como AKS, tienen un requisito difícil para una red virtual subyacente.

Redes virtuales aisladas

• Para mitigar los riesgos asociados a puntos de conexión públicos innecesarios, la aplicación se puede implementar dentro de una red independiente que no esté conectada a otras redes.

• Las solicitudes de cliente entrantes seguirán requirindo que se exponga un punto de conexión público a Internet; sin embargo, toda la comunicación posterior puede estar dentro de la red virtual mediante puntos de conexión privados. Al usar Azure Front Door Premium, es posible enrutar directamente desde nodos perimetrales a puntos de conexión de aplicación privados.

• Aunque la conectividad privada entre los componentes de la aplicación se producirá a través de redes virtuales, toda la conectividad con dependencias externas seguirá confiando en puntos de conexión públicos.

  • La conectividad con los servicios de la plataforma Azure se puede establecer con puntos de conexión privados si se admite. Si existen otras dependencias externas en Azure, como otra aplicación de bajada, se proporcionará conectividad a través de puntos de conexión públicos y la red troncal de Microsoft Azure.
  • La conectividad a cualquier sistema externo fuera de Azure la proporcionaría la red pública de Internet.

• En escenarios en los que no hay requisitos de integración de red para dependencias externas, la implementación de la solución dentro de un entorno de red aislado proporciona máxima flexibilidad de diseño. No hay restricciones de direccionamiento ni enrutamiento asociadas a una integración de red más amplia.

• Azure Bastion es un servicio PaaS totalmente administrado por la plataforma que se puede implementar en una red virtual y proporciona conectividad RDP/SSH segura a máquinas virtuales de Azure. Al conectarse a través de Azure Bastion, las máquinas virtuales no necesitan una dirección IP pública.

• El uso de redes virtuales de aplicaciones presenta importantes complejidades de implementación dentro de las canalizaciones de CI/CD, ya que se requiere tanto el acceso al plano de datos como al plano de control a los recursos hospedados en redes privadas para facilitar las implementaciones de aplicaciones.

  • Se debe establecer una ruta de acceso de red privada segura para permitir que las herramientas de CI/CD realicen acciones necesarias.
  • Los agentes de compilación privados se pueden implementar dentro de las redes virtuales de aplicaciones para proxy el acceso a los recursos protegidos por la red virtual.

Redes virtuales conectadas

• En escenarios con requisitos de integración de red externa, las redes virtuales de aplicaciones se pueden conectar a otras redes virtuales dentro de Azure, otro proveedor de nube o redes locales mediante una variedad de opciones de conectividad. Por ejemplo, algunos escenarios de aplicación pueden considerar la integración de nivel de aplicación con otras aplicaciones de línea de negocio hospedadas de forma privada dentro de una red corporativa local.

• El diseño de red de aplicaciones debe alinearse con la arquitectura de red más amplia, especialmente en temas como el direccionamiento y el enrutamiento.

• La superposición de espacios de direcciones IP entre regiones de Azure o redes locales creará una contención importante cuando se considere la integración de red.

  • Sin embargo, se puede actualizar un recurso de red virtual para tener en cuenta el espacio de direcciones adicional, cuando se requiere un espacio de direcciones de red virtual de una red emparejada que cambie una sincronización en el vínculo de emparejamiento, lo que deshabilitará temporalmente el emparejamiento.
  • Azure reserva cinco direcciones IP dentro de cada subred, que se deben tener en cuenta al determinar los tamaños adecuados para las redes virtuales de aplicaciones y las subredes abarcadas.
  • Algunos servicios de Azure requieren subredes dedicadas, como Azure Bastion, Azure Firewall o Azure Virtual Network Gateway. El tamaño de estas subredes de servicio es muy importante, ya que deben ser lo suficientemente grandes como para admitir todas las instancias actuales del servicio teniendo en cuenta los requisitos de escalado futuros, pero no tan grandes como para las direcciones de desecho innecesariamente.

• Cuando se requiere la integración de red local o entre nubes, Azure ofrece dos soluciones diferentes para establecer una conexión segura.

  • Un circuito ExpressRoute se puede ajustar para proporcionar anchos de banda de hasta 100 Gbps.
  • Se puede ajustar el tamaño de una red privada virtual (VPN) para proporcionar ancho de banda agregado de hasta 10 Gbps en redes de concentrador y radio, y hasta 20 Gbps en Azure Virtual WAN.

• La inclusión de rutas de acceso y recursos de red adicionales presenta consideraciones operativas y de confiabilidad adicionales para la aplicación para asegurarse de que se mantiene el estado.

Recomendaciones de diseño

• Se recomienda implementar soluciones críticas en redes virtuales de Azure siempre que sea posible para quitar puntos de conexión públicos innecesarios, lo que limita la superficie expuesta a ataques de la aplicación para maximizar la seguridad y la confiabilidad.

  • Use puntos de conexión privados para la conectividad con los servicios de la plataforma Azure. Los puntos de conexión de servicio se pueden considerar para los servicios que admiten Private Link, siempre que los riesgos de filtración de datos sean aceptables o mitigados a través de controles alternativos.

• En escenarios de aplicación que no requieren conectividad de red corporativa, trate todas las redes virtuales como recursos efímeros que se reemplazan cuando se realiza una nueva implementación regional.

• Al conectarse a otras redes de Azure o locales, las redes virtuales de aplicaciones no deben tratarse como efímeras, ya que crea complicaciones significativas en las que se preocupan el emparejamiento de redes virtuales y los recursos de puerta de enlace de red virtual. Todos los recursos de aplicación pertinentes dentro de la red virtual deben seguir siendo efímeros, con subredes paralelas que se usan para facilitar las implementaciones azul-verde de las marcas de implementación regionales actualizadas.

• En escenarios en los que se requiere conectividad de red corporativa para facilitar la integración de aplicaciones a través de redes privadas, asegúrese de que el espacio de direcciones IPv4 usado para las redes virtuales de aplicaciones regionales no se superponga con otras redes conectadas y tenga el tamaño adecuado para facilitar la escala necesaria sin necesidad de actualizar el recurso de red virtual e incurrir en tiempo de inactividad.

  • Se recomienda encarecidamente usar solo direcciones IP de la asignación de direcciones para Internet privado (RFC 1918).
    • Para entornos con una disponibilidad limitada de direcciones IP privadas (RFC 1918), considere la posibilidad de usar IPv6.
    • Si se requiere el uso de la dirección IP pública, asegúrese de que solo se usen bloques de direcciones propiedad.
  • Alinee con los planes de organización para el direccionamiento IP en Azure para asegurarse de que el espacio de direcciones IP de la red de aplicaciones no se superponga con otras redes entre ubicaciones locales o regiones de Azure.
  • No cree redes virtuales de aplicaciones innecesariamente grandes para asegurarse de que no se ha desperdiciado el espacio de direcciones IP.

• Priorice el uso de Azure CNI para la integración de red de AKS, ya que admite un conjunto de características más completo.

  • Considere Kubenet para escenarios con una limitación de las direcciones IP disponibles para ajustarse a la aplicación dentro de un espacio de direcciones restringido.

  • Priorice el uso del complemento de red de Azure CNI para la integración de red de AKS y considere Kubenet para escenarios con un intervalo limitado de direcciones IP disponibles. Consulte Microsegmentación y directivas de red de Kubernetes para obtener más detalles.

• En escenarios que requieren integración de red local, priorice el uso de ExpressRoute para garantizar una conectividad segura y escalable.

  • Asegúrese de que el nivel de confiabilidad aplicado a ExpressRoute o VPN cumple totalmente los requisitos de la aplicación.
  • Se deben tener en cuenta varias rutas de acceso de red para proporcionar redundancia adicional cuando sea necesario, como circuitos ExpressRoute conectados cruzados o el uso de VPN como mecanismo de conectividad de conmutación por error.

• Asegúrese de que todos los componentes de las rutas de acceso de red críticas están en línea con los requisitos de confiabilidad y disponibilidad de los flujos de usuario asociados, independientemente de si el equipo de aplicaciones de ti central entrega la administración de estas rutas de acceso y el componente asociado.

  Nota:

  Al implementar dentro de una zona de aterrizaje de Azure e integrarla con una topología de red organizativa más amplia, tenga en cuenta las instrucciones de red para asegurarse de que la red fundamental está alineada con los procedimientos recomendados de Microsoft.

• Use Azure Bastion o conexiones privadas proxy para acceder al plano de datos de los recursos de Azure o realizar operaciones de administración.

Salida de Internet

La salida a Internet es un requisito fundamental de red para una aplicación crítica para facilitar la comunicación externa en el contexto de:

1. Interacción directa del usuario de la aplicación.
2. Integración de aplicaciones con dependencias externas fuera de Azure.
3. Acceso a dependencias externas requeridas por los servicios de Azure usados por la aplicación.

En esta sección se explora cómo se puede lograr la salida de Internet a la vez que se garantiza la seguridad, la confiabilidad y el rendimiento sostenible, y se resaltan los requisitos de salida clave para los servicios recomendados en un contexto crítico.

Consideraciones de diseño

• Muchos servicios de Azure requieren acceso a puntos de conexión públicos para que varias funciones de plano de control y administración funcionen según lo previsto.

• Azure proporciona diferentes métodos de conectividad de salida directa de Internet, como azure NAT Gateway o Azure Load Balancer, para máquinas virtuales o instancias de proceso en una red virtual.

• Cuando el tráfico desde dentro de una red virtual viaja a Internet, debe realizarse la traducción de direcciones de red (NAT). Se trata de una operación de proceso que se produce dentro de la pila de redes y que, por tanto, puede afectar al rendimiento del sistema.

• Sin embargo, cuando NAT tiene lugar a pequeña escala, el impacto en el rendimiento debe ser insignificante, pero si hay un gran número de problemas de red de solicitudes salientes. Estos problemas suelen aparecer en forma de agotamiento de puertos nat de origen (o SNAT).

• En un entorno multiinquilino, como App de Azure Service, hay un número limitado de puertos salientes disponibles para cada instancia. Si estos puertos se ejecutan, no se pueden iniciar nuevas conexiones salientes. Este problema se puede mitigar reduciendo el número de recorridos perimetrales privados o públicos o mediante una solución NAT más escalable, como Azure NAT Gateway.

• Además de las limitaciones de NAT, el tráfico saliente también puede estar sujeto a las inspecciones de seguridad necesarias.

  • Azure Firewall proporciona funcionalidades de seguridad adecuadas para proteger la salida de red.

  • Azure Firewall (o una aplicación virtual virtual de red equivalente) se puede usar para proteger los requisitos de salida de Kubernetes proporcionando un control pormenorizado sobre los flujos de tráfico salientes.

• Los grandes volúmenes de salida de Internet incurrirán en cargos de transferencia de datos.

Azure NAT Gateway

• Azure NAT Gateway admite 64 000 conexiones para TCP y UDP por dirección IP de salida asignada.

  • Se pueden asignar hasta 16 direcciones IP a una sola puerta de enlace NAT.
  • Tiempo de espera de inactividad tcp predeterminado de 4 minutos. Si el tiempo de espera de inactividad se modifica a un valor mayor, los flujos se conservarán durante más tiempo, lo que aumentará la presión en el inventario de puertos SNAT.

• La puerta de enlace NAT no puede proporcionar aislamiento zonal de fábrica. Para obtener redundancia zonal, una subred que contenga recursos zonales debe alinearse con las puertas de enlace NAT zonales correspondientes.

Recomendaciones de diseño

• Minimice el número de conexiones salientes de Internet, ya que esto afectará al rendimiento de NAT.

  • Si se requieren grandes cantidades de conexiones enlazadas a Internet, considere la posibilidad de usar Azure NAT Gateway para abstraer los flujos de tráfico saliente.

• Use Azure Firewall en el que existen requisitos para controlar e inspeccionar el tráfico saliente de Internet.

  • Asegúrese de que Azure Firewall no se usa para inspeccionar el tráfico entre los servicios de Azure.

Si hay requisitos a gran escala asociados con el tráfico saliente, se debe tener en cuenta un recurso dedicado de Azure Firewall para una aplicación crítica, para mitigar los riesgos asociados con el uso de un recurso compartido centralmente, como escenarios ruidosos vecinos.

• Cuando se implementa dentro de un entorno de Virtual WAN, se debe tener en cuenta firewall Manager para proporcionar una administración centralizada de las instancias de Azure Firewall de aplicaciones dedicadas para garantizar que las posturas de seguridad de la organización se observan a través de directivas de firewall globales.
• Asegúrese de que las directivas de firewall incrementales se deleguen a los equipos de seguridad de aplicaciones a través del control de acceso basado en rol para permitir la autonomía de la directiva de aplicación.

Conectividad entre regiones e entre regiones

Aunque el diseño de aplicaciones promueve significativamente las unidades de escalado de implementación regionales independientes, muchos escenarios de aplicación pueden seguir necesitando una integración de red entre los componentes de la aplicación implementados en diferentes zonas o regiones de Azure, incluso si solo se produce en circunstancias de servicio degradadas. El método por el que se logra la comunicación entre zonas y entre regiones tiene un impacto significativo en el rendimiento general y la confiabilidad, que se explorarán a través de las consideraciones y recomendaciones de esta sección.

Consideraciones de diseño

• El enfoque de diseño de aplicaciones para una aplicación crítica aprueba el uso de implementaciones regionales independientes con redundancia zonal aplicada en todos los niveles de componente dentro de una sola región.

• Una zona de disponibilidad (AZ) es una ubicación físicamente independiente del centro de datos dentro de una región de Azure, lo que proporciona aislamiento de errores físicos y lógicos hasta el nivel de un único centro de datos.

  Se garantiza una latencia de ida y vuelta de menos de 2 ms para la comunicación entre zonas. Las zonas tendrán una pequeña varianza de latencia dadas distancias variadas y rutas de fibra entre zonas.

• La conectividad de zona de disponibilidad depende de las características regionales y, por tanto, el tráfico que entra en una región a través de una ubicación perimetral debe enrutarse entre zonas para llegar a su destino. Esto agregará una latencia de ~1ms-2ms dadas restricciones de enrutamiento entre zonas y restricciones de "velocidad de luz", pero esto solo debe tener un rodamiento para cargas de trabajo hiper confidenciales.

• Las zonas de disponibilidad se tratan como entidades lógicas dentro del contexto de una sola suscripción, por lo que es posible que las distintas suscripciones tengan una asignación zonal diferente para la misma región. Por ejemplo, la zona 1 de la suscripción A podría corresponder al mismo centro de datos físico que la zona 2 de la suscripción B.

• Con escenarios de aplicación muy chatear entre componentes de la aplicación, la propagación de niveles de aplicación entre zonas puede introducir una latencia significativa y un aumento de los costos. Es posible mitigar esto dentro del diseño limitando una marca de implementación a una sola zona e implementando varios stamps en las distintas zonas.

• La comunicación entre diferentes regiones de Azure conlleva un cargo de transferencia de datos mayor por GB de ancho de banda.

  • La velocidad de transferencia de datos aplicable depende del continente de las regiones de Azure consideradas.
  • Los datos que atraviesan continentes se cobran a una tasa considerablemente mayor.

• Los métodos de conectividad expressRoute y VPN también se pueden usar para conectar directamente diferentes regiones de Azure juntas para determinados escenarios o incluso plataformas en la nube diferentes.

• Para los servicios para la comunicación entre servicios Private Link se puede usar para la comunicación directa mediante puntos de conexión privados.

• El tráfico se puede anclar a través de circuitos ExpressRoute que se usan para la conectividad local con el fin de facilitar el enrutamiento entre redes virtuales dentro de una región de Azure y entre diferentes regiones de Azure dentro de la misma geografía.

  • El tráfico de anclaje del cabello a través de ExpressRoute omitirá los costos de transferencia de datos asociados con el emparejamiento de redes virtuales, por lo que se puede usar como una manera de optimizar los costos.
  • Este enfoque requiere saltos de red adicionales para la integración de aplicaciones en Azure, lo que introduce riesgos de latencia y confiabilidad. Expande el rol de ExpressRoute y los componentes de puerta de enlace asociados de Azure o local para que también abarquen la conectividad de Azure o Azure.

• Cuando se requiere latencia de submillisegundos entre servicios, los grupos de selección de ubicación por proximidad se pueden usar cuando se admiten en los servicios usados.

Recomendaciones de diseño

• Use el emparejamiento de redes virtuales para conectar redes dentro de una región y entre regiones diferentes. Se recomienda encarecidamente evitar el anclaje del cabello dentro de ExpressRoute.

• Use Private Link para establecer la comunicación directamente entre los servicios de la misma región o entre regiones (servicio en la región A que se comunica con el servicio en la región B.

• En el caso de las cargas de trabajo de aplicaciones que son extremadamente chatear entre componentes, considere la posibilidad de restringir una marca de implementación a una sola zona e implementar varios stamps en las distintas zonas. Esto garantiza que la redundancia zonal se mantenga en el nivel de una marca de implementación encapsulada en lugar de un único componente de aplicación.

• Siempre que sea posible, trate cada stamp de implementación como independiente y desconectado de otros stamps.

  • Use tecnologías de plataforma de datos para sincronizar el estado entre regiones en lugar de lograr la coherencia en un nivel de aplicación con rutas de acceso de red directas.
  • Evite el tráfico de "perras" entre diferentes regiones, a menos que sea necesario, incluso en un escenario de error. Use los servicios de enrutamiento global y los sondeos de estado de un extremo a otro para quitar toda la circulación en caso de que se produzca un error en un único nivel de componente crítico, en lugar de enrutar el tráfico en ese nivel de componente defectuoso a otra región.

• Para escenarios de aplicaciones sensibles a la hiper latencia, priorice el uso de zonas con puertas de enlace de red regionales para optimizar la latencia de red para las rutas de acceso de entrada.

Microsegmentación y directivas de red de Kubernetes

La microsegmentación es un patrón de diseño de seguridad de red que se usa para aislar y proteger cargas de trabajo de aplicaciones individuales, con directivas aplicadas para limitar el tráfico de red entre cargas de trabajo basadas en un modelo de Confianza cero. Normalmente se aplica para reducir la superficie expuesta a ataques de red, mejorar la contención de infracciones y reforzar la seguridad a través de controles de red de nivel de aplicación controlados por directivas.

Una aplicación crítica puede aplicar la seguridad de red de nivel de aplicación mediante grupos de seguridad de red (NSG) en una subred o nivel de interfaz de red, listas de control de acceso de servicio (ACL) y directivas de red al usar Azure Kubernetes Service (AKS).

En esta sección se explora el uso óptimo de estas funcionalidades, lo que proporciona consideraciones y recomendaciones clave para lograr la microsegmentación de nivel de aplicación.

Consideraciones de diseño

• AKS se puede implementar en dos modelos de red diferentes:

  • Redes de Kubenet: los nodos de AKS se integran dentro de una red virtual existente, pero los pods existen dentro de una red de superposición virtual en cada nodo. El tráfico entre pods en distintos nodos se enruta a través de kube-proxy.
  • Redes de Azure Container Networking Interface (CNI): el clúster de AKS se integra dentro de una red virtual existente y sus nodos, pods y servicios recibidos direcciones IP de la misma red virtual a la que están conectados los nodos del clúster. Esto es relevante para varios escenarios de red que requieren conectividad directa desde y hacia pods. Los distintos grupos de nodos se pueden implementar en subredes diferentes.

  Nota:

  Azure CNI requiere más espacio de direcciones IP en comparación con Kubenet. Se requiere un planeamiento inicial adecuado y el ajuste de tamaño de la red. Para más información, consulte la documentación de Azure CNI.

• De forma predeterminada, los pods no están aislados y aceptan tráfico de cualquier origen y pueden enviar tráfico a cualquier destino; un pod puede comunicarse con todos los demás pods de un clúster de Kubernetes determinado; Kubernetes no garantiza ningún aislamiento de nivel de red y no aísla los espacios de nombres en el nivel de clúster.

• La comunicación entre pods y espacios de nombres se puede aislar mediante directivas de red. La directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods. Con las directivas de red, se puede definir un conjunto ordenado de reglas para controlar cómo se envía o recibe el tráfico y se aplica a una colección de pods que coinciden con uno o varios selectores de etiquetas.

  • AKS admite dos complementos que implementan la directiva de red, Azure y Calico. Ambos complementos usan IPTables de Linux para aplicar las directivas especificadas. Consulte Diferencias entre las directivas de Azure y Calico y sus funcionalidades para más información.
  • Las directivas de red no entran en conflicto, ya que son aditivos.
  • Para que se permita un flujo de red entre dos pods, tanto la directiva de salida en el pod de origen como la directiva de entrada en el pod de destino deben permitir el tráfico.
  • La característica de directiva de red solo se puede habilitar en tiempo de creación de instancias del clúster. No es posible habilitar la directiva de red en un clúster de AKS existente.
  • La entrega de directivas de red es coherente independientemente de si se usa Azure o Calico.
  • Calico proporciona un conjunto de características más completo, incluida la compatibilidad con los nodos de Windows y admite Azure CNI, así como Kubenet.

• AKS admite la creación de grupos de nodos diferentes para separar diferentes cargas de trabajo mediante nodos con características de hardware y software diferentes, como nodos con y sin funcionalidades de GPU.

  • El uso de grupos de nodos no proporciona ningún aislamiento de nivel de red.
  • Los grupos de nodos pueden usar subredes diferentes dentro de la misma red virtual. Los grupos de seguridad de red se pueden aplicar en el nivel de subred para implementar la microsegmentación entre grupos de nodos.

Recomendaciones de diseño

• Configure un grupo de seguridad de red en todas las subredes consideradas para proporcionar una ACL de IP para proteger las rutas de acceso de entrada y aislar los componentes de la aplicación en función de un modelo de Confianza cero.

  • Use etiquetas de servicio de Front Door dentro de NSG en todas las subredes que contienen back-end de aplicaciones definidas en Azure Front Door, ya que esto validará que el tráfico se origina desde un espacio de direcciones IP de back-end de Azure Front Door legítimo. Esto garantizará que el tráfico fluya a través de Azure Front Door en un nivel de servicio, pero el filtrado basado en encabezados seguirá siendo necesario para garantizar el uso de una instancia de Front Door determinada y para mitigar también los riesgos de seguridad de "suplantación de ip".

  • El tráfico público de Internet deberá estar deshabilitado en los puertos RDP y SSH en todos los NSG aplicables.

  • Dé prioridad al uso del complemento de red de Azure CNI y considere Kubenet en escenarios con un intervalo limitado de direcciones IP disponibles para ajustarse a la aplicación dentro de un espacio de direcciones restringido.

    • AKS admite el uso de Azure CNI y Kubenet. Esta opción de red se selecciona en el momento de la implementación.
    • El complemento de red de Azure CNI es un complemento de red más sólido y escalable y se recomienda para la mayoría de los escenarios.
    • Kubenet es un complemento de red más ligero y se recomienda para escenarios con un intervalo limitado de direcciones IP disponibles.
    • Consulte Azure CNI para más información.

• La característica Directiva de red de Kubernetes deberá usarse para definir las reglas de tráfico de entrada y salida entre los pods de un clúster. Defina directivas de red pormenorizadas para restringir y limitar la comunicación entre pods.

  • Habilite la directiva de red para Azure Kubernetes Service en el momento de la implementación.
  • Dé prioridad al uso de Calico porque proporciona un conjunto de características más completo con una mayor adopción y soporte técnico de la comunidad.

Paso siguiente

Revise las consideraciones para cuantificar y observar el estado de la aplicación.