לממשקי Google API מסוימים (אלה שמקבלים היקפי הרשאות רגישים או מוגבלים) יש דרישות לגבי אפליקציות שמבקשות הרשאה לגשת לנתוני צרכנים. הדרישות הנוספות האלה לגבי היקפי הרשאות מוגבלים מחייבות את מפתחי האפליקציה להוכיח שהאפליקציה שלהם היא מסוג מותר, ולשלוח אותה לבדיקות נוספות, כולל הערכת אבטחה אפשרית.
ההתאמה של היקפים מוגבלים ב-API תלויה בעיקר ברמת הגישה שנדרשת כדי לספק תכונה רלוונטית באפליקציה: לקריאה בלבד, לכתיבה בלבד, לקריאה ולכתיבה וכו'.
כשמשתמשים ב-OAuth 2.0 כדי לקבל הרשאה מחשבון Google לגשת לנתונים האלה, משתמשים במחרוזות שנקראות היקפים כדי לציין את סוג הנתונים שאליהם רוצים לגשת ואת רמת הגישה הנדרשת. אם האפליקציה מבקשת היקפי הרשאות רגישים או מוגבלים, צריך להשלים את תהליך האימות, אלא אם השימוש באפליקציה עומד בתנאים להחרגה.
יש פחות היקפי הרשאות מוגבלים מאשר היקפי הרשאות רגישים. בשאלות הנפוצות בנושא אימות OAuth API מופיעה הרשימה הנוכחית של היקפי ההרשאות הרגישים והמוגבלים. ההיקפים האלה מספקים גישה רחבה לנתוני המשתמשים ב-Google, וצריך לעבור תהליך אימות של ההיקפים לפני שמבקשים אותם מחשבון Google כלשהו. מידע נוסף על הדרישה הזו זמין במאמרים מדיניות נתוני המשתמשים בשירותי Google API ודרישות נוספות להיקפי הרשאות ספציפיים של API או בדף המפתחים של Google הספציפי למוצר. אם אתם מאחסנים או מעבירים נתונים בהיקף מוגבל בשרתים, אתם צריכים להשלים הערכת אבטחה.
הסבר על היקפים מוגבלים
אם האפליקציה מבקשת היקפים מוגבלים כלשהם ולא עומדת בדרישות להחרגה, צריך לעמוד בדרישות הנוספות להיקפי API ספציפיים של מדיניות Google API Services בנושא נתוני משתמשים, או בדרישות הספציפיות למוצר שמופיעות בדף Google Developers של המוצר, שמחייבות תהליך בדיקה מקיף יותר.
הסבר על השימוש בהיקפים
- בודקים את היקפי ההרשאות שהאפליקציה משתמשת בהם או שאתם רוצים להשתמש בהם. כדי למצוא את היקפי ההרשאות הקיימים, בודקים את קוד המקור של האפליקציה ומחפשים היקפי הרשאות שנשלחו עם בקשות הרשאה.
- לוודא שכל היקף הרשאות שביקשתם נחוץ לפעולות המיועדות של התכונה באפליקציה, ושהוא משתמש בהרשאות המינימליות שנדרשות כדי לספק את התכונה. ל-Google API יש בדרך כלל מאמרי עזרה בדף Google Developer של המוצר, שכוללים את נקודות הקצה ואת ההיקף שנדרש כדי לקרוא לנקודת הקצה או למאפיינים ספציפיים בתוכה. למידע נוסף על היקפי הגישה הנדרשים לנקודות הקצה ל-API שהאפליקציה קוראת להן, קראו את מאמרי העזרה של נקודות הקצה האלה. לדוגמה, אם האפליקציה משתמשת בממשקי Gmail API רק כדי לשלוח מדי פעם אימיילים בשם המשתמש, אל תבקשו את היקף ההרשאות שנותן גישה מלאה לנתוני האימייל של המשתמש.
- מותר להשתמש בנתונים שמתקבלים מ-Google API רק בהתאם למדיניות של ה-API, ובאופן שמוצג למשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלה.
- במאמרי העזרה של ה-API מוסבר על כל היקף הרשאות, כולל הסטטוס שלו כרגיש או מוגבל.
- מצהירים על כל היקפי ההרשאות שהאפליקציה משתמשת בהם בדף Data Access במסוף Cloud. היקפי ההרשאות שאתם מציינים מקובצים לקטגוריות רגישות או קטגוריות מוגבלות, כדי להדגיח אם נדרש אימות נוסף.
- מוצאים את ההיקף שהכי מתאים לנתונים שבהם משתמשים בשילוב, מבינים את השימוש בו, מוודאים שהכול עדיין פועל בסביבת בדיקה ואז מתכוננים לשליחה לאימות.
חשוב להביא בחשבון את הזמן שנדרש להשלמת האימות בתוכנית ההשקה של האפליקציה או של תכונות חדשות שדורשות היקף חדש. אחת מהדרישות הנוספות האלה חלה אם האפליקציה ניגשת לנתוני משתמשים ב-Google משרת או דרך שרת, או אם יש לה את היכולת לגשת אליהם. במקרים כאלה, המערכת צריכה לעבור הערכת אבטחה שנתית על ידי מעריך עצמאי מצד שלישי שאושר על ידי Google. לכן, תהליך האימות של היקפי הרשאות מוגבלים עשוי להימשך כמה שבועות. שימו לב: אם פרטי המיתוג השתנו מאז האימות האחרון שאושר של מסך ההסכמה ב-OAuth, קודם כל צריך להשלים את שלב אימות המותג בכל האפליקציות. בדרך כלל התהליך נמשך 2-3 ימי עסקים.
סוגי האפליקציות המותרים
סוגים מסוימים של אפליקציות יכולים לגשת להיקפים מוגבלים בכל מוצר. סוגי האפליקציות מפורטים בדף המפתחים של Google למוצר הספציפי (לדוגמה, המדיניות של Gmail API).
באחריותכם להבין ולקבוע את סוג הבקשה שלכם. עם זאת, אם אתם באמת לא בטוחים מהו סוג האפליקציה שלכם, אתם יכולים לא לבחור אף אפשרות לשאלה באילו תכונות תשתמשו? כשאתם שולחים את האפליקציה לאימות. צוות האימות של Google API יקבע את סוג האפליקציה.
הערכת האבטחה
כל אפליקציה שמבקשת גישה לנתונים מוגבלים של משתמשי Google ויכולה לגשת לנתונים משרת של צד שלישי או דרכו, חייבת לעבור הערכת אבטחה על ידי מעריכי אבטחה שמונו על ידי Google. ההערכה הזו עוזרת לשמור על בטיחות הנתונים של משתמשי Google, על ידי אימות שכל האפליקציות שניגשות לנתוני משתמשים של Google יכולות לטפל בנתונים בצורה מאובטחת ולמחוק נתוני משתמשים לפי בקשת המשתמש.
כדי ליצור סטנדרט להערכת האבטחה, אנחנו משתמשים ב-App Defense Alliance וב-cloud application security assessment framework (CASA).
כמו שציינו קודם, כדי לשמור על הגישה להיקפים מוגבלים מאומתים, צריך לאמת מחדש את האפליקציות כדי לוודא שהן עומדות בדרישות, ולבצע הערכת אבטחה לפחות כל 12 חודשים אחרי תאריך האישור של מכתב ההערכה (LOA) של הגורם המעריך. אם האפליקציה מוסיפה היקף הרשאות מוגבל חדש, יכול להיות שיהיה צורך לבדוק אותה מחדש כדי לכסות את ההיקף הנוסף, אם הוא לא נכלל בהערכת אבטחה קודמת.
צוות הבדיקה של Google ישלח לכם אימייל כשיגיע הזמן לאשר מחדש את האפליקציה. כדי לוודא שחברי הצוות הרלוונטיים יקבלו הודעה על האכיפה השנתית הזו, שייכו חשבונות Google נוספים לפרויקט במסוף Cloud בתפקיד בעלים או עורך. כדאי גם לעדכן את כתובות האימייל ליצירת קשר עם המפתחים ועם התמיכה במשתמשים, שמצוינות בדף המיתוג של OAuth במסוף Google Cloud.
איך להתכונן לאימות
כדי להשלים את תהליך אימות המותג, כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים צריכות לבצע את הפעולות הבאות:
- מוודאים שהאפליקציה לא נכללת באף אחד מתרחישי השימוש שמפורטים בקטע חריגים לדרישות האימות.
- חשוב לוודא שהאפליקציה עומדת בדרישות לגבי מותגים של ממשקי ה-API או המוצר המשויכים. לדוגמה, אפשר לעיין בהנחיות המיתוג להיקפי ההרשאות של כניסה באמצעות חשבון Google.
- מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. משתמשים בחשבון Google שמשויך לפרויקט ב-קונסולה לממשקי API כבעלים או כעורכים.
- חשוב לוודא שכל פרטי המיתוג במסך ההסכמה של OAuth, כמו שם האפליקציה, כתובת האימייל לתמיכה, ה-URI של דף הבית, ה-URI של מדיניות הפרטיות וכו', מייצגים בצורה מדויקת את זהות האפליקציה.
הדרישות לגבי דף הבית של האפליקציה
צריך לוודא שדף הבית עומד בדרישות הבאות:
- דף הבית צריך להיות נגיש לכולם, ולא רק למשתמשים שמחוברים לאתר.
- הרלוונטיות של דף הבית לאפליקציה שנבדקת צריכה להיות ברורה.
- קישורים לדף האפליקציה בחנות Google Play או לדף שלה בפייסבוק לא נחשבים לדפי בית תקינים של אפליקציות.
הדרישות לגבי הקישור למדיניות הפרטיות של האפליקציה
צריך לוודא שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות צריכה להיות גלויה למשתמשים, להתארח באותו דומיין כמו דף הבית של האפליקציה, וצריך לקשר אליה במסך ההסכמה של OAuth ב-Google API Console. שימו לב שדף הבית צריך לכלול תיאור של הפונקציונליות של האפליקציה, וגם קישורים למדיניות הפרטיות ולתנאים והגבלות אופציונליים.
- במדיניות הפרטיות צריך לציין איך האפליקציה ניגשת לנתוני המשתמשים ב-Google, משתמשת בהם, מאחסנת אותם או משתפת אותם. מדיניות הפרטיות חייבת לעמוד בדרישות של המדיניות של Google בנושא נתוני משתמשים בשירותי API ובדרישות לשימוש מוגבל בהיקפים מוגבלים. אתם צריכים להגביל את השימוש בנתוני המשתמשים של Google לשיטות שצוינו במדיניות הפרטיות שפרסמתם.
- כאן אפשר למצוא דוגמאות למדיניות פרטיות שלא עומדת בדרישות של מדיניות השימוש המוגבל.
איך שולחים את האפליקציה לאימות מותג
פרויקט במסוף Google Cloud מארגן את כל המשאבים שלכם במסוף Cloud. פרויקט מורכב מקבוצה של חשבונות Google משויכים שיש להם הרשאה לבצע פעולות בפרויקט, מקבוצה של ממשקי API שמופעלים, ומהגדרות החיוב, האימות והמעקב לאותם ממשקי ה-API. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש על ידי הלקוחות האלה ולהגדיר מסך הסכמה של OAuth שמוצג למשתמשים לפני שהם מאשרים גישה לאפליקציה.
אם יש לכם לקוחות OAuth שלא מוכנים לסביבת הייצור, מומלץ למחוק אותם מהפרויקט שביקשתם לאמת. אפשר לעשות את זה בדף הלקוחות.
כדי לשלוח את הפרופיל לאימות:
- מוודאים שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs והמדיניות של Google בנושא נתוני משתמשים בשירותי API.
- במסוף Cloud, חשוב לעדכן את תפקידי הבעלים והעריכה של החשבונות שמשויכים לפרויקט, וגם את כתובת האימייל לתמיכה במשתמשים ואת פרטי הקשר של המפתח במסך ההסכמה של OAuth. כך תוכלו לוודא שחברי הצוות הרלוונטיים יקבלו הודעה על כל דרישה חדשה.
- נכנסים לדף Branding של OAuth במסוף Cloud.
- לוחצים על הכפתור Project selector.
בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים את מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שרוצים להשתמש בו.
בדף Branding, מזינים את פרטי המיתוג של האפליקציה, כולל שם האפליקציה, הלוגו, פרטים ליצירת קשר עם המפתח וקישורים רלוונטיים. כל שינוי שתבצעו יישמר בתור טיוטת מיתוג.
כדי להתחיל את תהליך ההערכה, לוחצים על הכפתור אימות המיתוג. הבדיקה האוטומטית מסתיימת בדרך כלל תוך כמה דקות.
אחרי שההערכה מסתיימת, בודקים את הסטטוס. אם הבדיקה תעבור בהצלחה, הסטטוס ישתנה למוכן לפרסום. אם האימות האוטומטי נכשל, תוכלו לראות את הבעיות שזוהו ולתקן אותן או לבקש בדיקה ידנית.
לוחצים על הכפתור פרסום המיתוג כדי להפעיל את המיתוג החדש.
אם האפליקציה דורשת גם אימות של היקפים רגישים או מוגבלים, עוברים אל מרכז האימות של OAuth כדי לעקוב אחרי סטטוס הגישה לנתונים ולספק את כל המידע הנוסף שנדרש, כמו סרטון הדגמה. שימו לב: כדי לבקש אימות לגישה לנתונים, סטטוס המיתוג שלכם צריך להיות "פורסם".
משתמשים בלחצן הוספה או הסרה של היקפי הרשאות כדי להצהיר על כל היקפי ההרשאות שהאפליקציה מבקשת. קבוצה ראשונית של היקפי הרשאות שנדרשים לכניסה באמצעות חשבון Google מולאה מראש בקטע היקפי הרשאות לא רגישים. ההיקפים שנוספו מסווגים כלא רגישים, רגישים או מוגבלים.
צריך לספק עד שלושה קישורים למסמכים רלוונטיים לגבי תכונות קשורות באפליקציה.
בשלבים הבאים, מספקים את כל המידע הנוסף שנדרש לגבי האפליקציה.
- לוודא שהאפליקציה עומדת בדרישות הנוספות להיקפי הרשאות ספציפיים של API, כולל ביצוע הערכת אבטחה שנתית אם האפליקציה ניגשת לנתוני משתמשים ב-Google בהיקף הרשאות מוגבל משרת של צד שלישי או דרכו.
- מוודאים שהאפליקציה היא אחד מהסוגים המותרים שמפורטים בקטע שימוש מוגבל בדף דרישות נוספות להיקפי הרשאות ספציפיים של API.
- אם האפליקציה היא פלטפורמה לאוטומציה של משימות, סרטון ההדגמה צריך להראות איך יוצרים תהליכי עבודה מרובים של API והופכים אותם לאוטומטיים, ובאילו כיוונים נתוני המשתמשים זורמים.
- מכינים סרטון שמדגים באופן מלא איך המשתמשים מתחילים את התהליך ומעניקים גישה להיקפי ההרשאות המבוקשים, ומראה בפירוט איך האפליקציה משתמשת בהיקפי ההרשאות הרגישים והמוגבלים שהוענקו לה. מעלים את הסרטון ל-YouTube Studio ומגדירים את החשיפה כלא רשומה. אתם צריכים לספק קישור לסרטון ההדגמה בשדה הקישור ל-YouTube.
- הציגו את תהליך הענקת הרשאת ה-OAuth שהמשתמשים יחוו, באנגלית. זה כולל את תהליך ההסכמה, ואם אתם משתמשים בכניסה באמצעות חשבון Google, גם את תהליך הכניסה.
- להראות שמסך ההסכמה של OAuth מציג את שם האפליקציה בצורה נכונה.
- מראים שסרגל הכתובות בדפדפן של מסך ההסכמה של OAuth כולל את מזהה הלקוח של OAuth של האפליקציה.
- כדי להראות איך תשתמשו בנתונים, אתם צריכים להדגים את הפונקציונליות שמתאפשרת באמצעות כל היקף הרשאות רגיש ומוגבל שאתם מבקשים.
- אם אתם משתמשים בכמה לקוחות, ולכן יש לכם כמה מזהי לקוחות ב-OAuth, הראו איך מתבצעת הגישה לנתונים בכל לקוח OAuth.
- בוחרים את סוג האפליקציה המורשה מהרשימה "באילו תכונות ברצונך להשתמש?".
- צריך לתאר איך האפליקציה תשתמש בהיקפים המוגבלים, ולמה היקפים מוגבלים יותר לא מספיקים.
אחרי שתפרסמו את המיתוג או תשלחו בקשה לגישה לנתונים, יכול להיות שצוות האמינות והבטיחות של Google יפנה אליכם באימייל כדי לבקש מידע נוסף או להנחות אתכם לגבי השלבים הבאים. כדי לבדוק אם קיבלתם בקשות למידע נוסף, בדקו את כתובות האימייל בקטע פרטים ליצירת קשר עם המפתח ואת כתובת האימייל לתמיכה במסך ההסכמה ל-OAuth. אתם יכולים גם לבדוק את סטטוס הבדיקה הנוכחי של הפרויקט בדפים Branding או Verification Center, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו ממתינים לתגובה שלכם.
חריגים לדרישות האימות
אם האפליקציה שלכם תשמש באחד מהתרחישים שמתוארים בקטעים הבאים, אתם לא צריכים לשלוח אותה לבדיקה.
שימוש אישי
תרחיש לדוגמה: אתם המשתמשים היחידים באפליקציה, או שמשתמשים בה רק כמה אנשים שאתם מכירים באופן אישי. יכול להיות שאתם ומספר המשתמשים המוגבל שלכם תרגישו בנוח להתקדם דרך מסך האפליקציה הלא מאומתת ולתת לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שמשמשים בשכבות פיתוח, בדיקה או Staging
כדי לעמוד בדרישות של מדיניות Google OAuth 2.0, מומלץ להשתמש בפרויקטים שונים לסביבות בדיקה וייצור. אנחנו ממליצים לשלוח את האפליקציה לאימות רק אם אתם רוצים שהיא תהיה זמינה לכל משתמש עם חשבון Google. לכן, אם האפליקציה נמצאת בשלבי פיתוח, בדיקה או Staging, אין צורך באימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את Publishing Status בהגדרת ברירת המחדל Testing. ההגדרה הזו מציינת שהאפליקציה עדיין בשלבי פיתוח וזמינה רק למשתמשים שאתם מוסיפים לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמעורבים בפיתוח או בבדיקה של האפליקציה.
רק נתונים בבעלות השירות
אם האפליקציה שלכם משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, והיא לא ניגשת לנתוני משתמשים (שמקושרים לחשבון Google), אתם לא צריכים לשלוח אותה לאימות.
כדי להבין מהם חשבונות שירות, קראו את המאמר חשבונות שירות במסמכי התיעוד של Google Cloud. במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת מוסבר איך משתמשים בחשבון שירות.
לשימוש פנימי בלבד
המשמעות היא שרק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity משתמשים באפליקציה. הפרויקט צריך להיות בבעלות הארגון, ומסך ההסכמה ל-OAuth צריך להיות מוגדר לסוג משתמש פנימי. במקרה כזה, יכול להיות שהאפליקציה תצטרך אישור ממנהל החשבון הארגוני. למידע נוסף, קראו את המאמר שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על אפליקציות ציבוריות ופנימיות
- כדי ללמוד איך לסמן את האפליקציה כפנימית, קראו את השאלה הנפוצה איך אפשר לסמן את האפליקציה כפנימית בלבד?
התקנה ברמת הדומיין
אם אתם מתכננים שהאפליקציה תטרגט רק משתמשים של ארגון ב-Google Workspace או ב-Cloud Identity, ותמיד תשתמשו בהתקנה ברמת הדומיין, האפליקציה לא תדרוש אימות מותג. עם זאת, אם האפליקציה משתמשת בהיקפים מוגבלים או רגישים, נדרש אימות אפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת למנהל הדומיין לתת לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתוני המשתמשים. רק מנהלי חשבון ארגוני יכולים להוסיף את האפליקציה לרשימת היתרים לשימוש בדומיינים שלהם.
בשאלה הנפוצה באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace מוסבר איך להגדיר את האפליקציה להתקנה בכל הדומיין.