Zero trust es un modelo de seguridad que elimina la confianza implícita basada sólo en estar dentro de la red de la empresa. En la práctica, cada acceso se decide con señales como la identidad, el dispositivo, el recurso solicitado y el contexto; después se concede únicamente el permiso necesario y se vuelve a evaluar si las condiciones cambian.

Para una pyme no significa comprar una plataforma única ni desconfiar del personal. Significa ordenar cuentas, permisos, equipos y reglas para que una contraseña filtrada, una laptop extraviada o un proveedor temporal no abran más recursos de los que realmente necesitan. La adopción puede hacerse por etapas, empezando por correo, cuentas administrativas, archivos sensibles y accesos remotos.

Si todavía no existe un inventario confiable de cuentas y permisos, conviene comenzar con una auditoría de accesos empresariales. Zero trust utiliza esa información para definir decisiones de acceso más precisas; no sustituye el trabajo de identificar responsables y retirar privilegios que ya no corresponden.

Qué significa zero trust en términos prácticos

La publicación SP 800-207 del NIST describe zero trust como un enfoque que deja de depender del perímetro tradicional y concentra la protección en usuarios, activos y recursos. La ubicación de una persona o el hecho de usar un equipo propiedad de la empresa no bastan, por sí solos, para dar confianza automática.

Esto cambia una pregunta habitual. En lugar de preguntar solamente “¿está conectado a la red interna?”, la empresa evalúa “¿quién solicita acceso, con qué equipo, a qué información, para realizar qué tarea y bajo qué condiciones?”. La respuesta puede permitir, limitar, solicitar una verificación adicional o rechazar la conexión.

Zero trust tampoco es un producto terminado. Es una arquitectura y una forma de administrar políticas. Puede apoyarse en directorios de usuarios, autenticación multifactor, administración de dispositivos, segmentación de red, registros de actividad y controles de aplicaciones, pero la tecnología sólo funciona cuando existen responsables, criterios de autorización y procesos de alta, cambio y baja.

Qué debe revisar una decisión de acceso

No todas las herramientas pueden evaluar las mismas señales, y no todos los recursos necesitan el mismo nivel de control. Antes de configurar reglas, conviene definir qué factores son relevantes para cada proceso de negocio.

  • Identidad: qué cuenta realiza la solicitud, si es individual, si continúa activa y qué función tiene asignada.
  • Autenticación: qué evidencia presenta la persona, incluido un segundo factor cuando el riesgo lo justifica.
  • Dispositivo: si el equipo está registrado, actualizado, cifrado y sujeto a las políticas acordadas por la empresa.
  • Recurso: qué aplicación, carpeta, servicio o dato se solicita y qué tan sensible es para la operación.
  • Contexto: desde dónde se conecta, en qué horario, mediante qué red y si el comportamiento coincide con el uso esperado.
  • Acción: si la persona sólo necesita consultar, también debe editar, descargar información o administrar configuraciones.

El resultado no tiene que ser idéntico en todos los casos. Consultar un documento general puede requerir controles básicos; cambiar reglas de correo, descargar una base de datos o entrar con privilegios administrativos exige una revisión más estricta. La meta es aplicar controles proporcionales al riesgo y a la tarea.

Los principios que conviene aplicar primero

Una empresa puede avanzar con zero trust sin rediseñar toda su infraestructura. Los primeros cambios deben reducir exposición real y ser entendibles para quienes utilizan los sistemas.

1. Identidades individuales y autenticación reforzada

Cada persona debería trabajar con una cuenta propia. Las cuentas compartidas dificultan saber quién realizó una acción, complican las bajas y obligan a cambiar una contraseña para varias personas. Cuando una plataforma necesita una cuenta común, debe existir un responsable, un uso delimitado y un método de acceso que conserve la mayor trazabilidad posible.

La autenticación multifactor agrega una evidencia además de la contraseña. Es especialmente importante en correo, administración, nube, acceso remoto y aplicaciones con información sensible. Sin embargo, no corrige por sí sola permisos excesivos, cuentas abandonadas ni aprobaciones fraudulentas; forma parte de un control más amplio.

2. Mínimo privilegio y permisos por función

El mínimo privilegio consiste en conceder sólo lo necesario durante el tiempo requerido. No significa quitar accesos sin revisar el trabajo de cada área. Significa relacionar permisos con responsabilidades reales, separar la operación cotidiana de las tareas administrativas y retirar excepciones cuando dejan de ser necesarias.

