VPN de oficina Zero Trust: reemplace redes planas por acceso basado en roles

Qué está reemplazando: la VPN de oficina plana

Un modelo típico de “VPN de oficina” funciona así:

• El usuario se autentica en un concentrador VPN (a menudo con MFA, a veces no).
• El cliente recibe una IP interna (o rutas a subredes internas).
• Las reglas del firewall permiten un amplio acceso este-oeste porque “están en la VPN”.
• El control de acceso es mayormente implícito: si puedes enrutar hacia ello, puedes intentar iniciar sesión.

Esto no es “Zero Trust con VPN”. Esto es “castillo y foso con teletransportador”. Falla de formas predecibles:

• El movimiento lateral se vuelve barato. A los atacantes les encanta la adyacencia porque convierte “una credencial” en “muchos sistemas”.
• La autorización está fragmentada. Los equipos de aplicaciones implementan autenticación de manera distinta; los equipos de red lo parchean con accesibilidad.
• La segmentación de red se pudre. La gente crea excepciones, luego las clonan, y entonces básicamente vuelve a plano.
• La complejidad operativa se oculta en el enrutamiento. Los debates sobre túnel dividido vs túnel completo se vuelven guerras religiosas, no decisiones de ingeniería.

Zero Trust no es polvo mágico. Es un contrato distinto: ningún usuario ni dispositivo obtiene “acceso a la red interna” por defecto. Obtienen acceso a aplicaciones específicas, por puertos específicos, bajo condiciones específicas, con auditoría que resista un mal día.

Una regla práctica: si su política es expresable como “los usuarios VPN pueden acceder a 10.0.0.0/8”, no tiene política. Tiene un encogimiento de hombros.

Hechos y contexto histórico que realmente importan

Zero Trust a menudo se comercializa como si se hubiese inventado el último trimestre. No fue así. Aquí hay puntos concretos que le ayudan a razonar sobre ello:

1. Las VPN se volvieron comunes a fines de los 1990 con la estandarización de IPsec (IKE, ESP). El objetivo era confidencialidad a través de redes hostiles, no autorización de grano fino.
2. Las SSL VPN (principios de los 2000) popularizaron el acceso web “sin cliente” y más tarde clientes de túnel completo. Mejoraron el despliegue, no la resistencia al movimiento lateral.
3. Las suposiciones del perímetro de red se debilitaron a medida que SaaS y la nube movieron aplicaciones “internas” a Internet público detrás de inicios de sesión en lugar de detrás de subredes.
4. La microsegmentación se puso de moda cuando la virtualización y SDN hicieron posible el filtrado este-oeste sin rehacer cableado. La mayoría de las organizaciones aprendió que escribir las reglas es la parte difícil.
5. El modelo BeyondCorp de Google (mediados de 2010) promovió la idea de que la red corporativa no es un límite de seguridad; lo son la identidad y el estado del dispositivo.
6. El robo de credenciales superó al malware en muchos incidentes porque resulta más barato pescar a un usuario que explotar diez hosts distintos.
7. “Red plana” suele ser un accidente, no un diseño: fusiones, VLANs temporales y “lo limpiaremos luego” se vuelven permanentes.
8. MFA es necesario pero no suficiente: detiene algunos ataques, pero una vez dentro de una VPN plana, el radio de impacto sigue siendo enorme.
9. Los productos Zero Trust tienden a converger en unos pocos primitivos: un proveedor de identidad, un motor de políticas, un conector/proxy y telemetría sólida.

Lección histórica terminada. Conclusión: las VPN resolvieron confidencialidad y conectividad. Zero Trust resuelve autorización y contención, asumiendo que la red ya es hostil.

Resultado objetivo: acceso basado en roles, no esperanza basada en roles

“Acceso basado en roles” en un contexto Zero Trust de oficina significa:

• Los usuarios se autentican con un proveedor de identidad (IdP).
• Se les mapea a roles/grupos (Ingeniería, Finanzas, TI, Proveedor-ACME).
• Las políticas conceden acceso a aplicaciones/servicios específicos según rol + postura del dispositivo + contexto.
• La conectividad está acotada por aplicación (o por servicio), no por subred.
• Cada evento de acceso se registra con identidad, dispositivo y motivo de la decisión.

El error es pensar que “RBAC” significa “añadir grupos y listo”. El RBAC real necesita:

• Higiene de roles: roles estables, mínima proliferación, propiedad clara.
• Inventario de recursos: no puede proteger lo que no puede nombrar.
• Límites de autorización: las aplicaciones deben seguir autenticándose; la política de red es una segunda línea, no la única cerradura.
• Tiempo de revocación: si la baja tarda horas en eliminar acceso, ocurrirá durante las horas que no quería.

