בדף הזה מוסבר איך להשתמש במדיניות ארגונית בפרויקט Cloud SQL. כדי להתחיל ליצור מדיניות ארגון, ראו הוספת מדיניות ארגון.
סקירה כללית
מדיניות ארגונית מאפשרת לאדמינים ארגוניים להגדיר הגבלות על האופן שבו משתמשים יכולים להגדיר מופעים בארגון. במדיניות הארגון נעשה שימוש בכללים שנקראים אילוצים, שהאדמין של הארגון מגדיר בפרויקט, בתיקייה או בארגון. ההגבלות אוכפות את המדיניות בכל המקרים. לדוגמה, אם מנסים ליצור מכונה בישות שיש לה מדיניות ארגונית, ההגבלה מריצה בדיקה כדי לוודא שהגדרת המכונה עומדת בדרישות של ההגבלה. אם הבדיקה נכשלת, Cloud SQL לא יוצר את המכונה.
כשמוסיפים פרויקטים לארגון או לתיקייה שמוגדרת בהם מדיניות ארגונית, הפרויקטים יורשים את האילוצים של המדיניות הזו.
מידע נוסף על מדיניות הארגון זמין במאמרים שירות מדיניות הארגון, מגבלות ו הערכת ההיררכיה.
אלה הם סוגי מדיניות הארגון שספציפיים ל-Cloud SQL:
כללי מדיניות מוגדרים מראש של הארגון
אתם יכולים להשתמש באילוצים המוגדרים מראש כדי לשלוט בהגדרות של כתובות IP ציבוריות ובהגדרות של מפתחות הצפנה בניהול הלקוח (CMEK) של מכונות Cloud SQL. כדי לקבל שליטה מפורטת יותר בהגדרות נתמכות אחרות, אפשר להשתמש באילוצים מותאמים אישית. מידע נוסף זמין במאמר בנושא מדיניות ארגונית בהתאמה אישית.
כללי מדיניות של הארגון בנושא חיבורים
מדיניות ארגונית בנושא חיבורים מספקת שליטה מרכזית בהגדרות של כתובות IP ציבוריות ב-Cloud SQL, כדי לצמצם את פני השטח של התקפות אבטחה על מכונות Cloud SQL מהאינטרנט. אדמין של מדיניות הארגון יכול להשתמש במדיניות חיבור כדי להגביל את הגדרות כתובות ה-IP הציבוריות של Cloud SQL ברמת הפרויקט, התיקייה או הארגון.
מגבלות שקשורות למדיניות הארגון לגבי חיבורים
במדיניות הארגון בנושא חיבורים יש שני סוגים של אילוצים מוגדרים מראש שמגבילים את הגישה למופעי Cloud SQL. יש גם מדיניות ארגונית בהתאמה אישית שאפשר להשתמש בה כדי לאכוף את המדיניות הארגונית בנושא חיבורים. מידע נוסף מופיע בדוגמאות של ipConfiguration באילוצים מותאמים אישית לדוגמה.
| מגבלה | תיאור | התנהגות ברירת מחדל |
|---|---|---|
| הגבלת הגישה לכתובות IP ציבוריות במכונות Cloud SQL | האילוץ הבוליאני הזה מגביל את ההגדרה של כתובת IP ציבורית במכונות Cloud SQL שבהן האילוץ הזה מוגדר ל-True. המגבלה הזו לא חלה רטרואקטיבית. מכונות Cloud SQL עם גישה קיימת לכתובת IP ציבורית ימשיכו לפעול גם אחרי שההגבלה הזו תיאכף.
כברירת מחדל, הגישה לכתובות IP ציבוריות למכונות Cloud SQL מותרת. constraints/sql.restrictPublicIp
|
מותר |
| הגבלת רשתות מורשות במכונות של Cloud SQL | כשהאילוץ הבוליאני הזה מוגדר ל-True, הוא מגביל את האפשרות להוסיף רשתות מורשות לגישה למסדי נתונים ללא פרוקסי למופעי Cloud SQL. המגבלה הזו לא חלה רטרואקטיבית.
מכונות Cloud SQL עם רשתות מורשות קיימות עדיין פועלות גם אחרי שהאילוץ הזה נאכף. כברירת מחדל, אפשר להוסיף רשתות מורשות למופעים של Cloud SQL. constraints/sql.restrictAuthorizedNetworks |
מותר |
הגבלות על מדיניות ארגונית בנושא חיבורים
כשמגדירים את מדיניות הארגון לכל פרויקט, צריך לקבוע אם אחת מהאפשרויות הבאות רלוונטית לפרויקט:
- בעיות שקשורות לכתובות IP ציבוריות של העתקי קריאה
- אי-תאימות לשימוש ב- ה-CLI של gcloud sql connect
- Google Cloud גישה לשירותים מתארחים
- כתובות IP פרטיות שלא תואמות ל-RFC 1918
קונפליקטים בכתובות IP ציבוריות של העתקי קריאה
רפליקות לקריאה ב-Cloud SQL מתחברות למכונה הראשית דרך חיבור מסד הנתונים שלא עובר דרך שרת proxy. משתמשים בהגדרה Authorized Networks במופע הראשי כדי להגדיר במפורש או במרומז את כתובות ה-IP הציבוריות של העותק לקריאה.
אם גם המופע הראשי וגם מופע ההעתק נמצאים באותו אזור ומופעלת בהם כתובת IP פרטית, לא תהיה התנגשות עם אילוצי המדיניות של ארגון החיבור.
חוסר תאימות בשימוש ב-gcloud sql connect
הפקודה gcloud sql connect משתמשת בכתובת IP ציבורית כדי להתחבר ישירות למכונות Cloud SQL. לכן, הוא לא תואם למגבלה sql.restrictPublicIp. בדרך כלל זו בעיה שמתרחשת במופעים שמשתמשים בכתובת IP פרטית.
בנוסף, הפקודה gcloud sql connect לא משתמשת בשרת ה-proxy, ולכן היא לא תואמת למגבלה sql.restrictAuthorizedNetworks.
במקום זאת, משתמשים בגרסת הבטא של הפקודה:
gcloud beta auth login
gcloud beta sql connect [INSTANCE_ID]
בגרסה הזו נעשה שימוש בשרת proxy ל-Cloud SQL Auth. מידע נוסף זמין במאמר בנושא gcloud beta sql connect.
בפעם הראשונה שמריצים את הפקודה הזו, מוצגת בקשה להתקין את הרכיב Cloud SQL Auth Proxy של ה-CLI של gcloud. לשם כך, צריכה להיות לכם הרשאת כתיבה בספריית ההתקנה של ה-CLI של gcloud SDK במכונת הלקוח.
כתובות IP פרטיות שהן לא RFC 1918
חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. כך כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך השרת הפרוקסי. צריך להגדיר טווחי כתובות שהם לא RFC 1918 כרשתות מורשות.
כדי להשתמש בטווחים של כתובות IP פרטיות שאינן RFC 1918 ושלא הוגדרו ברשתות המורשות, אפשר לבצע אחת או את שתי הפעולות הבאות:
- לא לאכוף את
sql.restrictAuthorizedNetworks. אם הרשתות המורשות גם אוכפותsql.restrictPublicIp, אי אפשר להגדיר אותן במסוף. במקום זאת, אפשר להשתמש ב-Cloud SQL API או ב-ה-CLI של gcloud. - להשתמש בחיבורים דרך שרת proxy למכונות עם כתובות IP פרטיות.
מדיניות ארגונית בנושא מפתחות הצפנה בניהול הלקוח (CMEK)
Cloud SQL תומך בשתי מגבלות של מדיניות הארגון שעוזרות להבטיח הגנה באמצעות CMEK בכל הארגון: constraints/gcp.restrictNonCmekServices ו-constraints/gcp.restrictCmekCryptoKeyProjects.
האילוץ constraints/gcp.restrictNonCmekServices מחייב הגנה באמצעות CMEK על sqladmin.googleapis.com. כשמוסיפים את האילוץ הזה ומוסיפים את sqladmin.googleapis.com לרשימת השירותים של מדיניות Deny, Cloud SQL מסרב ליצור מופעים חדשים אלא אם הם מופעלים עם CMEK.
האילוץ constraints/gcp.restrictCmekCryptoKeyProjects מגביל את השימוש במפתחות הצפנה של Cloud KMS להגנה באמצעות CMEK במופעים של Cloud SQL ל-SQL Server. באמצעות האילוץ הזה, כש-Cloud SQL יוצר מופע חדש עם CMEK, ה-CryptoKey חייב להגיע מפרויקט, מתיקייה או מארגון מורשים.
האילוצים האלה נאכפים רק במכונות חדשות של Cloud SQL ל-SQL Server.
למידע נוסף, ראו מדיניות הארגון לגבי CMEK. מידע על מגבלות שקשורות למדיניות הארגון לגבי CMEK זמין במאמר בנושא מגבלות שקשורות למדיניות הארגון.
כללי מדיניות ארגוניים בהתאמה אישית
כדי לקבל שליטה מפורטת ומותאמת אישית בהגדרות, אתם יכולים ליצור אילוצים מותאמים אישית ולהשתמש בהם במדיניות ארגונית מותאמת אישית. אתם יכולים להשתמש במדיניות ארגונית בהתאמה אישית כדי לשפר את האבטחה, התאימות והניהול.
איך מוסיפים מדיניות ארגונית בהתאמה אישית אפשר גם לראות רשימה של השדות הנתמכים להגבלות בהתאמה אישית.
כללי אכיפה של מדיניות הארגון
מערכת Cloud SQL אוכפת את מדיניות הארגון במהלך הפעולות הבאות:
- יצירה של מכונה
- יצירת רפליקה
- הפעלה מחדש של מכונה
- העברת מכונה
- שיבוט מכונה
כמו כל האילוצים של מדיניות הארגון, שינויים במדיניות לא חלים רטרואקטיבית על מופעים קיימים.
- מדיניות חדשה לא משפיעה על מקרים קיימים.
- הגדרת מופע קיימת נשארת תקפה, אלא אם משתמש משנה את הגדרת המופע ממצב תאימות למצב אי-תאימות באמצעות מסוף Google Cloud, ה-CLI של gcloud או RPC.
- עדכון מתוזמן של תחזוקה לא גורם לאכיפת מדיניות, כי התחזוקה לא משנה את ההגדרה של המופעים.