Cerrar
InicioAzureInfraestructura en Microsoft Azure y Servicios de Office 365 [Parte II]: tips para tu firewall

Infraestructura en Microsoft Azure y Servicios de Office 365 [Parte II]: tips para tu firewall

Continuando con el segundo artículo sobre alguna posible infraestructura de Azure y O365 [Infraestructura en Microsoft Azure y Servicios de Office 365 [Parte I]], vamos a poner algunos tips sobre la inclusión de un Firewall en tu vNet en Azure. Desde un punto de vista conceptual, pero teniendo en cuenta varios servicios:

  • Clientes VPN
  • Usuarios de Azure Virtual Desktop
  • Conexiones entre vNet
  • Definición de reglas de Firewall entre vNet y Subredes

Aquí os dejo una topología de referencia para los tips que daré en este artículo:

Como podéis apreciar, la idea es ir segmentando las vNets y Subnets, haciendo pasar todo el tráfico entre ellas pero siempre filtradas por nuestro Firewall. Aquí os dejo un par de artículos que os pueden ser de interés con respecto a la gestión de las vNet y Firewall de Azure (pero puede ser cualquiera que podáis implementar en Azure):

La idea es aplicar ciertos niveles de filtrado (sin entrar en el detalle de las reglas) en donde podéis empezar a aplicar ciertos controles de seguridad básico pero a su vez, importantes. Al final, todo tráfico que entra o sale de nuestras redes (cualquier de ellas), deberías ser supervisado y controlado por nosotros, no podemos dejar nada a la imaginación .. de otros :-).

Como no lo puedo documentar todo, os voy a poner algunos tips sencillo para “proteger/filtrar” el tráfico de red que puede circular por vuestra red de Azure. Antes de nada, comentar que debemos permitir únicamente el tráfico indispensable, nunca debemos permitir más tráfico del que nuestros servicios necesitan para estar 100% operativos.

Aquí van algunos tips sencillos para vuestros filtros en función de cada servicio desplegado en el esquema anterior:

  • Clientes VPN: es posible/probable que tengamos la necesidad de tener equipos conectados por VPN a nuestra infraestructura, tanto usuarios internos como externos. Es importante filtrar sus conexiones y acceso hacia nuestra infraestructura, si podemos evitar split-tunneling sería una opción perfecta para que todas las sesiones de red (red privada e internet) pasen por el firewall, lo que nos permitiría controlar incluso la navegación de internet mientras están conectados a nuestra red. Debemos ser capaces de identificar por perfiles de equipos/usuarios (si tenéis es posibilidad) para aplicar filtros dinámicos en función del dispositivo/usuario conectado.
  • Usuarios de Azure Virtual Desktop: si tenemos usuarios conectados vía AVD, vamos a necesitar controlar el tráfico que generan desde esas máquinas virtuales. Debemos centrarnos a que servicios internos le vamos a permitir el acceso (IP Origen, IP Destino, Servicio/Puerto), en que franjas horarias y siempre con el log habilitado tirando registros a un syslog o colector de registros especializado. En este escenario, es posible que podamos tener al “enemigo” dentro, por lo que es importante permitirle las conexiones a los servicios de forma explícita como son:
    • Webs específicas
    • Office 365 (Exchange, SPO, ODFB, Teams, etc..)
    • Conexiones a otros equipos de la red, puesto que, si somos administradores o internamente nos volvemos a conectar a otros servidores vía RDP u otro protocolo, debemos tenerlo siempre identificado y controlado.

Además de todo esto, debemos tener cuidado con los accesos propios del servicio de Azure Virtual Desktop de Azure, aquí os dejo un enlace que debéis verlo con atención para no evitar que los hosts no lleguen a los pool: Use Azure Firewall to protect Azure Virtual Desktop deployments

Azure Virtual Desktop architecture

Os dejo también por aquí, como podéis configurar en vuestras GPO la configuración avanzad de los Firewall de Windows para evitar/permitir el tráfico de red en función del tipo de usuario conectado a vuestros hosts de sesión: Windows Firewall: Aplica filtros autenticados a tus usuarios de AVD

  • Conexiones entre vNet: aquí hablamos primero de emparejamientos, como bien sabéis no son transitivas en Azure (A confía en B y B confía en C, pero C no confía en A), pero debemos siempre tener reglas específicas para el tráfico que puedan necesitar cursar entre ellas. Por ejemplo, si tenemos una red de Hub y Spokes, es posible que necesitemos que tengan acceso entre ellas (Adds, Dns, Nps, etc…). Además, si tenemos las cargas de trabajo de nuestros servidores bien segmentadas, tenemos los servidores de apps y bbdd (por ejemplo) en diferentes vNets, evitando que un servidor que se haya podido ver comprometido se convierta en un vector de ataque al resto de servicios. Ni que  decir tiene que, las conexiones siempre tienen que estar permitidas de forma explícita en el firewall, ejemplo un servidor de aplicaciones y uno de bbdd de SQL server:
    • IP Origen: servidor de aplicaciones
    • IP Destino: servidor de base de datos
    • Puerto: 1433 (o el que hayamos configurado)
    • Log activado: si

Si estamos utilizando un firewall centralizado en la red de Hub, todo el tráfico siempre irá centralizado por dicho firewall, lo que nos permite siempre mantener el control del tráfico entre vNets (Azure Firewall: Centralizar la salida a Internet de las vNet, Azure Firewall: Internet Centralizado por Hub, Emparejamiento y Conexión vía VPN con On-Premises)

Como podéis apreciar, al final es cuestión de hilar lo más fino posible y mantener siempre el control sobre vuestra red. Además, deberíais utilizar diferentes herramientas de monitorización y correlación de logs y eventos [+info Correlación de logs y eventos [INCIBE]].

Este artículo es súper básico, lo sé, pero creo que es bueno que se tome conciencia que la seguridad es cosa de todos y en todos los elementos vivos de nuestras infraestructuras. No puedo entrar en el detalle de todos los firewalls ni servicios, porque no los conozco y porque sería imposible dejarlo documento ni en 100 artículos.

Simplemente he querido comentar lo que creo que deberíamos hacer, MPP (Mínimo Privilegio Posible) SIEMPRE. Trabajar muy bien el diseño de nuestras soluciones, teniendo bien clarito como funcionan y que servicios tienen interconexión entre ellos y como los puedo proteger. Luego ya el firewall o aplicación o servicio que utilicemos para dar cabida  a todo esto, seguro que cada uno tiene su mejor aliado. Pensad que además del propio tráfico de red que está involucrado directamente con nosotros, tenemos el resto:

  • Como se conectan nuestros usuarios a la red pública
  • Como se autentican
  • Etc..

A continuación, os dejo algunos artículos que os pueden ser de ayuda:

Seguramente me he dejado millones de cosas atrás, pero espero que se entienda el fin de este artículo. Epero que os sirva como introducción, si alguien quiere dejar algún comentario, por favor, adelante!!!

Microsoft Intune: Ac
Microsoft Intune: In
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This