Seguridad de SaaS: lo que el agua enseña sobre tu sistema

Hay un panel de tu sistema abierto en internet ahora mismo. Probablemente no sabes cuál. Puede ser el admin del inventario, el dashboard del CRM que armó el proveedor anterior, o esa hoja de cálculo compartida "con cualquiera que tenga el enlace". La seguridad de SaaS suele fallar justo ahí: no por hackers geniales, sino por puertas que alguien olvidó abiertas.

En agosto de 2026, el exjefe de la NSA, Paul Nakasone, dijo algo simple después de una serie de ataques sospechosos vinculados a Irán contra sistemas de agua en Estados Unidos: los controladores de estaciones de agua no deberían estar en internet. Punto. No era un problema de criptografía avanzada. Era gente poniendo el equipo que abre y cierra válvulas en una red pública, muchas veces con contraseña por defecto.

Si una planta de tratamiento de agua comete ese error, tu SaaS de agendamiento también puede. La diferencia es que nadie va a escribir una noticia sobre ti. El perjuicio se queda solo contigo.

Por qué los sistemas de agua terminaron en internet

La respuesta es aburrida: comodidad. El operador quería revisar el nivel del depósito desde el celular, en casa, a las 23h. El proveedor del controlador ofreció acceso remoto. Alguien abrió un puerto en el router y listo. Funcionó durante años. Nadie volvió a cerrarlo.

En los casos reportados, los atacantes ni siquiera necesitaron técnica sofisticada. Buscaron en internet dispositivos conocidos, probaron la contraseña de fábrica y entraron. En algunos municipios, tocaron configuraciones y obligaron a operar en modo manual. En otros, solo dejaron un mensaje en la pantalla.

Esa es la parte que te importa: el ataque real casi nunca es de película. Es alguien probando la manija de cada puerta de la calle y entrando en la que estaba sin llave.

Tu negocio tiene la misma vulnerabilidad

Cambia "controlador de válvula" por cualquier sistema que haga funcionar tu empresa. Lo veo todo el tiempo en clientes pequeños y medianos:

• Panel de administración del sitio accesible en /admin con usuario admin y la contraseña que el desarrollador puso en 2019.
• Base de datos en la nube con el puerto abierto a cualquier IP, porque "el programador necesitaba acceder desde casa".
• Automatización en n8n o Make con webhook público que acepta cualquier petición, sin ningún token.
• Integración con WhatsApp usando una clave de API pegada en un archivo que está en GitHub, público.
• Cámaras, torniquete, sistema de fichaje, todo con acceso remoto activado y contraseña de fábrica.

Ninguno es exótico. Todos los encontré en auditorías de clientes que creían estar "tranquilos". Uno era una clínica con datos de pacientes. Tenía la API del sistema de citas abierta sin autenticación. Cualquiera con la URL podía listar nombre, teléfono y hora de la consulta.

La seguridad no va de cerrar bien. Va de no dejar la puerta en la calle.

Qué significa "no debería estar en internet" en la práctica

El consejo de Nakasone tiene una lógica que sirve para cualquier sistema. Antes de preguntar "¿cómo protejo esto?", pregunta "¿esto necesita ser accesible desde fuera?".

En la mayoría de los casos, la respuesta es no. La base de datos solo necesita hablar con la aplicación. El panel interno solo necesita ser accedido por el equipo. El webhook solo necesita aceptar llamadas de un proveedor específico.

Pensándolo así, la lista de cosas que de verdad necesitan estar expuestas se encoge mucho. Queda el sitio institucional, el área de clientes y, como mucho, uno o dos puntos de integración. Todo lo demás puede quedar detrás de una VPN, de una lista de IPs permitidas, o simplemente apagado.

Esto no cuesta caro. Cerrar el puerto de la base de datos para que solo acepte el servidor de la aplicación es una configuración de diez minutos en cualquier proveedor de nube. Poner un token en el webhook es una línea. Lo caro es la filtración después.

