אילוצים של מדיניות הארגון לגבי Cloud Storage

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

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

אילוצים של Cloud Storage

אפשר להחיל את האילוצים הבאים על מדיניות הארגון והם מתייחסים ל-Cloud Storage:

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

שם האילוץ: constraints/storage.publicAccessPrevention סוג האילוץ: boolean

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

משך השמירה של מחיקה זמנית

שם האילוץ: constraints/storage.softDeletePolicySeconds סוג האילוץ: list

כשמחילים את האילוץ softDeletePolicySeconds, צריך לציין משך זמן אחד או יותר של מחיקה רכה (softDeletePolicy.retentionDuration) כחלק מהאילוץ. האילוץ מאמת שכל בקשה ליצור קטגוריה חדשה או לעדכן את משך הזמן לשמירה של מחיקה זמנית בקטגוריה קיימת, חייבת לכלול באופן מפורש את אחד ממשכי הזמן המותרים לשמירה. לדוגמה, אם מגדירים את משך השמירה ל-864,000 שניות (10 ימים) כחלק מהאילוץ הזה, כל בקשה ליצור או לעדכן קטגוריה בארגון חייבת לכלול משך שמירה של מחיקה רכה של 864000 במטען הייעודי (payload) של הבקשה. בקשות שלא כוללות את ההגדרה הזו ייכשלו.

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

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

משך בשניות של מדיניות שמירת נתונים בקטגוריה

שם האילוץ: constraints/storage.retentionPolicySeconds סוג האילוץ: list

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

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

דרישה של גישה אחידה ברמת הקטגוריה

שם האילוץ: constraints/storage.uniformBucketLevelAccess סוג האילוץ: boolean

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

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

שם האילוץ: constraints/gcp.detailedAuditLoggingMode סוג האילוץ: boolean

כשמחילים את האילוץ detailedAuditLoggingMode, יומני ביקורת של Cloud המשויכים לפעולות של Cloud Storage מכילים מידע מפורט על הבקשות והתשובות. מומלץ להשתמש באילוץ הזה יחד עם נעילת קטגוריה ונעילת שמירת אובייקטים כשרוצים לעמוד בדרישות שונות, כמו כלל SEC 17a-4(f), כלל CFTC 1.31(c)-(d) וכלל FINRA 4511‎(c).

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

  • פרטי כניסה, כמו Authorization, X-Goog-Signature או upload-id.
  • מידע על מפתחות הצפנה, כמו x-goog-encryption-key.
  • נתוני אובייקט גולמיים.

כשמשתמשים באילוץ הזה, חשוב לשים לב לדברים הבאים:

  • לא מובטח שתקבלו מידע מפורט על הבקשה והתשובה. במקרים נדירים, יכול להיות שיוחזרו יומנים ריקים.
  • הבקשות והתשובות מתועדות בפורמט גנרי התואם לשמות השדות ב-API בפורמט JSON.

הגבלה של סוגי אימות

שם האילוץ: constraints/storage.restrictAuthTypes סוג האילוץ: list

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

אילוץ הרשימה דוחה באופן מפורש סוגי אימות ספציפיים ומאפשר את כל השאר. כדי לעשות את זה, צריך לציין את סוגי האימות המוגבלים במפתח deniedValues בתוך rules של המגבלה restrictAuthTypes. אם תנסו להציג את סוגי האימות המוגבלים במפתח allowedValues, תופיע שגיאה.

אפשר להגביל את סוגי האימות הבאים:

  • ‫SERVICE_ACCOUNT_HMAC_SIGNED_REQUESTS: מגביל בקשות שנחתמו על-ידי מפתחות HMAC של חשבון שירות.

  • ‫in:ALL_HMAC_SIGNED_REQUESTS: מגביל בקשות שנחתמו על-ידי מפתח HMAC כלשהו. אם צריך לעמוד בדרישות בנוגע לריבונות הנתונים, מומלץ להגביל את כל הבקשות החתומות בפורמט HMAC.

  • ‫in:ALL_SIGNED_REQUESTS: מגביל בקשות שנחתמו על-ידי מפתח HMAC או RSA.

כשמפעילים את האילוץ הזה, יקרו הדברים הבאים:

  • ‫Cloud Storage מגביל את הגישה לבקשות שמאומתות באמצעות סוג האימות המוגבל. הבקשות נכשלות ומתקבלת השגיאה 403 Forbidden.

  • ישויות שקיבלו בעבר הרשאה לבצע את הבקשה מקבלות הודעת שגיאה המסבירה שסוג האימות מושבת.

  • אם יש הגבלות על מפתחות HMAC:

    • אי אפשר יותר ליצור או להפעיל מפתחות HMAC מהסוג המוגבל במשאב שבו האילוץ נאכף. הבקשות ליצירה או להפעלה של מפתחות HMAC נכשלות, עם השגיאה 403 Forbidden.

    • מפתחות HMAC קיימים יישארו אבל כבר אי אפשר יהיה להשתמש בהם. אפשר להשבית או למחוק אותם, אבל אי אפשר להפעיל אותם מחדש.

כשמשתמשים באילוץ restrictAuthTypes, חשוב לשים לב למשאבים קיימים התלויים באימות HMAC. לדוגמה, אם עברתם מ-Amazon Simple Storage Service (Amazon S3), סביר להניח שהאפליקציה שלכם משתמשת במפתחות HMAC כדי לאמת בקשות ל-Cloud Storage. אפשר להשתמש במדד של Cloud Monitoring, storage.googleapis.com/authn/authentication_count כדי לעקוב אחרי מספר הפעמים שבהן נעשה שימוש במפתחות HMAC לאימות בקשות.

הגבלת בקשות HTTP לא מוצפנות

שם האילוץ: constraints/storage.secureHttpTransport סוג האילוץ: boolean

כשמחילים את האילוץ secureHttpTransport, כל גישת HTTP לא מוצפנת למשאבי Cloud Storage נדחית.

מגבלות נוספות

האילוצים הבאים של מדיניות הארגון חלים באופן כללי יותר עלCloud de Confiance, אבל לעיתים קרובות הם חלים על שירות Cloud Storage:

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

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

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