ביקורת ויומנים בלתי ניתנים לשינוי

ביקורת ויומנים בלתי ניתנים לשינוי

1) למה אתה צריך את זה

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

2) מודל איום ושליטה על מטרות

• עריכה/מחיקה מכוונת של אירועים על ידי מישהו מבפנים.
• החלפת זמן/מקור (הילוך חוזר/תאריך אחורי).
• ”שקט” כריתת עצים על צומת.
• אובדן חלק מהיומן בזמן תאונות/נדידות.
• אוסף מח "ש מוגזם וחוסר פרטיות.

1. יושר: הוכח על ידי הגנה מפני שינויים/מחיקות.

2. שלמות: סגירה של זרימות מפתח (מישור בקרה, מישור נתונים, גישה, כסף).

3. דיוק בזמן: זמן מתרבה, מסונכרן.

4. נגישות: קריאה וחיפוש בתוך SLO.

5. פרטיות: מינימום PII, אסימון/הצפנה, חוקיות השימוש.

3) טקסונומיה ועדיפויות אירועים

• מישור בקרה: אימות/אישור, שינויי תצורה, פעולות מפתח (KMS), ניהול סודי, שינויי מדיניות.
• מישור נתונים: גישה לאובייקטים/רשומות/צ 'קים/תשלומים; לקרוא/ליצור/למחוק.
• אדמין ו-DevOps: SSH/console, CI/CD, שינויי תשתית/IC, הסלמת זכויות.
• מוצר: עסקאות, חיוב, פעולות לקוחות.
• מערכת/רשת: גרעין/סוכנים/פרוקסי/מאזנים, ברוקרים, מסדי נתונים.
• אבטחה: IDS/IPS/EDR, WAF, אנטי-DDOS, אנטי-פראוד, DLP.

עבור כל כיתה, אנו מתקנים: ביקורתיות, מזימה, שדות חובה, חיי מדף, דרישות לחוסר יכולת.

4) שדות ותבנית דרושים

זיהוי קורלציה הם ”trace _ id',” span _ id', ”request _ id',” actor _ id' (משתמש/שירות), ”terant _ id',” resource _ id'.
A&A: שיטת אימות, תפקידים/מדיניות בעת הפעולה.
זמן: RFC3339/UTC, אלפיות שנייה/ננו ־ שניות; מקור הסינכרון.
פעולה ותוצאה: סוג של פעולה, מטרה, סטטוס, מספר אובייקטים מושפעים.
רשומות HMAC מקומיות, מספר רצף, hash-prev.
סכמה: JSON עם מודל יציב (לדוגמה, מתאים למילוני אירועים נפוצים).

סודות, מפתחות, אסימונים, פאן מלא, סיסמאות, מפתחות פרטיים. PII - רק כשצריך, עם מיסוך/אסימון.

5) זמן וסינכרון

מקור זמן: לפחות שני מקורות עצמאיים (NTP/PTP) + ניטור הטיה.
חתימות זמן קריטיות: השתמש בחותמת זמן אמינה (TSA) או שירות אטימת זמן פנימי עבור צרור אירועים.
חוקים: אין אזורי זמן מקומיים, UTC בלבד; רישום וקיזוז/איכות זמן.

6) ארכיטקטורת זרם יומן

סוכנים * Buffer # Transport # Landing # Hash Chain/Signature # Cold/Archive # Index to Search.

אוסף בצומת: סוכני אור (daemonset/sidecar) עם חוצץ על הדיסק (לחץ אחורי).
תעבורה: ערוץ מוגן (TLS/MTLS), משלוח מובטח (לפחות פעם אחת), בליעת אידמפוטנט.
אזור נחיתה: אחסון אובייקט בצורה ”גולמית” (חבורות לפי תאריך/דייר/סוג).
אינדקס: מנוע חיפוש/אנליטיקה לשאילתות מקוונות (שכבה חמה).
ארכיון (תולעת): דליים/קלטות ללא שינוי עם מדיניות שימור והחזקה משפטית.
עוגן/חותם: ”אטימה” תקופתית של חבילות של שרשראות חשיש (ראה להלן).

7) אי ־ יכולת קריפטוגרפית

7. 1 שרשראות של חשיש (Append-only)

כל רשומה מכילה: ”hash _ curr = H (רשומה)”, ”hash _ prev” מהרשומה הקודמת, ”seq”. כל עריכה שוברת את השרשרת.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 חתימה של חבילות וחותמת זמן

כל N שניות/MB אנו יוצרים בלוק: Merkle root of all 'hash _ curr'.
אנו חותמים על הבלוק עם מפתח הביקורת (מאוחסן באופן קבוע ב ־ KMS/HSM).
הוסף חותמת זמן של משרד התחבורה ופרסם את ”יומן השקיפות”.
אופציונלי: לעגן את חשיש השורש באופן תקופתי למרחב חיצוני (לדוגמה, כתב עת עצמאי או מחסן ציבורי בלתי ניתן לשינוי).

7. 3 ניהול מפתחות ביקורת

