יצירת כללים לחומת האש ב-App Engine

ב-App Engine, אפשר ליצור חומת אש עם עד 1,000 כללים נפרדים עם עדיפות, שמאפשרים או מגבילים טווח של כתובות IP ורשתות משנה. האפליקציה תגיב רק לבקשות שמותרות על ידי חומת האש.

כדי ללמוד איך חומת האש של App Engine פועלת, ראו מידע נוסף על חומות אש.

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

כדי ליצור כללים בחומת האש של App Engine לאפליקציה, צריך להיות לכם אחד מתפקידי ה-IAM של App Engine הבאים, שכוללים את ההרשאות הנדרשות ליצירה או לשינוי של כללים בחומת האש:

  • App Engine Admin
  • עריכה
  • בעלים

יצירת כללים לחומת האש

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

מסוף

משתמשים בדף Firewall rules (כללי חומת אש) במסוף Google Cloud כדי ליצור כלל חומת אש:

  1. נכנסים לדף Create a firewall rule במסוף Google Cloud :

    כניסה לדף יצירת כלל חומת אש

  2. מציינים את הפרטים של כלל חומת האש:

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

      הערכים החוקיים הם 1 עד 2147483646. הכלל הראשון שעובר הערכה הוא כלל העדיפות 1. עדיפות 2147483647 הוא הכלל האחרון שעובר הערכה והוא שמור לכלל `default`.

    2. בקטע פעולה במקרה של התאמה, מציינים אם לאפשר או לדחות בקשות שתואמות לכלל. כללים שהוגדרו לallow מעבירים את הבקשה לאפליקציה. כללים שהוגדרו לdeny מגיבים לבקשות עם שגיאת 403 Forbidden.
    3. בקטע טווח כתובות IP, מגדירים את טווח כתובות ה-IP שהכלל חל עליהן. צריך להגדיר את טווח כתובות ה-IP בסימון CIDR, והוא יכול לכלול מסכות של רשתות משנה. הטווח תומך ב-IPv4 וב-IPv6.
    4. אופציונלי: בשדה Description, מוסיפים תיאור של הכלל באורך של עד 100 תווים.
  3. לוחצים על שמירה כדי ליצור את הכלל.
  4. בודקים את הכלל כדי לוודא שהעדיפות והפעולה מספקות את ההתנהגות הצפויה:
    1. לוחצים על בדיקת כתובת IP.
    2. מזינים את כתובת ה-IP שרוצים לאמת ולוחצים על בדיקה כדי לוודא שהכלל התואם מוערך בצורה נכונה.
gcloud

מריצים את הפקודות הבאות של gcloud app firewall-rules כדי ליצור כלל לחומת האש:

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

    ‫
    gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
     כאשר:
    • ‫PRIORITY הוא מספר שלם בין 1 ל-2147483646 שמגדיר את החשיבות של הכלל ואת הסדר שבו הכלל מוערך. העדיפות 1 היא הכלל הראשון שעובר הערכה. העדיפות 2147483647 היא הכלל האחרון שמוערך והיא שמורה לכלל `default`.
    • ALLOW_OR_DENY מציין אם לאשר או לדחות גישה לבקשות שתואמות לכלל. הערכים התקינים הם allow או deny. כללים שהוגדרו לallow מעבירים את הבקשה לאפליקציה. כללים שהוגדרו לdeny מגיבים לבקשות עם שגיאת 403 Forbidden.
    • ההגדרה IP_RANGE מגדירה את טווח כתובות ה-IP שהכלל חל עליהן. טווח כתובות ה-IP צריך להיות מוגדר בסימון CIDR, יכול לכלול מסכות של תת-רשתות ותומך ב-IPv4 וב-IPv6.
    • ‫DESCRIPTION הוא תיאור אופציונלי של הכלל, באורך של עד 100 תווים.
  2. מריצים את הפקודה הבאה כדי לבדוק את הכלל ולוודא שהעדיפות והפעולה מספקות את ההתנהגות הצפויה: 
    gcloud app firewall-rules test-ip IP_ADDRESS
     כאשר IP_ADDRESS היא כתובת ה-IP שרוצים לבדוק ביחס לחומת האש.
  3. מריצים את הפקודה הבאה כדי להציג רשימה של הכללים הקיימים: 
    gcloud app firewall-rules list
  4. מריצים את הפקודה הבאה כדי למחוק כלל קיים:
    ‫
    gcloud app firewall-rules delete PRIORITY
     כאשר PRIORITY הוא ערך העדיפות של הכלל שרוצים למחוק.
