Seguridad del software de alquiler: qué preguntar antes de confiarle sus datos

Al cabo de solo unos meses de uso, el software de una empresa de alquiler ya alberga una mezcla de información genuinamente sensible. Nombres, direcciones y números de teléfono de los clientes. Datos de tarjetas de pago e importes de fianzas. Contratos de alquiler firmados y albaranes de entrega. Cada vez más, los documentos de identidad que los clientes suben para demostrar quiénes son antes de llevarse equipos que valen miles de euros. Añada a eso el detalle operativo — quién entregó qué artículo, qué conductor visitó qué dirección y cuándo, qué empleado procesó qué reembolso — y una plataforma de alquiler acaba pareciéndose menos a una herramienta de planificación y más a un registro completo de los clientes de una empresa, su dinero y las acciones de su propio personal, todo en un mismo sitio.

Nada de esto es inusual ni evitable. Es simplemente lo que ocurre en cuanto los presupuestos se convierten en contratos, los contratos en entregas y las entregas en pagos. Lo que sí es más evitable es lo poco que se examinan esos datos durante el proceso de compra. La mayoría de las evaluaciones de software dedican semanas a comparar funcionalidades: si gestiona activos serializados, si se comunica con el programa de contabilidad, si la aplicación del conductor funciona sin cobertura en una obra. La seguridad suele merecer una sola línea, si es que la tiene — «¿es seguro?» —, respondida con una frase tranquilizadora en lugar de una pregunta real, y aceptada sin más porque nadie quiere ser quien frene una decisión por algo que parece abstracto.

Eso es tener las prioridades al revés, porque un fallo de seguridad no se anuncia solo como lo haría una pantalla de reservas mal diseñada. Nadie nota un problema hasta que el acceso de un extrabajador sigue funcionando semanas después de que se fuera, o una conversación con soporte revela que cualquier empleado podía ver los datos de tarjeta de cualquier cliente, sin importar lo que su puesto realmente requiriera. La solución no es convertirse en experto en seguridad antes de firmar un contrato. Es hacer una breve lista de preguntas concretas y verificables — del tipo que un proveedor seguro de su propio producto debería poder responder con claridad. Este artículo aborda cuatro de ellas: el inicio de sesión, los permisos, los registros de auditoría y el acceso a la API — usando en todo momento las respuestas de Renttix como ejemplo de cómo es una buena respuesta a cada una.

Una contraseña por sí sola es una puerta débil. La gente las reutiliza entre servicios, las apunta en algún sitio o elige otras fáciles de adivinar, y en realidad eso no tiene tanto que ver con la negligencia como con lo que ocurre cuando se espera que todo el mundo recuerde docenas de contraseñas únicas para sistemas que usa apenas unas veces por semana. Es terreno bien estudiado en investigación de seguridad: los métodos de autenticación modernos reducen de forma medible la tasa de brechas relacionadas con contraseñas, porque eliminan el punto único de fallo que representa una contraseña.

Así que merece la pena hacerle a cualquier proveedor tres preguntas concretas. ¿Está disponible la autenticación de dos factores (2FA), de modo que una contraseña robada o adivinada no baste por sí sola para entrar? ¿Puede su equipo iniciar sesión mediante el inicio de sesión único (SSO) de su propia empresa, de forma que el acceso al sistema de alquiler suba y baje con la cuenta central de cada persona en lugar de depender de un inicio de sesión aparte que alguien tiene que recordar gestionar? ¿Y se ofrecen passkeys — un método de autenticación más reciente que sustituye una contraseña escrita por una clave criptográfica vinculada a un dispositivo, dejando casi sin efecto el truco de phishing más habitual (una página de inicio de sesión falsa que pide escribir la contraseña), sencillamente porque ya no hay contraseña que escribir?

Cada una de estas medidas resuelve un fallo distinto. La 2FA intercepta una contraseña filtrada antes de que se convierta en una intrusión. El SSO significa que, cuando alguien deja la empresa, revocar su cuenta de identidad central le retira el acceso a todos los sistemas conectados a la vez, incluida la plataforma de alquiler, en lugar de depender de que alguien recuerde desactivar por separado un inicio de sesión del software de alquiler, algo fácil de olvidar. Las passkeys eliminan directamente el punto débil: una contraseña que puede sufrir phishing, adivinarse o reutilizarse.

