Aislamiento de organizaciones

Sellada y fijada por la base de datos

Ninguna llamada del SDK recibe un argumento de organización. La organización viene de la credencial, y cuando se escribe una fila un trigger de la base de datos la sella a partir del claim de quien llama. Un segundo trigger impide que quien llama desde una organización mueva una fila a otra.

Las lecturas se filtran del mismo modo. Quien llama ve las filas compartidas en el proyecto, las de su propia organización y las de las organizaciones que están debajo.

También cubre los datos derivados

Las políticas a nivel de organización se aplican a registros, archivos, usuarios, notas, notificaciones y eventos, y a los datos derivados de ellos: valores de campo indexados, claves de búsqueda, relaciones, geometría, embeddings y concesiones de acceso. Un lector que no puede ver un registro pero sí sus valores indexados o su embedding no ha quedado excluido, y por eso esas tablas están incluidas. La búsqueda se ejecuta bajo las políticas de quien llama, así que nunca vuelve un resultado de un registro que no habría podido leer.

Credenciales que actúan en una organización

Una clave se puede confinar a una organización al crearla, y eso no se puede cambiar después. Esa clave lee su propia organización, las que están debajo y el nivel compartido, y escribe solo en la propia. Una clave de proyecto puede nombrar una organización en cada solicitud, y se rechaza una que no sea una organización activa de ese proyecto.

Qué lee una credencial sin organización

Una credencial que no actúa en ninguna organización lee las filas compartidas en el proyecto y nada que pertenezca a una organización. Leer en todas las organizaciones a la vez es un permiso aparte, de solo lectura, que una clave pública no puede tener.

La caché

Las respuestas en caché se guardan por organización además de por proyecto, así que las respuestas de dos organizaciones nunca comparten una entrada para una clave que está confinada a una o nombra una.