מעקב אחר פעילות שביל הביקורת

1) מהו שביל ביקורת חשבונות ומדוע הוא נחוץ

שביל ביקורת הוא שרשרת של אירועים אפשריים על פעולות עם מערכות ונתונים: מי, מה, איפה, מתי ובאיזה אופן עשה את זה,

• ראיות לרגולטורים ולמבקרים.
• חקירות ותגובה (ציר זמן של אירועים, סיבה שורשית).
• אישור של ביצוע מדיניות (SoD, שימור, מחיקה/אנונימיות).
• פיקוח על צדדים שלישיים ותת-מעבדים.

2) היקף (הרשמה מינימלית)

זהויות וגישה (IAM/IGA): התחברות/התחברות, הוצאה/ביטול של תפקידים, החרפה של הרשאות, גישה ל-JIT.
נתונים ופרטיות: קריאה/שינוי שדות PI, העלאות, מיסוך, מחיקה/TTL, Hold משפטי.
מימון/עסקאות: יצירה/עדכון/ביטול, הגבלות, היפוך, פעולות נגד הונאה.
תשתית/ענן: שינויי תצורה, סודות, מפתחות, פעולות KMS/HSM.
SDLC/DevSecOps: בונה, פורס, להתאים שערים, למשוך למעלה ספרייה (SCA), סריקה סודית.
מבצעים/ITSM: תקריות, שינויים, שחרורים, הסלמה, בדיקות DR/BCP.
Webhooks/3rd-party: שיחות נכנסות/יוצאות, חתימה, תוצאות אימות.

3) מודל אירוע (פורמט קנוני)

json
{
"ts": "2025-11-01T11:23:45.678Z",
"env": "prod",
"tenant": "eu-1",
"system": "iam",
"domain": "access",
"actor": {"type":"user","id":"u_123","source":"sso","ip":"0.0.0.0"},
"subject": {"type":"role","id":"finance_approver"},
"action": "grant",
"reason": "ITSM-12345",
"result": "success",
"severity": "info",
"labels": {"jurisdiction":"EEA","pii":"no","sod_check":"passed"},
"trace": {"request_id":"r_abc","trace_id":"t_456","span_id":"s_789"},
"integrity": {"batch":"b_20251101_11","merkle_leaf":"..."}
}

שדות נדרשים הם 't, שחקן, פעולה, נושא, תוצאה'.
מומלץ: ”סיבה (כרטיס/הזמנה), trace_id/request_id, דייר, תחום שיפוט”.

4) עקרונות איכות וסמנטיקה

מובנה לחלוטין: JSON/Otel בלבד; מילון אחד של שדות וקודי פעולה.
סינכרון זמן: NTP/PTP, חנות 'ts' ו-' קבל _ at '.
Correlation הוא ”trace _ id'/” request _ id' עבור איתור מקצה לקצה.
אידמפוטנטיות של רשומות: מפתחות דטרמיניסטיים של חבורות, הגנה מפני שכפולים.
נורמליזציה של שחקן: אדם/שירות/בוט/ספק עם מקור אימות.

5) ארכיטקטורת שביל ביקורת

1. יצרנים: יישומים, פלטפורמות, עננים, סוכנים מארחים.
2. אספנים/אוטובוס: משלוח אמין (TLS/mTLS, retrai, back-tress, dedup).
3. העשרה/נורמליזציה: תוכניות אחידות, מיפוי תפקידים/תחום שיפוט.

• חם (חיפוש/אנליטיקה) - 30-90 ימים.
• 1-7 שנים, תלוי בנורמות.
• נעילת אובייקט/תולעת - חוסר יכולת ראיה.
• 5. שלמות: חתימה של חבורות, שרשראות של חשיש, עגינה יומית (שורשי מרקל).
• 6. גישה: RBAC/ABAC, גישה מבוססת מקרה.
• 7. אנליטיקה/התראות: SIEM/SOAR, מתאם, כללי התנהגות.
• 8. קטלוג אירועים: סכימה גרסה, התייחסות לפעילות, סכימה בדיקות במודיעה.

6) אי ־ מידתיות ומשמעות משפטית

מנעול תולעת/אובייקט: למנוע מחיקה/כתיבה מחדש למשך זמן התביעה.
קיבעון קריפטוגרפי: חבורות SHA-256, עצי מרקל, עוגנים חיצוניים (לפי לוח הזמנים).
שרשרת משמורת: רישום של גישה ליומן (מי וכאשר נקרא/יצא), קבלות חשיש בדו "חות.
אימות רגיל: משימות שלמות; התראה במהלך דסינכרוניזציה.

7) פרטיות ומזעור

מזעור PI: רישום חשיש/אסימונים, שדות מסכות (דוא "ל/טלפון/IP).
הקשר במקום תוכן: ללכוד ”פעולה בפועל”, לא מטען מלא.
תחום שיפוט וגבולות: אחסון על ידי מדינה (תושבות נתונים), סימנים להעברה חוצה גבולות.
DSAR ודה-פרסון: תוויות לחיפוש מהיר, ייצוא עם מיסוך.

8) בקרת גישה (מי רואה עקבות ביקורת)

אנליסט רואה מינימום; יצוא לפי יישום/מקרה בלבד.
גישה מבוססת מקרה: חקירה/ביקורת = גישה זמנית עם כריתת עצים.
הפרדה בין חובות: איסור על עריכת עקבות של המערכת.
הסמכה חודשית: הסמכה מחדש של זכויות קריאה/ייצוא.

9) חזרה, אחיזה משפטית והסרה

