מדיניות רישום ואחסון אירועים
1) מטרה והיקף
המטרה: לספק רישום חוקי, מאובטח ויעיל/אחסון אירועים, לתמוך בחקירות AML/KYC, ביקורת, דיווח ועמידות פלטפורמה.
סיקור: כל הסביבות (prod/stage/dev), יישומים ומיקרו-רווחים, אנטי הונאה ותשלומים, CCM/סנקציות, RG, תשתיות (K8s/Cloud/CDN/WAF), שותפים/ספקים (PSP, KYC, אנטי-הונאה, אנליטיקה).
2) כיתות יומן והרכב שדה מינימלי
1. אבטחה (SecOps/Identity): אימות, אותות ATO/אנטי-הונאה, תפקידים ושינויי מדיניות, גישה ל-PII.
"שחקן", "נושא", "פעולה", "תוצאה", "ip", "התקן", "geo", "סיכון _ ציון", "trace _ id'.
2. עסקאות/תשלומים: הפקדות/משיכות, תרמילים, חוקים נגד הונאה.
"tx _ id', 'כמות', 'מטבע', 'psp', 'status', 'rule _ hits ', 'vision _ ref'.
3. CCM/סנקציות/PEP: חניכות, תוצאות, ספק/גרסה של רשימות, החלטות (חיובי אמיתי/שגוי).
4. מבצעים/SRE: מדדי SLO, שחרור, אוטוקאט, תקריות, התראות.
5. שיווק/CRM (אופציונלי): אירועי opt-in/unsubscribe, קמפיינים (ללא PII נוסף).
6. ביקורת גישה לנתונים: קריאת/ייצוא/מחיקת סטים מ ־ PII; אזכורים לתיקי DSAR/AML.
3) תקופות שימור ורמות שימור (חם/חם/קר/תולעת)
4) סינכרון זמן ויכולת מעקב
בסיס זמן יחיד: NTP/Chrony, Store 'ts _ utc' (UTC) + 'ts _ local' (לדיווח).
קורלציה: כלול את ”trace _ id'/” span _ id' ואת” source _ service ”בכל יומן.
אזורי זמן: דיווחים/ייצוא - עם אינדיקציה מפורשת של TZ.
5) גישה, הצפנה והפרדה בין חובות
הצפנה: במנוחה (KMS; סיבוב מפתח לפחות 90 יום למרחבים סודיים) ובמעבר (TLS 1. 2+).
RBAC/ABAC: גישה מינימלית; תפקידים נפרדים לקריאת יומני ביקורת.
פריצה: גישה זמנית עם אישור רב פקטור וסגירה אוטומטית.
סגמנט: יומנים עם PII/finance - מדדים נפרדים/טנקים, מפתחות נפרדים.
יומנים של גישה ליומנים: כל הקריאות/יצוא נרשמות ובוחנות.
6) פרטיות ומיסוך
אסור בהחלט לרשום: סיסמאות, אסימונים, פאן (במלואו), CVV/CVC, מספרי מסמכים מלאים, מידע ביומטרי ”גולמי”.
מיסוך ברירת מחדל: דוא "ל:" p @ domain ". com '; □ טלפון ”+ XX123”; IBAN/PAN = אסימונים/4 ספרות אחרונות.
שינוי: החלף את "user _ id' עם אסימון חזק ביומנים אנליטיים/שיווקיים.
עוגיות/SDK: רישום רק מזהים טכניים עם הסכמה (CMP) וללא הדבקה עם PII, אם אין בסיס חוקי.
תאימות DSAR: לאחסן התייחסות למקור הסט והיכולת לחלץ/למחוק באופן סלקטיבי.
7) איכות נתונים ותבנית
סכימה כקוד: תוכנות JSON מרכזיות/פרוטוקולי אירוע, ויסות.
אימות: not null/ranges/regexes; דחיית אירועים - לתור הסגר עם תווית סיבה.
שכפול: by '(trace_id, ts, source) "; רמות אידמפוטנטיות למגשים מחדש.
העשרה: דטרמיניסטית לחלוטין; מאפייני Geo/התקן - המציין את הגרסה של מילונים.
8) ארכיטקטורה ואחסון
חם: אחסון אינדקס/אשכולות חיפוש (חקירות מבצעיות, SIEM).
חם: אחסון אובייקטים עם גישה מואצת/התקררות.
קור: אחסון אובייקט/ארכיון (כיתת קרחון/אנלוגי), בקשות באמצעות אצווה.
WORM/Legal Hold: לא ניתן לשמר דליים/מדיניות ו ”החזקות חוקיות” ללא הסרה/שינוי לפני תפוגה.
9) מחיקה, אחיזה ארכיונית ומשפטית (SOP)
1. לוח הזמנים היומי מחשב את המועמדים בזמן.
2. בדוק תקריות פעילות/חקירות/החזקה משפטית.
3. הארכיון - היגר אל התולעת הקרה לפי הצורך.
4. מחק: טיהור בטוח + רישום (”dataset”, ”range”, ”player”, ”hash _ before/after”).
5. דווח לציות/נתונים בסוף המנה.
10) ציות לאינטגרציה (GDPR/AML/PCI/ISO)
GDPR: מזעור, מטרות/בסיסים ב ־ ROPA; זמינות DSAR; הודעות של 72 שעות מסתמכות על יומני ביקורת.
AML: אחסון יומנים של בדיקות סנקציות, קישורי STR/SAR; תנאים של 5-10 שנים (על ידי מדינה).
PCI DSS (אם ישים): בטל נתוני אימות רגישים; הפרדה גזעית של יומני היקפי תשלום.
ISO 27001/ISMS: רישום מדיניות כמסמך חובה; ביקורת ומבחנים שנתית.
11) ספקים ומעבדים משנה
DPA/SLA: רשום תקופות שימור, גאוגרפיה, TOMS, פורמט ייצוא, WORM/Legal Hold, זמן תגובה לאירוע.
שאלון, יומני גישה סלקטיבית, בדיקת תקרית/הודעה.
Offointing: מחיקה/חזרה של יומנים, פעולת סגירה, אישור של השמדת עותקים/גיבויים.
12) מעקב והתראות
KRIs: אימות כשל צמיחה> X%, בליעה> Y lags, אי ספיקת ETL <99%, ניסיונות גישה מחוץ לחלון.
KPI: כיסוי רישום של 95% מהשירותים; MTTD של כשל צינור סגר 15 דקות; אחוז הבקשות ל ”הוט” שהושלם 2 שניות הוא 95%.
כרטיסים אוטומטיים בניגוד לשמירה/גישה/מיסוך.
13) ראסי
14) ייצוא ודיווח
רשימות לבנות של מקבלים ופורמטים (CSV/Parquet/JSON) עם דפרסונליזציה כברירת מחדל.
חתימה/חשיש של כל ארכיון, רישום הורדה.
דוחות רגולטוריים: סיכומים של סנקציות/PEP, KYC, התראות AML, גישה ל-PII, תקריות.
15) דרישות לפיתוח ותפעול
יומן משמעות: פעולות מפתח/החלטות, לא כל התנועה.
תקני רמה: ”DEBUG” אינו מורשה בדרבן; מידע על אירועים עסקיים; להזהיר/טעות על חריגות.
redaction-middleware: שכבה אחת של מיסוך בשערים/SDKs.
סביבות מבחן: נתונים סינתטיים או פסאודונימיזציה; לנטרל העתקים של יומני עבודה בדב.
שחרור: רשימת רישום/מיסוך ב ־ CAB; דגלי תכונה לכריתת עצים מתקדמים.
16) רשימות בדיקה
16. ניטור שבועי 1
[ ] סנכרון זמן ללא היסחפות[ ] שגיאות בליעה <סף[ ] אין פיל/סודות ישירים בדגימות[ ] הגישה/תפקידים הם מעודכנים[ ] הצלחת ETL - 99%16. 2 ביקורת חודשית
[ ] בדוק שימור/הסרות[ ] בחירה אקראית של יצוא (חתימה/חשיש ok)[ ביקורות ] ונדור (יומני גישה, תקריות)[ ] עדכון סכמות/ספרי עיון16. 3 לפני מחיקה/ארכיון
[ ] אין אחיזה/תקרית משפטית[ ] ייצוא חפצים קשורים (אם נדרש)[ ] פרוטוקול הרס נוצר17) תקריות כריתת עצים (מהלכים מהירים)
PII/Secrets נמצאו ביומנים. PII/Secrets Name Production Rules.
כישלון של הצינור של יומנים = = לעבור חציצה, התראה SRE, בליעה מחדש, לאחר המוות.
18) מימוש מפת דרכים
שבועות 1-2: מלאי של מקורות, הסכם על תאריכים, מטריצת שימור בסיסית, תכנית-כקוד.
שבועות 3-4: מיסוך/שינוי יישום, הפרדת אינדקס עם PII, זיהוי NTP/עקבות, תולעת עבור סטים קריטיים.
חודש 2: אוטומציה של מחיקה/ארכיון, KRIs/KPIs והתראות, ספרי משחק SOAR.
חודש 3 +: ביקורות ספקים, אופטימיזציה עלויות (טירינג), סקירות רבעוניות של מועדים ודרישות של תחום שיפוט.
TL; DR
מדיניות רישום מאוחדת = מטריצת תזמון ברורה + מיסוך והצפנה + RBAC וביקורת גישה + WORM/Legal Hold + איכות וסנכרון זמן. זה מפחית את הסיכון (GDPR/AML/PCI), מפחית את עלויות האחסון ומאיץ את החקירות.