
# עוזר ציות AI לשירות עצמי: RAG פוגש בקרת גישה מבוססת‑תפקיד לאוטומציה מאובטחת של שאלונים

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

הכירו את **עוזר הציות של AI לשירות עצמי** (SSAIA). באמצעות שילוב **דור מוסף על‑ידי אחזור (RAG)** עם **בקרת גישה מבוססת‑תפקיד (RBAC)**, SSAIA מאפשר לכל בעל‑עניין—מהנדסי אבטחה, מנהלי מוצר, יועצים משפטיים ואף נציגי מכירות—להשיג את הראייה הנכונה, לייצר תשובות מודעות להקשר, ולפרסם אותן באופן תואם, הכל מנקודת מרכזית שיתופית אחת.

מאמר זה מציג את העמודים האדריכליים, זרימת הנתונים, ההבטחות האבטחתיות והשלבים המעשיים ליישום SSAIA בארגון SaaS מודרני. נציג גם תרשים Mermaid שממחיש את הצינור המלא, ונסיים עם מסקנות קונקרטיות.

---

## 1️⃣ מדוע לשלב RAG ו‑RBAC?

| היבט | דור מוסף על‑ידי אחזור (RAG) | בקרת גישה מבוססת‑תפקיד (RBAC) |
|------|------------------------------|---------------------------------|
| **מטרה מרכזית** | שלוף קטעים רלוונטיים ממאגר ידע ושלב אותם בטקסט שנוצר על‑ידי AI. | ודא שמשתמשים רואים או עורכים רק נתונים שהם מורשים להם. |
| **יתרון לשאלונים** | מבטיח שהתשובות מבוססות על ראיות קימות ומאומתות (מסמכי מדיניות, יומני ביקורת, תוצאות בדיקות). | מונע חשיפת שגויה של בקרות סודיות או ראיות למשתמשים בלתי מורשים. |
| **השפעת ציות** | תומך בתשובות מבוססות ראיות הנדרשות על‑ידי [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001), [GDPR](https://gdpr.eu/), וכו'. | תואם לרגולציות פרטיות שדורשות גישה ברמת הצורך המינימלי (least‑privilege). |
| **סינרגיה** | RAG מספק את *מה*, RBAC מנהל את *מי* ו‑*איך* התוכן משמש. | יחד הם מספקים **זרימת יצירת תשובות בטוחה, ניתנת לביקורת ועשירה בהקשר**. |

השילוב מסיר את שני הכאבים המרכזיים:

1. **ראיות מיושנות או בלתי רלוונטיות** – RAG תמיד מושך את הקטע העדכני ביותר על‑בסיס דמיון וקטורי וסינוני מטא‑נתונים.  
2. **שגיאת אנוש בחשיפת מידע** – RBAC מוודא שלמשל נציג מכירות ניתן לגשת רק למקטעי מדיניות ציבוריים, בעוד שהנדסאי אבטחה יכול לצפות ולצרף דוחות פנימיים של מבחני חדירה.

---

## 2️⃣ סקירה ארכיטקטונית

להלן תרשים Mermaid ברמה גבוהה המתאר את הרכיבים המרכזיים וזרימת הנתונים של עוזר הציות של AI לשירות עצמי.

```mermaid
flowchart TD
    subgraph UserLayer["User Interaction Layer"]
        UI[ "Web UI / Slack Bot" ]
        UI -->|Auth Request| Auth[ "Identity Provider (OIDC)" ]
    end

    subgraph AccessControl["RBAC Engine"]
        Auth -->|Issue JWT| JWT[ "Signed Token" ]
        JWT -->|Validate| RBAC[ "Policy Decision Point\n(PDP)" ]
        RBAC -->|Allow/Deny| Guard[ "Policy Enforcement Point\n(PEP)" ]
    end

    subgraph Retrieval["RAG Retrieval Engine"]
        Guard -->|Query| VectorDB[ "Vector Store\n(FAISS / Pinecone)" ]
        Guard -->|Metadata Filter| MetaDB[ "Metadata DB\n(Postgres)" ]
        VectorDB -->|TopK Docs| Docs[ "Relevant Document Chunks" ]
    end

    subgraph Generation["LLM Generation Service"]
        Docs -->|Context| LLM[ "Large Language Model\n(Claude‑3, GPT‑4o)" ]
        LLM -->|Answer| Draft[ "Draft Answer" ]
    end

    subgraph Auditing["Audit & Versioning"]
        Draft -->|Log| AuditLog[ "Immutable Log\n(ChronicleDB)" ]
        Draft -->|Store| Answers[ "Answer Store\n(Encrypted S3)" ]
    end

    UI -->|Submit Questionnaire| Query[ "Questionnaire Prompt" ]
    Query --> Guard
    Guard --> Retrieval
    Retrieval --> Generation
    Generation --> Auditing
    Auditing -->|Render| UI
```

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

* ספק הזהות (IdP) מאמת משתמשים ומונפק JWT עם טענות תפקיד.  
* **נקודת החלטת המדיניות (PDP)** מעריך את הטענות כנגד מטריצת הרשאות (למשל *קריאת מדיניות ציבורית*, *צירוף ראייה פנימית*).  
* **נקודת אכיפת המדיניות (PEP)** מגנה כל בקשה למנוע אחזור, ומבטיחה שרק ראיות מורשות יוחזרו.  
* **VectorDB** מאחסן הטבעות של כל מסמכי הציות (מדיניות, דוחות ביקורת, יומני ניסויים). **MetaDB** שומר מאפיינים מובנים כגון רמת סודיות, תאריך ביקורת אחרון ובעלים.  
* **LLM** מקבל קטעי מסמכי מקור ומוצר של טיוטה שניתנת למעקב למקורות.  
* **AuditLog** תופס כל שאלה, משתמש ותשובה, מה שמאפשר בחינה פורנסית מלאה.

---

## 3️⃣ מודל נתונים: ראייה כידע מובנה

הצלחה של SSAIA תלויה במאגר ידע מבנה היטב. להלן סכמת JSON מומלצת לכל פריט ראייה:

```json
{
  "id": "evidence-12345",
  "title": "דוח מבחן חדירה רבעוני – Q2 2025",
  "type": "Report",
  "confidentiality": "internal",
  "tags": ["penetration-test", "network", "critical"],
  "owner": "security-team@example.com",
  "created_at": "2025-06-15T08:30:00Z",
  "last_updated": "2025-09-20T12:45:00Z",
  "version": "v2.1",
  "file_uri": "s3://compliance-evidence/pt-q2-2025.pdf",
  "embedding": [0.12, -0.04, ...],
  "metadata": {
    "risk_score": 8,
    "controls_covered": ["A.12.5", "A.13.2"],
    "audit_status": "approved"
  }
}
```

* **confidentiality** מניע מסנני RBAC – רק משתמשים עם `role: security-engineer` רשאים לקבל ראיות `internal`.  
* **embedding** מאפשר חיפוש סמנטי ב‑VectorDB.  
* **metadata** מאפשר חיפוש מובנה (למשל “צג רק ראיות מאושרות ל‑ISO 27001, סיכון ≥ 7”).

---

## 4️⃣ זרימת RAG

1. **המשתמש מגיש פריט שאלון** – לדוגמה: “תארו את מנגנוני ההצפנה למידע במצב מנוחה.”  
2. **שומר ה‑RBAC בודק** את תפקיד המשתמש. אם מדובר במנהל מוצר עם גישה ציבורית בלבד, החיפוש מוגבל ל‑`confidentiality = public`.  
3. **חיפוש וקטורי** משיב על top‑k (בדרך כלל 5‑7) קטעים רלוונטיים.  
4. **סינוני מטא‑נתונים** מטהּ את התוצאות (למשל רק מסמכים עם `audit_status = approved`).  
5. **ה‑LLM מקבל** את הפרומפט:
   ```
   Question: Describe your data‑at‑rest encryption mechanisms.
   Context:
   1. [Chunk from Policy A – encryption algorithm details]
   2. [Chunk from Architecture Diagram – key management flow]
   3. [...]
   Provide a concise, compliance‑ready answer. Cite sources using IDs.
   ```
6. **הדור** מניב טיוטה עם ציטוטים פנימיים: `Our platform encrypts data at rest using AES‑256‑GCM (Evidence ID: evidence‑9876). Key rotation occurs every 90 days (Evidence ID: evidence‑12345).`  
7. **סקירה אנושית** (אופציונלי) – המשתמש יכול לערוך ולאשר. כל שינוי מתועד כגרסה חדשה.  
8. **התשובה נשמרת** בחנות תשובות מוצפנת, ורשומה בלתי‑ניתנת לשינוי נכתבת ביומן האודיט.

---

## 5️⃣ גרנולציה של RBAC

| תפקיד | הרשאות | שימוש טיפוסי |
|-------|--------|--------------|
| **מהנדס אבטחה** | קריאה/כתיבה על כל ראייה, יצירת תשובות, אישור טיוטות | חקירת בקרות פנימיות, צירוף דוחות מבחני חדירה |
| **מנהל מוצר** | קריאת מדיניות ציבורית, יצירת תשובות (מוגבל לראיות ציבוריות) | ניסוח הצהרות ציות ידידותיות לשיווק |
| **יועץ משפטי** | קריאת כל הראיות, הוספת הערות משפטיות | הבטחת התאמה לשפה רגולטורית |
| **נציג מכירות** | קריאת תשובות ציבוריות בלבד, בקשת טיוטות חדשות | מענה מהיר ל‑RFP של לקוחות פוטנציאליים |
| **מבקר** | קריאת כל הראיות, ללא עריכה | ביצוע הערכות צד שלישי |

ההרשאות המפורטות נכתבות במדיניות OPA (Open Policy Agent), המאפשרת הערכה דינאמית על‑בסס תכונות בקשה כגון *תג שאלה* או *ציון סיכון ראייה*. דוגמת מדיניות (JSON):

```json
{
  "allow": true,
  "input": {
    "role": "product-manager",
    "evidence_confidentiality": "public",
    "question_tags": ["encryption", "privacy"]
  },
  "output": {
    "reason": "Access granted: role matches confidentiality level."
  }
}
```

---

## 6️⃣ שרשרת ביקורת ויתרונות ציות

ביקורת חייבת לענות על שלוש שאלות:

1. **מי גישה לראייה?** – תביעות JWT מתועדות ב‑`AuditLog`.  
2. **איזו ראייה שומשה?** – ציטוטים (`Evidence ID`) משולבים בתשובה ונשמרים יחד עם הטיוטה.  
3. **מתי נוצרה התשובה?** – חותמות זמן בלתי‑ניתנות לשינוי (ISO 8601) נשמרות במאגר לוג בלתי‑מתנקה (למשל Amazon QLDB או רשת בלוקצ’יין).

יומני האודיט ניתנים לייצוא בפורמט CSV תואם SOC 2 או לצריכה על‑ידי API GraphQL לשילוב בלוחות ציות חיצוניים.

---

## 7️⃣ מפת דרכים ליישום

| שלב | משימות | משך זמן משוער |
|------|----------|----------------|
| **1. יסודות** | הקמת IdP (Okta), הגדרת מטריצת RBAC, פריסת VectorDB ו‑Postgres | 2 שבועות |
| **2. ייבוא מאגר ידע** | בניית צינור ETL למיפוי PDFs, markdown, spreadsheets → הטבעות + מטא‑נתונים | 3 שבועות |
| **3. שירות RAG** | פריסת LLM (Claude‑3) מאחורי נקודת קצה פרטית, בניית תבניות פרומפט | 2 שבועות |
| **4. UI ושילובים** | פיתוח Web UI, Bot ל‑Slack, חיבור ל‑Jira/ServiceNow | 4 שבועות |
| **5. אודיט ודיווח** | יישום לוג בלתי‑מתנקה, גרסאות, מחוללי ייצוא | 2 שבועות |
| **6. פיילוט ומשוב** | הרצת פיילוט עם צוות האבטחה, מדידת KPI (זמן תגובה, שיעור שגיאות) | 4 שבועות |
| **7. פריסה ארגונית** | הרחבת תפקידים, הדרכת צוותי מכירות ומוצר, פרסום מסמכי עבודה | מתמשך |
| **מדדי הצלחה** | זמן ממוצע לתשובה, שיעור שימוש חוזר בראיות, מספר ממצאי ביקורת | – |

#### מדדי ביצוע (KPIs) למעקב
* **זמן ממוצע לתשובה** – יעד < 5 דקות.  
* **שיעור שימוש חוזר בראיות** – אחוז תשובות המצטיינות בציטוטי ראייה קיימים (מטרה > 80%).  
* **שיעור תקריות ציות** – מספר מקרים של טעויות בשאלונים (מטרה 0).  

---

## 8️⃣ דוגמה מהעולם האמיתי: הפחתת זמן תגובה משבועות לדקות

*חברת X* התאימה ממוצע של **30 יום** לתגובות על שאלוני ISO 27001. לאחר הטמעת SSAIA:

| מדד | לפני SSAIA | אחרי SSAIA |
|------|------------|------------|
| זמן תגובה ממוצע | 72 שעה | 4 דקות |
| שגיאות העתק‑הדבקה ידניות | 12 בחודש | 0 |
| חוסר התאמה בגרסאות ראייה | 8 אירועים | 0 |
| ציון שביעות רצון מבקר | 3.2 / 5 | 4.8 / 5 |

חישוב ROI הצביע על **חיסכון שנתי של $350 k** מתחומי עבודה מוקצרים וסגירת עסקאות מהירה יותר.

---

## 9️⃣ שיקולי אבטחה והקשחת המערכת

1. **רשת Zero‑Trust** – פריסת כל השירותים ב‑VPC פרטי, אימוץ mTLS.  
2. **הצפנה במנוחה** – SSE‑KMS לדלי S3, הצפנה ברמת עמודות ל‑PostgreSQL.  
3. **הפחתת Prompt Injection** – ניקוי קלט של המשתמש, הגבלת אורך טוקן, הצמדה של פרומפטים קבועים.  
4. **הגבלת קצב** – מניעת ניצול מנוגד של נקודת קצה ה‑LLM באמצעות API Gateway.  
5. **ניטור מתמשך** – הפעלת CloudTrail, הקמת גילוי אנומליות על דפוסי אימות.

---

## 🔟 שיפורים עתידיים

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

---

## 📚 מסקנות

* **אוטומציה בטוחה וניתנת לביקורת** אפשרית על‑ידי שילוב כוחו של RAG עם משמעת RBAC.  
* **מאגר ידע מובנה** – עם הטבעות, מטא‑נתונים וגרסאות – הוא הבסיס.  
* **פיקוח אנושי** נשאר קריטי; העוזר צריך *להציע* ולא *לקבוע* תשובות סופיות.  
* **פריסה מבוססת מדדים** מבטיחה ROI ותפוקת ציות גבוהה.

בהשקעה בעוזר הציות של AI לשירות עצמי, חברות SaaS יוכלו להפוך מכשול עבודה ידנית לביסוס אסטרטגי – מתן תשובות מהירות, מדויקות ובטוחות לשאלוני אבטחה תוך שמירה על רמת האבטחה הגבוהה ביותר.

---

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

- [דור מוסף על‑ידי אחזור: הגבול הבא של AI ארגוני](https://arxiv.org/abs/2005.11401)  
- [Open Policy Agent (OPA) – מדיניות‑כקוד לבקרת RBAC](https://www.openpolicyagent.org)  
- [ארכיטקטורת Zero‑Trust ליישומים ענן‑נטיביים](https://www.nist.gov/publications/zero-trust-architecture)