ממשקי Google API מסוימים (אלה שמקבלים היקפים רגישים או מוגבלים ) כוללים דרישות לאפליקציות שמבקשות הרשאה לגשת לנתוני צרכנים. הדרישות הנוספות האלה להיקפי הרשאה מוגבלים מחייבות את האפליקציה להוכיח שהיא סוג אפליקציה מותר, ולעבור בדיקות נוספות, כולל הערכת אבטחה אפשרית.
ההתאמה של היקפי הרשאות מוגבלים ב-API תלויה בעיקר ברמת הגישה שנדרשת כדי לספק תכונה רלוונטית באפליקציה: קריאה בלבד, כתיבה בלבד, קריאה וכתיבה וכו'.
כשמשתמשים ב-OAuth 2.0 כדי לקבל הרשאה מחשבון Google לגשת לנתונים האלה, משתמשים במחרוזות שנקראות היקפי הרשאות כדי לציין את סוג הנתונים שרוצים לגשת אליהם ואת רמת הגישה שצריך. אם האפליקציה שלכם מבקשת היקפים רגישים או מוגבלים, אתם צריכים להשלים את תהליך האימות, אלא אם השימוש באפליקציה עומד בדרישות ל חריגה.
מספר ההיקפים המוגבלים קטן ממספר ההיקפים הרגישים. במאמר שאלות נפוצות בנושא אימות אפליקציות באמצעות OAuth API מפורטת הרשימה העדכנית של היקפי הרשאות רגישים ומוגבלים. היקפי ההרשאות האלה מספקים גישה רחבה לנתוני משתמשים ב-Google, ולכן צריך לעבור תהליך אימות של היקפי ההרשאות לפני שמבקשים אותם מחשבון Google כלשהו. מידע על הדרישה הזו מופיע במדיניות של Google בנושא נתוני משתמשים בשירותי API, בדרישות נוספות להיקפי הרשאות ספציפיים של API או בדף המפתחים של Google שספציפי למוצר. אם אתם מאחסנים או מעבירים נתונים בהיקף מוגבל בשרתים, אתם צריכים להשלים בדיקת אבטחה.
הסבר על היקפים מוגבלים
אם האפליקציה שלכם מבקשת הרשאות גישה מוגבלות ולא עומדת בדרישות לקבלת חריגה, אתם צריכים לעמוד בדרישות הנוספות להרשאות גישה ספציפיות ל-API של מדיניות Google API Services User Data (נתוני משתמשים בשירותי Google API), או בדרישות ספציפיות למוצר שמופיעות בדף המפתחים של Google של המוצר. במקרים כאלה נדרש תהליך בדיקה מקיף יותר.
הסבר על השימוש בהיקף
- בודקים את היקפי ההרשאות שבהם האפליקציה משתמשת או שרוצים שהיא תשתמש בהם. כדי לראות את השימוש בהיקפים הקיימים, בודקים את קוד המקור של האפליקציה כדי לראות אילו היקפים נשלחים עם בקשות הרשאה.
- צריך לוודא שכל היקף הרשאה שנדרש נחוץ לפעולות המיועדות של תכונת האפליקציה, ושהאפליקציה משתמשת בהרשאות המינימליות שנדרשות כדי לספק את התכונה. לממשקי API של Google יש בדרך כלל מסמכי עזר ב דף המפתחים של 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
- מצהירים על כל ההיקפים שבהם נעשה שימוש באפליקציה בדף גישה לנתונים ב-Cloud Console. ההיקפים שאתם מציינים מקובצים לקטגוריות רגישות או מוגבלות כדי להדגיש אם נדרש אימות נוסף.
- כדאי למצוא את ההיקף הכי מתאים לנתונים שמשמשים את השילוב, להבין איך הוא משמש אתכם, לוודא שהכול עדיין פועל בסביבת בדיקה ולהתכונן לשליחה לאימות.
חשוב לכלול בתוכנית ההשקה של האפליקציה או של תכונות חדשות שדורשות היקף חדש את הזמן שנדרש להשלמת האימות. אחת מהדרישות הנוספות האלה מתרחשת אם האפליקציה ניגשת לנתוני משתמשים ב-Google משרת או דרך שרת, או שיש לה אפשרות לגשת לנתונים האלה. במקרים האלה, המערכת צריכה לעבור בדיקת אבטחה שנתית על ידי בודק עצמאי מצד שלישי שאושר על ידי Google. לכן, תהליך האימות של היקפי הגישה המוגבלים עשוי להימשך כמה שבועות. שימו לב: כל האפליקציות צריכות להשלים קודם את שלב אימות המותג, שנמשך בדרך כלל 2-3 ימי עסקים, אם פרטי המיתוג השתנו מאז האימות האחרון של מסך הסכמה ל-OAuth שאושר.
סוגי האפליקציות המותרים
סוגים מסוימים של אפליקציות יכולים לגשת להיקפי הרשאות מוגבלים לכל מוצר. סוגי הבקשות מפורטים בדף למפתחים של Google שספציפי למוצר (לדוגמה, המדיניות של Gmail API).
באחריותכם להבין ולקבוע את סוג האפליקציה. עם זאת, אם אתם לא בטוחים לגבי סוג האפליקציה, אתם יכולים לא לבחור אף אפשרות לשאלה באילו תכונות תשתמש? כשאתם שולחים את האפליקציה לאימות. צוות האימות של Google API יקבע את סוג הבקשה.
הערכת אבטחה
כל אפליקציה שמבקשת גישה לנתונים מוגבלים של משתמשי Google ויש לה אפשרות לגשת לנתונים משרת צד שלישי או דרכו, חייבת לעבור בדיקת אבטחה על ידי מעריכי אבטחה שמוסמכים על ידי Google. ההערכה הזו עוזרת לשמור על בטיחות הנתונים של משתמשי Google. היא מאמתת שכל האפליקציות שיש להן גישה לנתוני משתמשי Google מסוגלות לטפל בנתונים בצורה מאובטחת ולמחוק נתוני משתמשים לפי בקשת המשתמש.
כדי ליצור סטנדרטיזציה של הערכת האבטחה, אנחנו משתמשים ב- App Defense Alliance וב- cloud application security assessment framework (CASA).
כמו שצוין קודם, כדי לשמור על הגישה להיקפים מוגבלים מאומתים, האפליקציות צריכות לעבור אימות מחדש לצורך עמידה בדרישות ולהשלים הערכת אבטחה לפחות כל 12 חודשים אחרי תאריך האישור של מכתב ההערכה (LOA) של המעריך. אם האפליקציה מוסיפה היקף חדש של הרשאות מוגבלות, יכול להיות שיהיה צורך להעריך מחדש את האפליקציה כדי לכסות את היקף ההרשאות הנוסף, אם הוא לא נכלל בהערכת אבטחה קודמת.
צוות הבדיקה של Google ישלח לכם אימייל כשיגיע הזמן לחדש את האישור של האפליקציה. כדי לוודא שהחברים הנכונים בצוות שלכם יקבלו הודעה על האכיפה השנתית הזו, צריך לשייך לחשבונות Google נוספים לפרויקט שלכם ב-Cloud Console בתור בעלים או עורכים. בנוסף, הוא עוזר לעדכן את כתובות האימייל של תמיכת המשתמשים ואת פרטי הקשר של המפתחים שמופיעים בדף המיתוג של OAuth ב-מסוף Google Cloud.
שלבים להכנה לאימות
כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים צריכות לבצע את השלבים הבאים כדי להשלים את אימות המותג:
- חשוב לוודא שהאפליקציה לא נכללת באף אחד מתרחישי השימוש שמפורטים בקטע חריגים לדרישות האימות.
- צריך לוודא שהאפליקציה עומדת בדרישות המיתוג של ממשקי ה-API או המוצר המשויכים. לדוגמה, אפשר לעיין בהנחיות המיתוג בנושא היקפי הרשאות של כניסה באמצעות חשבון Google.
- מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. משתמשים בחשבון Google שמקושר לפרויקט ב-קונסולה לממשקי API בתור בעלים או עורך.
- חשוב לוודא שכל פרטי המיתוג במסך ההסכמה ל-OAuth, כמו שם האפליקציה, כתובת האימייל לתמיכה, ה-URI של דף הבית, ה-URI של מדיניות הפרטיות וכו', משקפים בצורה מדויקת את הזהות של האפליקציה.
הדרישות לגבי דף הבית של האפליקציה
חשוב לוודא שדף הבית עומד בדרישות הבאות:
- דף הבית של האתר חייב להיות נגיש לכולם, ולא רק למשתמשים שמחוברים לאתר.
- הרלוונטיות של דף הבית לאפליקציה שנמצאת בבדיקה צריכה להיות ברורה.
- קישורים לדף האפליקציה בחנות Google Play או לדף שלה בפייסבוק לא נחשבים לדפי בית תקפים של אפליקציה.
דרישות לגבי קישור למדיניות הפרטיות של האפליקציה
צריך לוודא שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות צריכה להיות גלויה למשתמשים, להתארח באותו דומיין כמו דף הבית של האפליקציה שלכם, ולקשר למסך ההסכמה ל-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 Cloud מארגן את כל המשאבים שלכם במסוף Cloud. פרויקט מורכב מקבוצה של חשבונות Google משויכים שיש להם הרשאה לבצע פעולות בפרויקט, מקבוצה של ממשקי API מופעלים ומקבוצה של הגדרות חיוב, אימות ומעקב לאותם ממשקי API. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש על ידי הלקוחות האלה ולהגדיר מסך הסכמה ל-OAuth שמוצג למשתמשים לפני שהם מאשרים גישה לאפליקציה שלכם.
אם יש לקוחות OAuth שלא מוכנים לסביבת הייצור, מומלץ למחוק אותם מהפרויקט שבו מתבצעת הבקשה לאימות. אפשר לעשות זאת בדף הלקוחות.
כדי לשלוח את הבקשה לאימות, פועלים לפי השלבים הבאים:
- חשוב לוודא שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs ושל המדיניות של Google בנושא נתוני משתמשים בשירותי API.
- חשוב לוודא שתפקידי 'בעלים' ו'עריכה' בחשבונות המשויכים לפרויקט מעודכנים, וגם כתובת האימייל לתמיכה במשתמשים ופרטי הקשר של המפתח במסך ההסכמה ל-OAuth במסוף Cloud. כך אפשר לוודא שהחברים המתאימים בצוות שלכם יקבלו הודעה על כל דרישה חדשה.
- עוברים אל Cloud Console OAuth Verification Center.
- לוחצים על הלחצן Project selector (בורר הפרויקטים).
-
בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים מה מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שרוצים להשתמש בו.
- לוחצים על הלחצן עריכת האפליקציה.
- מזינים את המידע הנדרש בדף מסך הסכמה ל-OAuth ולוחצים על הלחצן שמירה והמשך.
- משתמשים בלחצן הוספה או הסרה של היקפים כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. קבוצה ראשונית של היקפים שנדרשים לכניסה באמצעות חשבון Google מאוכלסת מראש בקטע היקפים לא רגישים. ההיקפים שנוספו מסווגים כלא רגישים, sensitive, or restricted.
- צריך לספק עד שלושה קישורים לתיעוד רלוונטי של תכונות קשורות באפליקציה.
-
בשלבים הבאים תתבקשו לספק מידע נוסף על האפליקציה.
- 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.
- Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
- 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.
-
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.
- 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.
- Show that the OAuth consent screen correctly displays the App Name.
- Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
- To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
- If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
- Select your permitted application type from the "What features will you use?" list.
- Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
- אם הגדרת האפליקציה שסיפקתם דורשת אימות, תוכלו לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל את תהליך האימות.
אחרי ששולחים את האפליקציה, הצוות של Google לנושאי מהימנות ובטיחות (T&S) שולח אימייל עם מידע נוסף שנדרש או עם שלבים שצריך לבצע. כדי לראות אם קיבלת בקשות למידע נוסף, כדאי לבדוק את כתובות האימייל שלך בקטע פרטים ליצירת קשר עם המפתח ואת כתובת האימייל לתמיכה במסך ההסכמה ל-OAuth. אפשר גם לעבור לדף מסך ההסכמה ל-OAuth בפרויקט כדי לראות את סטטוס הבדיקה הנוכחי של הפרויקט, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו מחכים לתגובה שלכם.
חריגים לדרישות האימות
אם האפליקציה שלכם תשמש באחד מהתרחישים שמתוארים בקטעים הבאים, לא צריך לשלוח אותה לבדיקה.
שימוש אישי
תרחיש שימוש אחד הוא אם אתם המשתמשים היחידים באפליקציה שלכם או אם רק כמה משתמשים משתמשים באפליקציה, וכולם מוכרים לכם באופן אישי. יכול להיות שאתם ומספר מצומצם של משתמשים תרגישו בנוח להמשיך למסך של האפליקציה הלא מאומתת ולתת לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שמשמשים ברמות פיתוח, בדיקה או הכנה להשקה
כדי לפעול בהתאם למדיניות OAuth 2.0 של Google, מומלץ להשתמש בפרויקטים שונים לסביבות בדיקה וייצור. מומלץ לשלוח את האפליקציה לאימות רק אם רוצים שהיא תהיה זמינה לכל משתמש עם חשבון Google. לכן, אם האפליקציה שלכם נמצאת בשלבי פיתוח, בדיקה או הכנה, לא נדרש אימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את סטטוס הפרסום בהגדרת ברירת המחדל בדיקה. ההגדרה הזו מציינת שהאפליקציה עדיין בפיתוח וזמינה רק למשתמשים שאתם מוסיפים לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמשתתפים בפיתוח או בבדיקה של האפליקציה.
רק נתונים בבעלות השירות
אם האפליקציה שלכם משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ולא ניגשת לנתונים של משתמשים (שמקושרים לחשבון Google), אתם לא צריכים לשלוח אותה לאימות.
כדי להבין מהם חשבונות שירות, אפשר לעיין במאמר בנושא חשבונות שירות במסמכי Google Cloud. הוראות לשימוש בחשבון שירות מופיעות במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת.
לשימוש פנימי בלבד
המשמעות היא שרק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity יכולים להשתמש באפליקציה. הפרויקט צריך להיות בבעלות הארגון, ומסך ההסכמה ל-OAuth צריך להיות מוגדר עבור משתמש פנימי. במקרה כזה, יכול להיות שהאדמין של הארגון יצטרך לאשר את האפליקציה. מידע נוסף זמין במאמר שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על אפליקציות ציבוריות ופנימיות
- במאמר השאלות הנפוצות מוסבר איך לסמן את האפליקציה כפנימית איך אפשר לסמן את האפליקציה כפנימית בלבד?
התקנה ברמת הדומיין
אם אתם מתכננים שהאפליקציה שלכם תפנה רק למשתמשים בארגון Google Workspace או Cloud Identity ותמיד תשתמשו בהתקנה בכל הדומיין, לא תצטרכו לאמת את המותג שלכם. עם זאת, אם האפליקציה משתמשת בהיקפים מוגבלים או רגישים, נדרש אימות האפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת לאדמין בדומיין להעניק לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתונים של המשתמשים. רק אדמינים בארגון יכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.
במאמר בנושא שאלות נפוצות מוסבר איך להפוך את האפליקציה להתקנה בכל הדומיין באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace.