מדיניות הארגון ב-Cloud SQL

בדף הזה מוסבר איך להשתמש במדיניות הארגון בפרויקט 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, הוא מגביל את האפשרות להוסיף רשתות מורשות לגישה למסדי נתונים שלא עוברת דרך שרת proxy, במופעים של Cloud SQL. המגבלה הזו לא חלה רטרואקטיבית. מכונות Cloud SQL עם רשתות מורשות קיימות עדיין פועלות גם אחרי שהמגבלה הזו נאכפת.
כברירת מחדל, אפשר להוסיף רשתות מורשות למופעים של Cloud SQL.

constraints/sql.restrictAuthorizedNetworks
מותר

הגבלות על מדיניות הארגון בנוגע לחיבורים

כשמגדירים את מדיניות הארגון לכל פרויקט, צריך לקבוע אם אחד מהמצבים הבאים רלוונטי לפרויקט:

התנגשויות בכתובות 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. לשם כך, צריך הרשאת כתיבה לספריית ההתקנה של ה-SDK של gcloud CLI במכונת הלקוח.

כתובות IP פרטיות שהן לא RFC 1918

חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. כך כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך השרת הפרוקסי. צריך להגדיר טווחי כתובות שהם לא RFC 1918 כרשתות מורשות.

כדי להשתמש בטווחים של כתובות IP פרטיות שאינן RFC 1918 ושלא הוגדרו ברשתות המורשות, אפשר לבצע אחת מהפעולות הבאות או את שתיהן:

  1. לא לאכוף את sql.restrictAuthorizedNetworks. אם הרשתות המורשות גם אוכפות sql.restrictPublicIp, לא תוכלו להגדיר אותן במסוף. במקום זאת, אפשר להשתמש ב-Cloud SQL API או ב-ה-CLI של gcloud.
  2. להשתמש בחיבורים דרך שרת 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 אוכפת את מדיניות הארגון במהלך הפעולות הבאות:

  • יצירה של מכונה
  • יצירת רפליקה
  • הפעלה מחדש של מכונה
  • העברת מכונה
  • שיבוט מכונה

כמו כל האילוצים של מדיניות הארגון, שינויים במדיניות לא חלים רטרואקטיבית על מופעים קיימים.

  • מדיניות חדשה לא משפיעה על מקרים קיימים.
  • הגדרת מופע קיימת נשארת תקפה, אלא אם משתמש משנה את הגדרת המופע ממצב תאימות למצב אי-תאימות באמצעות המסוף, ה-CLI של gcloud או RPC.
  • עדכון תחזוקה מתוזמן לא גורם לאכיפת מדיניות, כי התחזוקה לא משנה את ההגדרה של המופעים.

המאמרים הבאים