mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-25 16:36:21 +02:00
196 lines
9.7 KiB
Markdown
196 lines
9.7 KiB
Markdown
---
|
||
layout: default
|
||
title: "תמיכה ביסודות משתמשים/מערכות ב-Neo4j"
|
||
parent: "Hebrew (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**: משתמשת במרחבי מפתחות נפרדים לכל משתמש וטבלאות לכל מערכת
|
||
- **אחסון וקטורי** (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"
|
||
})
|
||
|
||
// ישויות Literal
|
||
CREATE (n:Literal {
|
||
value: "literal value",
|
||
user: "john_doe",
|
||
collection: "production_v1"
|
||
})
|
||
```
|
||
|
||
#### מבנה קשר משופר
|
||
```cypher
|
||
// קשרים עם תכונות משתמש/מערכת
|
||
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);
|
||
|
||
// שמירה על אינדקסים קיימים לאחור התאמה (אופציונלי)
|
||
```
|
||
|
||
## תוכנית יישום
|
||
|
||
### שלב 1: יסודות (שבוע 1)
|
||
1. [ ] עדכן את שירות האחסון לקבל ולשמור תכונות משתמש/מערכת
|
||
2. [ ] הוסף אינדקסים משולבים לביצוע שאילתות מיטבי
|
||
3. [ ] יישם שכבת התאמה לגרסאות קודמות
|
||
4. [ ] צור בדיקות יחידה לפונקציונליות החדשה
|
||
|
||
### שלב 2: עדכוני שאילתות (שבוע 2)
|
||
1. [ ] עדכן את כל דפוסי השאילתות כדי לכלול סינון משתמש/מערכת
|
||
2. [ ] הוסף אימות שאילתות ובקרת אבטחה
|
||
3. [ ] עדכן בדיקות אינטגרציה
|
||
4. [ ] בדיקות ביצוע עם שאילתות מסוננות
|
||
|
||
### שלב 3: העברה והפצה (שבוע 3)
|
||
1. [ ] צור סקריפטים להעברת נתונים עבור מופעי Neo4j קיימים
|
||
2. [ ] תיעוד והוראות הפעלה
|
||
3. [ ] ניטור והתראות על הפרות ביסודות
|
||
4. [ ] בדיקות סיום עם מספר משתמשים/מערכות
|
||
|
||
### שלב 4: חיזוק (שבוע 4)
|
||
1. [ ] הסר את מצב ההתאמה לגרסאות קודמות
|
||
2. [ ] הוסף רישום ביקורת מקיף
|
||
3. [ ] ביקורת אבטחה וגישה
|
||
4. [ ] בדיקות ביצוע
|
||
|
||
## אסטרטגיית בדיקה
|
||
|
||
### בדיקות יחידה
|
||
```python
|
||
def test_user_collection_isolation():
|
||
# שמור שליש עבור משתמש1/מערכת1
|
||
processor.store_triples(triples_user1_coll1)
|
||
|
||
# שמור שליש עבור משתמש2/מערכת2
|
||
processor.store_triples(triples_user2_coll2)
|
||
|
||
# שאילת משתמש1 צריך רק להחזיר את הנתונים של משתמש1
|
||
results = processor.query_triples(query_user1_coll1)
|
||
assert all_results_belong_to_user1_coll1(results)
|
||
|
||
# שאילת משתמש2 צריך רק להחזיר את הנתונים של משתמש2
|
||
results = processor.query_triples(query_user2_coll2)
|
||
assert all_results_belong_to_user2_coll2(results)
|
||
```
|
||
|
||
### בדיקות אינטגרציה
|
||
- תרחישים רב-משתמשים עם נתונים חופפים
|
||
- שאילתות בין מערכות (צריכות להיכשל)
|
||
- בדיקות העברה עם נתונים קיימים
|
||
- ביצועים - שורה עם מערכות נתונים גדולות
|
||
|
||
### בדיקות אבטחה
|
||
- ניסיון לשאול נתונים של משתמשים אחרים
|
||
- התקפות SQL על פרמטרים של משתמש/מערכת
|
||
- אימות של ביסודות תחת דפוסי שאילתות שונים
|
||
|
||
## שיקולי ביצועים
|
||
|
||
### אסטרטגיית אינדקס
|
||
- אינדקסים משולבים על `(user, collection, uri)` לביצוע שאילתות מיטבי
|
||
- שקול אינדקסים חלקיים אם יש למערכות רבות יותר גודל גדול
|
||
- עקוב אחר שימוש באינדקס וביצוע שאילתות
|
||
|
||
### אופטימיזציה של שאילתות
|
||
- השתמש ב-EXPLAIN כדי לוודא שימוש באינדקס בשאילתות מסוננות
|
||
- שקול אחסון תוצאות שאילתות לשימוש חוזר
|
||
- פרופיל שימוש בזיכרון עם מספר משתמשים/מערכות גדולים
|
||
|
||
### סקלאביליות
|
||
- כל מערכת משתמשים/מערכת יוצרת איזולציה נפרדת של נתונים
|
||
- עקוב אחר גודל מסד הנתונים ושימוש בבריאת חיבורים
|
||
- שקול אסטרטגיות סקלאביליות אופקיות במידת הצורך
|
||
|
||
## אבטחה ותאימות
|
||
|
||
### ביסודות נתונים
|
||
- **פיזי**: כל הנתונים של משתמש מאוחסנים עם תכונות משתמש/מערכת ספציפיות
|
||
- **לוגי**: כל השאילתות מסוננות על ידי הקשר משתמש/מערכת
|
||
- **בקרה**: שכבת שירות מאמתת גישה
|
||
|
||
### דרישות ביקורת
|
||
- רשום את כל גישה לנתונים עם הקשר משתמש/מערכת
|
||
- עקוב אחר פעילויות העברה
|
||
- עקוב אחר ניסיונות הפרות ביסודות
|
||
|
||
### שיקולים תאימות
|
||
- GDPR: יכולת טובה יותר למצוא ולמחוק נתונים ספציפיים למשתמשים
|
||
- SOC2: בקרה בסיסית וגישה של משתמשים
|
||
- HIPAA: ביסודות חזקים עבור נתונים בתחום הבריאות
|
||
|
||
## סיכונים ותיקונים
|
||
|
||
| סיכון | השפעה | הסתברות | תיקון |
|
||
|------|--------|------------|------------|
|
||
| שאילתות חסרות סינון משתמש/מערכת | גבוה | בינונית | אימות חובה, בדיקות מקיפות |
|
||
| ירידה בביצועים | בינונית | נמוכה | אופטימיזציה של אינדקס, פרופיל שאילתות |
|
||
| אובדן נתונים בהעברה | גבוה | נמוכה | אסטרטגיית גיבוי, פרוצדורות שלבים אחורה |
|
||
| קשיים בהתאמה לגרסאות קודמות | בינונית | בינונית | תוכנית יישום, תיעוד |
|
||
| קשיים בביצוע שאילתות מורכבות | בינונית | בינונית | תיעוד דפוסי שאילתות |
|
||
|
||
## קריטריוני הצלחה
|
||
|
||
1. **אבטחה**: אין גישה בין משתמשים בייצור
|
||
2. **ביצועים**: <10% השפעה על ביצועי השאילתות בהשוואה לשאילתות לא מסוננות
|
||
3. **העברה**: 100% נתונים קיימים מוצלחים בהעברה ללא אובדן
|
||
4. **שימושיות**: כל דפוסי השאילתות הקיימים עובדים עם הקשר משתמש/מערכת
|
||
5. **תאימות**: תיעוד מלא של גישה לנתונים מבוסס משתמש/מערכת
|
||
|
||
## מסקנה
|
||
|
||
הגישה המבוססת על תכונות מספקת את האיזון הטוב ביותר של אבטחה, ביצועים וקלות תחזוקה להוספת ביסודות משתמשים/מערכות ב-Neo4j. היא תואמת עם דפוסי הרב-משתמשים הקיימים ב-TrustGraph תוך ניצול החוזקות של Neo4j בשאילתות גרפים ואינדקסים.
|
||
|
||
פתרון זה מבטיח שהבסיס של ה-Neo4j ב-TrustGraph עומד בסטנדרטים אבטחיים כמו מערכות אחסון אחרות, ומספק ביסודות תוך שמירה על גמישות וגודל שאילתות.
|