שיטות מומלצות לאבטחת אפליקציות וממשקי API באמצעות Apigee

Last reviewed 2025-04-01 UTC

במסמך הזה מתוארות שיטות מומלצות שיכולות לעזור לכם לאבטח את האפליקציות וממשקי ה-API שלכם באמצעות ניהול API של Apigee ומוצרי Google Cloud הבאים:

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

במסמך הזה מוצגות כמה ארכיטקטורות לדוגמה כדי להדגים שיטות מומלצות לשימוש ב-Apigee API Management. בנוסף, מוסברות בו שיטות מומלצות לשימוש ב-Web App and API Protection (WAAP), פתרון אבטחה מקיף שאפשר להשתמש בו כדי לאבטח את האפליקציות ואת ממשקי ה-API.

במסמך הזה אנחנו מניחים שאתם מכירים את המושגים הבסיסיים של רשתות, ממשקי API ו-Google Cloud.

Apigee API management

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

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

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

נקודות האבטחה הן:

  • משתמשים:
    • OAuth 2.0
    • בקרת גישה לפי כתובת IP
  • אפליקציות
    • מפתחות API
    • OAuth 2.0
    • TLS
  • מפתחים ושותפים
    • SSO
    • RBAC
  • ‫APIs
    • OAuth 2.0
    • OpenID Connect
    • מכסות
    • הפסקת עלייה
    • הגנה מפני איומים
  • צוות API
    • IAM RBAC
    • לוגיקה מאוחדת
    • הסתרת נתונים
    • יומני ביקורת
  • קצה עורפי
    • רשתות פרטיות
    • TLS הדדי
    • בקרת גישה לפי כתובת IP

כפי שרואים בתמונה שלמעלה, אפשר להשתמש במנגנוני אבטחה שונים באפליקציה, כמו מפתח API או OAuth 2.0 עם אבטחת שכבת התעבורה (TLS). אפשר גם להוסיף הגבלת קצב של יצירת בקשות, מדיניות להגנה מפני איומים ולהגדיר Mutual TLS (mTLS) לחלק האחורי של שכבת ה-API.

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

מומלץ להשתמש במדיניות ברירת המחדל של Apigee כדי לאבטח את ממשקי ה-API. כללי המדיניות הם:

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

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

סוג המדיניות שם המדיניות תרחיש שימוש באבטחה
ניהול תנועה SpikeArrest policy הגבלת קצב של יצירת בקשות חלה על מספר הבקשות שנשלחות אל ה-Backend.
ניהול תנועה מדיניות המכסות עוזר לארגון לאכוף מכסות (מספר הקריאות ל-API שבוצעו) לכל צרכן.
ניהול תנועה מדיניות ResponseCache מטמון של תגובות, שמקטין את מספר הבקשות לשרת העורפי.
הגנה ברמת ההודעה OASValidation policy מאמת את הבקשות הנכנסות או את הודעות התגובה בהתאם למפרט OpenAPI 3.0 (JSON או YAML).
הגנה ברמת ההודעה מדיניות SOAPMessageValidation מאמת הודעות XML מול סכימה לבחירתכם. מאמת הודעות SOAP מול WSDL וקובע אם הודעות JSON ו-XML נוצרו בצורה נכונה.
הגנה ברמת ההודעה מדיניות JSONThreatProtection היא עוזרת לצמצם את הסיכון להתקפות ברמת התוכן, כי היא מאפשרת לכם להגדיר מגבלות על מבני JSON כמו מערכים ומחרוזות.
הגנה ברמת ההודעה מדיניות XMLThreatProtection עוזרת לכם לטפל בפגיעויות ב-XML ולצמצם את הסיכון להתקפות על ידי הערכת תוכן ההודעות וזיהוי הודעות פגומות או לא תקינות לפני שהמערכת מנתחת אותן.
הגנה ברמת ההודעה מדיניות RegularExpressionProtection הפונקציה בודקת את התוכן מול ביטויים רגולריים מוגדרים מראש ודוחה אותו אם הביטוי נכון.
אבטחה מדיניות BasicAuthentication קידוד ופענוח של פרטי הכניסה של המשתמש בקידוד Base64.
אבטחה מדיניות VerifyAPIKey הוא אוכף את האימות של מפתחות API בזמן הריצה. הוא מאפשר רק לאפליקציות עם מפתחות API מאושרים שמשויכים למוצרי ה-API שלכם לגשת לממשקי ה-API שלכם.
אבטחה מדיניות OAuthV2 מבצע פעולות של סוג הרשאה מסוג OAuth 2.0 כדי ליצור ולאמת אסימוני גישה.
אבטחה המדיניות בנושא JWS ו-JWT יצירה, אימות ופענוח של אסימוני אינטרנט מסוג JSON ‏ (JWT) וחתימות אינטרנט מסוג JSON ‏ (JWS).
אבטחה מדיניות HMAC חישוב ואימות של קוד אימות הודעות (HMAC) מבוסס-גיבוב לאימות ולבדיקות תקינות ברמת האפליקציה.
אבטחה SAMLAssertion policy
  • מאמת הודעות נכנסות שמכילות טענת נכונות (assertion) ב-SAML עם חתימה דיגיטלית.
  • יוצר טענות נכוֹנוּת (assertions) של SAML לבקשות XML יוצאות.
