מידע על שליטה במישור הבקרה של GKE

.

במאמר הזה מוסברות האפשרויות שקיימות ב-Google Kubernetes Engine ‏ (GKE) כדי לשפר את החשיפה והשליטה באבטחה של מישור הבקרה המנוהל. האפשרויות האלה נקראות ביחד שליטה במישור הבקרה של GKE. המסמך מיועד למנהלי אבטחת מידע, לאדמינים שאחראים על תאימות ולמנתחי נתונים שרוצים לעמוד בדרישות מחמירות של פרטיות ואבטחה בטיפול במידע אישי רגיש.

מידע על התכונות של הרשאות הגישה למישור הבקרה של GKE

ב-GKE,‏ Cloud de Confiance by S3NS מנוהלת באופן מלא הגדרת האבטחה של מישור הבקרה, כולל הצפנה של אחסון במנוחה, והגדרת המפתחות ורשויות האישורים (CA) שחותמות על אישורים ומאמתות אותם באשכולות. צמתי מישור הבקרה של אשכולות GKE נמצאים בפרויקטים שמנוהלים על ידי Cloud de Confiance . לפרטים על הפעולות ש- Cloud de Confiance מבצע, קראו את המאמר אחריות משותפת ב-GKE.

שליטה במישור הבקרה של GKE היא קבוצה אופציונלית של יכולות בקרה וחשיפה שמאפשרות לכם לאמת ולנהל היבטים ספציפיים של צמתים מנוהלים לחלוטין של מישור הבקרה. היכולות האלה מתאימות במיוחד אם יש לכם דרישות כמו:

  • אתם פועלים בתעשייה מפוקחת מאוד, כמו פיננסים, בריאות או ממשל, עם דרישות תאימות ספציפיות.
  • אתם מטפלים במידע אישי רגיש שיש לו דרישות מחמירות לאבטחה ולהצפנה
  • אתם רוצים לשפר את החשיפה ב-GKE כדי להריץ עומסי עבודה קריטיים בביטחון רב יותר.
  • אתם צריכים לעמוד בדרישות ספציפיות של תאימות או ביקורת שקשורות להצפנת נתונים, לתקינות התוכנה או לרישום ביומן.
  • יש לכם עומסי עבודה רגישים מאוד שמעבדים נתונים קריטיים, ואתם רוצים לראות את ההצפנה של הנתונים האלה ואת הגישה אליהם.
  • אתם רוצים לאכוף מדיניות אבטחה בהתאמה אישית שעומדת בדרישות ספציפיות של הארגון או של הרגולציה.
  • אתם רוצים רמה גבוהה יותר של שקיפות וחשיפה בסביבות GKE, במיוחד לגבי פעולות ש-Cloud de Confiance מבצע במישור הבקרה

היתרונות של שליטה במישור הבקרה של GKE

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

  • שקיפות ובקרה משופרות: שימוש ביכולות נוספות של שקיפות, בקרה והצפנה למישור הבקרה של GKE.
  • עמידה פשוטה בדרישות: עמידה בדרישות רגולטוריות ובתקנים מקובלים בתחום, בעזרת יומני ביקורת מפורטים ומדיניות אבטחה שניתן להתאים אישית.
  • אמון ושקיפות: אתם יכולים לראות את הפעולות ש-Cloud de Confiance מבצעת במישור הבקרה כשהיא מטפלת בבקשות תמיכה של לקוחות.
  • הפחתת סיכונים: זיהוי יזום של איומים פוטנציאליים במישור הבקרה המנוהל והגנה מפניהם באמצעות יומנים מקיפים.
  • ניהול מפתחות ורשויות אישורים בתקן אחיד: ניהול רשויות אישורים של אשכולות GKE באמצעות שירות רשויות האישורים, שמאפשר להעביר את ניהול האישורים לצוותים ספציפיים ולאכוף מדיניות של רשויות אישורים באופן מקיף. בנוסף, אתם יכולים לנהל את מפתחות ההצפנה של הדיסק במישור הבקרה באמצעות Cloud KMS, כדי להאציל את הניהול באופן דומה.

זמינות של שליטה במישור הבקרה של GKE

התכונה "שליטה במישור הבקרה של GKE" זמינה בכל אזור של Cloud de Confiance. עם זאת, כדי להצפין את דיסקי האתחול של מישור הבקרה ואת דיסקי ה-etcd באמצעות מפתחות משלכם, אתם צריכים ליצור את האשכול באחד מהאזורים הבאים:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4

