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

---
layout: default
title: "Поддержка изоляции пользователя/коллекции в Neo4j"
parent: "Russian (Beta)"
---

# Поддержка изоляции пользователя/коллекции в 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.

## Формулировка проблемы

Текущая реализация хранения и запросов в Neo4j не обеспечивает изоляцию пользователя/коллекции, что создает проблему безопасности многопользовательской среды. Все тройки хранятся в одном графе без каких-либо механизмов для предотвращения доступа пользователей к данным других пользователей или смешения коллекций.

В отличие от других бэкендов хранения в TrustGraph:
- **Cassandra**: использует отдельные пространства ключей для каждого пользователя и таблицы для каждой коллекции.
- **Vector-хранилища** (Milvus, Qdrant, Pinecone): используют пространства имен, специфичные для коллекции.
- **Neo4j**: в настоящее время все данные хранятся в одном графе (уязвимость для безопасности).

## Текущая архитектура

### Модель данных
- **Узлы**: метка `:Node` с свойством `uri`, метка `:Literal` с свойством `value`
- **Отношения**: метка `:Rel` с свойством `uri`
- **Индексы**: `Node.uri`, `Literal.value`, `Rel.uri`

### Поток сообщений
- Сообщения `Triples` содержат поля `metadata.user` и `metadata.collection`
- Сервис хранения получает информацию о пользователе/коллекции, но игнорирует ее
- Сервис запросов ожидает `user` и `collection` в `TriplesQueryRequest`, но игнорирует их

### Текущая проблема безопасности
```cypher
# Любой пользователь может запросить любые данные - нет изоляции
MATCH (src:Node)-[rel:Rel]->(dest:Node)
RETURN src.uri, rel.uri, dest.uri
```

## Предлагаемое решение: Фильтрация на основе свойств (Рекомендуется)

### Обзор
Добавьте свойства `user` и `collection` ко всем узлам и отношениям, а затем фильтруйте все операции по этим свойствам. Этот подход обеспечивает надежную изоляцию, сохраняя при этом гибкость запросов и обратную совместимость.

### Изменения в модели данных

#### Улучшенная структура узла
```cypher
// Узел
CREATE (n:Node {
  uri: "http://example.com/entity1",
  user: "john_doe",
  collection: "production_v1"
})

// Литеральные сущности
CREATE (n:Literal {
  value: "literal value",
  user: "john_doe",
  collection: "production_v1"
})
```

#### Улучшенная структура отношений
```cypher
// Отношения с свойствами user/collection
CREATE (src)-[:Rel {
  uri: "http://example.com/predicate1",
  user: "john_doe",
  collection: "production_v1"
}]->(dest)
```

#### Обновленные индексы
```cypher
// Комплексные индексы для эффективного фильтра
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);

// Сохранение существующих индексов для обратной совместимости (необязательно)
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);
```

### Изменения в реализации

#### Сервис хранения (`write.py`)

**Текущий код:**
```python
def create_node(self, uri):
    summary = self.io.execute_query(
        "MERGE (n:Node {uri: $uri})",
        uri=uri, database_=self.db,
    ).summary
```

**Обновленный код:**
```python
def create_node(self, uri, user, collection):
    summary = self.io.execute_query(
        "MERGE (n:Node {uri: $uri})",
        uri=uri, user=user, collection=collection, database_=self.db,
    ).summary
```

#### Сервис запросов
- Добавьте фильтры для user и collection в запросы, чтобы обеспечить изоляцию.

### План реализации

### Этап 1: Основа (Неделя 1)
1. [ ] Обновление сервиса хранения для приема и хранения свойств user/collection
2. [ ] Создание комплексных индексов для эффективного запроса
3. [ ] Реализация обратной совместимости
4. [ ] Создание модульных тестов для новой функциональности

### Этап 2: Обновление запросов (Неделя 2)
1. [ ] Обновление всех шаблонов запросов для включения фильтров user/collection
2. [ ] Добавление валидации запросов и мер безопасности
3. [ ] Обновление интеграционных тестов
4. [ ] Тестирование производительности с запросами, отфильтрованными

### Этап 3: Миграция и развертывание (Неделя 3)
1. [ ] Создание скриптов миграции для существующих экземпляров Neo4j
2. [ ] Документация и руководства по развертыванию
3. [ ] Мониторинг и оповещения об изоляции
4. [ ] Тестирование конвейера