מפתחות חתימה - ב ־ KMS/HSM, סיבוב לפי לוח הזמנים, גישה לרב ־ פקטים, שליטה כפולה לייצוא.
שלילת מפתח = סניף אמון חדש; חתימות ישנות נותרות מאומתות.

8) מדיניות שימור ותולעת

WORM/imutability: כולל מכלים/דליים בלתי ניתנים לשינוי עם מדיניות Resurretation and Legal Hold עבור כיתות P0/P1.
ורסיונינג: מופעל; מחיקה - רק עבור נהלים עם עיכוב (איסור על טיהור מיידי).
שימור: חם (7-30 יום), חם (3-6 חודשים), קר/ארכיון (1-7 שנים או יותר - תלוי ברגולטור/חוזה).
ריבוי דיירים: הפרד בין שמות/חשבונות/מפתחות הצפנה לדייר; יומן דיווח גישה.

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

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

10) גישה, תפקידים וביקורת של הביקורת עצמה

מפיקים קוראים בכל יום.
קריאה בלבד מתולעת; שינוי במדיניות השמירה, בתפקידים נפרדים ובהליך באישור.
כל פעולות הקריאה/ייצוא מחוברות לרישום משני (meta audit).
ייצוא לחקירה/ציות - בצורה מוצפנת עם ספריית חסימת חשיש ושרשרת אמון.

11) יכולת תצפית ו ־ SLO

מדדים: קצב הזרקה, פיגור לאינדקס,% אבודים/חוזרים, שבריר זמן לא מסונכרן, שגיאות חתימה/עיגון, מילוי חוצץ.
SLO: IM 99. 9% מהאירועים העבירו את X השניות האינדקס החם; 0 ”חורים” בלתי מוסברים ברצפים; 100% מהבלוקים חתומים וזמן חתום.
התראות: הזרקת הפסקה> N דקות, גידול לא תקף-חשיש, סטיית שרשרת, אי ספיקת חתימה/חותמת זמן, קיזוז זמן מעבר לסף.

12) בדיקות ואימות

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

• 13) פעולה ונהלים

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

14) מתכונים קטנים

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• בקרה/דאטה מטוס P0: חם 30 יום * חם 6 חודשים לארכיון 7 שנים (WORM).
• DevOps: חם 14 ימים * חם 3 חודשים לארכיון 1.
• סקיוריטי מסמן: 90 ימים חמים (לחקירות), ואז 1-3 שנים.

15) שגיאות תכופות

"יומנים הם טקסט ללא סכימה. "ללא מזימה, אין שלמות וחיפוש דטרמיניסטיים; נדרשים JSON קנוני ושדות קבועים.
אין קורלציה. היעדר "עקבות _ id' מפרק חקירות.
זמן מקומי. UTC בלבד וקיזוז שליטה.
כותב לכרכים ניתנים לשינוי. ללא תולעת, כל חוסר יכולת הוא בדיוני.
אל תרשום קריאות. חשוב לקרוא נתונים רגישים כדי לתקן לא פחות מכתיבה.
סודות ביומנים. תפעיל חומרי חיטוי לפני שתשלח, ”רשימות אדומות” של תבניות.
מפתח אחד לכל דבר. מפתחות חתימה והצפנה - בנפרד, עם תפקיד וסיבוב.

16) ציות ורגולציה

דרישות לחיי מדף/אי-תזוזה תלויות בתחום (מימון, תשלום, תקשורת וכו ').
Provability: זמינות של פרוטוקולי WORM/reservation, דו "חות אימות מעגל, רישומי גישה ליומן, הליכי החזקה וייצוא חוקיים.

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

לפני המכירה

[ טקסונומיה ] אירוע וסכימה אושרו (שדות נדרשים).

[ סוכנים ], חוצצים, תחבורה מוגנת,

[ ] כולל: שרשראות חשיש, חתימת בלוק, חותמת זמן, יומן שקיפות.

[ ] אחסון תולעת/מצגת מופעל; מבחן לחוסר היכולת לשכתב/למחוק.

[ ] מסכות/אסימונים שדות רגישים.

[ ] סנכרון זמן וניטור קיזוז.

[ ] תוכנית סיבוב ואחסון מפתחות ביקורת בקמ "ס/HSM.

מבצע

[ ] אימות שבועי של שרשראות ובלוקים (+ דיווח).

[ ] הפרת מעגל/חתימה שגיאה/זמן התראות Offset.

[ ] בדיקות החלפה תקופתיות של צוות אדום/מחיקה.

[ ] סקירה רגילה של החזרות ועלויות.

18) FAQ

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

Q: מה לגבי הזכות למחוק נתונים?
A: Design crypto-lausure (הסרת מפתח) עבור שדות/צדדים, שמירה על התקשורת בלתי ניתנת לשינוי ורישומים.

קיו: האם אני צריך מפתח נפרד כדי לחתום על הבלוקים?
או, כן. מקשי חתימת בלוקים נפרדים ממפתחות הצפנה. חנות ב-KMS/HSM, עם סיבוב וביקורת.

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

• ”בהצפנת מנוחה”
• ”בהצפנת מעבר”
• ‏ ”ניהול סודי” ‏
• ”ניהול מפתח וסבב”
• ‏ ”לחתום ולאמת בקשות” ‏