‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

לפני שמתחילים

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

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

התפקידים הנדרשים

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

אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin)
כדי ליצור, למחוק או לשנות מאגרי נתונים משולבים: Logs Configuration Writer (roles/logging.configWriter)

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

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

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

מגבלות

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

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

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

אפשר ליצור מדיניות ארגון במצב הרצה יבשה לאילוץ באמצעות מסוףGoogle Cloud או Google Cloud CLI. בדוגמאות הבאות מוסבר איך ליצור מדיניות ארגון במצב פרימטר לבדיקות, שמבצעת ביקורת על ההשפעה של האילוץ המנוהל compute.managed.restrictProtocolForwardingCreationForTypes.

המסוף

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

מעבר למדיניות הארגון
בכלי לבחירת פרויקטים, בוחרים את המשאב שרוצים להגדיר לו את מדיניות הארגון.
בוחרים באילוץ Restricts the use of protocol forwarding (הגבלת השימוש בהעברת פרוטוקולים) מהרשימה בדף Organization policies (מדיניות הארגון).
לוחצים על הכרטיסייה הרצה יבשה.
לוחצים על ניהול המדיניות של הרצת הבדיקה.
בדף עריכת מדיניות הרצת הבדיקה, בוחרים באפשרות במקום המדיניות של המשאב הראשי.
לוחצים על הוספת כלל.
בקטע אכיפה, בוחרים באפשרות מופעל.
בקטע פרמטרים, לוחצים על עריכה .
בחלונית עריכת ערכי פרמטרים, בוחרים באפשרות מוגדר על ידי המשתמש.
בתיבה ערכים בהגדרת המשתמש, מזינים EXTERNAL ולוחצים על שמירה.
לוחצים על בדיקת שינויים כדי לדמות את ההשפעה של מדיניות הארגון הזו. מידע נוסף זמין במאמר בנושא בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
כדי לאכוף את המדיניות של הארגון במצב הרצת בדיקה, לוחצים על הגדרת מדיניות להרצת בדיקה. אפשר גם להגדיר את המדיניות לשידור החי בלחיצה על הגדרת מדיניות.

כדי לבדוק את הסטטוס של מדיניות הארגון במצב הרצה יבשה, עוברים לכרטיסייה Dry run (הרצה יבשה) של מגבלה במדיניות הארגון.

אם בפרויקט מופעלת מדיניות ארגונית במצב פרימטר לבדיקות, אפשר לראות את יומני הביקורת של הפרויקט בלחיצה על הצגת יומני בדיקה. במקרה של מדיניות הארגון הזו, ביומני הביקורת מוצגות הפרות כאילו האילוץ Restricts the use of protocol forwarding נאכף כדי לאפשר רק פריסות של העברת פרוטוקולים מסוג EXTERNAL.

gcloud

כדי ליצור מדיניות ארגונית במצב הרצה יבשה, יוצרים קובץ YAML שמגדיר את האילוץ באמצעות dryRunSpec. לדוגמה:

  name: RESOURCE_TYPE/RESOURCE_ID/policies/compute.managed.restrictProtocolForwardingCreationForTypes
  dryRunSpec:
    rules:
    - enforce: true
      parameters:
       allowedSchemes:
        - EXTERNAL

מחליפים את מה שכתוב בשדות הבאים:

‫RESOURCE_TYPE עם organizations,‏ folders או projects.
‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.

מדיניות הארגון הזו לא תאכוף את האילוץ compute.managed.restrictProtocolForwardingCreationForTypes, אבל ביומני הביקורת יוצגו הפרות כאילו היא כן נאכפת.

אפשר להגדיר מדיניות ארגונית פעילה ומדיניות ארגונית להרצה יבשה באותו קובץ YAML, אם מגדירים גם את spec וגם את dryRunSpec. לדוגמה:

name: RESOURCE_TYPE/RESOURCE_ID/policies/compute.managed.restrictProtocolForwardingCreationForTypes
spec:
  rules:
  - values:
      allowedValues:
      - INTERNAL
      - EXTERNAL

dryRunSpec:
  rules:
  - values:
      allowedValues:
      - INTERNAL

כדי לאכוף מדיניות ארגון במצב הרצה יבשה, משתמשים בפקודה org-policies set policy. כדי לעדכן מדיניות ארגון קיימת במצב הרצה יבשה עם אילוצים חדשים, משתמשים בדגל --update-mask. לדוגמה:

