להלן מספר דרכים לאבטח את סביבת הענן שלך ב-google cloud platform:
אימות דו-שלבי - מאפשר לנו להגדיר מקור אימות נוסף בגישה לניהול סביבת הענן שלנו. האימות בגוגל מובסס על חשבונות google. כתובות אלה יכולים להיות משתמשים בודדים או כחלק מארגון ב-google gsuite. גם אם יודעים את הסיסמא לחשבון שלך, לא ניתן לגשת לניהול המערכת בענן ללא הסיסמא החד פעמית שמונפקת מהמכשיר הנייד.
כאן תוכל למצוא את המידע על אופן האכיפה של MFA (עבור דומיינים של Google Suite, MFA משתמש ב -2 גורמים) באימות עבור תחומים של Google Suite: https://support.google.com/a/answer/2548882
הגדרת מדיניות משתמשים - הגדרה זו מאפשרת לנו להגדיר את מדיניות הסיסמא בגישה למערכת. כאן תוכל למצוא מידע נוסף על הגדרת דרישות סיסמה עבור הדומיין שלך ב- Google Suite: https://support.google.com/a/answer/139399?hl=iw
הגדרת הרשאות במודל least privilges - ב- IAM של Cloud ניתן להעניק גישה מפורטת למשאבי GCP ספציפיים ולמנוע גישה לא רצויה למשאבים אחרים. ענן IAM מאפשר לך לאמץ את עקרון האבטחה של לפחות זכויות, כך שאתה מעניק רק את הגישה הדרושה המשאבים שלך.
גישת ssh - ניתן להגדיר למשתמשים את היכולת להתחבר למחשב וירטואלי באמצעות SSH, אבל לא רוצה לתת להם את היכולת לנהל את משאבי Compute Engine, להוסיף את המפתח הציבורי של המשתמש לפרויקט, או להוסיף את הציבור של המשתמש מפתח למופע מסוים. באמצעות שיטה זו, תוכל להימנע מלהוסיף משתמש כחבר בפרוייקט, ועדיין להעניק להם גישה למקרים ספציפיים. בעזרת הרשאה של roles/compute.instanceAdmin.v1 הוא יכול להתחבר באופן אוטומטי באמצעות SSH.
הגדרות גישה למערכות - ישנם מספר כללים חשובים בהגדרות הגישה למערכת:
הגדר תפקידים מוגדרים מראש כך שתספק רק את הגישה המינימאלת הדרושה לגשת למשאבים.
התחייחס לכל רכיב ביישום שלך בענן בנפרד- צור חשבון עבור כל אחד מכם כך שיהיה ניתן להגדיר הרשאות בנפרד.
הגדר את התפקידים בהיקף הקטן ביותר שנדרש.
הגבל למי יש גישה לייצר חשבונות במערכת.
סובב את מפתחות השירות באמצעות ממשק ה-api של ה-iam.
השתמש בשם התצוגה של חשבון שירות כדי לעקוב אחר מה הם משמשים ומה ההרשאות שהם צריכים
אין להשתמש במפתחות חשבון השירות בקוד המקור או להשאיר אותם בספריית ההורדות.
הגדרת מכסות - מכסות ברירת המחדל מוגדרות עבור כל פרויקט שנוצר לאחרונה ב- Google Cloud Platform. זהו אמצעי אבטחה אחרון, כדי למנוע הוצאות בלתי צפויות. לדוגמה, אם יש לך סקריפט פגום יצירת משאבים באופן רקורסיבי, זה יהיה רק כדי ליצור אותם עד גבולות המכסה. הוא יכול גם להגן מפני חשבון שנפגע יוצר הרבה משאבים חדשים למטרות התוקף.
ניתן לשנות את המכסות בדף Quotas, אך הוא מחייב את הרשאת serviceusage.quotas.update, הכלולה רק בתפקידים שהוגדרו מראש: בעלים, עורך ומנהל מערכת של מכסה. לכן, אם חשבון שנפרץ או סקריפט פגום אינו בעל הרשאה זו, ההוצאות יכולות לגדול רק עד לגבולות המכסות.
למידע נוסף:
https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
https://cloud.google.com/iam/docs/using-iam-securely