פתרון בעיות בבקרת גישה

במאמר הזה מוסבר איך לפתור בעיות אבטחה שקשורות להרשאות ניהול זהויות והרשאות גישה (IAM), לבקרת גישה ברמת העמודה ולמפתחות הצפנה בניהול הלקוח (CMEK) ב-BigQuery. בעיות בהרשאות IAM בדרך כלל מובילות לשגיאות Access Denied כמו השגיאות הבאות:

  • Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.
  • Access Denied: Project PROJECT_ID: User does not have bigquery.datasets.get permission on dataset DATASET.
  • User does not have permission to query table PROJECT_ID:DATASET.TABLE.
  • Access Denied: Table PROJECT_ID:DATASET.TABLE: User does not have permission to query table PROJECT_ID:DATASET.TABLE, or perhaps it does not exist.
  • Access Denied: User PRINCIPAL does not have permission to perform bigquery.tables.getData on resource 'projects/PROJECT_ID/datasets/DATASET/tables/TABLE'.

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

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

איסוף מידע על הבעיה

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

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

כדי לקבל מידע על הישות המורשית, המשאב וההרשאות, בודקים את הפלט מכלי שורת הפקודה של BigQuery, את תגובה מה-API או את BigQuery במסוף Google Cloud .

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

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

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

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

קבלת מידע מיומני הביקורת של Cloud

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

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

    כניסה לדף Logs Explorer

    לחלופין, בתפריט הניווט, בוחרים באפשרות Monitoring > Logs Explorer.

  2. בכלי Logs Explorer, בוחרים באפשרות Project logs (יומני פרויקט) בהגדרת ההיקף של היומנים.

  3. בחלון השאילתה, מזינים את השאילתה הבאה כדי לקבל שגיאות שקשורות להרשאות מיומני הגישה לנתונים ב-BigQuery:

    resource.type="bigquery_resource" AND
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" AND
protoPayload.status.message:"Access Denied" OR
protoPayload.status.message:"Permission denied" OR
protoPayload.status.code=7

    מחליפים את PROJECT_ID במזהה הפרויקט.

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

  5. בקטע protoPayload, מרחיבים את המערך authorizationInfo ואז מרחיבים כל צומת במערך authorizationInfo.

    המערך authorizationInfo מציג כל בדיקת הרשאה שבוצעה במהלך קריאה ל-API.

  6. כדי לראות את הסיבה לשגיאה, מחפשים את הרשומה granted: false. granted: false הרשומה כוללת את הפרטים הבאים:

    • ‫permission: מחרוזת ההרשאה ב-IAM שנבדקה. לדוגמה, bigquery.tables.getData.
    • resource: השם מוגדר במלואו של המשאב שהגורם המורשה ניסה לגשת אליו. לדוגמה, projects/myproject/datasets/mydataset/tables/mytable.
    • ‫principalEmail (אם זמין): מוזכר ב-protoPayload.authenticationInfo, זהו חשבון המשתמש שניסה לבצע את הפעולה.

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

שימוש בכלי הניתוח למדיניות לצורך מדיניות הרשאות

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

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

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

  1. נכנסים לדף כלי הניתוח למדיניות במסוף Google Cloud .

    מעבר לכלי הניתוח למדיניות

    אפשרות נוספת: בתפריט הניווט, בוחרים באפשרות IAM & Admin > כלי הניתוח למדיניות.

  2. לוחצים על יצירת שאילתה מותאמת אישית.

  3. בדף Configure your query, מזינים את המידע שאספתם קודם:

    1. בקטע Select the scope, בשדה Select query scope, מוודאים שהפרויקט הנוכחי מופיע או לוחצים על Browse כדי לבחור משאב אחר.

    2. בקטע Set the query parameters (הגדרת פרמטרים של שאילתה), בParameter 1 (פרמטר 1), בוחרים באפשרות Principal (חשבון משתמש), ובשדה Principal (חשבון משתמש), מזינים את כתובת האימייל של המשתמש, הקבוצה או חשבון השירות.

    3. לוחצים על הוספת פרמטר.

    4. בפרמטר 2, בוחרים באפשרות הרשאה, בשדה הרשאה לוחצים על בחירה, בוחרים את ההרשאה של BigQuery ואז לוחצים על הוספה. לדוגמה, בוחרים באפשרות bigquery.tables.getData.

    5. לוחצים על הוספת פרמטר.

    6. בפרמטר 3, בוחרים באפשרות משאב, ובשדה משאב מזינים את שם המשאב המוגדר במלואו. שם המשאב חייב לכלול את קידומת השירות, כמו בדוגמאות הבאות:

      • BigQuery project: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • מערך נתונים של BigQuery: //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • טבלה ב-BigQuery: //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. בחלונית Custom query, לוחצים על Analyze > Run query.

  5. בודקים את תוצאות השאילתה. התוצאה יכולה להיות אחת מהאפשרויות הבאות:

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

