בדף הזה מוסברת הגישה האחידה ברמת הקטגוריה, שמאפשרת שליטה אחידה בגישה למשאבי Cloud Storage. כאשר מפעילים בקטגוריה גישה אחידה ברמת הקטגוריה, רשימות של בקרת גישה (ACL) מושבתות ורק הרשאות לניהול זהויות והרשאות גישה (IAM) ברמת הקטגוריה מעניקות גישה לקטגוריה הזו ולאובייקטים שהיא מכילה. אתם מבטלים את הגישה שהוענקה על ידי רשימות ACL של אובייקטים ואת היכולת לנהל הרשאות באמצעות רשימות ACL של קטגוריות.
סקירה כללית
Cloud Storage מציע שתי מערכות שבאמצעותן אפשר להעניק למשתמשים הרשאה לגשת לקטגוריות ולאובייקטים: IAM ורשימות של בקרת גישה (ACL). המערכות האלו פועלות במקביל - כדי שמשתמשים יקבלו גישה למשאב של Cloud Storage, רק אחת מהמערכות צריכה להעניק הרשאת משתמש. ב-Google Cloud משתמשים ב-IAM כדי להעניק מגוון הרשאות ברמת הקטגוריה והפרויקט. רשימות ACL משמשות רק ב-Cloud Storage ויש להן אפשרויות מוגבלות של הרשאות, אבל הן מאפשרות להעניק הרשאות בנפרד לכל אובייקט.
כדי לתמוך במערכת הרשאות אחידה, ל-Cloud Storage יש גישה אחידה ברמת הקטגוריה. השימוש בתכונה הזו בקטגוריה משבית את רשימות ה-ACL לכל המשאבים של Cloud Storage שבקטגוריה ולאחר מכן הגישה למשאבי Cloud Storage מוענקת רק דרך IAM. אי אפשר להשבית את הגישה האחידה ברמת הקטגוריה לאחר שהיא הופעלה בקטגוריה במשך 90 ימים רצופים.
האם כדאי להשתמש בגישה אחידה ברמת הקטגוריה?
באופן כללי, מומלץ להשתמש בגישה אחידה ברמת הקטגוריה:
הגישה האחידה ברמת הקטגוריה מאחדת ומפשטת את הדרך שבה אתם מעניקים גישה למשאבים של Cloud Storage.
גישה אחידה ברמת הקטגוריה מונעת חשיפת נתונים לא מכוונת מרשימות ACL.
כדי להשתמש בתכונות הבאות, צריך להפעיל גישה אחידה ברמת הקטגוריה:
- מרחב שמות היררכי
- תיקיות מנוהלות
- תנאי IAM שמוגדרים ישירות בקטגוריה
כדי להעניק גישה לישויות של איחוד זהויות של כוח עבודה או של איחוד זהויות של עומסי עבודה למשאבים של Cloud Storage, צריך להפעיל גישה אחידה ברמת הקטגוריה.
לא כדאי להשתמש בגישה אחידה ברמת הקטגוריה אם רוצים להשתמש במערכת רשימות ה-ACL בקטגוריה.
אופן ההתנהגות כאשר היא מופעלת
אפשר להפעיל את הגישה האחידה ברמת הקטגוריה כשיוצרים קטגוריה חדשה, או להפעיל באופן ספציפי גישה אחידה ברמת הקטגוריה בקטגוריה קיימת.
אחרי ההפעלה, הקטגוריה מתנהגת כך:
בקשות להגדרה, לקריאה או לשינוי של רשימות ACL של קטגוריות ואובייקטים נכשלות עם שגיאות
400 Bad Request.- זה כולל בקשות API בפורמט JSON בכל אחת מה-methods
BucketAccessControls,DefaultObjectAccessControlsאוObjectAccessControls.
- זה כולל בקשות API בפורמט JSON בכל אחת מה-methods
בקשות API בפורמט JSON לייצוג מלא של מטא-נתונים של קטגוריה או של אובייקט כוללות רשימת ACL ריקה כחלק מהתגובה.
בעלות על אובייקט מסוים לא קיימת יותר; גישה המוענקת מבעלות כזו מבוטלת, ובקשות למטא-נתונים של קטגוריות ואובייקטים לא כוללות יותר שדה
owner.בזמן יצירתן, הקטגוריות מקבלות תפקידי IAM מיוחדים. אם מפעילים גישה אחידה ברמת הקטגוריה כחלק מיצירת קטגוריה חדשה, לקטגוריה הזו יהיו תפקידי IAM נוספים.
התנהגות זו שומרת על ההרשאות שהאובייקטים היו מקבלים בירושה מה-ACL הסטנדרטי המשמש כברירת המחדל של אובייקטים בקטגוריה.
אם מפעילים גישה אחידה ברמת הקטגוריה בקטגוריה קיימת, צריך להחיל את כל התפקידים האלו באופן ידני; אם בוצע בעבר שינוי של ה-ACL המשמש כברירת המחדל לאובייקטים, כנראה כדאי להחיל קבוצה אחרת של תפקידי IAM.
אופן ההתנהגות אם היא מבוטלת
כדי לתמוך באפשרות להשבית גישה אחידה ברמת הקטגוריה ולחזור להשתמש ברשימות ACL, Cloud Storage שומר רשימות ACL קיימות. אם משביתים את הגישה האחידה ברמת הקטגוריה:
אובייקטים מקבלים חזרה את רשימות ה-ACL שנשמרו.
כל אובייקט שנוסף לקטגוריה אחרי שהופעלה גישה אחידה ברמת הקטגוריה, יקבל רשימות ACL בהתאם לרשימות ה-ACL שהוגדרו כברירת מחדל לאובייקטים בקטגוריה.
דרישות להשבתת גישה אחידה ברמת הקטגוריה
כדי להשבית את הגישה האחידה ברמת הקטגוריה, צריך לוודא שהתנאים הבאים מתקיימים:
התכונה הופעלה במשך פחות מ-90 ימים ברצף.
הסרתם את כל תנאי ה-IAM ממדיניות ה-IAM של הקטגוריה.
הקטגוריה לא כפופה לאילוץ של מדיניות הארגון – דרישה לגישה אחידה ברמת הקטגוריה.
מחקתם מהקטגוריה את כל התיקיות המנוהלות.
שיקולים כשמעבירים קטגוריה קיימת
כאשר מפעילים גישה אחידה ברמת הקטגוריה על קטגוריה קיימת, חשוב להעביר ל-IAM את ההרשאות של המשתמשים והשירותים שהסתמכו בעבר על רשימות ACL לצורך גישה. בקטע הזה מוסברים מספר שלבים שכדאי לבצע כאשר מעבירים קטגוריה לגישה אחידה ברמת הקטגוריה. שימו לב שמכיוון שרשימות ACL ו-IAM מסונכרנות בכל הנוגע להרשאות לקטגוריה, השיקולים מתמקדים במיוחד בגישה לאובייקטים בקטגוריה ולא בגישה לקטגוריה.
בדיקה אם הרשאת IAM ברמת הקטגוריה גורמת לחשיפת יתר של נתונים
לפני שמקצים שווי ערך ב-IAM לרשימות ה-ACL, כדאי לשקול את הדברים הבאים:
- הרשאת IAM שהוחלה ברמת הקטגוריה חלה עלכל האובייקטים בקטגוריה, ואילו רשימות ACL של אובייקטים יכולות להשתנות מאובייקט לאובייקט.
אם רוצים להחיל גישה על אובייקטים מסוימים אבל לא על אובייקטים אחרים, צריך לקבץ את האובייקטים לקטגוריות נפרדות. כל קיבוץ צריך לכלול את האובייקטים שיש להם את אותן ההרשאות.
בדיקת שימוש ב-ACL של אובייקט
כשעוברים לגישה אחידה ברמת הקטגוריה, צריך לבדוק האם ניגשים לאובייקטים בקטגוריה דרך רשימות ACL שהוחלו עליהם. כדי לבדוק זאת, Cloud Monitoring כולל מדד שעוקב אחרי השימוש ב-ACL. אם המדד הזה מצביע על כך שמשתמשים או שירותים מסתמכים על רשימות ACL לגישה לאובייקטים, צריך להקצות לקטגוריה שווי ערך ב-IAM לפני שמפעילים גישה אחידה ברמת הקטגוריה. למדריך לבדיקת השימוש ב-ACL ב-Monitoring, ראו בדיקת השימוש ב-ACL.
אפשר להשתמש במדד הזה כדי לקבוע אם הפעלת גישה אחידה ברמת הקטגוריה תפגע בתהליך העבודה:
| מדד | תיאור |
|---|---|
storage.googleapis.com/authz/acl_operations_count |
מספר פעולות ה-ACL שיושבתו לאחר הפעלת גישה אחידה ברמת הקטגוריה, בחלוקה לפי סוג פעולת ה-ACL והקטגוריה. |
פעולת ACL חשובה שצריך לבדוק היא OBJECT_ACCESS_REQUIRED_OBJECT_ACL:
אם המספר הוא אפס, לא נדרשו רשימות ACL ברמת האובייקט כדי לגשת לאובייקטים ב-6 השבועות האחרונים. כללי מדיניות IAM מתייחסים להרשאות הדרושות ברמת הקטגוריה או הפרויקט.
אם המספר הזה גדול מאפס, ב-6 השבועות האחרונים היו בקשות גישה לאובייקטים שדרשו הרשאות ACL של אובייקטים. צריך להקצות כללי מדיניות IAM שווי ערך לפני שמפעילים גישה אחידה ברמת הקטגוריה.
למידע נוסף על מדדים של Monitoring, ראו מדדים, סדרת זמנים ומשאבים.
בדיקת ה-ACL שמשמש כברירת המחדל לאובייקטים בקטגוריה
לקטגוריות ללא גישה אחידה ברמת הקטגוריה משויך ACL המשמש כברירת המחדל בשביל האובייקטים. כשמוסיפים אובייקטים חדשים לקטגוריות כאלו, ה-ACL המשמש כברירת המחדל חל עליהם, אלא אם מספקים ACL באופן מפורש בזמן הוספת האובייקט לקטגוריה.
לדוגמה, קטגוריות בדרך כלל משתמשות ב-ACL המוגדר מראש projectPrivate בתור ה-ACL המשמש כברירת המחדל בשביל האובייקטים. projectPrivate מעניקה הרשאת READER לאובייקט, לצופים בפרויקט המשויכים לקטגוריה, והרשאת OWNER לאובייקט, לעורכים ולבעלים של הפרויקט המשויכים לקטגוריה.
לפני שמפעילים גישה אחידה ברמת הקטגוריה, צריך לבדוק את ה-ACL הקיים בקטגוריה המשמש כברירת המחדל בשביל האובייקטים. כדאי לשקול אם רוצים להעניק את ההרשאות המשויכות ל-ACL המוגדר כברירת המחדל בשביל האובייקטים, אחרי הפעלה של גישה אחידה ברמת הקטגוריה. אם כן, צריך להקצות לקטגוריה שווי ערך ב-IAM.
הקצאת תפקידים שווי ערך ב-IAM לרשימות ACL של אובייקטים
רשימות ACL של אובייקטים יכולות להעניק גישה שלא ניתנת כרגע על ידי IAM. כדי לוודא שהמשתמשים הקיימים לא יאבדו את הגישה לאובייקטים כשמפעילים גישה אחידה ברמת הקטגוריה, אפשר להשתמש בטבלה הבאה ולהקצות למשתמשים המושפעים את תפקידי ה-IAM המתאימים.
| הרשאת ACL של אובייקט | תפקיד IAM שווה ערך |
|---|---|
READER |
קורא אובייקט מדור קודם של Storage (roles/storage.legacyObjectReader) |
OWNER |
בעלי אובייקט מדור קודם של Storage (roles/storage.legacyObjectOwner) |
שיקולים לשימוש בתנאי IAM
כדי למנוע התנגשויות בין כללי מדיניות IAM של קטגוריה לבין רשימות ACL של אובייקטים, אפשר להשתמש בתנאי IAM רק בקטגוריות שהופעלה בהן גישה אחידה ברמת הקטגוריה. כלומר:
כדי להגדיר תנאי IAM לקטגוריה, צריך קודם להפעיל בקטגוריה גישה אחידה ברמת הקטגוריה.
לפני שאפשר לבצע בקטגוריה מסוימת השבתה של הגישה האחידה ברמת הקטגוריה, צריך להסיר את כל תנאי IAM מהמדיניות של הקטגוריה. למידע על צפייה בתנאים והסרה שלהם ממדיניות של קטגוריה, ראו שימוש בתנאי IAM בקטגוריה.
המאמרים הבאים
- מידע על שימוש בגישה אחידה ברמת הקטגוריה
- מידע על מגבלות אכיפת גישה אחידה ברמת הקטגוריה, שאפשר להגדיר בארגון, בתיקייה או בפרויקט ב- Google Cloud .
- הגדרת הרשאות IAM בקטגוריות ובפרויקטים