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

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

אילוצים של Cloud Storage

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

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

שם ה-API: constraints/storage.publicAccessPrevention

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

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

משך בשניות של מדיניות שמירת נתונים

שם ה-API: constraints/storage.retentionPolicySeconds

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

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

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

שם ה-API: constraints/storage.uniformBucketLevelAccess

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

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

שם ה-API: constraints/gcp.detailedAuditLoggingMode

כשמחילים את האילוץ 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.
  • נתוני אובייקט גולמיים.

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

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

  • הפעלה של detailedAuditLoggingMode מגדילה את כמות הנתונים המאוחסנים ביומני הביקורת, ויכולה להיות לכך השפעה על החיובים של Cloud Logging על יומני גישה לנתונים.

  • יכולות לעבור עד 10 דקות עד להפעלה או להשבתה של detailedAuditLoggingMode.

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

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

שם ה-API: constraints/storage.restrictAuthTypes

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

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

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

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

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

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

  • ‫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 לאימות בקשות.

דרישה לשימוש במפתחות הצפנה בניהול הלקוח (CMEK)

שם ה-API: constraints/gcp.restrictNonCmekServices

כשמחילים את האילוץ restrictNonCmekServices, מגדירים את השירותים שהמשאבים שלהם צריכים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). כדי להחיל את האילוץ הזה על אובייקטים או על קטגוריות של Cloud Storage, מוסיפים את storage.googleapis.com לרשימת השירותים המוגבלים, כשהאילוץ מוגדר ל-Deny. בכפוף לאילוץ, צריך לכתוב את האובייקטים של Cloud Storage באמצעות מפתח Cloud KMS שמצוין בבקשה או מוגדר כמפתח ברירת המחדל להצפנה של קטגוריית היעד. בקטגוריות של Cloud Storage צריך להגדיר מפתח Cloud KMS כמפתח ברירת המחדל להצפנה.

אם מנסים לכתוב אובייקט או ליצור קטגוריה שאינה מוצפנת באמצעות מפתח Cloud KMS, תופיע הודעת השגיאה הבאה: "A customer-managed encryption key (CMEK) is required by an org policy in effect. Either set a default CMEK on the bucket or specify a CMEK in your request".

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

  • הפעלה של restrictNonCmekServices עלולה לגרום לשיבושים אם כותבים בקטגוריה ללא מפתח ברירת מחדל של Cloud KMS, או אם מחריגים מפתח Cloud KMS בבקשה.

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

  • אובייקטים קיימים המוצפנים באמצעות מפתחות הצפנה בניהול Google או באמצעות מפתחות הצפנה באספקת הלקוח (CSEK) לא כפופים לאילוץ הזה. עם זאת, שכתובים בעתיד של אובייקטים כאלו יהיו כפופים לאילוץ.

  • השינויים ב-constraints/gcp.restrictNonCmekServices נכנסים לתוקף בתוך 10 דקות לכל היותר.

למידע נוסף על האילוץ הזה, ראו מדיניות הארגון לגבי CMEK.

הגבלה של פרויקטים עם מפתח הצפנה תקף בניהול הלקוח (CMEK)

שם ה-API: constraints/gcp.restrictCmekCryptoKeyProjects

כשמחילים את האילוץ restrictCmekCryptoKeyProjects, מגדירים את הפרויקטים שמהם אפשר להשתמש במפתח Cloud KMS בבקשות. כשמחילים את האילוץ הזה:

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

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

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

אם מנסים לציין מפתח Cloud KMS בבקשה שלא מגיעה מפרויקט מורשה, תופיע הודעת השגיאה הבאה: "The specified key cannot be used because its project is restricted by an org policy. Try again with a customer-managed encryption key (CMEK) from an allowed project".

אם מנסים לכתוב בקטגוריה באמצעות מפתח Cloud KMS שלא מגיע מפרויקט מורשה, מקבלים את הודעת השגיאה הבאה: "The bucket uses a default key from a project that is restricted by an org policy in effect. Either set an allowed customer-managed encryption key (CMEK) as the default for the bucket or specify an allowed CMEK in your request".

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

  • האובייקטים הקיימים לא כפופים לאילוץ הזה.

  • האילוץ הזה לבדו לא אוכף את השימוש במפתחות הצפנה בניהול הלקוח (CMEK) מפרויקטים מורשים. כדי לאכוף את השימוש במפתחות הצפנה בניהול הלקוח מפרויקטים מורשים, צריך להחיל את האילוצים constraints/gcp.restrictNonCmekServices ו-constraints/gcp.restrictCmekCryptoKeyProjects.

  • השינויים ב-constraints/gcp.restrictCmekCryptoKeyProjects נכנסים לתוקף בתוך 10 דקות לכל היותר.

למידע נוסף על האילוץ הזה, ראו מדיניות הארגון לגבי CMEK.

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