איך פועלת השליטה במישור הבקרה של GKE

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

  • ניהול מפתחות ופרטי כניסה: שליטה במפתחות שמשמשים את GKE להצפנת נתונים במנוחה במישור הבקרה, ולהנפקה ואימות של זהויות באשכול.
  • יומני גישה ויומני הנפקת זהויות: אפשר להשתמש ביומנים מהרשת, ממכונה וירטואלית ומ-Access Transparency כדי לאמת את הגישה למישור הבקרה של GKE באמצעות כמה מקורות. אתם יכולים להשתמש ביומני הנפקת הזהויות ב-Cloud KMS וב-CA Service כדי לראות מתי נוצרות זהויות באמצעות מפתחות ורשויות אישורים שאתם מנהלים. אפשר להשתמש ביומני שימוש מפורטים ב-Kubernetes API כדי לעקוב אחרי הפעולות של הזהויות האלה באשכול.

ניהול מפתחות ופרטי כניסה

כברירת מחדל, Cloud de Confiance מנהל בשבילכם את המפתחות ורשויות האישורים באשכולות GKE. אתם יכולים להשתמש ב-Cloud KMS וב-CA Service כדי להגדיר מפתחות ורשויות אישורים משלכם, ולהשתמש בהם כשאתם יוצרים אשכול חדש.

‫GKE משתמש במפתחות וב-CA האלה במקום ב Cloud de Confiance ערכי ברירת המחדל כדי להנפיק ולאמת זהויות באשכול ולהצפין נתונים ב מכונות הווירטואליות של מישור הבקרה. שמירה על שליטה בהנפקת הזהויות ובמפתחות הצפנת הנתונים יכולה לעזור לכם:

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

רשויות אישורים בניהול עצמי ומפתחות של חשבונות שירות

אתם יכולים להגדיר את מישור הבקרה של GKE כך שישתמש במפתחות Cloud KMS וב-CAs של CA Service שאתם מנהלים. ‫GKE משתמש במשאבים האלה כדי להנפיק ולאמת זהויות באשכול. לדוגמה, GKE משתמש ברשויות אישורים ובמפתחות כדי להנפיק אישורי לקוח של Kubernetes וטוקנים למוכ"ז של חשבונות שירות ב-Kubernetes.

אתם יוצרים את המשאבים הבאים ש-GKE ישתמש בהם כשהוא ינפיק זהויות:

  1. מפתחות חתימה של חשבון שירות: חותמים על טוקנים למוכ"ז של Kubernetes ServiceAccount לחשבונות שירות באשכול. אסימוני טוקן למוכ"ז האלה הם אסימוני JWT (‏JSON Web Tokens) שמקלים על התקשורת בין ה-Pod לבין שרת ה-API של Kubernetes.
  2. מפתחות אימות של חשבון שירות: משמשים לאימות של JWT של חשבון שירות ב-Kubernetes. המפתח הזה בדרך כלל זהה למפתח החתימה, אבל הוא מוגדר בנפרד כדי שתוכלו לבצע רוטציה של המפתחות בצורה בטוחה יותר.
  3. רשות אישורים (CA) של אשכול: הנפקת אישורים חתומים למטרות כמו בקשות לחתימת אישורים (CSR) ותקשורת kubelet.
  4. ‫etcd peer CA: הנפקת אישורים חתומים לתקשורת בין מכונות etcd באשכול.
  5. ‫etcd API CA: הנפקת אישורים חתומים לתקשורת עם שרת API של etcd.
  6. רשות אישורים לצבירה: הנפקת אישורים חתומים כדי לאפשר תקשורת בין שרת ה-API של Kubernetes לבין שרתי התוספים.

כש-GKE מנפיק זהויות באשכול, יומני הביקורת המתאימים מופיעים ב-Cloud Logging, ואתם יכולים להשתמש בהם כדי לעקוב אחרי הזהויות שהונפקו במהלך משך החיים שלהן.

מידע נוסף זמין במאמר הפעלת רשויות אישורים ומפתחות חתימה משלכם ב-GKE.

דיסק אתחול של מישור הבקרה והצפנת etcd

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

  • הדיסק שבו מאוחסנים נתוני etcd.
  • Cloud de Confiance by S3NS הגיבוי התפעולי הפנימי של etcd.

ההצפנה הזו כברירת מחדל מתבצעת באמצעות מפתחות הצפנה ש Cloud de Confiance מנהלת. לפרטים על הצפנת ברירת המחדל, ראו ברירת המחדל להצפנה במנוחה.