דוגמאות:
הדוגמאות הבאות יעזרו לכם ליצור את חומת האש:

  • מוסיפים כלל שמאפשר כתובת IPv6 ומסכת רשת משנה, ואז בודקים את הכלל כדי לוודא שהוא נבדק לפני הכללים האחרים: 

    gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow
gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778

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

    gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny
gcloud app firewall-rules test-ip 74.125.0.8

  • מעדכנים את כלל ברירת המחדל ואז בודקים אותו כדי לוודא שהוא מגביל את כל כתובות ה-IP שלא תואמות לכללים אחרים: 

    gcloud app firewall-rules update default --action deny
gcloud app firewall-rules test-ip 123.456.7.89
API

כדי ליצור באופן פרוגרמטי כללים לחומת האש באפליקציית App Engine, אפשר להשתמש בשיטות apps.firewall.ingressRules ב-Admin API.

כדי לבדוק כלל חומת אש ולוודא שהעדיפות והפעולה מספקות את ההתנהגות הצפויה, אפשר להשתמש בשיטה apps.firewall.ingressRules.list ולציין את כתובת ה-IP שרוצים לבדוק בפרמטר matchingAddress.

הסבר על כללים לחומת אש ב-App Engine

חומת אש של App Engine מורכבת מרשימה מסודרת של כללים שיכולים לאפשר או לדחות גישה לאפליקציה מכתובת IP או מטווח כתובות IP שצוינו. הכלל חל על כל המשאבים של אפליקציית App Engine.

עדיפות של כלל חומת אש

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

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

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

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

בדוגמה של חומת האש שבהמשך מוצג איך שינוי של העדיפות של כלל יכול לשנות את ההתנהגות של חומת האש.

חומת אש לדוגמה

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

עדיפות פעולה טווח כתובות IP תיאור
1000 דחייה 192.0.2.1 דחיית הגישה של תוקף מסוג DoS.
2000 אישור 198.51.100.2 מאפשרת גישה למהנדס במשרד הלוויין.
3000 דחייה 198.51.100.0/24 הגישה לכל המבנים שאינם הנדסיים נחסמת.
5,000 אישור 203.0.113.0/24 מאפשרת גישה לרשת של הבניין הראשי.
2147483647 דחייה * פעולת ברירת מחדל

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

  • הבקשה מ-198.51.100.2 תואמת לכלל עם עדיפות 2000 ומותרת.
  • הבקשה מכתובת 198.51.100.100 תואמת לכלל עם עדיפות 3000 ונדחית.
  • הבקשה מכתובת 203.0.113.54 תואמת לכלל עם עדיפות 5000 ומותרת.
  • הבקשה מכתובת 45.123.35.242 תואמת לכלל ברירת המחדל ונדחית.

פתרון של כללים סותרים

לדוגמה, נניח ששני סדרי העדיפויות בחומת האש של החברה הוחלפו. אם מחליפים בין הכללים בעדיפויות 2000 ו-3000, אפשר לראות את ההתנהגות הלא מכוונת.

עדיפות פעולה טווח כתובות IP תיאור
1000 דחייה 192.0.2.1 דחיית הגישה של תוקף מסוג DoS.
2000 דחייה 198.51.100.0/24 שלילת הגישה לכל המבנים שאינם הנדסיים.
3000 אישור 198.51.100.2 מאפשרת גישה למהנדס במשרד הלוויין.
5,000 אישור 203.0.113.0/24 מאפשרת גישה לרשת של הבניין הראשי.
2147483647 דחייה * פעולת ברירת מחדל

המהנדס במשרד הלוויין לא יוכל לגשת לאפליקציה של החברה, כי העדיפות החדשה של הכלל אומרת שהוא אף פעם לא יוערך. כתובת ה-IP של המהנדס 198.51.100.2 תואמת לכלל שחוסם את כל מי שלא מהנדס בטווח 198.51.100.0/24 לפני הכלל שמאפשר גישה לכתובת ה-IP של המהנדס.

כדי לתקן את הבעיה, צריך להגדיר את העדיפות של הכלל שמאפשר גישה ל-198.51.100.2 כגבוהה יותר מהעדיפות של הכלל שחוסם גישה לטווח כתובות ה-IP‏ 198.51.100.0/24.

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

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