Idea parafraseada de una voz SRE notable (atribución): Werner Vogels ha enfatizado que todo falla eventualmente, por lo que los sistemas deben diseñarse para tolerar fallos. Aplique eso aquí: asuma que las credenciales se filtran, que los portátiles son comprometidos y que las redes se enrutan mal. Diseñe para que el radio de impacto sea pequeño y la traza de auditoría usable.

Segunda regla práctica: su política debe ser legible por humanos a las 2 a.m. durante una interrupción. Si la única persona que la entiende está de permiso parental, tiene un riesgo—no un sistema.

Broma #1: Una VPN plana es como dar a todos una llave maestra porque confía en que no toquen el armario de suministros. El armario de suministros no está de acuerdo.

Opciones de arquitectura: elija su batalla

Hay tres patrones amplios que verá. Todos pueden funcionar; cada uno falla de forma diferente.

1) ZTNA mediante proxy consciente de identidad (mejor para HTTP/S y apps modernas)

Los usuarios acceden a aplicaciones web internas a través de un proxy que aplica identidad, postura del dispositivo y políticas. El proxy se conecta a servicios internos mediante conectores (agentes) o enrutamiento privado. Esto brilla para:

• Aplicaciones web (paneles internos, Git, UIs de CI/CD)
• APIs
• Portales administrativos que ya soportan SSO

Puede resultar incómodo para:

• Servicios TCP puros (bases de datos, SSH) a menos que el producto lo soporte bien
• Clientes legacy pesados que asumen adyacencia de LAN

2) Túneles por aplicación (mejor para acceso TCP/SSH/BD con direccionamiento explícito)

En lugar de “conéctate a la VPN”, el usuario se conecta a “prod-db-readonly” o “k8s-admin” a través de un broker. La conectividad se establece solo hacia el destino(s) específico(s) permitido(s) por la política. Aquí es donde empuja a desarrolladores y admins cuando insisten en que “necesitan SSH”. Bien. Obtienen SSH a hosts específicos, con credenciales de corta duración y registro.

3) VPN microsegmentada (un patrón de transición, no el estado final)

Mantiene una VPN, pero deja de enrutar a los usuarios a una subred interna compartida. Emite pools IP por rol y aplica ACL estrictas. Esto sigue siendo confianza basada en red, pero al menos no es un solo radio de impacto. Úselo como paso intermedio si su paisaje de aplicaciones es muy legacy.

Guía con opinión: predetermine proxy consciente de identidad para web, túneles por aplicación para protocolos administrativos y mantenga una VPN general solo para casos raros con fecha de jubilación.

Modelo de políticas: identidades, roles y “quién puede alcanzar qué”

Comience con un grafo de acceso, no con un mapa de subredes

A los ingenieros de red les encantan los rangos IP porque son concretos. Zero Trust le obliga a modelar algo más cercano a un grafo de acceso:

• Sujetos: usuarios, cuentas de servicio, dispositivos
• Atributos: rol, departamento, puntuación de riesgo, gestionado/no gestionado, versión de SO, nivel de parches
• Objetos: apps, APIs, bases de datos, endpoints administrativos, bastiones SSH
• Acciones: HTTP GET/POST, SSH, RDP, conexión a base de datos, kubectl
• Condiciones: MFA, postura del dispositivo, geolocalización, horario, red, referencia de ticket

Una buena política se lee como una oración:

• “Ingenieros en dispositivos gestionados con cifrado de disco y nivel de parches reciente pueden acceder a Git y CI vía HTTPS.”
• “SREs de guardia pueden hacer SSH al bastión de producción con MFA y aprobación just-in-time, sesiones grabadas.”
• “Finanzas puede acceder a la app de nómina solo desde dispositivos gestionados; bloquear no gestionados y BYOD.”

Defina roles de la forma aburrida

Los roles deben ser estables y de grano grueso. Siempre puede añadir permisos más finos después. No puede eliminar fácilmente 400 micro-roles cuando cada equipo tiene uno. Comience con:

• Empleado vs contratista vs proveedor
• Roles a nivel de departamento (Eng, Ventas, Finanzas, RRHH)
• Roles privilegiados (Admin TI, SRE de guardia, Seguridad)
• Roles por entorno (Acceso Prod, Acceso Staging)

Luego imponga restricciones:

• Propiedad del rol: cada rol tiene un propietario humano que aprueba la membresía.
• Fuente de la verdad de membresía: idealmente HRIS → IdP → sistema de acceso, con excepciones rastreadas.
• Elevación acotada en el tiempo: roles de “break-glass” que expiran.