gcloud org-policies set-policy POLICY_PATH \
  --update-mask=UPDATE_MASK

מחליפים את מה שכתוב בשדות הבאים:

‫POLICY_PATH עם הנתיב המלא לקובץ ה-YAML של מדיניות הארגון.
‫UPDATE_MASK עם spec כדי לעדכן רק את המדיניות הפעילה, או dryRunSpec כדי לעדכן רק את מדיניות הארגון במצב הרצה יבשה. אפשר גם להשתמש ב-* כדי לעדכן את השדות spec ו-dryRunSpec. אם השדה הזה לא מוגדר כשמעדכנים מדיניות קיימת של הארגון, הפקודה הזו תגרום לשגיאה ומדיניות הארגון לא תעודכן.

כדי לוודא שמדיניות הארגון מוגדרת במצב הרצת בדיקה, משתמשים בפקודה org-policies describe. השדה dryRunSpec מופיע רק אם הוא קיים במדיניות הארגון.

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

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

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

המסוף

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

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

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

gcloud

כדי ליצור מדיניות ארגונית במצב הרצה יבשה, יוצרים קובץ YAML שמגדיר את האילוץ באמצעות dryRunSpec. לדוגמה:

  name: RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME
  dryRunSpec:
    rules:
    - enforce: true

מחליפים את מה שכתוב בשדות הבאים:

‫RESOURCE_TYPE עם organizations,‏ folders או projects.
‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.
CONSTRAINT_NAME בשם של האילוץ המותאם אישית. לדוגמה, custom.disableGkeAutoUpgrade.

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

אפשר להגדיר מדיניות ארגונית פעילה ומדיניות ארגונית במצב הרצה יבשה באותו קובץ YAML, אם מגדירים גם את spec וגם את dryRunSpec. לדוגמה:

name: RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME
spec:
  rules:
  - enforce: false

dryRunSpec:
  rules:
  - enforce: true

gcloud org-policies set-policy POLICY_PATH \
  --update-mask=UPDATE_MASK

מחליפים את מה שכתוב בשדות הבאים:

‫POLICY_PATH עם הנתיב המלא לקובץ ה-YAML של מדיניות הארגון.
‫UPDATE_MASK עם spec כדי לעדכן רק את המדיניות הפעילה, או dryRunSpec כדי לעדכן רק את מדיניות הארגון במצב הרצה יבשה. אפשר גם להשתמש ב-* כדי לעדכן את השדות spec ו-dryRunSpec. אם השדה הזה לא מוגדר כשמעדכנים מדיניות קיימת של הארגון, הפקודה הזו תגרום לשגיאה ומדיניות הארגון לא תעודכן.

כדי לוודא שמדיניות ארגונית מוגדרת במצב הרצה יבשה, משתמשים בפקודה org-policies describe. השדה dryRunSpec מופיע רק אם הוא קיים במדיניות הארגון.

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

יצירת מדיניות ארגונית במצב פרימטר לבדיקות ממדיניות פעילה

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

אפשר ליצור מדיניות ארגון במצב הרצה יבשה על סמך מדיניות קיימת באמצעות מסוף Google Cloud או Google Cloud CLI.

המסוף

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

מעבר למדיניות הארגון
בכלי לבחירת פרויקטים, בוחרים משאב שכבר מוגדרת בו האילוץ Restrict Resource Service Usage.
ברשימה שבדף מדיניות הארגון, בוחרים באילוץ הגבלת השימוש בשירות משאבים.
לוחצים על הכרטיסייה שידור חי.
לוחצים על ניהול המדיניות.
לוחצים על הוספת כלל.
בקטע ערכי מדיניות, בוחרים באפשרות בהתאמה אישית.
בקטע סוג המדיניות, בוחרים באפשרות דחייה.
בתיבה ערכים מותאמים אישית, מזינים appengine.googleapis.com.
לוחצים על סיום ואז על הגדרת מדיניות הרצה יבשה.

gcloud

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

gcloud org-policies describe gcp.restrictServiceUsage \
  --project=PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט או במספר הפרויקט שבו מוגדרת מדיניות הארגון.

