באפליקציות ובפרויקטים שמשתמשים בממשקי ה-API ובערכות ה-SDK של הפלטפורמה של מפות Google, צריך להשתמש במפתחות API או, אם התמיכה קיימת, ב-OAuth, כדי למנוע שימוש לא מורשה וחיובים. אם אתם משתמשים במפתחות API, מומלץ להגביל את מפתחות ה-API בזמן היצירה שלהם כדי לשפר את האבטחה. בשיטות המומלצות הבאות מוסבר איך להגביל אותם.
בנוסף להגבלות על אפליקציות ומפתחות API, חשוב לפעול לפי כל שיטות האבטחה שחלות על מוצרים ספציפיים של הפלטפורמה של מפות Google. לדוגמה, אפשר לעיין בממשק API של JavaScript במפות Google בקטע הגבלות מומלצות על אפליקציות וממשקי API שבהמשך.
אם מפתחות ה-API כבר נמצאים בשימוש, כדאי לעיין בהמלצות שבקטע אם מגבילים או יוצרים מחדש מפתח API שנמצא בשימוש.
למידע נוסף על חתימות דיגיטליות, ראו המדריך לחתימות דיגיטליות.
שיטות מומלצות
כדי לשפר את האבטחה וכדי להימנע מחיוב על שימוש לא מורשה, מומלץ לפעול לפי השיטות המומלצות הבאות לאבטחת API בכל ממשקי ה-API, ערכות ה-SDK או השירותים של הפלטפורמה של מפות Google:
מומלץ לכל שימושי מפתח ה-API
שימוש במפתחות API נפרדים לכל אפליקציה
מחיקה של מפתחות API שלא בשימוש
חשוב להיזהר כשיוצרים מחדש מפתחות API
המלצות נוספות לאתרים שמשתמשים בממשקי API סטטיים לאינטרנט
הגנה על אפליקציות באמצעות ממשקי Static Web API
המלצות נוספות לאפליקציות שמשתמשות בשירותי אינטרנט
הגנה על אפליקציות באמצעות שירותי אינטרנט
המלצות נוספות לאפליקציות לנייד ל-iOS ול-Android
הגנה על אפליקציות לנייד באמצעות ממשקי API של שירותי אינטרנט או ממשקי API סטטיים לאינטרנט
אם מגבילים או יוצרים מחדש מפתח API שנמצא בשימוש
לפני שמחליפים את מפתח ה-API, בודקים את השימוש במפתח ה-API. השלב הזה חשוב במיוחד אם מוסיפים הגבלות אחרי שהמפתח נמצא בשימוש.
אחרי שמחליפים את המפתח, מעדכנים את כל האפליקציות במפתחות ה-API החדשים לפי הצורך.
אם אין ניצול לרעה פעיל של מפתח ה-API, תוכלו להעביר את האפליקציות למספר מפתחות API חדשים בקצב שלכם, בלי לגעת במפתח ה-API המקורי עד שתראו רק סוג אחד של תנועה, ואז תוכלו להגביל את מפתחות ה-API לתנועה הזו באמצעות הגבלת אפליקציה. להוראות נוספות, ראו מיגרציה למספר מפתחות API.
לפני שתבחרו להגביל או למחוק את המפתח הישן, כדאי לעקוב אחרי השימוש בו לאורך זמן ולראות מתי ממשקי API, סוגי פלטפורמות ודומיינים מסוימים הועברו ממפתח ה-API הישן. למידע נוסף, ראו דיווח ומעקב ומדדים.
אם מפתח ה-API נפרץ, כדאי לפעול מהר יותר כדי לאבטח את מפתח ה-API ולעצור את ניצול לרעה. באפליקציות ל-Android ול-iOS, המפתחות לא מוחלפים עד שהלקוחות מעדכנים את האפליקציות שלהם. עדכון או החלפה של מפתחות ב-JavaScript או באפליקציות של שירותי אינטרנט הוא פשוט הרבה יותר, אבל עדיין עשוי לדרוש תכנון יסודי ועבודה מהירה.
מידע נוסף זמין במאמר טיפול בשימוש לא מורשה במפתח API.
הגבלת מפתחות ה-API
מומלץ תמיד להגביל את מפתחות ה-API באמצעות הגבלת אפליקציה והגבלה אחת או יותר של ממשק API. בהמשך מפורטות הצעות להגבלות לפי API, SDK או שירות JavaScript בקטע הגבלות מומלצות על אפליקציות וממשקי API.
הגבלת אפליקציה אפשר להגביל את השימוש במפתח API לפלטפורמות ספציפיות: אפליקציות ל-Android או ל-iOS, או אתרים ספציפיים לאפליקציות בצד הלקוח, או כתובות IP ספציפיות או תת-רשתות CIDR ספציפיות לאפליקציות בצד השרת שמנפיקות קריאות ל-API של שירותי אינטרנט ב-REST.
כדי להגביל מפתח, מוסיפים הגבלה אחת או יותר על אפליקציה מהסוגים שרוצים לאשר, ולאחר מכן רק בקשות שמקורן במקורות האלה מותרות.
הגבלות על ממשקי API אתם יכולים להגביל את ממשקי ה-API, ערכות ה-SDK או השירותים של הפלטפורמה של מפות Google שבהם אפשר להשתמש במפתח ה-API. הגבלות על ממשקי API מאפשרות רק בקשות לממשקי ה-API ולערכות ה-SDK שציינתם. לכל מפתח API ניתן לציין כמה הגבלות על ממשקי API שרוצים. רשימת ממשקי ה-API הזמינים כוללת את כל ממשקי ה-API שמופעלים בפרויקט.
הגדרת הגבלת אפליקציה למפתח API
פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים להגביל.
בדף Edit API key, בקטע Key restrictions, בוחרים באפשרות Set an application restriction.
בוחרים אחד מסוגי ההגבלות ומספקים את המידע המבוקש בהתאם לרשימת ההגבלות.
סוג ההגבלה תיאור אתרים מציינים אתר מפנה אחד או יותר. - הסכימות הנתמכות אוניברסלית של 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 Maps Platform Credentials במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים להגביל.
בדף Edit API key (עריכת מפתח ה-API), בקטע API restrictions (הגבלות על API):
בוחרים באפשרות 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 Console של הפלטפורמה של מפות Google כדי לקבוע אילו הגבלות על ממשקי API ואפליקציות יחולו על מפתח ה-API:
איך בודקים אילו ממשקי API משתמשים במפתח ה-API
דוחות המדדים הבאים מאפשרים לכם לקבוע באילו ממשקי API נעשה שימוש במפתחות ה-API שלכם. אפשר להשתמש בדוחות האלה כדי:
- איך רואים איך נעשה שימוש במפתחות ה-API
- זיהוי של שימוש לא צפוי
- איך בודקים אם אפשר למחוק מפתח שלא בשימוש. למידע על מחיקה של מפתח API, ראו מחיקת מפתחות API שלא בשימוש.
כשמחילים הגבלות על ממשקי API, אפשר להשתמש בדוחות האלה כדי ליצור רשימה של ממשקי API שרוצים להעניק להם הרשאה, או כדי לאמת המלצות שהונפקו באופן אוטומטי לגבי הגבלות על מפתחות API. מידע נוסף על ההגבלות המומלצות זמין במאמר החלת ההגבלות המומלצות. מידע נוסף על השימוש ב-Metrics Explorer זמין במאמר יצירת תרשימים באמצעות Metrics Explorer.
עוברים אל Metrics Explorer במסוף Google Cloud.
מתחברים לחשבון ובוחרים את הפרויקט של מפתחות ה-API שרוצים לבדוק.
עוברים לדף Metrics Explorer של סוג ה-API הרצוי:
למפתחות API שמשתמשים ב-API כלשהו למעט Maps Embed API: עוברים לדף Metrics explorer.
למפתחות API שמשתמשים ב-Maps Embed API: עוברים אל Metrics Explorer.
בודקים כל מפתח API:
בוחרים באפשרות הוספת מסנן.
בוחרים את התווית
credential_id
.בוחרים את הערך התואם למפתח שרוצים לבדוק.
שימו לב לאילו ממשקי API משמש מפתח ה-API הזה, ודאו שהשימוש צפוי.
בסיום, בוחרים באפשרות הסרת מסנן
בסוף השורה של המסנן הפעיל כדי למחוק את המסנן הנוסף.
חוזרים על הפעולה בכל המקשים האחרים.
מגבילים את מפתחות ה-API רק לממשקי ה-API שבהם אתם משתמשים.
אם אתם מזהים שימוש לא מורשה, תוכלו לקרוא את המאמר טיפול בשימוש לא מורשה במפתח API.
בחירת סוג ההגבלה המתאים על האפליקציה באמצעות 'כלי הניתוחים של המדדים'
אחרי שתבצעו את הפעולות הנדרשות כדי לוודא שמפתח ה-API משמש רק לשירותים של הפלטפורמה של מפות Google שבהם הוא משמש, ודאו גם שמפתח ה-API כולל את הגבלות האפליקציה המתאימות.
אם למפתח ה-API יש הגבלות מומלצות על מפתחות API, מחילים אותן. למידע נוסף, ראו החלת ההגבלות המומלצות על מפתחות API.
אם אין המלצות להגבלות למפתח ה-API, אפשר להחליט איזה סוג של הגבלה על האפליקציה להחיל על סמך הערך של platform_type
שדווח באמצעות כלי הניתוחים של המדדים:
עוברים אל Metrics Explorer במסוף Google Cloud.
מתחברים לחשבון ובוחרים את הפרויקט של ממשקי ה-API שרוצים לבדוק.
עוברים לדף הזה ב-Metrics Explorer: Metrics Explorer.
בודקים כל מפתח API:
בוחרים באפשרות הוספת מסנן.
בוחרים את התווית
credential_id
.בוחרים את הערך התואם למפתח שרוצים לבדוק.
בסיום, בוחרים באפשרות הסרת מסנן
בסוף השורה של המסנן הפעיל כדי למחוק את המסנן הנוסף.
חוזרים על הפעולה בכל המקשים האחרים.
אחרי שמגדירים את סוג הפלטפורמה של מפתחות ה-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
לחלק מבעלי הפרויקטים והעורכים, מסוף Google Cloud מציע הגבלות ספציפיות למפתחות API למפתחות API ללא הגבלה, על סמך השימוש והפעילות שלהם בפלטפורמת מפות Google.
אם יש המלצות, הן יופיעו כאפשרויות שמולאו מראש בדף פרטי הכניסה לפלטפורמת מפות Google.
סיבות לכך שאתם לא רואים המלצה, או המלצה חלקית
אתם משתמשים במפתח ה-API (גם) בשירותים שאינם של הפלטפורמה של מפות Google. אם אתם רואים שימוש בשירותים אחרים, אל תפעילו את ההמלצה לפני שתבצעו את הפעולות הבאות:
מוודאים שהשימוש ב-API שמוצג בכלי למדדים במסוף Google Cloud הוא לגיטימי.
מוסיפים באופן ידני את השירותים החסרים לרשימת ממשקי ה-API שרוצים להעניק להם הרשאה.
מוסיפים באופן ידני את כל ההגבלות החסרות על אפליקציות לשירותים שנוספו לרשימת ה-API. אם ההגבלות הנוספות שתוסיפו דורשות סוג אחר של הגבלות על אפליקציות, תוכלו לעיין במאמר מעבר למספר מפתחות API.
מפתח ה-API לא משמש ב-SDK או ב-API בצד הלקוח.
אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח נתונים נמוך שלא היו בהם שימושים ב-60 הימים האחרונים.
יצרתם מפתח חדש לאחרונה מאוד, או פרסתם לאחרונה מאוד מפתח קיים באפליקציה חדשה. במקרה כזה, צריך להמתין עוד כמה ימים כדי לאפשר לעדכן את ההמלצות.
אתם משתמשים במפתח ה-API במספר אפליקציות שדורשות סוגים מתנגשים של הגבלות על אפליקציות, או אתם משתמשים באותו מפתח API ביותר מדי אפליקציות או אתרים שונים. בכל מקרה, השיטה המומלצת היא לעבור לכמה מפתחות. מידע נוסף זמין במאמר מיגרציה למספר מפתחות API.
סיבות אפשריות לכך שיוצגו לכם המלצות שלא מוצגות בתרשימים
האפליקציה או האתר שלכם שלחו רק תנועה קצרה מאוד. במקרה כזה, צריך לעבור מתצוגת CHART לתצוגת TABLE או BOTH, כי השימוש עדיין גלוי במקרא. מידע נוסף זמין במאמר הצגה או הסתרה של ההסברים המלאים של התרשים.
התנועה מגיעה מ-Maps Embed API. להוראות, ראו זיהוי ממשקי ה-API שמשתמשים במפתח ה-API.
התנועה מהאפליקציה או מהאתר נמצאת מחוץ לטווח התאריכים שזמין ב-Metrics Explorer במסוף Google Cloud.
כדי להחיל את ההגבלות המומלצות
פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.
אם האפשרות הזו זמינה, בוחרים באפשרות החלת ההגבלות המומלצות.
הערה: אם לא מוצגות הגבלות מומלצות, תוכלו לקרוא את המאמר הגדרת הגבלות על ממשקי API למפתח API כדי להגדיר הגבלות מתאימות.
בוחרים באפשרות Check API usage כדי לוודא באילו שירותים נעשה שימוש במפתח ה-API. אם מופיעים שירותים שאינם של פלטפורמת מפות Google, צריך להשהות את הבדיקה כדי לבדוק באופן ידני את השלבים של ההמלצה שלמעלה. אפשר לעיין בשלבים לפתרון בעיות בתחילת הקטע החלת ההגבלות המומלצות על מפתחות API.
מוודאים שההגבלות שמולאו מראש תואמות לאתרים ולאפליקציות שבהם אתם מתכוונים להשתמש במפתח ה-API.
שיטה מומלצת: מתעדים ומסירים כל הגבלה על אפליקציות או על ממשקי API שלא משויכים לשירותים שלכם. אם משהו לא יפעל בגלל יחסי תלות בלתי צפויים, תוכלו להוסיף שוב את האפליקציות או ממשקי ה-API הנדרשים.
אם אתם רואים שאפליקציה, אתר או ממשק API חסרים בבירור מההמלצה, תוכלו להוסיף אותם באופן ידני או להמתין כמה ימים כדי שההמלצה תתעדכן.
אם אתם זקוקים לעזרה נוספת לגבי ההמלצה שהוצעה לכם, תוכלו לפנות לתמיכה.
בחר הפעל.
מה עושים אם הבקשה נדחית אחרי שמיישמים המלצה
אם אתם מבחינים שאישור של אפליקציה או אתר נדחה אחרי החלת הגבלה, תוכלו לחפש את הגבלת האפליקציה שצריך להוסיף בהודעת השגיאה בתשובת ה-API.
לגבי ערכות SDK בצד הלקוח, אפשר לעיין בהמשך:
- אפליקציות של Maps JavaScript API: ראו את מסוף ניפוי הבאגים בדפדפן
- אפליקציות ל-Android: משתמשים ב-Android Debug Bridge (adb) או ב-Logcat
- אפליקציות ל-iOS: הצגת הודעות ביומן
במאמר זיהוי ממשקי ה-API שמשתמשים במפתח ה-API מוסבר איך לבדוק את ההגבלות הנדרשות על ממשקי ה-API.
אם אתם לא מצליחים לקבוע אילו הגבלות להחיל:
- כדאי לתעד את ההגבלות הקיימות לשימוש עתידי.
- כדאי להסיר אותם באופן זמני בזמן הבדיקה של הבעיה. אפשר לבדוק את השימוש לאורך זמן לפי השלבים שמפורטים במאמר בדיקת השימוש במפתחות API.
- במקרה הצורך, אתם יכולים לפנות לתמיכה.
מחיקת מפתחות API שלא בשימוש
לפני שמוחקים מפתח API, צריך לוודא שהוא לא נמצא בשימוש בסביבת הייצור. אם אין תנועה מוצלחת, סביר להניח שאפשר למחוק את המפתח בבטחה. למידע נוסף, ראו בדיקת השימוש במפתח ה-API.
כדי למחוק מפתח API:
פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.
בוחרים את מפתח ה-API שרוצים למחוק.
לוחצים על הלחצן Delete בחלק העליון של הדף.
בדף Delete credential, בוחרים באפשרות Delete.
המחיקה של מפתח API יכולה להימשך כמה דקות. אחרי שההפצה תושלם, כל תעבורת הנתונים שמשתמשת במפתח ה-API שנמחק תידחה.
חשוב להיזהר כשיוצרים מחדש את מפתחות ה-API
יצירת מפתח API מחדש יוצרת מפתח חדש עם כל ההגבלות של המפתח הישן. התהליך הזה מפעיל גם טיימר של 24 שעות, שבסיום הטיימר מפתח ה-API הישן יימחק.
במהלך חלון הזמן הזה, גם המפתח הישן וגם המפתח החדש יתקבלו, כך שתוכלו להעביר את האפליקציות שלכם כך שישתמשו במפתח החדש. עם זאת, אחרי פרק הזמן הזה, אפליקציות שעדיין משתמשות במפתח ה-API הישן יפסיקו לפעול.
לפני שיוצרים מחדש מפתח API:
קודם נסו להגביל את מפתחות ה-API כפי שמתואר בקטע הגבלת מפתחות ה-API.
אם אי אפשר להגביל את מפתח ה-API בגלל סוגים מתנגשים של הגבלות על אפליקציות, צריך לעבור לכמה מפתחות חדשים (מוגבלים) כפי שמתואר במאמר מעבר לכמה מפתחות API. ההעברה מאפשרת לכם לשלוט בתהליך ההעברה ובלוח הזמנים להשקה של מפתחות ה-API החדשים.
אם לא ניתן להשתמש בהצעות הקודמות, וצריך ליצור מחדש את מפתח ה-API כדי למנוע שימוש לא מורשה, צריך לפעול לפי השלבים הבאים:
פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.
פותחים את מפתח ה-API שרוצים ליצור מחדש.
בחלק העליון של הדף, בוחרים באפשרות יצירת מפתח מחדש.
בוחרים באפשרות החלפת מפתח.
הערה: אם צריך, אפשר להחזיר מפתחות שנוצרו מחדש לגרסה הקודמת שלהם. אין מגבלות זמן לשליחת קובץ ה-rollback.
כדי לבטל את השינויים במפתח שעבר יצירת מחדש
פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.
פותחים את מפתח ה-API שרוצים לבצע לו חזרה לאחור.
בוחרים באפשרות Revert to previous key.
בתיבת הדו-שיח Revert, בוחרים באפשרות Revert key.
אחרי החזרה לאחור, הגרסה הקודמת 'החדשה' של המפתח הופכת לגרסה הקודמת, ומוגדר לה טיימר חדש להשבתה של 24 שעות. אפשר לעבור בין שני ערכי המפתח האלה עד שיוצרים מחדש את המפתח.
אם יוצרים מחדש את המפתח, הוא יחליף את ערך המפתח הישן הלא פעיל.
מעבר לכמה מפתחות API
כדי לעבור משימוש במפתח API אחד לכמה אפליקציות למפתח API ייחודי אחד לכל אפליקציה, מבצעים את הפעולות הבאות:
מזהים לאילו אפליקציות נדרשים מפתחות חדשים:
- קל יותר לעדכן אפליקציות אינטרנט כי אתם שולטים בכל הקוד. כדאי לתכנן את העדכון של כל המפתחות של האפליקציות מבוססות-האינטרנט.
- קשה הרבה יותר לעשות זאת באפליקציות לנייד, כי הלקוחות צריכים לעדכן את האפליקציות שלהם כדי שיוכלו להשתמש במפתחות החדשים.
יוצרים את המפתחות החדשים ומגבילים אותם: מוסיפים גם הגבלה על אפליקציה וגם לפחות הגבלה אחת על API. מידע נוסף זמין במאמר שיטות מומלצות.
מוסיפים את המפתחות החדשים לאפליקציות: בתהליך הזה לאפליקציות לנייד, יכול להיות שיחלפו חודשים עד שכל המשתמשים יעדכנו את האפליקציה האחרונה עם מפתח ה-API החדש.
הגנה על אפליקציות באמצעות ממשקי API סטטיים לאינטרנט
ממשקי API סטטיים לאינטרנט, כמו Maps Static API ו-Street View Static API, דומים לקריאות API של שירותי אינטרנט.
קוראים לשניהם באמצעות API פשוט ל-REST ב-HTTPS, ובדרך כלל יוצרים את כתובת ה-URL של בקשת ה-API בשרת. עם זאת, במקום להחזיר תגובה בפורמט JSON, ממשקי API לאינטרנט סטטי יוצרים תמונה שאפשר להטמיע בקוד HTML שנוצר. חשוב לדעת שבדרך כלל הלקוח של משתמש הקצה הוא זה שמפעיל את הקריאה לשירות של פלטפורמת מפות Google, ולא השרת.
שימוש בחתימה דיגיטלית
מומלץ תמיד להשתמש בחתימות דיגיטליות בנוסף למפתח API. בנוסף, כדאי לבדוק כמה בקשות לא חתומות אתם רוצים לאפשר ביום, ולשנות את המכסות של בקשות לא חתומות בהתאם.
למידע נוסף על חתימות דיגיטליות, ראו המדריך לחתימות דיגיטליות.
הגנה על הסוד לחתימה
כדי להגן על ממשקי API סטטיים לאינטרנט, אל תטמיעו את סודות החתימה של ה-API ישירות בקוד או בעץ המקור, ואל תחשפו אותם באפליקציות בצד הלקוח. כדי להגן על סודות החתימה, מומלץ לפעול לפי השיטות המומלצות הבאות:
חתימה על הבקשות בצד השרת, ולא בצד הלקוח. אם מבצעים את החתימה בצד הלקוח ב-JavaScript, חושפים אותה לכל מי שמבקר באתר. לכן, בתמונות שנוצרות באופן דינמי, תמיד צריך ליצור את כתובות ה-URL החתולות של הבקשות ל-Maps Static API ול-Street View Static API בצד השרת בזמן הצגת דף האינטרנט. לתוכן סטטי באינטרנט, אפשר להשתמש בווידג'ט Sign a URL now בדף Credentials של פלטפורמת מפות Google במסוף Cloud.
אחסון סודות החתימה מחוץ לקוד המקור ולעץ המקור של האפליקציה. אם תוסיפו את סודות החתימה או מידע פרטי אחר למשתני סביבה או לכללו קבצים שמאוחסנים בנפרד, ואז תשתפו את הקוד, סודות החתימה לא ייכללו בקבצים המשותפים. אם אתם מאחסנים סודות חתימה או מידע פרטי אחר בקבצים, כדאי לשמור את הקבצים מחוץ לעץ המקור של האפליקציה כדי שהסודות לא יגיעו למערכת הבקרה של קוד המקור שלכם. זו המלצה חשובה במיוחד למי שמשתמש במערכת ציבורית לניהול קוד מקור, כמו GitHub.
הגנה על מפתח ה-API באפליקציות באמצעות שירותי אינטרנט
אחסון מפתחות API מחוץ לקוד המקור או לעץ המקור של האפליקציה. אם תוסיפו את מפתחות ה-API או מידע אחר למשתני סביבה, או תכללו קבצים שמאוחסנים בנפרד, ואז תשתפו את הקוד, מפתחות ה-API לא ייכללו בקבצים המשותפים. זו המלצה חשובה במיוחד למי שמשתמש במערכת ציבורית לניהול קוד מקור, כמו GitHub.
הגנה על מפתח ה-API וסוד החתימה באפליקציות לנייד באמצעות שירותי אינטרנט או ממשקי API סטטיים לאינטרנט
כדי להגן על אפליקציות לנייד, משתמשים במאגר מפתחות מאובטח או בשרת proxy מאובטח:
אחסון מפתח ה-API או הסוד לחתימה במאגר מפתחות מאובטח. השלב הזה מקשה על גרירה (scraping) של מפתחות API ונתונים פרטיים אחרים ישירות מהאפליקציה.
שימוש בשרת proxy מאובטח. שרת ה-proxy מספק מקור יציב לאינטראקציה עם ממשק ה-API המתאים של הפלטפורמה של מפות Google. למידע נוסף על שימוש בשרת proxy, ראו חוויה עקיפה: שימוש בשרתי proxy עם ספריות הלקוח של Google Data API.
יוצרים את הבקשות של פלטפורמת מפות Google בשרת ה-proxy. לא מאפשרים ללקוחות להעביר קריאות שרירותיות ל-API דרך שרת ה-proxy.
עיבוד נוסף של התשובות מפלטפורמת מפות Google בשרת ה-proxy. לסנן נתונים שהלקוח לא צריך.
שימוש ב-App Check לאבטחת מפתח ה-API
ערכות SDK וממשקי API מסוימים של מפות Google מאפשרים לשלב את האפליקציה עם Firebase App Check. בדיקת האפליקציות מספקת הגנה לשיחות מהאפליקציה שלכם אל הפלטפורמה של מפות Google על ידי חסימה של תעבורת נתונים שמגיעה ממקורות שאינם אפליקציות חוקיות. הוא עושה זאת על ידי בדיקה של אסימון מספק אימות. שילוב האפליקציות שלכם עם App Check עוזר להגן מפני בקשות זדוניות, כך שלא תחויבו על קריאות API לא מורשות.
הוראות לשילוב עם App Check:
טיפול בשימוש לא מורשה במפתח API
אם תזהו שימוש לא מורשה במפתח ה-API שלכם, תוכלו לפעול לפי השלבים הבאים כדי לטפל בבעיה:
הגבלת המפתחות: אם השתמשתם באותו מפתח בכמה אפליקציות, כדאי לעבור לכמה מפתחות API ולהשתמש במפתחות API נפרדים לכל אפליקציה. למידע נוסף:
רק אם אין לכם אפשרות להגביל אותם, כדאי ליצור מחדש מפתחות. לפני שממשיכים, כדאי לקרוא את הקטע חשוב להיזהר כשיוצרים מחדש מפתחות API.
אם אתם עדיין נתקלים בבעיות או זקוקים לעזרה, תוכלו לפנות לתמיכה.
הגבלות מומלצות על אפליקציות וממשקי API
בקטעים הבאים מוצעות הגבלות מתאימות על אפליקציות וממשקי API לכל שירות, SDK או API של הפלטפורמה של מפות Google.
הגבלות מומלצות על ממשקי API
ההנחיות הבאות לגבי הגבלות API חלות על כל הפלטפורמה של מפות Google:
מגבילים את מפתח ה-API רק לממשקי ה-API שבהם אתם משתמשים בו, עם החרגות הבאות:
אם האפליקציה שלכם משתמשת ב-Places SDK ל-Android או ב-Places SDK ל-iOS, צריך להעניק הרשאה ל-Places API.
אם האפליקציה שלכם משתמשת ב-Maps JavaScript API, תמיד צריך להעניק לה הרשאה במפתח.
אם אתם משתמשים גם באחד מהשירותים הבאים של 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 של מפות ל-Android וב-Places SDK ל-Android, ולכן אתם צריכים לכלול את ה-SDK של מפות ל-Android ואת Places API כאילו מדובר בהגבלות API.
באתר שלכם נעשה שימוש בשירות הגובה של ממשק ה-API של JavaScript במפות Google וב-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 של מפות ל-Android וב-SDK של מפות ל-iOS.
2 אפשר גם לעיין במאמר הגנה על אפליקציות לנייד באמצעות שירות אינטרנט או ממשקי Static Web API.
אתרים עם Maps Embed API
השימוש ב-Maps Embed API הוא בחינם, אבל עדיין כדאי להגביל כל מפתח API שנעשה בו שימוש כדי למנוע ניצול לרעה בשירותים אחרים.
שיטה מומלצת: יוצרים מפתח API נפרד לשימוש ב-Maps Embed API ומגבילים את המפתח הזה ל-Maps Embed API בלבד. ההגבלה הזו מספקת אבטחה למפתח ומונעת שימוש בלתי מורשה בו בכל שירות אחר של Google.
אם אתם לא יכולים להפריד את השימוש ב-Maps Embed API למפתח API נפרד, תוכלו לאבטח את המפתח באמצעות ההגבלה על האפליקציה Websites
.
אפליקציות ושרתים שמשתמשים בשירותי אינטרנט
באפליקציות ובשרתים שמשתמשים בשירותי אינטרנט, צריך להשתמש בהגבלת האפליקציה IP addresses
.
שימוש באפליקציות ובשרתים באמצעות ממשקי ה-API האלה:
3 באפליקציות לנייד, מומלץ להשתמש ב-Places SDK ל-Android וב-Places SDK ל-iOS.
אפליקציות ל-Android
לאפליקציות ב-Android, משתמשים בהגבלת האפליקציה Android apps
.
שימוש באפליקציות ובשרתים שמשתמשים ב-SDKs האלה:
בנוסף, כדי למנוע בדיקה בטעות של מפתחות API במערכת לניהול גרסאות, אפשר להשתמש בPlugin של Secrets Gradle כדי להחדיר סודות מקובץ מקומי במקום לאחסן אותם ב-Android Manifest.
אפליקציות ל-iOS
באפליקציות ל-iOS, משתמשים בהגבלת האפליקציה iOS apps
.
שימוש באפליקציות ובשרתים שמשתמשים ב-SDKs האלה: