PII מסתתר ביומני האפליקציה
יומני אפליקציה הם אחת מנקודות ה-GDPR המוחמצות ביותר בהנדסה. לא בגלל שמהנדסים מתעלמים מהחוק. כי פרטי משתמשים נכנסים לקבצי יומן בטעות.
יומן בקשת JSON יחיד יכול להכיל ארבעה שדות PII:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
רשומה בודדת זו מכילה אימייל, IP ומספר טלפון. הכפל זאת על פני מיליוני קריאות API יומיות. התוצאה היא פעילות PII מרכזית הדורשת בסיס חוקי, גבולות ובקרות.
שיתוף יומנים עם צדדים שלישיים מעלה סיכון GDPR
צוותים משתפים קבצי יומן עם גורמים חיצוניים כל הזמן:
- חברות בדיקת חדירה מקבלות רשומות לממפ התנהגות אפליקציה
- יועצים חיצוניים משתמשים בדגימות יומן למציאת צווארי בקבוק
- פלטפורמות יומן (Elastic, Datadog, Splunk) מקבלות זרמי פלט מלאים
- קבלני SRE ניגשים לרשומות במהלך אירועים
- צוותי פיתוח בישויות משפטיות אחרות מקבלים קבצים לניפוי שגיאות
כל שיתוף מעלה שאלות לפי סעיף 28 ל-GDPR. האם הנמען הוא מעבד? האם קיים הסכם עיבוד נתונים? האם יש להם בסיס חוקי לראות פרטי משתמשים בקבצים אלה?
פלטפורמות יומן הן פער נפוץ. שליחת פלט עם אימיילי משתמשים וכתובות IP אמיתיים ל-Elastic Cloud או Datadog יוצרת קישור עיבוד. קישור זה דורש DPA, סעיפים סטנדרטיים וכלי העברה אם הפלטפורמה יושבת מחוץ לאיחוד האירופי. כל אחד מאלה לוקח זמן וסקירה משפטית.
הדרך הפשוטה יותר: פשוט פרטי משתמשים לפני שקבצים עוזבים את המערכת שלך. קרא את סקירת הציות שלנו לכללי סעיף 28 המלאים.
מדוע מבנה JSON מקשה על זיהוי
קבצי יומן JSON משתנים במבנה. סריקת טקסט גנרית אינה מספיקה.
עומק הקינון: פרטי משתמשים מופיעים בכל עומק. השדה request.headers.x-forwarded-for מכיל כתובות IP. השדה response.body.errors[0].field_value עשוי להכיל קלט משתמש. סריקה שטוחה מחמיצה שדות קבורים בנתיבים מקוננים.
סכמות לא עקביות: כל נקודת קצה API מייצרת צורת פלט משלה. קבצי אימות נראים שונה מקבצי תשלום. קבצי עדכון פרופיל נראים שונה משניהם. גישה מבוססת-נתיב קבוע מחמיצה פרטי משתמשים שמופיעים בנתיבים מוזרים בהקשרי שגיאה.
ערכים טכניים מעורבים עם PII: עקבות מחסנית, קודי שגיאה וחותמות זמן חייבים להישאר שלמים. ניגוב שטיח מוחק שדות נדרשים והופך את הקובץ לחסר תועלת.
גישה הנכונה היא זיהוי מבוסס תוכן. מצא פרטי משתמשים לפי מה שהם — דפוס אימייל, פורמט IP, ישות שמוזכרת — ולא לפי מיקומם במבנה. זה מטפל בסכמות משתנות ללא צורך בהגדרה לכל נקודת קצה.
החלפה עקבית שומרת על שימושיות היומנים
דרישת המפתח היא שלמות הפניה. אם sarah.johnson@company.com מופיע ב-47 רשומות לאורך שרשרת בקשה, כל 47 חייבות למפות לאותו ערך.
כללי מיפוי:
sarah.johnson@company.com→user1@example.com(אותו ערך לאורך הקובץ)82.123.45.67→192.0.2.1(IP תיעודי RFC 5737 — ברור שאינו אמיתי)+49 176 1234 5678→+49 XXX XXX XXXX(מוסתר)
עם מיפוי זה, מפתח יכול לעקוב אחרי user1@example.com דרך 47 רשומות, לשחזר את שרשרת הבקשה ולתקן את הבאג — מבלי לראות פרטי משתמש אמיתיים כלשהם.
שדות מטא-נתונים אלה נשארים ללא שינוי:
- חותמות זמן (לא נתוני משתמש)
- קודי וסוגי שגיאה (לא נתוני משתמש)
- עקבות מחסנית (עשויים להכיל מזהים טכניים, לא נתוני משתמש)
- מתודות HTTP, נתיבים, קודי סטטוס (לא נתוני משתמש)
- ערכי מדדים ונתוני זמן תגובה (לא נתוני משתמש)
התוצאה היא קובץ שעובד לניפוי שגיאות. אינו מכיל פרטי משתמש אמיתיים. ראה את המילון שלנו להבדל בין אנונימיזציה לפסאודונימיזציה תחת GDPR.
מקרה שימוש: שיתוף יומנים לבדיקת חדירה
חברת SaaS ביצעה סקירת אבטחה רבעונית עם צוות בדיקת חדירה חיצוני. ההיקף דרש 90 ימים של פלט API ייצור למיפוי זרימות אימות ולניתוח דפוסי שגיאה.
נפח גולמי: 180 MB קבצי JSON. ספירת PII: 4,200 אימיילי משתמשים ייחודיים, 1,800 כתובות IP ייחודיות, 340 מספרי חשבון חלקיים בהקשרי שגיאה.
ללא פישוט פרטי משתמשים תחילה, שיתוף הקבצים האלה היה דורש:
- DPA עם חברת בדיקת החדירה
- כלי העברה לפי סעיף 46 ל-GDPR (החברה ישבה מחוץ לאיחוד האירופי)
- סקירת הודעת נושא נתונים
כל אחד מאלה מוסיף עבודה משפטית וזמן.
עם פישוט PII מיושם:
- זמן עיבוד: 25 דקות ל-180 MB
- פלט: 180 MB קבצים זהים מבנית, כל האימיילים וכתובות ה-IP הוחלפו בערכים בטוחים
- תוצאה: צוות בדיקת החדירה קיבל הקשר מלא; אפס פרטי משתמש אמיתיים הגיעו אליהם
- תוצאת GDPR: לא נדרש DPA — פלט מפושט אינו נתוני משתמש תחת GDPR
ראה את השאלות הנפוצות שלנו לשאלות נפוצות לגבי מה נחשב אנונימי תחת GDPR.
שילוב פישוט PII ב-CI/CD
עבור צוותים שמשתפים פלט באופן קבוע, שלב זה יכול לפעול בתוך צינוריות קיימות.
רוטציית יומן:
- סקריפט רוטציה פועל לילי
- שלב פישוט פועל לפני ארכוב או משלוח לכל פלטפורמת יומן
- קבצים מפושטים עוברים למערכות חיצוניות
- קבצים מקוריים נשארים פנימיים עם שמירה מלאה
סקריפט קדם-שיתוף:
- מהנדס צריך לשתף דגימה עם קבלן
- מריץ את הסקריפט:
input=raw-logs/ output=clean-logs/ - משתף את תיקיית
clean-logs/ - אין צורך בסקירת PII ידנית
גישת sidecar:
- Sidecar מפשט את זרם הפלט לפני העברה
- פישוט בזמן אמת שומר על תועלת לניתוח יומן
- הפלטפורמה מקבלת אפס פרטי משתמש אמיתיים
שילוב מדיניות שמירה
סעיף 5(1)(e) ל-GDPR דורש הגבלת אחסון. פישוט PII מתאים לכל מדיניות שמירה.
- פלט גולמי נשמר 7 ימים (לעבודת ניפוי שגיאות יומיומית)
- גרסאות מפושטות נשמרות 90 ימים (לניתוח מגמות וסקירת אירועים)
- שלב הפישוט פועל ביום 7
זה מספק הגבלת אחסון. מסיר את הסיכון של שמירת פלט גולמי לטווח ארוך.