La seguridad a nivel de fila no es una sugerencia

Aquí hay un experimento mental. Utiliza una plataforma SaaS. Su competidor también utiliza la misma plataforma. Ambos almacenan inventario, resultados de calificaciones, precios e información del cliente. La pregunta: ¿qué impide que tu competidor vea tus datos?

Si la respuesta es "el código de la aplicación verifica qué inquilino es usted y solo muestra sus datos", felicidades, tiene seguridad a nivel de aplicación. Esto significa que un error en el código de la aplicación, un punto final API mal configurado, una inyección SQL o un desarrollador demasiado útil con acceso a la base de datos podrían exponer los datos del inquilino A al inquilino B.

Si la respuesta es "la propia base de datos impone el aislamiento y ninguna consulta puede devolver datos de otro inquilino independientemente de cómo estén escritos", tiene seguridad a nivel de fila. Son cosas muy diferentes.

El problema de la capa de aplicación

AEl aislamiento de inquilinos a nivel de aplicación funciona así: cada consulta incluye un filtro. WHERE inquilino_id = 'su-inquilino'. La aplicación agrega este filtro a cada llamada a la base de datos. Si el filtro está presente, verá sus datos. Si está ausente (debido a un error, un descuido, un nuevo punto final que olvidó la verificación o un desarrollador que ejecuta una consulta rápida en producción), la base de datos felizmente devuelve todo.

La base de datos no conoce los inquilinos. La base de datos solo almacena filas. El trabajo de la aplicación es solicitar los correctos. Y la aplicación, al ser software escrito por humanos, es capaz de cometer errores.

Esto no es teórico. Las fugas de datos de múltiples inquilinos son uno de los incidentes de seguridad más comunes en las plataformas SaaS. Un desarrollador escribe un nuevo punto final API y olvida el filtro de inquilinos. Un script de migración se ejecuta sin la cláusula WHERE. Una sesión de depuración se conecta directamente a la base de datos y ejecuta SELECT * que devuelve los registros de cada inquilino. Cada uno de estos es un simple error. Cada uno podría exponer su inventario, sus precios y los datos de sus clientes.

ALa seguridad a nivel de aplicación significa que la cerradura está en la puerta. La seguridad a nivel de fila significa que las paredes están hechas de hormigón. Las puertas se pueden dejar abiertas. El hormigón no puede.

Seguridad de nivel de fila: la base de datos como Enforcer

La seguridad de nivel de fila (RLS) de Postgres funciona de manera diferente. En lugar de depender de la aplicación para filtrar datos, la propia base de datos hace cumplir las reglas. Cada tabla tiene una política que dice: "este inquilino sólo puede ver filas donde el id_inquilino coincide con su sesión". La política se aplica a nivel de base de datos. Ningún código de aplicación puede anularlo. Ninguna consulta puede eludirlo. A SELECT * devuelve solo sus filas, no porque la aplicación las filtró, sino porque la base de datos se niega a mostrarle nada más.

Si un desarrollador escribe un punto final con errores que olvida el filtro de inquilinos, la base de datos aún devuelve solo los datos correctos del inquilino. Si alguien ejecuta una consulta sin formato, se aplica la política. Si se agrega una nueva función rápidamente y el control de acceso está incompleto, a la base de datos no le importa: la política está ahí, es permanente e inolvidable.

RLS no reemplaza la seguridad de las aplicaciones. Aún necesita autenticación, autorización y un diseño API adecuado. Pero RLS es la red de seguridad: la garantía de que incluso cuando la aplicación comete un error, los datos del inquilino no se filtran. Es la diferencia entre "confiamos en el código" y "la arquitectura no lo permite".

Por qué es importante para ITAD

Las plataformas

ITAD manejan datos sensibles por naturaleza. El inventario incluye números de serie de dispositivos e historiales de activos. El precio revela la estrategia comercial. Las listas de clientes son inteligencia competitiva. Los registros de borrado contienen datos sobre lo que había en el dispositivo antes de que se borrara y, aunque los datos en sí desaparecen, los metadatos (qué clientes tenían, qué dispositivos y qué clasificaciones de datos) son valiosos y confidenciales.

Si es una empresa ITAD que está evaluando una plataforma multiinquilino, la pregunta "¿cómo se aíslan mis datos de otros inquilinos?" Debería estar en tu primer correo electrónico. Y la respuesta debería ser "a nivel de base de datos, utilizando políticas RLS en cada tabla". No "nuestro código de aplicación lo maneja". No "tenemos controles de acceso". No "nuestros desarrolladores son muy cuidadosos". Cuidadoso no es una arquitectura de seguridad. El cuidado es una esperanza.

La seguridad de nivel de nivel no es una característica que se pueda activar o desactivar según las preferencias. Es una decisión arquitectónica fundamental que determina si su plataforma multiinquilino tiene un aislamiento real o un aislamiento simulado. La diferencia es invisible cuando todo funciona correctamente. La diferencia es toda cuando algo sale mal.

Su competidor utiliza la misma plataforma. ¿Pueden ver tus datos? Si la respuesta depende de que la aplicación nunca cometa un error, la respuesta es "todavía no".