La respuesta de Renttix a esta pregunta es sencilla: SSO, passkeys y 2FA están disponibles para cada inicio de sesión, en lugar de ser un extra reservado a un nivel empresarial o escondido detrás de un ticket de soporte. Sea cual sea el proveedor que esté evaluando, merece la pena preguntar exactamente esto: ¿cuáles de estas tres opciones admiten, y está disponible para nosotros como cliente hoy mismo, no como algo pendiente en una hoja de ruta?

Esta es la pregunta que la mayoría de los compradores nunca se plantea, porque a simple vista los permisos parecen funcionar en casi todos los sistemas de alquiler del mercado. La aplicación móvil de un conductor no muestra los precios de los clientes. Un usuario junior de oficina no ve una opción de menú para emitir reembolsos. Eso parece un control de acceso que funciona, pero solo demuestra que ciertas opciones están ocultas en ciertas pantallas. No dice nada sobre qué ocurre si alguien llega a la misma acción por otro camino.

La distinción está entre la autorización aplicada en la interfaz y la autorización aplicada en el servidor. Que la aplicación se haga solo en la interfaz significa que la restricción depende por completo de qué botones y menús decide mostrar una pantalla — lo cual está bien para un usuario honesto que navega por la aplicación como está previsto, pero no significa nada para alguien con capacidad técnica que puede abrir las herramientas de desarrollador de un navegador, interceptar la solicitud subyacente que envía la aplicación y enviar esa misma solicitud directamente, saltándose la interfaz que se suponía que iba a detenerlo. Si el propio servidor nunca comprueba si la persona que hace esa solicitud realmente tiene permiso para hacerlo, la restricción nunca existió de verdad: solo estaba fuera de la vista.

Los permisos aplicados en el servidor funcionan de otra manera: cada solicitud, sea cual sea el camino por el que llegue, se comprueba contra el rol y los permisos actuales de ese usuario antes de que ocurra nada, independientemente de lo que le hubiera mostrado la interfaz. Es una garantía notablemente más sólida, porque no depende de confiar en que nadie del personal, y nadie que consiga acceso a un dispositivo, una cuenta o un token de integración antiguo, vaya a buscar jamás un atajo alrededor de la interfaz. Se mantiene sin importar por qué camino llegue la solicitud.

Un ejemplo ilustrativo

Imagine a un jefe de almacén que deja la empresa en malos términos. Su cuenta se desactiva ese mismo día, en teoría. Si las comprobaciones de permisos viven solo en la interfaz, una sesión antigua que no haya caducado, una aplicación móvil que siga conectada en un teléfono personal, o un token de integración emitido bajo su cuenta podrían seguir dejando pasar solicitudes, porque nada en el servidor está realmente volviendo a comprobar quién las hace. Si los permisos se aplican en el servidor, en el momento en que esa cuenta se desactiva o su rol cambia, toda solicitud hecha en su nombre — desde cualquier dispositivo, por cualquier camino — se comprueba contra el conjunto de permisos actual y se rechaza. La diferencia no es cosmética: es la diferencia entre revocar un acceso de verdad o solo en apariencia.

La pregunta que merece la pena hacer a un proveedor es directa: si envío esta solicitud directamente, saltándome por completo su interfaz, ¿su servidor sigue comprobando si tengo permiso para hacerlo? La respuesta de Renttix es que los permisos se aplican en el servidor, por rol, en cada solicitud, y no solo se controlan por lo que una pantalla concreta decide mostrar.

Pregunte a cualquier proveedor si existe un registro de quién hizo qué y cuándo — un precio modificado, una factura anulada, una fianza liberada demasiado pronto, una ficha de cliente editada. Sin él, las disputas sobre lo ocurrido en un pedido concreto se convierten en recuerdos contradictorios de una llamada. Con él, se convierten en una consulta de dos minutos que zanja la cuestión con una marca de tiempo y un nombre.

Pero un registro de auditoría plantea una segunda pregunta igual de importante y mucho más olvidada: ¿quién puede leerlo realmente, y qué le muestra? Un registro que permite a cualquier empleado con acceso ver números completos de tarjeta, documentos de identidad o datos personales asociados a cualquier entrada no solo documenta responsabilidad: se convierte silenciosamente en otro lugar por donde se filtran datos sensibles a personas que nunca necesitaron verlos. Un agente de soporte que intenta averiguar por qué cambió el estado de un pedido no necesita ver el número completo de la tarjeta de un cliente para responder a eso; necesita ver que el estado cambió, cuándo y por quién.

