trustgraph/docs/tech-specs/neo4j-user-collection-isolation.es.md

layout	title	parent
default	Soporte de aislamiento de usuarios/colecciones en Neo4j	Spanish (Beta)

Soporte de aislamiento de usuarios/colecciones en Neo4j

Beta Translation: This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

Declaración del problema

La implementación actual de almacenamiento y consulta de triples en Neo4j carece de aislamiento de usuarios/colecciones, lo que genera una vulnerabilidad de seguridad para entornos multi-inquilinos. Todos los triples se almacenan en el mismo espacio de grafo sin ningún mecanismo para evitar que los usuarios accedan a los datos de otros usuarios o mezclen colecciones.

A diferencia de otros backends de almacenamiento en TrustGraph:

• Cassandra: Utiliza espacios de claves y tablas separados por usuario y colección
• Almacenes vectoriales (Milvus, Qdrant, Pinecone): Utilizan espacios de nombres específicos de la colección
• Neo4j: Actualmente comparte todos los datos en un único grafo (vulnerabilidad de seguridad)

Arquitectura actual

Modelo de datos

• Nodos: Etiqueta :Node con propiedad uri, etiqueta :Literal con propiedad value
• Relaciones: Etiqueta :Rel con propiedad uri
• Índices: Node.uri, Literal.value, Rel.uri

Flujo de mensajes

• Los mensajes Triples contienen los campos metadata.user y metadata.collection
• El servicio de almacenamiento recibe la información del usuario/colección, pero la ignora
• El servicio de consulta espera user y collection en TriplesQueryRequest, pero los ignora

Problema de seguridad actual

# Cualquier usuario puede consultar cualquier dato - sin aislamiento
MATCH (src:Node)-[rel:Rel]->(dest:Node) 
RETURN src.uri, rel.uri, dest.uri

Solución propuesta: Filtrado basado en propiedades (Recomendado)

Descripción general

Añadir las propiedades user y collection a todos los nodos y relaciones, y luego filtrar todas las operaciones por estas propiedades. Este enfoque proporciona un fuerte aislamiento manteniendo la flexibilidad de consulta y la compatibilidad con versiones anteriores.

Cambios en el modelo de datos

Estructura de nodos mejorada

// Entidades de nodo
CREATE (n:Node {
  uri: "http://example.com/entity1",
  user: "john_doe", 
  collection: "production_v1"
})

// Entidades de literal
CREATE (n:Literal {
  value: "literal value",
  user: "john_doe",
  collection: "production_v1" 
})

Estructura de relaciones mejorada

// Relaciones con propiedades user/collection
CREATE (src)-[:Rel {
  uri: "http://example.com/predicate1",
  user: "john_doe",
  collection: "production_v1"
}]->(dest)

Índices actualizados

// Índices compuestos para un filtrado eficiente
CREATE INDEX node_user_collection_uri FOR (n:Node) ON (n.user, n.collection, n.uri);
CREATE INDEX literal_user_collection_value FOR (n:Literal) ON (n.user, n.collection, n.value);
CREATE INDEX rel_user_collection_uri FOR ()-[r:Rel]-() ON (r.user, r.collection, r.uri);

// Mantener índices existentes para la compatibilidad con versiones anteriores (opcional)
CREATE INDEX Node_uri FOR (n:Node) ON (n.uri);
CREATE INDEX Literal_value FOR (n:Literal) ON (n.value);
CREATE INDEX Rel_uri FOR ()-[r:Rel]-() ON (r.uri);

Cambios de implementación

Servicio de almacenamiento (write.py)

Código actual:

def create_node(self, uri):
    summary = self.io.execute_query(
        "MERGE (n:Node {uri: $uri})",
        uri=uri, database_=self.db,
    ).summary

Código actualizado:

def create_node(self, uri, user, collection):
    summary = self.io.execute_query(
        "MERGE (n:Node {uri: $uri, user: $user, collection: $collection})",
        uri=uri, user=user, collection=collection, database_=self.db,
    ).summary

Función query

def query_triples(self, query):
    # Implementar lógica para filtrar por usuario y colección en la consulta
    # Por ejemplo, reemplazar 'user' y 'collection' en la consulta
    # Usar la función de ejecución de consultas de Neo4j para reemplazar
    # los marcadores de posición con los valores del usuario y la colección
    # y luego ejecutar la consulta.
    # Ejemplo (pseudocódigo):
    # resultado = neo4j.execute_query(query.replace("user", self.user), self.collection)
    # return resultado
    pass

