כללי התאימות עוקבים אחרי הנתונים ולא אחרי התווית של הסביבה, וזה המשפט שתופס צוותי פיתוח לא מוכנים. מדיניות נתוני בדיקה לפי PCI DSS קיימת מפני שמסד נתונים של בדיקות שמלא במספרי כרטיס אמיתיים הוא פרצה שממתינה לקרות, ומפני שהתקן מתייחס אליו ברצינות מלאה כמו אל ייצור, בלי קשר למידת הזמניות או הפנימיות של המערכת. כשסביבת הרצה מחזיקה נתוני בעלי כרטיס חיים, היא בתוך התחום, וכך גם כל מי שיש לו גישה אליה.
המאמר מסביר מה התקן דורש בתחום הזה, אילו סוגי נתונים מושפעים, כיצד הסתרה וטוקניזציה מצמצמות חשיפה, ולמה מספרים מופקים הם הדרך הפשוטה להוציא סביבת בדיקה מהדיון לגמרי.
הכלל שמפתיע צוותי פיתוח
ההפתעה תמיד אותה הפתעה: מישהו מעתיק טבלה מייצור אל מסד נתונים של סביבת הרצה כדי לשחזר באג, ומסיים את העניין מפני שהסביבה אינה ציבורית.
התקן אינו רואה זאת כך. בכל מקום שבו נשמרים, מעובדים או מועברים נתוני בעלי כרטיס, חלות הדרישות שמגנות עליהם. זה כולל סביבות בדיקה ופיתוח, כלים פנימיים, גיליונות אלקטרוניים שיוצאו לצורך חקירה, עותקי גיבוי, ותור ההודעות שמעביר בקשת תשלום בין שני שירותים. אין פטור למערכת שאינה פונה ללקוחות.
ההשלכה המעשית היא שעותקי נוחות של נתוני ייצור הם ההרגל היקר. כל עותק מכפיל את מספר המקומות שבהם יכולה לקרות פרצה ואת מספר המערכות שיש להעריך, והעותק נמחק לעיתים נדירות כשהחקירה מסתיימת.
האם PCI DSS חל על סביבות בדיקה?
כן, עם הסתייגות אחת חשובה שהיא גם הפתרון. הדרישות חלות על סביבות שמטפלות בנתוני בעלי כרטיס אמיתיים. הן אינן חלות על סביבה שאין בה נתוני בעלי כרטיס אמיתיים, מפני שאין בה מה להגן.
ההסתייגות הזו היא מה שהופך נתוני בדיקה מופקים לבעלי ערך כה רב. סביבה שמאוכלסת כולה בערכים מופקים אינה מחזיקה נתוני אימות רגישים, אין בה נתוני חשבון להסתיר, ואין לקוח אמיתי להודיע לו אם היא נפרצה. שאלת התחום מתמוססת כמעט לגמרי, וצוות הפיתוח יכול להפסיק לכתוב הצדקות.
גבול אחד חשוב: התקן אינו מתיר לסביבות בדיקה להשתמש בנתונים אמיתיים מפני שהם מציאותיים יותר. אם המציאותיות היא המטרה, נתונים מופקים שנגזרים מאותם כללי מבנה—אורכים נכונים, קידומות תקפות, ספרות ביקורת עקביות—נותנים אותה התנהגות בתוכנה בלי החשיפה. כל הערכים שהמחולל באתר הזה מפיק הם כאלה, והשימוש בהם הוא לבדיקות תוכנה בלבד.
מה נחשב לנתוני אימות רגישים
ההבחנה שחשובה היא בין נתוני חשבון לבין נתוני אימות רגישים. נתוני חשבון הם מספר הכרטיס עצמו, יחד עם השם, תאריך התוקף וקוד השירות. נתוני אימות רגישים הם כל מה שאפשר להשתמש בו כדי לבנות תשלום: קוד האבטחה, התוכן המלא של הפס המגנטי, והנתונים המקבילים שמחזיק השבב.
הכללים מתייחסים לקטגוריה השנייה בחמירות רבה יותר. נתוני אימות רגישים מותרים לשימוש לצורך הרשאת עסקה ואסורים בשימור לאחר ההרשאה, בכל צורה שהיא. זו הסיבה שעמודה של קוד אבטחה בטבלת הזמנות היא כשל תאימות ולא העדפת עיצוב, וזו הסיבה שהנתונים אסורים גם ביומנים, בדוחות שגיאה ובמטענים של ניסיון חוזר. מדריך קוד האבטחה מפרט את הצעדים המעשיים להרחיק אותו מהמקומות האלה.
מספר הכרטיס עצמו מותר בשימור, אבל רק עם הגנה. התקן מצפה שנתוני חשבון שמורים יהיו בלתי קריאים למי שאינו זקוק להם, והוא דורש הסתרה בכל תצוגה—המוסכמה המקובלת היא להציג רק את שש הספרות הראשונות ואת ארבע האחרונות. שש הספרות הראשונות מוצגות מפני שהן מזהות את המנפיק, וזו לרוב נחוצה לתמיכה ולהתאמה.
| רכיב נתונים | מותר לשמור לאחר הרשאה | כלל תצוגה |
|---|---|---|
| מספר כרטיס | כן, עם הגנה | מוסתר, בדרך כלל שש ספרות ראשונות וארבע אחרונות |
| שם בעל הכרטיס, תאריך תוקף | כן, עם הגנה | מוסתר במקום שבו הוא מוצג |
| קוד אבטחה | לא | אסור לשמור כלל |
| פס מגנטי מלא או נתוני שבב | לא | אסור לשמור כלל |
הסתרה, טוקניזציה ונתונים מופקים
שלוש טכניקות מוזכרות יחד ועושות עבודות שונות.
הסתרה מחביאה חלק מערך שעדיין נשמר במלואו. היא מצמצמת את מה שאפשר ללמוד ממבט מזווית או מצילום מסך, והיא נדרשת בתצוגה, אבל היא אינה מפחיתה את הסיכון במסד הנתונים עצמו, מפני שהערך שמתחתיה נמצא שם.
טוקניזציה מחליפה את מספר הכרטיס במזהה שנשמר אצל ספק הסליקה. המערכות של הארגון שומרות את המזהה, והספק מחזיק את המיפוי. זו הפחתה אמיתית בחשיפה, מפני שמסד נתונים שנגנב מפיק מזהים חסרי משמעות מחוץ לסביבה של הספק. זו גם הגישה היחידה שמאפשרת חיובים חוזרים בלי שהמערכות יחזיקו את המספר כלל.
נתונים מופקים מחליפים ערכים אמיתיים בערכים מופקים שעומדים באותם כללי מבנה. אין צורך להגן על דבר, מפני שדבר אמיתי אינו נמצא שם. המגבלה שלהם היא נאמנות: מספר מופק אינו ניתן לחיוב, אינו ניתן לאיתור במערכת של ספק ואינו יכול לשחזר באג שתלוי בחשבון מסוים. זה הופך אותו לברירת מחדל נכונה לבדיקות טפסים, לבדיקות עומס ולסביבות הדגמה, ולכלי שגוי כשהבעיה תלויה בחשבון מסוים.
למה מספר מופק בטוח יותר ממספר אמיתי מוסתר?
כדאי לשקול מה שווה כל ערך בעיני מי שמנסה לנצל אותו. מספר מוסתר הוא אישור אמיתי שחלקו הוסתר; אם הערך המלא קיים גם במקום אחר באותו ארגון—ביומן, בגיבוי, בתור—פריצה לאחד המקומות האלה חושפת כרטיס שמיש. מספר מופק הוא מחרוזת שאינה מתפענחת לשום דבר, בשום מקום ובשום תצורה.
יש גם תועלת עדינה יותר. ערך מופק אינו יכול להיכנס לשימוש בטעות. מספר אמיתי מוסתר, אם ההסתרה תוסר פעם אחת בשינוי ניפוי או בייצוא, הופך שוב לאישור חי בלי שום אזהרה. לנתונים מופקים אין מצב שני כזה. כל כרטיס שהמחולל באתר הזה מפיק הוא מסוג כזה: נכון מבנית, עקבי עם כללי התבנית, ומעולם לא הונפק לאיש.
ההסתייגות הכנה היא שעל נתונים מופקים עדיין לתייג. מתחזק עתידי שאינו יודע שהערכים מופקים עשוי לתהות מדוע אי אפשר לחייב את הכרטיס, או גרוע מכך, להחליף אותם בערכים אמיתיים כדי שבדיקה תעבור.
למפתחים: הפרדה בין בדיקות לייצור
רוב החשיפה במציאות מגיעה מצנרת ולא ממדיניות, ולכן העבודה היא בעיקרה מכנית.
מתחילים בפרטי גישה. מערכות בדיקה צריכות להחזיק מפתחות בדיקה, ומפתחות ייצור צריכים להיות נעדרים מכל סביבה אחרת, כולל המחשב של מי שמנפה תקלות. בדיקת תצורה באתחול שמסרבת לעלות כשהשניים מעורבבים שווה את המאמץ הקטן.
לאחר מכן בודקים כיצד נתונים נעים בין סביבות. שחזור של גיבוי מייצור אל סביבת הרצה הוא הדרך הנפוצה ביותר שבה נתוני בעלי כרטיס אמיתיים מגיעים למקום לא צפוי; אם שחזור נחוץ באמת לבדיקת ביצועים, יש להחליף את הערכים לפני שהמערכת נגישה. ההחלפה קלה בהרבה אם שלב הזריעה יושב במאגר הקוד ויכול לרוץ מחדש.
לבסוף, בודקים מה סביבת הבדיקה כותבת. יומנים, מטעני ניטור, דוחות שגיאה ותורי הודעות כולם לוכדים שברים של בקשות, וכל אחד מהם יכול להחזיק קוד אבטחה או מספר שאינו מוסתר. כדאי לחפש בפלט של הרצת בדיקות מלאה ערכים בעלי צורה של מספר כרטיס; התוצאה מלמדת בדרך כלל יותר מכל מסמך מדיניות.
השגת נתוני בדיקה תואמי תקן
הרצף המעשי הוא להסיר נתוני אימות רגישים מכל סביבה, לבצע טוקניזציה בכל מקום שבו חייבים להתייחס לחשבון אמיתי, ולהפיק את כל השאר. התקן עצמו מפורסם בידי מועצת תקני האבטחה של תעשיית הכרטיסים וזמין בpcisecuritystandards.org, והוא המקור המוסמך לגרסה העדכנית ולניסוח המדויק שלה; כדאי לקרוא בו את הסעיפים על שימור נתונים ועל סביבות בדיקה במקום להסתמך על סיכומים.
לחלק המופק, מחולל מספרי הכרטיס מפיק מספרים נכונים מבנית לפי דרישה, עם תאריכי תוקף תואמים וקודי מציין מקום, ושום דבר בפלט אינו מתייחס לחשבון אמיתי. רשימת הבדיקות לטופס תשלום מתארת את הזרימות שבהן כדאי להשתמש בערכים האלה.
צעדים הבאים
כדאי לרשום כל מקום שבו נתוני כרטיס אמיתיים יכולים להגיע למערכת שאינה ייצור—גיבויים, ייצוא, יומני ניפוי, מטעני תור—ולדרג אותם לפי הקלות שבה אפשר להסיר אותם. לאחר מכן להחליף את הקל שבהם בערכים מופקים עוד השבוע, ולאשר זאת בחיפוש אחר מחרוזות בעלות צורה של מספר כרטיס בסביבה, ולא בשאלה אם מישהו העתיק אותן.