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

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

שגיאות נפוצות של דחיית גישה

הנה כמה דוגמאות לשגיאות נפוצות של דחיית גישה:

  • 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'.

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

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

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

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

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

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

שגיאת "הגישה נדחתה" בכרטיסייה Job Information בקטע Query Results.

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

במקרים מסוימים, יכול להיות שתוכלו לבקש את ההרשאות החסרות ישירות מהודעת השגיאה. למידע נוסף, קראו את המאמר הודעות שגיאה בנושא הרשאות במסמכי התיעוד של 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" OR "bigquery_project" OR "bigquery_dataset") AND
logName=("projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" OR
  "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity") 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, שבו מוצגים ההרשאה, המשאב ו-principalEmail.

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

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

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

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

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

    לכלי הניתוח למדיניות

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

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

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

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

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

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

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

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

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

      • פרויקט ב-BigQuery: //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. בודקים את תוצאות השאילתה. התוצאה יכולה להיות אחת מהאפשרויות הבאות:

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

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

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

אם בארגון שלכם משתמשים בתפקידים בהתאמה אישית, אתם יכולים למצוא את התפקיד הנכון על ידי הצגת רשימה של כל התפקידים בהתאמה אישית שנוצרו בפרויקט או בארגון. לדוגמה, בדף Roles במסוף Google Cloud , אפשר לסנן את הרשימה לפי 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.

פתרון בעיות בתרחישים נפוצים של דחיית גישה

