רישום ורישום

1) מדוע אנו זקוקים ליומנים ופרוטוקולים

יומנים הם ”הקופסה השחורה” של הארגון: הם מספקים ראיות לביקורת ולחקירות, מפחיתים את הסיכון המבצעי והרגולטורי, מאפשרים לכם לשחזר את השתלשלות האירועים ולאשר את ביצוע המדיניות (גישה, שמירה, הצפנה, KYC/AML, PCI וכו ').

מטרות:

איתור פעולות (מי/מה/מתי/איפה/למה/מה).
זיהוי אירוע ובלימה (בלש ובקרה מונעת).
בסיס ראיות לרגולטורים/מבקרים (immutability).
SLA/SLO ביצועים ואנליטיקה צייתנית.

2) טקסונומיה של יומנים (כיסוי מינימלי)

גישה וזהויות (IAM/IGA): אימות, היפוך תפקידים, גישת SoD, JIT.
תשתית/ענן/IC: שיחות API, סחיפת תצורה, אירועי KMS/HSM.

יישומים/עסקים - עסקאות, PI/כספים, מחזור חיים שאילתי (DSAR)

אבטחה: IDS/IPS, EDR, DLP/EDRM, WAF, נקודות תורפה/טלאים, אנטי וירוס.
רשת: חומת אש, קרן VPN/אפס, פרוקסי, DNS.
CI/CD/DevSecOps: בונה, depla, SAST/DAST/SCA, סריקה סודית.
נתונים/אנליטיקה: שושלת, גישה לחנות, מיסוך/אנונימיות.
מבצעים: ITSM/כרטיסים, תקריות, שינוי-ניהול, בדיקות DR/BCP.
Vendors/3rd-party: אתרי אינטרנט, פדרציה של אס-אס-או, אירועי סלה.

3) דרישות רגולטוריות (קווים מנחים)

GDPR/ISO 27701: מזעור/מיסוך PI, שמירה על לוח הזמנים, Ligal Hold, DSAR.
SOC 2/ISO 27001: שבילי ביקורת, בקרת גישה, ראיות של ביצוע שליטה.
PCI DSS: כניסה לנתוני מדיה/כרטיס, יושר יומן, סקירה יומית.
AML/KYC: איתור צ 'קים, סינון סנקציה/PEP, פרוטוקולי STR/SAR.

4) ארכיטקטורת התייחסות לכריתת עצים

1. יצרנים: יישומים, ענן, רשת, סוכנים מארחים.
2. אוטובוס/אספנים: לחץ אחורי, ריטרי, TLS mTLS, שכפול.
3. נורמליזציה: פורמט יחיד (JSON/OTEL), העשרה (דייר, משתמש, גיאו, חומרה).

4. כספות:

7-30 ימים, גישה מהירה.
חודשים/שנים, אחסון זול.
ראיות ארכיון (WARM/Object Lock): חוסר תזוזה, קבלות חשיש.
5. שלמות וחתימה: שרשראות חשיש/מרקלי-עץ/טבעות זמן.
6. גישה ואבטחה: RBAC/ABAC, פיצול על ידי תחום שיפוט, גישה מבוססת מקרה.
7. אנליטיקה והתראות: SIEM/SOAR, זיהוי קורלציה, ספרי משחק.
8. קטלוגים ותרשימים: רישום סוג אירוע, ויסות, בדיקות סכימה.

5) מדיניות כקוד (דוגמאות YAML)

שימור והחזקה משפטית

yaml id: LOG-RET-001 title: "Access logs retention"
scope: ["iam. ","app. access"]
retention:
hot_days: 30 cold_days: 365 worm_years: 3 legal_hold: true # when Legal Hold is active, block privacy removal:
pii_mask: ["email","phone","ip"]
review: "annual"

יושרה וחתימה

yaml id: LOG-INT-001 title: "Signature and commercial fixation"
hashing: "SHA-256"
anchor:
cadence: "hourly"
store: "s3://evidence/anchors"
verification:
schedule: "daily"
alert_on_failure: true

6) דרישות איכות רישום

מבנה: JSON/Otel בלבד, ללא טקסט גולמי.
סינכרון זמן: NTP/PTP, בקרת סחיפה; 'חותמת זמן', 'קיבל _ at' entry.
זיהוי קורלציה: "trace _ id", "span _ id'," request _ id', "user _ id' (שם בדוי).
סמנטיקה שדה: מילון נתונים וסכימת מבחן.
לוקליזציה/שפה: שדות - מפתחות אנגליים, ערכים - מאוחדים (enum).
מדיניות נפח וצניחה: איסור ירידה בלתי מבוקרת; תורים/מכסות/דגימת סיכון.
נתונים רגישים: מיסוך/אסימון; איסור שמירת סודות/קלפים לחלוטין.

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

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

8) אי ־ מידתיות וראיות

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

9) בקרת גישה ליומן

RBAC/ABAC: לקרוא/לחפש רק תפקידים נגד ייצוא/שיתוף.
גישה מבוססת תיק: גישה ליומנים רגישים - רק כחלק מחקירה/כרטיס.
סודות/מפתחות: KMS/HSM; סיבוב, פיצול ידע, שליטה כפולה.
ביקורת גישה: מגזין נפרד ”מי קורא אילו יומנים” + מתריע על חריגות.

