שיטות מומלצות לאבטחה ב-API

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

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

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

למידע נוסף על חתימות דיגיטליות, ראו מדריך לחתימה דיגיטלית.

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

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

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

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

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

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

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

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

הגנה על אפליקציות באמצעות Static Web APIs

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

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

המלצות נוספות לאפליקציות לנייד ל-iOS ול-Android

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. נכנסים לדף Credentials.

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

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

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

    סוג הגבלה תיאור
    אתרים יש לציין אתר מפנה אחד או יותר.
    • סכימות ה-URI של הגורם המפנה האוניברסלי הן https ו-http.
    • צריך לספק תמיד את ה-URI המלא של הגורם המפנה, כולל סכמת הפרוטוקול, שם המארח ויציאה אופציונלית (למשל, 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 שרוצים לאשר. אם משתמשים בחתימת אפליקציה ב-Play, כדי לאחזר את טביעת האצבע של אישור החתימה, כדאי לעיין במאמר עבודה עם ספקי API. אם את/ה מנהל/ת את חתימת האפליקציה שלך, יש לעיין בקטע חתימה עצמית על האפליקציה או לפעול לפי ההוראות של סביבת ה-build.
    אפליקציות ל-iOS צריך להוסיף את מזהה החבילה של כל אפליקציה ל-iOS שברצונך לאשר.

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

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

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

  1. עוברים לדף Credentials.

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

  3. בדף Edit API key, בקטע API restrictions:

    • בוחרים באפשרות Restrict key.

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

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

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

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

מידע על הגבלות מומלצות ל-API זמין במאמר הגבלות API מומלצות.

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

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

קביעת ממשקי ה-API שמשתמשים במפתח ה-API שלכם

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

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

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

  1. נכנסים אל Metrics explorer במסוף Google Cloud.

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

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

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

    • למפתחות API באמצעות Maps embed API: עוברים אל Metrics Explorer.

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

    1. בוחרים באפשרות הוספת מסנן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**סיבות אפשריות לכך שההמלצות לא מוצגות בתרשימים של כלי הניתוחים של מסוף Google Cloud:

  • האפליקציה או האתר שלכם שלחו רק פרצי תנועה קצרים מאוד. במקרה כזה, כדאי לעבור מתצוגת CHART כדי להציג את הטבלה TABLE או BOTH, כי השימוש עדיין מופיע במקרא. מידע נוסף זמין במאמר הפעלה של רשימת האגדות המלאה בתרשים.
  • התנועה שלך מגיעה מ-Maps embed API. להוראות, קראו את המאמר זיהוי ממשקי ה-API שמשתמשים במפתח ה-API.
  • נפח התנועה מהאפליקציה או מהאתר חורג מטווח התאריכים שזמין בסייר המדדים של Google Cloud Console.

  1. מתחברים למסוף Google Cloud.

  2. פותחים את הדף Credentials.

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

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

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

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

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

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

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

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

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

לערכות SDK בצד הלקוח:

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

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

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

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

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

  1. נכנסים לדף Credentials.

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

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

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

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

יש להיזהר ביצירת מחדש של מפתחות ה-API

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

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

לפני יצירה מחדש של מפתח API:

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

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

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

  1. פותחים את הדף Credentials.

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

  3. בחלק העליון של הדף, בוחרים באפשרות Regenerate key.

  4. בוחרים באפשרות החלפת מפתח.

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

כדי להחזיר מפתח שנוצר מחדש

  1. פותחים את הדף Credentials.

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

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

  4. בתיבת הדו-שיח חזרה לגרסה קודמת לוחצים על חזרה לגרסה קודמת.

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

אם יוצרים מחדש את המפתח, הוא מחליף את הערך הישן של המפתח הלא פעיל.

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

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

  1. לאילו אפליקציות נדרשים מפתחות חדשים?

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

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

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

הגנה על אפליקציות באמצעות סטטיים באינטרנט

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

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

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

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

למידע נוסף על חתימות דיגיטליות, ראו מדריך לחתימה דיגיטלית.

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

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

  • חותמים על הבקשות בצד השרת, ולא על הלקוח. אם תעשו את זה בצד הלקוח של החתימה ב-JavaScript, אתם חושפים אותו לכל מי שמבקר באתר שלכם. לכן, בתמונות שנוצרות באופן דינמי, תמיד צריך ליצור את כתובות ה-URL החתומות של ה-API של מפות Google ושל Street View סטטיות בצד השרת בזמן ההצגה של דף האינטרנט. בתוכן סטטי באינטרנט, תוכלו להשתמש בווידג'ט Sign a URL בדף Credentials בפלטפורמה של מפות Google.

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

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

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

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

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

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

  • שימוש בשרת proxy מאובטח. שרת ה-proxy מספק מקור רציף לאינטראקציה עם ה-API המתאים של מפות Google. למידע נוסף על השימוש בשרת proxy, קראו את המאמר Live Licatively: שימוש בשרתי proxy עם ספריות הלקוח של Google Data API.

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

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

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

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

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

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

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

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

הגבלות API מומלצות

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

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

    • אם האפליקציה שלכם משתמשת ב-Places SDK ל-Android או ב-Places SDK ל-iOS, צריך לאשר את ה-API של 'מקומות'.

    • אם האפליקציה משתמשת ב-JavaScript JavaScript API, תמיד מאשרים אותה במפתח.

    • אם אתם משתמשים באחד או יותר מהשירותים הבאים של JavaScript 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, ולכן אתם כוללים את ה-SDK של מפות Google ל-Android ואת מקומות Google API כהגבלות על ה-API.

  • האתר שלכם משתמש ב-Maps JavaScript API Service ו-Maps Static API כדי להוסיף הגבלות לכל ממשקי ה-API הבאים:

    • Maps JavaScript API
    • Elevation API
    • Maps Static API

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

אתרים עם Maps JavaScript API או Static Web API

באתרים שמשתמשים בשירותי JavaScript של מפות Google או ב-Static Web APIs, משתמשים בהגבלה של Websites אפליקציות.

ההגדרה הזו מתאימה לאתרים שמשתמשים בממשקי ה-API ובשירותי ה-JavaScript הבאים:

1 לאפליקציות לנייד: כדאי להשתמש ב-SDK SDK המקורי ל-Android וב-Maps SDK ל-iOS.

2למידע נוסף: הגנה על אפליקציות לנייד באמצעות שירות אינטרנט או ממשקי Static Web APIs.

אתרים עם Maps embed API

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

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

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

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

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

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

3 לאפליקציות לנייד: כדאי להשתמש ב-Native SDK for Android וב-Places SDK ל-iOS.

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

באפליקציות ל-Android, יש להשתמש בהגבלת האפליקציות של Android apps.

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

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

באפליקציות ל-iOS, משתמשים בהגבלה של האפליקציה iOS apps.

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