Protección de Redes, Aplicaciones y Secretos en Azure

radio_button_uncheckedshort_text 1. Introducción: del perímetro físico a la infraestructura definida por software

La seguridad de redes nació en entornos en los cuales servidores, usuarios y equipos estaban concentrados dentro de edificios y centros de datos. Enrutadores, listas de control de acceso y cortafuegos formaban un perímetro relativamente estable entre la red interna y la internet. Con la virtualización, las aplicaciones web, los dispositivos móviles y la computación en la nube, ese perímetro se volvió distribuido. Redes, reglas de tráfico, balanceadores y almacenes de secretos pasaron a ser configurados por software y consumidos como servicios.

Esta transformación contribuye directamente a las organizaciones y a la sociedad porque los servicios esenciales - bancos, hospitales, escuelas, gobiernos y plataformas de comunicación - dependen de disponibilidad, confidencialidad e integridad. Una arquitectura bien protegida reduce interrupciones, filtraciones y fraudes, además de permitir la innovación con riesgos controlados. El desafío es comprender que “estar en la nube” no hace que un sistema sea automáticamente seguro: Microsoft protege la plataforma, mientras que el cliente debe configurar adecuadamente redes, identidades, aplicaciones y datos.

A lo largo de este capítulo, piensa en una aplicación de tres capas: una interfaz web expuesta al público, una API interna y una base de datos. Cada servicio estudiado responde a una pregunta diferente. Un ataque volumétrico requiere mitigación DDoS; una explotación HTTP requiere WAF ; el tráfico entre subredes requiere NSGs y, en escenarios centralizados, Azure Firewall; la administración de VMs requiere Bastion; contraseñas, claves y certificados requieren Key Vault . Entender estos límites es más importante que memorizar nombres.

Pregunta-guía

Si una aplicación utiliza WAF , ¿aún necesita NSG , Azure Firewall, DDoS Protection y Key Vault ? Sí. Cada control actúa en una superficie, capa u objetivo distinto.

1.1 Seguridad como arquitectura, no como producto aislado

La defensa en profundidad significa combinar controles preventivos, detectivos y de respuesta. Un control puede fallar, ser eludido o no detectar cierto tipo de tráfico. La segmentación limita el movimiento lateral; un firewall central controla rutas y destinos; el WAF entiende protocolos web; el Key Vault reduce la exposición de credenciales. El resultado es una secuencia de barreras complementarias, y no una promesa de invulnerabilidad.

radio_button_uncheckedshort_text 2. Fundamentos técnicos: capas, flujos y estado

2.1 Capas de red y aplicación

Para el SC-900, no es necesario memorizar todo el modelo OSI, pero es esencial diferenciar los controles de red y de aplicación. Las capas 3 y 4 se ocupan principalmente de direcciones IP , protocolos de transporte y puertos, como TCP 443 o UDP 53. La capa 7 interpreta el protocolo de la aplicación, por ejemplo métodos, encabezados, rutas y contenido HTTP . La Protección DDoS actúa principalmente contra ataques de red L3/L4; los NSG filtran flujos por IP , puerto y protocolo; el WAF analiza HTTP / HTTPS en L7. Azure Firewall combina inspección stateful , reglas de red y reglas orientadas a aplicaciones y destinos.

2.2 Tráfico norte-sur y este-oeste

El tráfico norte-sur entra o sale del entorno, como usuarios accediendo a un sitio web o servidores consultando internet. El tráfico este-oeste circula entre componentes internos, como una API accediendo a una base de datos o dos redes virtuales intercambiando información. Una arquitectura segura controla ambos: el borde no debe ser la única barrera, ya que un atacante que comprometa un componente puede intentar moverse internamente.

2.3 Filtrado stateful y stateless

