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

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

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

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

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

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

מודל הרכיבי מאמץ את הפילוסופיה „אתה בונה מה שאתה צריך, ומחליף מה שלא צריך”. הוא תואם את הטבע הדינמי של שאלוני אבטחה, שבהם מופיעים מסגרות שליטה חדשות (למשל, ISO 27001 Rev 2) באופן קבוע וצוותים חייבים להסתגל במהירות.

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 הממחיש מחזור בקשה טיפוסי.

  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)

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)

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. אבטחה ומשילות

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. מסלול מהדורה שלב‑אחר‑שלב לצוותים קיימים

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

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

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

10. סיכום

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

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

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

ראה גם

• OPA Policy‑as‑Code למיקרו‑שירותים