אימות היקף מוגבל

בחלק מממשקי ה-API של Google (אלה שמקבלים היקפי הרשאות רגישים או מוגבלים ) יש דרישות לגבי אפליקציות שמבקשות הרשאה לגשת לנתוני צרכנים. בהתאם לדרישות הנוספות האלה להיקפים מוגבלים, האפליקציה צריכה להוכיח שמדובר באפליקציה מסוג מותר ולשלוח אותה לבדיקות נוספות, כולל בדיקת אבטחה אפשרית.

הרלוונטיות של היקפים מוגבלים ב-API תלויה בעיקר ברמת הגישה שנדרשת כדי לספק תכונה רלוונטית באפליקציה: קריאה בלבד, כתיבה בלבד, קריאה וכתיבה וכו'.

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

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

הסבר על היקפים מוגבלים

אם האפליקציה שלך מבקשת היקפים מוגבלים ולא עומדת בדרישות להחרגה, עליך לעמוד בדרישות הנוספות של היקפי API ספציפיים במדיניות בנושא נתוני משתמשים בשירותי Google API, או בדרישות הספציפיות למוצר בדף Google Developers של המוצר, שדורש תהליך בדיקה מקיף יותר.

הסבר על השימוש בהיקף

  • בודקים את ההיקפים שבהם האפליקציה משתמשת או שרוצים להשתמש בה. כדי לברר מהו השימוש הנוכחי שלך בהיקף, יש לבדוק את קוד המקור של האפליקציה ולחפש היקפים שנשלחו עם בקשות הרשאה.
  • לוודא שכל היקף ההרשאות המבוקש נדרש עבור הפעולות הרצויות של התכונה באפליקציה, ושהוא משתמש בהרשאה המינימלית הנדרשת כדי לספק את התכונה. בדרך כלל, ב דף של Google Developers של המוצר ב-Google API מופיעים המסמכים שמתייחסים לנקודות הקצה של המוצר, שכוללים את ההיקף שנדרש כדי לקרוא לנקודת הקצה או לנכסים ספציפיים שכלולים בה. כדי לקבל מידע נוסף על היקפי הגישה הנדרשים לנקודות הקצה של ה-API שהאפליקציה שלך מפעילה, אפשר לקרוא את מסמכי התיעוד של נקודות הקצה האלה. For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
  • יש להשתמש בנתונים שהתקבלו מ-Google API אך ורק בהתאם למדיניות של ה-API ובהתאם לאופן שבו את/ה מייצג/ת את המשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלך.
  • במסמכי התיעוד של ה-API ניתן לקבל מידע נוסף על כל היקף, כולל הסטטוס sensitive or restricted הפוטנציאלי שלו.
  • יש להצהיר על כל ההיקפים שהאפליקציה משתמשת בהם בדף היקפי ההגדרות של API Console מסך ההסכמה של OAuth. היקפי ההרשאות שציינת מקובצים לפי קטגוריות רגישות או מוגבלות כדי להדגיש את הצורך לבצע אימות נוסף.
  • צריך למצוא את ההיקף המתאים ביותר לנתונים המשמשים את השילוב, להבין את אופן השימוש בו, לוודא שהכול עדיין פועל בסביבת הבדיקה ולהתכונן לשליחה לאימות.

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

סוגי הבקשות המותרים

לחלק מסוגי האפליקציות יש גישה להיקפים מוגבלים של כל מוצר. אפשר למצוא את סוגי האפליקציות בדף Google Developer הספציפי (לדוגמה, במדיניות Gmail API).

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

הערכת אבטחה

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

כדי לבצע סטנדרטיזציה של בדיקת האבטחה, אנחנו משתמשים ב- App Defense Alliance וב מסגרת הערכת האבטחה של אפליקציות בענן (CASA).

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

צוות הבדיקה של Google שולח לך אימייל כשיגיע הזמן לחדש את האישור של האפליקציה. כדי לוודא שהצוות המתאים יקבל הודעה על האכיפה השנתית הזו, עליך לשייך חשבונות Google נוספים לפרויקט API Console כבעלים או כעורך. היא גם עוזרת לשמור על העדכניות של פרטי התמיכה למשתמשים ובאימיילים ליצירת קשר עם המפתחים שצוינו ב- API Console OAuth Consent Screen page.

איך מתכוננים לאימות

כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים חייבות לבצע את השלבים הבאים כדי להשלים את אימות המותג:

  1. מוודאים שהאפליקציה לא משתייכת לאף אחד ממקרי השימוש בקטע חריגים לדרישות האימות.
  2. יש לוודא שהאפליקציה עומדת בדרישות המיתוג של ממשקי ה-API או המוצר המשויכים. לדוגמה, כדאי לעיין בהנחיות המיתוג להיקפים של כניסה באמצעות חשבון Google.
  3. מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. צריך להשתמש בחשבון Google שמשויך לפרויקט API Console בתור בעלים או עורך.
  4. יש לוודא שכל פרטי המיתוג במסך ההסכמה של OAuth, כמו שם האפליקציה, אימייל תמיכה, URI של דף הבית, URI של מדיניות הפרטיות וכו', מייצגים את הזהות של האפליקציה באופן מדויק.

דרישות לגבי דף הבית של האפליקציה

צריך לוודא שדף הבית עומד בדרישות הבאות:

  • דף הבית שלך חייב להיות נגיש לציבור, ולא נגיש רק למשתמשים שמחוברים לאתר שלך.
  • הרלוונטיות של דף הבית לאפליקציה שנמצאת בבדיקה חייבת להיות ברורה.
  • קישורים לדף האפליקציה בחנות Google Play או בדף ה-Facebook שלה לא נחשבים לדפי בית חוקיים של האפליקציה.

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

ודאו שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:

  • מדיניות הפרטיות חייבת להיות גלויה למשתמשים, שמתארחת באותו דומיין שבו מתארח דף הבית של האפליקציה שלך, ומקושרת אליו במסך ההסכמה של OAuth של Google API Console. לתשומת ליבך, דף הבית חייב לכלול תיאור של פונקציונליות האפליקציה, כמו גם קישורים למדיניות הפרטיות ולתנאים והגבלות אופציונליים.
  • מדיניות הפרטיות חייבת לכלול גילוי נאות לגבי האופן שבו האפליקציה ניגשת לנתוני משתמש ב-Google, משתמשת בהם, מאחסנת או משתפת אותם. The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. חובה להגביל את השימוש בנתוני המשתמשים ב-Google רק לשיטות המפורטות במדיניות הפרטיות שפורסמה.
  • Review example cases of privacy policies that don't meet the Limited Use requirements.

איך לשלוח את האפליקציה לאימות

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

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

כך שולחים בקשה לאימות:

  1. יש לוודא שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs והמדיניות בנושא נתוני משתמשים בשירותי Google API.
  2. צריך לוודא שתפקידי הבעלים והעריכה של החשבונות המשויכים לפרויקט יהיו עדכניים, כמו גם האימייל לגבי תמיכת המשתמשים במסך ההסכמה ל-OAuth והפרטים ליצירת קשר עם המפתח, במסגרת API Console. כך החברים הנכונים בצוות שלך יקבלו הודעה על כל דרישה חדשה.
  3. עוברים אל API Console OAuth Consent Screen page.
  4. לוחצים על הלחצן בורר הפרויקטים.

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

    https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

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

  6. לוחצים על הלחצן עריכת האפליקציה.
  7. מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth ולוחצים על הלחצן Save and continue (שמירה והמשך).
  8. יש ללחוץ על הלחצן הוספה או הסרה של היקפי הרשאות כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. בקטע היקפים לא רגישים, המערכת תמלא מראש קבוצה של היקפים שנחוצים לכניסה באמצעות חשבון Google. היקפי הרשאות שנוספו מסווגים כלא רגישים, sensitive, or restricted.
  9. יש לספק עד שלושה קישורים לכל תיעוד רלוונטי לגבי תכונות קשורות באפליקציה.

  10. בשלבים הבאים, צריך לספק כל מידע נוסף שנדרש לגבי האפליקציה.

    1. Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.

    4. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
      5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
  11. אם הגדרת האפליקציה שסיפקת דורשת אימות, יש לך אפשרות לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על Submit כדי להתחיל את תהליך האימות.

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

חריגים לדרישות האימות

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

שימוש אישי

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

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

כדי לציית למדיניות OAuth 2.0 של Google, מומלץ ליצור פרויקטים שונים לסביבות בדיקה וייצור. מומלץ לשלוח את האפליקציה לאימות רק אם ברצונך שהאפליקציה תהיה זמינה לכל משתמש שיש לו חשבון Google. לכן, אם האפליקציה שלך בשלבי פיתוח, בדיקה או Staging, לא נדרש אימות.

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

הודעת אזהרה על כך ש-Google לא אימתה אפליקציה שנמצאת בבדיקה.
איור 1. מסך האזהרה של הבודקים

נתונים בבעלות השירות בלבד

אם האפליקציה משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ואין לה גישה לנתוני משתמש (המקושרים לחשבון Google), אין צורך לשלוח בקשה לאימות.

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

שימוש פנימי בלבד

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

התקנה ברמת הדומיין

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

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