שלילת הגישה לפרויקט ב-Google Cloud

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

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

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

שיטות מומלצות להגדרת פרויקטים

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

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

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

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

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

מידע על איחוד שירותי אימות הזהות של כוח עבודה זמין במאמר איחוד שירותי אימות הזהות של כוח עבודה.

מומלץ להשתמש בקבוצות Google כדי לנהל את הגישה למשאבי הפרויקט

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

השימוש בקבוצות Google לא מתאים לכל הנסיבות. לדוגמה, לא מומלץ להשתמש בקבוצות שמבוססות רק על המבנה הארגוני של העסק כדי לנהל את הגישה. שיטות מומלצות לשימוש בקבוצות Google

למידע נוסף, תוכלו לקרוא על ניהול קבוצות ב Google Cloud מסוף ועל יצירת קבוצות בארגון.

שימוש ב-OS Login

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

למידע נוסף והוראות מפורטות, תוכלו לקרוא את על הגדרת OS Login.

הגבלת הגישה של חשבונות משתמשים חיצוניים

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

תוכלו להיעזר גם במאמר הגבלת זהויות לפי דומיין.

שימוש בשרתי proxy לאימות עם מסדי נתונים

שרתי proxy לאימות מאפשרים לקשר את מחזור החיים של פרטי הכניסה למסד נתונים למחזור החיים של זהות ב-Google. כשמשעים או מוחקים חשבון משתמש ב-Cloud Identity או ב-Google Workspace, הגישה למסדי הנתונים נשללת אוטומטית.

מידע נוסף זמין במאמרים בנושא שרת proxy ל-Cloud SQL Auth ושרת proxy ל-AlloyDB ל-PostgreSQL Auth.

תכנון תוך התחשבות ביכולת לעדכן את פרטי הכניסה

כדאי לתכנן את הפרויקטים והמשאבים כך שתוכלו לעדכן את פרטי הכניסה ברמת הפרויקט בלי לגרום לשיבושים. אלה סודות שקשורים לפרויקט עצמו, כמו מפתחות של חשבונות שירות, סודות של לקוחות ב-OAuth וסודות ספציפיים לאפליקציות כמו סיסמאות לרמה הבסיסית (root) של מסד הנתונים. מידע נוסף זמין במאמר בנושא מה עושים אם פרטי הכניסה ל-Google Cloud נחשפו?

הגבלת מפתחות API

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

מעקב אחרי הרשאות גישה

מעקב קפדני אחרי הגישה עוזר לצמצם את הסיכון לניצול לרעה של הרשאות הגישה. אתם יכולים להשתמש בכלי להמלצות לתפקידי IAM כדי לעקוב אחרי השימוש בתפקידים, וכך לאכוף את העיקרון של הרשאות מינימליות. בנוסף, היכולות של ניהול הרשאות בתשתית ענן (CIEM) ב-Security Command Center מאפשרות לכם לנהל את הזהויות שיש להן גישה למשאבים בפריסות שלכם ולצמצם נקודות חולשה פוטנציאליות שנובעות מטעויות בהגדרות.

שימוש בגישה אחידה ברמת הקטגוריה ב-Cloud Storage

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

שיטות מומלצות נוספות

מעבר לכל מה שתיארנו כאן, תוכלו להיעזר בשיטות המומלצות הבאות:

מתי חשוב לשלול גישה לפרויקטים ב- Google Cloud

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

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

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

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

ביטול גישה

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

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

מחיקת חשבון המשתמש מספק הזהויות

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

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

העברת החשבון לקבוצה אחרת

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

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

הסרת חשבון המשתמש ממדיניות ההרשאות של IAM

כדי להסיר חשבון משתמש מכללי מדיניות ההרשאות ברמת הפרויקט:

  1. נכנסים לדף ההרשאות של IAM במסוף Google Cloud .

    להרשאות של IAM

  2. בוחרים את הפרויקט שממנו רוצים להסיר את חשבון המשתמש.

  3. לוחצים על תיבת הסימון ליד השורה של החשבון שרוצים להסיר מהרשימה, ואז לוחצים על Remove.

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

עדכון של פרטי הכניסה לפרויקט

החלפת מפתחות של חשבונות שירות

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

  1. נכנסים לדף API credentials במסוף Google Cloud .

    API credentials

  2. לוחצים על השם של חשבון השירות שרוצים לשנות.

  3. בכרטיסייה Key, לוחצים על Add Key.

  4. לוחצים על Create new key.

  5. בהגדרה Key type, בוחרים את סוג המפתח שרוצים ליצור. ברוב המקרים מומלץ להשתמש ב-JSON, אבל אפשר להשתמש ב-P12 לצורך תאימות לאחור לקוד שתלוי במפתח הזה.

  6. לוחצים על Create. קובץ שמכיל את המפתח החדש יירד אוטומטית בדפדפן. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.

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