No confunda autenticación con autorización

La identidad fuerte es necesaria. Pero aún necesita decisiones de autorización cerca del recurso. En la práctica:

• Para apps web: use SSO y haga cumplir roles a nivel de app; el proxy es una puerta, no su única cerradura.
• Para SSH: use certificados de corta duración y comandos forzados cuando sea posible.
• Para bases de datos: evite contraseñas compartidas; use autenticación IAM o credenciales por usuario; restrinja la ruta de red como segunda capa.

Broma #2: “Solo ponlo detrás de la VPN” es el equivalente de seguridad de “simplemente reinícielo”. A veces funciona; nunca es una estrategia.

Listas de verificación / plan paso a paso: migre sin prenderse fuego

Paso 0: inventarie para qué se usa realmente la VPN

• Liste destinos: subredes, nombres de host, servicios, puertos.
• Liste grupos de usuarios: quién se conecta, cuándo y para qué.
• Clasifique el tráfico: apps web, SSH/RDP, bases de datos, compartición de archivos, DNS interno, servicios AD.

Resultado de decisión: descubrirá que el 80% del uso es predecible y puede moverse a acceso por aplicación. El 20% restante es donde vive lo raro.

Paso 1: elija su punto de aplicación

• Proxy consciente de identidad para HTTP/S y apps compatibles con SSO.
• Túneles por aplicación para SSH/BD/Kubernetes y otros protocolos TCP.
• Mantenga la VPN legacy solo para “no se puede migrar aún”, pero reduzca las rutas.

Paso 2: defina “dispositivo gestionado” y haga cumplir la postura

• Elija señales MDM/EDR en las que confíe: cifrado, nivel de parches del SO, bloqueo de pantalla, agente EDR conocido.
• Decida cómo manejar BYOD: rol separado con acceso limitado, o sin acceso a apps sensibles.

Resultado de decisión: el acceso no es solo “quién eres” sino “qué estás usando”. A los atacantes les disgusta esto.

Paso 3: migre las apps de baja fricción primero

• Wiki interna, paneles, ticketing, portales de documentación.
• Apps ya detrás de SSO.
• Apps con nombres de host claros y TLS.

Paso 4: aborde los protocolos administrativos con flujos explícitos

• Introduzca un bastión o broker de acceso para SSH/RDP.
• Implemente elevación just-in-time para producción.
• Active grabación de sesiones donde sea factible.

Paso 5: encoja la VPN hasta que dé vergüenza

• Reemplace rutas 10.0.0.0/8 por solo las subredes legacy específicas.
• Segmente usuarios por rol en pools IP separados y aplíqueles firewall agresivamente.
• Ponga una fecha: “Esta ruta VPN muere.” Luego realmente elimínela.

Paso 6: mida e itere

• Monitoree: solicitudes denegadas, tiempo de incorporación de nuevas apps, tickets de soporte, latencia mediana.
• Revise políticas trimestralmente como revisa la guardia: podar, simplificar, reasignar propiedad.

Tareas prácticas (con comandos): verificar, diagnosticar, decidir

Estas son las tareas que ejecuta durante la migración y durante tickets de “por qué no puedo alcanzar X”. Cada una incluye qué significa la salida y qué decisión tomar.

Task 1: Identify what routes the VPN client is actually installing

cr0x@server:~$ ip route show
default via 192.168.1.1 dev wlp2s0 proto dhcp metric 600
10.0.0.0/8 via 10.8.0.1 dev tun0 proto static metric 50
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.23 metric 50

Qué significa: La VPN está enrutando una superred RFC1918 completa (10/8) a través de tun0. Eso es la clásica adyacencia de red plana.

Decisión: Reemplace la ruta amplia por acceso por aplicación o, como mínimo, estreche las rutas a los destinos legacy que realmente lo necesiten.

Task 2: Confirm split tunnel vs full tunnel behavior

cr0x@server:~$ curl -s https://ifconfig.me
203.0.113.47

Qué significa: Su IP de salida es la del ISP público (túnel dividido) en lugar de la salida corporativa (túnel completo). Si esperaba salida corporativa por cumplimiento, esto es un fallo.

Decisión: Para Zero Trust, prefiera acceso acotado por aplicación y evite forzar túnel completo a menos que tenga un requisito específico (y capacidad) para ello.

Task 3: Check DNS resolution path (a common migration footgun)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1
DNS Domain: corp.example

Qué significa: Está usando un servidor DNS interno más una alternativa pública. Esto puede filtrar consultas o causar resolución inconsistente si las zonas corporativas no se manejan correctamente.

