המדריך הזה נועד לעזור לכם לטפל בבעיות שייחודיות לאפליקציות של Google Kubernetes Engine (GKE) כשאתם מיישמים את האחריות של הלקוח לדרישות של תקן אבטחת הנתונים המקובל בתעשיית כרטיסי התשלום (PCI DSS).
כתב ויתור: המדריך הזה מיועד למטרות מידע בלבד. Google לא מתכוונת שהמידע או ההמלצות במדריך הזה יהוו ייעוץ משפטי או ייעוץ בנושא ביקורת. כל לקוח אחראי לבצע הערכה עצמאית של השימוש הספציפי שלו בשירותים, בהתאם לצורך, כדי לתמוך בהתחייבויות המשפטיות והתחייבויות התאימות שלו.
מבוא לתאימות ל-PCI DSS ול-GKE
אם אתם מטפלים בנתונים של כרטיסי תשלום, אתם צריכים לאבטח אותם – בין אם הם נמצאים במסד נתונים מקומי או בענן. התקן PCI DSS פותח כדי לעודד ולשפר את אבטחת המידע של בעלי הכרטיסים, ולסייע באימוץ נרחב של אמצעי אבטחת מידע עקביים ברחבי העולם. תקן PCI DSS מספק בסיס של דרישות טכניות ותפעוליות שנועדו להגן על נתוני כרטיסי אשראי. תקן PCI DSS חל על כל הישויות שמעורבות בעיבוד של כרטיסי תשלום – כולל מוכרים, מעבדי תשלומים, בנקים רוכשים, בנקים מנפיקים וספקי שירותים. התקן PCI DSS חל גם על כל ישות אחרת שמאחסנת, מעבדת או מעבירה נתונים של בעלי כרטיסים (CHD) או נתוני אימות רגישים (SAD), או את שניהם.
אפליקציות מבוססות-קונטיינרים הפכו לפופולריות לאחרונה, ועומסי עבודה רבים מדור קודם עוברים מארכיטקטורה מבוססת-מכונה וירטואלית (VM) לארכיטקטורה מבוססת-קונטיינר. Google Kubernetes Engine (GKE) היא סביבה מנוהלת ומוכנה לייצור לפריסת אפליקציות בקונטיינרים. הוא כולל את החידושים האחרונים של Google בתחומים של פרודוקטיביות מפתחים, יעילות משאבים, פעולות אוטומטיות וגמישות של קוד פתוח, כדי להאיץ את זמן היציאה לשוק.
התאימות היא אחריות משותפת בענן. Google Cloud, כולל GKE (במצבי הפעולה Autopilot ו-Standard), עומדת בדרישות של PCI DSS. האחריות שלנו מפורטת בטבלת האחריות המשותפת.
הקהל המיועד
- לקוחות שרוצים להעביר עומסי עבודה שתואמים לתקן PCI אל Google Cloud שכולל GKE.
- מפתחים, קציני אבטחה, קציני תאימות, אדמינים של IT ועובדים אחרים שאחראים להטמעת אמצעי בקרה ולהבטחת תאימות לדרישות של PCI DSS.
לפני שמתחילים
כדי ליישם את ההמלצות הבאות, יכול להיות שתצטרכו להשתמש ב:
- Google Cloud משאבים של ארגון, תיקייה ופרויקט
- ניהול זהויות והרשאות גישה (IAM)
- Google Kubernetes Engine
- Google Cloud VPCs
- Google Cloud Armor
- Cloud Data Loss Prevention API (חלק מ-Sensitive Data Protection)
- שרת proxy לאימות זהויות (IAP)
- Security Command Center
המדריך הזה מיועד למי שמכיר קונטיינרים ו-GKE.
היקף
במדריך הזה מפורטות הדרישות הבאות של PCI DSS שרלוונטיות באופן ייחודי ל-GKE, ומוצעות הנחיות שיעזרו לכם לעמוד בהן. הוא נכתב בהתאם לגרסה 4.0 של התקן. המדריך הזה לא כולל את כל הדרישות בתקן PCI DSS. המידע שמופיע במדריך הזה עשוי לעזור לארגונים לעמוד בדרישות של PCI DSS, אבל הוא לא מהווה ייעוץ מקיף. ארגונים יכולים להעסיק בוחן אבטחה מוסמך (QSA) של PCI כדי לקבל אימות רשמי.
הסברים על המונחים
בקטע הזה מוגדרים המונחים שבהם נעשה שימוש במדריך הזה. לפרטים נוספים, אפשר לעיין במילון המונחים של PCI DSS.
- CHD
נתוני בעלי כרטיסים. לפחות, מורכב ממספר החשבון הראשי המלא (PAN). נתוני בעל הכרטיס עשויים להופיע גם בצורה של מספר PAN מלא בתוספת כל אחד מהפרטים הבאים:
- שם בעל הכרטיס
- תאריך התפוגה או קוד השירות
- נתוני אימות רגישים (SAD)
- CDE
סביבת נתונים של בעלי כרטיסים. האנשים, התהליכים והטכנולוגיה שמאחסנים, מעבדים או מעבירים נתונים של בעלי כרטיסים או נתוני אימות רגישים.
- PAN
מספר חשבון ראשי. נתון חשוב של בעל הכרטיס שאתם מחויבים להגן עליו בהתאם לתקן PCI DSS. מספר ה-PAN הוא בדרך כלל מספר בן 16 ספרות שייחודי לכרטיס תשלום (כרטיס אשראי וכרטיס חיוב מיידי) ומזהה את המוסד המנפיק ואת חשבון בעל הכרטיס.
- קוד אימות
מספר תעודת זהות אישי. סיסמה מספרית שמוכרת רק למשתמש ולמערכת, ומשמשת לאימות המשתמש במערכת.
- QSA
מעריך אבטחה מוסמך. אדם שקיבל הסמכה מהמועצה לתקני אבטחה של PCI לבצע ביקורות וניתוחי תאימות.
- SAD
נתוני אימות רגישים. במסגרת התאימות לתקן PCI, הנתונים שמשמשים את מנפיקי הכרטיסים לאישור עסקאות. בדומה לנתונים של בעלי כרטיסים, תקן PCI DSS מחייב הגנה על SAD. בנוסף, מוכרים ומעבדי התשלומים שלהם לא יכולים לשמור את נתוני ה-SAD. ה-SAD כולל את הפריטים הבאים:
- מעקב אחרי נתונים מרצועות מגנטיות
- "מעקב אחרי נתונים מקבילים" שנוצרים על ידי כרטיסים עם שבב וכרטיסים לתשלום ללא מגע
- קודי אימות אבטחה (לדוגמה, המספר בן 3 או 4 הספרות שמודפס על כרטיסים) שמשמשים לעסקאות באינטרנט ולעסקאות שבהן הכרטיס לא מוצג.
- קודים סודיים ובלוקים של קודים סודיים
- פילוח
בהקשר של PCI DSS, שיטת הבידוד של סביבת נתוני כרטיסי האשראי (CDE) משאר הרשת של הישות. פילוח לא נדרש על ידי PCI DSS. עם זאת, מומלץ מאוד להשתמש בשיטה הזו כדי לצמצם את הדברים הבאים:
- היקף ההערכה של PCI DSS והעלות שלה
- העלות והקושי בהטמעה ובתחזוקה של אמצעי בקרה של PCI DSS
- הסיכון לארגון (מופחת על ידי איחוד נתוני בעלי הכרטיסים למספר קטן יותר של מיקומים מבוקרים)
פילוח של סביבת נתוני כרטיסי האשראי
סביבת הנתונים של בעלי כרטיסים (CDE) כוללת אנשים, תהליכים וטכנולוגיות שמאחסנים, מעבדים או מעבירים נתונים של בעלי כרטיסים או נתוני אימות רגישים. בהקשר של GKE, סביבת ה-CDE כוללת גם את הרכיבים הבאים:
- מערכות שמספקות שירותי אבטחה (לדוגמה, IAM).
- מערכות שמסייעות בפילוח (לדוגמה, פרויקטים, תיקיות, חומות אש, עננים וירטואליים פרטיים (VPC) ותת-רשתות).
- פודים וקלאסטרים של אפליקציות שמאחסנים, מעבדים או מעבירים נתונים של בעלי כרטיסים. בלי פילוח הולם, כל טביעת הרגל שלכם בענן יכולה להיכלל בהיקף של PCI DSS.
כדי שרכיב מערכת ייחשב כלא רלוונטי ל-PCI DSS, הוא צריך להיות מבודד כראוי מה-CDE, כך שגם אם האבטחה שלו תיפרץ, זה לא ישפיע על האבטחה של ה-CDE.
תנאי מוקדם חשוב לצמצום ההיקף של סביבת נתוני הכרטיסים (CDE) הוא הבנה ברורה של הצרכים והתהליכים העסקיים שקשורים לאחסון, לעיבוד ולשידור של נתוני בעלי הכרטיסים. כדי להגביל את נתוני בעלי הכרטיסים למספר המיקומים הקטן ביותר האפשרי על ידי ביטול נתונים מיותרים ואיחוד נתונים נחוצים, יכול להיות שתצטרכו לשנות שיטות עסקיות קיימות.
יש כמה דרכים לפלח את סביבת ה-CDE ב-Google Cloud. בקטע הזה נדון באמצעים הבאים:
- פילוח לוגי באמצעות היררכיית המשאבים
- פילוח רשת באמצעות VPC ורשתות משנה
- פילוח ברמת השירות באמצעות VPC
- שיקולים נוספים לגבי כל אשכול שנכלל בהיקף
פילוח לוגי באמצעות היררכיית המשאבים
יש כמה דרכים לבודד את סביבת ה-CDE במבנה הארגוני באמצעות היררכיית המשאבים של Google Cloud. המשאבים ב- Google Cloudמאורגנים בהיררכיה.Google Cloud משאב הארגון הוא הצומת הבסיסי (root) בהיררכיית המשאבים ב- Google Cloud . תיקיות ופרויקטים נמצאים תחת משאב הארגון. תיקיות יכולות להכיל פרויקטים ותיקיות. משתמשים בתיקיות כדי לשלוט בגישה למשאבים בהיררכיית התיקיות באמצעות הרשאות IAM ברמת התיקייה. הם משמשים גם לקיבוץ פרויקטים דומים. פרויקט הוא גבול מהימן לכל המשאבים שלכם ונקודת אכיפה של IAM.
אפשר לקבץ את כל הפרויקטים שנמצאים בהיקף של PCI בתיקייה כדי לבצע בידוד ברמת התיקייה. אפשר גם להשתמש בפרויקט אחד לכל האשכולות והאפליקציות שנמצאים בהיקף של PCI, או ליצור פרויקט ואשכול לכל אפליקציה שנמצאת בהיקף של PCI ולהשתמש בהם כדי לארגן את המשאבים שלכם ב-Google Cloud . בכל מקרה, מומלץ לשמור את עומסי העבודה שנמצאים בהיקף של PCI ואת אלה שלא נמצאים בהיקף של PCI בפרויקטים שונים.
פילוח רשת באמצעות רשתות VPC ורשתות משנה
אתם יכולים להשתמש בענן וירטואלי פרטי (VPC) ובתת-רשתות כדי להקצות את הרשת, ולקבץ ולבודד משאבים שקשורים לסביבת CDE. VPC הוא בידוד לוגי של חלק בענן ציבורי. רשתות VPC מספקות רשתות גמישות וניתנות להתאמה למכונות הווירטואליות (VM) ב-Compute Engine ולשירותים שמשתמשים במכונות וירטואליות, כולל GKE. מידע נוסף זמין בסקירה הכללית על VPC ובמאמר בנושא שיטות מומלצות ודוגמאות לארכיטקטורות.
פילוח ברמת השירות באמצעות VPC Service Controls ו-Cloud Armor
רשתות VPC ותת-רשתות מספקות פילוח ויוצרות גבול גזרה לבידוד של סביבת ה-CDE, אבל VPC Service Controls מרחיב את גבול האבטחה בשכבה 7. אתם יכולים להשתמש ב-VPC Service Controls כדי ליצור גבולות גזרה סביב פרויקטים של CDE שנמצאים בהיקף. VPC Service Controls מספק לכם את האמצעים הבאים לשליטה:
- שליטה בתעבורת נתונים נכנסת (ingress). רק זהויות ולקוחות מורשים יכולים להיכנס למתחם האבטחה שלכם.
- שליטה בגישה יוצאת. רק יעדים מורשים יכולים לגשת לזהויות וללקוחות בתוך היקף האבטחה.
אתם יכולים להשתמש ב-Cloud Armor כדי ליצור רשימות של כתובות IP שמהן תותר או תיחסם הגישה למאזן העומסים של HTTP(S) בקצה הרשת של Google Cloud . בדיקת כתובות IP קרוב ככל האפשר למשתמש ולתעבורה זדונית עוזרת למנוע מתעבורה זדונית לצרוך משאבים או להיכנס לרשתות ה-VPC שלכם.
משתמשים ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות סביב הפרויקטים שכלולים בהיקף. הגבולות האלה שולטים בנתיבים של מכונות וירטואליות לשירותים ושירותים לשירותים, וגם בתעבורת נתונים נכנסת (ingress) ויוצאת (egress) ב-VPC.
יצירה ותחזוקה של רשת ומערכות מאובטחות
הדרישות 1 ו-2 של PCI DSS מתייחסות ליצירה ולתחזוקה של רשת מאובטחת.
דרישה 1
התקנה ותחזוקה של הגדרות חומת אש להגנה על נתונים של בעלי כרטיסים ותעבורה אל סביבת ה-CDE וממנה.
המושגים שקשורים לרשתות של קונטיינרים ו-GKE שונים מאלה שקשורים למכונות וירטואליות. פודים יכולים לתקשר ישירות ביניהם, בלי NAT, גם בין צמתים. כך נוצרת טופולוגיית רשת פשוטה, שיכולה להיות מפתיעה אם אתם רגילים לנהל מערכות מורכבות יותר. השלב הראשון באבטחת רשת ב-GKE הוא ללמוד על המושגים האלה שקשורים לרשתות.
לפני שמתעמקים בדרישות הספציפיות במסגרת דרישה 1, כדאי לעיין במושגים הבאים בנושא רשתות בהקשר של GKE:
כללים לחומת אש. כללים לחומת אש משמשים להגבלת התנועה לצמתים. הצמתים ב-GKE מוקצים כמכונות וירטואליות ב-Compute Engine ומשתמשים באותם מנגנונים של חומת אש כמו מכונות וירטואליות אחרות. ברשת שלכם, אתם יכולים להשתמש בתגים כדי להחיל את הכללים האלה של חומת האש על כל מכונה וירטואלית. כל מאגר צמתים מקבל קבוצה משלו של תגים שבהם אפשר להשתמש בכללים. כברירת מחדל, כל מכונה וירטואלית ששייכת למאגר צמתים מקבלת תג שמזהה אשכול GKE ספציפי שמאגר הצמתים הזה הוא חלק ממנו. התג הזה משמש בכללים של חומת האש ש-GKE יוצרת באופן אוטומטי בשבילכם. אתם יכולים להוסיף תגים מותאמים אישית בזמן יצירת האשכול או מאגר הצמתים באמצעות הדגל
--tagsב-Google Cloud CLI.מדיניות רשת. מדיניות רשת מאפשרת להגביל את חיבורי הרשת בין הפודים, מה שיכול לעזור להגביל התקפות pivot ברשת ותנועה לרוחב בתוך האשכול במקרה של בעיית אבטחה בפוד. כדי להשתמש במדיניות רשת, צריך להפעיל את התכונה באופן מפורש כשיוצרים את אשכול ה-GKE. אפשר להפעיל אותה באשכול קיים, אבל הפעולה הזו תגרום להפעלה מחדש של צמתי האשכול. התנהגות ברירת המחדל היא שכל התקשורת בין הפודים תמיד פתוחה. לכן, אם רוצים לפלח את הרשת, צריך לאכוף מדיניות רשת ברמת הפוד. ב-GKE, אפשר להגדיר מדיניות רשת באמצעות Kubernetes Network Policy API או באמצעות הכלי
kubectl. כללי מדיניות התנועה ברמת הפוד קובעים לאילו פודים ושירותים יש גישה אחד לשני בתוך האשכול.מרחבי שמות. מרחבי שמות מאפשרים פילוח של משאבים בתוך אשכול Kubernetes. ל-Kubernetes יש מרחב שמות שמוגדר כברירת מחדל, אבל אפשר ליצור כמה מרחבי שמות באשכול. מרחבי שמות מבודדים זה מזה באופן לוגי. הם מספקים היקף לפודים, לשירותים ולפריסות באשכול, כך שמשתמשים שמבצעים אינטראקציה עם מרחב שמות אחד לא יראו תוכן במרחב שמות אחר. עם זאת, מרחבי שמות באותו אשכול לא מגבילים את התקשורת בין מרחבי שמות. כאן נכנסות לתמונה מדיניות הרשת. מידע נוסף על הגדרת מרחבי שמות זמין בפוסט בבלוג בנושא שיטות מומלצות לשימוש במרחבי שמות.
בתרשים הבא מוצגים המושגים הקודמים ביחס זה לזה ולרכיבים אחרים של GKE, כמו אשכול, צומת ו-Pod.
דרישה 1.1
הוגדרו תהליכים ומנגנונים להתקנה ולתחזוקה של אמצעי בקרה לאבטחת רשתות, והם מובנים.
דרישה 1.1.2
תארו קבוצות, תפקידים ותחומי אחריות לניהול רכיבי רשת.
קודם כול, כמו ברוב השירותים ב- Google Cloud, צריך להגדיר תפקידים ב-IAM כדי להגדיר הרשאה ב-GKE. אחרי שמגדירים את התפקידים ב-IAM, צריך להוסיף הגדרה של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes כחלק מאסטרטגיית ההרשאות ב-Kubernetes.
בעצם, כל הגדרות ה-IAM חלות על כל Google Cloud המשאבים ועל כל האשכולות בפרויקט. הגדרות ה-RBAC של Kubernetes חלות על המשאבים בכל אשכול Kubernetes, ומאפשרות הרשאה מדויקת ברמת מרחב השמות. ב-GKE, הגישות האלה להרשאה פועלות במקביל, והיכולות של המשתמש מייצגות למעשה שילוב של תפקידי IAM ו-RBAC שהוקצו לו:
- משתמשים ב-IAM כדי לשלוט בקבוצות, בתפקידים ובאחריות לניהול לוגי של רכיבי רשת ב-GKE.
- שימוש ב-Kubernetes RBAC כדי להעניק הרשאות גרנולריות לכללי מדיניות של רשת באשכולות Kubernetes, כדי לשלוט בתעבורת נתונים בין קבוצות Pod ולמנוע שינויים לא מורשים או מקריים ממשתמשים שלא שייכים ל-CDE.
- להיות מסוגלים לספק הצדקה לכל המשתמשים וההרשאות ב-IAM וב-RBAC. בדרך כלל, כשבודקי QSA בודקים אמצעי בקרה, הם מחפשים הצדקה עסקית למדגם של IAM ו-RBAC.
דרישה 1.2
אמצעי בקרה לאבטחת רשתות (NSCs) מוגדרים ומתוחזקים.
קודם, מגדירים כללים לחומת האש במכונות Compute Engine שמריצות את הצמתים של GKE. כללים לחומת האש מגנים על הצמתים האלה באשכול.
בשלב הבא, מגדירים מדיניות רשת כדי להגביל את התנועה ולהגן על הפודים באשכול. מדיניות רשת היא מפרט של האופן שבו קבוצות של פודים יכולות לתקשר זו עם זו ועם נקודות קצה אחרות ברשת. אפשר להשתמש באכיפת מדיניות הרשת של GKE כדי לשלוט בתקשורת בין הפודים והשירותים באשכול. כדי לפלח את האשכול עוד יותר, אפשר ליצור בו כמה מרחבי שמות. מרחבי השמות מבודדים זה מזה באופן לוגי. הם מספקים היקף לפודים, לשירותים ולפריסות באשכול, כך שמשתמשים שפועלים במרחב שם אחד לא יראו תוכן במרחב שם אחר. עם זאת, מרחבי שמות באותו אשכול לא מגבילים את התקשורת ביניהם. כאן נכנסת לתמונה מדיניות הרשת. מרחבי שמות מאפשרים פילוח של משאבים בתוך אשכול Kubernetes. למידע נוסף על הגדרת מרחבי שמות, אפשר לעיין בפוסט בבלוג בנושא שיטות מומלצות לשימוש במרחבי שמות.
כברירת מחדל, אם לא קיימות מדיניות במרחב שמות, כל התנועה הנכנסת והיוצאת מותרת אל ומפודים במרחב השמות הזה. לדוגמה, אפשר ליצור מדיניות בידוד שמוגדרת כברירת מחדל למרחב שמות על ידי יצירת מדיניות רשת שבוחרת את כל הפודים אבל לא מאפשרת תעבורת נתונים נכנסת (ingress) לאף אחד מהפודים האלה.
דרישה 1.2.2
כל השינויים בחיבורי הרשת ובהגדרות של NSCs מאושרים ומנוהלים בהתאם לתהליך בקרת השינויים שמוגדר בדרישה 6.5.1.
כדי להתייחס לתצורות ולתשתית של הרשת כאל קוד, צריך ליצור צינור עיבוד נתונים של אינטגרציה רציפה (CI) ופיתוח רציף (CD) כחלק מתהליכי ניהול השינויים ובקרת השינויים.
אתם יכולים להשתמש בתבניות של Cloud Deployment Manager או של Terraform כחלק מצינור עיבוד הנתונים של CI/CD כדי ליצור מדיניות רשת באשכולות. באמצעות Deployment Manager או Terraform, אתם יכולים להתייחס לתצורה ולתשתית כאל קוד שיכול לשחזר עותקים עקביים של סביבת הייצור הנוכחית או של סביבות אחרות. לאחר מכן תוכלו לכתוב בדיקות יחידה ובדיקות אחרות כדי לוודא שהשינויים ברשת פועלים כמצופה. אפשר לנהל תהליך של בקרת שינויים שכולל אישור באמצעות קובצי תצורה שמאוחסנים במאגר גרסאות.
בעזרת Terraform Config Validator, אפשר להגדיר אילוצים כדי לאכוף מדיניות אבטחה ומדיניות ניהול. אם מוסיפים את Config Validator לצינור העיבוד של CI/CD, אפשר להוסיף שלב לכל תהליך עבודה. בשלב הזה מאמתים את התוכנית ב-Terraform ודוחים אותה אם נמצאו הפרות.
דרישה 1.2.5
כל השירותים, הפרוטוקולים והיציאות המותרים מזוהים ומאושרים, ויש להם צורך עסקי מוגדר.
כדי להגדיר אמצעי בקרה חזקים על תעבורת הכניסה לאשכולות GKE, אפשר להשתמש ברשתות מורשות כדי להגביל טווחי כתובות IP מסוימים שיכולים להגיע למישור הבקרה של האשכול. GKE משתמש גם ב-Transport Layer Security (TLS) וגם באימות כדי לספק גישה מאובטחת לנקודת הקצה של מישור הבקרה של האשכול מהאינטרנט הציבורי. הגישה הזו מאפשרת לכם לנהל את האשכול מכל מקום. באמצעות רשתות מורשות, אפשר להגביל עוד יותר את הגישה לקבוצות ספציפיות של כתובות IP.
אתם יכולים להשתמש ב-Cloud Armor כדי ליצור רשימות חסימה ורשימות היתרים של כתובות IP וכללי אבטחה לאפליקציות שמתארחות ב-GKE. באשכול GKE, תעבורה נכנסת מטופלת על ידי איזון עומסים ב-HTTP(S), שהוא רכיב של Cloud Load Balancing. בדרך כלל, מאזן העומסים HTTP(S) מוגדר על ידי בקר הכניסה (ingress) של GKE, שמקבל מידע על ההגדרות מאובייקט Ingress של Kubernetes. מידע נוסף זמין במאמר בנושא הגדרת כללי מדיניות של Cloud Armor באמצעות GKE.
דרישה 1.3
הגישה לרשת אל סביבת נתוני כרטיס בעל הכרטיס וממנה מוגבלת.
כדי לשמור על פרטיות של נתונים רגישים, אתם יכולים להגדיר תקשורת פרטית בין אשכולות GKE בתוך רשתות ה-VPC שלכם ובין פריסות היברידיות מקומיות באמצעות VPC Service Controls וגישה פרטית ל-Google.
דרישה 1.3.1
התנועה הנכנסת ל-CDE מוגבלת באופן הבא:
- רק לתנועה שנדרשת.
- כל התנועה האחרת נדחית באופן ספציפי.
כדאי להטמיע הגדרת Cloud NAT עם GKE כדי להגביל את תעבורת האינטרנט הנכנסת רק לאותו אשכול. אפשר להגדיר אשכול פרטי לאשכולות שלא פונים לציבור בסביבת ה-CDE. באשכול פרטי, לצמתים יש רק כתובות IP פנימיות מסוג RFC 1918, מה שמבטיח שהעומסים שלהם מבודדים מהאינטרנט הציבורי.
דרישה 1.4
חיבורים לרשתות בין רשתות מהימנות לבין רשתות לא מהימנות נמצאים בשליטה.
אפשר לעמוד בדרישה הזו באמצעות אותן שיטות שמפורטות בדרישה 1.3.
דרישה 1.4.3
אמצעים למניעת זיוף כתובות IP מיושמים כדי לזהות ולחסום כתובות IP מזויפות שמנסות להיכנס לרשת המהימנה.
כדי לזהות ולחסום כתובות IP מזויפות של מקורות מלהיכנס לרשת, מטמיעים אמצעים למניעת זיוף באמצעות כתובות IP של כינויים בתרמילי GKE ובאשכולות. אשכול שמשתמש בטווחים של כתובות IP של כינויים נקרא אשכול המותאם ל-VPC.
דרישה 1.4.5
חשיפת כתובות IP פנימיות ופרטי ניתוב מוגבלת לצדדים מורשים בלבד.
אתם יכולים להשתמש בסוכן של GKE לשינוי כתובת IP כדי לבצע תרגום של כתובות רשת (NAT) לתרגומים של כתובות IP מסוג רבים-לאחד באשכול. הסוואה מסתירה כמה כתובות IP של מקור מאחורי כתובת אחת.
דרישה 2
החלת הגדרות מאובטחות על כל רכיבי המערכת.
בדרישה 2 מפורטות דרכים להגברת האבטחה של פרמטרים על ידי הסרת ברירות מחדל ופרטי כניסה שסופקו על ידי הספק. הגברת האבטחה של האשכול היא באחריות הלקוח.
דרישה 2.2
רכיבי המערכת מוגדרים ומנוהלים בצורה מאובטחת.
מוודאים שהתקנים האלה מתייחסים לכל נקודות החולשה הידועות באבטחה, ושהם עומדים בתקנים המקובלים בתעשייה לחיזוק המערכת. מקורות של תקנים מקובלים בתעשייה לחיזוק מערכות עשויים לכלול, בין היתר:דרישה 2.2.4
רק שירותים, פרוטוקולים, תהליכי רקע ופונקציות נחוצים מופעלים, וכל הפונקציות שלא נחוצות מוסרות או מושבתות.
דרישה 2.2.5
- ההצדקה העסקית מתועדת.
- תכונות אבטחה נוספות מתועדות ומוטמעות כדי להפחית את הסיכון בשימוש בשירותים, בפרוטוקולים או בתהליכי רקע לא מאובטחים.
דרישה 2.2.6
פרמטרים של אבטחת המערכת מוגדרים כדי למנוע שימוש לרעה.
לפני הפריסה
לפני שמעבירים קונטיינרים ל-GKE, מומלץ לבצע את הפעולות הבאות:
- מתחילים עם תמונת בסיס מנוהלת של קונטיינר שנבנית, מתוחזקת ונבדקת על ידי מקור מהימן. כדאי ליצור קבוצה של תמונות בסיס 'טובות' או 'מושלמות' שהמפתחים יוכלו להשתמש בהן. אפשרות מגבילה יותר היא להשתמש בתמונה ללא הפצה או בתמונה בסיסית של scratch.
- משתמשים ב-Artifact Analysis כדי לסרוק את קובצי האימג' בקונטיינר ולחפש נקודות חולשה.
- כדאי ליצור מדיניות פנימית של DevOps/SecOps שתכלול רק ספריות וקבצים בינאריים מאושרים ומהימנים במאגרי התוכן.
במהלך ההגדרה
במהלך ההגדרה, מומלץ לבצע את הפעולות הבאות:
- משתמשים במערכת ההפעלה שמותאמת לקונטיינרים כברירת מחדל בתור קובץ האימג' של הצומת ב-GKE. מערכת ההפעלה Container-Optimized OS מבוססת על Chromium OS והיא מותאמת לאבטחת צמתים.
- מפעילים שדרוג אוטומטי של צמתים באשכולות שבהם האפליקציות פועלות. התכונה הזו משדרגת אוטומטית את הצומת לגרסת Kubernetes שפועלת במישור הבקרה המנוהל, וכך מספקת יציבות ואבטחה טובות יותר.
- מפעילים את התכונה תיקון אוטומטי של צמתים. כשהתכונה הזו מופעלת, GKE בודק מעת לעת את סטטוס תקינות הצומת ומשתמש בו כדי לקבוע אם צריך לתקן צומת. אם צריך לתקן צומת, המערכת מרוקנת את הצומת ויוצרת צומת חדש שמוסף לאשכול.
- כדי לקבל תצוגה של כל האירועים, כולל אירועי אבטחה וסטטוס תקינות הצומת, מפעילים את Cloud Monitoring ואת Cloud Logging. כדי לקבל התראה אם מתרחש אירוע אבטחה, יוצרים מדיניות התראות ב-Cloud Monitoring.
- החלת חשבונות שירות עם הרשאות מינימליות על צמתי GKE
- חשוב לעיין בקטע GKE במדריך Google Cloud CIS Benchmark ולהחיל את ההמלצות (במקרים הרלוונטיים). רישום ביומן של ביקורת Kubernetes כבר מופעל כברירת מחדל, והיומנים של שתי הבקשות ל-
kubectlול-API של GKE נכתבים ביומני הביקורת של Cloud. - הגדרת רישום ביומן הביקורת.
הגנה על נתוני החשבון
הגנה על נתונים של בעלי כרטיסים כוללת את הדרישות 3 ו-4 של PCI DSS.
דרישה 3
הגנה על נתוני חשבון מאוחסנים.
בדרישה 3 של PCI DSS נקבע ששיטות הגנה כמו הצפנה, חיתוך, מיסוך וגיבוב הן רכיבים חיוניים להגנה על נתוני בעלי כרטיסים. אם פורץ עוקף אמצעי בקרה אחרים לאבטחה ומקבל גישה לנתונים מוצפנים, בלי המפתחות הקריפטוגרפיים המתאימים, הוא לא יכול לקרוא את הנתונים ולא יכול להשתמש בהם.
כדאי גם לשקול שיטות אחרות להגנה על נתונים מאוחסנים, כהזדמנויות פוטנציאליות לצמצום הסיכון. לדוגמה, שיטות לצמצום הסיכון כוללות אי-אחסון של נתוני בעלי כרטיסים אלא אם הדבר נחוץ לחלוטין, חיתוך של נתוני בעלי כרטיסים אם לא נדרש מספר PAN מלא, ואי-שליחה של מספרי PAN לא מוגנים באמצעות טכנולוגיות העברת הודעות למשתמשי קצה, כמו אימייל והודעות מיידיות.
דוגמאות למערכות שבהן יכול להיות שפרטי כרטיס האשראי יישמרו כחלק מתהליכי עיבוד התשלומים כשמריצים אותן ב- Google Cloud :
- קטגוריות של Cloud Storage
- מופעים של BigQuery
- Datastore
- Cloud SQL
חשוב לדעת שנתוני כרטיסי אשראי עלולים להישמר בטעות ביומני תקשורת של שירות לקוחות או באימיילים. מומלץ להשתמש בSensitive Data Protection כדי לסנן את זרמי הנתונים האלה, וכך להגביל את הסביבה הרלוונטית למערכות לעיבוד תשלומים.
חשוב לשים לב שב- Google Cloud, הנתונים מוצפנים במנוחה כברירת מחדל, ומוצפנים בזמן ההעברה כברירת מחדל כשהם עוברים גבולות פיזיים. לא נדרשת הגדרה נוספת כדי להפעיל את אמצעי ההגנה האלה.
דרישה 3.5
מספר חשבון ראשי (PAN) מאובטח בכל מקום שבו הוא מאוחסן.
מנגנון אחד להצגת נתוני PAN בצורה לא קריאה הוא טוקניזציה. למידע נוסף, אפשר לעיין במדריך הפתרונות בנושא יצירת טוקנים לנתונים רגישים של בעלי כרטיסים לצורך עמידה בתקן PCI DSS.
אתם יכולים להשתמש ב-DLP API כדי לסרוק, לגלות ולדווח על נתוני בעלי הכרטיסים. ב-Sensitive Data Protection יש תמיכה מובנית בסריקה ובסיווג של נתוני PAN בני 12 עד 19 ספרות ב-Cloud Storage, ב-BigQuery וב-Datastore. יש לו גם API להזרמת תוכן שמאפשר תמיכה במקורות נתונים נוספים, בעומסי עבודה מותאמים אישית ובאפליקציות. אפשר גם להשתמש ב-DLP API כדי לקטוע (לצנזר) או להצפין את הנתונים.
דרישה 3.6
מפתחות קריפטוגרפיים שמשמשים להגנה על נתוני חשבון מאוחסנים מאובטחים.
Cloud Key Management Service (KMS) היא מערכת אחסון מנוהלת למפתחות קריפטוגרפיים. היא יכולה ליצור מפתחות קריפטוגרפיים, להשתמש בהם, לבצע רוטציה שלהם ולהשמיד אותם. למרות ש-Cloud KMS לא מאחסן סודות באופן ישיר, כמו נתונים של בעלי כרטיסים, אפשר להשתמש בו כדי להצפין נתונים כאלה.
ב-Kubernetes, סודות הם אובייקטים של סודות ב-Kubernetes שמאפשרים לכם לאחסן ולנהל מידע רגיש, כמו סיסמאות, טוקנים ומפתחות.
כברירת מחדל, Google Cloud תוכן של לקוחות שמאוחסן במנוחה מוצפן. GKE מטפל בהצפנה הזו כברירת מחדל ומנהל אותה בשבילכם בלי שתצטרכו לבצע פעולות נוספות. הצפנת סודות בשכבת האפליקציה מספקת שכבת אבטחה נוספת למידע אישי רגיש כמו סודות. באמצעות הפונקציונליות הזו, אתם יכולים לספק מפתח שאתם מנהלים ב-Cloud KMS כדי להצפין נתונים בשכבת האפליקציה. ההגנה הזו מיועדת למקרים שבהם תוקפים מקבלים גישה לעותק של מופע אחסון התצורה של Kubernetes באשכול.
דרישה 4
להגן על נתוני בעלי הכרטיס באמצעות קריפטוגרפיה חזקה במהלך ההעברה ברשתות פתוחות וציבוריות.
הנתונים שכלולים בהיקף צריכים להיות מוצפנים במהלך ההעברה ברשתות שקל לאנשים זדוניים לגשת אליהן, למשל רשתות ציבוריות.
Istio היא רשת שירותים בקוד פתוח שמוטמעת בשקיפות באפליקציות מבוזרות קיימות. Istio מנהל באופן מדרגי את האימות, ההרשאה וההצפנה של התעבורה בין מיקרו-שירותים. זו פלטפורמה שכוללת ממשקי API שמאפשרים לכם לבצע אינטגרציה עם כל פלטפורמה לרישום ביומן, טלמטריה או מערכת מדיניות. סט התכונות של Istio מאפשר להריץ ביעילות ארכיטקטורה מבוזרת של מיקרו-שירותים, ומספק דרך אחידה לאבטחה, לחיבור ולמעקב אחרי מיקרו-שירותים.
דרישה 4.1
תהליכים ומנגנונים להגנה על נתונים של בעלי כרטיסים באמצעות קריפטוגרפיה חזקה במהלך שידור ברשתות ציבוריות פתוחות מוגדרים ומתועדים.
אתם יכולים להשתמש ב-Istio כדי ליצור רשת של שירותים שנפרסו – עם איזון עומסים, אימות משירות לשירות ומעקב. אפשר גם להשתמש בו כדי לספק תקשורת מאובטחת בין שירותים באשכול – עם אימות והרשאה חזקים שמבוססים על זהות, ועל TLS הדדי. TLS בו-זמני (mTLS) הוא לחיצת יד בפרוטוקול TLS שמתבצעת פעמיים, ויוצרת רמת אמון זהה בשני הכיוונים (בניגוד לאמון חד-כיווני בין לקוח לשרת).
Istio מאפשרת לפרוס אישורי TLS לכל אחד מהפודים של GKE באפליקציה. שירותים שפועלים בפוד יכולים להשתמש ב-mTLS כדי לזהות באופן חזק את הזהויות של העמיתים שלהם. התקשורת בין השירותים מועברת במנהרה דרך פרוקסי Envoy בצד הלקוח ובצד השרת. פרוקסי Envoy משתמש במזהי SPIFFE כדי ליצור חיבורי mTLS בין השירותים. מידע על פריסת Istio ב-GKE זמין במסמכי GKE. מידע על גרסאות TLS נתמכות זמין בהפניה לניהול תנועה ב-Istio. מומלץ להשתמש בגרסה 1.2 של TLS ואילך.
אם האפליקציה שלכם חשופה לאינטרנט, כדאי להשתמש באיזון עומסים מסוג HTTP(S) ב-GKE עם ניתוב תעבורת נתונים נכנסת (Ingress) שמוגדר לשימוש ב-HTTP(S). איזון עומסים מסוג HTTP(S), שמוגדר על ידי אובייקט Ingress, כולל את התכונות הבאות:
- הגדרות גמישות לשירותים. אובייקט Ingress מגדיר איך תעבורת הנתונים מגיעה לשירותים שלכם ואיך היא מנותבת לאפליקציה. בנוסף, Ingress יכול לספק כתובת IP אחת למספר שירותים באשכול.
- שילוב עם Google Cloud שירותי רשת. אובייקט Ingress יכול להגדיר Google Cloud תכונות כמו אישורי SSL מנוהלים על ידי Google (בטא), Cloud Armor, Cloud CDN ו-שרת proxy לאימות זהויות (IAP).
- תמיכה במספר אישורי TLS. אובייקט Ingress יכול לציין את השימוש במספר אישורי TLS לסיום בקשה.
כשיוצרים אובייקט Ingress, בקר Ingress של GKE יוצר מאזן עומסים של Cloud HTTP(S) ומגדיר אותו בהתאם למידע באובייקט Ingress ובשירותים המשויכים אליו.
שמירה על תוכנית לניהול נקודות חולשה
שמירה על תוכנית לניהול נקודות חולשה כוללת את הדרישות 5 ו-6 של PCI DSS.
דרישה 5
הגנה על כל המערכות והרשתות מפני תוכנות זדוניות.
דרישה 5 של PCI DSS קובעת שצריך להשתמש בתוכנת אנטי-וירוס בכל המערכות שמושפעות בדרך כלל מתוכנות זדוניות, כדי להגן על המערכות מפני איומים של תוכנות זדוניות עדכניות ומתפתחות – וקונטיינרים לא יוצאים מן הכלל.
דרישה 5.2
מניעה של תוכנות זדוניות (malware), או זיהוי וטיפול בהן.
אתם צריכים להטמיע תוכניות לניהול נקודות חולשה בקובצי האימג' של הקונטיינרים.
צעדים מומלצים:
- חשוב לבדוק באופן קבוע את תיקוני האבטחה העדכניים וליישם אותם במאגרי התוכן.
- ביצוע סריקות חולשות באופן קבוע באפליקציות בקונטיינרים ובקבצים בינאריים או בספריות.
- סריקת תמונות כחלק מצינור ה-Build.
- כדאי להירשם לשירות מודיעין בנושא נקודות חולשה כדי לקבל מידע עדכני על נקודות חולשה שרלוונטי לסביבה ולספריות שבהן נעשה שימוש בקונטיינרים.
Google Cloud פועל עם ספקי פתרונות שונים לאבטחת קונטיינרים כדי לשפר את מצב האבטחה בפריסות של הלקוחות. מומלץ להשתמש בפתרונות ובטכנולוגיות אבטחה מאומתים כדי להעמיק את ההגנה בסביבת GKE. לרשימה העדכנית של שותפי אבטחה שאומתו על ידיGoogle Cloud, אפשר לעיין בשותפי אבטחה. Google Cloud
דרישה 5.2.2
פתרונות האנטי-וירוס שנפרסו:
- מזהה את כל הסוגים הידועים של תוכנות זדוניות.
- מסיר, חוסם או מכיל את כל הסוגים הידועים של תוכנות זדוניות.
דרישה 5.2.3
רכיבי מערכת שלא נמצאים בסיכון למתקפות של תוכנות זדוניות נבדקים מעת לעת, כולל:
- רשימה מתועדת של כל רכיבי המערכת שלא נמצאים בסיכון לתוכנות זדוניות.
- זיהוי והערכה של איומי תוכנות זדוניות מתפתחים עבור רכיבי המערכת האלה.
- אישור לכך שרכיבי מערכת כאלה עדיין לא דורשים הגנה מפני תוכנות זדוניות.
יש הרבה פתרונות זמינים לביצוע סריקות של תוכנות זדוניות, אבל תקן PCI DSS מכיר בכך שלא כל המערכות חשופות באותה מידה לפגיעות. בדרך כלל, מוֹכרים מצהירים שהשרתים שלהם ב-Linux, המחשבים המרכזיים ומכונות דומות לא מושפעים בדרך כלל מתוכנות זדוניות, ולכן הם פטורים מדרישה 5.2.2. במקרה כזה, חלה דרישה 5.2.3, ועליכם להטמיע מערכת להערכות תקופתיות של איומים.
חשוב לזכור שהכללים האלה חלים גם על צמתים וגם על פודים באשכול GKE.
דרישה 5.3
מנגנונים ותהליכים למניעת תוכנות זדוניות פעילים, מתוחזקים ומנוטרים.
בדרישות 5.2, 5.3 ו-11.5 נדרשות סריקות אנטי-וירוס ומעקב אחר תקינות הקבצים (FIM) בכל מארח שנכלל בהיקף. מומלץ להטמיע פתרון שבו סוכן מהימן יכול לסרוק את כל הצמתים באשכול, או שבו לכל צומת יש סורק שמדווח לנקודת ניהול אחת.
למידע נוסף, אפשר לעיין בסקירה הכללית על האבטחה ב-GKE ובסקירה הכללית על האבטחה במערכת הפעלה שמותאמת לקונטיינרים.
פתרון נפוץ לדרישות של האנטי-וירוס ושל FIM הוא נעילה של הקונטיינר כך שרק לתיקיות ספציפיות מותרת גישת כתיבה. כדי לעשות את זה, מריצים את הקונטיינרים כמשתמשים לא-ראשיים ומשתמשים בהרשאות של מערכת הקבצים כדי למנוע גישת כתיבה לכל התיקיות במערכת הקבצים של הקונטיינר, למעט תיקיות העבודה. איסור על הסלמת הרשאות כדי למנוע עקיפה של הכללים במערכת הקבצים.
דרישה 6
פיתוח ותחזוקה של מערכות ותוכנות מאובטחות.
בדרישה 6 של PCI DSS נקבע שצריך ליצור מחזור חיים חזק של פיתוח תוכנה, שבו האבטחה מוטמעת בכל שלב של פיתוח התוכנה.
דרישה 6.2
פיתוח מאובטח של תוכנות בהתאמה אישית.
דרישה 6.2.1
פיתוח של תוכנות בהתאמה אישית מתבצע באופן מאובטח, באופן הבא:
- מבוסס על תקנים בתחום ו/או על שיטות מומלצות לפיתוח מאובטח.
- בהתאם ל-PCI DSS (לדוגמה, אימות מאובטח ורישום ביומן).
- שילוב של שיקולים בנוגע לבעיות אבטחת מידע בכל שלב במחזור החיים של פיתוח התוכנה.
אתם יכולים להשתמש ב-Binary Authorization כדי לוודא שרק קונטיינרים מהימנים נפרסים ב-GKE. אם אתם רוצים להפעיל רק תמונות שאושרו על ידי מאמתים ספציפיים, אתם יכולים להגדיר את Binary Authorization כך שיאכוף מדיניות עם כללים שמחייבים אישורים על סמך תוצאות של סריקות פגיעות. אתם יכולים גם לכתוב מדיניות שמחייבת צדדים מהימנים (שנקראים 'מאמתים') לאשר תמונה לפני שהיא נפרסת. בצינור פריסה רב-שלבי שבו תמונות עוברות מפיתוח לבדיקה לאשכולות ייצור, אתם יכולים להשתמש במאמתים כדי לוודא שכל התהליכים הנדרשים הושלמו לפני שהתוכנה עוברת לשלב הבא.
בזמן הפריסה, Binary Authorization אוכף את המדיניות שלכם על ידי בדיקה שקובץ האימג' של הקונטיינר עבר את כל האילוצים הנדרשים – כולל אימות של כל המאמתים הנדרשים לכך שהקובץ מוכן לפריסה. אם התמונה עוברת את הבדיקה, השירות מאפשר לפרוס אותה. אחרת, הפריסה נחסמת ואי אפשר לפרוס את התמונה עד שהיא תעמוד בדרישות.
מידע נוסף על Binary Authorization זמין במאמר בנושא הגדרה ל-GKE.
במקרה חירום, אפשר לעקוף את מדיניות Binary Authorization באמצעות תהליך העבודה של breakglass. כל אירועי Breakglass מתועדים ביומני ביקורת של Cloud.
GKE Sandbox מצמצם את הצורך של הקונטיינר באינטראקציה ישירה עם המארח, וכך מקטין את שטח ההתקפה לפריצה למארח ומגביל את התנועה של גורמים זדוניים.
דרישה 6.3
נקודות חולשה באבטחה מזוהות ומטופלות.
דרישה 6.3.1
נקודות חולשה באבטחה מזוהות ומנוהלות באופן הבא:
- אנחנו מזהים נקודות חולשה חדשות באבטחה באמצעות מקורות מוכרים בתעשייה למידע על נקודות חולשה באבטחה, כולל התראות מצוותים בינלאומיים ולאומיים למענה למקרי חירום במחשבים (CERT).
- לפגיעויות מוקצה דירוג סיכון על סמך שיטות מומלצות בתעשייה ושיקולים של השפעה פוטנציאלית.
- דירוגי הסיכון מזהים לפחות את כל נקודות החולשה שנחשבות לבעלות סיכון גבוה או קריטי לסביבה.
- הפגיעות בתוכנות בהתאמה אישית ובתוכנות של צד שלישי (למשל מערכות הפעלה ומסדי נתונים) מכוסות.
האבטחה בענן היא אחריות משותפת בין ספק שירותי הענן לבין הלקוח.
ב-GKE, Google מנהלת את מישור הבקרה, שכולל את מכונות ה-VM הראשיות, את שרת ה-API ורכיבים אחרים שפועלים במכונות ה-VM האלה, וגם את מסד הנתונים etcd. השירות כולל שדרוגים, תיקונים, שינוי גודל ותיקונים, והוא מגובה על ידי יעד למדידת רמת השירות (SLO). במקרה של מערכת ההפעלה של הצמתים, כמו מערכת הפעלה שמותאמת לקונטיינרים או Ubuntu, GKE מפרסם במהירות את כל התיקונים לתמונות האלה. אם הפעלתם את השדרוג האוטומטי, התיקונים האלה יופעלו באופן אוטומטי. (זו שכבת הבסיס של הקונטיינר – היא לא זהה למערכת ההפעלה שפועלת בקונטיינרים).
מידע נוסף על מודל האחריות המשותפת ב-GKE זמין במאמר בדיקת אבטחת קונטיינרים: מודל האחריות המשותפת ב-GKE.
Google מספקת כמה שירותי אבטחה שיעזרו לכם לשלב אבטחה בצינור ה-CI/CD. כדי לזהות נקודות חולשה בקובצי אימג' של קונטיינרים, אפשר להשתמש ב-Google Artifact Analysis Vulnerability Scanning. כשדוחפים קובץ אימג' של קונטיינר אל Google Container Registry (GCR), בדיקת נקודות חולשה סורקת אוטומטית את קובצי האימג' כדי לאתר נקודות חולשה וחשיפות ידועות ממקורות ידועים של CVE. לנקודות חולשה מוקצות רמות חומרה (קריטית, גבוהה, בינונית, נמוכה ומינימלית) על סמך ציוני CVSS.
דרישה 6.4
אפליקציות אינטרנט שפונות לציבור מוגנות מפני התקפות.
Web Security Scanner מאפשר לסרוק אפליקציות אינטרנט של App Engine, Compute Engine ו-GKE שפתוחות לציבור כדי למצוא נקודות חולשה נפוצות, החל מפרצת אבטחה XSS (cross-site scripting) ועד משאבים פגיעים. אפשר לבצע סריקות על פי דרישה ולתזמן אותן ממסוףGoogle Cloud . באמצעות ממשקי ה-API של Security Scanner, אפשר להפוך את הסריקה לאוטומטית כחלק מחבילת מקרים לבדיקה בצינור ליצירת האפליקציה.
הטמעת בקרת גישה חזקה
הטמעה של אמצעים חזקים לבקרת גישה כוללת את הדרישות 7, 8 ו-9 של PCI DSS.
דרישה 7
הגבלת הגישה לרכיבי המערכת ולנתוני בעלי הכרטיסים בהתאם לצורך העסקי לדעת.
דרישה 7 מתמקדת בהרשאות מינימליות או בצורך לדעת. התקן PCI DSS מגדיר את העיקרון הזה כהענקת גישה לכמות המינימלית של נתונים ומתן ההרשאות המינימליות שנדרשות לביצוע עבודה.
דרישה 7.2
הגישה לרכיבי המערכת ולנתונים מוגדרת ומוקצית בצורה מתאימה.
IAM ובקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes פועלים יחד כדי לספק בקרת גישה פרטנית לסביבת GKE. משתמשים ב-IAM כדי לנהל את הגישה של המשתמשים ואת ההרשאות שלהם לGoogle Cloud משאבים בפרויקט CDE. ב-GKE, אפשר גם להשתמש ב-IAM כדי לנהל את הגישה והפעולות שמשתמשים וחשבונות שירות יכולים לבצע באשכולות, כמו יצירה ומחיקה של אשכולות.
בקרת הגישה מבוססת-תפקידים (RBAC) ב-Kubernetes מאפשרת להגדיר קבוצות הרשאות מפורטות שמגדירות איך Google Cloud משתמש Google Cloud, חשבונות שירות או קבוצת משתמשים (קבוצות Google) יכולים ליצור אינטראקציה עם אובייקט Kubernetes באשכול או במרחב שמות ספציפי באשכול. דוגמאות להרשאות RBAC כוללות עריכה של פריסות או של configmap, מחיקה של pods או צפייה ביומנים מ-pod. אתם נותנים למשתמשים או לשירותים הרשאות IAM מוגבלות, כמו צפייה באשכול Google Kubernetes Engine או תפקידים בהתאמה אישית, ואז מחילים את ה-RoleBindings של Kubernetes RBAC לפי הצורך.
אפשר לשלב את שרת ה-proxy לאימות זהויות (IAP) ב-Cloud דרך כניסה ל-GKE כדי לשלוט בגישה ברמת האפליקציה לעובדים או לאנשים שזקוקים לגישה לאפליקציות PCI שלכם.
בנוסף, אתם יכולים להשתמש במדיניות הארגון כדי להגביל את ממשקי ה-API והשירותים שזמינים בפרויקט.
דרישה 7.2.2
הגישה מוקצית למשתמשים, כולל משתמשים עם הרשאות מיוחדות, על סמך:
- סיווג התפקיד והפונקציה.
- הרשאות מינימליות שנדרשות לביצוע תחומי האחריות של התפקיד.
בנוסף לווידוא שמשתמשים וחשבונות שירות פועלים לפי העיקרון של הרשאות מינימליות, חשוב לוודא שגם קונטיינרים פועלים לפי העיקרון הזה. שיטה מומלצת להרצת קונטיינר היא להריץ את התהליך עם משתמש שאינו משתמש root. אפשר להשיג את המטרה הזו ולאכוף אותה באמצעות בקר הכניסה PodSecurity.
PodSecurity הוא בקר קבלה (admission controller) של Kubernetes שמאפשר להחיל תקני אבטחה של Pod על פודים שפועלים באשכולות GKE. תקני האבטחה של Pod הם מדיניות אבטחה מוגדרת מראש שמכסה את הצרכים ברמה גבוהה של אבטחת פודים ב-Kubernetes. המדיניות הזו נעה בין מדיניות מתירה מאוד למדיניות מגבילה מאוד. PodSecurity מחליף את בקר הקבלה PodSecurityPolicy הקודם שהוסר ב-Kubernetes גרסה 1.25. יש הוראות למעבר מ-PodSecurityPolicy לבקר הקבלה PodSecurity.
דרישה 8
זיהוי משתמשים ואימות הגישה לרכיבי המערכת
בדרישה 8 מצוין שצריך להקצות מזהה ייחודי לכל אדם שיש לו גישה למערכות PCI בהיקף, כדי להבטיח שכל אדם יהיה אחראי באופן ייחודי למעשים שלו.
דרישה 8.2
הזיהוי של המשתמשים והחשבונות הקשורים למשתמשים ולאדמינים מנוהל בקפדנות לאורך מחזור החיים של החשבון.
דרישה 8.2.1
לכל המשתמשים מוקצה מזהה ייחודי לפני שניתנת להם גישה לרכיבי המערכת או לנתוני בעלי כרטיסים.
דרישה 8.2.5
הגישה של משתמשים שהחשבון שלהם נסגר נשללת באופן מיידי.
אפשר להשתמש ב-IAM וב-Kubernetes RBAC כדי לשלוט בגישה לאשכול GKE, ובשני המקרים אפשר להעניק הרשאות למשתמש. מומלץ שהמשתמשים יקושרו למערכת ניהול הזהויות הקיימת, כדי שתוכלו לנהל את חשבונות המשתמשים ואת המדיניות במקום אחד.
דרישה 8.3
אימות חזק למשתמשים ולמנהלי מערכת מוגדר ומנוהל.
דרישה 8.3.1
- פרט שידוע לכם, כמו סיסמה או ביטוי גישה.
- משהו שיש לכם, כמו מכשיר טוקן או כרטיס חכם.
- משהו שאתם, כמו אלמנט ביומטרי.
האישורים משויכים לזהות של המשתמשים כשהם מבצעים אימות ל-kubectl.
כל אשכולות GKE מוגדרים לקבל זהויות של משתמשים וחשבונות שירות, על ידי אימות פרטי הכניסה ואחזור כתובת האימייל שמשויכת לזהות של המשתמש או חשבון השירות. Google Cloud לכן, כדי שהאימות יצליח, פרטי הכניסה של החשבונות האלה צריכים לכלול את היקף ההרשאה של userinfo.email OAuth.
דרישה 9
הגבלת הגישה הפיזית לנתונים של בעלי הכרטיסים.
Google אחראית לאמצעי בקרה פיזיים בכל מרכזי הנתונים של Google שמהווים את הבסיס ל-Google Cloud.
מעקב ובדיקה של רשתות באופן קבוע
מעקב ובדיקה קבועים של רשתות כוללים את דרישות 10 ו-11 של PCI DSS.
דרישה 10
תיעוד ומעקב אחרי כל הגישה לרכיבי המערכת ולנתוני בעלי הכרטיסים.
דרישה 10.2
יומני הביקורת מיושמים כדי לתמוך בזיהוי של אנומליות ופעילות חשודה, ובניתוח פורנזי של אירועים.
באשכולות של Kubernetes, רישום ביומן הביקורת של Kubernetes מופעל כברירת מחדל. הרישום הזה שומר תיעוד כרונולוגי של קריאות שבוצעו לשרת Kubernetes API. רשומות ביומן הביקורת של Kubernetes שימושיות לחקירת בקשות חשודות ל-API, לאיסוף נתונים סטטיסטיים או ליצירת התראות למעקב אחרי קריאות לא רצויות ל-API.
באשכולות GKE יש שילוב של הגדרת ברירת מחדל לרישום ביומני ביקורת של GKE עם יומני ביקורת של Cloud ועם Cloud Logging. אפשר לראות את הרשומות ביומן הביקורת של Kubernetes בפרויקט Google Cloud .
בנוסף לרשומות שנכתבות על ידי Kubernetes, יומני הביקורת של הפרויקט כוללים רשומות שנכתבות על ידי GKE.
כדי להבדיל בין עומסי עבודה של CDE לבין עומסי עבודה שלא שייכים ל-CDE, מומלץ להוסיף תוויות ל-pods של GKE, שיחלחלו למדדים וללוגים שמופקים מעומסי העבודה האלה.
דרישה 10.2.2
- זיהוי משתמשים
- סוג האירוע
- תאריך ושעה
- סימן להצלחה או לכישלון
- מקור האירוע
- הזהות או השם של הנתונים, רכיב המערכת, המשאב או השירות שהושפעו (לדוגמה, שם ופרוטוקול)
כל רשומה ביומן הביקורת ב-Logging היא אובייקט מסוג LogEntry שמכיל את השדות הבאים:
- מטען ייעודי (payload) מסוג
protoPayload. המטען הייעודי (payload) של כל רשומה ביומן הביקורת הוא אובייקט מסוגAuditLog. אפשר למצוא את זהות המשתמש בשדהAuthenticationInfoשל אובייקטים מסוגAuditLog. - האירוע הספציפי, שאפשר למצוא בשדה
methodNameשלAuditLog. - חותמת זמן.
- סטטוס האירוע, שמופיע באובייקטים
responseבאובייקטAuditLog. - בקשת הפעולה, שאפשר למצוא באובייקטים
requestו-requestMetadataבאובייקטAuditLog. - השירות שיבוצע, שאפשר למצוא באובייקט
AuditDataב-serviceData.
דרישה 11
בודקים את אבטחת המערכות והרשתות באופן קבוע.
דרישה 11.3
אנחנו מזהים, מתעדפים ומטפלים באופן קבוע בנקודות חולשה חיצוניות ופנימיות.
דרישה 11.3.1
- לפחות פעם בשלושה חודשים.
- נקודות חולשה קריטיות ובעלות סיכון גבוה (בהתאם לדירוג הסיכון של נקודות החולשה של הישות, כפי שמוגדר בדרישה 6.3.1) נפתרות.
- מבוצעות סריקות חוזרות כדי לוודא שכל נקודות החולשה הקריטיות ונקודות החולשה ברמת סיכון גבוהה (כפי שצוין למעלה) נפתרו.
- כלי הסריקה מתעדכן באופן שוטף במידע העדכני ביותר על פגיעויות.
- הסריקות מתבצעות על ידי אנשי צוות מוסמכים, והבודק הוא עצמאי מבחינת הארגון.
Artifact Analysis vulnerability scanning מבצע את הסוגים הבאים של בדיקות לאיתור נקודות חולשה בתמונות ב-Container Registry:
סריקה ראשונית. כשמפעילים את Artifact Analysis API בפעם הראשונה, הוא סורק את קובצי האימג' ב-Container Registry ומחלץ את מנהל החבילות, בסיס האימג' ונקודות החולשה של קובצי האימג'.
סריקה מצטברת. הכלי Artifact Analysis סורק תמונות חדשות כשמעלים אותן ל-Container Registry.
ניתוח רציף: ככל ש-Artifact Analysis מקבל מידע חדש ומעודכן על נקודות חולשה ממקורות של נקודות חולשה, הוא מריץ מחדש ניתוח של קונטיינרים כדי לשמור על עדכניות של רשימת המקרים של נקודות חולשה בתמונות שכבר נסרקו.
דרישה 11.5
מערכת האבטחה מזהה פריצות לרשת ושינויים לא צפויים בקבצים ומגיבה להם.
דרישה 11.5.1
- כל התנועה נבדקת בהיקף של סביבת ה-CDE.
- כל התנועה נבדקת בנקודות קריטיות ב-CDE.
- הצוות מקבל התראות על חשד לפריצות.
- כל המנועים, קווי הבסיס והחתימות של זיהוי פריצות ומניעת פריצות מעודכנים.
אפשר להשתמש בGoogle Cloud רפליקציה של חבילות נתונים עם Cloud IDS כדי לזהות חדירות לרשת. Google Cloud רפליקציה של חבילות נתונים מעבירה את כל התעבורה ברשת ממכונות וירטואליות של Compute Engine או מאשכולות של Google Cloud לכתובת ייעודית. מערכת Cloud IDS יכולה לעבד את התעבורה המשוכפלת הזו כדי לזהות מגוון רחב של איומים, כולל ניסיונות ניצול לרעה, סריקות של יציאות, הצפת מאגרים, פיצול פרוטוקולים, תעבורת נתונים של שליטה ובקרה (C2) ותוכנות זדוניות.
ב-Security Command Center אפשר לראות את מצב האבטחה של שירותים (כולל GKE) ונכסים בכל הארגון, ולכן קל יותר למנוע איומים, לזהות אותם ולהגיב להם.Google Cloud באמצעות Security Command Center, תוכלו לראות מתי זוהו איומים ברמת סיכון גבוהה, כמו תוכנות זדוניות, כריית מטבע וירטואלי, גישה לא מורשית למשאבי Google Cloud , מתקפות DDoS יוצאות, סריקת יציאות ו-SSH בכוח ברוטלי, על סמך היומנים של Cloud Logging.
שמירה על מדיניות אבטחת מידע
מדיניות אבטחה חזקה קובעת את הטון של האבטחה ומבהירה לאנשים מה מצופה מהם. במקרה הזה, המונח 'אנשים' מתייחס לעובדים במשרה מלאה ובמשרה חלקית, לעובדים זמניים, לקבלנים וליועצים שיש להם גישה לסביבת הנתונים המשותפת שלכם.
דרישה 12
תמיכה באבטחת מידע באמצעות מדיניות ותוכניות ארגוניות.
מידע על דרישה 12 זמין בGoogle Cloud מטריצת האחריות המשותפת של PCI.
סידור וארגון
אם השתמשתם במשאבים כלשהם במהלך קריאת המאמר הזה – למשל, אם הפעלתם מכונות וירטואליות חדשות או השתמשתם בסקריפטים של Terraform – תוכלו למחוק את הפרויקט שבו השתמשתם במשאבים האלה כדי להימנע מחיובים בחשבון Google Cloud .
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
המאמרים הבאים
- מידע נוסף על תאימות לתקן אבטחת הנתונים של PCI
- כדאי לנסות את ערכת ההתחלה של Terraform.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.