אבטחה מדיניות CORS ההגדרה הזו מאפשרת להגדיר כותרות של שיתוף משאבים בין מקורות (CORS) לממשקי API שנצרכים על ידי אפליקציות אינטרנט.

מומלץ להשתמש ב-Cloud Armor לבקרת גישה שמבוססת על כתובת IP ומיקום גיאוגרפי. אבל במקרים שבהם זה לא אפשרי, אפשר להשתמש במדיניות AccessControl. כדי לעזור לכם לאבטח את החיבורים מ-Apigee אל ה-Backend שלכם, Apigee מספקת גם ניהול של חנות מפתחות, שמאפשר לכם להגדיר את חנות המפתחות ואת חנות האישורים ללחיצות יד של TLS.

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

אתם משתמשים במוצרי API כדי לשלוט בגישה לממשקי ה-API שלכם. אם מגדירים מוצר API אחד או יותר באפליקציה למפתחים, אפשר להגביל את הגישה לשרתי proxy באמצעות מפתח API. לדוגמה, אפליקציות לנייד שמשמשות לקוחות יכולות לבצע רק פעולת POST בנקודת הקצה /v1/payments, ובמקרה הזה, https://$DOMAIN/v1/payments. דוגמה נוספת: אפליקציות של מוקדים טלפוניים שמשמשות את צוות המוקד יכולות לבצע פעולות כמו PUT או DELETE בנקודת הקצה /payments, כמו https://$DOMAIN/v1/payments/1234, כדי לבטל או להפוך תשלומים.

ארכיטקטורה ראשונית

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

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

זו הארכיטקטורה הראשונית:

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

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

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

שיטות מומלצות לארכיטקטורה

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

שימוש ב-Apigee כשכבת proxy

בתרשים הבא מוצגת הארכיטקטורה הראשונית עם הוספה של Apigee כשכבת proxy (חזיתית):

‫Apigee כשכבת proxy.

‫Apigee מוקצה בפרויקט Google Cloud וסביבת זמן הריצה מוקצית ומקושרת בפרויקט דייר באמצעות קישור בין רשתות VPC שכנות. כדי לאבטח את המערכת, במקום לשלוח נתונים דרך האינטרנט, אפשר להשתמש ב-Apigee כשכבת proxy כדי ליצור חיבור ישיר (פרטי) למרכז הנתונים באמצעות Cloud Interconnect.

