במסמך הזה מוסבר על האחריות המשותפת לאבטחה של Google ושל לקוחותGoogle Cloud . כדי להפעיל אפליקציה קריטית לעסק ב-Google Kubernetes Engine (GKE), צריך שגורמים שונים יישאו באחריות שונה. המסמך הזה לא כולל רשימה מלאה, אבל הוא יכול לעזור לכם להבין את האחריות שלכם.
המסמך הזה מיועד למומחי אבטחה שמגדירים, מנהלים ומיישמים מדיניות ונהלים כדי להגן על הנתונים של הארגון מפני גישה לא מורשית. כדי לקבל מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן ב Google Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.
האחריות של Google
- הגנה על התשתית הבסיסית, כולל חומרה, קושחה, ליבת מערכת ההפעלה, מערכת ההפעלה, אחסון, רשת ועוד. האמצעים האלה כוללים הצפנת נתונים במנוחה כברירת מחדל, הצפנה נוספת של דיסקים בניהול הלקוח, הצפנת נתונים בתנועה, שימוש בחומרה שתוכננה בהתאמה אישית, הנחת כבלים של רשת פרטית, הגנה על מרכזי נתונים מפני גישה פיזית, הגנה על טוען האתחול ועל ליבת מערכת ההפעלה מפני שינויים באמצעות צמתים מוגנים, ושימוש בשיטות פיתוח תוכנה מאובטחות.
- הקשחת ותיקון מערכת ההפעלה של הצמתים, כמו מערכת הפעלה שמותאמת לקונטיינרים או Ubuntu. GKE מפרסם במהירות כל תיקון לתמונות האלה. אם הפעלתם שדרוג אוטומטי או שאתם משתמשים בערוץ הפצה, העדכונים האלה יופעלו באופן אוטומטי. זוהי שכבת מערכת ההפעלה שמתחת לקונטיינר – היא לא זהה למערכת ההפעלה שפועלת בקונטיינרים.
- בנייה והפעלה של זיהוי איומים לאיומים ספציפיים לקונטיינרים בתוך ליבת המערכת באמצעות Container Threat Detection (זיהוי איומים בקונטיינר) (מחיר נפרד עם Security Command Center).
- הקשחה ותיקון של רכיבי צומת Kubernetes. כל הרכיבים המנוהלים של GKE משודרגים אוטומטית כשמשדרגים את גרסאות הצמתים של GKE. הם כוללים:
- מנגנון אתחול מהימן עם גיבוי vTPM להנפקת אישורי TLS של kubelet וסיבוב אוטומטי של האישורים
- הגדרת kubelet מוקשחת בהתאם לנקודות ההשוואה של CIS
- שרת המטא-נתונים של GKE ל-Workload Identity
- פלאגין Container Network Interface (ממשק רשת של קונטיינר) ו-Calico ל-NetworkPolicy של GKE
- שילובים של אחסון ב-GKE Kubernetes, כמו מנהל התקן ה-CSI
- סוכני רישום ביומן ומעקב ל-GKE
- הקשחה ותיקון של מישור הבקרה. מישור הבקרה כולל את מכונת ה-VM של מישור הבקרה, שרת API, מתזמן, מנהל בקרה, CA של אשכול, הנפקה ורוטציה של תעודת TLS, חומר מפתח של שורש האמון, מאמת ומאשר IAM, הגדרת רישום ביומן ביקורת, etcd ובקרים שונים אחרים. כל רכיבי מישור הבקרה פועלים במכונות של Compute Engine שמופעלות על ידי Google. המופעים האלה הם של דייר יחיד, כלומר כל מופע מריץ את מישור הבקרה ואת הרכיבים שלו רק עבור לקוח אחד.
- מספק Google Cloud שילובים ל-Connect, לניהול זהויות והרשאות גישה, ליומני ביקורת ב-Cloud, ל-Google Cloud Observability, ל-Cloud Key Management Service, ל-Security Command Center ועוד.
- הגבלת הגישה של Google ברמת האדמין לאשכולות של לקוחות ורישום הגישה למטרות תמיכה חוזיות באמצעות Access Transparency.
האחריות של הלקוח
- תחזוקה של עומסי העבודה, כולל קוד האפליקציה, קובצי build, קובצי אימג' של קונטיינרים, נתונים, מדיניות בקרת גישה שמבוססת על תפקידים (RBAC)/IAM, וקונטיינרים ו-pods שמופעלים.
- עדכון של פרטי הכניסה לאשכולות
- חשוב להשאיר את מאגרי הצמתים הרגילים רשומים לשדרוגים אוטומטיים.
- במצבים הבאים, כדאי לשדרג ידנית את האשכולות ואת מאגרי הצמתים כדי לטפל בפגיעויות במסגרת לוחות הזמנים של הארגון לתיקון פרצות:
- השדרוגים האוטומטיים נדחים בגלל גורמים כמו מדיניות תחזוקה.
- צריך להחיל תיקון לפני שהוא יהיה זמין בערוץ ההפצה שבחרתם. מידע נוסף זמין במאמר בנושא הפעלת גרסאות תיקון מערוץ חדש יותר.
- עוקבים אחרי האשכול והאפליקציות ומגיבים לכל ההתראות והתקריות באמצעות טכנולוגיות כמו מרכז הבקרה של מצב האבטחה ו-Google Cloud Observability.
- לספק ל-Google פרטים על הסביבה כשמתבקשים לעשות זאת לצורך פתרון בעיות.
- מוודאים שרישום ביומן ומעקב מופעלים באשכולות. אם לא מפעילים את האפשרות 'רישום ביומן' ו'מעקב', ואנשי התמיכה לא יכולים לגשת ליומנים האלה, התמיכה זמינה על בסיס המאמץ הטוב ביותר.