הרשאה ובקרת גישה

הפלטפורמה לניהול זהויות והרשאות גישה (IAM) ב-Google Distributed Cloud (GDC) air-gapped מאפשרת לכם לקבוע למי תהיה גישה למשאבים מסוימים ואילו פעולות הם יוכלו לבצע במשאבים האלה.

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

המסמך הזה מיועד לקהלים בקבוצות של אדמינים של הפלטפורמה ואופרטורים של אפליקציות (כמו אדמינים ממחלקת IT, מהנדסי אבטחה או מפתחים של אפליקציות) שרוצים להבין הרשאות ובקרת גישה ב-GDC עם air gap. המסמך הזה עוזר גם למנהלי תשתית להבין את מושגי היסוד של בקרת גישה. למידע נוסף, אפשר לעיין במאמר בנושא קהלים ב-GDC עם air gap.

מודל בקרת הגישה

הגישה ב-GDC מבוססת על שלושה רכיבי ליבה: חברים (מי), תפקידים (מה) והיקף המשאבים (איפה).

מודל בקרת הגישה

בקרת הגישה מורכבת משני שלבים נפרדים – הוכחת הזהות (אימות) וקביעת הפעולות שאפשר לבצע (הרשאה):

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

חברים

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

זהויות אנושיות

זהויות אנושיות הן המשתמשים והקבוצות שנכנסים ל-GDC. במקום לאחסן חשבונות משתמשים או סיסמאות, GDC מתחבר למערכות הכניסה הקיימות של הארגון או לספקי זהויות (IdP) (כמו Active Directory,‏ LDAP או Okta) באמצעות פרוטוקולים סטנדרטיים של איחוד שירותי אימות הזהות, כמו OpenID Connect ‏(OIDC) או SAML 2.0.

יש שני סוגים של זהויות אנושיות:

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

‫GDC משתמש ב-IdP כדי לזהות באופן ייחודי זהויות של בני אדם. מכיוון שהסביבה שלכם יכולה להתחבר לכמה ספקי זהויות (לדוגמה, אם מחלקות שונות משתמשות במערכות כניסה שונות), GDC מבחין בין ספקי הזהויות כדי לוודא שאתם מעניקים גישה לאדם הנכון.

כשמנהלים את הגישה, GDC מוסיף באופן אוטומטי קידומת ייחודית של ספק הזהויות לכל שמות המשתמשים והקבוצות החיצוניים:

  • פורמט: idpprefix-username@domain.com (או idpprefix-group-name לקבוצות).
  • דוגמה: אם ספק הזהויות של הארגון שלכם מוגדר עם הקידומת agency-a, ואתם נכנסים לחשבון בתור alice@example.com, מערכת GDC IAM מזהה אתכם בתור agency-a-alice@example.com.

זהויות לא אנושיות

זהויות לא אנושיות נקראות זהויות שירות (או חשבונות שירות). אתם יוצרים ומנהלים אותם ישירות ב-GDC (כמשאביםProjectServiceAccount) כדי לאפשר לאפליקציות, לסקריפטים או לעומסי עבודה אוטומטיים ליצור אינטראקציה עם ממשקי API בצורה מאובטחת.

מכיוון שחשבונות שירות מנוהלים באופן פנימי על ידי GDC, הם לא משתמשים בקידומות של ספק זהויות. במקום זאת, הם מזוהים לפי הפרויקט והשם שלהם (לדוגמה, serviceAccount:projectName:serviceAccountName כשמשתמשים ב-CLI של gdcloud).

מידע נוסף מופיע במאמר אבטחת מפתחות של חשבונות שירות.

הרשאות ותפקידים

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

ב-GDC יש שני סוגים של תפקידים:

  • תפקידים מוגדרים מראש: חבילות מובנות של הרשאות שנוצרו ומנוהלות על ידי GDC. ‫GDC מספק ספרייה מקיפה של תפקידים מוגדרים מראש שמותאמים לתפקידים ולשירותים ספציפיים (ממגוון רחב של תפקידים כמו Project Viewer ועד לתפקידים פרטניים כמו Bucket Project Admin או KMS Viewer).
  • תפקידים בהתאמה אישית: חבילות של הרשאות שמוגדרות על ידי המשתמש, שאפשר ליצור כשהתפקידים המוגדרים מראש לא עונים על הצרכים של הארגון.

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

היקף המשאבים

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

אפשר להקצות תפקידים בהיקפי המשאבים הבאים:

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

מידע נוסף זמין במאמרים בנושא היררכיית משאבים ובקרת הרשאות ביקום מרובה אזורים.

איך מאשרים גישה

‫GDC מנהל ומאשר גישה בעיקר באמצעות מודל של בקרת גישה מבוססת-תפקידים (RBAC). במודל RBAC, לא מקצים הרשאות ישירות למשתמשים או לעומסי עבודה ספציפיים. במקום זאת, אתם מקצים תפקידים לחברים בהיקף משאבים ספציפי כדי לקבוע את הגישה.

‫GDC מטמיע RBAC באמצעות המשאבים המותאמים אישית הבאים של Kubernetes:

  • ‫IAMRole: מגדיר חבילה ספציפית של הרשאות.
  • ‫IAMRoleBinding: מקשר חבר (משתמש אנושי, קבוצה או חשבון שירות) אל IAMRole בהיקף של ארגון או פרויקט.