אם פעולה נכשלת עם השגיאה 403 accessDenied (Access Denied: RESOURCE_TYPE RESOURCE_ID: DETAILS), בדקו את התרחישים הנפוצים הבאים, בנוסף לשלבים הכלליים של IAM שצוינו למעלה:

  • Non-existent resource or location mismatch (or perhaps it does not exist). כשבסוף הודעת השגיאה מופיע or perhaps it does not exist, המערכת של BigQuery מסתירה את קיומם של הטבלה, התצוגה או השגרה כי לחשבון הראשי אין הרשאות למטא-נתונים של מערך הנתונים או הפרויקט (bigquery.tables.get או bigquery.datasets.get). ודאו שמזהה הפרויקט, מזהה מערך הנתונים ושם הטבלה מאויתים נכון, ושהשאילתה פועלת באותו מיקום של מערך הנתונים.

  • תצוגות ופונקציות מורשות. כשמשתמש שולח שאילתה לתצוגה מורשית או לשגרה מורשית, הוא צריך הרשאה לשלוח שאילתה לתצוגה או לשגרה, והתצוגה או השגרה עצמה צריכות להיות מורשות ברשימת בקרת הגישה (ACL) של מערך הנתונים במקור. אם השאילתה נכשלת עם Access Denied במסד הנתונים הטבלאי הבסיסי, הוסיפו את התצוגה (View) או השגרה (או את קבוצת הנתונים כולה כקבוצת נתונים מורשית) לרשימת הגישה המורשית של קבוצת הנתונים של המקור. אם תצוגה שולחת שאילתה לתצוגה אחרת, כל תצוגה בשרשרת צריכה להיות מורשית בקבוצת הנתונים שממנה היא קוראת.

    אם תצוגה מורשית או מערך נתונים מורשה נמחקו, ונוצרו תצוגה או מערך נתונים אחרים עם אותו שם, יכול להיות שהשאילתות ייכשלו עם השגיאה Access Denied. השגיאה הזו יכולה לקרות גם אם השם עדיין מופיע ברשימת הגישה המורשית של מערך הנתונים במקור, שבה רשומות שנמחקו יכולות להישאר עד 24 שעות. בודקים ביומני הביקורת של Cloud אם תצוגה מורשית או מערך נתונים מורשה בשרשרת נמחקו והוחלפו מאז שהשאילתה הצליחה בפעם האחרונה. כדי לשחזר את הגישה, קודם צריך להסיר את הרשומה הקיימת מרשימת הגישה המורשית של מערך הנתונים המקורי, ואז להוסיף מחדש את התצוגה או את מערך הנתונים החדשים. אם תוסיפו את התצוגה החדשה לפני שתסירו את הרשומה הישנה, יכול להיות שתקבלו את השגיאה Duplicate authorized views.

    כדי לשנות תצוגה בלי לפגוע בהרשאה, עדכנו את שאילתת ה-SQL של התצוגה במקום למחוק וליצור אותה מחדש. עם זאת, אם משנים שגרה מורשית באמצעות הצהרת CREATE OR REPLACE או ה-method‏ routines.update, צריך לתת הרשאה מחדש לשגרה.

  • VPC Service Controls. אם הארגון שלכם משתמש ב-VPC Service Controls, בקשות שחוצות את גבולות הגזרה לשירות נכשלות עם השגיאה 403 accessDenied או policyViolation. מחפשים ביומני הביקורת של Cloud את הערך vpcServiceControlsUniqueIdentifier מהודעת השגיאה, בערך בזמן שבו אירע הכשל, ומשתמשים ב-Violation Analyzer כדי לבדוק את כללי התעבורה הנכנסת והיוצאת. כדי להשתמש בשאילתה של Logs Explorer, קראו את המאמר הבקשה אסורה לפי מדיניות הארגון.

  • תפקידים בסיסיים (roles/owner,‏ roles/editor,‏ roles/viewer). תפקידים בסיסיים בפרויקט לא כוללים הרשאות ברמת הארגון שנדרשות לתצוגות כמו INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION, או הרשאות מיוחדות כמו bigquery.rowAccessPolicies.overrideTimeTravelRestrictions, שנדרשות כדי לגשת לנתונים ההיסטוריים של טבלה שיש או שהיו לה כללי מדיניות גישה ברמת השורה (ראו Time Travel וגישה ברמת השורה). להקצות תפקידי IAM מוגדרים מראש ב-BigQuery במקום להסתמך על תפקידים בסיסיים.

  • דריסות זמניות של מדיניות IAM‏ (SetIamPolicy). אם ההרשאות פועלות לסירוגין ואז נכשלות, חפשו את protoPayload.methodName=~"SetIamPolicy" ביומני הביקורת של פעילות האדמין כדי לבדוק אם סקריפט אוטומטי או צינור עיבוד נתונים של תשתית כקוד (IaC) דורסים את קישורי המדיניות הקיימים במקום למזג אותם.

  • מקורות נתונים חיצוניים (Google Drive, ‏ Cloud Storage, ‏ BigLake):

    • ‫Google Drive (Permission denied while getting Drive credentials). צריך לתת למשתמש או לחשבון השירות גישת צפייה בקובץ ב-Google Drive או בגיליון האלקטרוני ב-Google Sheets, לוודא שהגורם ששולח את הקריאה מספק את היקף ההרשאות של OAuth https://www.googleapis.com/auth/drive, או לעדכן את פרטי הכניסה של השאילתה המתוזמנת.
    • טבלאות Cloud Storage ו-BigLake. נותנים למשתמש (בטבלאות חיצוניות רגילות) או לחשבון השירות של החיבור ל-BigLake (בטבלאות BigLake) את ההרשאה roles/storage.objectViewer בקטגוריה של Cloud Storage.

  • מפתחות הצפנה בניהול הלקוח (CMEK). אם השאילתה מפנה לטבלה שמוגנת באמצעות CMEK, ודאו שמפתח Cloud KMS התואם קיים ומופעל. אם שאילתה או משימת טעינה נכשלת עם השגיאה Cloud KMS Error: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied (או useToDecrypt), צריך לתת לסוכן השירות של BigQuery Encryption (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com) את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter במפתח של Cloud Key Management Service. איך נותנים הרשאת הצפנה ופענוח לשגיאות אחרות שקשורות ל-CMEK, קראו את המאמר פתרון בעיות במפתחות הצפנה בניהול הלקוח.

  • התחזות לחשבון שירות. אם בקשה שמשתמשת בהתחזות לחשבון שירות נכשלת עם השגיאה Permission 'iam.serviceAccounts.getAccessToken' denied, צריך לתת לחשבון המשתמש שמבצע את הקריאה את ההרשאה roles/iam.serviceAccountTokenCreator בחשבון השירות שאליו רוצים להתחזות.

  • אבטחה ברמת העמודה (תגי מדיניות) ואבטחה ברמת השורה. אם שאילתה או פקודת DML נכשלת עם Requires fineGrainedGet permission on the read columns או User does not have permission to access data protected by policy tag, צריך להקצות לחשבון המשתמש את התפקיד Fine-Grained Reader‏ (roles/datacatalog.categoryFineGrainedReader) של Data Catalog בתג המדיניות, או להחריג את העמודות המוגנות מהרשימה SELECT. הרשאות לא מספיקות לבקרת גישה ברמת העמודה אם הטבלה משתמשת באבטחה ברמת השורה, בודקים את כללי מדיניות הגישה הפעילים ברמת השורה במסוף Google Cloud או על ידי הפעלת bq ls --row_access_policies. הצגת רשימה של כללי מדיניות הגישה ברמת השורה בטבלה

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