הפלט אמור להיראות כך:

  name: projects/123456789012/policies/gcp.restrictServiceUsage
  spec:
    etag: CJy93KEGEKCJw/QB
    rules:
    - values:
        allowedValues:
        - compute.googleapis.com
  updateTime: '2023-04-12T21:11:56.512804Z'

מעתיקים את הפלט של הפקודה הזו לקובץ זמני. עליך לערוך את הקובץ הזה כדי להסיר את השדות etag ו-updateTime, ולשנות את השדה spec ל-dryRunSpec. מבצעים את השינויים שרוצים לבדוק בהגדרת האילוץ במדיניות הארגון במצב הרצת בדיקה.

קובץ ה-YAML שמתקבל צריך להיראות בערך כך:

  name: projects/123456789012/policies/gcp.restrictServiceUsage
  dryRunSpec:
    rules:
    - values:
        allowedValues:
        - compute.googleapis.com
        - appengine.googleapis.com

כדי לאכוף את מדיניות הארגון במצב הרצה יבשה, משתמשים באפשרות org-policies set policy עם הדגל --update-mask. לדוגמה:

gcloud org-policies set-policy POLICY_PATH \
  --update-mask=dryRunSpec

מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון הזמנית.

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

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

המסוף

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

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

gcloud

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

  name: RESOURCE_TYPE/RESOURCE_ID/policies/gcp.restrictServiceUsage
  spec:
    rules:
    - values:
        allowedValues:
        - container.googleapis.com

מחליפים את מה שכתוב בשדות הבאים:

‫RESOURCE_TYPE עם organizations, ‏ folders או projects.
‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.

לאחר מכן, משתמשים בפקודה org-policies set policy עם הדגל --update-mask שמוגדר לערך dryRunSpec. לדוגמה:

gcloud org-policies set-policy POLICY_PATH \
  --update-mask=dryRunSpec

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

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

gcloud org-policies delete CONSTRAINT_NAME \
  --RESOURCE_TYPE=RESOURCE_ID

מחליפים את מה שכתוב בשדות הבאים:

‫CONSTRAINT_NAME בשם של האילוץ שרוצים למחוק. לדוגמה, gcp.restrictServiceUsage.
‫RESOURCE_TYPE עם organizations, ‏ folders או projects.
‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.

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

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

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

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

לדוגמה, נניח שיש משאב ארגון, Organization A, עם מדיניות ארגון פעילה שמוגדרת ל-enforced: false, ומדיניות ארגון במצב הרצה יבשה שמוגדרת ל-enforced: true. במשאב צאצא, Folder B, מוגדרת גם מדיניות הארגון הפעילה ל-enforced: false, והוא יורש את מדיניות הארגון במצב בדיקה. ב-Folder B, המדיניות הפעילה שהוגדרה פירושה שהערכת המדיניות בפועל של מדיניות הארגון במצב הרצת בדיקה היא גם enforce: false, וכך היא מבטלת את מדיניות הארגון במצב הרצת בדיקה שהוגדרה בארגון האב.

משאב צאצא של Folder B, Project X, מגדיר את מדיניות השידור החי ל-enforced: true. בדומה להתנהגות ב-Folder B, ההערכה האפקטיבית של מדיניות הארגון במצב הרצת בדיקה ב-Project X היא enforced: true, כי המדיניות הפעילה מוגדרת.

משאב צאצא נוסף של Folder B, Project Y, מגדיר את מדיניות הארגון במצב הרצת בדיקה ל-enforced: true. היא יורשת את מדיניות הארגון ממשאב האב שלה, ולכן ההערכה בפועל היא enforced: false לגבי המדיניות הפעילה, ו-enforced: true לגבי מדיניות הארגון במצב הרצת בדיקה.