תהליך הבקשה הוא כדלקמן:

  1. הלקוח שולח את הבקשה אל מאזן העומסים החיצוני של אפליקציות (ALB) עם פרטי הכניסה לאפליקציה – לדוגמה, מפתח, טוקן או אישור.
  2. מאזן העומסים מנתב את הבקשה אל Apigee.
  3. מערכת Apigee מעבדת את הבקשה, מבצעת את מדיניות האבטחה כפי שמתואר במאמר ניהול API ב-Apigee, ומאשרת או דוחה את הבקשה. אפשר גם להשתמש ב-Apigee כדי לנתב את הבקשה לשרתי קצה עורפיים שונים על סמך הלקוח, הבקשה או שניהם.
  4. ‫Apigee מעביר את הבקשה לשרתי הקצה העורפיים של GKE ישירות דרך כתובות IP פנימיות. התקשורת בין Apigee לבין שירות העברת הכספים יכולה להתבצע דרך כתובת RFC 1918 (כתובת IP פנימית) כי הם נמצאים ברשת שכנה.
  5. ‫Apigee שולח את הבקשה לשרתי הקצה של מרכז הנתונים הפרטי דרך Cloud Interconnect.
  6. ‫Apigee שולח את הבקשה לשירותים של צד שלישי באמצעות הקצאה של כתובת IP של Apigee NAT.

שימוש ב-Cloud Armor כשכבת WAF עם Apigee

כדי להגדיל את היקף האבטחה, אפשר להוסיף את Cloud Armor לארכיטקטורה. ‏Cloud Armor הוא חלק מתשתית איזון העומסים הגלובלית של Google Cloud. הוא מספק יכולות של חומת אש ליישומי אינטרנט (WAF) ועוזר למנוע התקפות מניעת שירות (DDoS) מבוזרות. הוא גם יכול לעזור לכם לצמצם את האיום על אפליקציות מהסיכונים שמפורטים בעשרת הסיכונים המובילים של OWASP.

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

בתרשים הבא מוצגת דוגמה לארכיטקטורה עם Apigee ו-Cloud Armor:

ארכיטקטורה עם Cloud Armor.

זרימת האירועים בארכיטקטורה הזו דומה לזרימת האירועים שמתוארת בקטע שימוש ב-Apigee כשכבת proxy שמופיע בהמשך המסמך. זרימת הבקשות היא כדלקמן:

  1. הלקוח שולח את הבקשה אל מאזן העומסים החיצוני של אפליקציות (ALB) עם פרטי הכניסה לאפליקציה – לדוגמה, מפתח, טוקן או אישור.
  2. ‫Cloud Armor מסנן את הבקשה כי מאזן העומסים החיצוני של האפליקציה מופעל. הוא אוכף ומעריך את כל הכללים ומדיניות האבטחה שהוגדרו. אם יש הפרה של כלל כלשהו, Cloud Armor דוחה את הבקשה ומציג הודעת שגיאה וקוד סטטוס.
  3. אם אין הפרות של כללי Cloud Armor, מאזן העומסים החיצוני של אפליקציות (ALB) מנתב את הבקשה אל Apigee.
  4. מערכת Apigee מעבדת את הבקשה, מפעילה את מדיניות האבטחה ומאשרת או דוחה את הבקשה. אפשר גם להשתמש בה כדי לנתב את הבקשה לשרתי קצה עורפיים שונים על סמך הלקוח, הבקשה או שניהם.
  5. ‫Apigee מעביר את הבקשה ישירות לשרתי הקצה העורפיים של GKE דרך כתובות IP פנימיות. התקשורת בין Apigee לבין שירות העברת הכספים יכולה להתבצע באמצעות כתובת RFC 1918 (כתובת IP פנימית) כי הם נמצאים ברשת המקושרת.
  6. ‫Apigee שולח את הבקשה לשרתי הקצה של מרכז הנתונים הפרטי דרך Cloud Interconnect.
  7. ‫Apigee שולח את הבקשה לשירותים של צד שלישי באמצעות הקצאה של כתובת IP של Apigee NAT.

