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

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

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

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

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

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

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

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

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

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

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

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

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

הערכת אבטחה

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

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

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

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

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

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

   ?project=[PROJECT_ID]

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

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

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

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

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

שימוש אישי

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

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

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

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

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

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

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

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

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

• מידע נוסף על ציבוריים וגם לשימוש פנימי.
• בשאלות הנפוצות מוסבר איך לסמן את האפליקציה כפנימית איך מסמנים את האפליקציה בתור לשימוש פנימי בלבד?

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

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

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