Un proceso ordenado de administración de usuarios y equipos ayuda a mantener altas, movimientos y bajas alineados con correo, licencias, dispositivos y aplicaciones. Zero trust depende de que ese ciclo de vida se actualice cuando una persona cambia de puesto o termina una relación laboral.

3. Equipos conocidos y condiciones mínimas de seguridad

Una contraseña válida no convierte automáticamente en confiable a una computadora. Un equipo sin actualizaciones, sin protección o con software no autorizado puede exponer credenciales y datos. Por eso conviene distinguir entre dispositivos administrados por la empresa, equipos personales autorizados y conexiones que no cumplen las condiciones definidas.

Las reglas deben corresponder al recurso. Puede permitirse acceso web limitado desde un equipo personal, pero reservar la descarga de información o la administración para dispositivos registrados. La empresa debe documentar qué revisa, qué ocurre cuando un equipo deja de cumplir y cómo se atiende una excepción legítima.

4. Separación de recursos y reducción del movimiento lateral

Si todas las personas y equipos pueden comunicarse con todos los sistemas, una cuenta comprometida puede tener un alcance innecesario. Separar aplicaciones, redes y perfiles limita ese recorrido. La segmentación debe partir de dependencias reales para no bloquear impresoras, sistemas administrativos, respaldos o integraciones que la operación necesita.

Antes de cambiar reglas de red conviene mapear comunicaciones, responsables y horarios, preparar una reversión y probar con un grupo controlado. En ambientes con infraestructura local, esta etapa puede requerir revisión física de switches, puntos de acceso, servidores y cableado, además del trabajo de configuración.

5. Registro, revisión y ajuste continuo

Una política inicial puede quedar obsoleta cuando cambian los puestos, proveedores, aplicaciones o formas de trabajo. Los registros ayudan a identificar accesos rechazados, solicitudes inusuales y cuentas que ya no se utilizan. No se trata de acumular eventos sin revisión, sino de definir qué señales requieren seguimiento y quién debe atenderlas.

El modelo de madurez zero trust de CISA organiza la adopción alrededor de identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos; además considera visibilidad, automatización y gobierno como capacidades transversales. Para una pyme, esta referencia sirve como mapa de temas, no como una lista que deba implementarse completa desde el primer día.

Señales de alerta antes de adoptar zero trust

Zero trust no debe comenzar con una compra si la empresa desconoce su situación actual. Estas señales indican que primero hace falta ordenar el acceso y definir prioridades:

  • Existen cuentas compartidas sin responsable o contraseñas enviadas por mensajes informales.
  • Personas que cambiaron de puesto conservan permisos del área anterior.
  • Proveedores mantienen accesos permanentes después de terminar un proyecto.
  • No hay una lista confiable de cuentas administrativas, aplicaciones y equipos autorizados.
  • La autenticación multifactor está activa sólo para algunos usuarios sin un criterio documentado.
  • Equipos personales descargan información sensible sin condiciones definidas.
  • Las bajas se concentran en cerrar el correo y dejan activas otras aplicaciones.
  • Los registros existen, pero nadie revisa alertas ni tiene una ruta de escalamiento.

Estas condiciones no se resuelven con una sola política. Requieren coordinación entre dirección, responsables de área, recursos humanos, administración y TI. Cada área aporta información distinta sobre quién necesita acceso y cuándo deja de necesitarlo.

Cómo comenzar sin frenar la operación

La implementación más segura es gradual. Conviene trabajar con una línea base, un grupo piloto, criterios de éxito y un plan de reversión. Así se aprende con un alcance controlado antes de extender las reglas.

  • Inventaría usuarios, cuentas, dispositivos, aplicaciones, datos y accesos externos. Identifica responsables y dependencias.
  • Prioriza correo, cuentas administrativas, almacenamiento, acceso remoto, información financiera y plataformas críticas.
  • Define perfiles por función y separa tareas normales de privilegios elevados. Documenta excepciones y vigencia.
  • Activa controles con un grupo piloto, comunica qué cambiará y prepara soporte para resolver bloqueos legítimos.
  • Revisa eventos, solicitudes rechazadas, incidencias y retroalimentación del equipo antes de ampliar el alcance.
  • Extiende por etapas a otros usuarios, aplicaciones y segmentos, manteniendo una revisión periódica de permisos.