Un control stateful rastrea el estado de una conexión. Cuando un flujo de salida permitido inicia una sesión, el tráfico de respuesta correspondiente puede ser reconocido sin una regla reflejada manualmente. NSG y Azure Firewall son stateful . Esto no significa que “todo retorno está permitido”; significa que el servicio relaciona los paquetes con la conexión autorizada. Los controles stateless evalúan paquetes de forma independiente y normalmente requieren reglas explícitas para cada dirección.

2.4 Cinco elementos de un flujo

Concepto clave para examen

El puerto 443 no significa automáticamente “tráfico seguro”. TLS protege la comunicación, pero una solicitud HTTPS todavía puede contener un intento de inyección SQL. Por eso el WAF sigue siendo relevante.

radio_button_uncheckedshort_text 3. Azure Virtual Network, subredes y segmentación

Azure Virtual Network, o VNet, es la base de la red privada en Azure . Proporciona un espacio lógico e aislado en el cual los recursos pueden comunicarse usando direcciones IP privadas. Una VNet existe en una región, puede abarcar zonas de disponibilidad de esa región y puede conectarse a otras redes mediante emparejamiento, VPN o ExpressRoute. El aislamiento entre VNets es una propiedad importante: redes diferentes no se comunican automáticamente, a menos que se cree una conexión.

3.1 Espacio de direccionamiento y CIDR

Al crear una VNet, se define uno o más bloques de direcciones, normalmente privadas según RFC 1918, como 10.20.0.0/16. La notación CIDR indica cuántos bits identifican la red. Un bloque /16 contiene más direcciones que un /24. La planificación evita la superposición con redes locales y con otras VNets, ya que los intervalos superpuestos dificultan el peering, VPN y el enrutamiento.

3.2 Subredes como límites funcionales y de seguridad

Una subred divide el espacio de la VNet. En lugar de colocar todos los recursos en el mismo segmento, la organización separa componentes por función, sensibilidad o necesidad de comunicación. Una capa web puede aceptar tráfico del balanceador; la capa de aplicación acepta solo llamadas de la web; la capa de datos acepta solo el puerto de la base de datos proveniente de la aplicación. Esta organización reduce la superficie de ataque y facilita la aplicación de NSGs y rutas.

3.3 Conectividad no equivale a autorización

VNet y peering crean caminos de red; no reemplazan la autenticación, autorización o controles de la aplicación. Del mismo modo, bloquear un puerto no reemplaza el principio de menor privilegio en identidades. La seguridad de red limita “quién puede alcanzar el servicio”; la identidad y la autorización definen “quién puede usar el servicio y qué puede hacer”.

radio_button_uncheckedshort_text 4. Network Security Groups (NSGs)

Un Network Security Group filtra el tráfico de entrada y salida asociado a subredes o interfaces de red. Contiene reglas que permiten o deniegan flujos en función de la prioridad, dirección, protocolo, origen, destino y puertos. Los NSG son controles distribuidos y con estado : se encuentran cerca de los recursos y son adecuados para restringir la comunicación entre capas.

4.1 Componentes de una regla

4.2 Reglas estándar

Azure crea reglas predeterminadas de menor prioridad. Permiten el tráfico dentro de la VNet, permiten respuestas asociadas a determinados servicios de plataforma y niegan la entrada proveniente de Internet, mientras que la salida a Internet está permitida por defecto en muchos escenarios. Las reglas personalizadas de mayor prioridad pueden cambiar el resultado. Para el examen, el punto principal es que las reglas se procesan por prioridad hasta que se encuentra una coincidencia.

4.3 Etiquetas de servicio y Application Security Groups

Las etiquetas de servicio representan conjuntos de prefijos IP mantenidos por Azure , como Internet, VirtualNetwork o servicios específicos. Los Application Security Groups permiten agrupar interfaces de máquinas virtuales por función lógica, como WebServers o DatabaseServers, reduciendo la dependencia de direcciones individuales. Estos recursos hacen que las reglas sean más legibles y adaptables.

Ejemplo

