מומלץ להגדיר מגבלות מדיניות שמחייבות הגדרות מקובלות של משאבים ומונעות הגדרות מסוכנות. התוכנית משתמשת בשילוב של אילוצים על מדיניות הארגון ואימות של תשתית כקוד (IaC) בצינור. האמצעים האלה מונעים יצירה של משאבים שלא עומדים בהנחיות המדיניות. החלת אמצעי הבקרה האלה בשלב מוקדם של התכנון והבנייה של עומסי העבודה עוזרת לכם להימנע מעבודת תיקון בהמשך.
מגבלות שקשורות למדיניות הארגון
שירות Organization Policy אוכף מגבלות כדי להבטיח שלא ניתן ליצור בארגון Google Cloud הגדרות מסוימות של משאבים, גם לא על ידי מישהו עם תפקיד IAM עם הרשאות מספיקות.
התוכנית מפעילה מדיניות בצומת הארגון, כך שכל התיקיות והפרויקטים בארגון יקבלו את אמצעי הבקרה האלה בירושה. חבילת המדיניות הזו נועדה למנוע הגדרות מסוימות שעלולות לסכן את הארגון, כמו חשיפת מכונה וירטואלית לאינטרנט הציבורי או מתן גישה ציבורית לקטגוריות אחסון, אלא אם אתם מאשרים בכוונה חריגה ממדיניות.
בטבלה הבאה מוצגים אילוצי מדיניות הארגון שמיושמים בתוכנית ה-Blueprint:
| אילוץ של מדיניות הארגון | תיאור |
|---|---|
| וירטואליזציה מקוננת במכונות וירטואליות ב-Compute Engine יכולה לעקוף את המעקב ואת כלי האבטחה האחרים של המכונות הווירטואליות אם היא מוגדרת בצורה לא נכונה. המגבלה הזו מונעת יצירה של וירטואליזציה מקוננת. |
| תפקידי IAM כמו |
| רשתות משנה חיצוניות של IPv6 יכולות להיות חשופות לגישה לא מורשית באינטרנט אם הן לא מוגדרות בצורה טובה. האילוץ הזה מונע יצירה של רשתות משנה חיצוניות של IPv6. |
| התנהגות ברירת המחדל של הגדרת מפתחות SSH במטא-נתונים עלולה לאפשר גישה מרחוק לא מורשית למכונות וירטואליות אם המפתחות נחשפים. האילוץ הזה אוכף את השימוש ב-OS Login במקום במפתחות SSH שמבוססים על מטא-נתונים. |
|
העברת פרוטוקול של VM לכתובות IP חיצוניות עלולה להוביל לתעבורת נתונים יוצאת (egress) לא מורשית לאינטרנט אם ההעברה לא מוגדרת בצורה טובה. ההגבלה הזו מאפשרת העברת פרוטוקול של מכונות וירטואליות רק לכתובות פנימיות. |
|
מחיקה של פרויקט מארח של VPC משותף עלולה לשבש את הפעילות של כל הפרויקטים של השירותים שמשתמשים במשאבי רשת. האילוץ הזה מונע מחיקה בטעות או בזדון של פרויקטים מארחים ב-VPC משותף, כי הוא מונע את ההסרה של המנעול למניעת מחיקה של פרויקט בפרויקטים האלה. |
|
לא מומלץ להשתמש בהגדרה מדור קודם של DNS פנימי גלובלי (בכל הפרויקט) כי היא מפחיתה את זמינות השירות. המגבלה הזו מונעת את השימוש בהגדרה מדור קודם. |
| רשת VPC שמוגדרת כברירת מחדל וכללי חומת אש של VPC שמוגדרים כברירת מחדל עם הרשאות רחבות מדי נוצרים בכל פרויקט חדש שבו מופעל Compute Engine API. האילוץ הזה מדלג על יצירת רשת ברירת המחדל וכללי חומת האש של ברירת המחדל של VPC. |
| כברירת מחדל, מכונה וירטואלית נוצרת עם כתובת IPv4 חיצונית שיכולה להוביל לגישה לא מורשית לאינטרנט. האילוץ הזה מגדיר רשימת היתרים ריקה של כתובות IP חיצוניות שהמכונה הווירטואלית יכולה להשתמש בהן, ודוחה את כל הכתובות האחרות. |
|
כברירת מחדל, אפשר להגדיר את אנשי הקשר החיוניים כך שיישלחו התראות לגבי הדומיין לכל דומיין אחר. האילוץ הזה קובע שרק כתובות אימייל בדומיינים מאושרים יכולות להיות מוגדרות כנמענים של Essential Contacts. |
| כברירת מחדל, אפשר להעניק הרשאות גישה לכל חשבון Google, כולל חשבונות לא מנוהלים וחשבונות ששייכים לארגונים חיצוניים. ההגבלה הזו מבטיחה שניתן יהיה להעניק הרשאות רק לחשבונות מנוהלים מהדומיין שלכם. אפשר גם להוסיף דומיינים לרשימת ההיתרים. |
|
כברירת מחדל, חשבונות שירות שמוגדרים כברירת מחדל מקבלים באופן אוטומטי תפקידים עם הרשאות רבות מדי. האילוץ הזה מונע את ההקצאות האוטומטיות של תפקידי IAM לחשבונות שירות שמוגדרים כברירת מחדל. |
|
מפתחות של חשבונות שירות הם פרטי כניסה קבועים שמהווים סיכון גבוה, וברוב המקרים אפשר להשתמש בחלופה מאובטחת יותר למפתחות של חשבונות שירות. האילוץ הזה מונע את יצירת המפתחות של חשבונות השירות. |
|
העלאה של חומר מפתח של חשבון שירות עלולה להגדיל את הסיכון אם חומר המפתח נחשף. האילוץ הזה מונע העלאה של מפתחות של חשבונות שירות. |
|
מכונות Cloud SQL יכולות להיות חשופות לגישה לא מאומתת באינטרנט אם הן מוגדרות לשימוש ברשתות מורשות ללא שרת proxy ל-Cloud SQL Auth. המדיניות הזו מונעת את ההגדרה של רשתות מורשות לגישה למסד נתונים, ו מחייבת שימוש בשרת proxy ל-Cloud SQL Auth במקום זאת. |
| מכונות Cloud SQL יכולות להיות חשופות לגישה לאינטרנט ללא אימות אם הן נוצרות עם כתובות IP ציבוריות. האילוץ הזה מונע שימוש בכתובות IP ציבוריות במכונות Cloud SQL. |
| כברירת מחדל, אפשר לגשת לאובייקטים ב-Cloud Storage באמצעות רשימות של בקרת גישה (ACL) מדור קודם, במקום באמצעות IAM. מצב כזה עלול להוביל לבקרת גישה לא עקבית ולחשיפה לא מכוונת אם ההגדרות לא נכונות. הגישה לרשימת ACL מדור קודם לא מושפעת מההגבלה |
|
אם קטגוריות של Cloud Storage מוגדרות בצורה לא נכונה, הן יכולות להיות חשופות לגישה לאינטרנט ללא אימות. האילוץ הזה מונע שימוש ברשימות ACL ובהרשאות IAM שמעניקות גישה ל- |
המדיניות הזו היא נקודת התחלה שאנחנו ממליצים עליה לרוב הלקוחות ולרוב התרחישים, אבל יכול להיות שתצטרכו לשנות את ההגבלות של מדיניות הארגון כדי להתאים אותה לסוגים מסוימים של עומסי עבודה. לדוגמה, עומס עבודה שמשתמש בקטגוריה של Cloud Storage כבק-אנד ל-Cloud CDN כדי לארח משאבים ציבוריים נחסם על ידי storage.publicAccessPrevention, או שאפליקציית Cloud Run שפונה לציבור ולא דורשת אימות נחסמת על ידי iam.allowedPolicyMemberDomains. במקרים כאלה, צריך לשנות את מדיניות הארגון ברמת התיקייה או הפרויקט כדי לאפשר חריגה מצומצמת.
אפשר גם להוסיף מגבלות למדיניות הארגון על סמך תנאים. לשם כך, מגדירים תג שמעניק חריגה או אכיפה למדיניות, ואז מחילים את התג על פרויקטים ותיקיות.
מידע על אילוצים נוספים מופיע במאמרים אילוצים זמינים ואילוצים בהתאמה אישית.
אימות לפני פריסה של תשתית כקוד
התוכנית משתמשת בגישת GitOps לניהול התשתית, כלומר כל השינויים בתשתית מיושמים באמצעות תשתית כקוד (IaC) עם בקרת גרסאות, ואפשר לאמת אותם לפני הפריסה.
כללי המדיניות שנאכפים בתוכנית ה-Blueprint מגדירים תצורות משאבים קבילות שאפשר לפרוס באמצעות צינור עיבוד הנתונים. אם קוד שנשלח למאגר GitHub לא עובר את בדיקות המדיניות, לא מתבצע פריסה של משאבים.
מידע על השימוש בצינורות עיבוד נתונים ועל האופן שבו אמצעי הבקרה נאכפים באמצעות אוטומציה של CI/CD זמין במאמר מתודולוגיית פריסה.
המאמרים הבאים
- מידע על מתודולוגיית פריסה (המסמך הבא בסדרה)