כדי להעניק גישה למשאבים של ארגון או פרויקט, אפשר ליצור IAMRoleBinding באמצעות מסוף GDC,‏ gdcloud CLI או על ידי החלת מניפסטים של משאבים בהתאמה אישית (קבצי YAML) באמצעות kubectl CLI.

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

בעוד שמסוף GDC וה-gdcloud CLI מתחברים למשאבים שלכם באופן אוטומטי, גישה ישירה ל-API באמצעות ה-kubectl CLI מחייבת אימות מול אשכול Kubernetes הספציפי או שרת ה-API שמארח את המשאב הזה, על ידי יצירת קובץ kubeconfig. פרטים נוספים זמינים במאמר בנושא כניסה ויצירה של קובץ kubeconfig.

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

מה ההבדל בין GDC עם air gap לבין Google Cloud

אם יש לכם ניסיון בניהול גישה ב- Google Cloud,‏ GDC משתמשת במושגים דומים אבל מיישמת אותם בצורה שונה כדי לפעול במסגרת תשתית מבוססת-Kubernetes עם פער אוויר.

בטבלה הבאה מוצגת השוואה בין IAM ב-GDC לבין Google Cloud:

תכונה תיאור GDC עם air gap Google Cloud
זהות המשתמש (אימות) מערכת זהויות שמשמשת לאימות משתמשים אנושיים. מאוחד עם ספק הזהויות החיצוני באמצעות קידומות חובה של ספק הזהויות (לדוגמה, idpprefix-user@domain.com). חשבונות Google (כמו Gmail) או זהויות ארגוניות מאוחדות באמצעות Cloud Identity או Google Workspace.
מנוע הרשאות המערכת הבסיסית שמעריכה את ההרשאות ומאכפת אותן. בעיקר בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, שבה בקשות גישה מוערכות באופן מקומי על ידי שרת ה-API מול קישורי תפקידים. אפשר להשתמש במדיניות הארגון כדי להגדיר הגבלות על משאבים. שירות Cloud IAM הגלובלי של Google. הערכה של בקשות ל-API באופן מרכזי בהשוואה למדיניות גישה שמצורפת לכל רמה בהיררכיית המשאבים.
קישורים בין תפקידים איך חברים ממופים לתפקידים במשאבים ספציפיים. IAMRoleBinding משאבים מותאמים אישית. כל קישור הוא אובייקט שמקשר בין משתמשים לתפקיד אחד. ההרשאות של תפקיד IAM הן מצטברות בלבד (אפשר להגדיר כללי דחייה בנפרד באמצעות מדיניות הארגון). מדיניות גישה אחת של IAM שמצורפת לכל משאב, תיקייה או ארגון. מכיל כמה קישורים שממפים חברים לתפקידים, ותומך בכללים מותנים או בכללי דחייה.
חשבונות שירות זהויות לא אנושיות שמשמשות אפליקציות ועומסי עבודה אוטומטיים. חשבונות שירות מקומיים שנוצרו בתוך פרויקט ספציפי (ProjectServiceAccount). מפתחות ציבוריים מאוחסנים באשכול, ומפתחות פרטיים מנוהלים ומאובטחים באופן מקומי על ידי הלקוח. זהויות גלובליות שמנוהלות באופן מרכזי על ידי Google. אפשר לנהל את פרטי הכניסה באופן אוטומטי דרך Google, או להוריד אותם כקובצי מפתחות כדי לבצע אימות מכל מקום.
היררכיית המשאבים מבנה קונטיינר שמשמש לארגון משאבים ולקבלת הרשאות בירושה. היררכיה דו-שכבתית: ארגון > פרויקטים היררכיה מרובת רמות: ארגון > תיקיות > פרויקטים
היקף הרשאות בכמה אזורים איך הרשאות מוערכות ומופצות באזורי זמינות או באזורים. משתמש ב-Kubernetes RBAC שמנוהל על ידי שרת API גלובלי, שמתאם ומשכפל את קישורי התפקידים בשרתי API אזוריים, כך שהגישה חלה על כל האזורים כברירת מחדל. משתמש בשירות IAM גלובלי שמנוהל במלואו. ההרשאות שמוקצות בכל רמת משאב הן גלובליות באופן מובנה, והן חלות באופן אוטומטי על כל האזורים והתחומים.
כלים ללקוחות ממשקי משתמש ראשיים, כלי CLI וממשקי API שמשמשים לניהול הגישה. מסוף GDC,‏ gdcloud CLI וממשקי KRM API. Google Cloud מסוף Google Cloud,‏ ה-CLI של gcloud וממשקי API ל-REST או ל-gRPC.
גישה ישירה ל-API איך כלים ותסריטים מאמתים את עצמם כדי לנהל משאבים ישירות באמצעות ממשקי API. גישה ישירה ל-API באמצעות kubectl CLI מחייבת אימות לאשכול Kubernetes הספציפי או לשרת ה-API שמארח את המשאב הזה על ידי יצירת קובץ kubeconfig. (מסוף GDC ו-gdcloud CLI מתחברים למשאבים באופן אוטומטי). גישה ישירה ל-API באמצעות נקודות קצה של gcloud או REST/gRPC משתמשת באמצעי אימות מרכזיים (gcloud auth login) שחלים באופן גלובלי על כל השירותים, בלי צורך בהתחברות ספציפית לאשכול.

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