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

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

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

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

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

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

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

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

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

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

סוגי האפליקציות המותרים

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

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

הערכת אבטחה

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

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

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

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

שלבים להכנה לאימות

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

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

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

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

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

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

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

  • מדיניות הפרטיות חייבת להיות גלויה למשתמשים, להתארח באותו דומיין שבו מתארח דף הבית של האפליקציה, ולכלול קישור למסך ההסכמה של OAuth ב- . לתשומת ליבכם: דף הבית חייב לכלול תיאור של הפונקציונליות של האפליקציה, וכן קישורים למדיניות הפרטיות ולתנאים וההגבלות האופציונליים.
  • במדיניות הפרטיות צריך לפרט את האופן שבו האפליקציה ניגשת לנתוני המשתמשים ב-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 שמופעלים ומגדרות החיוב, האימות והמעקב של ממשקי ה-API האלה. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש של הלקוחות האלה ולהגדיר מסך הסכמה ל-OAuth שמוצג למשתמשים לפני שהם נותנים הרשאת גישה לאפליקציה.

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

כדי לשלוח את הבקשה לאימות, פועלים לפי השלבים הבאים:

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

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

    ?project=[PROJECT_ID]

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

  6. לוחצים על הלחצן עריכת האפליקציה.
  7. מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth, ואז לוחצים על הלחצן שמירה והמשך.
  8. לוחצים על הלחצן Add or remove scopes (הוספה או הסרה של היקפים) כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. קבוצה ראשונית של היקפים שנדרשים לכניסה באמצעות חשבון Google מולאו מראש בקטע Non-sensitive scopes (היקפים לא רגישים). היקפים שנוספו מסווגים כ'לא רגישים', 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. אם הגדרות האפליקציה שסיפקתם מחייבות אימות, תוכלו לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל את תהליך האימות.

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

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

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

שימוש אישי

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

פרויקטים שמשמשים בשכבות הפיתוח, הבדיקה או ההרצה

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

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

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

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

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

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

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

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

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

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

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