Cuatro preguntas para hacerle hoy a tu proveedor

No necesitas entender de firewall para exigir esto. Necesitas hacer las preguntas correctas a quien cuida tu sistema, sea freelancer, agencia o el sobrino que "sabe de computadoras".

1. ¿Qué servicios de la empresa son accesibles desde internet sin login? Pide la lista. Si la persona no sabe responder, ese ya es el problema.
2. ¿Todavía hay alguna contraseña por defecto o compartida en uso? Router, panel, base de datos, admin de WordPress. Una contraseña por persona, con dos factores en los sistemas críticos.
3. Si el desarrollador anterior se va hoy, ¿todavía puede entrar en algo? El acceso de exproveedores es una de las formas más comunes de filtración. Ya escribí sobre eso aquí en el blog.
4. ¿Cómo me entero de que me invadieron? Sin logs y sin alertas, solo te enteras cuando el cliente reclama o cuando el dato aparece a la venta.

Si las cuatro respuestas son claras y convincentes, genial. Si quedan vagas, acabas de descubrir dónde invertir la próxima hora de tu mes.

El SaaS que contratas también entra en la cuenta

Hay un segundo lado. Buena parte de tu negocio corre en SaaS de terceros: CRM, ERP, herramienta de envíos, sistema de citas. No controlas su servidor, pero controlas cómo lo usas.

Dos cosas marcan diferencia de verdad. Primera: activa la autenticación en dos factores en todo lo que lo permita. Es la protección más barata que existe y la mayoría de las cuentas invadidas no la tenía. Segunda: revisa quién tiene acceso a qué, al menos cada trimestre. Las cuentas de gente que ya se fue siguen activas durante años, y cada una es un controlador de agua enchufado a internet con la contraseña en la etiqueta.

Si el proveedor del SaaS no ofrece dos factores en 2026, eso dice algo sobre su madurez. Vale la pena pesarlo en la renovación.

No necesitas volverte paranoico, necesitas cerrar puertas

Nada de esto exige que entiendas de seguridad. Exige que alguien mire tu sistema con la pregunta correcta: ¿qué está expuesto y no necesitaba estarlo? En la mayoría de las empresas que atiendo, la primera ronda de ese análisis cabe en una tarde y resuelve los riesgos más obvios sin cambiar de sistema ni gastar en herramientas nuevas.

La estación de agua no fue atacada por ser importante. Fue atacada por estar visible. Tu sistema puede ser mucho menos importante y seguir igual de visible.

Si quieres que alguien haga esa revisión a fondo en tu sistema, en tu automatización o en el SaaS que desarrollaste, mira cómo trabajo. Suele ser una conversación más corta de lo que imaginas.

Hay un panel de tu sistema abierto en internet ahora mismo. Solo que no sabes cuál.

En agosto, el exjefe de la NSA resumió una ola de ataques a estaciones de agua en EE. UU. en una frase: un controlador de válvula no debería estar en internet. No fue un hacker genial. Fue contraseña de fábrica y un puerto que alguien olvidó abierto.

Cambia "válvula" por un panel /admin de 2019, una base de datos en la nube abierta a cualquier IP o un webhook de n8n sin token. Ya encontré todos en clientes que se decían "tranquilos", incluida una clínica con datos de pacientes expuestos.

La seguridad no va de cerrar bien. Va de no dejar la puerta en la calle.

Antes de preguntar "¿cómo protejo esto?", pregunta "¿esto necesita ser accesible desde fuera?". En la mayoría de los casos, la respuesta es no y la corrección cabe en una tarde.

¿Quieres saber qué está expuesto en tu sistema sin necesidad? Escríbeme, suele ser una conversación más corta de lo que imaginas.

#SeguridadDeLaInformación #SaaS #Ciberseguridad #PequeñasEmpresas #Automatización