# מפת חום סיכון ציות בזמן אמת מבוססת AI עם כריית תהליכים עסקיים

## מבוא

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

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

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

## למה זמן אמת חשוב

1. **קצב רגולטורי** – תקנות חדשות (למשל [GDPR](https://gdpr.eu/)-ePrivacy, [CCPA](https://oag.ca.gov/privacy/ccpa), [EU AI Act Compliance](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)) מתפרסמות מדי שבוע. גילוי מאוחר עלול לגרום לקנסות ולנזק למוניטין.  
2. **נוף תהליכים דינמי** – צינורות CI/CD, תזמור מיקרו‑שירותים, ופונקציות ללא שרת משתנים יומיומית. מפת ציות סטטית מפספסת את השינויים המהירים האלה.  
3. **תיעדוף סיכון** – מפת חום שמתעדכנת כל כמה שניות מאפשרת למנתחי האבטחה להתמקד בנקודות החמות ביותר, ובכך מקצרת את זמן הטיפול הממוצע (MTTR).  

## כריית תהליכים עסקיים בקיצור

כריית תהליכים מחלץ **רשומות אירועים** ממקורות כגון:

- רשומות אפליקציה (למשל שער API, שירותי אימות)  
- מסילות ביקורת ענן (AWS CloudTrail, Azure Activity Log)  
- אירועי צינורות CI/CD (GitHub Actions, Jenkins)  

הרשומות מומרות ל‑**גרף מכוון** שבו צמתים מייצגים פעילויות (למשל “כניסת משתמש”, “ייצוא נתונים”) וקשתות קולטות את התדירות והסדר של המעברים. מודל התהליך המתקבל משקף את המציאות *כפי שהיא*, ולא את העיצוב *כפי שהוא אמור להיות*.

כאשר משולב עם מטא‑נתוני ציות (למשל אילו פעילויות כפופות ל‑[ISO 27001](https://www.iso.org/standard/27001) A.12.4), גרף התהליך הופך ל‑**מפת תהליך מודעת ציות**.

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

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

```mermaid
graph LR
    A[Event Sources] -->|Stream| B[Kafka Ingestion Layer]
    B --> C[Schema Validation & Enrichment]
    C --> D[Process Mining Engine]
    D --> E[Compliance Knowledge Graph]
    E --> F[AI Anomaly & Causal Engine]
    F --> G[Risk Scoring Service]
    G --> H[Real‑Time Heatmap UI]
    subgraph AI Models
        F
    end
    subgraph Storage
        D
        E
        G
    end
```

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

| רכיב | תפקיד |
|-----------|------|
| **שכבת הקליטה של Kafka** | מבטיחה זרימה בעלת השהייה נמוכה ועמידות לתקלות של רשומות אירועים. |
| **מנוע כריית תהליכים** | מייצר גרף תהליך חי באמצעות אלגוריתם *Inductive Miner*. |
| **גרף ידע ציות** | מאחסן מיפויי מדיניות‑לפעילות, מגבלות רגולטוריות, ונתוני סטייה במדיניות בגרסאות. |
| **מנוע אנומליות והסקת סיבתיות AI** | מזהה מעברים חריגים (למשל עלייה פתאומית בייצוא נתונים) ומסיק קשרים סיבתיים לשינויים במדיניות. |
| **שירות דירוג סיכון** | מחשב ציון סיכון משולב לכל צומת באמצעות גורמים משוקללים (סטייה במדיניות, חומרת האנומליה, השפעה עסקית). |
| **ממשק UI של מפת חום בזמן אמת** | Front‑end מבוסס React + D3, מציג מטריצה מקודדת בצבעים שבה העוצמה משקפת את רמת הסיכון. |

## קליטת נתונים ונרמול

1. **לכידת אירועים** – פרסו סוכנים קלים על כל מיקרו‑שירות כדי לדחוף אירועי JSON לנושאי Kafka.  
2. **רישום סכמות** – אכפו סכמת אחידה (timestamp, user_id, activity, resource_id, outcome).  
3. **העשרה** – הוסיפו נתונים קונטקסטואליים: תפקיד משתמש, סיווג נתונים, ובקרות ציות משויכות.  

הנרמול קריטי מכיוון שמודלי AI מצפים לווקטורים תכונה עקביים. שדות חסרים מוחזרים באמצעות **k‑nearest neighbor** על בסיס רשומות היסטוריות.

## מודלי AI בפעולה

### 1. זיהוי אנומליות

אנו משתמשים ב‑**Variational Auto‑Encoder (VAE)** המאומן על גרף תהליך נורמלי. המקודד מכווץ רצפי פעילות למרחב חבוי; המפענח משחזר אותם. שגיאת שיחזור מעל סף דינמי מסמנת אנומליה.

### 2. הסקת סיבתיות

באמצעות **DoWhy** ו‑**Structural Causal Models (SCM)**, אנו מעריכים את ההסתברות שהאנומליה שנזוהתה נגרמה מעדכון מדיניות אחרון. גרף הסיבתיות כולל:

- `PolicyVersion` → `AllowedActivities`  
- `AllowedActivities` → `ProcessTransitions`  
- `ProcessTransitions` → `RiskScore`

### 3. דירוג סיכון משולב

`RiskScore = w₁·PolicyDriftScore + w₂·AnomalySeverity + w₃·BusinessImpact`

המשקלים (`w₁, w₂, w₃`) מכוונים באמצעות **אופטימיזציה בייזיאנית** על נתוני אירועים היסטוריים.

## ויזואליזציית מפת החום

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

- רמת סיכון נוכחית (נמוכה/בינונית/גבוהה)  
- גרסת המדיניות האחרונה שהוחלה  
- פרטי האנומליה (זמן, משתמש מושפע)  

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

## מקרי שימוש בעולם האמיתי

| מקרה שימוש | תועלת |
|------------|--------|
| **גילוי מהיר של סטייה במדיניות** | מדגיש מיידית תהליכים שהתרחקו מהגרסה העדכנית של המדיניות, ומזמין תיקון מיידי. |
| **ביקורות ממוקדות בתהליך** | מבקרי ציות יכולים להתמקד בתאים בעלי סיכון, מה שמפחית את משך הביקורת עד 40 %. |
| **דירוג סיכון ספקים רציף** | כאשר API של ספק חלק מהגרף, תרומתו לסיכון משתקפת במפת החום, מאפשרת ניהול ספקים דינמי. |
| **תעדוף תגובה לאירועים** | צוותי האבטחה מקבלים התראות רק לתאים שעוברים סף גבוה, מצמצמים עייפות מהתראות. |

## שלבי יישום

1. **הגדרת מיפוי ציות** – קטלגו את כל הבקרות הרגולטוריות ומיפו אותן לפעילויות תהליך.  
2. **פריסת אוספי אירועים** – השתמשו בסוכנים קוד פתוח (למשל OpenTelemetry) לשידור רשומות ל‑Kafka.  
3. **הקמת כריית תהליכים** – התקינו **pm4py** (קוד פתוח) והגדרו עדכונים אינקרמנטליים.  
4. **בניית גרף ידע** – נצלו Neo4j לאחסון יחסי מדיניות‑פעילות והיסטוריית גרסאות.  
5. **אימון מודלי AI** – הריצו צינורות VAE והסקת סיבתיות על נתונים היסטוריים; שמרו מודלים במאגר מודלים (MLflow).  
6. **פיתוח UI של מפת חום** – השתמשו ב‑React, D3, ו‑WebSocket לעדכונים בזמן אמת.  
7. **אינטגרציית התראות** – קשרו ספי סיכון ל‑Slack, PagerDuty או פלטפורמות SIEM.  

## אתגרים ושיטות עבודה מומלצות

| אתגר | פתרון |
|------|--------|
| **נפח נתונים** | חלקו נושאי Kafka לפי שירות; השתמשו באגרגציות מבוססות חלון במנוע הכרייה. |
| **הסטת מודלים** | קבעו אימון מחודש רבעוני; עקבו אחרי התפלגות שגיאת השיחזור. |
| **פיצוץ גרסאות מדיניות** | שמרו רק שינויי דלתא; ארכיבו גרסאות ישנות באחסון קר. |
| **קבלת משתמשים** | ספקו טיפים קונטקסטואליים והדרכות; הטמיעו את מפת החום בפורטלים קיימים של ציות. |

## כיוונים עתידיים

- **AI גנרטיבי להצעת מדיניות** – השתמשו במודלים גדולים (LLM) כדי להמליץ על התאמות מדיניות על בסיס אנומליות בתהליך.  
- **כריית תהליכים בקצה** – פרסו מכרייונים קלים על צמתים קצה לקבלת השהייה אפסית בסביבות מבוזרות.  
- **הוכחות אפס‑ידע לביקורת** – אפשרו הוכחה קריפטוגרפית שהתהליך עומד במדיניות ללא חשיפת רשומות גולמיות.  

## סיכום

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