Decisión: En un modelo Zero Trust, decida qué nombres deben resolverse internamente y asegure que su camino de acceso proporcione DNS apropiadamente (horizonte dividido, DoH policy o enrutado por proxy).

Task 4: Verify that a specific internal service is reachable by policy (TCP)

cr0x@server:~$ nc -vz git.corp.example 443
Connection to git.corp.example 443 port [tcp/https] succeeded!

Qué significa: Existe ruta de red a 443. Si la app sigue fallando, el problema probablemente sea TLS/SSO/autenticación de la app en lugar de enrutamiento.

Decisión: Cambie la depuración a capas HTTP/TLS/identidad, no a reglas de firewall.

Task 5: Diagnose whether the problem is DNS vs connectivity

cr0x@server:~$ dig +short git.corp.example
10.20.30.40

Qué significa: El nombre resuelve a una IP privada. Si usa un proxy consciente de identidad, quizás no quiera que los usuarios resuelvan direcciones privadas en absoluto.

Decisión: O (a) publique la app vía proxy con un nombre público que no filtre IPs internas, o (b) asegure que el túnel por aplicación cubre esa IP/puerto y que el DNS es consistente.

Task 6: Confirm TLS and SNI behavior to an app endpoint

cr0x@server:~$ openssl s_client -connect git.corp.example:443 -servername git.corp.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=git.corp.example
Verification: OK

Qué significa: TLS está sano, el certificado coincide, SNI funciona. Si los usuarios ven advertencias en el navegador, probablemente sean problemas de interceptación/proxy o del almacén de confianza del dispositivo.

Decisión: Si su solución ZTNA realiza terminación TLS, asegúrese de que presente una cadena de certificados confiable y que no rompa las expectativas de la app.

Task 7: Inspect firewall rules that accidentally kept the network flat

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "tun0" ip daddr 10.0.0.0/8 accept
    ct state established,related accept
  }
}

Qué significa: Existe un allow explícito desde la interfaz VPN hacia 10/8. Esa es su autopista de movimiento lateral.

Decisión: Reemplace el allow global por reglas específicas por aplicación o elimine el reenvío por completo a favor de acceso por proxy/túnel.

Task 8: Confirm identity group membership used for RBAC (IdP via SSO token introspection)

cr0x@server:~$ jq -r '.email, .groups[]' /tmp/id_token_claims.json
alex@example.com
role:engineering
env:staging
priv:none

Qué significa: Las claims del usuario muestran engineering + staging, sin elevación privilegiada.

Decisión: Si necesita acceso a prod, no “simplemente lo añada”. Implemente un grupo privilegiado con tiempo limitado, aprobaciones y auditoría.

Task 9: Check device posture signal (managed vs unmanaged) from the endpoint

cr0x@server:~$ sudo osqueryi "select * from disk_encryption;"
device_name = /dev/nvme0n1p3
encrypted = 1
type = luks

Qué significa: El cifrado de disco está activado (bien). Esta es una de las pocas comprobaciones de postura que correlaciona con el riesgo de “portátil perdido”.

Decisión: Si el cifrado está desactivado, bloquee acceso a apps sensibles y dirija al usuario al enrolamiento. No negocie con la física.

Task 10: Validate that a per-app tunnel is only exposing intended destinations

cr0x@server:~$ ss -tnlp | grep 127.0.0.1:15432
LISTEN 0 4096 127.0.0.1:15432 0.0.0.0:* users:(("ztna-client",pid=2214,fd=9))

Qué significa: El cliente local está escuchando solo en localhost. Bien: no está abriendo un puerto a su LAN ni al mundo entero.

Decisión: Mantenga el bind local en 127.0.0.1 para túneles de BD; haga cumplir ese patrón en su procedimiento operativo estándar.

Task 11: Confirm audit trail exists for an access attempt

cr0x@server:~$ sudo journalctl -u ztna-connector --since "10 min ago" | tail -n 8
Dec 28 12:11:02 connector-01 ztna-connector[1189]: allow user=alex@example.com app=git-web device=managed policy=eng-web-mfa
Dec 28 12:11:04 connector-01 ztna-connector[1189]: deny user=alex@example.com app=prod-bastion reason=missing_jit_approval

Qué significa: Tiene eventos explícitos de allow/deny con motivos. Eso es oro durante incidentes y revisiones de acceso.

Decisión: Si su sistema no puede explicar un deny, terminará evadiéndolo. Arregle la observabilidad antes de ampliar el despliegue.

Task 12: Identify latency sources (DNS, connect time, TLS, TTFB)