La subred de aplicación puede aceptar TCP 443 solo del grupo WebServers y negar otras fuentes. La subred de base de datos puede aceptar TCP 1433 solo del grupo AppServers. Así, incluso si un host web se ve comprometido, el camino hacia otros recursos permanece limitado.

4.4 Lo que un NSG no hace

• No analiza inyección SQL, XSS ni semántica HTTP .
• No es un proxy de aplicación ni un servicio de publicación web.
• No reemplaza una solución central de firewall cuando se requieren control de salida, NAT , inspección avanzada o políticas entre muchas redes.
• No almacena secretos y no autentica a usuarios finales.

radio_button_uncheckedshort_text 5. Azure Firewall

Azure Firewall es un firewall como servicio, nativo de la nube, totalmente stateful y con alta disponibilidad integrada. Puede inspeccionar el tráfico norte-sur y este-oeste , funcionando como punto central de control en arquitecturas hub-and-spoke. En lugar de administrar appliances virtuales individualmente, la organización usa un servicio gestionado que escala con la plataforma.

5.1 Tipos de reglas

5.2 Azure Firewall versus NSG

NSG es un filtro distribuido aplicado a subredes e interfaces. Azure Firewall es un servicio centralizado por el cual el tráfico puede ser enrutado. En entornos pequeños, los NSG pueden satisfacer varios requisitos básicos. En arquitecturas corporativas, el firewall centraliza egress, inspección, NAT , registros y políticas entre múltiples redes. Frecuentemente se usan ambos: el firewall controla caminos centrales y los NSG imponen microsegmentación local.

5.3 SKUs y profundidad

La documentación actual presenta SKUs Basic, Standard y Premium. La elección depende de la escala y los recursos, como filtrado avanzado, inspección TLS y sistemas de prevención de intrusiones disponibles en capas superiores. Para el SC-900, es más importante reconocer el Azure Firewall como firewall de red administrado y con estado que memorizar todos los límites comerciales de cada SKU.

Trampa de prueba

Azure Firewall y WAF no son sinónimos. El Firewall protege los flujos de red y los destinos de forma amplia; el WAF está especializado en ataques contra aplicaciones web e interpreta HTTP / HTTPS .

5.4 Rutas definidas por el usuario

Para garantizar que el tráfico pase por el Azure Firewall, las subredes pueden utilizar tablas de rutas y rutas definidas por el usuario, conocidas como UDRs. Este patrón se llama forced tunneling cuando la organización fuerza determinado tráfico por un punto de inspección. Sin planificación de rutas, crear un firewall no garantiza que todos los flujos lo atraviesen.

radio_button_uncheckedshort_text 6. Azure Web Application Firewall ( WAF )

El Azure Web Application Firewall proporciona protección centralizada para aplicaciones web contra explotaciones y vulnerabilidades comunes. Opera en la capa de aplicación, entendiendo solicitudes HTTP y HTTPS . Puede integrarse con Azure Application Gateway , para entrada regional, y con Azure Front Door, para entrada global en el borde. El WAF reduce la necesidad de implementar la misma protección de forma aislada en cada aplicación, aunque no elimina la necesidad de correcciones en el código.

6.1 Ataques y anomalías observadas

• Inyección SQL: intento de manipular consultas a la base de datos mediante entradas maliciosas.
• Cross-site scripting ( XSS ): inserción de scripts en páginas consumidas por otros usuarios.
• Inclusión de archivos, inyección de comandos y violaciones del protocolo HTTP .
• Bots, escáneres, patrones de reputación de IP y volumen excesivo, según recursos y reglas disponibles.
• Encabezados, rutas, métodos y parámetros incompatibles con políticas definidas.

6.2 Reglas administradas y reglas personalizadas

Se mantienen conjuntos de reglas gestionadas para detectar clases conocidas de ataques, frecuentemente alineadas con las categorías OWASP . Las reglas personalizadas permiten bloquear o permitir en función de la dirección, país/región, encabezado, ruta, tamaño, tasa y otras condiciones. En modo de detección, el WAF registra coincidencias; en modo de prevención, puede bloquear solicitudes. La implementación debe comenzar con observación y ajuste para reducir falsos positivos.