מציאת התפקיד הנכון ב-IAM שמעניק את ההרשאות הנדרשות

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

אם בארגון שלכם משתמשים בתפקידים בהתאמה אישית, תוכלו להציג רשימה של כל התפקידים בהתאמה אישית שנוצרו בפרויקט או בארגון כדי למצוא את התפקיד הנכון. לדוגמה, במסוף Google Cloud , בדף Roles, אפשר לסנן את הרשימה לפי Type:Custom כדי לראות רק תפקידים בהתאמה אישית.

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

  1. פותחים את הקטע BigQuery permissions בדף BigQuery IAM roles and permissions.

  2. בסרגל החיפוש Enter a permission, מזינים את ההרשאה שאוחזרה מהודעת השגיאה, מהיסטוריית העבודות או מיומני הביקורת. לדוגמה, bigquery.tables.getData.

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

  3. החלת העיקרון של הרשאות מינימליות: ברשימת התפקידים, בוחרים את התפקיד עם ההרשאות המינימליות שמעניק את ההרשאות הנדרשות. לדוגמה, אם חיפשתם את bigquery.tables.getData כדי להעניק את היכולת לשלוח שאילתות לגבי נתוני טבלה, התפקיד BigQuery Data Viewer הוא התפקיד עם ההרשאות הכי מצומצמות שמאפשר את ההרשאה הזו.

  4. נותנים לחשבון המשתמש את התפקיד המתאים. במאמר בקרת גישה למשאבים באמצעות IAM מוסבר איך להעניק תפקיד IAM למשאב BigQuery.

פתרון בעיות שקשורות לבקרת גישה ברמת העמודה

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

אני לא רואה את התפקידים בקטלוג הנתונים

אם אתם לא רואים תפקידים כמו Data Catalog Fine-Grained Reader, יכול להיות שלא הפעלתם את Data Catalog API בפרויקט. במאמר לפני שמתחילים מוסבר איך להפעיל את Data Catalog API. התפקידים של Data Catalog מופיעים כמה דקות אחרי שמפעילים את Data Catalog API.

לא ניתן להציג את הדף Taxonomies

כדי לראות את הדף Policy tag taxonomies בGoogle Cloud מסוף, צריך הרשאות נוספות. לדוגמה, לתפקיד Policy Tag Admin ב-Data Catalog יש גישה לדף Taxonomies.

הפעלתי תגי מדיניות, אבל נראה שהם לא פועלים

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

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

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

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

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

כדי לפתור את הבעיה, צריך לוודא את הפרטים הבאים:

  • בדף Policy tag taxonomies במרכז האבטחה של BigQuery, מוודאים שהמתג Enforce access control במצב On.

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

    bq query --nouse_cache --use_legacy_sql=false "SELECT * EXCEPT (customer_pii) FROM my_table;"

שיקולים לגבי העברת פרויקטים

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

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

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

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

ריכזנו כאן רשימה של שגיאות נפוצות והמלצות לפתרון שלהן כשמשתמשים במפתחות הצפנה בניהול הלקוח (CMEK) עם Cloud Key Management Service:

שגיאה: Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
פתרון: לחשבון השירות של BigQuery שמשויך לפרויקט אין הרשאת IAM מספקת כדי לבצע פעולות במפתח Cloud KMS שצוין. כדי להעניק את הרשאת ה-IAM הנדרשת, פועלים לפי ההוראות שמופיעות בהודעת השגיאה או במאמר הענקת הרשאה להצפנה ולפענוח.
שגיאה: Existing table encryption settings don't match encryption settings specified in the request
פתרון: השגיאה הזו יכולה להתרחש אם בטבלת היעד יש הגדרות הצפנה שלא תואמות להגדרות ההצפנה בבקשה. כדי לפתור את הבעיה, צריך להשתמש בTRUNCATE write disposition כדי להחליף את הטבלה, או לציין טבלת יעד אחרת.
שגיאה: This region is not supported
פתרון: האזור של מפתח Cloud KMS לא תואם לאזור של מערך הנתונים ב-BigQuery עבור טבלת היעד. כדי לפתור את הבעיה, צריך לבחור מפתח באזור שמתאים למערך הנתונים, או לטעון נתונים למערך נתונים שמתאים לאזור המפתח.
שגיאה: Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
פתרון: מדיניות ארגונית מנעה יצירת משאב או הרצת שאילתה. מידע נוסף על המדיניות הזו זמין במאמר בנושא דרישה להשתמש ב-CMEK לכל המשאבים.
שגיאה: Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
פתרון: מדיניות ארגונית מנעה יצירת משאב או הרצת שאילתה. מידע נוסף על המדיניות הזו זמין במאמר הגבלת מפתחות Cloud KMS לפרויקט BigQuery.

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