
# ארכיטקטורת מיקרו‑שירותים של AI הרכיבי לאוטומציה של שאלוני אבטחה בקנה מידה גדול

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

**ארכיטקטורת מיקרו‑שירותים הרכיבית**, המבוססת על מודלים גדולים של שפה (LLM) ו‑Retrieval‑Augmented Generation (RAG), מציעה דרך להגדיל את האוטומציה תוך שמירה על הגמישות והמשילות שהענפים המפוקחים דורשים. במדריך זה נסקור:

* עקרונות העיצוב המרכזיים שמבטיחים שהמערכת **מאובטחת, ניתנת לביקורת וניתנת להרחבה**.  
* יישום רפרנס המודגם ב‑Mermaid.  
* כיצד ניתן לפרוס כל שירות באופן עצמאי על Kubernetes, FaaS ללא שרת או סביבת Edge.  
* המלצות מעשיות לאבטחת נתונים, נראות ושיפור מתמשך.

> **TL;DR:** חלקו את פלטפורמת אוטומציית השאלונים לשירותים קטנים ומוגדרים היטב, גרמו למודלים גדולים של השפה לפעול מאחורי שכבת חישוב חסרת מצב, והשתמשו בצינורות מונחי אירועים כדי לשמור על מקור יחיד של אמת עבור הראיות ושליטה בגרסאות.

---

## 1. למה להרכיב במקום לבנות מונולית ענק?

| גישה מונולית | מיקרו‑שירותים הרכיבי |
|---------------|----------------------|
| קוד יחיד, קושי להרחיב עומסי עבודה ספציפיים (לדוגמה, אינפרנס של LLM). | הרחבה עצמאית – אינפרנס של AI יכול לרוץ על צמתים עם GPU, בעוד שהאחסון נשאר בחנויות אובייקטים חסכוניות. |
| קישוריות הדוקה יוצרת סיכון בעדכונים; באג בממשק המשתמש עלול לגרום לנפילת כל המערכת. | קישוריות רזה באמצעות אירועים אסינכרוניים או API‑HTTP מבודדת תקלות. |
| אינטגרציה מוגבלת לשפה אחת – לרוב נעולה לערימה אחת. | תמיכה רב‑שפתית – כל שירות יכול להיכתב בשפה המתאימה ביותר לתפקידו (Go לאימות, Python לתזמור LLM, Rust לצינורות מהירים). |
| ביקורת וצייתנות הופכות לסיוט כשקבצי הלוג מתערבבים. | חנות אירועים מרכזית + לוג ביקורת בלתי‑שינוי מספקת מסלול ברור וניתן לחיפוש עבור רגולטורים. |