cr0x@server:~$ curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://git.corp.example/
dns=0.012 connect=0.031 tls=0.112 ttfb=0.487 total=0.512

Qué significa: DNS/conexión/TLS están bien; la respuesta del servidor (TTFB) domina. Eso probablemente sea carga del backend o buffering del proxy, no “la VPN está lenta”.

Decisión: Escale al rendimiento de la app o capacidad del proxy; no pierda días ajustando MTU si el backend es el cuello de botella.

Task 13: Check MTU and path MTU issues (classic VPN pain, still shows up in tunnels)

cr0x@server:~$ ip link show dev tun0
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Qué significa: El MTU es 1280 (común en entornos con túnel). Algunos servicios legacy fallan si asume 1500 y se bloquea ICMP.

Decisión: Si ve bloqueos en transferencias grandes, valide PMTUD y permita los tipos ICMP necesarios, o limite MSS en el borde del túnel.

Task 14: Confirm whether a “blocked” app is actually being accessed directly instead of via proxy

cr0x@server:~$ traceroute -n git.corp.example | head -n 6
traceroute to git.corp.example (10.20.30.40), 30 hops max, 60 byte packets
 1  192.168.1.1  1.103 ms  0.921 ms  0.877 ms
 2  203.0.113.1  9.902 ms  10.004 ms  9.811 ms
 3  * * *

Qué significa: Está intentando enrutar a una IP privada por Internet público (fallará). Esto ocurre cuando el DNS apunta a IPs internas pero los usuarios ya no están en la VPN.

Decisión: Arregle DNS y publicación: las IPs privadas no deberían filtrarse a clientes que no deben tener acceso a nivel de red.

Task 15: Verify segmentation boundaries inside the office network (east-west reality check)

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp port 445' -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:20:11.102938 IP 10.50.12.34.51322 > 10.50.0.10.445: Flags [S], seq 122233, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0

Qué significa: Está viendo intentos SMB dentro de un entorno que supuestamente está segmentado. Esa es superficie de movimiento lateral con disfraz.

Decisión: Asegure que las VLANs de estaciones de trabajo no puedan alcanzar VLANs de servidores salvo mediante allow explícito; elimine exposición legacy de compartición de archivos cuando sea posible.

Task 16: Validate who is still using the legacy VPN and for what

cr0x@server:~$ sudo awk '{print $1,$2,$3,$9}' /var/log/openvpn/status.log | tail -n 5
CLIENT_LIST alex@example.com 10.8.0.23 192.0.2.44
CLIENT_LIST sam@example.com 10.8.0.24 198.51.100.19
ROUTING_TABLE 10.30.0.0/16 10.8.0.23
ROUTING_TABLE 10.40.0.0/16 10.8.0.24
GLOBAL_STATS Max_bcast_mcast_queue_length 0

Qué significa: Usuarios siguen obteniendo rutas a grandes redes internas. Las entradas de la tabla de enrutamiento muestran qué pueden alcanzar.

Decisión: Use estos datos para priorizar objetivos de migración y justificar la eliminación de rutas con evidencia en lugar de sensaciones.

Guion de diagnóstico rápido: encuentre el cuello de botella con rapidez

Cuando alguien dice “Zero Trust rompió mi acceso”, no empiece cambiando políticas. Empiece por averiguar qué capa falla. Este es el orden que ahorra tiempo.

Primero: resolución de nombres y corrección del destino

• ¿Resuelve el hostname? ¿A qué—dirección proxy pública o IP privada?
• ¿El usuario usa la URL correcta (puerta de entrada del proxy) vs el hostname interno antiguo?
• ¿Están usando un marcadors obsoleto que evita sus controles?

Segundo: establecimiento de la ruta (red + túnel/proxy)

• ¿Puede establecer TCP al endpoint del proxy/túnel?
• ¿MTU/PMTUD causa colgamientos parciales (especialmente descargas grandes, clones de git, pull de contenedores)?
• ¿Hay enrutamiento asimétrico entre conector y app?

Tercero: identidad y decisión de política

• ¿El usuario tiene claims/grupos/roles correctos?
• ¿Pasa la postura del dispositivo? (gestionado, cifrado, conforme)
• ¿La política está denegando con una razón visible en logs?

Cuarto: autenticación a nivel de aplicación y rendimiento

• ¿Bucles de SSO? ¿Desajustes de dominio en cookies? ¿Confusión por terminación TLS?
• ¿Lentitud del backend atribuida erróneamente a “latencia de la VPN”?
• ¿Límites de tasa o bloqueos WAF activados por la IP de egress del proxy?