6.3 WAF no reemplaza el desarrollo seguro

Un WAF es una capa compensatoria. Puede bloquear una carga conocida, pero no corrige fallas de autorización, lógica de negocio, exposición indebida de APIs o secretos en el código. Las aplicaciones siguen necesitando validación de entrada, autenticación, autorización, corrección de dependencias y pruebas de seguridad.

radio_button_uncheckedshort_text 7. Azure DDoS Protection

Un ataque distribuido de denegación de servicio, o DDoS, intenta agotar el ancho de banda, conexiones, CPU, memoria u otros recursos para hacer que un servicio sea inaccesible. Se llama distribuido porque utiliza muchas fuentes, frecuentemente dispositivos comprometidos. Cualquier endpoint accesible públicamente puede ser objetivo.

7.1 Protección de infraestructura y protección mejorada

La plataforma Azure posee protección de infraestructura contra ataques comunes. Azure DDoS Protection agrega recursos mejorados y adaptados a los recursos protegidos. La documentación actual diferencia DDoS Network Protection, asociado a redes virtuales mediante un plan, y DDoS IP Protection, habilitado por IP pública. Ambos comparten recursos centrales de ingeniería, pero difieren en modelo comercial y servicios adicionales.

7.2 Cómo actúa el servicio

• Monitoreo continuo de los patrones de tráfico.
• Ajuste adaptativo de límites basado en el perfil del recurso.
• Mitigación automática cuando el tráfico excede los parámetros de ataque.
• Métricas, alertas, registros e reportes para investigación.
• Protección contra vectores de capa 3 y 4, como inundaciones TCP , SYN y UDP .

7.3 La protección DDoS y WAF son complementarias

La Protección DDoS está especializada en disponibilidad y ataques volumétricos de red. El WAF protege la lógica HTTP /S y puede aplicar limitación de velocidad o reglas contra bots y explotaciones. Una aplicación web crítica frecuentemente usa ambos: DDoS para L3/L4 y WAF para L7. Azure Front Door también ofrece protección de borde e integración con WAF , pero el concepto examinable permanece en el uso de capas complementarias.

No confundas

DDoS no significa invasión exitosa ni robo de datos. El objetivo principal es la indisponibilidad. Sin embargo, los ataques pueden combinarse con otras técnicas o usarse como distracción, por lo que el monitoreo y la respuesta siguen siendo necesarios.

7.4 La resiliencia es parte de la defensa

La mitigación no sustituye la arquitectura resiliente. La distribución regional, las zonas de disponibilidad, el balanceo, el autoscale, el caching y los planes de respuesta reducen el impacto. La seguridad de disponibilidad depende del servicio de protección y del diseño capaz de continuar operando durante fallos o picos.

radio_button_uncheckedshort_text 8. Comparando DDoS Protection, NSG , Azure Firewall y WAF

8.1 Cómo resolver cuestiones por eliminación

1. Identifique el activo: IP pública, subred, flujo entre redes, aplicación HTTP o máquina virtual. 2. Identifique la amenaza: inundación, puerto indebido, destino no autorizado, explotación web o exposición administrativa. 3. Observe la capa: L3/L4 favorece DDoS, NSG o Firewall; L7 favorece WAF . 4. Busque palabras clave: “sin IP pública para RDP / SSH ” apunta a Bastion; “secretos, claves y certificados” apunta a Key Vault .

Regla mental

Disponibilidad volumétrica = DDoS. Filtrado distribuido = NSG . Control central de red = Azure Firewall. Ataque HTTP = WAF . Administración privada = Bastión. Material secreto = Key Vault .

radio_button_uncheckedshort_text 9. Azure Bastion

