סקירה כללית על בקרת הגישה

אתם קובעים למי תהיה גישה לקטגוריות ולאובייקטים שלכם ב-Cloud Storage, ואיזו רמת גישה תהיה להם.

בחירה בין גישה אחידה לגישה פרטנית

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

  • אחידה (מומלץ): גישה אחידה ברמת הקטגוריה מאפשרת להשתמש בניהול זהויות והרשאות גישה (IAM) בלבד כדי לנהל הרשאות. ‫IAM מחילה את ההרשאות על כל האובייקטים שנכללים בקטגוריה או על קבוצות של אובייקטים עם קידומות נפוצות של שמות. IAM מאפשרת גם להשתמש בתכונות שלא זמינות כשעובדים עם רשימות ACL, כמו תיקיות מנוהלות, תנאים של IAM, שיתוף עם הגבלות על דומיינים ואיחוד שירותי אימות הזהות של כוח עבודה.

  • פרטנית: האפשרות הפרטנית מאפשרת להשתמש ב-IAM וברשימות של בקרת גישה (ACL) יחד כדי לנהל את ההרשאות. רשימות ACL הן מערכת בקרת גישה מדור קודם ל-Cloud Storage, שמיועדת לפעול בשילוב עם Amazon S3. רשימות ACL מאפשרות גם לציין גישה לכל אובייקט בנפרד.

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

שימוש בהרשאות IAM עם רשימות ACL

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

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

רשימות ACL שולטות בהרשאות רק למשאבי Cloud Storage ויש להן אפשרויות הרשאה מוגבלות, אבל הן מאפשרות להעניק הרשאות לכל אובייקטים בנפרד. כדאי להשתמש ברשימות ACL במקרים הבאים:

  • התאמה אישית של גישה לאובייקטים ספציפיים בתוך קטגוריה.
  • העברת נתונים מ-Amazon S3.

אפשרויות נוספות לבקרת גישה

נוסף על IAM ורשימות ACL, אפשר להיעזר בכלים הבאים כדי לשלוט בגישה למשאבים:

כתובות URL חתומות (אימות מחרוזת שאילתה)

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

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

יצירת כתובות URL חתומות:

מסמכי מדיניות חתומים

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

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

כללי אבטחה של Firebase

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

מניעת גישה ציבורית

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

גבולות הגישה לפרטי כניסה

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

סינון לפי כתובת IP של קטגוריות

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

שיטות מומלצות לשימוש ב-IAM וברשימות ACL

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

  • מומלץ להשתמש בעיקרון של הרשאות מינימליות כשמעניקים גישה לקטגוריות, לאובייקטים או לתיקיות מנוהלות.

    העיקרון של הרשאות מינימליות הוא כלל אבטחה בסיסי כשמעניקים גישה למשאבים. כשאתם מעניקים גישה שמבוססת על העיקרון של הרשאות מינימליות, אתם מעניקים למשתמשים את ההרשאה המינימלית הנדרשת לביצוע המשימה שהוקצתה להם. לדוגמה, כשרוצים לשתף קבצים עם מישהו, נותנים לו תפקיד Storage Object Viewer של IAM או הרשאת READER של רשימות ACL, ולא תפקיד Storage Admin של IAM או הרשאת OWNER של רשימות ACL.

  • רצוי לא להקצות תפקידי IAM עם הרשאת setIamPolicy, או להעניק הרשאת OWNER של ACL לאנשים שאתם לא מכירים.

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

  • צריך להיזהר מאוד עם ההרשאות שנותנים למשתמשים אנונימיים.

    חשבונות המשתמשים allUsers ו-allAuthenticatedUsers מתאימים רק כשרוצים שכל מי שמשתמש באינטרנט יוכל לקרוא ולנתח את הנתונים. הרשאות בהיקף כזה מתאימות לפעמים לאפליקציות ולתרחישים מסוימים, אבל בדרך כלל רצוי לא להעניק לכל המשתמשים הרשאות מסוימות, כמו הרשאות setIamPolicy, update, create ו-delete של IAM, או ההרשאות OWNER של רשימות ACL.

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

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

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

    • מקצים את תפקיד ה-Storage Admin של IAM בפרויקט לקבוצה במקום לאדם ספציפי.

    • מקצים את תפקיד ה-IAM ‏Storage Admin בפרויקט לשני אנשים לפחות.

    • מעניקים הרשאת OWNER של רשימות ACL בקטגוריה לשני אנשים לפחות.

  • שימו לב להתנהגות של Cloud Storage בתרחישים של פעולה הדדית.

    כשמשתמשים ב-API בפורמט XML לגישה הדדית עם שירותי אחסון אחרים, כמו Amazon S3, מזהה החתימה קובע את התחביר של ה-ACL. לדוגמה, אם הכלי או הספרייה שלכם שולחים בקשה ל-Cloud Storage לאחזור רשימות ACL ומזהה החתימה של הבקשה הוא של ספק אחסון אחר, Cloud Storage מחזיר מסמך XML שמשתמש בתחביר ה-ACL של ספק האחסון הזה. אם הכלי או הספרייה שלכם שולחים בקשה ל-Cloud Storage להשתמש ברשימות ACL ומזהה החתימה של הבקשה הוא של ספק אחסון אחר, Cloud Storage מצפה לקבל מסמך XML שמשתמש בתחביר ה-ACL של ספק האחסון הזה.

    מידע נוסף על השימוש ב-API בפורמט XML לפעולה הדדית עם Amazon S3 זמין במאמר בנושא מיגרציה מ-Amazon S3 ל-Cloud Storage בקלות.

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