אופציונלית, אתם יכולים להשתמש במפתחות הצפנה משלכם שאתם מנהלים באמצעות Cloud KMS כדי להצפין את המשאבים הבאים:

  • ‫דיסק אתחול של מישור הבקרה: דיסק Compute Engine שכל מכונת VM של מישור הבקרה משתמשת בו כדי לבצע אתחול.
  • דיסק etcd: דיסק Compute Engine שמצורף לכל מכונה וירטואלית במישור הבקרה ומאחסן נתונים עבור מופעי etcd באשכול.

  • גיבוי תפעולי פנימי של etcd: הגיבוי הפנימי של Cloud de Confiance ב-etcd שמשמש למטרות תפעוליות כמו תוכנית התאוששות מאסון (DR).

    הגיבוי הזה הוא אמצעי חירום פנימי של Cloud de Confiance. אם רוצים לגבות ולשחזר את האשכולות, צריך להשתמש במקום זאת בגיבוי ל-GKE.

הוראות מפורטות מופיעות במאמר הצפנה של etcd ושל דיסקים לאתחול של מישור הבקרה.

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

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

רוטציה של פרטי כניסה בניהול הלקוח

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

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

מידע נוסף זמין בדפים הבאים:

יומני גישה ויומנים של הנפקת זהויות

ב-Logging אפשר לראות יומנים של כל האירועים שקשורים לגישה ולזהות במישור הבקרה, כולל האירועים הבאים:

  • גישה ישירה: יומנים שקשורים לניסיונות גישה ישירה (כמו SSH) לצומתי מישור הבקרה של GKE, מאפשרים לוודא שיומני ה-SSH של ה-VM וחיבורי הרשת של ה-VM תואמים לרשומות ה-SSH ביומני Access Transparency.
  • הנפקה ואימות של זהויות: יומנים שקשורים לזהויות שהונפקו באמצעות רשויות אישורים ומפתחות שאתם מנהלים ב-CA Service וב-Cloud KMS.
  • שימוש בזהויות ב-Kubernetes: יומנים שקשורים לפעולות שזהויות ספציפיות מבצעות בשרת ה-API של Kubernetes.
  • ‫Access Transparency: יומנים שקשורים לחיבורים שנוצרו למישור הבקרה ולפעולות שבוצעו במישור הבקרה על ידי צוות Cloud de Confiance . כשמפעילים את התכונה 'אישור גישה משופר', מקבלים רמת פירוט גבוהה יותר לבקרת גישה, כולל פרטים על פקודות SSH ביומני Access Transparency ובבקשות לאישור גישה. כדי לקבל מידע נוסף על דרישות הסף וההרשמה, פנו לצוות ניהול החשבון שלכם ב- Cloud de Confiance by S3NS .

היומנים האלה יכולים לעזור לכם:

  • שומרים על יומני ביקורת מקיפים של כל הגישות למישור הבקרה ואירועי הזהות לצורך תאימות ואבטחה.
  • בנוסף לאמצעי ההגנה המובנים של Google, אתם יכולים ליצור מערכת משלכם למעקב אחרי פעילות חשודה במישור הבקרה ולחקור אותה.
  • לוודא שרק גורמים מוסמכים ניגשים לאשכול GKE ומקיימים איתו אינטראקציה, וכך לשפר את מצב האבטחה.
  • אתם יכולים לראות מתי נוצרות זהויות באמצעות מפתחות ורשויות אישורים שאתם מנהלים, בעזרת יומני הנפקת הזהויות ב-Cloud KMS וב-CA Service. להשתמש ביומני שימוש מפורטים של Kubernetes API כדי לעקוב אחרי הפעולות של הזהויות האלה באשכול.

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

מקורות מידע נוספים על אבטחת מישור הבקרה

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

  • תקינות קובץ האימג' של המכונה הווירטואלית במישור הבקרה: GKE מוסיף ל-Cloud Logging יומנים מפורטים של אירועי יצירה והפעלה של מכונות וירטואליות של צמתים. בנוסף, אנחנו מפרסמים ב-GitHub הצהרות VSA של SLSA שתואמות לתמונות מכונה של מישור הבקרה ושל צומת עובד. אתם יכולים לוודא שהמכונות הווירטואליות משתמשות בקובצי אימג' של מערכת ההפעלה שיש להן VSAs תואמים, ולוודא את תקינות האתחול של כל מכונה וירטואלית של מישור הבקרה.

    כדי לבצע אימות של תקינות מכונות וירטואליות, אפשר לעיין במאמר בנושא אימות של תקינות מכונות וירטואליות במישור הבקרה של GKE.

  • אמצעי אבטחה מובנים במישור הבקרה: GKE מבצע אמצעי הקשחה שונים במישור הבקרה המנוהל. למידע נוסף, ראו אבטחה של מישור הבקרה.

המאמרים הבאים