Segmentación de la red: planifique las zonas y verifique el acceso.

La segmentación de la red limita qué dispositivos y servicios pueden comunicarse. Una estación de trabajo comprometida no debería obtener automáticamente acceso a servidores, copias de seguridad o gestión de equipos. Dibujar zonas separadas no es suficiente. Los controles técnicos deben hacer cumplir los límites y las conexiones permitidas deben servir a las tareas comerciales.

El resultado práctico es un mapa de zonas, una tabla de flujos permitidos, propietarios de reglas y resultados de pruebas. El plan debe garantizar que las aplicaciones sigan funcionando mientras se bloquean las rutas innecesarias. Este artículo cubre ese plan para una red empresarial. Configure los dispositivos individuales por separado después de acordar la arquitectura.

Defina qué separar y proteger

Comience con los procesos y recursos críticos. Identifique dónde se encuentra los datos importantes, quién los utiliza y qué configuraciones permiten los cambios. Verifique el registro de activos y los diagramas de conexión. Incluya conexiones físicas, redes inalámbricas, empleados remotos, contratistas, telefonía, recursos en la nube y equipos que son difíciles de actualizar. Los propietarios de estos sistemas deben comprender el alcance del proyecto.

Para cada dispositivo o grupo, registre su propósito, propietario, método de conexión y dependencias requeridas. Investigue el papel de un dispositivo desconocido y acuerde una solución temporal segura. No lo coloque automáticamente en una zona de trabajo de confianza. Recopile información de la configuración, observaciones del flujo y discusiones con los propietarios de las aplicaciones. Un breve período de observación sin conexión no prueba que nunca se necesita. Las operaciones, actualizaciones y recuperación poco frecuentes también son importantes.

Resumen de la infraestructura de red y de telecomunicaciones describe su papel en las operaciones empresariales. Un proyecto de segmentación requiere más detalles: zonas específicas, conexiones permitidas y pruebas de sus restricciones.

Mapee las zonas por propósito y riesgo

No es necesario una zona separada para cada departamento o dispositivo. Agrupe los sistemas por función, sensibilidad de los datos, privilegios y protección requerida. Comience con un número manejable de límites que el equipo pueda mantener. Si un grupo necesita controles más estrictos, considere separar las cargas de trabajo individuales. Más detalle ayuda cuando tiene un propósito claro y el equipo puede verificar las reglas.

Este es un ejemplo para la discusión, y no un diseño obligatorio para todas las empresas. La telefonía puede estar gestionada por un proveedor, y puede que no haya servidores internos. El mapa variará, pero aún debe mostrar las dependencias en la nube y el acceso de gestión. Considere una barrera de protección separada para las copias de seguridad y los datos importantes, para que el acceso normal del usuario no pueda modificar ni eliminar las copias de seguridad.

Verifique cómo se aplica la barrera.

La separación física utiliza recursos y enlaces separados. La separación lógica utiliza una infraestructura compartida. Una VLAN define un dominio de difusión separado, mientras que una subred organiza la dirección. Un nombre de VLAN o un rango de direcciones diferente por sí solo no determinan quién puede conectarse. Las zonas necesitan reglas verificables en firewalls, routers u otros puntos de control adecuados. En la nube, las reglas de acceso a la red y a las cargas de trabajo pueden servir para este propósito.

La segmentación de las cargas de trabajo individuales controla conexiones más granulares, incluida la comunicación dentro de una zona compartida. Esto requiere información precisa sobre las dependencias y el mantenimiento de las políticas. El acceso a través de ZTNA no elimina la necesidad de restringir las conexiones locales después de la entrada. Elija una combinación de herramientas para la tarea, en lugar de depender de una promesa de que un producto reemplaza a todos los demás controles.

Describa los flujos permitidos antes de cambiar las reglas.

Cada conexión necesita una fuente, un destino, un servicio requerido, una razón de negocio y un propietario. El administrador especifica los protocolos y los objetos técnicos en la configuración de trabajo. El propietario de la aplicación confirma la necesidad. Una regla amplia de «todos a todo» no está justificada simplemente porque se ha utilizado antes. Una conexión observada no siempre es necesaria. Puede reflejar una configuración antigua.

El objetivo es permitir las conexiones necesarias y bloquear el resto. Proceda de esta manera después de verificar las dependencias y acordar los cambios. Si es necesario un acceso más amplio de forma temporal, registre la razón, el propietario, las restricciones, la fecha de caducidad y el método para reducirlo. Una regla temporal sin fecha de revisión puede convertirse rápidamente en una forma permanente de eludir las restricciones.

