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

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

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

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

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

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

מידע נוסף על חתימות דיגיטליות שנתמכות על ידי Maps Static API ו-Street View Static API זמין במדריך לחתימות דיגיטליות.

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

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

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

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

מידע נוסף

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

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

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

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

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

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

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

1. פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף 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 מזהים. אם אתם משתמשים בתרגום כתובות רשת (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 במסוף 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, אפשר להשתמש בכלי Metrics Explorer במסוף Google Cloud Platform.

• איך בודקים באילו ממשקי 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 שבהם הוא נמצא בשימוש, צריך גם לוודא שמפתח ה-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 : החלת הגבלות על מפתחות API באתר.

   ‫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 Credentials.

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

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

• ‫Maps SDK ל-Android,‏ Navigation SDK ל-Android,‏ Places SDK ל-Android ו-Places UI Kit ב-Android

• ‫Maps SDK ל-iOS,‏ Navigation SDK ל-iOS,‏ Places SDK ל-iOS,‏ Places Swift SDK ל-iOS ו-Places UI Kit ב-iOS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך צופים בהודעות ביומן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש בשרת Proxy

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

נקודות חשובות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ערכות SDK וממשקי API מסוימים של מפות Google מאפשרים לכם להשתמש ב-Firebase App Check. התכונה 'בדיקת אפליקציות' מספקת הגנה לשיחות מהאפליקציה שלכם אל הפלטפורמה של מפות Google, על ידי חסימת תנועה שמגיעה ממקורות אחרים מלבד אפליקציות לגיטימיות. הבדיקה מתבצעת באמצעות טוקן מספק אימות. שילוב האפליקציות עם 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. רק אם מתקיים אחד מהתנאים הבאים, צריך להחליף או לסובב את המפתחות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• באתר שלכם נעשה שימוש בשירות הגובה של 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 ישירות דרך HTTPS REST API או gRPC, אתם צריכים להשתמש בהגבלת האפליקציה אתרים:

Directions Service (Legacy) שירות מטריצת מרחקים (גרסה קודמת) Elevation Service שירות המרת כתובות לקואורדינטות (geocoding)

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

¹ באפליקציות לנייד, מומלץ להשתמש ב-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 נפרד, תוכלו לאבטח את המפתח הקיים באמצעות הגבלת השימוש באפליקציה Websites.

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

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

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

‫Address Validation API Aerial View API Air Quality API ‫Directions API (גרסה קודמת)4 ‫Distance Matrix API (גרסה קודמת)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.

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

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

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

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

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

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

• ‫Maps SDK ל-Android
• ‫Places SDK ל-Android
• ‫Navigation SDK ל-Android

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

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

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

• ‫Maps SDK ל-iOS
• ‫Places SDK ל-iOS
• ‫Navigation SDK ל-iOS

קריאה נוספת

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