Azure Bastion es un servicio PaaS gestionado para conexión RDP y SSH a máquinas virtuales mediante TLS . Se despliega en la red virtual y permite acceder a las VM utilizando direcciones IP privadas. El beneficio principal es evitar el IP público directamente en la VM y reducir la exposición de los puertos administrativos 3389 y 22 a Internet.

9.1 Por qué abrir RDP / SSH a Internet es arriesgado

Los servicios administrativos expuestos reciben escaneos, intentos de contraseña, explotación de vulnerabilidades y ataques automatizados. Incluso con NSG restringido a determinadas direcciones, cambios de origen y errores de regla pueden ampliar la exposición. Bastion crea un punto de entrada gestionado, mientras que las VMs permanecen privadas.

9.2 Lo que ofrece Bastion

• Sesiones RDP o SSH protegidas por TLS .
• Conexión por el portal y, según el SKU, por clientes nativos y recursos adicionales.
• Ausencia de agente especial dentro de la VM para el escenario principal.
• Reducción de IPs públicas y de puertos administrativos expuestos.
• Posibilidad de recursos de auditoría y grabación de sesión en ofertas específicas.

9.3 Lo que Bastion no resuelve solo

Bastion no sustituye la autenticación fuerte, RBAC , actualización del sistema operativo, protección del endpoint , registros y principio del menor privilegio. Un administrador excesivamente privilegiado sigue siendo un riesgo. El servicio protege el camino de red; la identidad y el sistema operativo todavía necesitan sus propios controles.

Detalle de arquitectura

Implementaciones dedicadas utilizan una subred reservada llamada AzureBastionSubnet. Esta subred debe planificarse según los requisitos actuales del servicio y no debe alojar cargas de trabajo comunes.

radio_button_uncheckedshort_text 10. Azure Key Vault : secretos, claves y certificados

Azure Key Vault es un servicio en la nube para almacenar y acceder a material sensible con control riguroso. Reduce la práctica insegura de insertar contraseñas, tokens o claves en el código fuente, variables compartidas, archivos de configuración, pipelines o imágenes de contenedor. El servicio separa la aplicación del ciclo de vida de las credenciales y proporciona autorización, auditoría e integración con identidades de Microsoft Entra .

10.1 Tres tipos principales de objetos

10.2 Vault y Managed HSM

Los cofres de Key Vault almacenan secretos, claves y certificados; las claves pueden estar protegidas por software o HSM según la capa. Managed HSM es un servicio dedicado para claves protegidas por módulos de seguridad de hardware y atiende escenarios de control criptográfico más exigentes. Para el SC-900, el punto central es que Key Vault gestiona secretos, claves y certificados; Managed HSM profundiza la protección y el control de claves.

10.3 Plan de control y plan de datos

El plano de control administra el recurso Azure : crear el cofre, configurar la red, diagnósticos y políticas. El plano de datos accede a los objetos: leer un secreto, firmar con una clave u obtener un certificado. Una identidad puede tener permiso para administrar el recurso sin tener permiso para leer los secretos, y viceversa. Esta separación aplica el principio de menor privilegio.

Secreto versus llave

Una contraseña necesita ser revelada a la aplicación para su uso y normalmente se almacena como secreto. Una clave criptográfica puede permanecer dentro del servicio: la aplicación solicita una operación de firma o descifrado sin recibir el material privado.

radio_button_uncheckedshort_text 11. Acceso seguro y ciclo de vida en Key Vault

11.1 Autenticación y autorización

Microsoft Entra autentica a usuarios, aplicaciones e identidades administradas. Luego, Key Vault autoriza la operación mediante Azure RBAC o, en entornos heredados, políticas de acceso. RBAC permite asignar funciones en ámbitos como suscripción, grupo de recursos o bóveda. La recomendación moderna es aplicar roles mínimos y separar administradores de infraestructura de consumidores de secretos.

11.2 Identidades administradas