Verifique las rutas alternativas

Confirme que el tráfico relevante realmente pasa por el punto de control. Verifique las rutas alternativas, las interfaces de red secundarias, los puentes entre redes, el acceso remoto y las conexiones en la nube. Una regla de IPv4 no necesariamente restringe la ruta equivalente de IPv6. Verifique el acceso por cable y por inalámbrico por separado, alternando entre ellos, y el aislamiento de clientes en el entorno de invitados si el plan lo incluye.

La segmentación no reemplaza la autenticación de usuarios, los permisos de aplicaciones o la protección del extremo. Un atacante con acceso adecuado puede utilizar un flujo de red permitido. Es más preciso describir los límites en las rutas y el posible impacto que garantizar que cada ataque permanezca en una zona. La segmentación tampoco garantiza una red más rápida. Evalúe el ancho de banda y la calidad de la conexión por separado.

Implemente de forma gradual con condiciones de reversión

• Guarde la configuración, el mapa de conexiones original y el método de emergencia para gestionar el equipo.
• Acuerde el grupo piloto, el período de mantenimiento, los propietarios de las pruebas y las señales que requieren detener el trabajo.
• Pruebe las reglas propuestas en un modo de observación o entorno de prueba disponible. La observación por sí sola no bloquea el tráfico.
• Habilite las restricciones para el grupo acordado, pruebe las operaciones requeridas y bloqueadas, e investigue los bloqueos inesperados.
• Amplíe el alcance después de verificar el resultado. Si se produce un fallo, restaure el estado aprobado, registre la causa y revise la regla antes de volver a implementarla.

No modifique de forma remota la red de administración sin una ruta de recuperación separada probada. Acuerde de antemano las pruebas aceptables para equipos y servicios de proveedores sensibles. Realice pruebas activas únicamente dentro del alcance autorizado. No deben interrumpir los servicios de otras partes ni interferir con un incidente en curso.

Verifique los permisos y bloqueos mediante pruebas reales

Para cada regla importante, realice dos tipos de pruebas: que la operación requerida funcione y que un intento innecesario se bloquee. Realice las pruebas desde las zonas de origen utilizando los roles correspondientes. Un ping fallido no prueba que una conexión de aplicación esté bloqueada. Un servicio que no responde simplemente puede estar desactivado. Compare el resultado con el registro en el punto de control relevante y el estado del destino.

• Realice pruebas diarias de las operaciones de la aplicación, la autenticación, la impresión y las comunicaciones requeridas.
• Realice pruebas de actualizaciones, supervisión, copias de seguridad y recuperación bajo las condiciones acordadas.
• Realice pruebas de los bloqueos en el acceso de invitados a los recursos empresariales, el acceso estándar del cliente a la administración y las conexiones innecesarias entre servidores.
• Realice pruebas para verificar si las reglas persisten después de un reinicio o cambio de conexión si el escenario acordado incluye esto.
• Registre la fecha, la fuente, el destino, el resultado esperado y real, la referencia del registro y el propietario. No marque una regla como completa simplemente porque la configuración existe.

Mantenga la representación gráfica y las reglas después de la implementación

Asigne un propietario para la representación gráfica de la zona y revisiones periódicas de las reglas basadas en la criticidad. Reevalúe las conexiones después de agregar una aplicación, cambiar un proveedor, migrar un servicio, cambiar el acceso remoto o experimentar un incidente. Asigne nuevos sistemas a las zonas y otorgue los permisos requeridos a través de un proceso acordado. Enseñe a los participantes dónde reportar el acceso bloqueado y quién puede aprobar un cambio.

Recopile eventos y supervise los flujos inesperados, los cambios de ruta y los permisos amplios. La automatización puede detectar desviaciones y aplicar las políticas aprobadas. No debe permitir automáticamente cada nueva conexión. Verifique las excepciones temporales, las reglas no utilizadas y las diferencias entre la representación gráfica y la red operativa. Elija pruebas técnicas adicionales basadas en el riesgo y realícelas dentro del alcance acordado.

Si necesita un plan técnico y cambios seguros en una red existente, consulte con los expertos de DK en la página Servicios de Red y Telecomunicaciones. Prepare la lista de solicitudes, el diagrama actual y los límites en las interrupciones del servicio.

Fuentes

• MITRE sobre los controles de segmentación
• NCSC sobre la limitación del impacto de la vulneración mediante ZTNA
• Guía de ASD sobre la planificación de la segmentación