סקירה כללית של מדיניות הארגון

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

יתרונות

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

תרחישים נפוצים לדוגמה

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

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

ההבדלים מניהול זהויות והרשאות גישה (IAM)

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

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

איך פועלת מדיניות הארגון

מדיניות הארגון מגדירה מגבלה אחת שמגבילה שירות אחד או יותר Google Cloud . מדיניות הארגון מוגדרת במשאב של ארגון, תיקייה או פרויקט כדי לאכוף את האילוץ על המשאב הזה ועל כל משאבי הצאצא.

מדיניות ארגון מכילה כלל אחד או יותר שמציינים איך לאכוף את האילוץ, או אם לאכוף אותו בכלל. לדוגמה, מדיניות ארגון יכולה להכיל כלל אחד שמחיל את ההגבלה רק על משאבים שתויגו בתג environment=development, וכלל אחר שמונע את החלת ההגבלה על משאבים אחרים.

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

מושגים שקשורים למדיניות הארגון

מגבלות

אילוץ הוא סוג מסוים של הגבלה על שירותGoogle Cloud או על רשימה של שירותים. Google Cloud אפשר לחשוב על האילוץ כעל תוכנית שמגדירה אילו התנהגויות נשלטות. לדוגמה, אפשר להגביל את הגישה של משאבי פרויקט למשאבי אחסון של Compute Engine באמצעות האילוץ compute.storageResourceUseRestrictions.

לאחר מכן, התוכנית מוגדרת במשאב בהיררכיית המשאבים כמדיניות ארגון, שמחיל את הכללים שמוגדרים באילוץ. השירות Google Cloud שממופה לאילוץ הזה ומשויך למשאב הזה אוכף את ההגבלות שהוגדרו במדיניות הארגון.

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

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

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

אילוצים מנוהלים

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

אם למגבלה המקבילה מדור קודם יש סוג מגבלה בוליאני, אפשר לאכוף את המגבלה המנוהלת או לא לאכוף אותה באותו אופן. לדוגמה, מדיניות הארגון הבאה אוכפת את iam.managed.disableServiceAccountCreation, שהוא האילוץ המקביל ל-iam.disableServiceAccountCreation:

name: organizations/1234567890123/policies/iam.managed.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

אם לאילוץ המנוהל המקביל מדור קודם יש סוג אילוץ של רשימה, האילוץ המנוהל תומך בהגדרת פרמטרים שמגדירים את המשאבים וההתנהגויות שמוגבלים על ידי האילוץ. לדוגמה, מדיניות הארגון הבאה אוכפת אילוץ מנוהל שמאפשר להוסיף רק את הדומיינים example.com ו-altostrat.com לאנשי קשר חיוניים עבור organizations/1234567890123:

name: organizations/1234567890123/policies/essentialcontacts.managed.allowedContactDomains
spec:
   rules:
     - enforce: true
       parameters:
          allowedDomains:
               - @example.com
               - @altostrat.com

מידע נוסף על שימוש באילוצים מנוהלים זמין במאמר בנושא יצירת מדיניות ארגון.

תנאים מותאמים אישית

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

רשימה של משאבי שירות שתומכים באילוצים בהתאמה אישית זמינה במאמר שירותים שתומכים באילוצים בהתאמה אישית.

מידע נוסף על שימוש במדיניות ארגונית מותאמת אישית זמין במאמר יצירת הגבלות מותאמות אישית.

רשימה של אילוצים מותאמים אישית לדוגמה זמינה בספריית כללי המדיניות המותאמים אישית של הארגון ב-GitHub.

אילוצים מנוהלים (גרסה קודמת)

לאילוצים מנוהלים מדור קודם יש סוג אילוץ של רשימה או בוליאני, שקובע את הערכים שאפשר להשתמש בהם לבדיקת האכיפה. השירותGoogle Cloud האוכף יעריך את סוג המגבלה ואת הערך שלה כדי לקבוע את ההגבלה שנאכפת.

האילוצים הקודמים האלה נקראו בעבר אילוצים מוגדרים מראש.

כללים לרשימה

אילוצים מנוהלים מדור קודם עם כללי רשימה מאפשרים או אוסרים שימוש ברשימת ערכים שמוגדרים במדיניות הארגון. האילוצים הקודמים האלה נקראו אילוצי רשימה. רשימת הערכים המותרים או האסורים מופיעה כמחרוזת של עץ משנה היררכי. מחרוזת העץ המשני מציינת את סוג המשאב שהיא חלה עליו. לדוגמה, האילוץ המנוהל מדור קודם constraints/compute.trustedImageProjects מקבל רשימה של מזהי פרויקטים בצורה projects/PROJECT_ID.

