mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-25 16:36:21 +02:00
197 lines
9.7 KiB
Markdown
197 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 עומד בסטנדרטים אבטחיים כמו מערכות אחסון אחרות, ומספק ביסודות תוך שמירה על גמישות וגודל שאילתות.
|