באפליקציות ובפרויקטים שמשתמשים בממשקי ה-API וב-SDK של הפלטפורמה של מפות Google, תצטרכו להשתמש במפתחות API, או, אם האפשרות נתמכת, ב-OAuth, כדי למנוע שימוש וחיובים לא מורשים. אם אתם משתמשים במפתחות API, כדי להגביר את האבטחה, כדאי להגביל את מפתחות ה-API כשיוצרים אותם. השיטות המומלצות הבאות מראות איך להגביל אותן.
נוסף על החלת הגבלות על אפליקציות ומפתחות API, עליכם לפעול לפי נוהלי האבטחה שחלים על מוצרים ספציפיים של הפלטפורמה של מפות Google. לדוגמה, בקטע Maps JavaScript API (הגבלות על אפליקציות וממשקי API) מומלץ לקרוא בהמשך.
אם מפתחות ה-API שלכם כבר בשימוש, קראו את ההמלצות שמפורטות בקטע אם אתם מגבילים או יוצרים מחדש מפתח API שנמצא בשימוש.
מידע נוסף על חתימות דיגיטליות זמין במדריך לחתימה דיגיטלית.
שיטות מומלצות
כדי להגביר את האבטחה ולמנוע חיוב בגין שימוש לא מורשה, כדאי ליישם את השיטות המומלצות הבאות לאבטחת API בכל ממשקי ה-API, ערכות ה-SDK והשירותים של הפלטפורמה של מפות Google:
מומלץ לכל השימושים במפתחות API
שימוש במפתחות API נפרדים לכל אפליקציה
יש לפעול בזהירות כשאתם יוצרים מחדש מפתחות API
המלצות נוספות לאתרים שמשתמשים בממשקי API סטטיים באינטרנט
הגנה על אפליקציות באמצעות Static Web APIs
המלצות נוספות לאפליקציות שמשתמשות בשירותי אינטרנט
הגנה על אפליקציות בעזרת שירותי אינטרנט
המלצות נוספות לאפליקציות לנייד של iOS ו-Android
הגנה על אפליקציות לנייד באמצעות שירות אינטרנט או ממשקי API סטטיים באינטרנט
אם מגבילים או יוצרים מחדש מפתח API שנמצא בשימוש
לפני שמשנים את מפתח ה-API, כדאי לבדוק את השימוש במפתחות API השלב הזה חשוב במיוחד אם אתם מוסיפים הגבלות אחרי שהמפתח נמצא בשימוש.
אחרי שמחליפים את המפתח, מעדכנים את כל האפליקציות במפתחות ה-API החדשים לפי הצורך.
אם אין ניצול לרעה פעיל של מפתח ה-API, תוכלו להעביר את האפליקציות למספר מפתחות API חדשים בקצב שלכם, ולהשאיר את מפתח ה-API המקורי ללא שינוי עד שיופיע רק סוג אחד של תנועה, שאליו תוכלו להגביל את מפתחות ה-API באמצעות הגבלה על האפליקציה. הוראות נוספות זמינות במאמר העברה למפתחות API מרובים.
תוכלו לעקוב אחרי השימוש לאורך זמן ולראות מתי ממשקי API, סוגי פלטפורמות ודומיינים ספציפיים הועברו ממפתח ה-API הישן, לפני שתבחרו להגביל או למחוק את המפתח הישן. למידע נוסף תוכלו לקרוא את המאמרים דיווח ומעקב ומדדים.
אם מפתח ה-API שלכם נפרץ, כדאי לפעול מהר יותר לאבטחת מפתח ה-API ולהפסיק את הניצול לרעה. באפליקציות ל-Android ול-iOS, המפתחות לא מוחלפים עד שהלקוחות מעדכנים את האפליקציות שלהם. קל יותר לעדכן או להחליף מפתחות ב-JavaScript או באפליקציות של שירותי אינטרנט, אבל עדיין יכול להיות שתצטרכו תכנון זהיר ועבודה מהירה.
למידע נוסף קראו את המאמר טיפול בשימוש לא מורשה במפתח API.
הגבלת מפתחות ה-API
השיטה המומלצת היא להגביל תמיד את מפתחות ה-API באמצעות הגבלה על אפליקציות והגבלה אחת או יותר על ממשקי API. במאמר הגבלות על אפליקציות ו-API שבהמשך תוכלו לקרוא על הגבלות לפי API, SDK או שירות JavaScript.
הגבלת אפליקציות תוכלו להגביל את השימוש במפתח API לפלטפורמות ספציפיות: אפליקציות ל-Android או ל-iOS או אתרים ספציפיים לאפליקציות בצד הלקוח, או כתובות IP ספציפיות ותת-רשתות CIDR לאפליקציות בצד השרת שמייצרות קריאות ל-API ל-REST של שירות האינטרנט.
כדי להגביל מפתח, מוסיפים הגבלה אחת או יותר של אפליקציות מהסוגים שרוצים לתת הרשאה. לאחר מכן, מותרות רק בקשות שמגיעות מהמקורות האלה.
הגבלות על ממשקי API: אתם יכולים להגביל את ממשקי ה-API, ערכות ה-SDK והשירותים בפלטפורמה של מפות Google שבהם ניתן יהיה להשתמש במפתח ה-API שלכם. הגבלות על ממשקי API מאפשרות לשלוח בקשות רק לממשקי ה-API ולערכות ה-SDK שציינתם. אפשר לציין כמה הגבלות על ממשקי API לכל מפתח API נתון. רשימת ממשקי ה-API הזמינים כוללת את כל ממשקי ה-API שהופעלו בפרויקט.
הגדרת הגבלה של אפליקציה למפתח API
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים להגביל.
בדף Edit API key, בקטע Key restrictions, בוחרים באפשרות Set an application restricted.
בוחרים אחד מסוגי ההגבלות ומציינים את המידע המבוקש לפי רשימת ההגבלות.
סוג הגבלה תיאור אתרים יש לציין אתר מפנה אחד או יותר. - סכימות ה-URI של הגורם המפנה הן
https
ו-http
. - צריך לספק תמיד את ה-URI המלא של הגורם המפנה, כולל
סכמת הפרוטוקול, שם המארח והיציאה האופציונלית
(למשל,
https://google.com
). - אפשר להשתמש בתווים כלליים לחיפוש כדי לתת הרשאה לכל תת-הדומיינים. לדוגמה,
https://*.google.com
מקבלת את כל האתרים שמסתיימים ב-.google.com
. הערה: אם מציינים את www.domain.com, הוא פועל כתו כללי לחיפוש www.domain.com/* ומאשר כל נתיב משנה בשם המארח הזה. - כדאי להיזהר כשמאשרים גורמים מפנים בנתיב מלא, למשל
https://google.com/some/path
, כי כברירת מחדל, רוב הדפדפנים הנוכחיים מסירים את הנתיב מבקשות ממקורות שונים.
כתובות IP צריך לציין כתובת אחת או יותר מסוג IPv4 או IPv6, או תת-רשתות, באמצעות סימון CIDR. כתובות ה-IP חייבות להיות זהות לכתובת המקור שמזהים לשרתים של הפלטפורמה של מפות Google. אם אתם משתמשים בתרגום כתובת רשת (NAT), הכתובת הזו תואמת בדרך כלל לכתובת ה-IP הציבורית של המחשב שלכם. אפליקציות ל-Android מוסיפים את שם החבילה של Android (מהקובץ AndroidManifest.xml
) ואת טביעת האצבע לאישור חתימה SHA-1 של כל אפליקציה ל-Android שרוצים להעניק לה הרשאה. אם משתמשים בחתימת אפליקציה ב-Play, במאמר עבודה עם ספקי API מוסבר איך לאחזר את טביעת האצבע של אישור החתימה. אם אתם מנהלים את חתימת האפליקציה שלכם בעצמכם, תוכלו לעיין במאמר חתימה עצמית של האפליקציה או לעיין בהוראות של סביבת ה-build.אפליקציות ל-iOS צריך להוסיף את מזהה החבילה של כל אפליקציה ל-iOS שרוצים לתת לה הרשאה. במאמר הגבלות על אפליקציות מומלצות תוכלו לקרוא המלצות להגבלות על אפליקציות.
- סכימות ה-URI של הגורם המפנה הן
לוחצים על שמירה.
הגדרת הגבלות על ממשקי API למפתח API
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים להגביל.
בדף Edit API key (עריכת מפתח API), בקטע API restrictions:
בוחרים באפשרות Restrict key.
פותחים את Select APIs ובוחרים את ממשקי ה-API או ה-SDK שאליהם האפליקציה תוכל לגשת באמצעות מפתח ה-API.
אם API או SDK לא מופיעים ברשימה, צריך להפעיל אותם. פרטים נוספים זמינים במאמר הפעלת ממשק API או SDK אחד או יותר.
לוחצים על שמירה.
אחרי השלב הזה ההגבלה הופכת לחלק מההגדרה של מפתח ה-API. חשוב לשלוח את הפרטים המתאימים ולבחור באפשרות Save כדי לשמור את ההגבלות על מפתחות API. מידע נוסף זמין במדריך קבלת מפתח API במסמכי התיעוד של ה-API או ה-SDK הספציפיים שבהם אתם מעוניינים.
במאמר הגבלות על ממשקי API מומלצים תוכלו לקרוא על ההגבלות המומלצות בנושא API.
בדיקת השימוש במפתחות API
אם אתם מגבילים מפתחות API אחרי שהם נוצרו, או אם אתם רוצים לראות באילו ממשקי API נעשה שימוש במפתח כדי להגביל אותם, כדאי לבדוק את השימוש שלכם במפתחות API. בשלבים הבאים תוכלו לראות באילו שירותים ושיטות API נעשה שימוש במפתח API. אם רואים שימוש מעבר לשירותי הפלטפורמה של מפות Google, כדאי לבדוק אם צריך להוסיף עוד הגבלות כדי להימנע משימוש לא רצוי. תוכלו להשתמש בסייר המדדים במסוף Cloud של הפלטפורמה של מפות Google כדי לקבוע אילו הגבלות על ממשקי API ועל אפליקציות יחולו על מפתח ה-API שלכם:
קביעת ממשקי ה-API שמשתמשים במפתח ה-API שלך
דוחות המדדים הבאים מאפשרים לקבוע אילו ממשקי API משתמשים במפתחות ה-API שלכם. אפשר להשתמש בדוחות האלה כדי:
- איך משתמשים במפתחות API
- איתור שימוש לא צפוי
- אפשר לעזור לנו לבדוק אם בטוח למחוק מפתח שלא נמצא בשימוש. במאמר מחיקת מפתחות API שלא בשימוש מוסבר איך מוחקים מפתח API.
כשמחילים הגבלות על ממשקי API, אפשר להשתמש בדוחות האלה כדי ליצור רשימה של ממשקי API לאישור, או כדי לאמת המלצות שנוצרו באופן אוטומטי להגבלה על מפתחות API. מידע נוסף על הגבלות מומלצות זמין במאמר החלת הגבלות מומלצות. למידע נוסף על השימוש בסייר המדדים, ראו יצירת תרשימים באמצעות סייר המדדים.
פותחים את Metrics explorer במסוף Google Cloud.
מתחברים ובוחרים את הפרויקט של מפתחות ה-API שרוצים לבדוק.
נכנסים לדף של סייר המדדים בהתאם לסוג ה-API:
למפתחות API שמשתמשים ב-API כלשהו, מלבד ה-API של מפות Google: יש להיכנס לדף סייר המדדים.
למפתחות API שמשתמשים ב-API של מפות Google להטמעה: נכנסים אל Metrics Explorer.
בודקים כל מפתח API:
בוחרים באפשרות הוספת מסנן.
בוחרים את התווית
credential_id
.בוחרים את ה-value שתואם למפתח שרוצים לבדוק.
שימו לב לאילו ממשקי API משמש מפתח ה-API הזה, ובדקו שהשתמשתם באופן צפוי.
בסיום, בוחרים באפשרות Remove filter (הסרת המסנן)
בסוף השורה של המסנן הפעיל כדי למחוק את המסנן הנוסף.
חוזרים על הפעולה עבור שאר המפתחות.
להגביל את מפתחות ה-API רק לממשקי ה-API שנמצאים בשימוש.
אם הבחנתם בשימוש לא מורשה, קראו את המאמר טיפול בשימוש לא מורשה במפתח API.
איך לבחור את הסוג הנכון של הגבלת אפליקציות באמצעות סייר המדדים
אחרי שמוודאים שמפתח ה-API נמצא בשימוש רק בשירותי הפלטפורמה של מפות Google שבהם הוא משתמש, ומבצעים את הפעולות הנדרשות, חשוב לוודא גם שמפתחות ה-API כפופים להגבלות הנכונות.
אם מפתח ה-API כולל הגבלות מומלצות על מפתחות API, צריך להחיל אותן. מידע נוסף זמין במאמר החלת הגבלות על מפתחות API מומלצים.
אם מפתח ה-API שלכם לא כולל המלצות להגבלות, עליכם לבחור את סוג הגבלת האפליקציה שאתם רוצים להחיל על סמך הערך בשדה platform_type
המדווח באמצעות סייר המדדים:
פותחים את Metrics explorer במסוף Google Cloud.
מתחברים ובוחרים את הפרויקט של ממשקי ה-API שרוצים לבדוק.
נכנסים לדף של Metrics Explorer: הכלי לבדיקת המדדים.
בודקים כל מפתח API:
בוחרים באפשרות הוספת מסנן.
בוחרים את התווית
credential_id
.בוחרים את ה-value שתואם למפתח שרוצים לבדוק.
בסיום, בוחרים באפשרות Remove filter (הסרת המסנן)
בסוף השורה של המסנן הפעיל כדי למחוק את המסנן הנוסף.
חוזרים על הפעולה עבור שאר המפתחות.
אחרי שבחרתם את סוג הפלטפורמה למפתחות ה-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, קראו את המאמר הגנה על אפליקציות באמצעות ממשקי API סטטיים באינטרנט. הוראות נוספות להטמעה של Maps API זמינות במאמר אתרים עם Maps Embed API.
- מפתח ה-API שלי משתמש בכמה סוגי פלטפורמות
- לא ניתן לאבטח את התנועה כראוי באמצעות מפתח API אחד בלבד. תצטרכו לעבור לכמה מפתחות API. מידע נוסף זמין במאמר העברה למפתחות API מרובים.
שימוש במפתחות API נפרדים לכל אפליקציה
השיטה הזו מגבילה את ההיקף של כל מפתח. אם מפתח API אחד נפרץ, תוכלו למחוק או ליצור מחדש את המפתח המושפע בלי לעדכן את מפתחות ה-API האחרים. בכל פרויקט ניתן ליצור עד 300 מפתחות API. למידע נוסף, קראו את המאמר מגבלות על מפתחות API.
אומנם מפתח API אחד לכל אפליקציה הוא אידיאלי מטעמי אבטחה, אבל אתם יכולים להשתמש במפתחות מוגבלים במספר אפליקציות, כל עוד הן משתמשות באותו סוג של הגבלת אפליקציות.
החלת הגבלות מומלצות על מפתחות API
אצל חלק מבעלי הפרויקטים והעורכים, במסוף Google Cloud מוצעות הגבלות ספציפיות על מפתחות API למפתחות API שאינם מוגבלים, על סמך השימוש והפעילות שלהם בפלטפורמה של מפות Google.
אם ההמלצות זמינות, הן מופיעות כאפשרויות שמולאו מראש בדף Google Maps Platform Credentials.
סיבות אפשריות לכך שלא מוצגת המלצה או המלצה חלקית
אתם (גם) משתמשים במפתח ה-API בשירותים אחרים של הפלטפורמה של מפות Google. אם תראו את השימוש בשירותים אחרים, אל תיישמו את ההמלצה בלי תחילה לבצע את הפעולות הבאות:
ודאו שהשימוש ב-API שמופיע ב-Metrics Explorer ב-Google Cloud Console הוא לגיטימי.
יש להוסיף באופן ידני שירותים חסרים לרשימת ממשקי ה-API שיש לאשר.
אפשר להוסיף באופן ידני את כל ההגבלות החסרות על האפליקציות עבור השירותים שנוספו לרשימת ה-API. אם אתם מוסיפים את החשבון הזה עם סוג אחר של הגבלות על אפליקציות, קראו את המאמר העברה למפתחות API מרובים.
לא נעשה שימוש במפתח ה-API שלכם בערכות SDK או בממשקי API מצד הלקוח.
אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח תנועה נמוך שלא ראו שימוש בהם ב-60 הימים האחרונים.
יצרתם מפתח חדש ממש לאחרונה או שפרסתם מפתח קיים באפליקציה חדשה לאחרונה. במקרה כזה, כדאי להמתין עוד כמה ימים כדי שההמלצות יתעדכנו.
אתם משתמשים במפתח ה-API במספר אפליקציות, שמחייבות התנגשות בין סוגים של הגבלות על אפליקציות, או שאתם משתמשים באותו מפתח API ביותר מדי אפליקציות או אתרים שונים. בכל מקרה, כשיטה מומלצת כדאי להעביר למספר מפתחות. פרטים נוספים זמינים במאמר העברה למפתחות API מרובים.
סיבות אפשריות לכך שיוצגו לכם המלצות שלא מוצגות בתרשימים
האפליקציה או האתר שלכם שלחו רק פקיעי תנועה קצרים מאוד. במקרה כזה, תוכלו לעבור מתצוגת CHART כדי להציג TABLE או BOTH, כי השימוש עדיין מופיע במקרא. למידע נוסף, קראו את המאמר החלפת המקרא השלם של התרשים.
התנועה שלך מגיעה מ- Maps Embed API. ההוראות מפורטות במאמר איך בודקים באילו ממשקי API נעשה שימוש במפתח ה-API שלכם.
התנועה מהאפליקציה או מהאתר נמצאת מחוץ לטווח התאריכים הזמין בסייר המדדים במסוף Google Cloud.
כדי להחיל הגבלות מומלצות
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
אם האפשרות הזו זמינה, בוחרים באפשרות החלת ההגבלות המומלצות.
הערה: אם לא מוצגות הגבלות מומלצות, קראו את המאמר הגדרת הגבלות על ממשקי API למפתח API כדי להגדיר את ההגבלות המתאימות.
בוחרים באפשרות Check API usage כדי לבדוק באילו שירותים מפתח ה-API נמצא בשימוש. אם מופיעים שירותים אחרים מלבד הפלטפורמה של מפות Google, צריך להשהות כדי לבדוק ידנית את שלבי ההמלצה שלמעלה. תוכלו להיעזר בשלבים לפתרון בעיות בתחילת הקטע החלת ההגבלות המומלצות על מפתחות API.
ודאו שההגבלות שמולאו מראש תואמות לאפליקציות ולאתרים שבהם אתם מצפים להשתמש במפתח ה-API.
שיטה מומלצת: כדאי לתעד ולהסיר את כל ההגבלות על האפליקציות או ה-API שלא משויכות לשירותים שלכם. אם משהו נשבר עקב תלות בלתי צפויה, תוכלו להוסיף שוב את האפליקציות וממשקי ה-API הנדרשים.
אם אתם מזהים שאפליקציה, אתר או API חסרים בהמלצות, תוכלו להוסיף אותם ידנית או להמתין כמה ימים כדי שההמלצה תתעדכן.
אם אתם זקוקים לעזרה נוספת בנוגע להמלצה, תוכלו לפנות לתמיכה.
בחר הפעל.
מה לעשות אם הבקשה שלכם נדחתה אחרי שמיישמים המלצה
אם שמתם לב שאפליקציה או אתר נדחות אחרי שהחילו עליהם הגבלה, חפשו את ההגבלה על האפליקציות שצריך להוסיף בהודעת השגיאה של התגובה ל-API.
עבור ערכות SDK בצד הלקוח, ראו:
- אפליקציות JavaScript API של מפות Google: אפשר לעיין במסוף ניפוי הבאגים של הדפדפן
- אפליקציות ל-Android: משתמשים ב-Android Debug Bridge (adb) או ב-Logcat
- אפליקציות ל-iOS: אפשר לעיין במאמר הצגת הודעות ביומן.
במאמר זיהוי ממשקי ה-API שמשתמשים במפתח ה-API שלכם מוסבר איך לבדוק את ההגבלות הנדרשות לשימוש ב-API.
אם לא ניתן לקבוע אילו הגבלות להחיל:
- לתעד את ההגבלות הנוכחיות לשימוש עתידי.
- חשוב להסיר אותם באופן זמני במהלך בדיקת הבעיה. תוכלו לבדוק את השימוש שלכם לאורך זמן בעזרת השלבים שבמאמר בדיקת השימוש במפתחות API.
- במקרה הצורך, אפשר לפנות לתמיכה.
מחיקת מפתחות API שאינם בשימוש
לפני שמוחקים מפתח API, חשוב לוודא שלא נעשה בו שימוש בסביבת הייצור. אם לא הייתה תנועה מוצלחת, סביר להניח שאפשר למחוק את המפתח. למידע נוסף, תוכלו לקרוא את המאמר בדיקת השימוש במפתחות API.
כך מוחקים מפתח API:
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים למחוק.
לוחצים על הלחצן מחיקה בסמוך לחלק העליון של הדף.
בדף מחיקת פרטי כניסה, בוחרים באפשרות מחיקה.
תהליך ההפצה של מפתח API נמשך כמה דקות. בסיום ההפצה, כל תעבורת הנתונים באמצעות מפתח ה-API שנמחק תידחה.
צריך להיזהר כשיוצרים מחדש מפתחות API
יצירה מחדש של מפתח API יוצרת מפתח חדש עם כל ההגבלות של המפתח הישן. התהליך הזה מתחיל גם טיימר של 24 שעות, שאחריו מפתח ה-API הישן נמחק.
בחלון הזמן הזה, מקבלים גם את המפתח הישן וגם את המפתח החדש, כך שיש לכם אפשרות להעביר את האפליקציות כך שישתמשו במפתח החדש. עם זאת, בתום פרק הזמן הזה, כל האפליקציות שעדיין משתמשות במפתח ה-API הישן יפסיקו לפעול.
לפני יצירה מחדש של מפתח API:
קודם כול, מנסים להגביל את מפתחות ה-API, כמו שמתואר במאמר הגבלת מפתחות ה-API.
אם אי אפשר להגביל את מפתח ה-API בגלל סוגים מתנגשים של הגבלות על אפליקציות, כדאי לעבור לכמה מפתחות חדשים (מוגבלים), כפי שמוסבר במאמר העברה למפתחות API מרובים. ההעברה מאפשרת לשלוט בהעברה ולפרוס את ציר הזמן למפתחות ה-API החדשים.
אם ההצעות שלמעלה לא אפשריות, וצריך ליצור מחדש את מפתח ה-API כדי למנוע שימוש לא מורשה, אז צריך לבצע את הפעולות הבאות:
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
פותחים את מפתח ה-API שרוצים ליצור מחדש.
בחלק העליון של הדף, לוחצים על Regenerate key (יצירה מחדש של מפתח).
בוחרים באפשרות החלפת המפתח.
הערה: במקרה הצורך, תוכלו להחזיר כל מפתח שנוצר מחדש לגרסה הקודמת שלו. אין מגבלות זמן להחזרה לגרסה קודמת.
כדי להחזיר מפתח שנוצר מחדש
פותחים את הדף פרטי הכניסה לפלטפורמה של מפות Google במסוף Google Cloud.
פותחים את מפתח ה-API שרוצים להחזיר למצב הקודם.
בוחרים באפשרות חזרה למקש הקודם.
בתיבת הדו-שיח חזרה לגרסה הקודמת, בוחרים באפשרות מקש החזרה.
אחרי החזרה לגרסה הקודמת של המפתח, הגרסה 'החדשה' הקודמת הופכת לגרסה הקודמת, ומוגדר לה טיימר חדש להשבתה למשך 24 שעות. קיימת אפשרות לחזור בין שני ערכי המפתח האלה עד שתיצרו שוב את המפתח.
אם תיצרו מחדש את המפתח, הוא יחליף את הערך הישן של המפתח הלא פעיל.
העברה למספר מפתחות API
כדי לעבור משימוש במפתח API אחד למספר אפליקציות במפתח API ייחודי אחד לכל אפליקציה:
מזהים לאילו אפליקציות נדרשות מפתחות חדשים:
- הכי קל לעדכן אפליקציות אינטרנט, כי כל הקוד הוא בשליטתך. כדאי לתכנן לעדכן את כל המפתחות של האפליקציות מבוססות-האינטרנט.
- קשה יותר להשתמש באפליקציות לנייד, מכיוון שהלקוחות שלכם צריכים לעדכן את האפליקציות שלהם כדי שניתן יהיה להשתמש במפתחות החדשים.
יצירה והגבלה של המפתחות החדשים: מוסיפים הגבלה על אפליקציות ולפחות הגבלת API אחת. למידע נוסף, קראו את המאמר שיטות מומלצות מומלצות.
הוספת המפתחות החדשים לאפליקציות: באפליקציות לנייד התהליך הזה עשוי להימשך חודשים עד שכל המשתמשים יתעדכנו לאפליקציה האחרונה עם מפתח ה-API החדש.
הגנה על אפליקציות באמצעות Static Web APIs
ממשקי API סטטיים באינטרנט, כמו Maps Static API ו-Street View Static API, דומים לקריאות ל-API של שירותי אינטרנט.
אפשר לבצע את שתי הפעולות באמצעות API פשוט של HTTPS ל-REST, ובדרך כלל יוצרים את כתובת ה-URL של בקשת ה-API בשרת. עם זאת, במקום להחזיר תגובת JSON, ממשקי Static Web APIs יוצרים תמונה שאפשר להטמיע בקוד HTML שנוצר. חשוב יותר לציין שבדרך כלל הלקוח של משתמש הקצה, ולא השרת, הוא זה שקורא לשירות הפלטפורמה של מפות Google.
שימוש בחתימה דיגיטלית
השיטה המומלצת היא תמיד להשתמש בחתימות דיגיטליות בנוסף למפתח API. בנוסף, צריך לבדוק כמה בקשות לא חתומות אתם רוצים לאשר ביום ולהתאים את המכסות של הבקשות הלא חתומות בהתאם.
מידע נוסף על חתימות דיגיטליות זמין במדריך לחתימה דיגיטלית.
הגנה על סוד החתימה שלך
כדי להגן על Static Web APIs, אין להטמיע את סודות החתימה של ה-API ישירות בקוד או בעץ המקור, ואין לחשוף אותם באפליקציות בצד הלקוח. תוכלו להיעזר בשיטות המומלצות הבאות כדי להגן על סודות החתימה שלכם:
חותמים על הבקשות בצד השרת, לא בצד הלקוח. אם מבצעים את החתימה בצד הלקוח ב-JavaScript, חושפים אותו לכל מי שמבקר באתר. לכן, עבור תמונות שנוצרות באופן דינמי, תמיד צריך ליצור את כתובות ה-URL החתומות של מפות Google עם Static API ו-Street View Static API בצד השרת כשמציגים את דף האינטרנט. לתוכן סטטי באינטרנט, תוכלו להשתמש בווידג'ט Sign a URL now (חתימה על כתובת URL) בדף Credentials בפלטפורמה של מפות Google בענן.
אחסון סודות חתימה מחוץ לקוד המקור ולעץ המקור של האפליקציה. אם מוסיפים את סודות החתימה או כל מידע פרטי אחר במשתני סביבה, או כוללים קבצים שמאוחסנים בנפרד ואז משתפים את הקוד, סודות החתימה לא ייכללו בקבצים המשותפים. אם אתם מאחסנים סודות חתימה או כל מידע פרטי אחר בקבצים, חשוב לשמור את הקבצים מחוץ לעץ המקור של האפליקציה כדי שסודות החתימה לא ייכנסו למערכת הבקרה של קוד המקור. זה חשוב במיוחד אם אתם משתמשים במערכת ציבורית לניהול קוד מקור, כמו GitHub.
הגנה על מפתח ה-API באפליקציות באמצעות שירותי אינטרנט
אחסון מפתחות API מחוץ לקוד המקור או לעץ המקור של האפליקציה. אם אתם מזינים במשתני סביבה את מפתחות ה-API או כל מידע אחר, או כוללים קבצים שמאוחסנים בנפרד ואז משתפים את הקוד, מפתחות ה-API לא ייכללו בקבצים המשותפים. זה חשוב במיוחד אם אתם משתמשים במערכת ציבורית לניהול קוד מקור, כמו GitHub.
הגנה על מפתח ה-API ועל סוד החתימה באפליקציות לנייד באמצעות שירותי אינטרנט או ממשקי Static Web API
כדי להגן על אפליקציות לנייד, צריך להשתמש במאגר מפתחות מאובטח או בשרת proxy מאובטח:
אחסון מפתח ה-API או סוד החתימה במאגר מפתחות מאובטח. בשלב הזה קשה יותר לגרד מפתחות API ונתונים פרטיים אחרים ישירות מהאפליקציה.
שימוש בשרת proxy מאובטח. שרת ה-proxy מספק מקור יציב לאינטראקציה עם ממשק ה-API המתאים של הפלטפורמה של מפות Google. למידע נוסף על השימוש בשרת proxy, קראו את המאמר Living Vicariously: שימוש בשרתי proxy עם ספריות הלקוח של Google Data API.
יוצרים את הבקשות לפלטפורמה של מפות Google בשרת ה-proxy. לא לאפשר ללקוחות להעביר קריאות שרירותיות ל-API דרך שרת ה-proxy.
לאחר העיבוד של התגובות מפלטפורמת מפות Google בשרת ה-proxy. לסנן נתונים שהלקוח לא צריך.
טיפול בשימוש לא מורשה במפתח API
אם אתם מזהים שימוש לא מורשה במפתח ה-API, עליכם לבצע את הפעולות הבאות כדי לטפל בבעיה:
הגבלת המפתחות: אם השתמשתם באותו מפתח בכמה אפליקציות, עליכם לעבור למספר מפתחות API ולהשתמש במפתחות API נפרדים לכל אפליקציה. פרטים נוספים זמינים במאמרים הבאים:
עליך ליצור מפתחות חדשים רק אם אין לך אפשרות להגביל אותם. קראו את הקטע היזהרו כשאתם יוצרים מחדש מפתחות API לפני שממשיכים.
אם אתם עדיין נתקלים בבעיות או זקוקים לעזרה, תוכלו לפנות לתמיכה.
הגבלות מומלצות על אפליקציות וממשקי API
בקטעים הבאים מוצעים הגבלות מתאימות על אפליקציות ו-API, לכל ממשק API, SDK או שירות של הפלטפורמה של מפות Google.
הגבלות מומלצות לשימוש ב-API
ההנחיות הבאות בנוגע להגבלות API חלות על כל הפלטפורמה של מפות Google:
להגביל את מפתח ה-API רק לממשקי ה-API שעבורם אתם משתמשים בו, למעט כמה יוצאים מן הכלל:
אם האפליקציה שלך משתמשת ב- Places SDK ל-Android או ב-Places SDK ל-iOS, אשרו את Places API.
אם באפליקציה נעשה שימוש ב-API של JavaScript של מפות Google, תמיד יש לאשר אותו במפתח.
אם אתם משתמשים גם בשירותים הבאים של Maps JavaScript API, תצטרכו לאשר גם את ממשקי ה-API הבאים:
שירות הגבלת API שירות מסלולים, Maps JavaScript API Directions API שירות מטריצת מרחקים, Maps JavaScript API Distance Matrix API שירות גובה, Maps JavaScript API Elevation API שירות המרת כתובות לקואורדינטות (geocoding), Maps JavaScript API Geocoding API ספריית מקומות, Maps JavaScript API Places API
מספר דוגמאות:
אתם משתמשים ב-SDK של מפות Google ל-Android וב-Places SDK ל-Android, ולכן אתם כוללים את Maps SDK עבור Android ואת Places API כהגבלות על ממשקי API.
באתר שלכם נעשה שימוש ב-API של Maps JavaScript API וב- Maps Static API, לכן עליכם להוסיף הגבלות על ממשקי API לכל ממשקי ה-API הבאים:
- Maps JavaScript API
- Elevation API
- Maps Static API
הגבלה מומלצת לאפליקציות
אתרים עם Maps JavaScript API או Static Web API
באתרים שמשתמשים בשירותי JavaScript של מפות Google או בממשקי API סטטיים באינטרנט, יש להשתמש בהגבלת האפליקציות Websites
.
לשימוש באתרים שמשתמשים בשירותים ובממשקי ה-API הבאים של JavaScript:
1 באפליקציות לנייד, כדאי להשתמש ב-SDK של מפות Google ל-Android וב-SDK של מפות Google ל-iOS המקורי.
2 ראו גם הגנה על אפליקציות לנייד באמצעות שירות אינטרנט או ממשקי API סטטיים באינטרנט.
אתרים עם ממשק API להטמעה של מפות Google
השימוש ב-API להטמעה של מפות Google הוא בחינם, אבל עדיין צריך להגביל את כל מפתח ה-API שנעשה בו שימוש כדי למנוע ניצול לרעה בשירותים אחרים.
שיטה מומלצת: כדאי ליצור מפתח API נפרד לשימוש ב- Maps Embed API, ולהגביל את המפתח הזה רק ל- Maps Embed API. ההגבלה הזאת מאובטחת במידה מספקת במפתח ומונעת שימוש לא מורשה בו בשירותים אחרים של Google.
אם אי אפשר להפריד את השימוש ב- Maps Embed API למפתח API נפרד, צריך לאבטח את המפתח באמצעות הגבלת האפליקציה Websites
.
אפליקציות ושרתים שמשתמשים בשירותי אינטרנט
לאפליקציות ולשרתים שמשתמשים בשירותי אינטרנט, יש להשתמש בהגבלה על האפליקציות IP addresses
.
לשימוש באפליקציות ובשרתים שמשתמשים בממשקי ה-API האלה:
3 לאפליקציות לנייד, מומלץ להשתמש ב-Places SDK for Android וב-Places SDK for iOS המקוריים.
אפליקציות ל-Android
לאפליקציות ל-Android, יש להשתמש בהגבלת האפליקציות Android apps
.
לשימוש עבור אפליקציות ושרתים באמצעות ערכות ה-SDK הבאות:
אפליקציות ל-iOS
לאפליקציות ב-iOS, יש להשתמש בהגבלת האפליקציות iOS apps
.
לשימוש עבור אפליקציות ושרתים באמצעות ערכות ה-SDK הבאות: