PII בצילומי מסך בבסיסי ידע פנימיים
בסיסי ידע פנימיים — Confluence, Notion, SharePoint, GitBook — מחזיקים סוג ספציפי של בעיית PII שכלי תאימות סטנדרטיים מחמיצים: נתונים אישיים של לקוחות המוטבעים בצילומי מסך המשמשים לתיעוד תהליכים.
התבנית מתרחשת אצל אלפי צוותי תמיכה ותפעול.
סוכן תמיכה מוצא הגדרת חשבון חריגה. הוא לוקח צילום מסך של דף חשבון הלקוח כדי לתעד את הבעיה. צילום המסך מציג את שם הלקוח בכותרת ממשק המשתמש, את האימייל שלו בהגדרות החשבון ואת פרטי התוכנית שלו.
המאמר עולה לבסיס הידע הפנימי. מאה וחמישים סוכני תמיכה יכולים כעת לצפות בו. שנים עשר קבלנים במוקד העזרה החיצוני יכולים לצפות בו גם. המאמר שימושי. הוא מראה כיצד לטפל באותה מקרה קצה. כל סוכן שיפגוש אותה הגדרה בעתיד יקרא אותו.
שלוש שנים מאוחר יותר, בסיס הידע מחזיק 847 מאמרים כאלה. כל אחד מכיל צילומי מסך של חשבונות לקוחות. הלקוחות המוצגים לא הסכימו לשימוש משני זה ברשומותיהם. רובם אינם יודעים שנתוניהם מאוחסנים שם.
זו אינה בעיה קטנה. היא גדלה עם כל מאמר חדש.
חשיפת GDPR: מדוע זה חשוב
ניתוח ה-GDPR לצילומי מסך בבסיס ידע הוא ישיר.
מינימיזציית נתונים (סעיף 5(1)(ג)): נתונים אישיים חייבים להיות "מספקים, רלוונטיים ומוגבלים למה שנדרש". מאמר בסיס ידע על הגדרת חשבון אינו צריך את שם הלקוח האמיתי ואת האימייל שלו. צילום מסך מטושטש משרת את המטרה באותה מידה. הכלל לכלול נתוני לקוח חיים אינו הכרחי.
הגבלת מטרה (סעיף 5(1)(ב)): נתונים שנאספו למטרה אחת — שירות לקוחות — אינם יכולים לשמש למטרה אחרת — תיעוד תהליכים פנימי — ללא בסיס משפטי. רשומות חשבון נאספו לאספקת שירות, לא לתיעוד פנימי. אלו שתי מטרות עיבוד שונות. שימוש באותן רשומות לשתיהן מצריך בסיס משפטי תקף שרוב הצוותים לא הגדירו.
בקרת גישה (סעיף 5(1)(ו) וסעיף 32): אמצעים טכניים מתאימים חייבים להגן על נתונים אישיים. צילומי מסך של חשבונות לקוחות בכלי הפתוח לכל 150 הסוכנים והקבלנים — כולל אלה ללא גישה למערכת החשבונות הבסיסית — יוצרים גישה רחבה מדי.
זכות מחיקה (סעיף 17): נבדק המבקש מחיקה זכאי שרשומותיו יוסרו "ללא עיכוב מיותר". אם הנתונים שלו מופיעים ב-23 מאמרי בסיס ידע כצילומי מסך מוטבעים, הבקשה מצריכה מציאה ועדכון של כל 23 המאמרים. זה קשה ללא מערכת. מדריך זכות המחיקה של GDPR שלנו מכסה את השלבים בפירוט.
אף אחת מהן אינה קריאה של מקרה קצה. הן יישומים ישירים של טקסט הרגולציה לפרקטיקה נפוצה.
עקיפת בקרת הגישה
בעיית התאימות החמורה ביותר עם צילומי מסך של Confluence היא עקיפת בקרת הגישה שהם יוצרים.
צוותי תמיכה משתמשים בבקרת גישה מבוססת תפקיד (RBAC) כדי להגביל מי יכול לצפות במערכות חשבון לקוחות. סוכני רמה 1 רואים פרטי חשבון בסיסיים. סוכני רמה 2 רואים רשומות חיוב וטכניות. מנהלים רואים את פרופיל החשבון המלא.
כאשר סוכן רמה 2 יוצר מאמר בסיס ידע עם צילום מסך של חשבון לקוח מלא, צילום המסך הופך לגלוי לכל משתמשי הכלי. סוכני רמה 1 שלא אמורים לראות רשומות חיוב יכולים כעת לצפות בהן. קבלנים ללא גישת מערכת יכולים לצפות בהן. עובדים חדשים בהכשרה יכולים לצפות בהן.
צילום המסך עוקף את בקרות ה-RBAC על מערכת חשבון הלקוח. הנתונים האישיים שה-RBAC נבנה להגן עליהם פתוחים כעת לכולם עם גישה לבסיס הידע.
זהו לא סיכון תיאורטי. זה התוצאה הרגילה של תהליך עבודה תיעודי. צילום המסך יושב שם ללא פג תוקף, ללא יומן גישה, וללא שביל ביקורת.
שלבי תיקון מעשיים
לצוותים שמגלים בעיה זו במהלך ביקורת GDPR:
תיקון רטרואקטיבי:
- זהו את כל דפי בסיס הידע עם קבצים מצורפים של תמונות
- הפעילו זיהוי PII בתמונות על כל קובץ מצורף
- בדקו תמונות מסומנות: ממצאים בביטחון גבוה עוברים לתור בדיקה
- לכל תמונה מסומנת: החלפו בגרסה מנוקה או הגבילו גישה לדף
- תעדו פעולות תיקון לרשומות GDPR
היקף עבודת התיקון הרטרואקטיבית תלוי בגודל בסיס הידע. עבור בסיס ידע בן שלוש שנים בצוות תמיכה של 50 אנשים, מספר התמונות יכול להגיע לאלפים. עיבוד תמונות באצווה הופך זאת לישים. בדיקה אנושית של תמונות מסומנות היא צוואר הבקבוק המרכזי.
בקרות עתידיות:
- הכשירו את כל אנשי התמיכה לנקות צילומי מסך לפני פרסום לבסיס הידע
- ספקו כלים: כלי הערות צילום מסך שמטשטשים שמות לקוחות לפני הדבקה
- הוסיפו שלב בדיקה: מבקר ייעודי בודק מאמרים לפני פרסום, מחפש במיוחד PII לקוחות בתמונות
- הפעילו סריקת תמונות אצווה רבעונית על כל קבצי ה-Confluence המצורפים
בקרה מינימלית אפשרית: רשימת בדיקה לפרסום: "הסירו או טשטשו את כל שמות הלקוחות, האימיילים ומזהי החשבון מצילומי המסך לפני פרסום." טכנולוגיה נמוכה, לא אוטומטי, אבל יוצר בקרה מתועדת. לצוותים קטנים, זו נקודת ההתחלה.
ראו את סקירת תאימות GDPR שלנו למסגרת המשפטית הרחבה, ואת מדוע מדיניות ללא בקרות טכניות נכשלת לסיבה שגישות של רשימות בדיקה בלבד מתמוטטות בנפח.
מדוע הבעיה גדלה עם הזמן
ללא בקרות שיטתיות, חשיפת PII בבסיס הידע מתחזקת.
נפח: כל מאמר חדש עם צילום מסך של לקוח מוסיף לחשיפה הכוללת. ככל שצוות התמיכה גדל ובסיס הידע מתרחב, ה-PII המצטבר גדל גם. המאפיינים שהופכים כלים אלה לשימושיים — קלות פרסום, קביעות, גישה רחבה — הם מה שמחמיר את בעיית ה-PII.
מאמרים שנשכחו: מאמרים על מקרי קצה ישנים שכבר לא מגיעים נשארים נגישים. הם מחזיקים PII מלקוחות שמאז הגישו בקשות מחיקה. אף אחד לא בודק מאמר שעודכן לאחרונה ב-2022.
התפשטות בין-צוותית: בסיסי ידע לרוב הופכים לחוצי-פונקציות. מאמר תמיכה עם צילומי מסך של לקוחות עשוי להיות משותף עם צוות המוצר, צוות ההנדסה, או קבלנים חיצוניים לצורך הקשר בבקשת תכונה או דוח באג. כל שיתוף מרחיב את הקהל לנתונים האישיים.
פיגור במחיקה: ככל שרשומות לקוחות נוספות מצטברות בבסיס הידע, מענה לבקשות מחיקה הופך מורכב יותר. ללא מערכת, אין דרך אמינה לאשר שכל מופע של רשומות נבדק נמצא והוסר. הצוות אינו יכול לאשר מחיקה באופן מהימן.
PII בבסיס ידע קל יותר למניעה מאשר לתיקון. בקרות שמוצבות עכשיו נמנעות מבעיית התיקון המצטברת. כל מאמר שפורסם ללא צילום מסך מטושטש הוא משימת תיקון שנדחתה לעתיד.