
# גרף ידע פדרלי Zero Trust לאוטומציה של שאלונים למספר שוכרים

## מבוא

שאלוני אבטחה ותקנה מהווים צוואר bottleneck מתמשך עבור ספקי SaaS. כל ספק חייב לענות על מאות שאלות המתפרסות על פני מסגרות שונות—[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001), [GDPR](https://gdpr.eu/), ותקנים ייחודיים לתעשייה. המאמץ הידני הדרוש לאיתור ראיות, אימות הרלוונטיות שלהן, והתאמת תשובות לכל לקוח מתפתח במהרה למרכז עלויות.

**גרף ידע פדרלי (FKG)**—הצגה מבוזרת ועשירה סכמתית של ראיות, מדיניות ובקרות—מאפשר לפרק את הצוואר bottleneck הזה. כאשר הוא משולב עם **אבטחת Zero‑Trust**, ה‑FKG יכול לשרת בבטחה שוכרים מרובים (יחידות עסקיות שונות, חברות בת, או ארגוני שותפים) מבלי לחשוף נתונים השייכים לשוכר אחר. התוצאה היא **מנוע אוטומציה של שאלונים מרובה שוכרים המונע בינה מלאכותית** שמבצע את הפעולות הבאות:

* **אוגר** ראיות ממקורות שונים (Git, אחסון ענן, CMDBs).  
* **מאכף** מדיניות גישה קפדנית ברמת הצמתים ובקשת הקשתות (Zero‑Trust).  
* **מתזמן** תשובות שנוצרות על‑ידי AI באמצעות Retrieval‑Augmented Generation (RAG) שמושכות רק מהידע המורשה לשוכר.  
* **עוקב** אחרי המקור והאודיטביליות דרך ספרת‑רשומה בלתי‑משתנה.

במאמר זה נצלול לעומק הארכיטקטורה, זרימת הנתונים והצעדים ליישום מערכת כזו על גבי **פלטפורמת Procurize AI**.

---

## 1. מושגים מרכזיים

| מושג | משמעותו לאוטומציה של שאלונים |
|---|---|
| **Zero Trust** | “לעולם אל תסמוך, תמיד אמת”. כל בקשה לגרף מאומתת, מורשית ומוערכת continuamente מול מדיניות. |
| **גרף ידע פדרלי** | רשת של צמתי גרף בלתי‑תלויים (בעלות שוכר) החולקים סכמת‑נתונים משותפת אך שומרים על הנתונים מבודדים פיזית. |
| **RAG (Retrieval‑Augmented Generation)** | יצירת תשובות מונעת‑LLM שמביאה ראיות רלוונטיות מהגרף לפני הרכבת תגובה. |
| **ספרת‑רשומה בלתי‑משתנה** | אחסון רק‑הוספה (כמו עץ Merkle בסגנון בלוקצ׳יין) המתעד כל שינוי בראיות, ומבטיח זיהוי זדון. |

---

## 2. סקירת הארכיטקטורה

להלן תרשים Mermaid ברמת‑הקשר המתאר את המרכיבים המרכזיים ואת האינטראקציות ביניהם.

```mermaid
graph LR
    subgraph Tenant A
        A1[Policy Store] --> A2[Evidence Nodes]
        A2 --> A3[Access Control Engine<br>(Zero Trust)]
    end
    subgraph Tenant B
        B1[Policy Store] --> B2[Evidence Nodes]
        B2 --> B3[Access Control Engine<br>(Zero Trust)]
    end
    subgraph Federated Layer
        A3 <--> FK[Federated Knowledge Graph] <--> B3
        FK --> RAG[Retrieval‑Augmented Generation]
        RAG --> AI[LLM Engine]
        AI --> Resp[Answer Generation Service]
    end
    subgraph Audit Trail
        FK --> Ledger[Immutable Ledger]
        Resp --> Ledger
    end
    User[Questionnaire Request] -->|Auth Token| RAG
    Resp -->|Answer| User
```

**נקודות חשובות מהתרשים**

1. **בידוד שוכרים** – לכל שוכר יש חנות מדיניות וצמתי ראיות משלו, אך מנוע בקרת הגישה מנהל כל בקשה משותפת.  
2. **גרף פדרלי** – צומת `FK` מאגד מטא‑סכמות תוך שמירה על הצפנה ובידוד של הראיות הגולמיות.  
3. **אימות Zero‑Trust** – כל בקשת גישה עוברת דרך מנוע בקרת הגישה, אשר מעריך הקשר (תפקיד, תנאי מכשיר, מטרת הבקשה).  
4. **אינטגרציית AI** – רכיב RAG מושך רק את צמתי הראיות שהשוכר מורשה לראות, ולאחר מכן מעביר אותם ל‑LLM ליצירת תשובה.  
5. **אודיטביליות** – כל שלבי השאיפה וההפקה מתועדים בספרת‑רשומה בלתי‑משתנה עבור מבקרי תקנה.

---

## 3. מודל נתונים

### 3.1 סכמת‑אחד

| ישות | תכונות | דוגמה |
|---|---|---|
| **Policy** | `policy_id`, `framework`, `section`, `control_id`, `text` | `SOC2-CC6.1` |
| **Evidence** | `evidence_id`, `type`, `location`, `checksum`, `tags`, `tenant_id` | `evid-12345`, `log`, `s3://bucket/logs/2024/09/01.log` |
| **Relationship** | `source_id`, `target_id`, `rel_type` | `policy_id -> evidence_id` (evidence_of) |
| **AccessRule** | `entity_id`, `principal`, `action`, `conditions` | `evidence_id`, `user:alice@tenantA.com`, `read`, `device_trust_score > 0.8` |

כל הישויות נשמרות כ‑**גרפי‑מאפיינים** (לדוגמה Neo4j או JanusGraph) ונחשפות דרך API תואם GraphQL.

### 3.2 שפת מדיניות Zero‑Trust

DSL (שפה ספציפית לתחום) קלה לביטוי כללים מדויקים:

``` 
allow(user.email =~ "*@tenantA.com")
  where action == "read"
    and entity.type == "Evidence"
    and entity.tenant_id == "tenantA"
    and device.trust_score > 0.8;
```

חוקים אלו מתורגמים למדיניות זמן‑אמת המיושמת על‑ידי מנוע בקרת הגישה.

---

## 4. זרימת העבודה: משאלתה לתשובה

1. **קביעת שאלון** – סוקר אבטחה מעלה שאלון (PDF, CSV, או API JSON). Procurize מפענח אותו לשאלות בודדות וממפה כל אחת לשולטות (controls) במסגרת רלוונטית.  
2. **מיפוי שולט‑ל‑ראייה** – המערכת שולחת שאילתה ל‑FKG עבור קשתות שמקשרות את השולט לראיות השייכות לשוכר המבקש.  
3. **אימות Zero‑Trust** – לפני שליפת ראיות, מנוע בקרת הגישה מאמת את הקשר של הבקשה (משתמש, מכשיר, מיקום, זמן).  
4. **שילוף ראיות** – ראיות מורשות מוזרמות למודול RAG. מודול RAG מדרג ראיות לפי רלוונטיות בעזרת מודל משולב TF‑IDF + הטמעת‑שכבות (embedding).  
5. **יצירת LLM** – ה‑LLM מקבל את השאלה, את הראיות המשוקלות, ותבנית Prompt שמחייבת טון ודרישות תקנה. דוגמת Prompt:

   ```
   אתה מומחה תקנה עבור {tenant_name}. השב על פריט שאלון האבטחה הבא בעזרת הראיות המסופקות *בלבד*. אל תמציא פרטים.
   שאלה: {question_text}
   ראיות: {evidence_snippet}
   ```

6. **סקירת תשובה ושיתוף פעולה** – התשובה שנוצרה מופיעה בממשק שיתוף בזמן‑אמת של Procurize, שם מומחי תחום יכולים להגיב, לערוך או לאשר.  
7. **תיעוד באודיט** – כל שלב של שליפה, יצירה ועריכה מתווסף לספרת‑רשומה עם חותמת קריפטוגרפית המקשרת לגרסת הראייה המקורית.

---

## 5. הבטחות אבטחה

| אי‑איום | הפחתה |
|---|---|
| **דליפת נתונים בין שוכרים** | בקרת גישה Zero‑Trust מבטיחה התאמת `tenant_id`; כל ההעברות מוצפנות קצה‑אל‑קצה (TLS 1.3 + Mutual TLS). |
| **פריצת אישורים** | JWTים קצרים, attestation של מכשיר, ו‑risk scoring מתמשך (אנליטיקה התנהגותית) מבטלים טוקנים עם זיהוי חריגות. |
| **שינוי ראיות** | ספרת‑רשומה בלתי‑משתנה משתמשת הוכחות Merkle; כל שינוי גורם לאי‑התאמה שמופיעה כהתרעה למבקרים. |
| **הלאה של מודל (Hallucination)** | RAG מגביל את ה‑LLM לראיות שנשלפו; מאמת post‑generation בודק שאין הצהרות ללא תמיכה. |
| **התקפות שרשרת האספקה** | כל תוספות לגרף (plugins, connectors) חתומות ונבדקות דרך צינור CI/CD שמריץ ניתוח סטטי ובדיקות SBOM. |

---

## 6. צעדים ליישום ב‑Procurize

1. **הקמת צמתי גרף לשוכרים**  
   - פרוס מופע Neo4j נפרד לכל שוכר (או השתמש במסד נתונים מרובה‑שוכרים עם Row‑Level Security).  
   - טען מסמכי מדיניות וקבצי ראיות קיימים בעזרת צינורות ה‑Import של Procurize.

2. **הגדרת כללי Zero‑Trust**  
   - השתמש בעורך המדיניות של Procurize לכתיבת חוקים ב‑DSL.  
   - הפעל אינטגרציה עם תנאי מכשיר (MDM, Endpoint Detection) לקבלת ציון סיכון דינמי.

3. **הקמת סנכרון פדרלי**  
   - התקן את שירות המיקרו‑שירות `procurize-fkg-sync`.  
   - קונפיגור אותו לפרסום עדכוני סכמות ל‑Schema Registry משותף תוך שמירה על הצפנת נתונים במנוחה.

4. **אינטגרציית צינור RAG**  
   - פרוס את קונטיינר `procurize-rag` (כולל Vector Store, Elasticsearch ו‑LLM משופר).  
   - חבר את קצה RAG ל‑API GraphQL של FKG.

5. **הפעלה של ספרת‑רשומה בלתי‑משתנה**  
   - הפעל מודול `procurize-ledger` (מבוסס Hyperledger Fabric או לוג Append‑Only קל).  
   - קבע מדיניות שמירת נתונים בהתאם לדרישות תקנה (למשל, שמירת רישום ל‑7 שנים).

6. **הפעלת ממשק שיתוף בזמן‑אמת**  
   - הפעל את תכונת *Real‑Time Collaboration*.  
   - הגדר תפקידים והרשאות תצוגה (Reviewer, Approver, Auditor).

7. **הפעלת פיילוט**  
   - בחר שאלון נפוץ בעל נפח גבוה (לדוגמה SOC 2 Type II) ומדוד:  
     - **זמן תגובה** – השוואה בין זמן ידני לזמן בעזרת AI.  
     - **דיוק** – אחוז תשובות שעוברות ביקורת מבקר.  
     - **חיסכון תפעולי** – שעות FTE שחסכות.  

---

## 7. סיכום היתרונות

| יתרון עסקי | תוצאה טכנית |
|---|---|
| **מהירות** – קיצור זמן מענה לשאלונים מימים לדקות. | RAG שולף ראיות רלוונטיות < 250 ms; LLM מייצר תשובה < 1 s. |
| **הפחתת סיכון** – ביטול טעויות אנוש ודליפות נתונים. | בקרת Zero‑Trust ורשומה בלתי‑משתנה מבטיחות ש‑RA בלבד ייעשה שימוש בראיות מורשות. |
| **קנה מידה** – תמיכה במאות שוכרים ללא שכפול נתונים. | גרף פדרלי מבודד אחסון, סכמת‑משותפת מאפשרת ניתוחים חוצי‑שוכרים. |
| **מוכנות לאודיט** – מסלול הוכחה רלוונטי לרגולטרים. | כל תשובה מקושרת לחתמת קריפטוגרפית של גרסת הראייה המדויקת. |
| **יעילות עלות** – הפחתת ה‑OPEX של תקנות. | האוטומציה חוסכת עד 80 % מהמאמץ הידני, משחררת צוותים לאסטרטגיות. |

---

## 8. שיפורים עתידיים

1. **למידה פדרלית עבור כוונון LLM** – כל שוכר יכול לתרום עדכוני גרדיאנט אנונימיים לשיפור מודל ה‑LLM ללא חשיפת נתונים גולמיים.  
2. **יצירת מדיניות‑קוד (Policy‑as‑Code) דינמי** – יצירת מודולי Terraform או Pulumi שמיישמים את אותן מדיניות Zero‑Trust בתשתית ענן.  
3. **שקף AI מבוסס Explainable** –visualize את נתיב ההיגיון (ראייה → Prompt → תשובה) ישירות בממשק בעזרת דיאגרמות סדרת‑זמן Mermaid.  
4. **אינטגרציית Zero‑Knowledge Proof (ZKP)** – להוכיח למבקרים ששולט מסוים מושלם ללא חשיפת הראייה בפועל.

---

## 9. מסקנה

**גרף ידע פדרלי Zero‑Trust** משנה את עולם ניהול שאלוני האבטחה והתקנה ממקום מקובע, מבודד וידני למקום בטוח, שיתופי ומונע בינה מלאכותית. באמצעות שילוב גרפים מבודדים לפי שוכרים, מדיניות גישה מדויקת, Retrieval‑Augmented Generation, וספרת‑רשומה בלתי‑משתנה, ארגונים יכולים לענות על שאלוני תקנה במהירות, בדיוק ובטחון רגולטורי מלא.

הטמעת הארכיטקטורה הזאת על **פלטפורמת Procurize AI** מנצלת את קווי ההזנה הקיימים, כלי שיתוף הפעולה, והקונסטרוקציות האבטחה – ומאפשרת לצוותים להתמקד בניהול סיכונים אסטרטגי במקום באיסוף נתונים חוזר.

העתיד של תאימות הוא פדרלי, אמין ובינה מלאכותית. **הצטרפו אלינו היום** כדי להישאר צעד אחד לפני בודקי האבטחה, השותפים והרגולטורים.

---

## <span class='highlight-content'>ראה</span> גם

* [Zero Trust Architecture – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)  
* [Federated Learning: Collaborative Machine Learning without Centralized Data](https://arxiv.org/abs/1902.01046)  
* [Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks (Paper)](https://arxiv.org/abs/2005.11401)