מידע על שליטה במישור הבקרה של 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 וב-CA Service CAs שאתם מנהלים. ‫GKE משתמש במשאבים האלה כדי להנפיק ולאמת זהויות באשכול. לדוגמה, ב-GKE נעשה שימוש ב-CA ובמפתחות כדי להנפיק אישורים של לקוחות Kubernetes ואסימוני גישה (bearer tokens) של חשבונות שירות ב-Kubernetes.

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

  1. מפתחות חתימה של חשבון שירות: חותמים על אסימוני ה-bearer של 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: הנפקת אישורים חתומים לתקשורת עם שרת etcd API.
  6. רשות אישורים (CA) של צבירה: מנפיקה אישורים חתומים כדי לאפשר תקשורת בין שרת ה-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 לצורכי תפעול: הגיבוי הפנימי של etcd שמשמש למטרות תפעוליות כמו תוכנית התאוששות מאסון (DR). Cloud de Confiance

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

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

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

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

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

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

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

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

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

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

  • גישה ישירה: יומנים שקשורים לניסיונות גישה ישירה (כמו SSH) לצמתים של מישור הבקרה של GKE מאפשרים לכם לוודא שהיומנים של SSH במכונה הווירטואלית והחיבורים לרשת של המכונה הווירטואלית תואמים לרשומות ה-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 שמתאים לתמונות של מכונות במישור הבקרה ובצומת העובד. אתם יכולים לוודא שהמכונות הווירטואליות משתמשות בתמונות של מערכת הפעלה שיש להן חתימות VSA תואמות, ולוודא את תקינות האתחול של כל מכונה וירטואלית במישור הבקרה.

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

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

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