מודל **הרכיבי** מאמץ את הפילוסופיה *„אתה בונה מה שאתה צריך, ומחליף מה שלא צריך”*. הוא תואם את הטבע הדינמי של שאלוני אבטחה, שבהם מופיעים מסגרות שליטה חדשות (למשל, [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) באופן קבוע וצוותים חייבים להסתגל במהירות.

---

## 2. יסודות ארכיטקטוריים מרכזיים

1. **שער API חסר‑מצב** – נקודת הכניסה לממשק המשתמש, מחברים SaaS וכלים חיצוניים. מטפל באימות, אימות בקשות והגבלת קצב.  
2. **מיקרו‑שירותים תחום‑ספציפיים** – כל אחד מקיף הקשר מוגבל:
   * **שירות שאלונים** – מאחסן מטא‑נתוני שאלונים, גרסאות והקצאת משימות.  
   * **שירות ראיות** – מנהל קבצים (מדיניות, צילומי מסך, יומני ביקורת) בחנות אובייקטים בלתי‑מתה.  
   * **שירות תזמור AI** – מחבר פרומפטים, מריץ צינורות RAG ומחזיר טיוטות תשובה.  
   * **שירות גילוי שינוי** – צופה בעדכוני ראיות, ומפעיל הערכה מחודשת של תשובות מושפעות.  
   * **שירות התראות** – שולח אירועים ל‑Slack, Teams או דואר אלקטרוני למשתתפים.  
3. **אופק אירועים (Kafka / Pulsar)** – מבטיח אספקה של לפחות‑פעם אחת של אירועי תחום (לדוגמה, `EvidenceUploaded`, `AnswerDrafted`).  
4. **ערכת נראות** – עקבות OpenTelemetry בין השירותים, מדדי Prometheus, ו‑Loki ל‑logs.  
5. **מנוע מדיניות‑כתקוד** – מודד כללים של ציות (ב‑Rego או OPA) לפני שמסמנים תשובה כ„סופית”.  

כל השירותים מתקשרים באמצעות **gRPC** (לזמן השהייה נמוך) או **REST** (לאינטגרציות חיצוניות). העיצוב מעודד *צינורות טיפשיים, קצות חכמים* – הלוגיקה העסקית בחסרות, בעוד שה‑bus רק מעביר הודעות.

---

## 3. זרימת נתונים – משאלה לתשובה ניתנת לביקורת

להלן תרשים Mermeid הממחיש מחזור בקשה טיפוסי.

```mermaid
flowchart TD
    subgraph UI["ממשק משתמש"]
        UI1["\"Web UI\""] -->|שליחת שאלון| AG["\"שער API\""]
    end

    AG -->|אימות & וידוא| QMS["\"שירות שאלונים\""]
    QMS -->|איסוף תבנית| AIOS["\"שירות תזמור AI\""]
    AIOS -->|שליפה של ראיות רלוונטיות| ES["\"שירות ראיות\""]
    ES -->|אובייקטי ראיות| AIOS
    AIOS -->|ייצור טיוטת תשובה| RAG["\"צינור RAG\""]
    RAG -->|פלט LLM| AIOS
    AIOS -->|אחסון טיוטה| QMS
    QMS -->|הפקת AnswerDrafted| EB["\"אופק אירועים\""]
    EB -->|הפעלת| CDS["\"שירות גילוי שינוי\""]
    CDS -->|הפעלה מחודשת אם ראיות שונו| AIOS
    CDS -->|הפקת AnswerUpdated| EB
    EB -->|הודעה| NS["\"שירות התראות\""]
    NS -->|שליחת Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**רגעים מרכזיים**:

1. **המשתמש מגיש** שאלון חדש או בוחר קיים.  
2. **שער ה‑API** מאמת JWT, בודק מגבלות קצב, ושולח ל‑שירות השאלונים.  
3. השירות **מושך** את תבנית השאלון ומשדר אירוע לשירות תזמור AI.  
4. **תזמור AI** מבצע שלב שליפה – שואל את שירות הראיות על כל המסמכים הרלוונטיים לבקרה (באמצעות חיפוש וקטורי או מילות‑מפתח).  
5. ההקשרים שנשלפו, יחד עם תבנית הפרומפט, מזינים **צינור RAG** (למשל, `openAI/gpt‑4o‑preview`).  
6. טיוטת התשובה נשמרת חזרה בשירות השאלונים, מסומנת כ„בממתנה לביקורת“.  
7. **שירות גילוי שינוי** מצופה על העלאות ראיות חדשות. כשמדיניות מתעדכנת, הוא מפעיל מחדש את צינור RAG לתשובות מושפעות.  
8. מבקרים סופיים מאשרים או עורכים את הטיוטה; עם האישור, **מנוע מדיניות‑כתקוד** בודק שהתגובה עומדת בכללי הציות לפני שמתחייבת ללוג ביקורת בלתי‑מתה.  

---

## 4. פרטי יישום

### 4.1. שער API (Envoy + OIDC)

* **ניתוב** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **אבטחה** – אכיפת scopes (`questionnaire:write`).  
* **הגבלת קצב** – 100 בקשות לדקה לכל שוכר, למניעת רכיבים בלתי צפויים של עלויות LLM.

### 4.2. שירות שאלונים (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* משתמש ב‑**PostgreSQL** למבנה יחסי, וב‑**EventStoreDB** לאירועי תחום.  
* מציע מתודות gRPC: `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. שירות ראיות (Python + FastAPI)

* מאחסן קבצים ב‑**MinIO** או **AWS S3** עם הצפנה ברמת הדלי.  
* מאנדקס תוכן ב‑**Qdrant** (בסיס וקטורי) לחיפוש דמיון.  
* מספק קצה `POST /search` המקבל שאילתה ומחזיר את קובצי ה‑ID המובילים.

### 4.4. שירות תזמור AI (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – משלב חיפוש וקטורי עם *system prompt* שמורה למודל לציין מזהי ראיות.  
* **קאשינג** – שומר תגובות שנוצרו במשך 24 שעה כדי למנוע קריאות LLM מיותרות.

### 4.5. שירות גילוי שינוי (Rust)

* מנוי לאירועים `EvidenceUploaded`.  
* מחשב **hash** של הקובץ החדש, מבצע **diff** מול ראיות קשורות לכל בקרה.  
* אם ה‑diff חורג מסף שנקבע, מפרסם `AnswerRequiresRegen`.

### 4.6. שירות התראות (Node.js)

* מאזין ל‑`AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* מעצב בלוקים ל‑Slack, Adaptive Cards ל‑Teams, או תבניות מייל.  
* תומך ב‑**deduplication** – מתראה רק פעם אחת לכל שינוי לכל שאלון.

---

## 5. אבטחה ומשילות

| נושא | פתרון |
|------|-------|
| **דליפת מידע** – פרומפטים יכולים להכיל טקסט רגיש. | השתמש **באינפרנס LLM on‑prem** (למשל Llama 3.2) מאחורי VPC. טשטש מידע אישי לפני שליחה ל‑API חיצוני. |
| **גישה בלתי‑מאושרת לראיות** | אכוף ACL מדויקות באמצעות מדיניות OPA בשירות הראיות. |
| **ריחוף מודל** – איכות התשובות פוחתת עם הזמן. | קבע **הערכות תקופתיות** מול קורפוס מבחן וחדש את תבניות הפרומפט. |
| **ביקורת** | כל שינוי מצורף ללוג אירועים בלתי‑מתה המאוחסן ב‑WORM S3. |
| **צייתנות GDPR/CCPA** | יישם **זרימת “זכות להתבקש לשכוח”** המוחקת ראיות משתמשים מה‑vector DB ומ‑object store ([GDPR](https://gdpr.eu/)). |
| **ISO 27001** | אמת שהמדיניות של שמירת ראיות, הצפנה, ובקרת גישה עומדים בתקן ISO 27001. |
| **HIPAA / SOC 2** | הרחב את מדיניות OPA כדי לאכוף את ההגנות הנדרשות. |

---

## 6. אסטרטגיות סקלאביליות

1. **Horizontal Pod Autoscaling (HPA)** – מתאם את פודי תזמור AI לפי ניצול GPU (`nvidia.com/gpu`).  
2. **מתקני תור מתפרצים** – השתמש בפיצול partitions ב‑Kafka להפרדת שוכרים עם עומס גבוה.  
3. **הפחתת Cold‑Start** – שמור **פול קונטיינרים** של שרת אינפרנס LLM חמים באמצעות **KEDA** עם סקלר מותאם.  
4. **בקרת עלויות** – יישם **תקציב token‑based** לכל שוכר; הגבל או חיוב על שימוש יתר אוטומטית.

---

## 7. נראות ושיפור מתמשך

* **Tracing מפוזר** – עקבות OpenTelemetry משאלון UI → שער API → תזמור AI → RAG → שירות ראיות.  
* **מדדים** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **איסוף לוגים** – JSON מובנה עם `request_id` מועבר לכל השירותים.  
* **לולאת משוב** – אחרי אישור תשובה, אסף תגובות מבקרים (`review_score`). השתמש במודל reinforcement learning כדי לכוון טמפרטורת פרומפטים או בחירת מקורות ראיות.

---

## 8. מסלול מהדורה שלב‑אחר‑שלב לצוותים קיימים

| שלב | מטרה | פעולות |
|------|------|--------|
| **0 – גילוי** | מיפוי תהליך שאלון קיים. | זיהוי מקורות נתונים, הגדרת טקסונומיית בקרות. |
| **1 – בניית יסודות** | פריסת שער API, אימות, שירותים בסיסיים. | קונטיינריזציה של `questionnaire-service` ו‑`evidence-service`. |
| **2 – הוספת AI** | הרצת RAG על שאלון פיילוט. | שימוש ב‑LLM בחול, אימות טיוטות ידנית. |
| **3 – אוטומציה מבוססת אירועים** | חיבור צינור גילוי שינוי. | הפעלת ריפרש אוטומטי של תשובות עם עדכון ראיות. |
| **4 – חיזוק משילות** | הוספת מדיניות OPA, לוג ביקורת בלתי‑מתה. | מעבר ל‑LLM on‑prem ל‑הפחתת סיכון. |
| **5 – סקלאביליות** | אוטומציה של הרחבת GPU, שליטת עלויות. | פריסת ערכת נראות, קביעת SLOs. |

באופן הדרגתי הצוותים נמנעים מסיכון “קפיצה גדולה” ומציגים תועלת ראשונית (לעיתים **הפחתת 30‑50 %** בזמן טיפול בשאלונים).

---

## 9. חידוד עתידי של הערימה

* **למידה פדראלית** – אימון מתאמים קלים על נתוני כל שוכר ללא העברת ראיות חוץ‑אתר, לשיפור רלוונטיות תשובות תוך שמירת ריבונות הנתונים.  
* **רשת שירות‑אפס (Zero‑Trust Service Mesh)** – יישום **Istio** או **Linkerd** עם mTLS לכל התעבורה הפנימית.  
* **משילות סמנטית** – הרחבת מנוע מדיניות‑כתקוד כדי לאמת גם את **דמיון סמנטי** בין ראיות לטקסט בקרת השאלה.  
* **עקבות גנרטיביות** – שמירת טמפרטורה, top‑p, ותבנית מערכת לכל תשובה לצורך חקירה פורנזית.

---

## 10. סיכום

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

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

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

---

## ראה גם

- [OPA Policy‑as‑Code למיקרו‑שירותים](https://www.openpolicyagent.org/docs/latest/policy-language/)