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