אפשר לציין שכל הערכים מותרים, שכל הערכים אסורים או שרשימה ספציפית של ערכים מותרת או אסורה. כשמציינים רשימה של ערכים מותרים או אסורים, Organization Policy מעריך באופן מרומז שרק הערכים האלה מותרים או אסורים. לדוגמה, אם יש לכם אילוץ שמאפשר רק projects/PROJECT_ID, אז כל הערכים האחרים נדחים באופן מרומז.

אפשר להוסיף תחילית לערכים בפורמט prefix:value לאילוצים שתומכים בהם, כדי להוסיף משמעות לערך:

  • ‫is: – החלת השוואה לערך המדויק. ההתנהגות זהה למצב שבו לא מציינים קידומת, והיא נדרשת כשהערך כולל נקודתיים.

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

  • ‫in: – משווה את כל המשאבים שכוללים את הערך הזה. לדוגמה, אפשר להוסיף את in:us-locations לרשימת המיקומים שנדחו במגבלת constraints/gcp.resourceLocations כדי לחסום את כל המיקומים שנכללים באזור us.

אם לא מספקים רשימת ערכים, או אם מדיניות הארגון מוגדרת כברירת המחדל שמנוהלת על ידי Google, ברירת המחדל של האילוץ נכנסת לתוקף, כלומר כל הערכים מותרים או כל הערכים אסורים.

מדיניות הארגון הבאה אוכפת מגבלה מנוהלת מדור קודם שמאפשרת למכונות וירטואליות ב-Compute Engine‏ vm-1 ו-vm-2 ב-organizations/1234567890123 לגשת לכתובות IP חיצוניות:

name: organizations/1234567890123/policies/compute.vmExternalIpAccess
spec:
  rules:
  - values:
      allowedValues:
      - is:projects/project_a/zones/us-central1-a/instances/vm-1
      - is:projects/project_b/zones/us-central1-a/instances/vm-2

כללים בוליאניים

אילוץ מנוהל מדור קודם עם כלל בוליאני נאכף או לא נאכף. לדוגמה, ל-constraints/compute.disableSerialPortAccess יש שני מצבים אפשריים:

  • נאכף – האילוץ נאכף, ולא מותרת גישה ליציאות טוריות.
  • לא נאכף – האילוץ disableSerialPortAccess לא נאכף או נבדק, ולכן הגישה ליציאה טורית מותרת.

אם מדיניות הארגון מוגדרת כברירת המחדל שמנוהלת על ידי Google, ההתנהגות שמוגדרת כברירת מחדל לאילוץ תיכנס לתוקף.

האילוצים הקודמים האלה נקראו בעבר אילוצים בוליאניים.

מדיניות הארגון הבאה אוכפת מגבלה מנוהלת מדור קודם שמשביתה את היצירה של חשבונות שירות חיצוניים ב-organizations/1234567890123:

name: organizations/1234567890123/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

מדיניות הארגון במצב בדיקה

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

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

מדיניות ארגון מותנית

תגים מאפשרים להגדיר תנאי לאכיפת הגבלות בהתאם לתג ספציפי שמצורף או לא מצורף למשאב. אתם יכולים להשתמש בתגים ובאכיפה מותנית של הגבלות כדי לספק בקרה מרכזית על המשאבים בהיררכיה.

מידע נוסף על תגים זמין במאמר סקירה כללית על תגים. כדי לדעת איך להגדיר מדיניות ארגונית מותנית באמצעות תגים, אפשר לעיין במאמר הגדרת מדיניות ארגונית באמצעות תגים.

ירושה

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

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

מידע נוסף זמין במאמר בנושא הערכת היררכיה.

הפרות

הפרה מתרחשת כש Google Cloud שירות פועל או נמצא במצב שנוגד את הגדרת ההגבלות של מדיניות הארגון במסגרת היררכיית המשאבים שלו. Google Cloud שירותים יאכפו אילוצים כדי למנוע הפרות, אבל בדרך כלל מדיניות ארגונית חדשה לא חלה באופן רטרואקטיבי. אם אילוץ של מדיניות הארגון נאכף באופן רטרואקטיבי, הוא יסומן ככזה בדף מגבלות שקשורות למדיניות הארגון.

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

כלים לבקרת מדיניות

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

חלק מהכלים לבקרת מדיניות מיועדים ספציפית לבדיקה ולניתוח של כללי מדיניות של Organization Policy. מומלץ לבדוק את כל השינויים במדיניות הארגון ולבצע הרצה יבשה. בעזרת כלים לבקרת מדיניות תוכלו לבצע משימות כמו הבאות:

מידע נוסף על הכלים האלה ועל כלים אחרים של Policy Intelligence

השלבים הבאים