Control del tráfico con grupos de seguridad de red (NSG)
Los grupos de seguridad de red (NSG) proporcionan un control preciso sobre qué cargas de trabajo pueden comunicarse entre sí en Azure. El equipo de Contoso ha priorizado tres objetivos de segmentación en función de la evaluación de la unidad 2: bloquee las máquinas virtuales de nivel web (VM) de acceder directamente al nivel de base de datos en el puerto 1433, aísle las máquinas virtuales de desarrollo de las cargas de trabajo de producción y permita que las máquinas virtuales de nivel de aplicación lleguen solo al nivel de base de datos en el puerto 1433. Aquí aprenderá a configurar reglas de NSG para aplicar estos objetivos mediante un enfoque de seguridad primero y con privilegios mínimos.
| Step | Acción |
|---|---|
| Definición de objetivos de segmentación | Identificar qué cargas de trabajo necesitan acceso y cuáles deben bloquearse |
| Crear un NSG con la línea base de denegación total | Comience con una regla de denegación para bloquear todo el tráfico de forma predeterminada |
| Adición de reglas de permiso específicas | Permitir solo el tráfico documentado crítico para la empresa |
| Asociar NSG a una subred | Aplicar el conjunto de reglas a todos los recursos del nivel |
| Validar el orden de prioridad de la regla | Asegúrese de que las reglas de denegación se ejecutan antes de que las reglas de permiso entren en conflicto |
Comprender la arquitectura de NSG y el diseño con la seguridad como prioridad
Un NSG es una lista de reglas de seguridad entrantes y salientes que Azure evalúa por orden de prioridad para determinar si se debe permitir o denegar el tráfico. Cada regla de NSG especifica un origen, destino, protocolo, intervalo de puertos y acción (Permitir o Denegar).
Los NSG pueden asociarse a subredes o tarjetas de interfaz de red individuales (NIC). La asociación de la subred es la opción correcta para la segmentación por nivel porque afecta a todos los recursos de la subred y simplifica la gestión. Los grupos de seguridad de red a nivel de NIC crean más complejidad y pueden entrar en conflicto con las reglas de NSG de la subred, lo que dificulta la solución de problemas.
Cada NSG incluye reglas predeterminadas que no se pueden eliminar. Estos valores predeterminados permiten el tráfico dentro de la red virtual (AllowVNetInBound en prioridad 65000), permiten el tráfico desde el equilibrador de carga de Azure (AllowAzureLoadBalancerInBound con prioridad 65001) y deniegan el resto del tráfico entrante (DenyAllInBound con prioridad 65500). Existen reglas similares para el tráfico saliente. Las reglas personalizadas con números de prioridad inferior se ejecutan antes de estos valores predeterminados.
El enfoque de seguridad por defecto comienza con un NSG de subred que lo deniega todo y solo agrega las reglas de permiso necesarias. Este enfoque es lo contrario del método predeterminado de permitir todo y luego añadir una regla de denegación, que es el que adoptan la mayoría de los administradores de red, pero evita la exposición accidental de las cargas de trabajo durante los cambios de configuración.
La prioridad es importante porque Azure evalúa las reglas en orden del número de prioridad más bajo al más alto. Una regla de denegación con prioridad 100 bloquea el tráfico antes de que Azure evalúe la regla de permiso en prioridad 200. Esto significa que debe reservar el intervalo de prioridad 100-200 para las reglas de denegación críticas que aplican límites de seguridad estrictos.
Configuración de las propiedades de regla para aplicar privilegios mínimos
Cada regla de NSG requiere seis propiedades que, en conjunto, determinan qué tráfico se permite o se deniega.
El origen y el destino aceptan una dirección IP, un intervalo CIDR (enrutamiento sin clases Inter-Domain) o una etiqueta de servicio o un grupo de seguridad de aplicaciones. Las etiquetas de servicio como AzureLoadBalancer, Internet y la red virtual permiten definir el ámbito de las reglas sin administrar listas de direcciones IP. Por ejemplo, el uso de la etiqueta AzureLoadBalancer como origen permite el tráfico desde el equilibrador de carga de infraestructura de Azure (168.63.129.16) sin codificar de forma rígida esa dirección IP.
Protocol especifica TCP, UDP o Any. Ser específico: elegir "Cualquiera" crea un riesgo innecesario. Si la aplicación usa el puerto TCP 1433 para las conexiones SQL Server, la regla debe especificar TCP, no Any.
Port acepta un número de puerto específico (como 1433, 22, 443 o 3389) o un intervalo. Evite intervalos amplios como 0-65535 en las reglas permitidas porque debilitan el principio de privilegios mínimos. Con las reglas de seguridad aumentadas, puede especificar varios puertos, direcciones de origen o direcciones de destino en una sola regla mediante valores separados por comas, que reducen el número total de reglas.
La acción es Permitir o Denegar. Use reglas de denegación para crear límites de seguridad estrictos y Permitir que las reglas abran caminos específicos documentados.
La prioridad oscila entre 100 y 4096, con números inferiores evaluados primero. Deje huecos entre los números de prioridad para que los administradores futuros puedan insertar reglas sin volver a numerar todo el conjunto de reglas.
Sugerencia
Use etiquetas de servicio siempre que sea posible en lugar de direcciones IP de codificación rígida. Las etiquetas como la red virtual y AzureLoadBalancer se adaptan automáticamente cuando Azure actualiza sus intervalos IP de infraestructura, lo que reduce el mantenimiento a largo plazo.
Adjuntar un NSG a la subred de la base de datos
El equipo de Contoso crea un NSG (grupo de seguridad de red) para proteger la capa de base de datos mediante la asociación a nivel de subred. Los pasos siguientes muestran la secuencia de configuración en el portal de Azure.
- Cree un nuevo grupo de seguridad de red denominado
nsg-database-subneten el mismo grupo de recursos que la red virtual. - Agregue una regla de permiso de entrada con el origen establecido en el intervalo IP de subred de la aplicación (por ejemplo, 10.0.2.0/24), destino establecido en Any, protocol establecido en TCP, puerto de destino establecido en 1433, prioridad establecida en 200 y acción establecida en Permitir.
- Agregue una regla de denegación de entrada con el origen establecido en Cualquier, destino establecido en Any, protocolo establecido en TCP. A continuación, asegúrese de que el puerto de destino esté establecido en 1433, la prioridad esté establecida en 300 y la acción esté establecida en Denegar para impedir que cualquier otro origen acceda al puerto 1433.
- Agregue una regla de entrada que deniegue todo con prioridad 4000, con el origen establecido en Any, el destino establecido en Any, el protocolo establecido en Any, el puerto establecido en Any y la acción establecida en Deny, como medida de seguridad redundante, aunque la regla predeterminada DenyAllInBound con prioridad 65500 ya proporciona esta protección.
- Adjunte el grupo de seguridad de red a la subred de la base de datos en lugar de a NIC individuales, ya que la aplicación de nivel de subred es más amplia y sencilla de administrar.
La asociación de la subred implica que todas las máquinas virtuales de la capa de base de datos heredan automáticamente la misma protección. Cuando Contoso agrega un nuevo servidor de bases de datos a la subred, las reglas de NSG se aplican inmediatamente sin configuración adicional.
Traducir los objetivos de segmentación a reglas de NSG
Los tres objetivos de segmentación de Contoso se asignan directamente a reglas de NSG específicas. En la tabla siguiente se muestra cómo cada requisito empresarial se traduce en un control técnico.
| Objetivo | Tipo de regla | Source | Puerto de destino | Acción | Priority |
|---|---|---|---|---|---|
| Bloquear base de datos de → web (puerto 1433) | Entrada en la subred de base de datos | CIDR de la subred web (x.x.x.x/24) | 1433 | Denegar | 100 |
| Permitir aplicación → base de datos (puerto 1433) | Entrada en la subred de base de datos | CIDR de la subred de la aplicación (x.x.x.X/24) | 1433 | Permitir | 200 |
| Bloquear desarrollo → producción (todos los puertos) | Tráfico entrante en la subred de producción | CIDR de subred de desarrollo (x.x.x.x/24) | * | Denegar | 100 |
| Permitir el equilibrador de carga → web (443) | Entrada en la subred web | Etiqueta AzureLoadBalancer | 443 | Permitir | 200 |
Estas reglas usan intervalos CIDR como origen, que funciona en entornos estables donde las asignaciones de subred no cambian con frecuencia. En la unidad siguiente, reemplazará los orígenes basados en CIDR por grupos de seguridad de aplicaciones, lo que facilita el mantenimiento de estas reglas a medida que se escala el entorno.
Evitar errores comunes de configuración de NSG
Varios antipatrones debilitan la eficacia de los NSG y crean una falsa sensación de confianza en su postura de seguridad.
Las reglas de tipo Allow Any → Any anulan por completo el beneficio de seguridad de los NSG. Si tiene una justificación empresarial documentada para permitir todo el tráfico, es probable que el entorno no necesite segmentación a nivel de NSG. El apilamiento de demasiados NSG de nivel de NIC que entran en conflicto con los NSG de subred crea una solución de problemas difícil porque Azure evalúa ambas capas y aplica la regla más restrictiva.
Brechas de prioridad que permiten a los administradores futuros insertar reglas por encima de las reglas de denegación crean un desfase de seguridad a lo largo del tiempo. Por ejemplo, si la regla de denegación crítica tiene prioridad 200 y la regla de permiso tiene prioridad 300, alguien puede insertar una regla de permiso en la prioridad 150 que omite la regla de denegación. Reserve el intervalo de 100 a 199 para las reglas de denegación y haga que las reglas de permiso comiencen en 200 o superior.
No habilitar los registros de flujo de NSG impide auditar qué tráfico bloquean o permiten las reglas. Los registros de flujo de NSG se alimentan de herramientas como Microsoft Defender para la nube y Microsoft Sentinel para detectar anomalías.
El principio de privilegios mínimos se aplica a las reglas de NSG: si no tiene un motivo empresarial documentado para una regla, no debería existir. Revise el conjunto de reglas trimestralmente y quite las reglas que ya no atienden cargas de trabajo activas.
Las reglas CIDR basadas en IP funcionan en entornos estables, pero a medida que cambian las cargas de trabajo y las direcciones IP, el mantenimiento de CIDR de origen y destino precisos se convierte en propenso a errores.