הגדרת הרשאות עיצוב

במסמך הזה מפורטות שיטות מומלצות לעיצוב הרשאות ביקום של Google Distributed Cloud (GDC) במודל Air-gapped. הנושאים שמוסברים במאמר הזה:

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

הגדרה של ספק זהויות לכל ארגון

מפעיל צריך להגדיר ספק זהויות אחד או יותר לכל ארגון. אדמין מתחבר לספק זהויות כדי לנהל שירותי אימות לאפליקציות ב-GDC.

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

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

הגדרת אימות רב-גורמי בספק הזהויות

האימות ב-GDC מתבסס על פלטפורמת ניהול הזהויות והרשאות הגישה שלכם, כולל הגדרות אבטחה נוספות כמו אימות רב-שלבי. מומלץ להגדיר אימות רב-שלבי באמצעות מפתח פיזי לכל משתמש שעשוי לגשת למשאבים רגישים.

הגבלת שירותים מנוהלים ושירותים מ-Marketplace

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

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

ניהול קובצי kubeconfig לכמה אשכולות

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

כשמשתמשים במסוף GDC, לא צריך לדעת איזה אשכול בסיסי מבצע משימה, כי מסוף GDC מסתיר את הפעולות ברמה הנמוכה, כמו חיבור לאשכול.

עם זאת, כשעובדים עם gdcloud CLI או kubectl CLI, יכול להיות שיהיו כמה קובצי kubeconfig כדי לבצע את המשימות. חשוב לוודא שנכנסתם באמצעות פרטי הכניסה של kubeconfig לאשכול המתאים למשימה.

שיטות מומלצות לשימוש בחשבונות שירות של Kubernetes

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

  • לא מומלץ להוריד פרטי כניסה קבועים של חשבון שירות לשימוש מחוץ ל-GDC.
  • חשוב להכיר את נתיבי ההסלמה ב-Kubernetes למשתמשים או לחשבונות שירות שיש להם אפשרות ליצור ולערוך קבוצות Pod.
  • מגדירים את השדה expirationSeconds לתקופה קצרה עבור תחזית הטוקן של חשבון השירות של עומסי העבודה.
  • מומלץ לבצע רוטציה של פרטי הכניסה לחשבון השירות באופן קבוע.

התחשבות בעיקרון של הרשאות מינימליות

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

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

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

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

אם החברה שלכם משתמשת בכמה ארגונים, לא מומלץ שלמשתמש בודד יהיו תפקידים עם הרשאות גבוהות בכמה ארגונים, כי זה עלול לפגוע במטרה של הפרדת הארגונים מלכתחילה.