הנחיות אבטחה בפלטפורמה של מפות Google

אפליקציות ופרויקטים שמשתמשים בממשקי ה-API ובערכות ה-SDK של Google Maps Platform חייבים להשתמש במפתחות API או ב-OAuth 2.0 (אם יש תמיכה בכך) כדי לבצע אימות.

השיטות המומלצות האלה מראות איך לאבטח את הגישה לפלטפורמה של מפות Google.

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

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

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

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

למידע נוסף על חתימות דיגיטליות שנתמכות על ידי Maps Static API ו-Street View Static API, קראו את המדריך לחתימות דיגיטליות.

שיטות מומלצות

כדי לשפר את האבטחה ולמנוע חיובים על שימוש לא מורשה, כדאי לפעול לפי השיטות המומלצות הבאות לאבטחת ממשקי API בכל ממשקי ה-API, ערכות ה-SDK או השירותים של Google Maps Platform:

מומלץ לכל השימושים במפתחות API

הגבלת מפתחות API

שימוש במפתחות API נפרדים לכל אפליקציה

מחיקת מפתחות API שלא נמצאים בשימוש

בדיקת השימוש במפתח ה-API

היזהרו כשאתם מחליפים מפתחות API

פיצול השימוש בצד הלקוח ובצד השרת לפרויקטים נפרדים

השבתה של שירותים שלא בשימוש

המלצות נוספות לאפליקציות מצד הלקוח

שימוש בערכות SDK בצד הלקוח

הגנה על קריאות לשירותי אינטרנט בצד הלקוח

המלצות נוספות לאתרים או לאפליקציות בצד הלקוח שמשתמשים בממשקי API סטטיים לאינטרנט

הגנה על השימוש ב-Static Web API

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

הגנה על מפתחות API של שירותי אינטרנט

שימוש ב-OAuth לאפליקציות בצד השרת

אם אתם מגבילים או מחליפים מפתח API שנמצא בשימוש

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

• אחרי שמחליפים את המפתח, צריך לעדכן את כל האפליקציות עם מפתחות ה-API החדשים, לפי הצורך.

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

  הוראות נוספות זמינות במאמר מעבר לשימוש בכמה מפתחות API.

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

• אם מפתח ה-API שלכם נחשף, כדאי לפעול במהירות כדי לאבטח אותו ולהפסיק את השימוש לרעה. באפליקציות ל-Android ול-iOS, המפתחות לא מוחלפים עד שהלקוחות מעדכנים את האפליקציות שלהם. העדכון או ההחלפה של מפתחות בדפי אינטרנט או באפליקציות בצד השרת הם פשוטים יותר, אבל עדיין דורשים תכנון קפדני ועבודה מהירה.

  מידע נוסף מופיע במאמר טיפול בשימוש לא מורשה במפתח API.

מידע נוסף

הגבלות מומלצות על אפליקציות וממשקי API

הגבלת מפתחות ה-API

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

השיטה המומלצת היא תמיד להגביל את מפתחות ה-API באמצעות סוג אחד של הגבלות על אפליקציות והגבלה אחת או יותר על ממשקי API. בקטע המלצות להגבלות על אפליקציות ועל ממשקי API שבהמשך מפורטות ההגבלות המומלצות לפי API,‏ SDK או שירות JavaScript.

• הגבלות על אפליקציות אתם יכולים להגביל את השימוש במפתח API לפלטפורמות ספציפיות: אפליקציות ל-Android או ל-iOS, או אתרים ספציפיים לאפליקציות בצד הלקוח, או כתובות IP ספציפיות או רשתות משנה של CIDR לאפליקציות בצד השרת שמנפיקות קריאות ל-API בארכיטקטורת REST של שירות אינטרנט.

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

  הערה: אם מגדירים הגבלת אפליקציה במפתח API, אי אפשר להשתמש בו בפלטפורמות אחרות. לדוגמה, אם מגבילים את מפתח ה-API רק לאפליקציות ל-Android, אי אפשר להשתמש בו עם iOS, שירותי אינטרנט או ממשקי API של JavaScript.

• הגבלות על ממשקי API אתם יכולים להגביל את השימוש במפתח ה-API לממשקי API, לערכות SDK או לשירותים מסוימים של Google Maps Platform. ההגבלות על ממשקי API מאפשרות רק בקשות לממשקי ה-API ולערכות ה-SDK שאתם מציינים. לכל מפתח API אפשר לציין כמה הגבלות שרוצים. רשימת ממשקי ה-API הזמינים כוללת את כל ממשקי ה-API שמופעלים בפרויקט.

  חשוב: ודאו שממשקי ה-API או ה-SDK שאתם מגבילים את מפתח ה-API שלהם תומכים בסוג ההגבלות על האפליקציות שהגדרתם. לדוגמה, אם מגדירים את המפתח עם הגבלה ל-iOS, צריך לוודא שה-API שבו רוצים להשתמש במפתח זמין ב-iOS.

הגדרת הגבלה על אפליקציות למפתח API

1. פותחים את הדף פרטי הכניסה של Google Maps Platform במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים להגביל.