Una identidad administrada elimina la necesidad de una credencial fija para que la aplicación se autentique en Entra. El recurso de Azure recibe una identidad y obtiene tokens automáticamente. La aplicación usa el token para solicitar únicamente el objeto o la operación autorizada. Así, no es necesario guardar una “contraseña del Key Vault ” en el propio código.

11.3 Protección de red

Además de la autorización, la bóveda puede restringir caminos de red. El firewall del Key Vault , redes seleccionadas y el Private Endpoint permiten acceso privado desde una VNet. Esta combinación reduce la exposición pública, pero no reemplaza el RBAC : estar en la red correcta no otorga el derecho de leer un secreto.

11.4 Versionado, rotación y recuperación

• Los objetos poseen versiones, lo que permite actualizar sin reutilizar el mismo valor indefinidamente.
• La rotación reduce el período en que una credencial comprometida permanece válida.
• La expiración y las alertas ayudan a evitar certificados vencidos y secretos olvidados.
• El borrado suave mantiene los objetos eliminados por un período de retención.
• La protección de purga impide la eliminación definitiva durante el período configurado, protegiendo contra la destrucción maliciosa o accidental.
• Registros y diagnósticos registran solicitudes para auditoría e investigación.

Buena práctica

Use cofres separados por aplicación, ambiente y región cuando eso reduzca el impacto y simplifique

radio_button_uncheckedshort_text 12. Arquitectura integrada: cómo los servicios trabajan juntos

Considere una aplicación de comercio electrónico. Los usuarios llegan por internet. La capa de borde absorbe y distribuye tráfico; DDoS Protection ayuda contra ataques de red volumétricos; el WAF bloquea solicitudes HTTP maliciosas. El front-end está en una subred propia, la API en otra y la base de datos en una tercera. Los NSG permiten solamente los flujos necesarios entre estas capas.

El Azure Firewall en el hub controla salidas hacia internet, acceso a destinos aprobados y comunicación entre redes. Los administradores acceden a las máquinas virtuales a través de Bastion, sin IP pública en las VMs. La aplicación usa una identidad administrada para recuperar en el Key Vault la cadena de conexión o para ejecutar una operación con la llave. Los registros de WAF , NSG , Firewall, Bastion y Key Vault se envían para monitoreo e investigación.

12.1 Flujo normal de una solicitud

5. El usuario envía HTTPS al punto de entrada público. 6. La protección DDoS monitorea el volumen y mitiga patrones de ataque L3/L4. 7. El WAF inspecciona la solicitud HTTP /S y aplica reglas gestionadas y personalizadas. 8. El front-end llama a la API solo por el puerto autorizado en el NSG . 9. La API se autentica con identidad administrada y obtiene el secreto necesario en el Key Vault . 10. La API accede a la base de datos solo por el flujo permitido entre subredes.

12.2 Flujo durante un incidente

Si un origen intenta explotar SQL injection, el WAF puede detectar y bloquear. Si el volumen crece de forma anormal, DDoS Protection actúa en la disponibilidad. Si un servidor comprometido intenta acceder a un destino malicioso, Azure Firewall puede alertar o negar con inteligencia de amenazas. Si alguien intenta leer un secreto sin función adecuada, el Key Vault niega y registra la solicitud. La arquitectura convierte un incidente amplio en eventos observables y límites de contención.

radio_button_uncheckedshort_text 13. Decisiones de proyecto, monitoreo y errores comunes

13.1 Comenzar por los requisitos, no por los productos

La selección de controles debe partir de activos, amenazas, caminos de datos y requisitos regulatorios. Una aplicación interna sin IP pública puede no necesitar el mismo diseño de borde que un portal global. Un entorno con pocas redes puede comenzar con NSG ; una organización con decenas de suscripciones puede necesitar hub-and-spoke, Azure Firewall y políticas centralizadas. Key Vault es útil siempre que haya secretos, pero la forma de aislamiento y HSM depende del riesgo.

13.2 Observabilidad

