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

layout	title	parent
default	תמיכה ביסודות משתמשים/מערכות ב-Neo4j	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 אך מתעלם מהם

בעיית אבטחה נוכחית

# כל משתמש יכול לשאול כל נתונים - אין ביסודות
MATCH (src:Node)-[rel:Rel]->(dest:Node)
RETURN src.uri, rel.uri, dest.uri

פתרון מוצע: סינון מבוסס תכונות (מומלץ)

סקירה כללית

הוסף תכונות user ו-collection לכל הצמתים והקשרים, ואז לסנן את כל הפעולות לפי התכונות הללו. גישה זו מספקת ביסודות חזקות תוך שמירה על גמישות שאילתות והתאמה לגרסאות קודמות.

שינויים במודל נתונים

מבנה צומת משופר

// ישויות צומת
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"
})

מבנה קשר משופר

// קשרים עם תכונות משתמש/מערכת
CREATE (src)-[:Rel {
  uri: "http://example.com/predicate1",
  user: "john_doe",
  collection: "production_v1"
}]->(dest)

אינדקסים מעודכנים

// אינדקסים משולבים לסינון יעיל
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. בדיקות ביצוע

אסטרטגיית בדיקה

בדיקות יחידה

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 עומד בסטנדרטים אבטחיים כמו מערכות אחסון אחרות, ומספק ביסודות תוך שמירה על גמישות וגודל שאילתות.