Aislamiento de datos entre entornos

Cada entorno de KeenAuth (development, staging, production en cada uno de sus proyectos) es un tenant independiente. Los usuarios, las organizaciones, las aplicaciones, las sesiones, las claves, los registros y los eventos de un entorno nunca son visibles desde otro entorno, incluido otro entorno de su propia cuenta. Esta página explica cómo se aplica ese límite.

Dos líneas de defensa independientes

Los entornos comparten un esquema de base de datos, y cada fila que pertenece a un entorno incluye el identificador de ese entorno. El aislamiento se aplica dos veces, y ambas comprobaciones deben fallar al mismo tiempo para que los datos crucen el límite:

1. Ámbito de entorno tipado en la aplicación. Cada solicitud se resuelve a exactamente un entorno a partir de su nombre de host o de su credencial, antes de leer cualquier dato. El código que lee o escribe datos de un entorno no puede abrir una transacción de base de datos sin ese ámbito; una llamada sin él se rechaza antes de ejecutar la consulta.
2. Seguridad a nivel de fila de PostgreSQL. Cada tabla que contiene datos de entornos tiene la seguridad a nivel de fila habilitada y forzada, de modo que la política también se aplica al propietario de la tabla. Cada transacción establece el entorno actual, y una fila solo es visible cuando su entorno coincide. Una transacción que no ha establecido un entorno no ve ninguna fila. Ningún rol de aplicación o de mantenimiento puede omitir la seguridad a nivel de fila.

Cada tabla con ámbito de entorno comienza su clave primaria y sus índices con el identificador del entorno, de modo que la condición de aislamiento no añade una búsqueda independiente a las consultas.

Búsquedas por token o clave

Algunas solicitudes llegan con solo un valor secreto, por ejemplo un código de autorización, un token de actualización o una clave de API. KeenAuth localiza ese valor mediante una búsqueda basada únicamente en su resumen (digest) y, después, compara el entorno del registro almacenado con el entorno de la solicitud. Si no coinciden, el valor se trata como no válido.

Qué ve al cruzar el límite

Más allá de la base de datos

El mismo límite se aplica a todos los demás lugares donde se almacenan datos de entornos:

• Cachés: cada clave de caché comienza con el identificador del entorno.
• Eventos y trabajos: cada evento interno incluye su entorno, y los consumidores establecen su ámbito de base de datos a partir de él; cada trabajo en cola incluye el entorno al que pertenece.
• Claves: las claves de cifrado y de firma son independientes para cada entorno.
• Registros: las líneas de registro incluyen el entorno como campo, y la API de registros del entorno devuelve únicamente las entradas del entorno que usted invoca.
• Trabajo en segundo plano: los trabajos de mantenimiento (limpieza por retención, eliminaciones) se ejecutan entorno por entorno, cada uno en su propia transacción con ámbito.

Trasladar la configuración de un entorno a otro (promoción de configuración) copia únicamente los ajustes. Los secretos y los datos de usuarios finales u organizaciones nunca forman parte de un paquete de promoción.

Cómo se prueba el aislamiento

Un conjunto de pruebas de aislamiento entre tenants se ejecuta en la integración continua de KeenAuth y bloquea un cambio cuando falla. Comprueba que:

• cada tabla que contiene datos de entornos tiene la seguridad a nivel de fila habilitada y forzada;
• cada superficie de API devuelve 404 o 401 para recursos, tokens y clientes de otro entorno;
• los trabajos en segundo plano y la canalización de registros y eventos solo afectan al entorno indicado en su entrada.

Una comprobación del esquema también rechaza una nueva tabla de datos de entorno que no tenga la columna del identificador de entorno.

Relacionado

• Usuarios y mensajes de prueba en entornos que no son de producción
• Política de versionado y obsolescencia de la API