El enfoque de seguridad tradicional se basaba principalmente en la defensa del perímetro protegiendo el tráfico norte-sur, asumiendo que el tráfico este-oeste del centro de datos es intrínsecamente seguro, lo que significa que hace poco para frustrar las APT (tipo de malware diseñado para evadir controles de seguridad convencionales). Los modelos de seguridad convencionales asumen que se puede confiar en todo lo que se encuentra dentro de la red de una organización, mientras que la confianza cero asume lo contrario, ya que es un enfoque para mejorar las defensas del centro de datos. Este requiere la inspección de cada flujo de tráfico dentro del mismo y divide la infraestructura en zonas de seguridad más pequeñas. El tráfico entre las zonas se inspecciona para garantizar que se adhiere a las políticas de seguridad definidas por la organización, una de las principales funcionalidades que entrega NSX-T con la microsegmentación.
La microsegmentación por su parte es un enfoque para dividir la infraestructura del centro de datos en pequeñas zonas (Imagen 1) como ya lo mencionamos anteriormente, permite un control más fino de los flujos de tráfico entre cada carga de trabajo, permitiendo al administrador proteger toda la comunicación este-oeste. La microsegmentación proporcionada por NSX-T admite una arquitectura de confianza cero para la seguridad de TI, también establece un perímetro de seguridad alrededor de cada VM o carga de trabajo de contenedor con una política definida dinámicamente en el centro de datos local, así como en la nube. Un componente clave que hace posible la microsegmentación es el firewall distribuido ubicado en la vNic de cada máquina, que se implementa en el puerto lógico de la carga de trabajo y permite un nivel granular de aplicación, independientemente si es una máquina virtual, contenedor, servidor o dónde esa carga de trabajo reside – On Premise – AWS -Azure – VMC. Todas las políticas se configuran de forma centralizada desde la interfaz de usuario, a través de un CMP o utilizando nuestra API.
Debido a que NSX está integrado en el hipervisor, tiene un amplio conocimiento contextual de lo que está sucediendo con las cargas de trabajo dinámicas en los entornos físicos y virtuales. Además, podemos usar construcciones basadas en características específicas incluido, por ejemplo, el sistema operativo o el nombre de la carga. Mediante el uso de etiquetas de seguridad, la carga de trabajo también se puede agrupar según criterios como la función de la aplicación, el nivel de aplicación del que forma parte, la postura de seguridad, los requisitos reglamentarios como PCI o GDPR o el entorno en el que se implementa la aplicación. En los enfoques de seguridad tradicionales, las políticas se aplican a grupos estáticos definidos por la topología de la red, como zonas de seguridad y subredes IP. Tenemos que poder identificar nuestra aplicación, determinar qué cargas de trabajo la comprenden y qué tráfico de red es necesario para que la aplicación funcione. Luego, podemos crear políticas de microsegmentación para restringir cualquier otro tráfico, lo que reduce inmediatamente la superficie de ataque.
La identificación de aplicaciones y protocolos genera un paquete o flujo en particular, independientemente del puerto que se esté utilizando. Además de la visibilidad de los flujos, la aplicación basada en la identidad de esta es otro aspecto clave, por permitir o denegar que las aplicaciones se ejecuten en cualquier puerto, o en el estándar. Esto logra reducir aún más la superficie de ataque al garantizar que solo la aplicación prevista pueda comunicarse en un puerto determinado y evita que cualquier otro protocolo haga un túnel a través de un puerto abierto. Las arquitecturas más recientes de los centros de datos también presentan desafíos, ya que las aplicaciones modernas de nueva creación rara vez son monolíticas y no se ejecutan en servidores designados. Los subcomponentes de las aplicaciones abarcan múltiples recursos dinámicos, varias aplicaciones se dividen en niveles, algunas se basan en microservicios y otras aprovechan los servicios en la nube.
Comprender la topología actual de las aplicaciones y los flujos de comunicación entre sus subcomponentes no es fácil y como muchas aplicaciones son de naturaleza dinámica cambian con el tiempo. Los administradores necesitan construir un mapa de aplicaciones y flujos que refleje la topología real de las aplicaciones entre sus subcomponentes para determinar las políticas de microsegmentación correctas, esta construcción implica la recopilación y el análisis de información procedente de múltiples fuentes, como las bases de datos de gestión de la configuración (CMDB), las plataformas de gestión del centro de datos (por ejemplo, VMware vCenter®) y registros de tráfico. La construcción manual de mapas precisos de aplicaciones y flujos requiere mucho tiempo y es propenso a errores. Por lo tanto, los administradores recurren a un enfoque de acierto o error, basando sus políticas de seguridad de microsegmentación en conjeturas e información obsoleta. Este enfoque crea lagunas de seguridad que dejan el centro de datos expuesto a los ataques.
La mayoría de las políticas de seguridad de microsegmentación se basan en parámetros de red L4, es decir, direcciones IP de origen y destino y números de puerto, por ejemplo, para bloquear (o permitir) el tráfico HTTP entre dos nodos, puede ser suficiente con bloquear (o permitir) el tráfico TCP entre ellos en el puerto 80. Pero el reto de reconocer los flujos de tráfico buenos o malos no se limita a los números de puerto, tal como la convención para HTTPS es utilizar el puerto 443. ¿Podemos asumir que cualquier tráfico en el puerto 443 es seguro? No del todo. HTTPS utiliza diferentes versiones del protocolo Transport Layer Security (TLS) (por ejemplo, TLS 1.0, 1.2, 1.3). Supongamos que determinamos que sólo debemos permitir el tráfico HTTPS utilizando TLS 1.2 o superior, ¿cómo lo hacemos cumplir? El uso del puerto 443 como indicador no sería suficiente para distinguir entre el tráfico HTTPS que cumple y el que no lo hace.
Si queremos detectar el tráfico HTTPS, debemos mejorar nuestras capacidades de análisis para mirar más profundamente y así mismo detectarlo, independientemente del puerto que utilice, es decir, el análisis del tráfico debe ser capaz de utilizar las características del nivel de aplicación (L7). VMware reconoció el reto del descubrimiento de políticas y desarrolló VMware NSX® Intelligence™ para abordarlo. NSX Intelligence es un motor de análisis distribuido que automatiza el proceso de descubrimiento de políticas de la siguiente manera:
1.NSX Intelligence, con la ayuda de otras fuentes de información (por ejemplo, VMware vRealize® Network Insight™), recopila información sobre las aplicaciones en ejecución y sus flujos de comunicación. La información recopilada se analiza de forma centralizada.
2. El resultado es un mapa topológico completo de las aplicaciones y los flujos. Los administradores pueden ver fácilmente los componentes reales de la aplicación y los flujos de comunicación entre ellos. El mapa es jerárquico, lo que facilita el recorrido por grandes redes, eliminando las conjeturas que conlleva la comprensión de la topología.
3. NSX Intelligence (VMware vRealize® Network Insight) genera automáticamente recomendaciones para las políticas de seguridad de microsegmentación. Las recomendaciones son basadas en los flujos observados, deduciendo cuáles deben permitirse y bloqueando el resto, siguiendo efectivamente el enfoque de confianza cero.
4. El administrador puede aplicar estas recomendaciones con un simple clic. Las políticas seleccionadas se propagan al cortafuegos distribuido de NSX y se aplican a cada nodo en la red.
5. NSX Intelligence (VMware vRealize® Network Insight) valida la topología frente a las políticas de seguridad y presenta un mapa de cumplimiento codificado por colores. Los administradores pueden detectar inmediatamente qué flujos son conformes y cuáles no.
Después de hacer esta pequeña introducción a la microsegmentación con NSX-T, mostraremos el proceso de creación y los puntos para tener en cuenta. También nos apoyaremos de vRealize Network Insight, la herramienta de VMware que facilita el descubrimiento de todo el tráfico en la red y entregarnos sugerencias de configuración de tráfico.
Para empezar a microsegmentar nuestra red lo primero que se debe hacer es un levantamiento de información con las aplicaciones donde se conozca como mínimo el nombre de la aplicación y los servicios que la componen, estos se discriminaran por grupos. Una aplicación en vRNI, es un contenedor lógico que contiene objetos asociados con la aplicación, permitiendo definir los tipos de tráfico que existen y así mismo categorizarlos por Tier. Es decir, una aplicación es una colección de Tier y cada uno en una aplicación es una colección de VM e IP físicas basadas en los criterios de filtro definidos por el usuario. Las aplicaciones le permiten crear un grupo de Tiers y visualizar el tráfico o los flujos entre los Tiers de la misma aplicación y entre aplicaciones. Por ejemplo, en la siguiente tabla se describe el nombre de la aplicación, el grupo(Tier) y las máquinas virtuales o físicas que conforman ese grupo. Con esta información podemos empezar a crear las aplicaciones de lado de vRNI.
1.Abra un Navegador e ingrese a vRNI por IP o FQDN utilizando la cuenta de admin@localo con un usuario que tenga permisos de administración.
2. Navegue a Plan & Assess y haga clic en Applications
Haga clic en ADD
3. En Application Name Ingrese un nombre. Para este caso Common-Infra-srv teniendo en cuenta nuestro levantamiento de información.
En Tier / Deployment, Name ingrese el nombre para el primer Tier, en nuestro caso AD (Active Directory)
En Member seleccione VMs e ingrese el nombre de las máquinas virtuales
Si se tienen máquinas físicas o que no están haciendo parte de un clúster integrado con NSX-t regístrelas por IP haciendo clic en Add another condition, en Member seleccione IP Address e ingrese las IPs.
Y, por último, haga clic en Save.
4. Para agregar los demás Tier de la aplicación haga clic en Add tier / Deployment y repita el procedimiento que seguimos en el paso 3. Para este ejemplo agregaremos NTP, Antivirus, Deep Security, Syslog, SNMP y SMTP.
5. Repita el paso 3 y 4 para agregar una nueva aplicación. Para el ejemplo agregaremos AP Regional
6. En Application confirme que las aplicaciones creadas están listadas como se muestra en la captura siguiente.
7. Ahora ingresaremos a NSX-T para crear los grupos y tags, ya que esto es un requerimiento para poder microsegmentar cualquier aplicación sobre NSX-T.
Abra un Navegador e ingrese a NSX-T por IP o FQDN utilizando la cuenta admin o con un usuario que tenga permisos de administración.
8. Navegue a Inventory seleccione Group y haga clic en add, en Name ingrese el nombre.
9. Haga clic en Set Members navegue a Members (este caso de uso se utiliza cuando se agregan los miembros por nombre de máquina virtual) en category seleccione Virtual Machine y vaya seleccionando las máquinas virtuales a agregar. Si por el contrario se agregan las maquinas o servidores por IP navegue a IP Addreses e ingrese las IPs que correspondan a cada servidor a agregar. Haga clic en Apply
10. Haga clic en Save para guardar
11. Repita los pasos 8, 9 y 10 para crear los demás grupos que correspondan. Con nuestro ejemplo crearemos los grupos para NTP, Antivirus, Deep Security, Syslog, SNMP y SMTP.
12. Luego creamos un grupo global donde agrupe los security group creados anteriormente
Dar clic en Add Group, en Name ingresar el nombre, hacer clic en Set Members navegue a Members en category seleccione Groups y seleccione los security group creados anteriormente. Haga clic en Apply.
13. Haga clic en Save
Ahora crearemos los grupos y los tags para la aplicación AP Regional siguiendo con nuestro ejemplo.
14. Sobre NSX-T navegue a Inventory seleccione Tags y haga clic en Add Tag. En Tag ingrese el nombre, En Scope Ingrese un nombre que identifique el nombre de la aplicación y agrupe los tags.
En Assigned To haga clic en el 0 para seleccionar las máquinas virtuales, Apply y Save
15. Repita el paso 14 para crear los Tag de los demás Tier.
16. Vamos a crear ahora los grupos. Navegue a Inventory seleccione Group y haga clic en Add Group, en Name ingrese el nombre
Haga clic en Set Members navegue a Membership Criteria haga clic en Add Criteria. En el primer espacio seleccione Virtual Machine, en el Segundo seleccione Tag, en el tercero seleccione Equals, en el cuarto seleccione el nombre del Tag creado anteriormente y en el quinto seleccione el Scope que se definió durante la creación del Tag. Haga clic en Apply.
17. Haga clic en Save
18. Repita los pasos 16 y 17 para crear los demás grupos que hacen parte de la aplicación.
19. Crearemos también un grupo global donde agrupe los security group de la aplicación.
Damos clic en Add Group en Name ingresamos el nombre, hacemos clic en Set Members navegue a Membership Criteria, Add Criteria. En el primer espacio seleccione virtual machine, en el segundo seleccione Tag, en el tercero seleccione Equals, en el cuarto lo dejaremos vació y en el quinto seleccione el scope al que corresponde el Tag. Haga clic en Apply.
20. Y, haga clic en Save
Después de tener creados los grupos y las etiquetas avanzaremos ahora sí con la creación de las reglas en NSX-T. En este punto nos apoyaremos de VRNI para la filtración del tráfico que debe ser permitido.
21. Sobre VRNI seleccionamos Plan &Assess y Security Planning, en Duration filtramos la información dependiendo el rango de tiempo que consideremos o queremos revisar y en Group by seleccionamos Tier por último damos clic en Analyze.
Esperamos un par de minutos a que VRNI haga la recolección del tráfico.
22. En Flow type seleccionamos All unprotected flows, esto nos filtrara el tráfico que aún no está protegido.
23.Hacemos clic sobre el nombre del tier, por ejemplo, elegiremos AD y luego hacemos clic en Recommended Firewall Rules, nos entrega los flujos recomendados a configurar de lado de NSX-T. Es importante confirmar que realmente todo el flujo arrojado debe ser configurado.
NOTA: VRNI, nos entrega sugerencias, pero no quiere decir que debamos de configurar todos los flujos listados, existirán algunos que no deben ser permitidos.
La captura anterior de VRNI nos muestra el origen, destino, servicios (son los puertos que deben ser habilitados), protocolos y acción (en la cual se declara si la regla debe de ser permitida o no) de la regla, que se debe crear para la aplicación.
Debemos de ir revisando los flujos uno a uno y configurar las reglas de lado de NSX-T.
24. Vamos a NSX-T navegamos a Security, Distributed Firewall, nos ubicamos en Category Specific Rules y seleccionamos Infraestructure para crear las reglas de Common Infra que corresponde a todos los servicios de infraestructura.
25. Crearemos una sección que se llame Common Infra to Apps y otra como Apps to Common Infra, esto con el fin de configurar el tráfico según corresponda. Es decir, si va de infraestructura a aplicación o por el contrario de aplicación a infraestructura.
Para agregarla o crearla daremos clic en Add Policy e ingresamos el nombre para nuestro caso Common Infra to Apps.
26.Ahora daremos clic sobre los 3 puntos que aparecen de lado izquierdo del nombre de la sección, seleccionamos Add Rule para agregar una nueva regla.
27. En Name ingresamos el nombre, luego en Sources seleccionamos el grupo de la aplicación que pertenece a infraestructura y en Destinations seleccionamos o incluimos las aplicaciones que deben de ser permitidas, en Services agregamos los puertos y protocolos que se requieran y en Applied To seleccionamos el grupo global de las aplicaciones junto con el de infraestructura. Finalmente, en Action elegiremos Allow.
Para agregar un nuevo servicio que no aparezca en el listado. Damos clic en Add Services, en Name ingresamos el nombre, hacemos clic en Set Service Entries, Add Service Entry, en Name damos un nombre, en Service Type seleccionamos el tipo de protocolo y en Additional Properties / Destination Ports ingresamos el número de los puertos necesarios, Apply, Save y Apply.
28. Debemos repetir los pasos 26 y 27 para cada nueva regla que se vaya a agregar y configurar; teniendo en cuenta los flujos recomendados por VRNI sobre la aplicación.
29. Repetimos los pasos 25, 26 y 27 para crear la sección Apps to Common Infra acá en Sources seleccionamos o incluimos las aplicaciones que deben de ser permitidas y en Destinations seleccionamos el grupo de la aplicación que pertenece a infraestructura.
Después de haber agregado todas las reglas recomendado desde infraestructura a aplicaciones y viceversa de aplicaciones a infraestructura pasaremos a microsegmentar nuestra aplicación AP Regional.
30. Regresamos a VRNI y repetimos los pasos 21 y 22 para hacer el descubrimiento del tráfico de nuestra aplicación AP Regional.
31. Damos clic sobre uno de los Tier de nuestra aplicación. Recuerden que debemos pasar por todos los tier para microsegmentar completamente la aplicación.
32. Sobre NSX-T en Distributed Firewall nos ubicamos ahora en Application, damos clic en Add Policy para agregar una nueva política. En Name damos el nombre y enter.
33. Daremos clic sobre los 3 puntos que aparecen de lado izquierdo del nombre de la política, seleccionamos Add Rule para agregar una nueva regla.
34. En Name ingresamos el nombre, preferiblemente que sea un nombre donde se pueda identificar de que Tier a que Tier va la regla o si va de un Tier de la aplicación a otro Tier de otra aplicación. Luego en Sources seleccionamos el grupo de origen y en Destinations seleccionamos el grupo de destino, en Services agregamos los puertos y protocolos que se requieran y en Applied To seleccionamos el grupo global de las aplicaciones. Finalmente, en Action elegiremos Allow.
35. Es importante tener en cuenta que debemos de crear dos reglas adicionales en por cada aplicación una de entrada de tráfico y otra de salida de tráfico que finalmente deberán ser configuradas en Action como Reject para asegurar totalmente la aplicación y así mismo no permitir ningún otro tipo de tráfico.
Inicialmente las creamos y las mantenemos su Action como Allow para no bloquear todo el tráfico que debe ingresar o salir de la aplicación. Lo que demos hacer es revisar desde el lado de VRNI que tráfico está cayendo sobre estas 2 reglas y configurarlo. Cuando ya estemos completamente seguros de que ya tenemos todo el tráfico cubierto. Ahora sí, pasaremos la Action a Reject para bloquear el tráfico no permitido.
36. Para revisar las dos últimas reglas que deben de ser bloqueadas.
Vamos a VRNI seleccionamos Saved Searches e ingresamos el filtro “Flow where firewall rule = Block the rest Ap” y seleccionamos la de entrada o salida.
37. Nos entregara el tráfico que aún no está asegurado. Debemos revisar uno a uno y verificar si ya existe de lado de NSX-T o de lo contrario agregarlo, lo mismo que descartar tráfico que no debe ser permitido.
38. Después de revisar completamente todo el flujo de estas 2 reglas, repito si podremos cambiar la acción a Reject de la aplicación o aplicaciones.
Autor: Ingeniera Blanca Ramirez
Espero haya sido de su ayuda este texto.
BIBLIOGRAFIA
Para iniciar a realizar la migración de tecnología de NSX-V a NSX-A se deben tener en cuenta varias cosas:
Descarga de la OVA
Cuando se adquiere o implementa VMware para solución de virtualización en el centro de datos, se requiere migrar estos servicios, bien sea por homologar la infraestructura, aprovechar al máximo nuevas funcionalidad o simplemente por temas de licenciamiento.
A continuación, se detalla cómo podemos migrar exitosamente una máquina virtual que vive en una infraestructura de Citrix Xenserver a una infraestructura VMware vSphere.
NSX intelligence es un componente adicional dentro del entorno de NSX Data Center y la virtualización de redes. Este gestiona, permite realizar un análisis a la red y administra de manera más optima todo el flujo de tráfico que se presenta dentro de la infraestructura, para que el administrador tenga la capacidad de acceder a recomendaciones que NSX intelligence ofrece, con el fin de mejorar la seguridad y denegar comunicaciones que no deberían presentarse entre las maquinas.
Actualización de vSphere de 6.7 a 7u3: todo lo que necesita saber en un solo lugar Las actualizaciones de los productos VMware aseguran un apropiado
https://blog.v2s.us/wp-content/uploads/2022/05/La-regla-de-backup-3-2-1-de-Veeam.mp4 La regla 3-2-1 es muy general y funciona para todo tipo de datos (individuales y corporativos) en entornos físicos y virtuales. Al realizar la
COMPARTE ESTE POST Share on facebook Share on twitter Share on linkedin Share on whatsapp Share on print Share on email Fundada en 2006, V2S
Fundada en 2006, V2S Corporation es una multinacional de Servicios de Infraestructura y Aplicaciones para todos los sectores e industrias.
Somos expertos en soluciones innovadoras de Virtualización como respuesta a los retos actuales de Transformación Digital.
Nuestras soluciones personalizadas y el conocimiento de los distintos sectores son nuestros principales diferenciadores. Llevamos años auditando, diseñando, implementando y gestionando las soluciones de virtualización más avanzadas. Nuestros servicios se enmarcan dentro del profesionalismo, la precisión, la innovación y la calidad.
V2S Corporation opera globalmente desarrollando proyectos en distintos países. Tenemos oficinas y personal en Europa, África y América Latina. Aunque nuestras operaciones están muy extendidas, nuestro enfoque es operar como una empresa multinacional global centrada en la calidad del servicio. La misma metodología y enfoque están presentes allí donde ofrecemos nuestros servicios adaptándonos al mismo tiempo, a los retos locales.
V2S Headquarters
Wilmington, DE, USA