La comunicación es parte del control. Si una persona no entiende por qué aparece una validación adicional o qué hacer cuando cambia de teléfono, buscará atajos. Un instructivo breve, responsables visibles y un proceso de recuperación reducen fricción sin relajar la política.

Caso práctico común: acceso remoto a información administrativa

Imagina una empresa con personal administrativo híbrido y un despacho externo que consulta documentos durante el cierre mensual. Esta es una situación ilustrativa, no un caso de cliente. La empresa desea evitar que una contraseña permita entrar desde cualquier equipo y conservar acceso indefinido.

Un enfoque zero trust puede asignar cuentas individuales, exigir autenticación multifactor, permitir el acceso sólo a la carpeta o aplicación necesaria, diferenciar equipos administrados y limitar la vigencia del proveedor. Los eventos relevantes se revisan y, al terminar el periodo, se retira el permiso temporal.

El beneficio operativo no es prometer que nunca habrá un incidente. Es reducir el alcance de cada acceso, conocer quién tiene permisos y facilitar una respuesta cuando aparece una señal anormal. Si el proveedor necesita una excepción, queda documentada y con una fecha de revisión.

Qué puede atenderse a distancia y cuándo conviene una visita

El inventario de cuentas, revisión de permisos, configuración de autenticación, análisis de registros y ajustes en servicios de nube suelen poder realizarse a distancia cuando existen accesos autorizados y documentación suficiente. También es posible acompañar remotamente un piloto y capacitar a usuarios.

Una visita puede ser necesaria para verificar inventario físico, cableado, switches, servidores locales, segmentación de red, dispositivos sin administración o fallas que no pueden diagnosticarse de forma remota. El alcance debe acordarse antes de intervenir y considerar horarios, dependencias y reversión.

Errores comunes que reducen el valor del proyecto

  • Comprar una herramienta antes de identificar recursos, responsables y riesgos prioritarios.
  • Aplicar la misma regla a todos los usuarios y sistemas sin considerar funciones ni sensibilidad.
  • Activar autenticación multifactor y asumir que ya están resueltos los permisos excesivos.
  • Bloquear accesos sin probar dependencias, comunicar el cambio ni preparar recuperación.
  • Conservar cuentas de emergencia sin responsable, protección adicional o revisión periódica.
  • Acumular registros y alertas sin definir quién los revisa ni qué acciones debe tomar.
  • Intentar transformar toda la empresa al mismo tiempo, sin piloto ni criterios de avance.

También es un error medir el proyecto únicamente por la cantidad de controles activados. Conviene observar si disminuyen las cuentas sin dueño, los permisos fuera de función, las excepciones permanentes y el tiempo necesario para cerrar accesos durante una baja.

Cómo ayuda SOATI a ordenar el control de acceso

SOATI puede apoyar con diagnóstico de usuarios, equipos, aplicaciones y accesos; definición de prioridades; configuración autorizada de controles; documentación de altas, cambios y bajas; y seguimiento técnico dentro del alcance contratado. La propuesta depende de las plataformas, sedes, responsables y nivel de administración que ya tenga la empresa.

Cuando todavía no existe una ruta clara, una consultoría TI para pymes puede ayudar a separar lo urgente de lo que conviene implementar por etapas. Si la empresa necesita operación continua de usuarios, equipos y servicios, el siguiente paso puede integrarse a servicios administrados de TI con responsabilidades y entregables acordados.

SOATI no sustituye las decisiones internas sobre quién debe ver cada información ni promete seguridad absoluta. El responsable del proceso debe autorizar los permisos; TI implementa y documenta los controles; y la dirección define el nivel de riesgo aceptable para la operación.

Lista breve para la primera revisión

  • ¿Cuáles son las cuentas administrativas y quién responde por cada una?
  • ¿Qué aplicaciones y datos no deberían estar disponibles desde cualquier equipo?
  • ¿Qué accesos conservan excolaboradores, proveedores o personas que cambiaron de función?
  • ¿Dónde falta autenticación multifactor y cómo se recuperará una cuenta?
  • ¿Qué equipos están registrados, actualizados y asignados a una persona?
  • ¿Qué excepciones existen, quién las autorizó y cuándo se revisarán?
  • ¿Quién recibe alertas y qué procedimiento sigue ante una actividad inusual?

Responder estas preguntas permite definir un primer alcance realista. El siguiente paso útil no es activar todo, sino elegir un recurso importante, corregir sus cuentas y permisos, probar las reglas con usuarios representativos y documentar lo aprendido antes de ampliar el modelo.