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

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

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

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

מה שורה אחת מספרת לכם

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

שמירה: ניתנת להארכה בלבד, מעצם הבנייה

מתחת ליומן עצמו, אם יש לכם הרשאת קריאה, יושבת טבלת מדיניות שמירה — שורה אחת לכל סוג נתונים, מ-Public ועד SpecialCategory — כל אחת עם מספר ימים והצדקה. אם יש לכם גם הרשאת כתיבה, אפשר להאריך כל אחת מהן, אבל לעולם לא לקצר: הצבר בדומיין שמאחורי המסך הזה (AuditRetentionPolicy.Extend) זורק חריגה אם הערך החדש נמוך מהנוכחי, והטופס משבית את כפתור השמירה על אותו תנאי בדיוק במקום לתת לשרת לדחות בשקט אחרי מעשה.

למה השניים חיים על מסך אחד

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