שימוש ב-WAAP

כדי לשפר עוד יותר את פרופיל האבטחה, אפשר גם להשתמש ב-WAAP, שמשלב בין Cloud Armor,‏ reCAPTCHA ו-Apigee כדי לעזור להגן על המערכת מפני מתקפות DDoS ובוטים. הוא גם מספק הגנה על WAF ו-API.

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

בתרשים הבא מוצג תהליך העבודה:

תהליך הבקשה ל-WAAP.

תהליך הבקשה בתרשים שלמעלה הוא כזה:

  • ‫(1) כל בקשות ה-HTTP(S) של לקוחות וצרכני API נשלחות למאזן העומסים של אפליקציות החיצוני.
  • ‫(2) נקודת הקשר הראשונה בנוגע לפתרון WAAP היא Cloud Armor.
  • ‫(2א) אם אף אחד מהכללים האלה לא מופעל על ידי מדיניות Cloud Armor, בקשה נשלחת אל reCAPTCHA API כדי להעריך אם התנועה הנכנסת היא בקשה לגיטימית או לא.
  • ‫(3א) אם הבקשה לגיטימית, היא מועברת אל הקצה העורפי.
  • ‫(2ב) אם הבקשה לא לגיטימית, Cloud Armor יכול לדחות את הבקשה ולשלוח למשתמש קוד תגובה 403.
  • ‫(3ב) בכל בקשת API, אחרי שכללי OWASP של Cloud Armor וההגנה מפני DDoS נבדקים, הבקשה מועברת אל Apigee כדי לבדוק את התוקף שלה.
  • ‫(4) מערכת Apigee קובעת אם מפתחות ה-API או טוקני הגישה שמשמשים בבקשה תקפים. אם מערכת Apigee קובעת שהבקשה לא לגיטימית, היא יכולה לשלוח קוד תגובה 403.
  • ‫(5) אם הבקשה לגיטימית, Apigee מעביר את הבקשה אל ה-Backend.

בתרשים הבא מוצגת הארכיטקטורה של WAAP עם Cloud Armor,‏ reCAPTCHA ו-Apigee לבקשות API.

זרימת הבקשות ל-WAAP עם Cloud Armor,‏ reCAPTCHA ו-Apigee.

תהליך הבקשה בתרשים שלמעלה הוא כזה:

  1. הלקוח שולח את הבקשה אל מאזן העומסים החיצוני של אפליקציות (ALB) עם פרטי הכניסה לאפליקציה – לדוגמה, מפתח, טוקן או אישור.
  2. מאחר ש-Cloud Armor מופעל במאזן העומסים החיצוני של האפליקציות, Cloud Armor בוחר את הבקשה. המערכת אוכפת ומעריכה את כל הכללים ומדיניות שהוגדרו. אם יש הפרה של כלל כלשהו, Cloud Armor דוחה את הבקשה עם הודעת שגיאה וקוד סטטוס.
  3. לגבי קריאות באתר כמו שליחת טופס בדף כניסה,‏ Cloud Armor משולב עם reCAPTCHA.‏ reCAPTCHA מעריך את התנועה הנכנסת ומוסיף ציוני סיכון לתנועה לגיטימית. לגבי תנועה לא לגיטימית, ‏ Cloud Armor יכול לדחות את הבקשה.
  4. אם אין הפרות של כללי Cloud Armor, מאזן העומסים החיצוני של האפליקציות מנתב את בקשת ה-API אל Apigee.
  5. מערכת Apigee מעבדת את הבקשה, מבצעת את מדיניות האבטחה ומאשרת או דוחה את הבקשה. אפשר להשתמש ב-Apigee גם כדי להפנות את הבקשה לשרתי קצה עורפיים שונים על סמך הלקוח, הבקשה או שניהם.
  6. ‫Apigee מעביר את הבקשה לשרתי הקצה העורפיים של GKE ישירות דרך כתובות IP פנימיות. התקשורת בין Apigee לבין שירות העברת הכספים יכולה להתבצע דרך כתובת RFC 1918, שהיא כתובת IP פנימית, כי שניהם נמצאים ברשת שכנה.
  7. ‫Apigee שולח את הבקשה לשרתי הקצה של מרכז הנתונים הפרטי דרך Cloud Interconnect.
  8. ‫Apigee שולח את הבקשה לשירותים של צד שלישי דרך הקצאת כתובות IP של Apigee NAT.

