במסמך הזה נפרט על שיטות מומלצות ונהלים לשלילת הגישה של משתמשים ל 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 כדי לעקוב אחרי השימוש בתפקידים, וכך לאכוף את העיקרון של הרשאות מינימליות. בנוסף, היכולות של ניהול הרשאות ב-Cloud Infrastructure (CIEM) ב-Security Command Center מאפשרות לכם לנהל את הזהויות שיש להן גישה למשאבים בפריסות שלכם ולצמצם נקודות חולשה פוטנציאליות שנובעות מטעויות בהגדרות.
שימוש בגישה אחידה ברמת הקטגוריה ב-Cloud Storage
גישה אחידה ברמת הקטגוריה מאפשרת לכם להשתמש ב-IAM בלבד כדי לנהל הרשאות לקטגוריות של Cloud Storage. אפשר להשתמש בגישה אחידה ברמת הקטגוריה יחד עם אפשרויות אחרות של בקרת גישה כדי להגדיר בצורה מדויקת יותר למי תהיה גישה לתוכן בקטגוריות.
שיטות מומלצות נוספות
מעבר לכל מה שתיארנו כאן, תוכלו להיעזר בשיטות המומלצות הבאות:
- שיטות מומלצות לשימוש בחשבונות שירות
- בחירת אבטחה לאזור הנחיתה ב- Google Cloud
- אימות מפורש של כל ניסיון גישה
מתי חשוב לשלול גישה לפרויקטים Google Cloud
אם יישמתם את השיטות המומלצות להגדרת הפרויקט, תוכלו להיעזר בטבלה הבאה כדי להבין מתי ואיך תוכלו לשלול גישה.
| תרחיש | אפשרויות לשלילת הגישה |
|---|---|
| עובד עזב את החברה. | אם איחדתם בין Cloud Identity או Google Workspace, וגם הגדרתם שההרשאות יוקצו אוטומטית למשתמשים, יכול להיות שהגישה תישלל אוטומטית. אם לא הקפדתם על השיטות המומלצות ונתתם לזהויות של משתמשים חיצוניים גישה למשאבים, תצטרכו להסיר ידנית את הזהויות מהפרויקטים ומהמשאבים שלכם. |
| עובד עבר תפקיד. | תוכלו להסיר את העובד מהקבוצה של הצוות או המחלקה. |
| הסתיים חוזה העסקה. | אם איחדתם בין Cloud Identity או Google Workspace, וגם הגדרתם שההרשאות יוקצו אוטומטית למשתמשים, יכול להיות שהגישה תישלל אוטומטית. אם לא הקפדתם על השיטות המומלצות ונתתם לזהויות של משתמשים חיצוניים גישה למשאבים, תצטרכו להסיר ידנית את הזהויות מהפרויקטים ומהמשאבים שלכם. |
| החשבון נפרץ. | הוראות מפורטות מופיעות במאמר תגובה לפרטי כניסהGoogle Cloud שנחשפו. |
ביטול גישה
אם קיבלתם החלטות נבונות בשלב הגדרת הפרויקט, תוכלו לבצע את הפעולות הבאות ביעילות כדי לשלול מאנשים גישה.
אתם יכולים להשתמש בכלי הניתוח למדיניות כדי להחליט לאילו משאבים לאנשים תהיה גישה. הוראות מפורטות מופיעות במאמר ניתוח מדיניות IAM.
מחיקת חשבון המשתמש מספק הזהויות
אם מישהו עזב את הארגון שלכם ואיחדתם בין Cloud Identity או Google Workspace לבין ספק הזהויות שלכם, וגם הגדרתם שההרשאות יוקצו אוטומטית למשתמשים, יכול להיות שהגישה תישלל אוטומטית.
מידע על מחיקת משתמשים באיחוד שירותי אימות הזהות של כוח עבודה זמין במאמר מחיקת משתמשים באיחוד שירותי אימות הזהות של כוח עבודה והנתונים שלהם.
ביטול סשנים של משתמשים במאגרי כוח עבודה
אם יש חשד שהפרטים של משתמש ב-Workforce נפרצו או אם רוצים להפסיק באופן מיידי סשנים פעילים לפני שהמחיקה תושלם, צריך לבטל את הסשנים של המשתמש.
מידע נוסף זמין במאמר ביטול סשנים של משתמשים באיחוד שירותי אימות הזהות של כוח עבודה.
העברת החשבון לקבוצה אחרת
אם מישהו עבר תפקיד, תוכלו להסיר את חשבון המשתמש שלו מהקבוצה בקבוצות Google. אם איחדתם בין Cloud Identity או Google Workspace לבין ספק הזהויות שלכם, וגם הגדרתם שחברי הקבוצה ינוהלו אוטומטית, יכול להיות שהגישה תישלל אוטומטית.
מידע נוסף מופיע במאמר בנושא צפייה בפרטי הקבוצה ועריכתם.
הסרת חשבון המשתמש מכללי מדיניות ההרשאות של IAM
כדי להסיר חשבון משתמש מכללי מדיניות ההרשאות ברמת הפרויקט:
נכנסים לדף ההרשאות של IAM במסוף Google Cloud .
בוחרים את הפרויקט שממנו רוצים להסיר את חשבון המשתמש.
לוחצים על תיבת הסימון ליד השורה של החשבון שרוצים להסיר מהרשימה, ואז לוחצים על Remove.
כדי לבדוק מיקומים אחרים שבהם אפשר להגדיר את מדיניות ההרשאה, כולל תיקיות, ארגון או משאבים פרטניים, אפשר לעיין במאמר בדיקה שההרשאות הוסרו.
עדכון של פרטי הכניסה לפרויקט
אם למי שאתם רוצים לבטל את הגישה שלו הייתה גישה לפרטי כניסה ברמת הפרויקט, כמו מפתחות של חשבונות שירות, סודות של לקוחות ב-OAuth או מפתחות API, אתם צריכים לעדכן את פרטי הכניסה האלה.
החלפת מפתחות של חשבונות שירות
אם אתם משתמשים במפתחות של חשבונות שירות כדי לאמת אותם, תצטרכו להחליף את המפתחות. בנוסף, כדאי לבדוק אם לאותו אדם הייתה גישה למפתחות של חשבון השירות מחוץ לכלים של Google Cloud, למשל במאגר המקורות של הקוד או בהגדרות האפליקציה.
נכנסים לדף API credentials במסוף Google Cloud .
לוחצים על השם של חשבון השירות שרוצים לשנות.
בכרטיסייה Key, לוחצים על Add Key.
לוחצים על Create new key.
בהגדרה Key type, בוחרים את סוג המפתח שרוצים ליצור. ברוב המקרים מומלץ להשתמש ב-JSON, אבל אפשר להשתמש ב-P12 לצורך תאימות לאחור לקוד שתלוי במפתח הזה.
לוחצים על Create. קובץ שמכיל את המפתח החדש יירד אוטומטית בדפדפן. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.
אחרי שמוודאים שהמפתח החדש פועל כמו שצריך, חוזרים לדף של פרטי הכניסה ומוחקים את המפתח הקודם שמקושר לאותו חשבון שירות.
החלפת סודות של מזהי לקוחות ב-OAuth
אי אפשר להשתמש בסודות של מזהי הלקוחות ב-OAuth כדי לקבל גישה ישירה לפרויקט. עם זאת, אם פורץ יודע את הסוד של מזהה הלקוח ב-OAuth, הוא יכול להתחזות לאפליקציה ולבקש גישה לחשבונות Google של המשתמשים שלכם מאפליקציה זדונית.
אם אתם רוצים לשלול גישה ממישהו שיודע את הסודות של מזהי הלקוחות ב-OAuth, כולל במאגר של קוד המקור, בהגדרות של האפליקציה או באמצעות תפקידי IAM, יכול להיות שתצטרכו לשנות את הסודות.
נכנסים לדף API credentials במסוף Google Cloud .
לוחצים על השם של מזהה הלקוח ב-OAuth 2.0 שרוצים לשנות.
לוחצים על Reset secret בדף Client ID.
לוחצים על Reset בהודעת האישור כדי לבטל מיידית את הסוד הקודם וליצור סוד חדש. שימו לב שכל המשתמשים הפעילים יצטרכו לעבור אימות מחדש בבקשה הבאה שהם ישלחו.
תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.
החלפת מפתחות ה-API
אנשים לא יכולים להשתמש במפתחות API כדי לקבל גישה לפרויקט או לנתוני המשתמשים, אבל הם קובעים את מי Google תחייב על בקשות API. חשבונות משתמשים עם תפקידים כמו 'צפייה' או אדמינים של מפתחות API יכולים לראות את מפתחות ה-API של הפרויקט. אם יש לכם מפתחות ללא הגבלה, כדי לשלול ממישהו גישה לפרויקט תצטרכו למחוק את המפתחות האלה או ליצור אותם מחדש.
נכנסים לדף API credentials במסוף Google Cloud .
לוחצים על השם של מפתח ה-API שרוצים לשנות.
לוחצים על Regenerate key.
תיפתח תיבת דו-שיח עם המפתח החדש שנוצר. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם רוצים להחליף אותו.
אחרי שמוודאים שהאפליקציות החדשות פועלות כמו שצריך עם המפתח החדש, חוזרים לדף של פרטי הכניסה ומוחקים את המפתח הקודם שאין עליו הגבלה.
שלילת הגישה למכונות וירטואליות
אם למי שרוצים לשלול ממנו גישה אין גישה לאף מכונה וירטואלית בפרויקט שלכם, תוכלו לדלג על השלב הזה.
מסירים את כל מפתחות ה-SSH ברמת הפרויקט שלאותו משתמש יש גישה אליהם.
מסירים את המפתחות ברמת המכונה בכל אחת מהמכונות הווירטואליות שבהן למשתמש הייתה גישה ל-SSH.
מסירים את החשבון של המשתמש הזה מכל המכונות הווירטואליות שאליהן יש לו גישה.
בודקים אם יש אפליקציות חשודות שאותו משתמש אולי התקין כדי לתת לעצמו גישת Backdoor למכונה הווירטואלית. אם לא בטוחים שהקוד שמריצים במכונה הווירטואלית מאובטח, יוצרים אותה מחדש ופורסים מחדש את האפליקציות הדרושות מהמקור.
מוודאים שההגדרות של חומת האש של המכונה הווירטואלית לא שונות ממה שתוכנן או מצופה.
אם יוצרים מכונות וירטואליות חדשות מתמונות בסיס בהתאמה אישית, מוודאים שתמונות הבסיס לא שונו בדרך שעלולה לסכן את האבטחה של המכונות הווירטואליות החדשות.
ביטול הגישה למסדי נתונים
אם אתם לא משתמשים במשאבים של Cloud SQL או של AlloyDB ל-PostgreSQL בפרויקט, תוכלו לדלג על השלב הזה.
כדי לשלול את הגישה למסד נתונים של Cloud SQL, מבצעים את הפעולות הבאות:
נכנסים לדף SQL instances במסוף Google Cloud .
לוחצים על מספר המכונה במסד הנתונים שבו רוצים לשלול את הגישה.
בתפריט השמאלי, לוחצים על Connections.
מוודאים שכתובות ה-IP ברשימה Authorized networks ושהאפליקציות ברשימה App Engine authorization תואמות למצופה. אם למי שרוצים לשלול ממנו גישה יש גישה לרשתות או לאפליקציות שמופיעות כאן, יש לו גישה למסד הנתונים הזה.
בתפריט השמאלי לוחצים על Users.
מוחקים או משנים את הסיסמה של כל החשבונות שלאותו משתמש יש גישה אליהם. אל תשכחו לעדכן את האפליקציות שתלויות באותם חשבונות משתמש.
כדי לבטל את הגישה למסד נתונים של AlloyDB ל-PostgreSQL, אפשר לעיין במאמר בנושא הסרה של משתמש IAM או חשבון שירות מאשכול.
פריסה מחדש של אפליקציות ב-App Engine
כברירת מחדל, לאפליקציות ב-App Engine יש גישה לחשבון שירות עם הרשאת עריכה בפרויקט המשויך. מי שמטפל בבקשות של App Engine יכול, בין השאר, ליצור מכונות וירטואליות חדשות ולקרוא או לשנות את הנתונים ב-Cloud Storage. מי שיכול לפרוס את הקוד ל-App Engine יוכל להשתמש באותו חשבון שירות בתור פרצת Backdoor לפרויקט. אם אתם חוששים שהקוד של האפליקציות שפרסתם לא מאובטח, כדאי לפרוס אותן מחדש (כולל כל מודול) מתמונה שאתם יודעים שהיא טובה מהמערכת לניהול גרסאות.
איך מוודאים שההרשאות הוסרו
אפשר לבדוק את ההרשאות ברמת הארגון, ברמת הפרויקט או באמצעות כלי הניתוח למדיניות.
כדי למצוא משאבים שלמשתמש מסוים יש גישה אליהם ברמת הארגון, משתמשים בשיטה search-all-iam-policies ב-Google Cloud CLI. לדוגמה, כדי לברר אם למשתמש יש גישה למשאבים שלכם, תוכלו להריץ את הפקודה:
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
כאשר:
ORGANIZATION_IDהוא מספר הארגון.-
IDENTITYהוא המזהה של המשתמש, למשל כתובת אימייל.
כדי לבדוק את ההרשאות בפרויקט, אפשר לעיין במאמר ההרשאות שיש לחשבון משתמש בפרויקט.
כדי לאמת הרשאות באמצעות כלי הניתוח למדיניות, ראו קביעה של המשאבים שאליהם יש לחשבון משתמש גישה.
המאמרים הבאים
יוצרים מדיניות דחייה כדי לציין אילו הרשאות המשתמש לא יכול יותר לגשת אליהן.