Función store_triples

def store_triples(self, triples):
    # Implementar lógica para almacenar triples con las propiedades user y collection
    # Por ejemplo, añadir las propiedades user y collection a los nodos al crear
    #  nuevos nodos y relaciones.
    pass

Pruebas

Pruebas unitarias

def test_user_collection_isolation():
    # Almacenar triples para user1/collection1
    processor.store_triples(triples_user1_coll1)
    
    # Almacenar triples para user2/collection2
    processor.store_triples(triples_user2_coll2)
    
    # Consultar como user1 solo debería devolver datos de user1/collection1
    resultados = processor.query_triples(query_user1_coll1)
    assert all_results_belong_to_user1_coll1(resultados)
    
    # Consultar como user2 solo debería devolver datos de user2/collection2
    resultados = processor.query_triples(query_user2_coll2)
    assert all_results_belong_to_user2_coll2(resultados)

Pruebas de integración

• Escenarios de múltiples usuarios con datos superpuestos
• Consultas de cross-colección (deberían fallar)
• Pruebas de migración con datos existentes
• Pruebas de rendimiento con grandes conjuntos de datos

Pruebas de seguridad

• Intentar consultar datos de otros usuarios
• Ataques de inyección SQL en parámetros de usuario/colección
• Verificar el aislamiento completo bajo diferentes patrones de consulta

Consideraciones de rendimiento

Estrategia de índice

• Índices compuestos en (user, collection, uri) para un filtrado óptimo
• Considerar índices parciales si algunas colecciones son mucho más grandes
• Supervisar el uso y el rendimiento de los índices

Optimización de consultas

• Utilizar EXPLAIN para verificar el uso de índices en las consultas filtradas
• Considerar el almacenamiento en caché de resultados para datos accedidos con frecuencia
• Perfilar el uso de memoria con un gran número de usuarios/colecciones

Escalabilidad

• Cada combinación de usuario/colección crea islas de datos separadas
• Supervisar el tamaño de la base de datos y el uso de la piscina de conexiones
• Considerar estrategias de escalado horizontal si es necesario

Seguridad y cumplimiento

Garantías de aislamiento de datos

• Físico: Todos los datos del usuario almacenados con propiedades de usuario/colección explícitas
• Lógico: Todas las consultas filtradas por contexto de usuario/colección
• Control de acceso: Validación a nivel de servicio para evitar el acceso no autorizado

Requisitos de auditoría

• Registrar todos los accesos de datos con contexto de usuario/colección
• Rastrear las actividades de migración y los movimientos de datos
• Supervisar los intentos de violar el aislamiento

Consideraciones de cumplimiento

• GDPR: Mayor capacidad para localizar y eliminar datos específicos del usuario
• SOC2: Claros controles de aislamiento de datos y acceso
• HIPAA: Fuerte aislamiento de inquilinos para datos de atención médica

Riesgos y mitigaciones

Riesgo	Impacto	Probabilidad	Mitigación
Consulta sin filtro de usuario/colección	Alto	Medio	Validación obligatoria, pruebas exhaustivas
Degradación del rendimiento	Medio	Bajo	Optimización del índice, perfilado de consultas
Corrupción de datos durante la migración	Alto	Bajo	Estrategia de copia de seguridad, procedimientos de reversión
Complejidad de consultas multi-colección	Medio	Medio	Documentar los patrones de consulta, proporcionar ejemplos

Criterios de éxito

1. Seguridad: Cero acceso de datos cruzado de usuarios en producción
2. Rendimiento: <10% de impacto en el rendimiento de las consultas en comparación con las consultas no filtradas
3. Migración: 100% de los datos existentes migrados sin pérdida de datos
4. Usabilidad: Todos los patrones de consulta existentes funcionan con contexto de usuario/colección
5. Cumplimiento: Rastro de auditoría completo del acceso de datos de usuario/colección

Conclusión

El enfoque de filtrado basado en propiedades proporciona el mejor equilibrio de seguridad, rendimiento y mantenibilidad para añadir aislamiento de usuarios/colecciones a Neo4j. Se alinea con los patrones de multi-inquilinos existentes de TrustGraph al tiempo que aprovecha las fortalezas de Neo4j en la consulta y el indexado de grafos.

Esta solución garantiza que el backend de Neo4j de TrustGraph cumpla con los mismos estándares de seguridad que otros backends de almacenamiento, evitando las vulnerabilidades de aislamiento de datos al tiempo que mantiene la flexibilidad y el poder de las consultas de grafos.