Regla de atajo: si no puede ver una razón de denegación en logs en cinco minutos, su sistema aún no es operable. Arregle la telemetría antes de continuar el despliegue.

Errores comunes: síntomas → causa raíz → solución

1) “Los usuarios no pueden alcanzar apps internas a menos que usen la VPN antigua”

Síntomas: Timeouts en el navegador; traceroute muestra saltos públicos; DNS resuelve IPs privadas.

Causa raíz: DNS de horizonte dividido todavía devuelve direcciones internas a clientes fuera de la red; la app no está publicada correctamente vía proxy/túnel.

Solución: Publique la app detrás de una puerta de entrada consciente de identidad con un nombre resolvible para clientes remotos; deje de filtrar IPs internas en contextos DNS externos.

2) “ZTNA es más lento que la VPN” (dicho en voz alta, en mayúsculas)

Síntomas: Clones de Git lentos; descargas grandes se bloquean; shells interactivos con retardo.

Causa raíz: Desajuste de MTU, PMTUD bloqueado o conector/proxy infra-provisionado. A veces es solo que la app backend es lenta y ahora puede verse.

Solución: Mida con desglose de tiempos (DNS/conexión/TLS/TTFB). Permita ICMP necesario para PMTUD o limite MSS. Escale conectores horizontalmente y colóquelos cerca de las cargas de trabajo.

3) “Añadimos grupos RBAC, pero la gente todavía tiene demasiado acceso”

Síntomas: Usuarios de un departamento pueden alcanzar servicios no relacionados; el pentest muestra que el movimiento lateral sigue siendo posible.

Causa raíz: La política de red aún concede amplia alcanzabilidad por subred; el acceso a la app no está verdaderamente acotado por aplicación.

Solución: Elimine rutas de subred de los dispositivos de usuario. Reemplace con conectores/proxies por aplicación y listas de permitidos explícitas por identidad de servicio.

4) “Los contratistas pueden acceder a prod porque están en el mismo grupo ‘Ingeniería’”

Síntomas: Señalamientos en auditoría; reuniones incómodas; interés repentino en separación de funciones.

Causa raíz: Roles modelados alrededor del organigrama, no de límites de riesgo. El estado de contratista no está codificado en atributos de identidad.

Solución: Cree identidades/roles separados para contratistas y proveedores; exija condiciones más estrictas (VDI gestionado, aprobaciones JIT) para acceso sensible.

5) “SSO entra en un bucle infinito” tras proxyar una app web interna

Síntomas: Bucle de redirección; cookies que no se mantienen; el usuario ve solicitudes de inicio de sesión repetidas.

Causa raíz: URLs de callback mal configuradas, problemas de dominio de cookies, supuestos mixtos HTTP/HTTPS o doble terminación TLS que confunde la app.

Solución: Estandarice HTTPS de extremo a extremo. Alinee la URL base de la app con la URL externa del proxy. Valide URIs de redirección del IdP y configuraciones de cookies (Secure, SameSite).

6) “Funciona en portátiles pero falla en teléfonos”

Síntomas: Usuarios móviles denegados; escritorio bien.

Causa raíz: Los requisitos de postura del dispositivo excluyen dispositivos no gestionados; o el móvil carece del cliente/cert requerido.

Solución: Decida explícitamente: permita acceso móvil limitado a apps de bajo riesgo o exija enrolamiento móvil gestionado. No lo soporte a medias en silencio.

7) “Encendimos túnel completo por ‘seguridad’ y todo se rompió”

Síntomas: Inicios de sesión SaaS fallan; llamadas de video degradadas; el tráfico se hace hairpin; la cola de helpdesk crece sin remedio.

Causa raíz: La capacidad de egress corporativa no fue dimensionada; las excepciones de túnel dividido son un lío; DNS y políticas de proxy entran en conflicto.

Solución: Prefiera acceso acotado por aplicación. Si necesita túnel completo, invierta en capacidad, egress locales y reglas de enrutado claras. Mida antes y después.

8) “Nuestras políticas son correctas, pero los logs son inútiles”

Síntomas: Eventos deny sin contexto; falta ID de correlación; no se puede responder “quién accedió qué”.

Causa raíz: El logging no se trata como requisito primario; los datos no están centralizados; problemas de sincronización de tiempo.

Solución: Estandarice campos de logs (usuario, dispositivo, app, decisión, motivo). Centralice en SIEM/almacén de logs. Asegure NTP en todos lados.

Tres micro-historias corporativas desde la trinchera

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana migró a una brillante nueva plataforma de acceso. El plan del proyecto decía: “No más VPN. Todo detrás del proxy.” Activaron el interruptor para el acceso remoto y se felicitaron con una invitación de calendario titulada “ZTNA hecho”. Esa invitación envejeció mal.

