
# דירוג רעננות הוכחה בזמן אמת מבוססת בינה מלאכותית לטפסי שאלון אבטחה

## הקדמה

שאלוני אבטחה הם קו המ front‑line של האמון בין ספקי SaaS ללקוחותיהם. על ספקים לצרף קטעי מדיניות, דוחות ביקורת, צילומי מסך של תצורות או יומני מבחנים כ**הוכחה** כדי להוכיח ציות. בעוד שהפקת ההוכחה כבר מאוטומטת בארגונים רבים, נותר נקודת עיוור קריטית: **כמה רעננה ההוכחה**?

קובץ PDF שעודכן לפני חצי שנה עשוי עדיין להיות מצורף לשאלון המתשאל היום, מה שמ expose את הספק לממצאי ביקורת ופוגע באמון הלקוח. בדיקות רעננות ידניות הן מאמצתיות ושגיאות. הפתרון הוא לאפשר ל**בינה מלאכותית גנרטיבית** ול**Generative Retrieval‑Augmented Generation (RAG)** להעריך, לדרג ולשלוח התראות על רעננות ההוכחה באופן רציף.

מאמר זה מפרט תכנון מלא, מוכן לייצור, של **מערכת דירוג רעננות הוכחה בזמן אמת (EFSE) מונעת AI** אשר:

1. **קולטת** כל פרט הוכחה ברגע שהוא נחת במאגר.  
2. **מחושבת** על‑ידי ניקוד רעננות תוך שימוש בחותמות זמן, גילוי שינוי סמנטי והערכת רלוונטיות מבוססת מודל שפה גדול (LLM).  
3. **מפעילה** התראות כאשר ניקוד נופל מתחת לספים שהוגדרו במדיניות.  
4. **מציגה** מגמות בלוח מחוונים המשולב עם כלי ציות קיימים (כגון Procurize, ServiceNow, JIRA).

בסיום המאמר יהיה לכם מפת דרכים ברורה ליישם את EFSE, לשפר את זמן המשוב לשאלונים ולהציג ציות מתמשך לבוחנים.

---

## למה רעננות הוכחה חשובה

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

לוחות ציות מסורתיים מציגים **מה** ההוכחות קיימות, ולא **כמה חדשות** הן. EFSE גשר את הפער הזה.

---

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

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

```mermaid
graph LR
    subgraph Ingestion Layer
        A["Document Store<br/>(S3, Git, SharePoint)"] --> B[Metadata Extractor]
        B --> C[Event Bus<br/>(Kafka)]
    end

    subgraph Scoring Engine
        C --> D[Freshness Scorer]
        D --> E[Score Store<br/>(PostgreSQL)]
    end

    subgraph Alerting Service
        D --> F[Threshold Evaluator]
        F --> G[Notification Hub<br/>(Slack, Email, PagerDuty)]
    end

    subgraph Dashboard
        E --> H[Visualization UI<br/(React, Grafana)]
        G --> H
    end

    style Ingestion Layer fill:#f9f9f9,stroke:#333,stroke-width:1px
    style Scoring Engine fill:#e8f5e9,stroke:#333,stroke-width:1px
    style Alerting Service fill:#fff3e0,stroke:#333,stroke-width:1px
    style Dashboard fill:#e3f2fd,stroke:#333,stroke-width:1px
```

*כל תוויות הצמתים מוקיפות במרכאות כפולות כדי לעמוד בדרישות תחביר של Mermaid.*

### רכיבים מרכזיים

1. **Document Store** – מסד מרכזי לכל קבצי ההוכחה (PDF, DOCX, YAML, צילומי מסך).  
2. **Metadata Extractor** – מפענח חותמות זמן, תגים מובנים בגרסה, ומבצע OCR לשינויים בטקסט.  
3. **Event Bus** – מפרסם אירועי *EvidenceAdded* ו‑*EvidenceUpdated* לצרכנים במטה‑שרשרת.  
4. **Freshness Scorer** – מודל היברידי המשלים ההוריסטיקות הקבועות (גיל, שינוי גרסה) עם זיהוי שינוי סמנטי מבוסס LLM.  
5. **Score Store** – שומר ניקוד לכל פריט יחד עם היסטוריית מגמות.  
6. **Threshold Evaluator** – מיישם ספים מדיניות (למשל ≥ 0.8) ומייצר התראות.  
7. **Notification Hub** – שולח הודעות בזמן אמת לערוצי Slack, מייל או כלי תגובה לאירועים.  
8. **Visualization UI** – מפות חום אינטראקטיביות, גרפים סדרת‑זמן וטבלאות drill‑down למבקרים ולמנהלי הציות.

---

## אלגוריתם דירוג בפירוט

ניקוד הרעננות *S* ∈ [0, 1] מחושב כסכום משוקלל:

```
S = w1·Tnorm + w2·Vnorm + w3·Snorm
```

| סימון | משמעות | חישוב |
|--------|---------|-------------|
| **Tnorm** | גורם גיל מנורמל | `Tnorm = 1 - min(age_days / max_age, 1)` |
| **Vnorm** | דמיון גרסה | מרחק Levenshtein בין מחרוזות הגרסה הנוכחית לקודמת, מושקל ל‑[0, 1] |
| **Snorm** | שינוי סמנטי | דמיון שמיוצר על‑ידי LLM בין הצילום הטקסטואלי העדכני לצילום המאושר האחרון |

קונפיגורציית משקלים טיפוסית: `w1=0.4, w2=0.2, w3=0.4`.

