תפריט

נתוני בדיקה ו-GDPR: מדוע בדיקה על פרטים אמיתיים היא בעיה

נתוני בדיקה ו-GDPR מתחילים בהרגל אחד: להשאיר מידע אישי אמיתי מחוץ לפיתוח ולסביבות ביניים. כאן מוסבר מדוע וכיצד מחליפים אותו ברשומות בדיוניות.

פורסם

  • נתוני בדיקה
  • זהות
  • פרטיות

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

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

מה נחשב כאן מידע אישי?

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

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

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

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

מדוע מערכות בדיקה לא צריכות להחזיק נתוני ייצור?

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

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

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

מה ההבדל בין אנונימיזציה לפסידונימיזציה?

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

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

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

האם הסוואה ומחיקה פותרות את הבעיה?

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

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

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

מה צריך להחליף העתקות מייצור?

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

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

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

כיצד מרחיקים מידע אישי מיומנים ומצילומי מסך?

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

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

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

למפתחים: הפרדה, מקורות והוכחה

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

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

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

הצעדים הבאים

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

המשך קריאה

מדריכים בנושא מחולל זהויות ונתוני בדיקה