החלפת סודות של מזהי לקוחות ב-OAuth

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

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

  1. נכנסים לדף API credentials במסוף Google Cloud .

    API credentials

  2. לוחצים על השם של מזהה הלקוח ב-OAuth 2.0 שרוצים לשנות.

  3. לוחצים על Reset secret בדף Client ID.

  4. לוחצים על Reset בהודעת האישור כדי לבטל מיידית את הסוד הקודם וליצור סוד חדש. שימו לב שכל המשתמשים הפעילים יצטרכו לעבור אימות מחדש בבקשה הבאה שהם ישלחו.

  5. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.

החלפת מפתחות ה-API

אנשים לא יכולים להשתמש במפתחות API כדי לקבל גישה לפרויקט או לנתוני המשתמשים, אבל הם קובעים את מי Google תחייב על בקשות API. חשבונות משתמשים עם תפקידים כמו 'צפייה' או אדמינים של מפתחות API יכולים לראות את מפתחות ה-API של הפרויקט. אם יש לכם מפתחות ללא הגבלה, כדי לשלול ממישהו גישה לפרויקט תצטרכו למחוק את המפתחות האלה או ליצור אותם מחדש.

  1. נכנסים לדף API credentials במסוף Google Cloud .

    API credentials

  2. לוחצים על השם של מפתח ה-API שרוצים לשנות.

  3. לוחצים על Regenerate key.

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

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

שלילת הגישה למכונות וירטואליות

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

  1. מסירים את כל מפתחות ה-SSH ברמת הפרויקט שלאותו משתמש יש גישה אליהם.

  2. מסירים את המפתחות ברמת המכונה בכל אחת מהמכונות הווירטואליות שבהן למשתמש הייתה גישה ל-SSH.

  3. מסירים את החשבון של המשתמש הזה מכל המכונות הווירטואליות שאליהן יש לו גישה.

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

  5. מוודאים שההגדרות של חומת האש של המכונה הווירטואלית לא שונות ממה שתוכנן או מצופה.

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

ביטול הגישה למסדי נתונים

אם הפרויקט שלכם לא משתמש במשאבים של Cloud SQL או AlloyDB ל-PostgreSQL, תוכלו לדלג על השלב הזה.

כדי לבטל את הגישה למסד נתונים של Cloud SQL, מבצעים את הפעולות הבאות:

  1. נכנסים לדף SQL instances במסוף Google Cloud .

    לדף SQL instances

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

  3. בתפריט השמאלי, לוחצים על Connections.

  4. מוודאים שכתובות ה-IP ברשימה Authorized networks ושהאפליקציות ברשימה App Engine authorization תואמות למצופה. אם למי שרוצים לשלול ממנו גישה יש גישה לרשתות או לאפליקציות שמופיעות כאן, יש לו גישה למסד הנתונים הזה.

  5. בתפריט השמאלי לוחצים על Users.

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

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

פריסה מחדש של אפליקציות ב-App Engine

כברירת מחדל, לאפליקציות ב-App Engine יש גישה לחשבון שירות עם הרשאת עריכה בפרויקט המשויך. מי שמטפל בבקשות של App Engine יכול, בין השאר, ליצור מכונות וירטואליות חדשות ולקרוא או לשנות את הנתונים ב-Cloud Storage. מי שיכול לפרוס את הקוד ל-App Engine יוכל להשתמש באותו חשבון שירות בתור פרצת Backdoor לפרויקט. אם אתם חוששים שהקוד של האפליקציות שפרסתם לא מאובטח, כדאי לפרוס אותן מחדש (כולל כל מודול) מתמונה שאתם יודעים שהיא טובה מהמערכת לניהול גרסאות.

איך מוודאים שההרשאות הוסרו

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

כדי למצוא משאבים שלמשתמש מסוים יש גישה אליהם ברמת הארגון, משתמשים ב-method search-all-iam-policies ב-Google Cloud CLI. לדוגמה, כדי לברר אם למשתמש יש גישה למשאבים שלכם, תוכלו להריץ את הפקודה:

gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'

כאשר:

  • ORGANIZATION_ID הוא מספר הארגון.
  • ‫IDENTITY הוא המזהה של המשתמש, למשל כתובת אימייל.

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

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

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