10) מדידות ורישום SLO

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

11) לוחות מחוונים (סט מינימלי)

בליעה & לאג: נפח/מהירות, פיגור, ירידה, קפיצים חמים.
שלמות & תולעת: מעגן מצב, השלכות, נעילת אובייקט.
אירועים ביטחוניים: התאמות קריטיות, כרטיס MITRE.
גישה ליומנים: מי ומה קרא/ייצא; חריגות.
תצוגת ציות: Status/Legal Hold Statoses, דו "חות ביקורת, יצוא DSAR.
סכימה בריאות: ניתוח שגיאות/סכימה גרסאות, אחוז של סוכני מורשת.

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

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

1. Scheme TLS/MTLS/MTLS 2 Scheme of the/Otel # 3)

2. run-run בהיערכות (אימות של מזימות, מסכות PII) = 5) חיבור בייצור #

3. הוספת ספריות/לוחות מחוונים * * 7) אימות של שמירה/תולעת.

SOP-2: תגובת אירוע (יומנים כראיה)

איתור = = Triage Action-Action # Ligal Hold Ac.Name

Hash Capture and Analytics/Timeline # Report and CAPA # Less Release.

SOP-3: Reg Request/Audit

1. פתח את התיק והמסננים לפי בקשה ID _ 2) ייצוא לפורמט הנדרש

2. אימות חוקי/ציות * 4) סיכום חשיש * 5) שליחה ורישום.

SOP-4: גישת יומן

הסמכה חודשית של בעלים; שאגה אוטומטית של זכויות ”יתומים”; דו "ח סו-די.

13) פורמטים ודוגמאות

דוגמה לאירוע גישה (JSON)

json
{
"ts": "2025-10-31T13:45:12. 345Z",
"env": "prod",
"system": "iam",
"event": "role_grant",
"actor": {"type": "user", "id": "u_9f1...", "tenant": "eu-1"},
"subject": {"type": "user", "id": "u_1ab..."},
"role": "finance_approver",
"reason": "ticket-OPS-1422",
"ip": "0. 0. 0. 0",
"trace_id": "2a4d...",
"pii": {"email": "hash:sha256:..."},
"sign": {"batch_id":"b_20251031_13","merkle_leaf":"..."}
}

כלל גילוי (פסאודו-Rego)

rego deny_access_if_sod_conflict {
input. event == "role_grant"
input. role == "finance_approver"
has_role(input. subject. id, "vendor_onboarder")
}

14) תפקידים ו ־ RACI

תפקיד	אחריות
Log Platform בעלים (A)	אמינות, בטיחות, שימור, תקציבים
הנדסת ציות (ר)	מדיניות-כקוד, מזימות, שימור/אחיזה משפטית
SecOps/DFIR (R)	גילויים, חקירות, ספרי משחק של SOAR
פלטפורמת נתונים (R)	DWH/קטלוגים, יצוא, ראיות-תצוגה
IAM/IGA (C)	בקרת גישה, שימת לב, זון
חוקי/DPO (C)	פרטיות, מיקום רג ', DSAR/Ligal Hold
ביקורת פנימית (אני)	אימות נהלים וחפצים

15) ניהול שרשרת ספקים ואספקה

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

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

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

17) רשימות בדיקה

מתחיל את פונקציית הרישום

[ ] טקסונומיה וביקורתיות.

[ תוכנות השימור והמדיניות של ]/Ligal Hold הכריזו (כקוד).

[ ] TLS/mTLS, אסימונים, סוכני עדכון אוטומטי.

[ ] מסכות PII/אסימונים.

[ ] נעילת תולעת/אובייקט ועגינה מופעלים.

[ ] לוחות מחוונים/התראות/מדדים מבוססים.

[ ] תיקוני גישה ותיקוני SoD מוגדרים.

לפני בקשת ביקורת/Reg

[ ] "חבילת ביקורת" שנאספה: תוכניות, מדיניות, דו "חות יושר, דגימות.

[ ] בודק יומנויות ויומני גישה לתקופה.

[ ] דיסאר/חוקי Hold אישר.

[ ] נוצר סיכום של העלאות ושליחת אישורים.

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

מדריך M0: יומנים מפוזרים, ללא מזימות ועדכונים.
אוסף מרכזי M1: חיפוש בסיסי, טקסונומיה חלקית.
M2 מנוהלת: תוכניות ומדיניות-כקוד, לוחות מחוונים, שמירה/תולעת.
M3 Integrated: OTEL Tracking, SOAR, עוגן/מרקלי, גישה מבוססת מקרה.
M4 מובטח: ”ביקורת מוכנה על ידי כפתור”, זיהוי ניבוי, בקרת שלמות אוטומטית וקבלות משמעותיות מבחינה חוקית.

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

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

KPIs ומדדי ציות

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

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

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

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

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

סך הכל

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

רישום ורישום

יושרה וחתימה

כלל גילוי (פסאודו-Rego)

לפני בקשת ביקורת/Reg

סך הכל

צרו קשר

חיבור מהיר

הווידאו יעודכן בקרוב

אנחנו עמוסים מאוד בפרויקטים כרגע