לא אישרת את התנאים וההגבלות של BigQuery

מחרוזת השגיאה: BigQuery Terms of Service have not been accepted

שגיאת ה-HTTP‏ 403 Forbidden‏ (reason: termsOfServiceNotAccepted) מתרחשת כשלא מאשרים את התנאים וההגבלות של BigQuery. השגיאה לא נגרמת בגלל הרשאות IAM חסרות. היא יכולה לחזור בבקשות כמו יצירת קבוצת נתונים או טעינת נתונים.

כדי לפתור את הבעיה:

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

    כניסה ל-BigQuery

  2. אם מופיע דף קבלת פנים, בוחרים את המדינה, מסמנים את תיבת הסימון תנאים והגבלות ולוחצים על Agree and continue. מידע נוסף זמין במאמר הפעלת ארגז החול של BigQuery.

אחרי שמאשרים את התנאים וההגבלות, מנסים שוב לשלוח את הבקשה.

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

אם אתם מקבלים שגיאת HTTP 403 PERMISSION_DENIED ב-BigQuery עם סיבת השגיאה policyViolation, זה מצביע על כשל שנגרם בגלל מדיניות הארגון, גבולות נתונים או VPC Service Controls.

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

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

מחרוזת השגיאה: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

אבחון

הבקשה הגיעה מכתובת רשת או מלקוח שנמצאים מחוץ לגבולות הגזרה של VPC Service Controls, או שהבקשה הפרה את הכללים שהוגדרו לתעבורת נתונים נכנסת ויוצאת בסביבת העבודה. זה קורה לעיתים קרובות כשהשאילתה כוללת כמה פרויקטים. לדוגמה, פרויקט החיוב של השאילתה נמצא מחוץ להיקף האבטחה של פרויקט הנתונים.

רזולוציה

  1. מאתרים את המזהה הייחודי. מאחזרים את ה-vpcServiceControlsUniqueIdentifier שכלול בהודעת השגיאה. אתם יכולים להשתמש במזהה הזה כדי לסנן את Google Cloudב-Logs Explorer, לאתר את היומן התואם של VPC Service Controls ולמצוא את הפרטים של הסיבה:

    protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER"

    מחפשים את הערך violationReason בקטע protoPayload.metadata.violationReason. אחרי שמזהים את הבעיה, קוראים את הפרטים הנוספים ברשומת היומן ופועלים לפי המדריך לפתרון בעיות ב-VPC Service Controls. כדאי גם להשתמש ב-Violation Analyzer.

  2. תיקון החיוב בפרויקטים שונים בשאילתות בין פרויקטים, ודאו שהפרויקט לחיוב שמריץ את השאילתה נמצא באותו היקף כמו הנתונים ששלחתם לגביהם שאילתה בתוך ההיקף. במקרה הצורך, אפשר לציין ידנית פרויקט לחיוב שתואם לדרישות באמצעות הכלי לבחירת פרויקטים במסוף Google Cloud , הדגל --project_id בכלי שורת הפקודה של BigQuery או הבקשה ל-API או לספריית הלקוח.

  3. אימות רמות הגישה. מוודאים שלרשת הלקוח, לכתובת ה-IP או לחשבון המשתמש יש הרשאה באמצעות Access Context Manager. כדי לאפשר למשתמשים לגשת לסביבות מוגנות, צריך להגדיר במסוףGoogle Cloud כללי תעבורת נתונים נכנסת (ingress) ספציפיים.

הייצוא ל-Google Drive חסום בפרויקטים שבהם מופעל VPC Service Controls

מחרוזת השגיאה: Export to Google Drive is blocked for projects with VPC-SC enabled

אבחון

‫Google Drive לא תומך ב-VPC Service Controls. מכיוון שאי אפשר לאכוף את היקף האבטחה ב-Google Drive, כדי למנוע זליגת נתונים, BigQuery משבית באופן אוטומטי את הייצוא של תמציות API ל-Google Drive לכל בקשה שמקורה בגבולות של VPC Service Controls.

רזולוציה