La suposición errónea fue sutil: creyeron que quitar el cliente VPN eliminaba la adyacencia de red. En realidad, la Wi‑Fi de la oficina seguía plana, y los usuarios remotos aún tenían un perfil VPN “legacy” como fallback para “excepciones”. La lista de excepciones creció en silencio porque siempre lo hace. Algunos servicios todavía dependían de nombres DNS internos que resolvían a IPs privadas, y la gente fue entrenada para “simplemente usar la VPN” cuando algo no cargaba.

Entonces un portátil de un contratista fue phisheado. El atacante no necesitó exploits sofisticados; usó el acceso VPN del contratista, llegó a una VLAN de estaciones y escaneó. Los compartidos de archivos respondieron. Una interfaz de gestión en un hypervisor antiguo respondió. La plataforma de acceso no fue eludida; simplemente fue irrelevante para los caminos que escogió el atacante.

Durante la respuesta, los paneles del equipo estaban llenos de logs del proxy que mostraban “nada sospechoso”. Cierto, y también inútil. La actividad sospechosa estaba en las rutas VPN antiguas y en la red plana de la oficina. El proxy protegía la puerta frontal mientras la puerta trasera estaba apoyada con “solo por unas semanas”.

La solución no fue una herramienta nueva. Fue una decisión de límites: eliminar rutas VPN amplias, aplicar segmentación basada en roles en las redes de oficina y publicar apps de forma que no dependieran del filtrado de DNS interno. También reclasificaron a los contratistas como un nivel de riesgo distinto con condiciones diferentes. La lección: Zero Trust muere cuando mantiene un camino de red de confianza “temporal”.

Micro-historia 2: La optimización que salió mal

Un equipo TI empresarial quería reducir latencia. Movieron sus conectores a un centro de datos central y forzaron todo el tráfico de usuarios remotos a través de él porque “un único egress es más fácil de monitorizar”. Seguridad estuvo de acuerdo, porque la monitorización reconforta y a todo el mundo le gustan los gráficos.

Las quejas de rendimiento empezaron en una semana. No porque la plataforma de acceso fuera inherentemente lenta, sino porque la ruta de tráfico era absurda: usuario → proxy → conector central → carga en la nube en otra región → de vuelta. Las rondas extra fueron letales para protocolos chatty y para apps con muchas peticiones HTTP pequeñas. El volumen de tickets subió, y la gente empezó a susurrar la palabra prohibida: “¿Podemos volver a la VPN?”

El equipo volvió a escalar CPU y ancho de banda de los conectores. Los costes subieron; la experiencia de usuario apenas mejoró. El cuello de botella no era capacidad bruta; era latencia y diseño de camino. Habían optimizado para la conveniencia de monitorizar, no para la física.

La recuperación eventual fue ingeniería aburrida. Desplegaron conectores más cerca de las cargas (incluso dentro de VPCs en la nube), usaron egress regional cuando cumplimiento lo permitió y mantuvieron la monitorización centralizando logs en lugar de centralizar paquetes. También separaron políticas por sensibilidad de app: el tráfico de nómina mantuvo el camino más estricto; la wiki interna tomó el más rápido.

Lección de optimización: “un único punto de estrangulamiento” es atractivo operativamente hasta que se vuelve el cuello de botella en sentido literal.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa con cultura SRE madura implementó acceso por aplicación para administración de producción. Nada dramático: exigieron elevación just-in-time para SSH de prod, usaron certificados de corta duración y grabaron sesiones. La implementación fue poco glamorosa. También funcionó.

Meses después, robaron el portátil de un ingeniero senior de un coche. El ingeniero hizo lo correcto y lo reportó rápido. Seguridad rotó tokens, revocó sesiones y eliminó la confianza del dispositivo. Aun así, todos estuvieron tensos porque “portátil robado” es una frase que hace aprender nuevo vocabulario a los ejecutivos.

Esto es lo que no pasó: no hubo evidencia de acceso a producción desde ese dispositivo tras el robo. Los logs de sesiones mostraron la última elevación exitosa, y los eventos deny del sistema de acceso mostraron intentos de reutilización desde un estado de dispositivo no gestionado. El atacante tenía la máquina, pero no la postura, no los certificados y no la aprobación JIT.

El incidente se resolvió sin rotación masiva de credenciales de producción. No tuvieron que dejar fuera de servicio a la mitad de la flota para estar seguros. Hicieron una revisión dirigida, confirmaron que las restricciones funcionaron y siguieron adelante. El activo más valioso del equipo no fue una herramienta; fue una práctica: privilegios acotados en el tiempo más trazas de auditoría limpias.