משאב	הגדרת מדיניות הארגון לשידורים חיים	המדיניות התקפה לגבי הארגון	הגדרת מדיניות הארגון במצב הרצת בדיקה	מדיניות הארגון בפועל במצב הרצת בדיקה
ארגון א'	`enforced: false`	`enforced: false`	`enforced: true`	`enforced: true`
תיקייה ב'	`enforced: false`	`enforced: false`	ללא	`enforced: false`
תיקייה ג'	ללא	`enforced: false`	ללא	`enforced: true`
Project X	`enforced: true`	`enforced: true`	ללא	`enforced: true`
פרויקט Y	ללא	`enforced: false`	`enforced: true`	`enforced: true`

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

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

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

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

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

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {
      "code": 7,
      "message": "PERMISSION_DENIED"
    },
    "authenticationInfo": {},
    "requestMetadata": {
      "callerIp": "1.2.3.4",
      "requestAttributes": {},
      "destinationAttributes": {}
    },
    "serviceName": "appengine.googleapis.com",
    "methodName": "google.api.appengine.v1.appengine.apps.services.get",
    "resourceName": "projects/sur-project-test-3",
    "metadata": {
      "constraint": "constraints/gcp.restrictServiceUsage",
      "checkedValue": "appengine.googleapis.com",
      "liveResult": "ALLOWED",
      "@type": "type.googleapis.com/google.cloud.audit.OrgPolicyDryRunAuditMetadata",
      "dryRunResult": "DENIED"
    }
  },
  "insertId": "1f2bvoxcmg1",
  "resource": {
    "type": "audited_resource",
    "labels": {
      "project_id": "sur-project-test-3",
      "service": "appengine.googleapis.com",
      "method": "google.api.appengine.v1.appengine.apps.services.get"
    }
  },
  "timestamp": "2022-06-16T19:42:58.244990928Z",
  "severity": "WARNING",
  "logName": "projects/sur-project-test-3/logs/cloudaudit.googleapis.com%2Fpolicy",
  "receiveTimestamp": "2022-06-16T19:42:59.572025716Z"
}

אפשר להשתמש ב-Logs Explorer כדי לשלוח שאילתות רק לגבי הפרות של מדיניות הארגון במצב הרצה יבשה.

המסוף

ב Google Cloud מסוף, תוכלו להשתמש ב-Logs Explorer כדי לאחזר את הרשומות ביומן הביקורת של Google Cloud הפרויקט, התיקייה או הארגון:

במסוף Google Cloud , נכנסים לדף Logging> Logs Explorer.

כניסה לדף Logs Explorer
בוחרים פרויקט, תיקייה או ארגון קיימים ב- Google Cloud .
בחלונית Query builder:
- בקטע Resource Type, בוחרים את המשאב שרוצים לראות את יומני הביקורת שלו. Google Cloud
- בקטע Log name, בוחרים את סוג יומן הביקורת policy.
- בחלונית Query, מזינים את הטקסט הבא: protoPayload.metadata.dryRunResult = "DENIED" AND \ protoPayload.metadata.liveResult = "ALLOWED"
לא הצלחתם לצפות ביומנים ב-Logs Explorer? פתרון בעיות

מידע נוסף על שליחת שאילתות באמצעות Logs Explorer מופיע במאמר יצירת שאילתות ב-Logs Explorer.

gcloud

הכלי Google Cloud CLI מספק גישה ל-Logging API באמצעות ממשק שורת הפקודה (CLI). חשוב לציין מזהה משאב תקין בכל אחד משמות היומנים. לדוגמה, אם שאילתה כוללת מזהה פרויקט, מזהה הפרויקט שאתם מציינים חייב להתייחס לשם הפרויקט שבחרתם.

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

gcloud logging read protoPayload.metadata.dryRunResult = "DENIED" AND \
      protoPayload.metadata.liveResult = "ALLOWED" \
    --RESOURCE_TYPE=RESOURCE_ID \

מחליפים את מה שכתוב בשדות הבאים:

‫RESOURCE_TYPE עם organization, ‏ folder או project.
‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.

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

למידע נוסף על השימוש ב-CLI של gcloud:‏ gcloud logging read.

רשומות מצטברות ביומן הביקורת

אם יש לכם פרויקטים רבים בארגון, אתם יכולים להשתמש באובייקטים נצברים מסוג sink כדי לצבור ולנתב את הרשומות ביומן הביקורת מכל הפרויקטים בארגון לטבלה ב-BigQuery.

כדי ליצור מאגר נתונים מצטבר, משתמשים בפקודה logging sinks create.

