במסמך הזה מוסברות שיטות מומלצות לביטול הגישה של אנשים לפרויקטים ב-Google Cloud Platform. המסמך מחולק לשני חלקים. בחלק הראשון מוסבר איך מגדירים פרויקטים כך שיהיה קל לבטל את הגישה. בחלק השני מוסבר בפירוט איך מבטלים את הגישה של אנשים לסוגים שונים של משאבים.
רקע
ביטול הגישה של אנשים הוא שלב קריטי במחזור החיים של משאבים ב-Google Cloud Platform. כשעובדים עוזבים את החברה, כשההתקשרות עם עובדי קבלן מסתיימת או כשאנשי צוות עוברים לפרויקט אחר, צריך לבצע כמה פעולות כדי לבטל בצורה יסודית את הגישה שהם לא צריכים יותר למשאבים.
חלק מהתהליכים האלה הם לא בגדר חובה. עליכם להחליט אילו מהפעולות לבצע בהתאם לצורכי האבטחה, למוצרים שבשימוש ולאמון שלכם במי שאתם שוקלים אם לבטל את הגישה שלו. תוכלו להיעזר במסמך הזה כדי לקבוע כללי מדיניות ונהלים שיתאימו לכם ולשימוש שלכם ב-GCP.
הגדרת הפרויקט
כדי שתוכלו לבטל את הגישה של המשתמשים בצורה יעילה ומאובטחת, אתם יכולים לקבל החלטות מושכלות כבר בשלב ההגדרה של הפרויקט.
הגבלת הגישה למכונות וירטואליות
מכונות וירטואליות – כמו אלו שמשמשות את Google Compute Engine, את Google Kubernetes Engine ואת הסביבה הגמישה של App Engine – הן קרקע גדולה למתקפה פוטנציאלית. אם למישהו הייתה גישה למכונה וירטואלית, במיוחד עם הרשאות לרמה הבסיסית (root) או הרשאות אדמין, קשה מאוד להבטיח שהוא לא שינה אותה והשאיר פרצת Backdoor שתיתן לו גישה בעתיד. כדאי להגביל את הגישה למכונה הווירטואלית רק למי שיש לו צורך ברור וספציפי בה. שימו לב שכברירת מחדל, לאנשים עם הרשאת עריכה בפרויקט ולבעלים שלו יש הרשאות אדמין בכל המכונות הווירטואליות באותו פרויקט.
לפני שאתם נותנים גישה לאנשים, נסו לחשוב מה הם צריכים לעשות ולְמה הם צריכים גישה, ולמצוא דרכים אחרות לתת מענה לאותם צרכים. במקום לתת לכל מפתח גישת כניסה כדי לפרוס את הקוד, שקלו להשתמש בכלים כמו Chef, Puppet ו-Salt כדי לנהל את הפריסות.
תכנון תוך התחשבות ביכולת לעדכן את פרטי הכניסה
כדאי לתכנן את הפרויקטים והמשאבים כך שתוכלו לעדכן את פרטי הכניסה שקשורים לפרויקטים בלי לגרום לשיבושים – סודות שקשורים לפרויקטים עצמם כמו מפתחות של חשבונות שירות, סודות של לקוחות ב-OAuth וסודות ספציפיים לאפליקציות כמו סיסמאות לרמה הבסיסית (root) של מסד הנתונים. מומלץ לתכנן את זה כבר עכשיו כדי שתוכלו לעדכן בקלות את פרטי הכניסה החדשים בכל אפליקציה שבה הם נדרשים.
הגבלת מפתחות API
כשאתם יוצרים ומנהלים מפתחות API, כדאי להגביל את כתובות ה-IP, את האפליקציות ואת האתרים שניתן להשתמש בהם. מפתחות ה-API גלויים לכל המשתמשים בפרויקט, כך שכדי לבטל את הגישה לחיוב צריך להעביר או למחוק כל מפתח שאין עליו הגבלה. בשיטות המומלצות לשימוש מאובטח במפתחות API תוכלו לקרוא מידע נוסף בנושא, כדי לתכנן את השימוש בהתאם.
ביטול הגישה
אם קיבלתם החלטות נבונות בשלב הגדרת הפרויקט, תוכלו לבצע את הפעולות הבאות ביעילות ובבטחה כדי לבטל את הגישה של אנשים.
הסרת החשבון מהפרויקט
נכנסים לדף ההרשאות של IAM במסוף Google Cloud Platform.
בוחרים את הפרויקט שממנו רוצים להסיר את החשבון.
לוחצים על תיבת הסימון ליד השורה של החשבון שרוצים להסיר מהרשימה, ואז לוחצים על Remove. אפשר גם ללחוץ על הסמל של פח האשפה ליד החשבון שרוצים להסיר.
עדכון פרטי הכניסה לפרויקט
מפתחות של חשבונות שירות
חשבונות שירות הם סוג מיוחד של חשבון Google שמייצג משתמש לא אנושי, שצריך לאמת ולאשר כדי לתת לו גישה לנתונים ב-Google APIs.
רק בעלי הפרויקט יכולים ליצור חשבונות שירות חדשים או מפתחות חדשים לחשבונות שירות קיימים. אם מי שאתם רוצים לבטל את הגישה שלו הוא בעלי הפרויקט, תצטרכו לעדכן את המפתחות הקיימים של חשבון השירות. אם הוא לא בעלי הפרויקט, תוכלו לדלג על השלב הזה. עם זאת, כדאי לבדוק אם הייתה לו גישה למפתחות של חשבונות השירות מחוץ לכלים המאובטחים של Google Cloud Platform, כמו המאגר של קוד המקור או הגדרות האפליקציה.
נכנסים לדף פרטי הכניסה של ה-API במסוף Google Cloud Platform.
לוחצים על Create credentials ואז על Service account key.
בוחרים את חשבון היעד מהתפריט Service account.
בהגדרה Key type, בוחרים את סוג המפתח שרוצים ליצור. ברוב המקרים מומלץ להשתמש ב-JSON, אבל אפשר להשתמש ב-P12 לצורך תאימות לאחור לקוד שתלוי במפתח הזה.
לוחצים על Create. קובץ שמכיל את המפתח החדש יירד אוטומטית בדפדפן. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.
אחרי שמוודאים שהמפתח החדש פועל כמו שצריך, חוזרים לדף של פרטי הכניסה ומוחקים את המפתח הקודם שמקושר לאותו חשבון שירות.
סודות של מזהי לקוחות ב-OAuth
אי אפשר להשתמש בסודות של מזהי הלקוחות ב-OAuth כדי לקבל גישה ישירה לפרויקט. עם זאת, אם תוקף מצליח לגנוב את אסימוני הרענון של OAuth ש-Google סיפקה בשם המשתמשים של האפליקציה, התוקף יוכל להשתמש בסודות של מזהי הלקוחות כדי לקבל גישה לחשבונות Google של המשתמשים באותו היקף שהאפליקציה ביקשה במקור.
כל בעלי הפרויקט ומשתמשים עם הרשאת עריכה יכולים לראות את הסודות של מזהי הלקוחות ב-OAuth, אבל לא משתמשים עם הרשאת קריאה. אם מי שאתם רוצים לבטל את הגישה שלו הוא לא בעלי הפרויקט או משתמש עם הרשאת עריכה, תוכלו לדלג על השלב הזה. עם זאת, כדאי לבדוק אם הייתה לו גישה לסודות של מזהי הלקוחות מחוץ לכלים המאובטחים של Google Cloud Platform, כמו המאגר של קוד המקור או הגדרות האפליקציה.
נכנסים לדף פרטי הכניסה של ה-API במסוף Google Cloud Platform.
לוחצים על השם של מזהה הלקוח ב-OAuth 2.0 שרוצים לשנות. דף הפרטים של מזהה הלקוח שנבחר ייפתח.
לוחצים על Reset Code בדף הפרטים של מזהה הלקוח.
לוחצים על Reset בהודעת האישור כדי לבטל מיידית את הסוד הקודם וליצור סוד חדש. שימו לב שכל המשתמשים הפעילים יצטרכו לעבור אימות מחדש בבקשה הבאה שהם ישלחו.
תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם זקוקים לו.
מפתחות API
אנשים לא יכולים להשתמש במפתחות API כדי לקבל גישה לפרויקט או לנתוני המשתמשים, אבל הם קובעים את מי Google תחייב על בקשות API. כל אחד מהמשתמשים בפרויקט יכול לראות את מפתחות ה-API של אותו פרויקט. אם יש לכם מפתחות ללא הגבלה, כדי לבטל את הגישה של מישהו לפרויקט תצטרכו למחוק את המפתחות האלה או ליצור אותם מחדש.
נכנסים לדף פרטי הכניסה של ה-API במסוף Google Cloud Platform.
לוחצים על Create credentials ואז על API key.
תיפתח תיבת דו-שיח עם המפתח החדש שנוצר. תצטרכו לפרוס את המפתח הזה בכל אפליקציה שבה אתם רוצים להחליף אותו.
אחרי שמוודאים שהאפליקציות החדשות פועלות כמו שצריך עם המפתח החדש, חוזרים לדף של פרטי הכניסה ומוחקים את המפתח הקודם שאין עליו הגבלה.
ביטול הגישה למכונות וירטואליות
אם למי שאתם רוצים לבטל את הגישה שלו אין גישה לאף מכונה וירטואלית בפרויקט, תוכלו לדלג על השלב הזה.
מסירים את כל מפתחות ה-SSH ברמת הפרויקט שלאותו משתמש יש גישה אליהם.
מסירים את המפתחות ברמת המכונה בכל אחת מהמכונות הווירטואליות שבהן למשתמש הייתה גישה ל-SSH.
מסירים את החשבון של המשתמש הזה מכל המכונות הווירטואליות שאליהן יש לו גישה.
בודקים אם יש אפליקציות חשודות שאותו משתמש אולי התקין כדי לתת לעצמו גישת Backdoor למכונה הווירטואלית. אם לא בטוחים שהקוד שמריצים במכונה הווירטואלית מאובטח, יוצרים אותה מחדש ופורסים מחדש את האפליקציות הדרושות מהמקור.
מוודאים שההגדרות של חומת האש של המכונה הווירטואלית לא שונות ממה שתוכנן או מצופה.
אם יוצרים מכונות וירטואליות חדשות מתמונות בסיס בהתאמה אישית, מוודאים שתמונות הבסיס לא שונו בדרך שעלולה לסכן את האבטחה של המכונות הווירטואליות החדשות.
ביטול הגישה למסדי נתונים של Cloud SQL
אם אתם לא משתמשים במשאבים של Cloud SQL בפרויקט, תוכלו לדלג על השלב הזה.
נכנסים לדף המכונות של SQL במסוף Google Cloud Platform.
לוחצים על מספר המכונה במסד הנתונים שבו רוצים לבטל את הגישה.
לוחצים על Access Control. בכרטיסייה הזו, מוודאים שכתובות ה-IP ברשימה Authorized networks ושהאפליקציות ברשימה App Engine authorization תואמות למצופה. אם למי שרוצים לבטל את הגישה שלו יש גישה לרשתות או לאפליקציות שמופיעות כאן, יש לו גישה למסד הנתונים הזה.
לוחצים על Users. בכרטיסייה הזו, מוחקים או משנים את הסיסמה של כל החשבונות שלאותו משתמש יש גישה אליהם. אל תשכחו לעדכן את האפליקציות שתלויות באותם חשבונות משתמש.
פריסה מחדש של אפליקציות ב-App Engine
כברירת מחדל, לאפליקציות של App Engine יש גישה לחשבון שירות עם הרשאת עריכה בפרויקט המקושר. מי שמטפל בבקשות של App Engine יכול, בין השאר, ליצור מכונות וירטואליות חדשות ולקרוא או לשנות את הנתונים ב-Cloud Storage. ומי שיכול לפרוס את הקוד ל-App Engine יוכל להשתמש באותו חשבון שירות בתור פרצת Backdoor לפרויקט. אם אתם חוששים שהקוד של האפליקציות שפרסתם לא מאובטח, כדאי לפרוס אותן מחדש (כולל כל מודול) מגרסה שאתם יודעים שהיא טובה מהמערכת לניהול גרסאות.
בדיקת ההרשאות במשאבים אחרים
נסו לחשוב על משאבים אחרים בפרויקט שאולי לאותו משתמש יש גישה אליהם, ובדקו שההרשאות באותם משאבים מאובטחות. כדאי לבדוק את המשאבים הבאים:
- רשימות של בקרת גישה לקטגוריות של Cloud Storage
- הרשאות למערכי נתונים ב-BigQuery
- הרשאות לנושאים ב-Cloud Pub/Sub