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

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

השיטות המומלצות האלה מראות לכם איך לאבטח את הגישה ל-Maps Platform.

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

בנוסף להחלת הגבלות על אפליקציות ומפתחות 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, SDK או שירות JavaScript.

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

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

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

הגדרת הגבלת אפליקציה למפתח 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.mawarmekar.com). אפשר להשתמש בתווים כלליים לחיפוש כדי לאשר את כל תתי-הדומיין. לדוגמה, https://*.google.com מקבל את כל האתרים שמסתיימים ב-.google.com. צריך להיזהר כשמאשרים מפנים עם נתיב מלא, למשל, https://google--com.mawarmekar.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. בדף Edit API key, בקטע API restrictions:

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

   • פותחים את 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

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

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

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

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

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

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

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

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, מסוף Google Cloud מציע הגבלות ספציפיות על מפתחות API לא מוגבלים, על סמך השימוש והפעילות שלהם ב-Google Maps Platform.

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

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

• ‫Maps JavaScript API, כולל שירות הכיוונים (מדור קודם), שירות מטריצת המרחקים (מדור קודם), שירות הגובה, שירות הגיאו-קידוד, המחלקה Place, הווידג'ט השלמה אוטומטית למקומות (חדש), Place Autocomplete Data API, ספריית המקומות, שירות המקומות, הווידג'ט השלמה אוטומטית למקומות ו-Places UI Kit

• ‫Maps Static API ו-Street View Static API

• Maps Embed API

• ‫Maps 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 לא נמצא בשימוש בממשקי API או בערכות SDK בצד הלקוח.

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

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

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

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

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

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

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

  1. מוודאים שהשימוש ב-API שמוצג בכלי Metrics Explorer במסוף Google Cloud הוא לגיטימי.

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. מוסיפים את המפתחות החדשים לאפליקציות: באפליקציות לנייד, התהליך הזה עשוי להימשך חודשים עד שכל המשתמשים יעברו לגרסה העדכנית של האפליקציה עם מפתח ה-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 סטטיים לאינטרנט, כמו Maps Static API ו-Street View Static API, דומים לקריאות ל-API של שירותי אינטרנט.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש בשרת Proxy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אם אתם מאשרים את אפליקציה ל-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 של קובץ מקומי, ימנעו את הפעולה של הרשאה שמבוססת על מפנה, כי מנוע הדפדפן שמפעיל את תצוגת האינטרנט ישמיט את שליחת הכותרת 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 & ווידג'ט השלמה אוטומטית למקומות	‫Places API2

^‫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

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

אתרים

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

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

‫Maps JavaScript API1 ספריית מקומות2 ‫Maps Static API3 ‫Street View Static API3

^‫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, מומלץ גם להחיל הגבלות על אפליקציות מסוג אתרים.

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

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

.

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

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

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

‫Maps Datasets API ‫Places API (חדש)7 ‫Places API6 ‫Roads API ‫Routes API4 Pollen API ‫Solar API ‫Time Zone API8 Weather API

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

‫⁵ כדי להשתמש בנייד בצורה בטוחה, צריך להשתמש בשרת פרוקסי מאובטח.

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

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

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

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

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

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

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

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

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

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

קריאה נוספת

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