שימוש ב-Cloud CDN לשמירה במטמון

‫Cloud CDN משתמש ברשת הגלובלית של Google כדי להציג תוכן באמצעות שרתים שנמצאים במיקום קרוב יותר אל המשתמשים, לצורך האצת זמני התגובה של אתרים ואפליקציות. Cloud CDN מציע גם יכולות שמירה במטמון שעוזרות לאבטח את ה-Backend על ידי החזרת התגובה מהמטמון שלו. שמירת נתונים שמתבצעת לעיתים קרובות בGoogle Front End‏ (GFE), שנמצא בקצה של רשת Google, מאפשרת לשמור את הנתונים קרוב ככל האפשר למשתמשים ולספק גישה מהירה ככל האפשר.

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

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

זרימת הבקשות עם Cloud CDN.

תהליך הבקשה שמוצג בתרשים שלמעלה:

  1. הלקוח משתמש בספריות reCAPTCHA כדי לקבל אסימון ושולח את הבקשה למאזן העומסים החיצוני של האפליקציות עם פרטי הכניסה לאפליקציה – למשל, מפתח, אסימון או אישור.
  2. ‫Cloud CDN בודק את המטמון באמצעות מפתח המטמון ומחזיר את התגובה אם הפגיעה במטמון היא חיובית.
  3. אם התוצאה של הפגיעה במטמון היא false, ‏ Cloud Armor מסנן את הבקשה כי מאזן העומסים החיצוני של האפליקציות מפעיל את Cloud Armor. ‏ Cloud Armor אוכף ומעריך את כל הכללים ומדיניות האבטחה שהוגדרו. אם יש הפרה של כלל כלשהו, הוא דוחה את הבקשה עם הודעת שגיאה וקוד סטטוס.
  4. ‫Cloud Armor משולב עם reCAPTCHA, שמעריך את תנועת הגלישה הנכנסת הלגיטימית באמצעות ציוני סיכון. אם תנועת הגלישה לא לגיטימית, Cloud Armor יכול לדחות את הבקשה.
  5. אם אין הפרות של כללי Cloud Armor, מאזן העומסים החיצוני של האפליקציות מנתב את הבקשה אל Apigee.
  6. מערכת Apigee מעבדת את הבקשה, מבצעת את מדיניות האבטחה כפי שמתואר במאמר ניהול API ב-Apigee, ומאשרת או דוחה את הבקשה. אפשר להשתמש בה גם כדי לנתב את הבקשה לשרתי קצה עורפיים שונים על סמך הלקוח, הבקשה או שניהם.
  7. ‫Apigee מעביר את הבקשה לשרתי הקצה העורפיים של GKE ישירות דרך כתובות IP פנימיות. התקשורת בין Apigee לבין שירות העברת הכספים יכולה להתבצע דרך כתובת RFC 1918, שהיא כתובת IP פנימית, כי הם נמצאים ברשת המקושרת.
  8. ‫Apigee שולח את הבקשה לשרתי הקצה של מרכז הנתונים הפרטי דרך Cloud Interconnect.
  9. ‫Apigee שולח את הבקשה לשירותים של צד שלישי באמצעות הקצאה של כתובת IP של Apigee NAT.
  10. כשמוחזרת תגובה ללקוח, Cloud CDN שומר אותה במטמון כדי שיוכל להחזיר את התגובה מהמטמון לשיחות עתידיות.

המאמרים הבאים