**זיהוי שינוי סמנטי עם LLM**  
1. חילוץ טקסט גולמי באמצעות OCR (לתמונות) או פרסרים טבעיים.  
2. שליחת פקודה ל‑LLM (למשל Claude‑3.5, GPT‑4o):

   ```
   Compare the two policy excerpts below. Provide a similarity score between 0 and 1 where 1 means identical meaning.
   ---
   Excerpt A: <previous approved version>
   Excerpt B: <current version>
   ```

3. ה‑LLM מחזיר מספר שמוגדר כ‑*Snorm*.

**ספים**  
- **קריטי**: S < 0.5 → נדרש תיקון מיידי.  
- **אזהרה**: 0.5 ≤ S < 0.75 → לתזמן עדכון בתוך 30 יום.  
- **בריא**: S ≥ 0.75 → אין צורך בפעולה.

---

## אינטגרציה עם פלטפורמות ציות קיימות

| פלטפורמה | נקודת אינטגרציה | יתרון |
|----------|-------------------|---------|
| **Procurize** | ווב‑הוק מ‑EFSE לעדכון מטא‑דטה של ההוכחה בממשק השאלון. | תו “רעננות” אוטומטי ליד כל קובץ מצורף. |
| **ServiceNow** | יצירת משימות אירוע כאשר ניקוד חודר לסף האזהרה. | תיוק חלק למערך תיקון. |
| **JIRA** | יצירת סיפורי “עדכון הוכחה” מקושרים לשאלון הפגוע. | זרימת עבודה גלויה לבעלי המוצר. |
| **Confluence** | הטמעת מקרו מפה חמה קריאה ישירה מ‑Score Store. | בסיס ידע מרכזי מציג את מצב הציות בזמן אמת. |

כל האינטגרציות נשענות על **REST endpoints** של EFSE (`/evidence/{id}/score`, `/alerts`, `/metrics`). ה‑API תואם OpenAPI 3.1 ומאפשר יצירת SDKים אוטומטית ב‑Python, Go ו‑TypeScript.

---

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

| שלב | אבני דרך | זמן משוער |
|-------|------------|----------------|
| **1. יסודות** | פריסת Document Store, Event Bus, ו‑Metadata Extractor. | 2 שבועות |
| **2. אבטיפוס מנוע דירוג** | בניית לוגיקת Tnorm/Vnorm; אינטגרציה עם LLM דרך Azure OpenAI. | 3 שבועות |
| **3. שירות התראה ולוח מחוונים** | יישום Threshold Evaluator, Notification Hub, ומפת חום Grafana. | 2 שבועות |
| **4. חיבורים לשירותים** | פיתוח ווב‑הוקים ל‑Procurize, ServiceNow, JIRA. | 1 שבוע |
| **5. בדיקות וכיול** | מבחן עומס עם 10 k פריטי הוכחה, כוונון משקלים, הוספת CI/CD. | 2 שבועות |
| **6. השקה** | פיילוט בקו מוצר אחד, איסוף משוב, הפצה ארגונית. | 1 שבוע |

**שיקולי CI/CD**  
- שימוש ב‑**GitOps** (ArgoCD) לגרסאות של מודלים וספים מדיניות.  
- שמירת מפתחות API של LLM ב‑**HashiCorp Vault**.  
- בדיקות רגרסיה אוטומטיות שמוודאות שמסמך ידוע‑טוב לא יורד תחת סף הבריאות לאחר שינוי קוד.

---

## שיטות עבודה מומלצות

1. **תיוג גרסאות בהוכחות** – עודדו מחברים לשלב כותרת `Version: X.Y.Z` בכל מסמך.  
2. **הגדרת Max Age לפי תקן** – ISO 27001 אפשר 12 חודשים, SOC 2 6 חודשים; שמרו ערכים בתצורת טבלה.  
3. **אימון מחודש של LLM** – טיוב מודל על השפה הפנימית של המדיניות להפחתת סיכון לזיוף.  
4. **עקבות audit** – רשמו כל אירוע דירוג; שמרו לפחות 2 שנים לצרכי ביקורת.  
5. **בקרת אדם במעגל** – כאשר ניקוד נכנס לטווח קריטי, דרשו אישור ממומחה ציות לפני סגירת ההתראה באופן אוטומטי.

---

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

- **תמיכה רב‑שפתית** – הרחבת צינור OCR ו‑LLM לשפות נוספות (למשל, גרמנית עבור נספחים GDPR).  
- **רשתות גרפים (GNN) לקונטקסט** – מודל יחסים בין פריטי הוכחה (PDF שמפנה ללוג מבחן) לחישוב **ניקוד רעננות קלאסטר**.  
- **חיזוי רעננות** – יישום מודלים של סדרת‑זמן (Prophet, ARIMA) לחיזוי מתי הוכחה תתיישן ולתזמן עדכונים מראש.  
- **אימות Zero‑Knowledge** – עבור הוכחות סודיות מאוד, יצירת הוכחות zk‑SNARK שמוודאות שהניקוד חושב כראוי ללא חשיפת המסמך.

---

## סיכום

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

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

ה‑EFSE מתבצעת לפי מפת דרכים מודולרית וניתנת לשילוב עם כלי ציות קיימים כגון Procurize, ServiceNow ו‑JIRA. בעזרת שילוב של הוריסטיקות קבועות וניתוח סמנטי מבוסס LLM, המערכת מספקת ניקוד מהימן ומעצימה צוותי אבטחה להישאר לפני שינוי המדיניות.

התחילו למדוד רעננות עוד היום והפכו את מאגר ההוכחות שלכם מנכס מסוכן לנכס אסטרטגי.