במסמך הזה מתוארות שיטות מומלצות לתכנון ארכיטקטורה של סביבת הענן בהתאם למועצה לתקני אבטחה של תעשיית כרטיסי התשלום (PCI). השיטות המומלצות האלה שימושיות לארגונים שמבצעים מיגרציה או מתכננים מערכות בענן שחלות עליהן דרישות של תאימות לתקן PCI. במאמר הזה אנחנו מתייחסים לדרישות של PCI DSS 4.0 במקומות הרלוונטיים.
הסבר על היקף ההערכה של PCI DSS
אם הארגון שלכם עוסק במסחר באינטרנט, אתם צריכים לתמוך בתאימות לתקן PCI ולשמור עליה. האופן שבו אתם מתכננים ומנהלים את סביבת הענן משפיע על היקף המערכות שייכללו בהערכה של תקן אבטחת הנתונים (DSS) של PCI. להיקף יש השלכות חשובות על האבטחה של נכסי ה-IT ועל היכולת שלכם לתמוך בתאימות לתקן PCI ולשמור עליה. כדי לוודא שהיקף סביבת ה-PCI מוגדר בצורה נכונה, אתם צריכים להבין איך התהליכים העסקיים והחלטות התכנון משפיעים על ההיקף.
מהו היקף?
כל המערכות שמאחסנות, מעבדות או מעבירות נתונים של בעלי כרטיסים (CHD) נכללות בהיקף ההערכה שלכם לפי PCI DSS. אבטחה חשובה לכל סביבת הענן שלכם, אבל פריצה למערכות שנכללות בהיקף עלולה לגרום לפרצת אבטחת מידע ולחשיפה של נתונים של בעלי כרטיסים.
באיור 1, סביבת הנתונים של בעלי הכרטיסים (CDE), המערכות המחוברות והמערכות שמשפיעות על האבטחה נמצאות בתוך גבול היקף ההערכה, בעוד שמערכות לא מהימנות ומערכות שלא נכללות בהיקף ההערכה נמצאות מחוץ לגבול היקף ההערכה.
לפי PCI DSS, מערכות בהיקף נחשבות מהימנות. מערכות שנכללות בהיקף כוללות את סביבת ה-CDE שלכם וכל מערכת שמחוברת לסביבת ה-CDE או שיכולה להשפיע על האבטחה שלה.
מערכת מחוברת אל אם היא נמצאת באותה רשת, חולקת מסדי נתונים או אחסון קבצים, או שיש לה גישה או קישוריות לכל מערכת או תהליך שנמצאים בסביבת נתוני הכרטיסים, אבל אין לה גישה ישירה לנתוני הכרטיסים.
מערכת משפיעה על האבטחה אם היא יכולה, במקרה של פריצה, לאפשר לתוקף לקבל גישה לסביבת נתוני כרטיסי האשראי (CDE). כל המערכות שמחוברות למערכת שנבדקת ומשפיעות על האבטחה שלה תמיד ייכללו בבדיקה.
מערכות שמוגדרות מחוץ להיקף ההסמכה הן לא מהימנות בהגדרה בתקן PCI DSS, ואין להן ערך לתוקף שרוצה לקבל גישה לנתוני כרטיסי אשראי (CHD) או לנתוני אימות רגישים (SAD). מערכת מוגדרת מחוץ להיקף ההסמכה אם היא לא יכולה להשפיע על האבטחה של מערכת שמוגדרת בתוך היקף ההסמכה, גם אם המערכת שמוגדרת מחוץ להיקף ההסמכה נפגעה. למרות שמערכות שמוגדרות מחוץ להיקף ההסמכה לא נבדקות ישירות, מעריך אבטחה מוסמך (QSA) של PCI מוודא שההיקף שלכם מדויק ושנתוני כרטיסי האשראי מוגנים בהתאם לתקן PCI DSS. לכן חשוב שהגבולות של היקף ההסמכה יהיו מוגנים היטב, שיהיו נתונים למעקב רציף ומקיף ושיהיו מתועדים בצורה ברורה.
חיבורים בהקשר של PCI
כמה מהדרישות של PCI DSS מתייחסות לחיבורים, אבל החיבורים לא מוגדרים באופן מפורש ב-PCI DSS. כדי להבין את המשמעות של חיבורים בהקשר הזה, אפשר לעיין בעץ ההחלטות בנושא הגדרת היקף בהנחיות של PCI SSC בנושא הגדרת היקף ופילוח רשת של PCI DSS (PDF).
לצורך הערכת היקף ה-PCI, חיבור מוגדר על ידי הפרטים הבאים:
- העברת מידע פעילה שמקשרת בין שני מחשבים או מערכות
- מי משני הצדדים יזם את השיחה
כשמתעדים את הסביבה, מומלץ לציין בבירור איזה צד מורשה ליזום חיבור. חומת אש שמוגדרת כך שהיא מאפשרת תנועה רק בכיוון אחד יכולה לאכוף חיבור חד-כיווני. לדוגמה, אפליקציה לעיבוד תשלומים שנמצאת בהיקף יכולה לשלוח שאילתות לשרת מסד נתונים שלא נמצא בהיקף, בלי שהשרת שלא נמצא בהיקף ייכנס להיקף, אם כל התנאים הבאים מתקיימים:
- החיבור ומסד הנתונים שלא נכלל בהיקף לא שומרים, מעבדים או מעבירים נתוני CHD או SAD.
- מסד הנתונים נמצא ברשת נפרדת או שהוא מפולח בדרך אחרת מ-CDE.
- מסד הנתונים לא יכול ליזום שיחות ישירות או עקיפות ל-CDE.
- מסד הנתונים לא מספק שירותי אבטחה לסביבת ה-CDE.
- מסד הנתונים לא משפיע על ההגדרה או על האבטחה של סביבת הנתונים.
- המסד תומך בדרישות של PCI DSS.
בתרשים הבא מוצגים הגורמים שקובעים את היקף המערכת:
באיור 2, היקף המערכת נקבע באופן הבא:
רכיבי המערכת שנכללים בהיקף של PCI DSS:
- מערכות שנמצאות בסביבת הנתונים המשותפת (CDE) שאחד מהתנאים הבאים מתקיים לגביהן:
- רכיב במערכת מאחסן, מעבד או מעביר נתוני כרטיסי אשראי או נתוני כתובות למשלוח.
- רכיב מערכת נמצא באותו פלח רשת – לדוגמה, באותה רשת משנה או באותו VLAN – כמו מערכות שמאחסנות, מעבדות או מעבירות נתוני כרטיסי חיוב.
- מערכות שמחוברות למערכות אחרות או משפיעות על האבטחה שלהן, ואחד מהתנאים הבאים מתקיים לגביהן:
- רכיב מערכת שמתחבר ישירות ל-CDE.
- רכיב במערכת משפיע על ההגדרה או על האבטחה של סביבת הנתונים.
- רכיב מערכת שמפלח מערכות CDE ממערכות וממרשתות שלא נכללות בהיקף.
- רכיב מערכת מתחבר באופן עקיף ל-CDE.
- רכיב מערכת מספק שירותי אבטחה ל-CDE.
- רכיב מערכת תומך בדרישות של PCI DSS.
- מערכות שנמצאות בסביבת הנתונים המשותפת (CDE) שאחד מהתנאים הבאים מתקיים לגביהן:
רכיבי מערכת יכולים להיחשב כלא מהימנים וכלא רלוונטיים לתקן PCI DSS אם כל התנאים הבאים מתקיימים:
- רכיב במערכת לא מאחסן, מעבד או מעביר נתוני כרטיסי אשראי או נתונים רגישים אחרים.
- רכיב מערכת לא נמצא באותו פלח רשת – לדוגמה, באותה רשת משנה או באותו VLAN – כמו מערכות שמאחסנות, מעבדות או מעבירות נתוני CHD או SAD.
- רכיב מערכת לא יכול להתחבר לאף מערכת ב-CDE.
- רכיב במערכת לא עומד בקריטריונים של מערכות שמחוברות למערכת או של מערכות שמשפיעות על האבטחה.
מערכות שלא נכללות בהיקף יכולות לכלול מערכות שמתחברות לרכיב מערכת שמשפיע על האבטחה או שמתחבר למערכת, שבה יש אמצעי בקרה למניעת גישה של המערכת שלא נכללת בהיקף ל-CDE באמצעות רכיב המערכת שנכלל בהיקף.
מבחינה מעשית, ההגדרה של היקף המערכת בתקן PCI DSS יכולה להיות שמאגר הסשנים של אפליקציית האינטרנט ומסד הנתונים של המסחר האלקטרוני עשויים להיחשב כחלקים שלא נכללים בהיקף, אם הפילוח מיושם ומתועד בצורה נכונה. בתרשים הבא מוצג אופן הפעולה של חיבורי קריאה וכתיבה בין מערכות שנכללות בהיקף לבין מערכות שלא נכללות בהיקף:
איור 3 מציג את החיבורים הבאים:
- קריאה בלבד:
- אפליקציה לעיבוד תשלומים שנמצאת בהיקף קוראת מזהה עגלת קניות ממסד נתונים של עגלות קניות שלא נמצא בהיקף, וקוראת נתונים מ-DNS ומ-NTP.
- כתיבה בלבד:
- אפליקציה לעיבוד תשלומים שנכללת בהיקף כתיבה למסד הנתונים הראשי של אפליקציה שלא נכללת בהיקף ול-Cloud Logging.
- אפליקציית האינטרנט הראשית שלא נכללת בהיקף כותבת נתונים לשירות רישום ביומן. הנתונים האלה לא כוללים נתוני המרה של קמפיינים לקידום אפליקציות או קמפיינים לחיפוש אפליקציות.
- קריאה וכתיבה:
- משתמש באינטרנט הציבורי קורא וכותב מטא-נתונים של בקשות באופן הבא:
- המשתמש קורא מתוך אפליקציה לעיבוד תשלומים שכלולה בהיקף הבדיקה וכותב לתוכה. המטא-נתונים של הבקשה הם מזהה העגלה ומפתח האימות של העגלה, שמכילים נתוני כרטיס אשראי ונתוני כתובת למשלוח.
- המשתמש קורא וכותב לאפליקציית האינטרנט הראשית שלא נכללת בהיקף. המטא-נתונים של הבקשה הם מזהה סשן שלא מכיל נתוני כרטיס אשראי או נתוני כתובת למשלוח.
- אפליקציית האינטרנט הראשית שלא נכללת בהיקף קוראת נתונים וכותבת נתונים למסד נתונים של עגלת קניות, למאגר נתוני סשנים ולמסד נתונים ראשי של האפליקציה, שלא נכללים בהיקף. הנתונים האלה לא כוללים נתוני כרטיסי חיוב או נתונים רגישים אחרים.
- אפליקציה לעיבוד תשלומים שנמצאת בהיקף של התקן קוראת נתונים וכותבת נתונים לשירות טוקניזציה של כרטיסים שנמצא בהיקף של התקן ולמעבד כרטיסי אשראי באינטרנט הציבורי. הנתונים האלה כוללים נתוני כרטיס ונתוני חשבון רגישים.
- משתמש באינטרנט הציבורי קורא וכותב מטא-נתונים של בקשות באופן הבא:
הארכיטקטורה באיור 3 מתארת שתי אפליקציות אינטרנט נפרדות: אפליקציית האינטרנט הראשית (האפליקציה הראשית), שלא נכללת בהיקף של PCI, ואפליקציית עיבוד התשלומים (אפליקציית התשלום), שנכללת בהיקף. בארכיטקטורה הזו, אפשר ליצור חיבור בין שתי ישויות רק בכיוונים שמתוארים ברשימה הקודמת. הקשרים בין ישויות יכולים להיות לקריאה בלבד, לקריאה ולכתיבה או לכתיבה בלבד מנקודת המבט של המתקשר. כל נתיב או כיוון בקשה שלא מתוארים במפורש נחסמים על ידי הפילוח. לדוגמה, אפליקציה לעיבוד תשלומים יכולה לקרוא ממאגר הנתונים של עגלת הקניות ולכתוב לשירות הרישום ביומן, מה שכולל יצירת חיבור לישויות האלה.
בדרך כלל, מערכות שנכללות בהיקף קוראות למערכות ולשירותים שלא נכללים בהיקף. החיבורים האלה נשארים מאובטחים כי הפילוח מונע מכל מתקשר מרוחק (חוץ מבעל הכרטיס) ליצור חיבור ל-CDE באופן ישיר או עקיף. באיור 3 אפשר לראות שנתיב הכניסה היחיד לאפליקציית התשלום הוא מהמשתמש.
באיור 3, אף שירות או אפליקציה שלא נכללים בהיקף לא מספקים נתוני תצורה או נתוני אבטחה לאפליקציה לעיבוד תשלומים. הנתונים זורמים בארכיטקטורה באופן הבא:
- האפליקציה הראשית מעבירה את המשתמש לאפליקציית התשלום ומשתמשת ב-HTTP
POSTכדי להעביר אתCartIDואמצעי אימות שנקראCartAuthKey. CartAuthKeyהוא גיבוב שלCartIDוסוד ששותף מראש וידוע רק לאפליקציות הראשיות ולאפליקציות של דף התשלום. - אפליקציית התשלום מאמתת את המשתמש על ידי גיבוב של
CartIDיחד עם הסוד והשוואת הערך הזה לערך שלCartAuthKey. - אחרי אימות נתוני המשתמש, נעשה שימוש ב-
CartIDכדי לקרוא את תכולת עגלת הקניות ממסד הנתונים של עגלות הקניות. כל נתוני בעלי הכרטיסים נשלחים מהמשתמש ישירות לאפליקציית התשלום. - אם נעשה שימוש בפרופילי תשלומים, נתוני בעל הכרטיס מאוחסנים בשירות הטוקניזציה.
- אחרי שהתשלום מעובד, התוצאה מוכנסת למסד הנתונים של האפליקציה הראשית באמצעות חשבון שירות של מסד נתונים עם הרשאת כתיבה בלבד.
שיקולים לגבי היקף ההרשאות
בהנחיות בנושא הגדרת היקף של PCI DSS ופילוח רשת, המועצה לתקני אבטחה של PCI (SSC) ממליצה להניח שכל דבר נמצא בהיקף עד שיוכח אחרת. ההמלצה הזו של קמפיין שופינג חכם (SSC) לא אומרת שצריך להרחיב את ההיקף ככל האפשר. המשמעות היא ש-QSA מעריך את כל המערכות כאילו הן מהימנות, אלא אם אתם יכולים להוכיח שלמערכת מסוימת אין קישוריות ל-CDE או השפעה על האבטחה שלו. כדי לעמוד בדרישות התאימות הרגולטוריות ולשמור על נכסי ה-IT שלכם, כדאי להגדיר את הסביבה בהתאם לעקרון של הרשאות מינימליות, כלומר לתת אמון למספר המינימלי האפשרי של מערכות.
לפני ההערכה, צריך להעריך את הסביבה כדי להבין ולתעד את הגבול בין המערכות שנכללות בהיקף לבין המערכות שלא נכללות בו. המשימה הראשונה של ה-QSA היא לוודא שההיקף המתועד כולל באופן סביר את ה-CDE ואת המערכות המחוברות. כחלק מההערכה הכוללת, ה-QSA מוודא שמערכות שלא נכללות בהיקף לא יכולות להשפיע באופן שלילי על מערכות שנכללות בו.
חשוב לוודא שאתם מבינים את הנסיבות המיוחדות שספציפיות לסביבה שלכם, כמו:
- אם אתם אוספים נתונים של בעלי כרטיסים בטלפון או דרך מערכת VOIP, כדאי לעיין בבעיות הנוספות שקשורות להיקף השימוש שמתוארות במאמר הגנה על נתונים של כרטיסי תשלום שמבוססים על טלפון (PDF).
- אם ספק השירות שלכם צריך גישה לסביבת נתוני הכרטיסים (CDE) שלכם (PDF) כדי להפעיל מערכת נקודת מכירה, יכול להיות שהמערכת שספק השירות שלכם משתמש בה תיחשב כמערכת שמחוברת למערכת שלכם. יכול להיות שיהיה צורך בהיקף נוסף של בדיקות ובבדיקת נאותות נוספת.
השיטות המומלצות של Google לאבטחה יכולות לעזור לכם להגדיר ולהדגים גבול ברור וניתן להגנה בין מערכות שנכללות בהיקף לבין מערכות לא מהימנות, וכך לסייע בהערכה. כשאתם מנהלים את הגישה והאבטחה על ידי יישום העקרון של הרשאות מינימליות, אתם עוזרים למזער את מספר נקודות החשיפה של נתוני בעלי הכרטיסים, למזער את שטח מתקפה של ה-CDE שלכם, וכתוצאה מכך לצמצם את ההיקף. כשאתם מצמצמים את טביעת הרגל של מערכות שנכללות בהיקף, אתם עוזרים לצמצם את מורכבות המערכת ולייעל את ההערכה שלכם בהתאם לתקן PCI DSS.
הסיכונים של הגדרת היקף שגויה
היקף רחב מדי עלול להוביל להערכות יקרות ולסיכוני תאימות מוגברים. כדי לשמור על היקף מצומצם, מומלץ לתת אמון במספר מצומצם ככל האפשר של מערכות ולהעניק גישה רק למספר מצומצם של משתמשים ייעודיים. באמצעות הערכה קפדנית והערכה עצמית, אפשר לזהות מערכות שלא צריכות להיכלל בהיקף של PCI DSS, לוודא שהן עומדות בהנחיות למערכות שלא נכללות בהיקף, ולהקטין את ההיקף בהתאם. תהליך ההדרה הוא הדרך הבטוחה ביותר לגלות אילו מערכות לא מהימנות, ולוודא שהן לא יכולות להשפיע על המערכות שכלולות בהיקף.
אם אתם צריכים תשתית גדולה כדי לעמוד בדרישות של PCI DSS, אתם עלולים לגרום לכך שמערכות חיצוניות ייכללו בהיקף ההערכה. כשמערכות חיצוניות נכללות בהיקף ההערכה, הדבר עלול לסכן את היכולת שלכם לעמוד בדרישות התאימות. זה גם עלול לפגוע ברמת האבטחה הכוללת שלכם, כי זה מרחיב את שטח הפנים של הסביבה המהימנה שלכם שנכללת בהיקף ההערכה.
עיקרון מרכזי באבטחת רשתות וב-PCI DSS הוא ההנחה שחלק מהרשת או כולה כבר נפרצו. העיקרון הזה מעוגן במודל האבטחה של אפס אמון של Google, שדוחה אבטחה שמבוססת רק על היקף האבטחה, ומעדיף מודל שבו כל מערכת אחראית לאבטחה של עצמה. מודל האבטחה של Google תואם ל-PCI DSS, שבו מומלץ לפרוס את ה-CDE והמערכות שמחוברות אליו במרחב קטן ומהימן שמפולח מסביבת ה-IT הרחבה יותר שלכם, ולא לערבב אותו איתה.
בסביבת ה-PCI שלכם, אל תמקמו את ה-CDE במרחב גדול ומהימן עם היקף רחב. הדבר עלול ליצור תחושת ביטחון כוזבת ולפגוע באסטרטגיית הגנה הוליסטית. אם תוקף פורץ את אבטחת המתחם, הוא יכול לפעול בקלות בתוך אינטראנט פרטי ומהימן. כדאי לחשוב על דרכים לצמצם את המרחב המהימן כך שיכלול רק את מה שנדרש להפעלה ולאבטחה שלו, ולא להסתמך רק על אבטחת היקף. הבנה של העקרונות האלה ופעולה לפיהם יעזרו לכם לתכנן את סביבת הענן כך שתעזור לכם לאבטח את המערכות הקריטיות ולצמצם את הסיכון לזיהום ממערכות שנפרצו.
סביבה גדולה של מערכות מהימנות שכלולה בהיקף הבדיקה דורשת מערכת ניהול גדולה באופן דומה כדי לשמור על מעקב רציף, תחזוקה, ביקורת ומלאי של המערכות האלה. מורכבות ארכיטקטורת המערכת, תהליכי ניהול השינויים ומדיניות בקרת הגישה עלולים ליצור סיכוני אבטחה ותאימות. קושי בתחזוקת תהליכי הניטור האלה עלול להוביל לקשיים בעמידה בדרישות PCI DSS 10 ו-11. חשוב להבין את הסיכונים האלה ולהטמיע אסטרטגיות להגבלת היקף הסביבה שנבדקת. מידע נוסף זמין בהמשך המאמר, בקטע תמיכה בתאימות מתמשכת.
שירותים בהיקף של PCI DSSGoogle Cloud
לפני שמתחילים לצמצם את היקף סביבת ה-PCI, חשוב להבין אילו שירותים נכללים בתקן PCI DSS. השירותים האלה מספקים תשתית שעליה אפשר לבנות שירות או אפליקציה משלכם שמאחסנים, מעבדים או מעבירים נתונים של בעלי כרטיסים. Google Cloud
אסטרטגיות לצמצום ההיקף
בקטע הזה נדון באסטרטגיות הבאות לצמצום היקף ההערכה: אמצעי בקרה על היררכיית המשאבים, פילוח של VPC Service Controls וטוקניזציה. במקום לבחור גישה אחת, כדאי להשתמש בכל האסטרטגיות האלה כדי למקסם את הפוטנציאל לצמצום היקף החשיפה.
אין פתרון אוניברסלי להגדרת היקף התאימות לתקן PCI. יכול להיות שיש לכם פתרון פילוח קיים ברשת מקומית, או פתרון לעיבוד כרטיסי אשראי, ולכן עיצוב התשתית שלכם עשוי להיות שונה ממה שמתואר כאן. אפשר להשתמש בשיטות האלה כעקרונות שאפשר ליישם בסביבה שלכם.
הגדרת אמצעי בקרה בהיררכיית המשאבים
המשאבים ב-Google Cloud מאורגנים בהיררכיה באופן הבא:
- משאב הארגון הוא צומת הבסיס בהיררכיית המשאבים של Google Cloud . משאבי הארגון מכילים משאבי תיקיות ופרויקטים. כללי המדיניות של בקרת הגישה בניהול הזהויות והרשאות הגישה (IAM) שמוחלים על משאב הארגון חלים גם על כל המשאבים של הארגון בהיררכיה.
- תיקיות יכולות להכיל פרויקטים ותיקיות אחרות, ולשלוט בגישה למשאבים שלהן באמצעות הרשאות IAM ברמת התיקייה. בדרך כלל משתמשים בתיקיות כדי לקבץ פרויקטים דומים.
- פרויקטים הם גבולות אמון לכל המשאבים שלכם, והם נקודת אכיפה של IAM.
כדי לצמצם את היקף ההערכה, מומלץ לפעול בהתאם לשיטות המומלצות של Google להגדרת היררכיית המשאבים. בתמונה הבאה מוצגת דוגמה להיררכיית משאבים לצורך עמידה בדרישות PCI:
באיור 4, כל הפרויקטים שנמצאים בהיקף של PCI מקובצים בתיקייה אחת כדי לבודד אותם ברמת התיקייה. התיקייה בהיקף PCI מכילה את סביבת ה-CDE ועוד פרויקט שמכיל שירותים משותפים. כשמטמיעים היררכיית משאבים דומה, התיקייה עם ההיקף של PCI יוצרת שורש לוגי של היקף התאימות ל-PCI. כך תוכלו להבטיח שרק משתמשים ייעודיים יוכלו לגשת לתיקייה הזו ולפרויקטים שבה, ולמנוע מתיקיות, פרויקטים ומשאבים אחרים בהיררכיה להיכלל בהיקף ההערכה.
כשמעניקים למשתמשים גישה רק לתיקיות ולפרויקטים שהם צריכים, לפי הצורך, מוודאים שרק משתמשים מיועדים מקבלים גישה לרכיבים שכלולים בהיקף. כך אפשר לעמוד בדרישות 7.2 ו-7.3 של PCI DSS (PDF) ובדרישות אחרות. כדי לוודא שההרשאות לארגון ולתיקיות ברמת ההורה מוגדרות בצורה מתאימה, חשוב להבין את ההשלכות של העברת מדיניות בירושה. כדי לעמוד בדרישה 8.4.1 של PCI DSS, חשוב להטמיע אימות דו-שלבי למשתמשים מיועדים, ולעיין בתוסף PCI DSS בנושא הנחיות לאימות רב-גורמי (PDF). כדי לאכוף תאימות בהיררכיית המשאבים, חשוב להבין איך מגדירים אילוצים של מדיניות הארגון. האילוצים האלה תומכים בתאימות מתמשכת ויכולים לעזור להגן על סביבות מהימנות מפני העלאת רמת ההרשאות.
כמו בכל תאימות ל-PCI, נדרשים רישום ביומן ומעקב הולמים של הסביבה ושל הרכיבים שכלולים בה כדי להגדיר היקף ברור. היררכיית המשאבים קשורה באופן הדוק לניהול זהויות והרשאות גישה, ורישום ביומן, ביקורת ומעקב יעילים אחר פעולות המשתמשים נחוצים כדי לאכוף ולשמור על ההפרדה.
הטמעת סגמנטציה של רשת
פילוח רשת הוא דפוס ארכיטקטורה חשוב שעוזר לאבטח את סביבת ה-CDE והמערכות המחוברות אליה, כפי שמתואר במדריך הנוסף של PCI SSC בנושא פילוח רשת (PDF). כשמיישמים אותו בצורה נכונה, פילוח הרשת מצמצם את היקף ההערכה על ידי הסרת נתיבי רשת שמערכות לא מהימנות עשויות להשתמש בהם כדי לגשת לסביבת ה-CDE או לרכיבים המחוברים שלה. צריך להגדיר רק את הנתיבים שנדרשים כדי לאפשר תקשורת בין רכיבים מהימנים. כשאין למערכות לא מהימנות נתיב שדרכו הן יכולות לשלוח או לקבל מנות נתונים ממערכות מהימנות, המערכות הלא מהימנות לא נכללות בהיקף ההערכה ולא יכולות להשפיע על האבטחה של הרכיבים שנכללים בהיקף ההערכה.
כדי להטמיע פילוח רשת, צריך למקם את סביבת ה-CDE בענן וירטואלי פרטי (VPC) ייעודי עם VPC Service Controls מופעלים. צריך ליצור את ה-VPC הזה במצב מותאם אישית כדי לוודא שלא נוצרים תתי-רשתות או נתיבים מיותרים שיאפשרו גישת ברירת מחדל לרשתות מהימנות. צריך להטמיע אילוצים של מדיניות הארגון כדי לוודא שאי אפשר לשתף את ה-VPC הזה עם פרויקטים אחרים, ושאפשר לקשר אותו רק לרשתות מהימנות אחרות.
בתרשים הבא מוצג הקשר ההדוק בין אסטרטגיית פילוח הרשת לבין היררכיית המשאבים. התרשים מבוסס על היררכיית משאבים עם תיקייה אחת לסביבת PCI שבתחום הבקרה, ושני פרויקטים בתיקייה הזו עבור CDE ושירותים משותפים.
באיור 5, פרויקט השירותים המשותפים לא נכלל בסביבת ה-CDE, אבל הוא מערכת מקושרת ולכן הוא נכלל בהיקף של PCI. הגישה לסביבת ה-CDE מוגבלת ברמת הרשת על ידי מאזן העומסים וכללי חומת האש או מדיניות חומת האש, כדי להגן על הרשתות האלה ולעמוד בדרישות PCI DSS 1.2 ו-1.3. מערכת הטוקניזציה ומערכת התשלומים ממוקמות ברשתות משנה נפרדות, והתקשורת ביניהן מנוהלת על ידי כללי חומת אש בין כל רשת משנה כדי לאפשר רק את התקשורת הנדרשת. פונקציות הרישום ביומן, המעקב וההתראות הנדרשות שעומדות בדרישות PCI DSS 10.2, 10.4 ו-10.5 נמצאות בפרויקט נפרד. השירותים המשותפים וסביבת הנתונים (CDE) נמצאים בתוך היקף אבטחה של VPC Service Controls כדי להגן מפני טעויות בהגדרות או פגיעה באמצעי בקרת הגישה של IAM.
אם הפריסה שלכם מתבצעת ב-Google Kubernetes Engine (GKE), יש עוד דרכים לפלח את סביבת הנתונים של כרטיסי התשלום ולהגן על נתוני בעלי הכרטיסים מפני מערכות לא מהימנות:
- מרחבי שמות מספקים שכבת בידוד נוספת של בקרת גישה, שבה אפשר להעניק למשתמשים גישה רק לפודים, לשירותים ולפריסות מסוימים באשכול Kubernetes. זה שימושי כדי לספק גישה מפורטת יותר למשתמשים ייעודיים.
- מדיניות הרשת יכולה לבודד בין Pods ושירותים כדי להגביל את זרימת הנתונים, וגם לספק שכבת פילוח נוספת ברשת בתוך האשכול.
- PodSecurity הוא בקר כניסה של Kubernetes שמאפשר להחיל תקני אבטחה של Pod על Pods שפועלים באשכול GKE.
כל אחת מהשכבות האלה היא חלק חשוב מהאסטרטגיה שלכם להגנה מעמיקה, ועוזרת לצמצם את היקף הפעולה על ידי בידוד והגנה נוספים על הרכיבים המהימנים שלכם מהסביבה שמסביב. אם אתם פורסים את כל סביבת ה-CDE או חלק ממנה באמצעות Kubernetes, תוכלו לקרוא מידע נוסף על הפעלת סביבה שתואמת לתקן PCI ב-GKE.
הטמעה של המרה לטוקנים
טוקניזציה היא תהליך של הסתרת מספר חשבון ראשי (PAN) באופן בלתי הפיך. אי אפשר להמיר PAN שעבר טוקניזציה, או טוקן, בחזרה ל-PAN באמצעות חישובים מתמטיים. בפרק 3 של התוספת להנחיות בנושא טוקניזציה (PDF), PCI SSC מספק הנחיות לגבי ההשפעה של טוקניזציה על היקף הבדיקה. היקף הבדיקה של PCI DSS מושפע מאוד מהרכיבים שבהם מאוחסנים ומועברים נתוני בעלי הכרטיסים. כשמיישמים טוקניזציה בצורה נכונה, היא יכולה לעזור לצמצם את היקף הבדיקה על ידי מזעור המקרים שבהם מופיעים מספרים של חשבונות ראשיים והעברתם.
טוקניזציה היא גם סוג של פילוח לפי זרימת נתונים, כי היא מפרידה בין מערכות שמאחסנות ומשדרות נתונים של בעלי כרטיסים לבין מערכות שיכולות לבצע פעולות באמצעות טוקנים בלבד. לדוגמה, יכול להיות שמערכות שמנתחות פעילות של צרכנים כדי לזהות הונאות לא צריכות מספרי כרטיסים, אלא יכולות לבצע את הניתוחים האלה באמצעות נתונים שעברו טוקניזציה. טוקניזציה גם מוסיפה שכבת הפרדה בין מערכות שמאחסנות ומשדרות מספרי כרטיסים לבין אפליקציית האינטרנט של המסחר האלקטרוני. כשאפליקציית האינטרנט מקיימת אינטראקציה רק עם מערכות שמשתמשות בטוקנים, יכול להיות שאפשר להסיר את אפליקציית האינטרנט מהקבוצה של המערכות המחוברות, וכך לצמצם את ההיקף.
בתרשים הבא מוצג אופן הטיפול בנתוני כרטיס, במספר כרטיס ובנתונים שעברו טוקניזציה במערכת טוקניזציה טיפוסית:
באיור 6, מספר כרטיס בנקאי (PAN) ונתונים אחרים של בעל הכרטיס מתקבלים מהמשתמש, ואז הנתונים נשלחים מיד לשירות הטוקניזציה. שירות הטוקניזציה מצפין את מספר הכרטיס הבנקאי, יוצר טוקן ואז מאחסן את שניהם בכספת טוקנים מאובטחת. רק שירותים ייעודיים, כמו שירות הסליקה, יכולים לגשת לכספת ברשת, והם מורשים לממש מספר כרטיס בנקאי באמצעות טוקן שנוצר. שירות הסליקה משתמש במספר הכרטיס הבנקאי רק כדי לשלוח אותו למעבד התשלומים. מספר הכרטיס הבנקאי או נתונים אחרים של בעל הכרטיס לא מופיעים אף פעם מחוץ לזרימת הנתונים המבוקרת הזו. כחלק מאסטרטגיית הגנה לעומק, הארכיטקטורה משתמשת גם בSensitive Data Protection כשכבת הגנה נוספת מפני דליפה לא מכוונת של מספרי כרטיסים בנקאיים או נתונים אחרים של בעלי הכרטיסים.
באיור 6, מערכת הטוקניזציה משתמשת ב-Hashicorp Vault, מאגר סודיות שמור בקפידה, כדי לנהל את המיפויים של PAN לטוקן. רק משתמשים ושירותים מורשים יכולים לממש מספר PAN מאסימון באמצעות תהליך חיפוש. אפשר לתת לרכיבים שמורשים לגשת לכספת האסימונים גישה מוגבלת בזמן, כך שהרכיב יוכל לממש מספר כרטיס בנקאי רק במהלך חלון הזמן הספציפי שנדרש לו כדי לבצע את הפונקציה שלו. יכול להיות שמאגרי נתונים אחרים יתאימו גם הם, בהתאם לדרישות העסקיות שלכם. מידע נוסף על הטמעה מאובטחת של טוקניזציה בסביבה שלכם זמין במאמר יצירת טוקנים לנתונים רגישים של בעלי כרטיסים לצורך תאימות ל-PCI DSS.
דוגמה לארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה לדוגמה לעיבוד עסקאות עם טוקנים באמצעות Pub/Sub ו-Dataflow, ולאחסון רשומות של עסקאות עם טוקנים ב-Spanner.
באיור 7, פרויקט עיבוד העסקאות הוא מערכת מקושרת ל, והוא נכלל בהיקף של PCI. זו לא בעיה שמשפיעה על האבטחה, כי פריצה לרכיב כלשהו בפרויקט של עיבוד העסקאות לא יכולה לספק לתוקף גישה ל-CHD. הפרויקט של אפליקציית האינטרנט לא נכלל בהיקף, כי הוא לא מתחבר לסביבת הנתונים המשותפת, ומתקשר רק עם נתונים שעברו ניקוי.
הנתונים שעברו טוקניזציה נשלחים מ-CDE אל Pub/Sub. לפני שנתונים שעברו טוקניזציה מתפרסמים למנויים אחרים, Sensitive Data Protection מוודאת שהם לא מכילים נתוני כרטיסי אשראי. הנתונים שעברו טוקניזציה מעובדים על ידי Dataflow ומאוחסנים במסד הנתונים של טרנזקציות ב-Spanner. אפשר לשייך עסקאות למשתמשים ספציפיים באמצעות אסימונים בלי לגשת למספרי כרטיסי אשראי. אפשר גם להשתמש במסד הנתונים של טרנזקציות ב-Spanner כדי ליצור דוחות ולנתח נתונים באמצעות כלים של בינה עסקית (BI) כמו Looker.
תמיכה בתאימות רציפה
אבטחה ותאימות הן יותר מארכיטקטורה נכונה והנדסה טובה. ארכיטקטורה נכונה יכולה להראות שהסביבה שלכם מתוכננת בצורה מאובטחת בתיאוריה. כדי לוודא שהסביבה שלכם תישאר מאובטחת בפועל, אתם צריכים גם תהליכים יעילים של ביקורת, רישום ביומן, מעקב ותיקון.
כדי לעמוד בדרישות של כל אחת מ-12 קטגוריות הדרישות של PCI DSS, אתם צריכים לעקוב באופן שוטף אחרי היישום של הדרישה הזו. אתם צריכים להוכיח לעצמכם ולבודק שכל רכיב בהיקף הבדיקה יישאר מאובטח בעתיד, הרבה אחרי שהערכת PCI DSS תסתיים. פיקוח נאות בשילוב עם פעולות תיקון מהירות נקרא תאימות מתמשכת. תאימות מתמשכת היא דרישה של PCI DSS, וכשמיישמים אותה בצורה נכונה, היא יכולה לעזור למקסם את ההשפעה של שאר האסטרטגיות לצמצום היקף הבדיקה.
Google Cloud מאפשר לכם לרשום ביומן כל מה שקורה ברשת באמצעות רישום ביומן של כללי חומת אש, יומני זרימה של VPC, יומנים של VPC Service Controls ויומנים של Cloud Load Balancing. אפשר לעקוב אחרי הפעילות של המערכות והמשתמשים באמצעות יומני הביקורת של Cloud. מעקב קבוע אחרי היומנים האלה עוזר לכם לעמוד בדרישות של PCI DSS 10.4, ומאפשר לכם להגיב במהירות לאיומי אבטחה פוטנציאליים ולטפל בהם. מידע נוסף זמין בתוסף PCI DSS בנושא מעקב יעיל אחר יומנים יומיים (PDF).
Security Command Center מאפשר לכם להבין את האבטחה ואת פני השטח של מתקפות על הנתונים שלכם באמצעות מתן מלאי נכסים, גילוי, חיפוש וניהול. Security Command Center יכול לנתח את תוצאות הסריקה של Sensitive Data Protection כדי לזהות נתוני כרטיסי אשראי שדלפו, וכדי לוודא שלא נעשה שימוש לרעה במערכת הטוקניזציה שלכם כדי לפדות מספרי כרטיסי אשראי באופן זדוני. באמצעות Event Threat Detection, Security Command Center יכול לעזור לכם לזהות באופן יזום איומים ופעילות חריגה ברשת ובמכונות הווירטואליות שלכם, שיכולים להצביע על כך שתוקף בודק את המערכת כדי לזהות את יכולות ההגנה שלה. בנוסף, Security Command Center מאפשר לכם ליצור מקורות אבטחה בהתאמה אישית שספציפיים לסביבה שלכם.
Google Cloud Armor יכול לספק הגנה נוספת לאפליקציות Google Cloud אינטרנט שפתוחות לציבור ולעזור לכם לעמוד בדרישה 6.4 של PCI DSS. Cloud Armor מעריך בקשות נכנסות למגוון של מתקפות נפוצות באינטרנט, ויכול לעזור לכם להימנע מבדיקות קוד ידניות שדורשות הרבה עבודה, כפי שמצוין בדרישה 6.4. WAF עוזר לכם לשמור על תאימות רציפה, תוך הפחתת העלויות והסיכונים השוטפים של התאימות.
המאמרים הבאים
- כדאי לעיין בשיטות מומלצות לניהול חובות תאימות.
- מידע נוסף על תאימות לתקן אבטחת הנתונים המקובל ב-PCI ב- Google Cloud
- הנחיות של מועצת PCI בנושא הגדרת היקף של PCI DSS ופילוח רשת (PDF)
- אפשר לנסות את התוכנית של PCI ב-GKE.
- אבטחת עומסי עבודה (workload) של Kubernetes בהתאם ל-PCI DSS.
- טוקניזציה של נתונים רגישים של בעלי כרטיסים לצורך עמידה בדרישות PCI DSS
- פורסים את פרויקט Terraform למתחילים בנושא PCI.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.