Controles sin registros limitan la detección y la investigación. Los diagnósticos pueden enviarse a Log Analytics, Storage, Event Hubs y soluciones como Microsoft Sentinel , según el servicio. Las métricas DDoS muestran mitigación; los registros del WAF registran reglas activadas; los registros de flujo de NSG o recursos equivalentes ayudan a entender los flujos; el Firewall registra decisiones; Key Vault registra operaciones; Bastion puede ofrecer auditoría de sesión en ofertas compatibles.

13.3 Principio del menor privilegio en todas las capas

El menor privilegio no se limita a funciones de identidad. En red, significa permitir solamente orígenes, destinos, puertos y protocolos necesarios. En WAF , significa publicar solo rutas y métodos esperados. En administración, significa reducir personas y máquinas que pueden iniciar sesiones. En Key Vault , significa conceder solo acciones específicas sobre objetos necesarios.

Estrategia de implementación

Planifique, implemente en modo de observación cuando sea aplicable, valide registros, ajuste falsos positivos, automatice mediante infraestructura como código y revise periódicamente reglas y permisos.

radio_button_uncheckedshort_text 14. Escenario práctico integrado

Una empresa migra su portal de atención al Azure . El portal es público, posee APIs internas, base de datos y dos máquinas virtuales de soporte. La organización quiere reducir la indisponibilidad, impedir la exposición administrativa, limitar la comunicación entre capas y eliminar contraseñas del código.

14.1 Solución propuesta

14.2 Secuencia de implementación

11. Planificar bloques CIDR sin superposición y crear subredes por función. 12. Aplicar NSGs con reglas explícitas para web, aplicación, datos y administración. 13. Crear el punto de entrada con WAF y validar las reglas en modo de detección antes de bloquear. 14. Habilitar protección DDoS adecuada para las IPs públicas críticas. 15. Implementar Azure Firewall y rutas cuando haya requisito de inspección central y egress controlado. 16. Implementar Bastion y eliminar IPs públicas innecesarias de las VMs. 17. Crear Key Vault , habilitar recuperación, configurar la red, asignar RBAC mínimo y usar identidad administrada. 18. Enviar logs a una plataforma de monitoreo y probar escenarios de falla y respuesta.

14.3 Resultado

El ambiente no se vuelve invulnerable, pero gana límites claros. Los ataques volumétricos encuentran mitigación; los ataques web encuentran inspección; las compromisiones internas encuentran segmentación; la administración no depende de puertos públicos; las credenciales dejan de circular en el código. Cada evento genera evidencias para operación y auditoría. Esta es la esencia de la defensa en profundidad aplicada a la infraestructura de Azure .

Punto de prueba

La mejor respuesta suele ser el servicio más específico para el requisito presentado, no el producto “más avanzado”. Lea el verbo: mitigar DDoS, filtrar flujo, inspeccionar HTTP , administrar VM o almacenar secreto.

radio_button_uncheckedshort_text 15. Revisión rápida para el examen SC-900

• VNet es la red privada lógica en Azure ; las subredes dividen su espacio de direcciones y organizan las cargas de trabajo.
• NSG es stateful y filtra entrada/salida por prioridad, dirección, protocolo, origen, destino y puerto.
• Azure Firewall es un firewall como servicio central, stateful , con reglas de red, aplicación, NAT y recursos de amenaza.
• WAF protege aplicaciones web contra ataques y anomalías HTTP / HTTPS en la capa 7.
• Azure DDoS Protection mitiga ataques distribuidos de denegación de servicio, principalmente en las capas 3 y 4.
• Bastion permite RDP / SSH a VM por IP privado sin exposición directa de IP público en la máquina.
• Key Vault almacena secretos, claves y certificados e se integra con Entra, RBAC e identidades administradas.
• El Endpoint Privado restringe el camino de red, pero no reemplaza la autorización.
• Los servicios son complementarios e implementan defensa en profundidad.

radio_button_uncheckedshort_text 16. Conclusión

