mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-26 00:46:22 +02:00
Feat: TrustGraph i18n & Documentation Translation Updates (#781)
Native CLI i18n: The TrustGraph CLI has built-in translation support that dynamically loads language strings. You can test and use different languages by simply passing the --lang flag (e.g., --lang es for Spanish, --lang ru for Russian) or by configuring your environment's LANG variable. Automated Docs Translations: This PR introduces autonomously translated Markdown documentation into several target languages, including Spanish, Swahili, Portuguese, Turkish, Hindi, Hebrew, Arabic, Simplified Chinese, and Russian.
This commit is contained in:
Alex Jenkins
GitHub
parent
19f73e4cdc
commit
f95fd4f052
560 changed files with 236300 additions and 99 deletions
223
docs/tech-specs/neo4j-user-collection-isolation.ru.md
Normal file
223
docs/tech-specs/neo4j-user-collection-isolation.ru.md
Normal file
|
|
@ -0,0 +1,223 @@
|
|||
---
|
||||
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 соответствует тем же стандартам безопасности, что и другие бэкенды, обеспечивая при этом изоляцию данных, одновременно сохраняя гибкость и мощь запросов графов.
|
||||
Loading…
Add table
Add a link
Reference in a new issue