מידע על שליטה במישור הבקרה של 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 באמצעות Certificate Authority Service מאפשר להקצות ניהול אישורים לצוותים ספציפיים ולאכוף מדיניות של רשויות אישורים באופן מקיף. בנוסף, אפשר לנהל את מפתחות ההצפנה של הדיסקים במישור הבקרה באמצעות 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 של חשבונות שירות ב-Kubernetes.

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

  1. מפתחות חתימה של חשבון שירות: חתימה על אסימוני bearer של חשבון שירות ב-Kubernetes ServiceAccount עבור חשבונות שירות באשכול. אסימוני ה-Bearer האלה הם אסימוני 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 שמשמש למטרות תפעוליות כמו התאוששות מאסון. Cloud de Confiance

    הגיבוי הזה הוא אמצעי חירום פנימי של Cloud de Confiance. אם רוצים לגבות ולשחזר את האשכולות, צריך להשתמש במקום זאת בגיבוי ל-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 אנשי צוות.

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

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

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

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

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

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

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

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

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