במקום לייצא ישירות ל-Google Drive, חלצו את תוצאות השאילתה לקטגוריה של Cloud Storage שנמצאת באותו מתחם היקפי של VPC Service Controls, או שמרו את התוצאות כקובץ מקומי.

טבלאות חיצוניות של Google Drive חסומות בפרויקטים שבהם מופעל VPC Service Controls

מחרוזת השגיאה: Google Drive external tables are blocked for projects with VPC-SC enabled

אבחון

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

רזולוציה

לייבא את הנתונים מהקובץ ב-Google Sheets או ב-Google Drive ישירות לטבלה רגילה ב-BigQuery בתוך ההיקף של VPC Service Controls, במקום לשלוח שאילתות באופן דינמי כטבלה מאוחדת חיצונית. אפשר גם לפנות לאדמין הפנימי של Cloud כדי לדון בגבולות ייצוא הנתונים של הארגון.

הייצוא ל-Google Drive חסום בפרויקט שלכם

מחרוזת השגיאה: Export to Google Drive is blocked for your project.

אבחון

גם בלי היקף של VPC Service Controls, האדמינים ב- Google Cloud ביקשו להחיל על הפרויקט הגדרה ארגונית ספציפית ומחמירה, שמונעת את כל יכולות חילוץ הנתונים ל-Google Drive.

רזולוציה

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

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

מחרוזת השגיאה: LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID או LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

אבחון

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

  • יצירת מערך נתונים באזור גיאוגרפי לא מורשה (לדוגמה, אזור שמוגבל על ידי constraints/gcp.resourceLocations).
  • ניסיון להשתמש ב-BigQuery Omni בעננים חיצוניים כשהדבר אסור (לדוגמה, חסום על ידי constraints/bigquery.disableBQOmniAWS או constraints/bigquery.disableBQOmniAzure).

רזולוציה

  1. כדי להבין איזו פעולה נחסמת, בודקים את הערך המדויק של CONSTRAINT_NAME שמופיע בהודעת השגיאה.
  2. בוחרים אזור אחר שלא חסום לנתונים, או מבקשים מ-Organization Administrator של הארגון לבדוק את מדיניות הארגון ברמת התיקייה או ברמת הארגון.Google Cloud פרטים נוספים זמינים במאמר הבנייה והגדרה של מיקומי משאבים.

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

כשמקבלים שגיאת HTTP 401 Unauthorized (gRPC UNAUTHENTICATED) ב-BigQuery עם סיבת השגיאה unauthenticated, זה אומר שלבקשה חסרים פרטי כניסה לאימות חוקיים, שתוקף אסימון הגישה של OAuth 2.0 פג או שהגורם ששלח את הבקשה לא יכול לאמת את הזהות שצוינה.

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

פרטי הכניסה לא תקינים או שהתוקף שלהם פג

מחרוזות של שגיאות:

  • Invalid credential
  • User credential was invalid.
  • Credentials expired
  • Credentials missing required scope.
  • Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.

אבחון

פג התוקף של אסימון הגישה, המפתח של חשבון השירות או Application Default Credentials (ADC) שסופקו עם הבקשה, או שהם בוטלו או שחסרים בהם היקפי ההרשאות הנדרשים של OAuth 2.0. השגיאה הזו מתרחשת גם כשהבקשה נחתמת באמצעות שעון מערכת שסטה מהשעה של Network Time Protocol‏ (NTP).

רזולוציה

  • מרעננים את פרטי הכניסה. אם אתם מבצעים אימות מסביבת פיתוח מקומית, הריצו את gcloud auth application-default login (ל-ADC) או את gcloud auth login כדי לקבל אסימון חדש.
  • אימות המפתחות של חשבונות השירות והיקפי ההרשאות של OAuth. אם האפליקציה משתמשת ב-GOOGLE_APPLICATION_CREDENTIALS, ודאו שהמשתנה מפנה לקובץ מפתח JSON תקין שלא בוטל, שחשבון השירות מופעל במסוףGoogle Cloud , ושפרטי הכניסה כוללים את ההיקף הנדרש של https://www.googleapis.com/auth/bigquery או https://www.googleapis.com/auth/cloud-platform.
  • משתמשים בספריות הלקוח הנוכחיות ומסנכרנים את שעוני המערכת. מעדכנים את ספריית הלקוח של BigQuery או את מנהל ההתקן של ODBC או של JDBC לגרסה העדכנית, כדי שרענון האסימונים של OAuth 2.0 ופרטי הכניסה המאוגדים יטופלו באופן אוטומטי. צריך גם לוודא ששעון המערכת של המכונה המארחת מסונכרן באמצעות NTP.