לוחות זמנים אחסון: לפי תחומים ונורמות (לדוגמה, גישה - שנה 1, עסקאות כספיות - 5-7 שנים).
הקפאה מיידית של אירועים רלוונטיים, עדיפות על טי-טי-אל.
אישור מחיקה: דיווח עם סיכום חשיש של חבורות שנמחקו.
שימור מקצה לקצה עבור צד שלישי: אחסון חוזי/גישה/מחיקת SLA.

10) לוחות מחוונים ודיווחים

כיסוי: אילו מערכות/תחומי שיפוט מכוסים; חללים.
שלמות/תולעת - מצב של עיגון ובדיקות שלמות.
גישה לשביל הביקורת: מי צופה/מה מייצא; חריגות.
שינוי בפעילות ההנהלה: פעולות רגישות (הרשאות, מפתחות, סודות).
עדשת פרטיות: אירועים מעל PI, DSAR/מחיקות, Hold משפטי.
תצוגת ציות: מוכנות ”על ידי כפתור” לביקורת/בקשות.

11) מדדים ו ־ SLO

בליעה Lag p95 על 60 שניות

קצב ירידה = 0 (התראה> 0. 001%).
סכימה ציות 99. 5%.
אישור שלמות = 100% של המחאות.
סיקור מערכות קריטיות ב-98%.
סקירת גישה: הערכות 100% זכאות חודשית.
קצב דליפת PII: 0 קריטי בעקבות ביקורת.

12) SOP (נהלים סטנדרטיים)

SOP-1: חיבור למקור

1. scheme TLS/MTLS, keys _ 4) dresidation of schemes/masks) # 5) fress to production # 6) הכללה בספריות ולוחות מחוונים.

SOP-2: תגובה לבקשה רגולטורית/ביקורת

פתח את המקרה * מסנן אירועים על ידי אובייקט/תקופה * יצוא עם קבלה של חשיש * סקירה משפטית _ תשלח דרך הארכיון הרשמי של התעלה * לתולעת.

SOP-3: תקרית (DFIR)

Freeze (Legal Hold) # trace_id time line _ expact extress (פעולות מפתח)> דיווח עם ראיות * CAPA ואיתור עדכונים.

SOP-4: מחיקת TTL

זהה חבורות מוכנות למחיקה * בדיקת החסר Legal Hold # למחוק את Late # ליצור דו "ח מחיקה עם סיכום חשיש.

13) דוגמאות חוק/שאילתה

חיפוש הסלמה קריטית של הרשאות (פסאודו SQL)

sql
SELECT ts, actor.id, subject.id
FROM audit_events
WHERE domain='access' AND action='grant'
AND subject.id IN ('admin','db_root','kms_manager')
AND reason NOT LIKE 'ITSM-%'
AND ts BETWEEN @from AND @to;

חוק סו-די (פסאודו-רגו)

rego deny_if_sod_conflict {
input.domain == "access"
input.action == "grant"
input.subject.id == "payment_approver"
has_role(input.actor.id, "payment_creator")
}

מסנן על DSAR (JSONPath)

$.events[?(@.domain=='privacy' && @.action in ['dsar_open','dsar_close','delete'])]

14) מיפוי ליחסים (סימני ספסל)

GDPR (ART 5, 30, 32, 33, 34): מזעור, חשבונות פעולה, אבטחת עיבוד, הודעת אירוע; DSAR/מחיקה/Hold משפטי.
ISO/IEC 27001/27701: A.12/A. 18 - יומן, ניהול ראיות, פרטיות.
SOC 2 (CC6/CC7/CC8): בקרת גישה, ניטור, טיפול באירוע, שלמות יומן.
PCI DSS (10. איתור פעולות על נתוני מפות ומערכות, סקירה יומית, שלמות יומן.

15) אינטגרציה עם פונקציות אחרות

ציות לקוד/CCM: מבחני מדיניות מבוצעים ונרשמים; התראות - לסטיות.
RBA (ביקורת סיכון): דגימות וטפסים חוזרים לפי נתוני שביל ביקורת.
סיכון ספק: ביקורת וזכויות יצוא בחוזים; שימור מראה עם קבלנים.
Policy Lifecycle - שינויים בדרישות * דור אוטומטי של כללים ושדות חדשים.

16) תרופות אנטי ־ פטריות

”טקסט חופשי” ללא תרשימים וסמנטיקה.
חוסר יכולת לקשר אירוע עם כרטיס/סיבה.
גישה ”לכל” ללא מקרה ולקרוא רישום.
חוסר בתולעת/חתימה - ראיות שנויות במחלוקת.
ערבוב אזורי זמן ומתוך סינכרון 'tt'/' קבל _ at'.
רישום ”מלא” סודות PI/במקום חשיש/מסכות.

17) מודל בגרות (M0-M4)

מדריך M0: יומנים מפוזרים, כיסוי לא שלם, ללא שמירה.
אוסף מרכזי M1: חיפוש בסיסי, פורמט מאוחד חלקית.
M2 מנוהל: ספריית אירועים, סכימות כקוד, שימור/Ligal Hold, RBAC.
M3 מובטח: WORM + Extreme, גישה מבוססת תיק, KPI/SLO, ראיה אוטומטית.
הבטחה רציפה M4: עקבות, זיהוי חיזוי, ”ביקורת מוכנה על ידי כפתור”.

18) מאמרים הקשורים לוויקי

רישום ורישום

ניטור ציות רציף (CCM)

KPIs ומדדי ציות

אחיזה חוקית והקפאת נתונים

מדיניות ואופן חיים של נהלים

תקשורת של פתרונות ציות

ניהול שינוי מדיניות ציות

בדיקת נאותות וסיכוני מיקור חוץ

תוצאות

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