לפני שמשתמשים בפקודה הבאה, מחליפים את הערכים הבאים:
- ‫SINK_NAME: השם של ה-sink ביומן. אי אפשר לשנות את השם של יעד אחרי שיוצרים אותו.
- ‫PROJECT_ID: המזהה של הפרויקט שמכיל את מערך הנתונים שלכם ב-BigQuery.
- ‫DATASET_ID: המזהה של מערך נתונים ב-BigQuery עם הרשאת כתיבה.
- ‫ORGANIZATION_ID: מזהה הארגון.
מריצים את הפקודה gcloud logging sinks create:
```
gcloud logging sinks create SINK_NAME \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID \
  --include-children \
  --organization=ORGANIZATION_ID \
  --log-filter='logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy" AND protoPayload.metadata.@type:OrgPolicyDryRunAuditMetadata'
```
כדי לנתב רשומות ביומן, צריך להעניק לחשבון השירות שמשויך ליעד הרשאה לנתב אליו.

כדי למצוא את חשבון השירות שצריך להעניק לו הרשאה, משתמשים בפקודה gcloud logging sinks describe.

לפני שמשתמשים בפקודה הבאה, מחליפים את SINK_NAME בשם של sink ביומן שיצרתם קודם.

מריצים את הפקודה gcloud logging sinks describe:
```
gcloud logging sinks describe SINK_NAME
```
אם פרטי יעד ההעברה מכילים שדה עם התווית writerIdentity, ממשיכים לשלב הבא. אם הפרטים לא כוללים שדה writerIdentity, אין צורך להגדיר הרשאות יעד ל-Sink.
מעתיקים את זהות הכתיבה של יעד הנתונים ללוח. בדוגמה הבאה מוצגת זהות של יוצר:
```
serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com
```
משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להעניק לזהות בעל הרשאת הכתיבה של ה-sink הרשאה לכתוב נתוני יומן ליעד.

לפני שמשתמשים בפקודה הבאה, מחליפים את הערכים הבאים:
- ‫PROJECT_ID: המזהה של הפרויקט שבו מאוחסן היעד של מאגר הנתונים המצטבר.
- ‫PRINCIPAL_ID: זהות בעל הרשאת הכתיבה של יעד הנתונים שהעתקתם קודם.
מריצים את הפקודה gcloud projects add-iam-policy-binding:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=PRINCIPAL_ID \
  --role=roles/bigquery.dataEditor
```
מידע נוסף על יצירת אובייקטים מסוג sink מצטבר מופיע במאמר איסוף וניתוב של יומנים ברמת הארגון ליעדים נתמכים.
כדי לראות את היומנים שמועברים ל-BigQuery:
1. במסוף Google Cloud , עוברים לדף BigQuery:
  עוברים אל BigQuery Studio
  
  אפשר גם להשתמש בסרגל החיפוש כדי למצוא את הדף הזה.
2. בחלונית Explorer מרחיבים את הפרויקט ובוחרים מערך נתונים.
  
  רשומות היומן מוצגות בכרטיסייה פרטים, או שאפשר להריץ שאילתה על הטבלה כדי לקבל את הנתונים.
3. יוצרים שאילתה כדי לנתח את מדיניות הארגון להרצת בדיקה. לדוגמה, השאילתה הבאה מחזירה יומני ביקורת של מדיניות הארגון בהרצה יבשה, שכוללים דחיות ונוצרו ב-7 הימים האחרונים.
```
SELECT protopayload_auditlog.serviceName as serviceName,
    protopayload_auditlog.methodName as methodName,
    JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, '$.constraint') as constraint,
    JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, '$.dryRunResult') as dryRunResult,
    JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, '$.liveResult') as liveResult
FROM {PROJECT_ID}.{DATASET_ID}.cloudaudit_googleapis_com_policy_*
WHERE JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, '$.dryRunResult') = "DENIED"
AND `timestamp` > DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
LIMIT 1000
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט שמכיל את מערך הנתונים שלכם ב-BigQuery.
- ‫DATASET_ID: המזהה של מערך נתונים ב-BigQuery עם הרשאת כתיבה.
מידע נוסף זמין במאמר בנושא צפייה ביומנים שמועברים ל-BigQuery.

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

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

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

לפני שמתחילים

התפקידים הנדרשים

מגבלות

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

המסוף

gcloud

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

המסוף

gcloud

יצירת מדיניות ארגונית במצב פרימטר לבדיקות ממדיניות פעילה

המסוף

gcloud

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

המסוף

gcloud

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

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

המסוף

gcloud

רשומות מצטברות ביומן הביקורת

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

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