### Этап 4: Усиление (Неделя 4)
1. [ ] Удаление режима обратной совместимости
2. [ ] Добавление комплексной журнализации
3. [ ] Проверка безопасности и тестирование на проникновение
4. [ ] Оптимизация производительности

## Стратегия тестирования

### Модульные тесты
```python
def test_user_collection_isolation():
    # Храним тройки для user1/collection1
    processor.store_triples(triples_user1_coll1)

    # Храним тройки для user2/collection2
    processor.store_triples(triples_user2_coll2)

    # Запрос как user1 должен возвращать только данные user1
    results = processor.query_triples(query_user1_coll1)
    assert all_results_belong_to_user1_coll1(results)

    # Запрос как user2 должен возвращать только данные user2
    results = processor.query_triples(query_user2_coll2)
    assert all_results_belong_to_user2_coll2(results)
```

### Интеграционные тесты
- Сценарии многопользовательского взаимодействия с перекрывающимися данными
- Запросы к перекрестным коллекциям (должны завершаться неудачей)
- Тестирование миграции с существующими данными
- Тестирование производительности с большими наборами данных

### Тесты безопасности
- Попытки запросить данные других пользователей
- Атаки SQL injection на параметры user/collection
- Проверка полной изоляции при различных шаблонах запросов

## Соображения производительности

### Стратегия индексирования
- Комплексные индексы на `(user, collection, uri)` для оптимальной фильтрации
- Рассмотрите частичные индексы, если некоторые коллекции значительно больше
- Отслеживайте использование и производительность индекса

### Оптимизация запросов
- Используйте EXPLAIN для проверки использования индекса в запросах, отфильтрованных по user/collection
- Рассмотрите кэширование результатов запросов для часто используемых данных
- Профилируйте использование памяти с большим количеством пользователей/коллекций

### Масштабируемость
- Каждая комбинация пользователя/коллекции создает отдельные "острова данных"
- Отслеживайте размер базы данных и использование пула соединений
- Рассмотрите стратегии горизонтального масштабирования, если необходимо

## Безопасность и соответствие

### Гарантии изоляции данных
- **Физическая**: Все данные пользователя хранятся с явными свойствами user/collection
- **Логическая**: Все запросы фильтруются по контексту user/collection
- **Контроль доступа**: Уровень сервиса обеспечивает проверку доступа

### Требования к отчетности
- Отслеживайте доступ к данным с контекстом user/collection
- Отслеживайте активности миграции и перемещения данных
- Мониторинг попыток нарушить изоляцию

### Соображения соответствия
- GDPR: Улучшенная возможность находить и удалять данные, специфичные для пользователя
- SOC2: Четкая изоляция и контроль доступа
- HIPAA: Сильная изоляция для данных о здравоохранении

## Риски и смягчающие факторы

| Риск | Влияние | Вероятность | Смягчение |
|------|--------|------------|------------|
| Отсутствие фильтра user/collection в запросе | Высокий | Средняя | Обязательная валидация, комплексное тестирование |
| Снижение производительности | Средний | Низкая | Оптимизация индекса, профилирование запросов |
| Повреждение данных во время миграции | Высокий | Низкая | Стратегия резервного копирования, процедуры отката |
| Уязвимость для безопасности | Высокий | Низкая | Проверка безопасности, тестирование на проникновение |

## Критерии успеха

1. **Безопасность**: Полная изоляция данных между пользователями в производственной среде
2. **Производительность**: <10% влияния на производительность запросов по сравнению с нефильтрованными запросами
3. **Миграция**: 100% данных существующего экземпляра Neo4j успешно мигрированы без потерь
4. **Удобство использования**: Все существующие шаблоны запросов работают с контекстом user/collection
5. **Соответствие**: Полный журнал доступа к данным с контекстом user/collection

## Заключение

Предлагаемый подход на основе фильтрации свойств обеспечивает наилучший баланс между безопасностью, производительностью и удобством обслуживания для добавления изоляции пользователя/коллекции в Neo4j. Он соответствует существующим многопользовательским шаблонам TrustGraph, одновременно используя возможности Neo4j в области запросов и индексирования графов.

Это решение гарантирует, что бэкенд Neo4j TrustGraph соответствует тем же стандартам безопасности, что и другие бэкенды, обеспечивая при этом изоляцию данных, одновременно сохраняя гибкость и мощь запросов графов.