Cada vez más empresas en Bizkaia tienen algún tipo de portal digital: un espacio donde el cliente puede consultar el estado de su pedido, descargar documentos, gestionar su cuenta o comunicarse con el equipo. Son herramientas útiles, pero tienen una cara que pocas veces se discute antes de ponerlas en marcha: la seguridad de los datos que contienen.
No hace falta ser un experto técnico para hacerse las preguntas correctas. Sí hace falta saber cuáles son esas preguntas y qué tipo de respuesta debería darte tu proveedor.
El problema más frecuente: la seguridad que se añade después
En el desarrollo de portales digitales hay un patrón que se repite con más frecuencia de la deseable: el sistema se construye rápido, se pone en marcha, y la seguridad se piensa después. A veces porque las prisas del proyecto lo impiden, a veces porque el cliente no lo pide, y a veces porque el proveedor asume que las plataformas modernas son seguras por defecto.
Ese último punto es el más peligroso. Las plataformas de desarrollo modernas (Firebase de Google es una de las más usadas para este tipo de aplicaciones) son potentes y flexibles, pero su modelo de seguridad requiere configuración explícita. Un proyecto que se despliega sin revisar esa configuración puede tener los datos completamente expuestos aunque la interfaz se vea impecable.
Un ejemplo concreto: Firebase, la plataforma de Google para construir portales y aplicaciones, arranca en modo de prueba cuando se crea un proyecto nuevo. Ese modo permite acceso libre a todos los datos durante los primeros 30 días. Es una configuración pensada para que los desarrolladores trabajen rápido. Si nadie la cambia antes del lanzamiento, el portal queda con la base de datos abierta.
Qué significa que un portal sea seguro, en términos prácticos
La seguridad de un portal de cliente no es un concepto abstracto. Se traduce en respuestas concretas a preguntas concretas.
¿Puede un cliente ver los datos de otro cliente?
Esta es la pregunta más básica y la más importante. En un portal bien construido, cada usuario autenticado solo puede acceder a sus propios documentos, pedidos, facturas o lo que sea que el sistema gestione. Si un usuario malintencionado intenta acceder a los datos de otro cliente, el sistema debe bloquearlo automáticamente.
Esto no se gestiona solo con contraseñas. Se gestiona con reglas de acceso que el desarrollador define en el propio sistema de base de datos, de forma independiente a la interfaz visual. Una contraseña fuerte no protege nada si las reglas de la base de datos permiten acceso libre a cualquier usuario autenticado.
¿Qué ocurre si alguien intenta acceder sin identificarse?
Un portal seguro rechaza cualquier petición de datos que no venga acompañada de una sesión válida. Esa verificación ocurre en el servidor, no solo en la interfaz, lo que significa que no se puede eludir manipulando el navegador o haciendo peticiones directas a la base de datos.
¿Dónde se guardan las contraseñas?
Las contraseñas nunca deben guardarse en texto plano. Cualquier sistema serio almacena una representación cifrada e irreversible, de forma que incluso si alguien accediera a la base de datos, no podría recuperar las contraseñas originales. Plataformas como Firebase Authentication gestionan esto por defecto, lo cual es una de sus ventajas como infraestructura.
Los archivos: un punto que a menudo se pasa por alto
Muchos portales permiten subir o descargar archivos: presupuestos, contratos, facturas, informes. El sistema de almacenamiento de archivos tiene sus propias reglas de acceso, independientes de las de la base de datos.
Es posible (y ocurre) que el acceso a los datos del portal esté correctamente restringido pero los archivos adjuntos estén alojados en un espacio sin restricciones, accesibles para cualquiera que conozca la URL directa. No hace falta estar autenticado: basta con tener el enlace.
La pregunta que hacerle al proveedor: si alguien obtiene el enlace directo a un archivo de otro cliente, ¿puede descargarlo? La respuesta debería ser no.
Las copias de seguridad: qué pasa si algo falla
Un portal en producción acumula datos que tienen valor: historial de pedidos, comunicaciones, documentos. La pregunta sobre copias de seguridad no es catastrofista, es de gestión básica.
Hay que saber con qué frecuencia se hace copia de los datos, dónde se guardan esas copias y cuánto tiempo tardaría en recuperarse el sistema ante un fallo grave. Si el proveedor no tiene una respuesta clara a estas tres preguntas, es una señal de que el sistema no tiene política de recuperación definida.
Una distinción importante: que la plataforma subyacente sea robusta (Google, Amazon y Microsoft tienen infraestructuras con disponibilidad altísima) no significa que los datos de tu empresa estén respaldados automáticamente. La disponibilidad de la infraestructura y la política de copias de seguridad son dos cosas distintas.
El inicio de sesión: más allá de la contraseña
El sistema de autenticación de un portal merece atención propia. Algunos puntos que deberían estar cubiertos:
- Inicio de sesión con Google u otros proveedores: delegar la autenticación en un proveedor externo establecido reduce el riesgo de gestionar contraseñas directamente y aprovecha las capas de seguridad adicionales que esos proveedores ya tienen, como la doble verificación y la detección de accesos sospechosos.
- Qué ocurre cuando un cliente se da de baja: su acceso debe revocarse de forma completa, no solo ocultarle la interfaz. Si la cuenta de autenticación sigue activa, ese usuario podría seguir accediendo aunque ya no debería.
- Límite de intentos fallidos: un sistema que no limita los intentos de inicio de sesión es vulnerable a ataques automatizados. Plataformas como Firebase Authentication gestionan esto de forma nativa.
Preguntas concretas para hacerle a tu proveedor
No hace falta entender la arquitectura técnica del portal para hacer estas preguntas. Son razonables, forman parte de la entrega de cualquier sistema profesional, y cualquier proveedor con experiencia debería poder responderlas sin dificultad:
- ✓ ¿Puede un usuario acceder a los datos de otro usuario? ¿Cómo está bloqueado eso?
- ✓ Si alguien obtiene el enlace directo a un archivo de otro cliente, ¿puede descargarlo?
- ✓ ¿Con qué frecuencia se hace copia de seguridad de los datos? ¿Cuánto tiempo tardaríamos en recuperarnos ante un fallo?
- ✓ Cuando damos de baja a un cliente del portal, ¿su acceso queda completamente revocado?
- ✓ ¿Las contraseñas se almacenan cifradas?
- ✓ ¿El acceso a los datos requiere autenticación en el servidor, o solo en la interfaz?
Si la respuesta a alguna de estas preguntas es vaga o el proveedor no puede explicarla con claridad, merece la pena profundizar antes de poner más datos de clientes en el sistema.
La seguridad como parte del diseño, no del mantenimiento
La forma más eficiente de tener un portal seguro es diseñarlo así desde el principio. Añadir seguridad a un sistema que ya está en producción es costoso, complejo y, en algunos casos, requiere reescribir partes importantes de la arquitectura.
Un proveedor que aborda la seguridad desde el inicio del desarrollo no es más lento ni más caro a largo plazo. Es más predecible: lo que se entrega funciona bien y no genera sorpresas seis meses después.
En zazpiweb: todos los portales de cliente que desarrollamos incluyen reglas de acceso por usuario verificadas antes del lanzamiento, autenticación con proveedores establecidos y política de copias de seguridad documentada. La revisión de seguridad es parte de la entrega, no un paso opcional.
¿Tienes dudas sobre la seguridad del portal de tu empresa?
Revisamos la configuración de portales existentes y explicamos en términos claros qué está bien, qué falta y cómo resolverlo.
Consulta gratuita por WhatsApp