Lo aburrido salvó el día. Ese es el trabajo.

Preguntas frecuentes

1) ¿Zero Trust es solo “MFA en todas partes”?

No. MFA ayuda a probar que realmente es el usuario, una vez. Zero Trust también limita qué puede alcanzar ese usuario, desde qué dispositivo, bajo qué condiciones, y registra la decisión.

2) ¿Tenemos que eliminar la VPN por completo?

No. Pero debería eliminar la enroutación VPN plana. Mantenga una VPN legacy solo para excepciones claramente definidas, con rutas estrechas y un plan de fin de vida.

3) ¿Cuál es la diferencia entre ZTNA y microsegmentación?

ZTNA se centra en decisiones de acceso usuario→app usando identidad y postura. La microsegmentación se centra en controles este-oeste entre cargas de trabajo. Normalmente necesita ambos: ZTNA reduce el radio de impacto de usuarios; la microsegmentación reduce lo que un servidor comprometido puede alcanzar.

4) ¿Cómo manejamos acceso SSH en un modelo Zero Trust?

Use un broker/bastión con credenciales de corta duración (certs), elevación JIT para producción y registro/grabación de sesiones. Evite claves compartidas de larga duración y evite dar a portátiles enrutado amplio hacia subredes de servidores.

5) ¿El acceso basado en roles explotará en proliferación de roles?

Lo hará si deja que cada equipo invente roles libremente. Ponga guardrails: roles estables, propietarios, revisiones trimestrales y sesgo hacia roles de grano grueso más autorización a nivel de app.

6) ¿Qué pasa con las cuentas de servicio y la automatización—también hacen “Zero Trust”?

Sí, o ha construido una puerta frontal segura y dejado una entrada lateral robótica. Use identidad de carga de trabajo, tokens de corta duración y políticas explícitas servicio→servicio. No tunelice redes enteras para runners de CI.

7) ¿Cómo evitamos romper apps legacy que asumen acceso LAN?

Comience aislándolas: túneles por aplicación, listas de destinos restringidas y postura estricta. Luego planifique la modernización: SSO, TLS y eliminar dependencias de broadcast, protocolos antiguos y compartidos de archivos.

8) ¿Cuál es la victoria más rápida con mayor reducción de riesgo?

Deje de enrutar a usuarios remotos a grandes subredes internas. Mueva los caminos administrativos más sensibles (SSH/RDP de prod, administración de bases) a acceso por aplicación con JIT y registro.

9) ¿Cómo demostramos a auditores que esto funciona?

Muestre políticas explícitas, controles de membresía de grupos, requisitos de postura y logs de auditoría que respondan: quién accedió qué, cuándo, desde qué dispositivo y por qué se permitió.

10) Si el proxy de acceso cae—¿perdemos todo?

Si lo diseña mal, sí. Construya redundancia: múltiples conectores, health checks y procedimientos de break-glass claros con elevación de corta duración y auditada. La disponibilidad es un requisito de seguridad porque las interrupciones crean rutas de evasión.

Conclusión: próximos pasos que sobreviven el contacto con la realidad

Si recuerda una cosa, que sea esta: su objetivo no es reemplazar un cliente VPN por otro cliente distinto. Su objetivo es reemplazar la confianza implícita en la red por un acceso explícito, basado en roles y consciente de identidad.

Próximos pasos

1. Inventario de rutas VPN reales, destinos y poblaciones de usuarios. Use logs, no suposiciones.
2. Publique apps web a través de acceso consciente de identidad primero. Es la forma más rápida de reducir dependencia de subredes.
3. Mueva acceso administrativo (SSH/RDP/kubectl/admin BD) a túneles por aplicación con credenciales de corta duración y elevación JIT.
4. Encoja el enrutado VPN agresivamente: elimine 10/8 y amigos. Si alguien “necesita todo”, necesita una review de arquitectura, no una ruta.
5. Haga real la postura: defina dispositivos gestionados, haga cumplir cifrado y nivel de parches y trate BYOD como un nivel separado.
6. Operationalícelo: logging con razones de denegación, guion de diagnóstico rápido, revisión trimestral de roles y un camino claro de break-glass que no se convierta en la ruta por defecto.

Hágalo bien y su red de oficina dejará de ser un club privilegiado donde todos obtienen una pulsera que abre todas las puertas. Se convertirá en lo que siempre debió ser: un conjunto de caminos estrechamente definidos que existen solo cuando hay una razón y desaparecen cuando no la hay.