Asuma que ya entraron: qué cambia cuando diseña con Zero Trust

La pregunta con la que suelen llamarnos es "¿cómo evito que entren?". Es una pregunta razonable y también una trampa, porque lleva a gastar todo el presupuesto en la puerta. La pregunta que de verdad ordena las decisiones es otra: ¿qué pasa el día que entren?

El perímetro ya no protege lo que solía proteger

Durante años el modelo fue sencillo: adentro de la red se confía, afuera no. Ese modelo se sostenía cuando todo el mundo trabajaba en la oficina y los sistemas no hablaban con nadie más. Hoy su gente entra desde casa, hay aplicaciones móviles en el campo, y sus sistemas intercambian datos con SAP, con Odoo, con el banco y con el SENIAT. Buena parte del tráfico que importa nace fuera de su red.

Zero Trust parte de aceptar eso: no se confía en una petición por el lugar de donde viene, sino por lo que puede demostrar en ese momento.

Las tres reglas que cambian el diseño

• Verificar siempre: cada petición se autentica y se autoriza, aunque venga de la red interna o de otro sistema propio.
• Menor privilegio de verdad: cada rol accede a lo que necesita para su trabajo, y ni un campo más. Un analista de cobranza no necesita ver la nómina.
• Asumir la brecha: segmentar de forma que un acceso comprometido no abra la casa entera, sino una habitación.

La tercera es la que más cuesta aceptar y la que más rinde. Diseñar asumiendo que algo va a fallar cambia por completo dónde se ponen los controles.

El control que más rinde no es el más caro

En los sistemas que operamos para banca, el control que más veces ha salvado una situación no es el más sofisticado: es la bitácora inalterable. Un registro donde cada acción queda escrita y nadie —ni un administrador— puede modificarla después.

El regulador lo exige en el sector financiero, pero el valor es el mismo en cualquier empresa. Si ocurre un incidente y usted no puede reconstruir quién hizo qué, con qué datos y a qué hora, no tiene forma de responder: ni ante un cliente, ni ante una auditoría, ni ante usted mismo.

Lo que casi siempre encontramos flojo

• Cuentas de servicio con permisos de administrador que se crearon para una migración y nadie volvió a revisar.
• Accesos activos de personas que ya no trabajan en la empresa.
• Verificación en dos pasos en el correo, pero no en los sistemas donde se mueve el dinero.
• Respaldos que se hacen todas las noches y que nunca se probaron restaurando de verdad.

Ninguno de esos cuatro puntos requiere comprar nada. Requiere revisarlos y corregirlos, que es distinto de comprar una herramienta nueva.

Cómo ayuda ABCDesarrollos

Diseñamos con OAuth 2.0, verificación en dos pasos, control de acceso por rol y bitácora inalterable desde el primer día, no como parche posterior. Y cuando el sistema ya existe, revisamos accesos, privilegios y trazabilidad, y le entregamos qué corregir en orden de riesgo.

¿Sabe hoy quién puede ver qué dentro de sus sistemas? Si la respuesta tarda, conviene revisarlo. Lo vemos en 30 minutos.