Este Artículo será parte de una serie de posts en los que hablaremos de diferentes aspectos de los Clouds Públicos más importantes. Empecemos por las redes virtuales en Microsoft Azure.
Las Redes virtuales en Azure inteconectan Azure Virtual Machines y otros recursos y servicios. Por defecto solo las VMs dentro de la misma red tienen interconexión, asímismo, las VMs y servicios fuera de esa red virtual no pueden conectarse con las VMs dentro de la red.
En Azure se pueden usar las IPs privadas clases A, B y C (10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16), la forma más sencilla de planificar la interconexión con una red on-premise es no solapar los diferentes segmentos. Quizás usar un segmento contiguo a la red del Data Center sería interesante para la administación y aplicación de políticas de tráfico.
En cuanto a la Segmentación de redes virtuales, de igual manera como lo hacemos on-premises podemos segmentar las redes virtuales para crear subredes y así poder tener diferentes segmentos por roles o por dominios de seguridad distintos, por ejemplo: Producción 10.0.0.0, desarrollo 10.1.0.0 o BBDD 10.3.0.0.
Azure reserva las 4 primeras direcciones de cada subred para uso interno.
Cuando hablamos de Seguridad por defecto no cuenta con segmentación entre cada subred, lo que quiere decir que todas las subredes se podrían comunicar (muy parecido a cuando hacemos SVIs o VLANs Interfaces en un Switch Multicapa) cuando queremos aplicar políticas de comunicación a nivel de puertos TCP/UDP o IP introducimos los Network Security Groups (NSG) para controlar el flujo de comunicación entre redes, subredes y VMs. Su funcionamiento es muy parecido a un Firewall Tradicional de de Capa 4. Esto sería similar a lo que hacemos con Enpoints Policy Groups en Cisco ACI o Security Groups en VMWare NSX (pero esto lo dejamos para un siguiente artcículo).
Este es un artículo original del Blog, si le parece interesante, por favor compártalo.