Así que la versión más afinada de la pregunta de auditoría es: ¿aplica el propio registro el principio de «necesidad de saber», ocultando los campos sensibles según quién lo consulte, en lugar de mostrarlo todo a cualquiera que tenga algún motivo para abrirlo? La respuesta de Renttix es un registro de auditoría con ocultación — los campos sensibles permanecen ocultos según quién esté mirando, incluso dentro del propio registro construido para dejar constancia de lo ocurrido. Esa es la diferencia entre un registro que genera responsabilidad y otro que crea silenciosamente una segunda exposición de los mismos datos que se supone debe vigilar.

La mayoría de las empresas de alquiler acaban conectando su software de alquiler con otra cosa — una plataforma de contabilidad, una herramienta de marketing, un panel de informes personalizado, su propia web para reservas online. Cada una de esas conexiones suele funcionar mediante una clave API: una credencial que el otro sistema usa para hablar con la plataforma de alquiler en nombre de la empresa.

La pregunta que merece la pena hacer aquí es si esa clave está limitada a un ámbito concreto y es revocable, o si es todo o nada. Una clave limitada puede restringirse exactamente a lo que necesita una integración concreta — acceso de lectura a los datos de reservas para una herramienta de informes, por ejemplo, sin capacidad de emitir reembolsos ni cambiar precios. Una clave revocable puede desactivarse individualmente en cuanto deja de ser necesaria, o en cuanto se sospecha que está comprometida, sin afectar a ninguna otra integración que dependa de su propia clave independiente.

La alternativa es una única clave compartida que concede acceso total a todo lo que la cuenta puede hacer, usada en cada integración que la empresa mantiene. Eso es un único punto de fallo: si acaba por error en un repositorio de código público, se pega en el canal de chat equivocado, o queda alojada en una herramienta de terceros que más tarde sufre su propia brecha, quien la tenga puede hacer cualquier cosa que la cuenta pueda hacer. Y desactivarla para frenar la filtración implica rotar la única clave de la que dependen también todas las demás integraciones, rompiéndolas todas a la vez para resolver un problema causado por una sola.

La API para desarrolladores de Renttix emite claves API con ámbito limitado y revocables, de modo que una sola credencial filtrada o retirada no se lleva por delante todos los sistemas conectados a ella. También merece la pena hacer una pregunta relacionada sobre la exposición de cara al cliente: ¿qué ve un cliente cuando entra en su propia cuenta online? El portal de clientes de Renttix está construido para que los clientes vean sus propios datos — sus propios pedidos, facturas y métodos de pago guardados — y nada más allá de eso. Es un detalle pequeño, pero es el mismo principio aplicado a otro público: acceso limitado a lo que una persona concreta realmente necesita ver.

Ninguna de las cuatro preguntas anteriores requiere conocimientos técnicos para plantearla, solo la disciplina de exigir un mecanismo concreto en lugar de aceptar una frase tranquilizadora general. «¿Se toman en serio la seguridad?» obtiene el mismo sí seguro de cualquier proveedor en cualquier llamada comercial. «¿Su servidor comprueba los permisos en cada solicitud, sea cual sea la interfaz que se muestre?» obtiene un tipo de respuesta muy distinto, y la diferencia entre un proveedor capaz de describir exactamente cómo funciona eso y otro que da rodeos a la pregunta ya es, en sí misma, reveladora.

Como lista breve para llevar a una conversación con un proveedor: ¿admite la plataforma 2FA, SSO y passkeys para el inicio de sesión? ¿Se comprueban los permisos en el servidor en cada solicitud, o solo los controla lo que muestra la interfaz? ¿Existe un registro de auditoría, y oculta los campos sensibles según quién lo consulte? ¿Están las claves API limitadas a lo que realmente necesita cada integración, y son revocables de forma individual en lugar de compartirse entre todas las conexiones?

Esas cuatro preguntas no le dirán todo sobre cómo está construida una plataforma, pero le dirán mucho sobre lo en serio que se ha tomado un proveedor los datos que su empresa está a punto de entregarle, y merece la pena hacerlas antes de que los datos se muevan, no después de que algo salga mal. Si quiere ver cómo responde Renttix a estas preguntas sobre un sistema real y no sobre una diapositiva, pida una demo y pregunte.