חסרים פרטי כניסה של משתמש בחשבון Google או הרשאת התחזות לחשבון שירות

מחרוזות של שגיאות:

  • Current user can not act as user for service account SERVICE_ACCOUNT_EMAIL
  • No end user credentials found when accessing PROJECT_ID:DATASET_ID.TABLE_ID. Please use end user credentials to call BigQuery APIs.

אבחון

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

רזולוציה

  • מתן הרשאות להתחזות לחשבון שירות כשמריצים שאילתה מתמשכת או משימה שמוגדרת עם חשבון שירות בהתאמה אישית, צריך להקצות לחשבון השירות הזה את התפקיד "משתמש בחשבון שירות" (roles/iam.serviceAccountUser, שכולל את ההרשאה iam.serviceAccounts.actAs). כשמתחזים לחשבון שירות או מחליפים פרטי כניסה מאוחדים באסימון לטווח קצר, צריך להקצות למבצע הקריאה החוזרת את התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator) בחשבון השירות המטורגט.
  • אימות באמצעות פרטי כניסה של משתמש בחשבון Google אם משאב היעד דורש פרטי כניסה של משתמש בחשבון Google, צריך לאמת את הבקשה באמצעות פרטי הכניסה של משתמש אינטראקטיבי ב-OAuth 2.0 (לדוגמה, על ידי הפעלת gcloud auth application-default login או הגדרת OAuth של משתמש בכלי ה-BI), ולא באמצעות פרטי כניסה של חשבון שירות עצמאי.
  • אימות של כללי תעבורת הנתונים הנכנסת והיוצאת של VPC Service Controls אם הבקשה חוצה את הגבולות של VPC Service Controls, צריך לוודא שכללי תעבורת הנתונים הנכנסת והיוצאת של גבולות הגזרה מאפשרים את זהות מבצע הקריאה החוזרת ואת משאב היעד.

החשבון הוגבל, הושעה או נמחק

מחרוזות של שגיאות:

  • The account was restricted due to REASON
  • Account deleted

אבחון

חשבון Google או חשבון Google Workspace שממנו נשלחה הבקשה הושעה, הושבת, הוגבל או נמחק על ידי אדמין או מדיניות אבטחה של החשבון.

רזולוציה

פנו לאדמין ב-Google Workspace או ב-Cloud Identity כדי לבדוק את סטטוס החשבון במסוף Google Admin, לשחזר את חשבון המשתמש או לבטל את ההשעיה שלו, או לעדכן את עומס העבודה כדי לבצע אימות באמצעות חשבון שירות פעיל.

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

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

אני לא רואה את התפקידים של Data Catalog

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

אני לא מצליח/ה לראות את הדף "טקסונומיות"

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

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

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

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

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

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

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

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

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

  • מוודאים שהשאילתות לא משתמשות בתוצאות של שאילתות שנשמרו במטמון. אם אתם משתמשים בכלי שורת הפקודה של 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.

פתרון בעיות בתגי משילות מידע (data governance)

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

שמות תגים בפורמט שגוי

כשיוצרים תגים, מגדירים שם מקוצר (לדוגמה, ssn). עם זאת, כשמצרפים תגים לעמודות בסכימה או משתמשים בהם בתנאים, מפתח התג חייב להשתמש בפורמט של מרחב השמות (PROJECT_ID/TAG_KEY או ORGANIZATION_ID/TAG_KEY), בעוד שערך התג עדיין משתמש בשם המקוצר. אם תספקו רק את השם המקוצר של מפתח התג, תופיע השגיאה Invalid tagKey או Invalid tagValue.

החלת מדיניות על כמה פרויקטים

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

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

ברשימה הבאה מתוארות שגיאות נפוצות והפתרונות המומלצים כשמשתמשים במפתחות הצפנה בניהול הלקוח (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
פתרון: השגיאה הזו יכולה להתרחש כשהגדרות ההצפנה של טבלת היעד לא תואמות להגדרות ההצפנה בבקשה. כדי לפתור את הבעיה, צריך להשתמש ב-write disposition של TRUNCATE כדי להחליף את הטבלה, או לציין טבלת יעד אחרת.
שגיאה: 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.

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