Proteger la infraestructura en la nube exige comprender flujos, capas y responsabilidades. Las redes virtuales y subredes crean aislamiento; los NSG restringen la comunicación local; Azure Firewall centraliza políticas de red; WAF interpreta el tráfico web; DDoS Protection preserva la disponibilidad; Bastion reduce la exposición administrativa; Key Vault protege secretos y material criptográfico. La seguridad surge de la combinación coherente de estos servicios con identidades, monitoreo y procesos humanos.

En mi evaluación, el concepto más valioso de este capítulo es la especialización de los controles. Los proyectos inseguros frecuentemente intentan hacer que un producto resuelva todos los riesgos. Los proyectos maduros preguntan cuál activo está expuesto, qué capa está siendo atacada, qué flujo necesita existir y qué evidencia será generada. Esta forma de pensar prepara al alumno no solo para el SC-900, sino para decisiones reales de arquitectura.

radio_button_uncheckedshort_text 17. Preguntas de repaso

1. Una empresa necesita bloquear intentos de inyección SQL en un portal HTTPS . ¿Cuál servicio es el más directamente indicado?

A) NSG B) Azure Web Application Firewall C) Azure Bastion D) Azure Key Vault

Respuesta comentada

Respuesta correcta: B. El WAF interpreta HTTP / HTTPS en la capa 7 y tiene reglas para ataques web, incluyendo inyección SQL.

2. ¿Qué servicio permite conectarse por RDP o SSH a una VM usando IP privada, sin exponer directamente una IP pública en la VM?

A) Azure Bastion B) Azure DDoS Protection C) WAF D) Network Security Group

Respuesta comentada

Respuesta correcta: A. Azure Bastion proporciona un camino gestionado para RDP / SSH sobre TLS a máquinas virtuales privadas.

3. ¿Qué afirmación describe mejor la diferencia entre NSG y Azure Firewall?

A) NSG protege solamente HTTP y Firewall solamente bancos. B) NSG almacena secretos y Firewall emite certificados. C) NSG es filtro distribuido en subnets/interfaces; Azure Firewall es control central stateful para tráfico entre redes e internet. D) No existe diferencia funcional.

Respuesta comentada

Respuesta correcta: C. Pueden usarse juntos: NSG para segmentación local y Azure Firewall para políticas e inspección centralizadas.

4. Una aplicación necesita acceder a una contraseña bancaria sin mantener credenciales fijas en el código. ¿Qué combinación es la más adecuada?

A) WAF y Protección DDoS B) Azure Key Vault e identidad administrada C) Bastion y NSG D) Azure Firewall e IP público

Respuesta comentada

Respuesta correcta: B. La identidad administrada autentica la aplicación, y el Key Vault entrega solo el secreto autorizado.

radio_button_uncheckedshort_text 18. Glosario esencial

radio_button_uncheckedshort_text 19. Referencias oficiales para profundización

• Microsoft Learn - Guía de estudio para el examen SC-900: Fundamentos de Seguridad, Cumplimiento e Identidad de Microsoft. Actualizado el 26 de junio de 2026.
• Microsoft Learn - Descripción general de la protección DDoS de Azure .
• Microsoft Learn - ¿Qué es Azure Firewall?
• Microsoft Learn - Introducción al Azure Web Application Firewall.
• Microsoft Learn - Descripción general de los grupos de seguridad de red de Azure .
• Microsoft Learn - Redes virtuales y subredes de Azure .
• Microsoft Learn - ¿Qué es Azure Bastion?
• Microsoft Learn - Conceptos básicos de Azure Key Vault .
• Microsoft Learn - Descripción general de claves, secretos y certificados de Azure Key Vault .
• Microsoft Learn - Asegura tu Azure Key Vault .

Observación sobre actualización

Los servicios en la nube evolucionan continuamente. Para precios, SKUs, regiones, límites y recursos disponibles, consulte siempre la documentación oficial más reciente. El enfoque de este capítulo es el propósito y la diferenciación conceptual exigidos en el SC-900.