3. בדף Edit API key, בקטע Key restrictions, בוחרים באפשרות Set an application restriction.

   

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

   סוג ההגבלה	תיאור
   אתרים	מציינים אתר מפנה אחד או יותר. סכימות ה-URI של מקורות התנועה שנתמכות באופן אוניברסלי הן https ו-http. אין ערובה לכך שסכימות אחרות יפעלו בצורה תקינה, כי דפדפני אינטרנט מודרניים לא ישלחו כותרת Referer בבקשות יוצאות מסיבות שקשורות לפרטיות. צריך תמיד לספק את מחרוזת המפנה המלאה, כולל סכמת הפרוטוקול, שם המארח והיציאה האופציונלית (לדוגמה, https://google.com). אפשר להשתמש בתווים כלליים לחיפוש כדי לאשר את כל תתי-הדומיין. לדוגמה, https://*.google.com מקבל את כל האתרים שמסתיימים ב-.google.com. צריך להיזהר כשמאשרים מפנים עם נתיב מלא, למשל, https://google.com/some/path, כי רוב דפדפני האינטרנט יסירו את הנתיב מבקשות חוצות-מקור מסיבות שקשורות לפרטיות.
   כתובות IP	מציינים כתובת IPv4 או IPv6 אחת או יותר, או רשתות משנה באמצעות סימון CIDR. כתובות ה-IP צריכות להתאים לכתובת המקור ששרתי Google Maps Platform מזהים. אם אתם משתמשים בתרגום כתובת רשת (NAT), הכתובת הזו בדרך כלל תואמת לכתובת ה-IP הציבורית של המכונה.
   אפליקציות ל-Android	מוסיפים את שם החבילה של Android (מתוך הקובץ AndroidManifest.xml) ואת טביעת האצבע לאישור החתימה SHA-1 של כל אפליקציה ל-Android שרוצים לאשר. בוחרים באפשרות אפליקציות ל-Android. לוחצים על + הוספה. מזינים את שם החבילה ואת טביעת האצבע לאישור SHA-1. לדוגמה: com.example.android.mapexample BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75 לוחצים על שמירה. יש שני סוגים של אישורים: אישור ניפוי באגים: אפשר להשתמש בסוג האישור הזה רק באפליקציות שאתם בודקים ובקוד שאינו קוד ייצור. אל תנסו לפרסם אפליקציה שנחתמה באמצעות אישור ניפוי באגים. הכלים של Android SDK יוצרים את האישור הזה באופן אוטומטי כשמריצים גרסת build לניפוי באגים. אישור פרסום: משתמשים באישור הזה כשמוכנים לפרסם את האפליקציה בחנות אפליקציות. הכלים של Android SDK יוצרים את האישור הזה כשמריצים גרסת build להפצה. מידע נוסף על חתימה על אפליקציות ל-Android ואישורים זמין במדריך בנושא חתימה על אפליקציות. אם אתם משתמשים בחתימת אפליקציות ב-Play, כדי לאחזר את טביעת האצבע לאישור החתימה, עיינו במאמר עבודה עם ספקי API. אם אתם מנהלים את מפתח החתימה שלכם, תוכלו לעיין במאמר בנושא חתימה עצמית על האפליקציה או בהוראות של סביבת הפיתוח שלכם.
   אפליקציות ל-iOS	מוסיפים את מזהה החבילה של כל אפליקציית iOS שרוצים לאשר. בוחרים באפשרות אפליקציות ל-iOS. לוחצים על + הוספה. מוסיפים את מזהה החבילה כדי לאשר בקשות מאפליקציית iOS עם המזהה הזה. לוחצים על שמירה.

   המלצות להגבלת אפליקציות מופיעות במאמר המלצות להגבלת אפליקציות.

5. לוחצים על שמירה.

הגדרת הגבלות על ממשקי API למפתח API

1. פותחים את הדף פרטי הכניסה של Google Maps Platform במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים להגביל.

3. בדף עריכת מפתח API, בקטע הגבלות API:

   • בוחרים באפשרות הגבלת מקש.

   • פותחים את Select APIs (בחירת ממשקי API) ובוחרים את ממשקי ה-API או ערכות ה-SDK שרוצים שהאפליקציה תגש אליהם באמצעות מפתח ה-API.

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

   

4. לוחצים על שמירה.

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

המלצות להגבלות על ממשקי API מפורטות במאמר המלצות להגבלות על ממשקי API.

בדיקת השימוש במפתח API

אם אתם מגבילים את מפתחות ה-API אחרי שהם נוצרו, או אם אתם רוצים לראות באילו ממשקי API נעשה שימוש באמצעות מפתח מסוים כדי להגביל אותם, אתם צריכים לבדוק את השימוש במפתח ה-API. בשלבים האלה מוסבר באילו שירותים ובאילו methods של API נעשה שימוש במפתח API. אם אתם רואים שימוש מעבר לשירותים של Google Maps Platform, כדאי לבדוק אם צריך להוסיף עוד הגבלות כדי למנוע שימוש לא רצוי. כדי להבין אילו הגבלות על ממשקי API ועל אפליקציות כדאי להחיל על מפתח ה-API, אפשר להשתמש בכלי לבדיקת מדדים של Google Maps Platform במסוף Cloud:

• איך בודקים אילו ממשקי API משתמשים במפתח ה-API

• בחירת סוג ההגבלה הנכון על האפליקציה באמצעות הכלי Metrics Explorer

טיפ: אם לא רואים את כל התוויות בתרשים כשפותחים את הכלי Metrics Explorer, אפשר לעיין בנושאים הבאים במאמר העזרה בנושא הכלי Metrics Explorer במסוף Google Maps Platform Cloud:החלפת מצב של מקרא התרשים והצגת כל העמודות של המקרא.

איך קובעים באילו ממשקי API נעשה שימוש במפתח ה-API

הדוחות הבאים על מדדים מאפשרים לכם לקבוע באילו ממשקי API נעשה שימוש במפתחות ה-API שלכם. אפשר להשתמש בדוחות האלה כדי:

• איך בודקים את השימוש במפתחות ה-API
• זיהוי שימוש לא צפוי
• עוזרת לוודא אם אפשר למחוק בבטחה מפתח שלא בשימוש. במאמר מחיקת מפתחות API שלא נעשה בהם שימוש מוסבר איך למחוק מפתחות API.

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

1. עוברים אל Metrics Explorer במסוף Google Cloud.

2. נכנסים לחשבון ובוחרים את הפרויקט של מפתחות ה-API שרוצים לבדוק.

3. עוברים לדף Metrics explorer של סוג ה-API:

   • למפתחות API שמשתמשים בכל API חוץ מ-Maps Embed API: נכנסים לדף Metrics explorer.

   • למפתחות API שמשתמשים ב-Maps Embed API: נכנסים אל Metrics Explorer.

4. בודקים כל מפתח API:

   1. לוחצים על הוספת מסנן.

   2. בוחרים את התווית credential_id.

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

   4. שימו לב לאילו ממשקי API משמש מפתח ה-API הזה, וודאו שהשימוש צפוי.

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

5. חוזרים על הפעולה לגבי כל המקשים שנותרו.

6. הגבילו את מפתחות ה-API רק לממשקי ה-API שנמצאים בשימוש.

7. אם מזהים שימוש לא מורשה, אפשר לעיין במאמר בנושא טיפול בשימוש לא מורשה במפתח API.

בחירת סוג ההגבלה הנכון על האפליקציה באמצעות הכלי 'מרכז המדדים'

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

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

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

1. עוברים אל Metrics Explorer במסוף Google Cloud.

2. נכנסים לחשבון ובוחרים את הפרויקט של ממשקי ה-API שרוצים לבדוק.

3. עוברים לדף Metrics Explorer: Metrics explorer.

4. בודקים כל מפתח API:

   1. לוחצים על הוספת מסנן.

   2. בוחרים את התווית credential_id.

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

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

5. חוזרים על הפעולה עם כל המפתחות שנותרו.

6. אחרי שמקבלים את סוג הפלטפורמה של מפתחות ה-API, מחילים את הגבלת האפליקציה על platform_type:

   ‫PLATFORM_TYPE_JS : החלת הגבלות גישה לאתרים על המפתח.

   ‫PLATFORM_TYPE_ANDROID : החלת הגבלות על אפליקציות ל-Android על המפתח.

   ‫PLATFORM_TYPE_IOS : החלת הגבלות על אפליקציות ל-iOS במפתח.

   ‫PLATFORM_TYPE_WEBSERVICE : יכול להיות שתצטרכו להסתמך על הגבלות של כתובות IP במפתח, כדי להגביל אותו בצורה נכונה.

   המלצות ל-Maps Static API ול-Street View Static API מפורטות במאמר הגנה על השימוש ב-Static Web API.

   המלצות ל-Maps Embed API מפורטות במאמר אתרים עם Maps Embed API.

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

שימוש במפתחות API נפרדים לכל אפליקציה

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

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

החלת ההגבלות המומלצות על מפתחות API

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

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

זהירות: אם אתם משתמשים במפתח ה-API גם בשירותים אחרים מלבד Google Maps Platform (כמו Cloud), כדאי להחיל הגבלות רק אחרי בדיקה ידנית יסודית.

אם יש המלצות, הן מופיעות כאפשרויות שמולאו מראש בדף Google Maps Platform Credentials.

חשוב: יכול להיות שרשימת ההמלצות לא תהיה מלאה. חשוב לבדוק את השימוש במפתח ה-API לפי ההוראות במסוף Google Cloud, ולבדוק את השימוש במפתח ה-API לפני שמיישמים את ההמלצות.

ממשקי API וערכות SDK של Google Maps Platform שנתמכים על ידי ההמלצות האוטומטיות

• ‫Maps JavaScript API, כולל Directions Service (מדור ישן),‏ Distance Matrix Service (מדור ישן),‏ Elevation Service,‏ Geocoding Service,‏ Place class,‏ Place Autocomplete Widget (חדש),‏ Place Autocomplete Data API,‏ Places Library,‏ Places Service, ‏ Place Autocomplete Widget ו-Places UI Kit

• ‫Maps Static API ו-Street View Static API

• Maps Embed API

• ‫SDK של מפות ל-Android, ‏Navigation SDK ל-Android, ‏Places SDK ל-Android ו-Places UI Kit ב-Android

• ‫SDK של מפות ל-iOS,‏ Navigation SDK ל-iOS,‏ Places SDK ל-iOS,‏ Places Swift SDK ל-iOS ו-Places UI Kit ל-iOS.

סיבות אפשריות לכך שלא מוצגת לכם המלצה, או שההמלצה לא מלאה

סיבות לכך שלא מוצגת המלצה

• אתם משתמשים במפתח ה-API גם בשירותים אחרים מלבד שירותי Google Maps Platform, או בשירותי Maps Platform שעדיין לא נתמכים על ידי ההמלצות האוטומטיות.

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

  1. מוודאים שהשימוש ב-API שמופיע ב-Metrics explorer במסוף Google Cloud הוא לגיטימי.

  2. להוסיף ידנית את השירותים החסרים לרשימת ממשקי ה-API שצריך לאשר.

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

• מפתח ה-API לא משמש בערכות SDK או בממשקי API בצד הלקוח.

• אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח תנועה נמוך, שלא היו בשימוש ב-60 הימים האחרונים.

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

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

סיבות לכך שההמלצה לא מוצגת במלואה

• אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח נמוך של תנועה, שלא נרשמה בהם פעילות ב-60 הימים האחרונים.

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

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

  1. מוודאים שהשימוש ב-API שמופיע ב-Metrics explorer במסוף Google Cloud הוא לגיטימי.

  2. להוסיף ידנית את השירותים החסרים לרשימת ממשקי ה-API שצריך לאשר.

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

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

     טיפ: במקרה חירום, כדאי לעיין במאמר בנושא טיפול בשימוש לא מורשה במפתח API.

סיבות אפשריות לכך שיוצגו המלצות שלא מופיעות בתרשימים

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

• התנועה מגיעה מ-Maps Embed API. הוראות מפורטות זמינות במאמר בנושא קביעת ממשקי ה-API שמשתמשים במפתח ה-API.

• התנועה מהאפליקציה או מהאתר לא נכללת בטווח התאריכים שזמין בכלי Metrics Explorer במסוף Google Cloud.

כדי להחיל הגבלות מומלצות

1. פותחים את הדף פרטי הכניסה של Google Maps Platform במסוף Google Cloud.

2. אם האפשרות החלת ההגבלות המומלצות מופיעה, לוחצים עליה.

   

   הערה: אם לא מופיעות הגבלות מומלצות, אפשר לעיין במאמר הגדרת הגבלות על ממשקי API למפתח API כדי להגדיר הגבלות מתאימות.

3. בוחרים באפשרות Check API usage כדי לבדוק באילו שירותים נעשה שימוש במפתח ה-API. אם אתם רואים שירותים אחרים ולא שירותים של Google Maps Platform, השהו את ההמלצה כדי לבדוק ידנית את השלבים שצוינו למעלה. בקטע החלת הגבלות מומלצות על מפתחות API מפורטים שלבי פתרון בעיות.

4. בודקים שההגבלות שמולאו מראש תואמות לאתרים ולאפליקציות שבהם אתם רוצים להשתמש במפתח ה-API.

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

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

   • אם אתם צריכים עזרה נוספת בהמלצה המוצעת, אתם יכולים לפנות לתמיכה.

5. לוחצים על אישור.

מה לעשות אם הבקשה נדחתה אחרי שיישמתם המלצה

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

ממשקי API וערכות SDK בצד הלקוח

אפליקציות שמבוססות על דפדפן ו-WebView

זהירות: סכימות URI לא שגרתיות של מפנים (כלומר, לא HTTPS או HTTP) לא נתמכות היטב, ומומלץ להימנע מהן אם אפשר. אלא אם צוין אחרת, אל תצפו ששירותים או ממשקי API של Google Maps Platform יתמכו בסכימות אחרות של URI של מפנה מלבד HTTPS או HTTP.

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

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

הנחיות נוספות זמינות במאמר בנושא אירוח אפליקציות מבוססות דפדפן בשרת.

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

• ב-Maps JavaScript API, אפשר לעיין במסוף ניפוי הבאגים של הדפדפן כדי לקבל פרטים על הרשאת האפליקציה.

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

  אם אתם צריכים עזרה בנוגע לסכימות URI לא שגרתיות, אתם יכולים לפנות לתמיכה.

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

  אין תמיכה בסכימות URI לא שגרתיות.

אפליקציות ל-Android

משתמשים ב-Android Debug Bridge (adb) או ב-Logcat

אפליקציות ל-iOS

צפייה בהודעות ביומן

אפליקציות שקוראות ישירות לשירותי אינטרנט

אם האפליקציות קוראות ישירות ל-API בארכיטקטורת REST של HTTPS או לנקודות קצה של gRPC ב-Google Maps Platform בלי להשתמש ב-SDK של Google Maps Platform בצד הלקוח, כדאי לעיין במידע שבהמשך:

אפליקציות ל-Android ול-iOS

אם האפליקציה שלכם ל-Android או ל-iOS קוראת לשירותים של Google Maps Platform ישירות בלי להשתמש באף אחת מערכות ה-SDK הזמינות של הלקוח של Google Maps Platform, כדאי לעיין במאמרים בנושא אפליקציות ל-Android ואפליקציות ל-iOS כדי לקבל טיפים נוספים לפתרון בעיות, ובמאמר בנושא קריאות מאובטחות לשירותי אינטרנט בצד הלקוח כדי לקבל מידע על שיטות מומלצות עדכניות לאבטחה בתרחישי שימוש בנייד.

אם האפליקציה שלכם מתעדת תגובות שגיאה של Maps Platform API, יכול להיות שההוראות שלמעלה לגבי ערכות SDK בצד הלקוח יעזרו לכם גם בפתרון בעיות שקשורות לאימות.

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

הדרך הכי טובה לאבטח אפליקציות בצד השרת שמסתמכות על מפתחות API היא באמצעות הגבלות על כתובות IP. אם הגבלתם את השימוש במפתח לכתובות IP מסוימות, והשירות שלכם מתעד תגובות שגיאה של Maps Platform API, כדאי לבדוק את יומני המערכת כדי לקבל מידע נוסף. תגובת השגיאה תכלול את כתובת ה-IP של השרת שצריך לאשר.

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

בנוסף, ממשקי API עדכניים יותר של Google Maps Platform, כמו Maps Static API ו-Street View Static API, יתמכו גם בהגבלות על גורמים מפנים. עם זאת, חשוב לזכור שדפדפני אינטרנט או WebView כנראה יגבילו את הכותרת Referer ל-Origin עבור בקשות ממקורות שונים, וכנראה שלא ישלחו אותה בכלל, למשל עבור משאבים שניגשים אליהם באופן מקומי או עבור משאבים שמוגשים באמצעות פרוטוקולים שאינם HTTP או HTTPS.

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

טיפים לבדיקת הגבלות על ממשקי API

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

אם אתם לא בטוחים אילו הגבלות להחיל:

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

מחיקת מפתחות API שלא בשימוש

חשוב: בדקו את השימוש במפתח ה-API לפני שאתם מוחקים אותו.

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

כדי למחוק מפתח API:

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים למחוק.

3. לוחצים על הלחצן מחיקה בחלק העליון של הדף.

4. בדף Delete credential, לוחצים על Delete.

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

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

חשוב להיזהר כשמחליפים מפתחות API

חשוב: לפני שמחליפים את מפתח ה-API, כדאי לבדוק את השימוש בו.

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

לפני שמחליפים מפתח API:

• קודם כל, נסו להגביל את מפתחות ה-API כמו שמוסבר במאמר הגבלת מפתחות API.

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

אם אי אפשר ליישם את ההצעות הקודמות, ואתם חייבים להחליף את מפתח ה-API כדי למנוע שימוש לא מורשה, אתם יכולים לפעול לפי השלבים הבאים:

1. פותחים את הדף פרטי הכניסה של Google Maps Platform במסוף Google Cloud.

2. פותחים את מפתח ה-API שרוצים להחליף.

3. בחלק העליון של הדף, לוחצים על החלפת מפתח.

4. אפשר לשנות את השם של מפתח ה-API.

5. בוחרים באפשרות יצירה.

6. מעדכנים את האפליקציות כדי שישתמשו במפתח החדש.

אחרי שמעדכנים את האפליקציות לשימוש במפתח החדש, מוחקים את המפתח הישן. כדי לעשות זאת, לוחצים על הלחצן Delete the previous key (מחיקת המפתח הקודם) בקטע Previous Key (מפתח קודם) בדף של מפתח ה-API החדש.

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

מעבר למספר מפתחות API

כדי לעבור משימוש במפתח API אחד לכמה אפליקציות לשימוש במפתח API ייחודי אחד לכל אפליקציה, צריך לבצע את הפעולות הבאות:

1. מזהים אילו אפליקציות צריכות מפתחות חדשים:

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

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

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

חשוב: אפשר לאבטח מפתחות API אחרי שהם נוצרו ונמצאים בשימוש, אבל באפליקציות לנייד (Android ו-iOS), המפתחות לא מוחלפים עד שהלקוחות מעדכנים את האפליקציות שלהם. עדכון או החלפה של מפתחות באפליקציות JavaScript או באפליקציות של שירותי אינטרנט הם פשוטים יותר, אבל עדיין נדרשים תכנון קפדני ועבודה מהירה. מידע נוסף זמין במאמר הגבלת מפתח API או יצירה מחדש של מפתח API שנמצא בשימוש.

פיצול השימוש בצד הלקוח ובצד השרת לפרויקטים נפרדים

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

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

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

השבתה של שירותים שלא נמצאים בשימוש

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

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

שימוש בערכות SDK בצד הלקוח

כשמשתמשים בערכות ה-SDK של Google Maps Platform בצד הלקוח, תמיד אפשר להחיל הגבלות מתאימות על מפתח ה-API כדי לאבטח את השימוש בשירות.

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

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

למידע על הזמינות של ערכות SDK של Google Maps Platform בצד הלקוח לפלטפורמות שונות, ראו הגבלות מומלצות על אפליקציות וממשקי API.

הגנה על השימוש ב-Static Web API

חשוב: אם מפתח API סטטי חשוף לציבור בדף האינטרנט שלכם, למשל בתוך תג <img> HTML שמשמש להצגת מפה סטטית או פנורמה ב-Street View, צריך להגדיר לו הגבלות על אתרים ועל API.

ממשקי API סטטיים לאינטרנט, כמו Maps Static API ו-Street View Static API, דומים לקריאות ל-API של שירות אינטרנט.

קוראים לשניהם באמצעות API בארכיטקטורת REST של HTTPS, ובדרך כלל יוצרים את כתובת ה-URL של בקשת ה-API בשרת. עם זאת, במקום להחזיר תגובת JSON, ממשקי API של אתרים סטטיים יוצרים תמונה שאפשר להטמיע בקוד HTML שנוצר. חשוב מכך, בדרך כלל הלקוח של משתמש הקצה, ולא השרת, הוא זה שמבצע את הקריאה לשירות של Google Maps Platform.

טיפ: מידע נוסף על אבטחת ממשקי API סטטיים לאינטרנט זמין בפוסט בבלוג אבטחת מפתחות API כשמשתמשים בממשקי API של מפות סטטיות ו-Street View.

שימוש בחתימה דיגיטלית

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

פרטים נוספים על חתימות דיגיטליות זמינים במדריך לחתימות דיגיטליות.

הגנה על סוד החתימה

חשוב: תמיד חותמים על הבקשות בצד השרת, ולא בצד הלקוח. אם, לדוגמה, אתם מבצעים את החתימה בצד הלקוח ב-JavaScript, אתם חושפים אותה לכל מי שמבקר באתר שלכם.

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

• צרו את כתובות ה-URL של בקשות ה-API החתומות ל-Maps Static API ול-Street View Static API בצד השרת כשאתם מציגים דף אינטרנט, או בתגובה לבקשה מהאפליקציה לנייד.

  כדי לחתום על תוכן סטטי באינטרנט, אפשר להשתמש בווידג'ט Sign a URL now בדף Credentials של Google Maps Platform במסוף Cloud.

  לתוכן מהאינטרנט דינמי, עיינו בדוגמאות הקוד הזמינות לחתימה על בקשות של כתובות URL.

  טיפ: מפתחים של אפליקציות לנייד יכולים להשתמש בשרת proxy מאובטח כדי ליצור את הבקשות החתומות שלהם.

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

הגנה על מפתחות API של שירותי אינטרנט

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

כדי להשתמש בצורה מאובטחת בממשקי ה-API ובשירותים של Google Maps Platform מאפליקציות בצד הלקוח, קראו את המאמרים שימוש ב-SDK בצד הלקוח ואבטחת קריאות לשירותי אינטרנט בצד הלקוח.

מאחסנים מפתחות API מחוץ לקוד המקור או לעץ המקור של האפליקציה. אם אתם מכניסים את מפתחות ה-API או מידע אחר למשתני סביבה או כוללים קבצים שמאוחסנים בנפרד ואז משתפים את הקוד, מפתחות ה-API לא נכללים בקבצים המשותפים. זו המלצה חשובה במיוחד למי שמשתמש במערכת ציבורית לניהול קוד מקור, כמו GitHub.

כדי להגן על מפתח ה-API של שירות האינטרנט מפני שימוש לא מכוון, מומלץ להחיל הגבלות על ה-API על כל מפתח שמשמש את הפלטפורמה של מפות Google. בנוסף, אם תחיל הגבלות על כתובות IP על מפתח שירות האינטרנט, תוכל להגן עליו מפני שימוש לא מורשה מכתובות IP אחרות, גם אם המפתח ידלוף בטעות.

שימוש ב-OAuth לאפליקציות בצד השרת

‫OAuth 2.0 הוא תקן פתוח להענקת גישה.

אזהרה: גם אם יכול להיות שממשק Maps Platform API תומך ב-OAuth, לעולם אל תחשפו מפתחות של חשבונות שירות באפליקציה בצד הלקוח, שאולי מופעלת על ידי משתמשי קצה לא מהימנים או במכשירים לא מהימנים של משתמשי קצה.

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

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

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

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

לדוגמה, הנה נושא OAuth עבור Address Validation API.

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

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

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

שימוש בשרת Proxy

שימוש בשרת proxy מאובטח מספק מקור אמין לאינטראקציה עם נקודת קצה של שירות אינטרנט של Google Maps Platform מאפליקציה בצד הלקוח, בלי לחשוף את מפתח ה-API, את סוד החתימה או את חשבון השירות של Google Cloud למשתמשים לא מורשים.

טיפ: ב-Maps Static API וב-Street View Static API, מספיק שהשרת ייצור את כתובת ה-URL של הבקשה החתומה. אם לוגיקת החתימה של הבקשה מיושמת בשרת proxy, אפשר פשוט להנפיק הפניה אוטומטית של HTTP ללקוח באמצעות כתובת ה-URL החדשה של הבקשה החתומה.
לדוגמה, אפשר להשתמש בגישה הזו יחד עם אפליקציה לנייד שמשתמשת בממשקי API סטטיים לאינטרנט.

נקודות מרכזיות:

• יוצרים את הבקשות ל-Google Maps Platform בשרת ה-proxy. אל תאפש העברת קריאות שרירותיות ל-API באמצעות ה-proxy.

• לעבד את התגובות של Google Maps Platform בשרת ה-proxy. מסננים את הנתונים שהלקוח לא צריך.

חשוב: תמיד צריך לדרוש אימות לגישת לקוח לשרתי ה-proxy.

מידע נוסף על שימוש בשרת proxy זמין במאמר Living Vicariously: Using Proxy Servers with the Google Data API Client Libraries.

שיחות מאובטחות ישירות לשירותי אינטרנט בנייד

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

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

1. שימוש בכותרות HTTP:

   • ‫Android: משתמשים בכותרות ה-HTTP‏ X-Android-Package ו-X-Android-Cert.

   • ‫iOS: משתמשים בכותרת ה-HTTP‏ X-Ios-Bundle-Identifier.

2. מוסיפים את ההגבלות המתאימות על האפליקציה למפתח Android או iOS.

   חשוב: יכול להיות שהגבלות על אפליקציות ל-Android ול-iOS לא ייתמכו באופן מלא בשירותים מדור קודם של Google Maps Platform.

3. לפני ששוקלים להנפיק קריאות ישירות מהאפליקציה לנייד לשירות אינטרנט של API בארכיטקטורת REST ב-Google Maps Platform, צריך לוודא שבקשות עם מזהים לא נכונים של אפליקציות ל-Android או ל-iOS נדחות.

   אם הגבלות על אפליקציות ל-Android ול-iOS לא נתמכות בנקודת הקצה שנבדקה, Google strongly ממליצה להשתמש בשרת proxy מאובטח בין הלקוחות בנייד לבין נקודת הקצה של שירות האינטרנט של Google Maps Platform.

טיפים לאפליקציות ל-Android:

• לפני שמשלבים את האפליקציה ל-Android עם שירותי Google Maps Platform, צריך לוודא שמזהה האפליקציה (שנקרא גם שם החבילה) בפורמט הנכון. פרטים נוספים זמינים במאמר Configure app module (הגדרת מודול האפליקציה) במסמכי העזרה של Android.

• כדי להעביר את X-Android-Package ישירות מהאפליקציה, מחפשים אותו באופן פרוגרמטי באמצעות Context.getPackageName().

• כדי להעביר את X-Android-Cert ישירות מהאפליקציות, מחשבים את טביעת האצבע הנדרשת מסוג SHA-1 של אישורי החתימה של האפליקציה, שאפשר לגשת אליהם דרך PackageInfo.signingInfo.

  חשוב: כשמגדירים את הכותרת, צריך לוודא שמעבירים את הגיבוב (digest) של SHA-1 של אישור החתימה, וממירים את הגיבוב שמתקבל (20 בייט) למחרוזת מקודדת בבסיס 16 (הקסדצימלי) ללא תוחמים או קידומות, למשל, 00112233445566778899AABBCCDDEEFF00112233.

• אם אתם מאשרים את האפליקציה ל-Android באמצעות מסוף Google Cloud, שימו לב שממשק המשתמש מצפה שטביעת האצבע מסוג SHA-1 תהיה מחרוזת שמופרדת בנקודתיים, למשל 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33. עם זאת, הכלי gcloud וה-API של מפתחות ה-API מצפים למחרוזת הקסדצימלית ללא מפרידים.

טיפים לאפליקציות ל-iOS:

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

• בדרך כלל, כשמאשרים את האפליקציה ל-iOS, צריך תמיד להעביר את מזהה החבילה של החבילה הראשית בכותרת X-Ios-Bundle-Identifier.

מידע נוסף זמין במאמרים ניהול מפתחות API ושימוש במפתחות API לגישה לממשקי API.

אירוח אפליקציות מבוססות-דפדפן בשרת

בעזרת מסגרות כמו Apache Cordova, אפשר ליצור בקלות אפליקציות היברידיות חוצות פלטפורמות שפועלות בתוך תצוגת אינטרנט. עם זאת, לא מובטח שהגבלות הגישה לאתרים של מפתח ה-API יפעלו בצורה תקינה, אלא אם אפליקציית האינטרנט נטענת באמצעות HTTP או HTTPS מאתר שבשליטתכם ושהרשיתם.

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

לחלופין, באפליקציות לנייד, כדאי להשתמש בערכות ה-SDK הזמינות של Google Maps Platform ל-Android ול-iOS, במקום להשתמש ב-SDK מבוסס-אינטרנט.

שימוש ב-App Check כדי לאבטח את מפתח ה-API

חלק מממשקי ה-API ומערכות ה-SDK של מפות Google מאפשרים לכם לשלב עם Firebase App Check. השירות App Check מספק הגנה על קריאות מהאפליקציה שלכם ל-Google Maps Platform על ידי חסימת תעבורת נתונים שמגיעה ממקורות אחרים מלבד אפליקציות לגיטימיות. הבדיקה מתבצעת על ידי חיפוש טוקן מספק אימות. שילוב האפליקציות עם App Check עוזר להגן מפני בקשות זדוניות, כדי שלא תחויבו על קריאות לא מורשות ל-API.

הוראות לשילוב App Check:

• ‫Places SDK ל-iOS
• ‫Places SDK ל-Android
• ‫Maps JavaScript API
• המחלקות Place, ‏ Maps JavaScript API

טיפול בשימוש לא מורשה במפתח API

אם זיהיתם שימוש לא מורשה במפתח ה-API שלכם, אתם יכולים לפתור את הבעיה כך:

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

   • הגבלת מפתחות API
   • מעבר לשימוש בכמה מפתחות API
   • שימוש במפתחות API נפרדים לכל אפליקציה

2. אם אתם משתמשים ב-Places SDK או ב-Maps JavaScript API, אתם יכולים גם להשתמש ב-App Check כדי לאבטח את מפתח ה-API.

3. רק אם מתקיים התנאי הבא, מחליפים או מסובבים את המקשים:

   • זיהיתם שימוש לא מורשה במפתחות שאי אפשר להגביל או שהם כבר מוגבלים, ו-App Check לא רלוונטי.

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

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

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

הגבלות מומלצות על אפליקציות וממשקי API

בקטעים הבאים מוצעות הגבלות מתאימות על אפליקציות ועל ממשקי API לכל אחד מממשקי ה-API, ערכות ה-SDK או השירותים של Google Maps Platform.

הגבלות מומלצות על ממשקי API

ההנחיות הבאות לגבי הגבלות על ממשקי API חלות על כל השירותים של Google Maps Platform:

• הגבילו את מפתח ה-API רק לממשקי ה-API שאתם משתמשים בו, עם החריגים הבאים:

  • אם האפליקציה שלכם משתמשת ב-Places SDK ל-Android או ב-Places SDK ל-iOS, צריך לתת הרשאה ל-Places API (חדש) או ל-Places API, בהתאם לגרסאות ה-SDK שבהן אתם משתמשים. ¹

  • אם האפליקציה שלכם משתמשת ב-Maps JavaScript API, צריך תמיד להעניק לה הרשאה במפתח.

  • אם אתם משתמשים גם באחד מהשירותים הבאים של Maps JavaScript API, אתם צריכים גם לאשר את ממשקי ה-API התואמים:

    שירות	הגבלת API
    שירות Directions (דור קודם)	‫Directions API (גרסה קודמת)
    שירות מטריצת מרחקים (דור קודם)	‫Distance Matrix API (הגרסה הקודמת)
    Elevation Service	Elevation API
    שירות המרת כתובות לקואורדינטות (geocoding)	Geocoding API
    ‫Place class, השלמה אוטומטית למקומות Widget (חדש) & Place Autocomplete Data API	‫Places API (חדש)^2
    ספריית המקומות, שירות המקומות ו ווידג'ט ההשלמה האוטומטית למקומות	‫Places API^2

^‫1 פרטים נוספים זמינים במסמכי התיעוד של Places SDK ל-Android ושל Places SDK ל-iOS.

² אם אתם לא בטוחים אם אתם צריכים לאשר את Places API (חדש) או את Places API (מדור קודם), תוכלו לעיין במסמכי התיעוד של Maps JavaScript API.

מספר דוגמאות:

• אתם משתמשים ב-SDK של מפות ל-Android וב-Places SDK ל-Android, ולכן אתם כוללים את SDK של מפות ל-Android ואת Places API (חדש) כהגבלות על API.

• האתר שלכם משתמש בשירות Elevation של Maps JavaScript API וב-Maps Static API, ולכן אתם מוסיפים הגבלות על API לכל ממשקי ה-API הבאים:

  • Maps JavaScript API
  • Elevation API
  • Maps Static API

הגבלת אפליקציות מומלצות

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

אתרים

טיפ: למידע על Maps Embed API, קראו את המאמר אתרים עם Maps Embed API.

באתרים שמשתמשים בשירותים של Maps JavaScript API, ‏Maps Static API או Street View Static API, או שולחים קריאות לשירותים האחרונים של Google Maps Platform ישירות דרך ה-API בארכיטקטורת REST ב-HTTPS או gRPC, צריך להשתמש בהגבלה על אפליקציות מסוג אתרים:

Directions Service (Legacy) ‫Distance Matrix Service (Legacy) Elevation Service Geocoding Service

‫Maps JavaScript API^1 ספריית מקומות^2 ‫Maps Static API^3 Street View Static API^3

^‫1 באפליקציות לנייד, מומלץ להשתמש ב-Maps SDK for Android וב-Maps SDK for iOS.

‫² באפליקציות לנייד, מומלץ להשתמש ב-Places SDK ל-Android וב-Places SDK ל-iOS.

³ ראו גם הגנה על השימוש ב-Static Web API.

אתרים עם Maps Embed API

השימוש ב-Maps Embed API הוא בחינם, אבל עדיין כדאי להגביל את השימוש במפתח ה-API כדי למנוע ניצול לרעה בשירותים אחרים.

שיטה מומלצת: צרו מפתח API נפרד לשימוש ב-Maps Embed API, והגבילו את המפתח הזה רק ל-Maps Embed API. ההגבלה הזו מאבטחת את המפתח בצורה מספקת, ומונעת שימוש לא מורשה בו בשירות אחר של Google. כדי לקבל שליטה מלאה על המקומות שבהם אפשר להשתמש במפתח Maps Embed API, ‏ Google ממליצה להחיל גם הגבלות על אפליקציות מסוג אתרים.

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

אפליקציות ושרתים שמשתמשים בשירותי אינטרנט

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

.

לשרתים ולאפליקציות בצד הלקוח מרשתות פנימיות ארגוניות מהימנות שמשתמשות בשירותי אינטרנט יחד עם מפתחות API, משתמשים בהגבלת האפליקציה IP addresses.

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

שימוש באפליקציות ובשרתים באמצעות ממשקי ה-API האלה:

Address Validation API Aerial View API Air Quality API ‫Directions API (גרסה קודמת)^4 ‫Distance Matrix API (Legacy)^4 Elevation API Geocoding API^5 ‫Geolocation API^6 ‫Map Tiles API

Maps Datasets API Places API (New)^7 Places API (דור קודם)^6 Roads API ‫Routes API^4 Pollen API ‫Solar API ‫Time Zone API^8 Weather API

‫⁴ באפליקציות לנייד, מומלץ להשתמש ב-Navigation SDK.

⁵ כדי להשתמש במכשיר הנייד בצורה בטוחה, השתמשו בשרת proxy מאובטח.

⁶ באפליקציות בצד הלקוח, כדאי להשתמש בשירות המיקום המקורי של הפלטפורמה. לדוגמה, W3C Geolocation לדפדפני אינטרנט, LocationManager או ספק מיקום משולב API ל-Android, או מסגרת Core Location של אפל ל-iOS.

^‫7 באפליקציות לנייד, מומלץ להשתמש ב-Places SDK ל-Android וב-Places SDK ל-iOS.

‫⁸ כדי להשתמש ב-Tag Manager בצד הלקוח בצורה בטוחה, צריך להשתמש בשרת Proxy מאובטח.

אפליקציות ל-Android

באפליקציות ב-Android, משתמשים בהגבלת האפליקציה Android apps. שימוש באפליקציות שמשתמשות בערכות ה-SDK האלה:

• ‫SDK של מפות ל-Android
• ‫Places SDK ל-Android
• ‫Navigation SDK ל-Android

חשוב: כדי להבטיח את רמת האבטחה הגבוהה ביותר, Google ממליצה מאוד להשתמש בערכות ה-SDK המקוריות שלנו כדי לגשת לשירותים של Google Maps Platform מאפליקציית Android.
אם אתם צריכים לגשת לשירותים של Google Maps Platform שלא זמינים כ-Android SDKs מקוריות, כדאי לעיין במאמרים קריאות מאובטחות לשירותי אינטרנט בצד הלקוח והגנה על השימוש ב-Static Web API.

בנוסף, כדי למנוע הוספה לא מכוונת של מפתחות API למערכת לניהול גרסאות, אפשר להשתמש ב-Secrets Gradle Plugin כדי להוסיף סודות מקובץ מקומי במקום לשמור אותם במניפסט של Android.

אפליקציות ל-iOS

באפליקציות ל-iOS, צריך להשתמש בהגבלת האפליקציה iOS apps. אפשר להשתמש בהם באפליקציות ובשרתים שמשתמשים בערכות ה-SDK האלה:

• SDK של מפות ל-iOS
• ‫Places SDK ל-iOS
• ‫Navigation SDK ל-iOS

חשוב: כדי להבטיח את רמת האבטחה הגבוהה ביותר, Google ממליצה מאוד להשתמש בערכות ה-SDK המקוריות שלנו כדי לגשת לשירותים של הפלטפורמה של מפות Google מאפליקציית iOS.
אם אתם צריכים לגשת לשירותים של הפלטפורמה של מפות Google שלא זמינים ב-SDK מקורי ל-iOS, כדאי לעיין במאמרים קריאות מאובטחות לשירותי אינטרנט מצד הלקוח והגנה על השימוש ב-Static Web API.

קריאה נוספת

• ניהול מפתחות API
• שימוש במפתחות API כדי לגשת לממשקי API
• אופטימיזציה של השימוש ב-Google Maps Platform באמצעות מכסות (סרטון)
• איך ליצור מפתחות API ולהגביל את השימוש בהם ב-Google Maps Platform (סרטון)
• הגבלת מפתחות API
• אבטחת מפתחות API כשמשתמשים בממשקי API של מפות סטטיות ושל Street View
• 15 שיטות מומלצות לשימוש בפלטפורמה של מפות Google