כללי חומת אש ב-VPC

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

כללי חומת אש של VPC מאפשרים או מונעים חיבורים אל מכונות וירטואליות (VM) ברשת ה-VPC או מהן. כללי חומת האש ב-VPC שמופעלים תמיד נאכפים, ומגנים על המכונות ללא קשר להגדרה ולמערכת ההפעלה שלהן, גם אם הן לא הופעלו.

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

למידע נוסף על חומות אש, ראו חומת אש (מחשוב).

שיטות מומלצות לכללי חומת אש

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

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

    כללי חומת אש ב- Google Cloud

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

    אפשר ליצור או לשנות כללי חומת אש של VPC באמצעותGoogle Cloud console,‏ Google Cloud CLI ו-API בארכיטקטורת REST. כשיוצרים או משנים כלל של חומת אש, אפשר לציין את המופעים שאליהם הכלל אמור לחול באמצעות פרמטר היעד של הכלל. דוגמאות לכללים של חומת האש מופיעות במאמר דוגמאות אחרות להגדרות.

    בנוסף לכללי חומת האש שאתם יוצרים, Google Cloud יש כללים אחרים שיכולים להשפיע על חיבורים נכנסים (ingress) או יוצאים (egress):

    • Google Cloud חוסמת או מגבילה תנועה מסוימת. מידע נוסף זמין במאמר בנושא תנועה חסומה ומוגבלת.

    • ‫Google Cloud תמיד מאפשר תקשורת בין מכונה וירטואלית לבין שרת המטא-נתונים התואם שלה בכתובת 169.254.169.254. מידע נוסף זמין במאמר בנושא תנועה שתמיד מותרת.

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

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

    מפרטים

    כללי חומת אש ב-VPC כוללים את המאפיינים הבאים:

    • כל כלל חומת אש חל על חיבורים נכנסים (ingress) או יוצאים (egress), ולא על שניהם. מידע נוסף זמין במאמר בנושא כיוון החיבור.

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

    • כל כלל חומת אש יכול להכיל טווחים של IPv4 או של IPv6, אבל לא את שניהם.

    • הפעולה של כל כלל בחומת האש היא allow או deny. הכלל חל על חיבורים כל עוד הוא נאכף. לדוגמה, אפשר להשבית כלל לצורך פתרון בעיות.

    • כשיוצרים כלל לחומת אש, צריך לבחור רשת VPC. האכיפה של הכלל מתבצעת ברמת המכונה, אבל ההגדרה שלו משויכת לרשת VPC. כלומר, אי אפשר לשתף כללי חומת אש בין רשתות VPC, כולל רשתות שמקושרות באמצעות קישור בין רשתות VPC שכנות או באמצעות מנהרות Cloud VPN.

    • כללי חומת האש ב-VPC הם stateful:

      • אם החיבור מותר דרך חומת האש בשני הכיוונים, גם תנועת החזרה שתואמת לחיבור הזה מותרת. אי אפשר להגדיר כלל חומת אש כדי לחסום תנועה של תשובות משויכות.
      • תעבורת החזרה חייבת להיות זהה ל-5-tuple (כתובת IP של המקור, כתובת IP של היעד, יציאת המקור, יציאת היעד, פרוטוקול) של תעבורת הבקשות שאושרו, אבל עם כתובות ויציאות הפוכות של המקור והיעד.
      • ‫Google Cloud associates incoming packets with corresponding outbound packets by using a connection tracking table. חיבורי IPv4 תומכים בפרוטוקולים TCP,‏ UDP,‏ SCTP ו-ICMP. חיבורי IPv6 תומכים בפרוטוקולים TCP,‏ UDP,‏ SCTP ו-ICMPv6.
      • Google Cloud מיישם מעקב אחר חיבורים, בלי קשר לשאלה אם הפרוטוקול תומך בחיבורים. אם מותר ליצור חיבור בין מקור ליעד (במקרה של כלל כניסה) או בין יעד ליעד (במקרה של כלל יציאה), כל תנועת התגובה מותרת כל עוד מצב מעקב החיבורים של חומת האש פעיל. מצב המעקב של כלל חומת אש נחשב פעיל אם נשלח לפחות חבילת נתונים אחת כל 10 דקות.
      • כשמאפשרים חיבור מקוטע דרך חומת האש, Google Cloud משתמש במעקב אחר חיבורים כדי לאפשר רק את הקטע הראשון של תנועת החזרה. כדי לאפשר שברירים חוזרים, צריך להוסיף כלל חומת אש.
      • תעבורת נתונים של תגובות ICMP, כמו ICMP TYPE 3, DESTINATION UNREACHABLE, שנוצרת בתגובה לחיבור TCP/UDP מותר, מותרת דרך חומת האש. ההתנהגות הזו עקבית עם RFC 792.

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

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

      סוג המכונה של המופע מספר מקסימלי של חיבורים עם שמירת מצב
      סוגי מכונות עם ליבת מעבד משותפת 130,000
      Instances with 1–8 vCPUs ‫130,000 חיבורים לכל vCPU
      Instances with more than 8 vCPUs ‫1,040,000 (‎130,000×8) חיבורים בסך הכול

    פעולות משתמעות

    אם אף כלל של חומת אש ב-VPC לא חל על יעד, יכול להיות שתהליך ההערכה של כלל חומת האש יגיע לשלב האחרון. בשלב הזה, Cloud NGFW משתמש בפעולה משתמעת. הפעולה המשתמעת תלויה בכיוון התנועה ובסוג משאב היעד.

    מידע נוסף זמין במאמר בנושא תהליך ההערכה של כללי חומת האש.

    כללים שאוכלסו מראש ברשת שמוגדרת כברירת מחדל

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

    שם הכלל כיוון עדיפות טווחים של מקורות פעולה פרוטוקולים ויציאות תיאור
    default-allow-internal ingress 65534 10.128.0.0/9 allow tcp:0-65535
    udp:0-65535
    icmp         		מאפשר חיבורים נכנסים למכונות וירטואליות ממופעים אחרים באותה רשת VPC.
    default-allow-ssh ingress 65534 0.0.0.0/0 allow tcp:22 מאפשרת להתחבר למופעים באמצעות כלים כמו ssh,‏ scp או sftp.
    default-allow-rdp ingress 65534 0.0.0.0/0 allow tcp:3389 מאפשרת להתחבר למכונות באמצעות פרוטוקול Microsoft Remote Desktop ‏(RDP).
    default-allow-icmp ingress 65534 0.0.0.0/0 allow icmp מאפשרת לכם להשתמש בכלים כמו ping.

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

    תנועה חסומה ומוגבלת

    בנוסף לכללים של חומת האש ב-VPC ולמדיניות היררכית של חומת האש, Google Cloud השירות חוסם או מגביל תנועה מסוימת כמו שמתואר בטבלה הבאה.

    סוג תעבורה פרטים
    קצב החבילות ורוחב הפס

    האפליקציה הרלוונטית:

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

    פרטים נוספים זמינים במאמר רוחב פס ברשת במסמכי התיעוד של Compute Engine.
    הצעות ואישורים של DHCP

    האפליקציה הרלוונטית:

    • מנות נכנסות ליציאת UDP‏ 68 (DHCPv4)
    • מנות נכנסות ליציאת UDP‏ 546 (DHCPv6)
    		 ‫Google Cloud blocks incoming DHCP offers and acknowledgments from all sources except for DHCP packets coming from the metadata server.
    פרוטוקולים שנתמכים על ידי Google Cloud כתובות IP חיצוניות

    האפליקציה הרלוונטית:

    • מנות נכנסות לכתובות IP חיצוניות

    כתובות IPv4 ו-IPv6 חיצוניות מקבלות רק חבילות TCP,‏ UDP,‏ ICMP,‏ IPIP,‏ AH,‏ ESP,‏ SCTP ו-GRE. למשאבים שמשתמשים בכתובות IP חיצוניות יש הגבלות נוספות על פרוטוקולים:
    תנועה של SMTP (יציאה 25)

    האפליקציה הרלוונטית:

    • מנות יוצאות לכתובות IP חיצוניות ביציאת TCP ‏25

    כדי למנוע ספאם, כברירת מחדל Google Cloud חוסמת Google Cloud חבילות יוצאות שנשלחות ליעד של יציאת TCP ‏25 של כתובת IP חיצונית (כולל כתובת IP חיצונית של משאב אחר Google Cloud ). Google Cloud מסיר אוטומטית את החסימה הזו ברגע שהוא קובע שהסיכון שפרויקט ישלח נפחים גדולים של אימיילים דרך חיבורים לא מוצפנים הוא נמוך. Google Cloud לא כולל תנועת SMTP דרך TLS ביציאה 465 או 587 בחסימה הזו. כדי לבדוק אם הפרויקט מאפשר את התנועה הזו, עוברים לדף VPC networks או לדף Firewall policies במסוף Google Cloud . הודעת באנר בשני הדפים מציינת אם הפרויקט מאפשר את התנועה הזו. למידע נוסף, אפשר לפנות לGoogle Cloud מומחה מכירות.

    החסימה הזו לא חלה על חבילות יוצאות שנשלחות ליעד TCP port 25 של כתובת IP פנימית, כולל כתובת IP ציבורית בשימוש פרטי ברשת VPC או ברשת מקומית.

    אם תעבורת נתונים יוצאת (egress) של SMTP חיצוני ביציאה 25 מותרת בפרויקט שלכם, ואתם רוצים לשלוח תעבורת נתונים מהסוג הזה, צריך לעמוד בתנאים הנוספים הבאים:

    • כללי חומת האש לתעבורת נתונים יוצאת ברשת ה-VPC ומדיניות חומת האש ההיררכית שחלה על רשת ה-VPC צריכים לאפשר תעבורת נתונים יוצאת לכתובת ה-IP החיצונית ביציאת TCP ‏25. כללי היציאה המשתמעים עומדים בדרישה הזו כי הם מאפשרים יציאה לכל כתובת IP (ותשובות נכנסות שנוצרו מכתובות IP).
    • המסלול הרלוונטי ליעד חייב להשתמש בצעד הבא של שער האינטרנט שמוגדר כברירת מחדל. מסלולי ברירת המחדל שנוצרו על ידי המערכת עומדים בדרישה הזו.
    • המכונה ששולחת מנות לכתובת ה-IP החיצונית צריכה לעמוד בדרישות לגישה לאינטרנט.

    כדי למנוע יציאה של SMTP חיצונית, אפשר ליצור כללי חומת אש של VPC או מדיניות חומת אש היררכית שחוסמים יציאה.

    תנועה בלי הגבלת שימוש

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

    • חבילות שנשלחו אל שרת המטא-נתונים Google Cloud והתקבלו ממנו

    • מנות שנשלחות לכתובת IP שהוקצתה לאחד מממשקי הרשת (NIC) של המופע, שבהם המנות נשארות בתוך המכונה הווירטואלית עצמה. כתובות ה-IP שמוקצות ל-NIC של מופע כוללות:

      • כתובת ה-IPv4 הפנימית הראשית של כרטיס הרשת
      • כל כתובת IPv4 פנימית מטווח כתובות IP של כינוי של כרטיס ה-NIC
      • אם מוגדר IPv6 ברשת המשנה, כל אחת מכתובות ה-IPv6 שהוקצו לכרטיס הרשת
      • כתובת IPv4 פנימית או חיצונית שמשויכת לכלל העברה, לאיזון עומסים או להעברת פרוטוקולים, אם המכונה היא קצה עורפי של מאזן העומסים או מכונת יעד להעברת פרוטוקולים
      • כתובות לולאה חוזרת (loopback)
      • כתובות שמוגדרות כחלק מתוכנת שכבת-על של רשת שמופעלת בתוך המכונה עצמה

    Google Cloud שרת מטא-נתונים

    ‫Google Cloud מריץ שרת מטא-נתונים מקומי לצד כל מופע. אפשר לגשת לשרת בכתובת 169.254.169.254 (ל-IPv4) ובכתובת fd20:ce::254 (ל-IPv6). השרת הזה חיוני לפעולה של המופע, ולכן המופע יכול לגשת אליו בלי קשר לכללי חומת האש שהגדרתם. שרת המטא-נתונים מספק למופע את השירותים הבסיסיים הבאים:

    אינטראקציות עם מוצרים

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

    כללים לחומת אש ומאזני עומסים של העברת נתונים

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

    כללי חומת אש ומאזני עומסים של שרת proxy

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

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

    כללי חומת אש ו-Cloud VPN

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

    שערי Cloud VPN מקבלים רק חבילות של הפרוטוקולים והיציאות שמתוארים במפרט של Cloud VPN.

    כללי חומת אש ו-GKE

    ‫Google Kubernetes Engine יוצר ומנהל כללי חומת אש באופן אוטומטי כשיוצרים אשכול או משאבים באשכול (כולל שירותים ו-Ingress). מידע נוסף זמין במאמר כללים של חומת אש שנוצרו באופן אוטומטי במסמכי התיעוד של Google Kubernetes Engine.

    כללים לחומת אש ו-AI Hypercomputer

    אתם יכולים ליצור כללי חומת אש של VPC כשאתם יוצרים את רשתות ה-VPC שנדרשות ליצירת מכונות וירטואליות ב-AI Hypercomputer. משתמשים בכללי חומת האש כדי לציין את הפרוטוקולים והיציאות שמותרים לרשתות ה-VPC. מידע נוסף זמין במאמר סקירה כללית על AI Hypercomputer.

    רכיבים של כלל חומת אש

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

    • כיוון מנקודת המבט של היעד. הכיוון יכול להיות תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress).

    • priority – מספר שקובע אם הכלל יחול. המערכת מחילה רק את הכלל עם העדיפות הגבוהה ביותר (מספר העדיפות הנמוך ביותר) שהרכיבים האחרים שלו תואמים לתנועה, ומתעלמת מכללים סותרים עם עדיפויות נמוכות יותר.

    • פעולה במקרה של התאמה, allow או deny, שקובעת אם הכלל מאפשר או חוסם חיבורים.

    • סטטוס האכיפה של כלל חומת האש: אתם יכולים להפעיל ולהשבית כללים של חומת האש בלי למחוק אותם.

    • יעד, שמגדיר את המופעים (כולל אשכולות GKE ומופעים של סביבה גמישה ב-App Engine) שהכלל חל עליהם.

    • מסנן מקור או יעד למאפייני מנות.

    • הפרוטוקול (כמו TCP,‏ UDP או ICMP) ויציאת היעד.

    • אפשרות בוליאנית logs שמתעדת ביומן את החיבורים שתואמים לכלל ב-Cloud Logging.

    סיכום הרכיבים

    כלל לתעבורת נתונים נכנסת (ingress)
    עדיפות פעולה אכיפה פרמטר של יעד מסנני מקור ויעד פרוטוקולים ויציאות
    מספר שלם מ-0 עד 65535, כולל; ברירת המחדל היא 1000 allow או deny ‫enabled (ברירת מחדל) או disabled מציין את המקרים שבהם חבילות מתקבלות.

    מקורות לכללי תעבורת נתונים נכנסת (ingress)

    יעדים של כללי תעבורה נכנסת

    מציינים פרוטוקול או פרוטוקול ויציאת יעד.

    אם לא מגדירים את המדיניות, הכלל חל על כל הפרוטוקולים ועל יציאות היעד. מידע נוסף זמין במאמר בנושא פרוטוקולים ויציאות.
    כלל לתעבורת נתונים יוצאת (egress)
    עדיפות פעולה אכיפה פרמטר של יעד מסנני מקור ויעד פרוטוקולים ויציאות
    מספר שלם מ-0 עד 65535, כולל; ברירת המחדל היא 1000 allow או deny ‫enabled (ברירת מחדל) או disabled מציינת את המקרים שבהם חבילות נתונים נשלחות.

    מקורות לכללי תעבורת נתונים יוצאת (egress)

    יעדים לכללי תעבורת נתונים יוצאת (egress)

    מציינים פרוטוקול או פרוטוקול ויציאת יעד.

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

    כיוון התנועה

    אפשר ליצור כללים של חומת אש שחלים על תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress). אי אפשר להחיל כלל יחיד על תנועת נתונים נכנסת ויוצאת. אבל אפשר ליצור כמה כללים כדי להגדיר את תנועת הכניסה והיציאה שאתם מאשרים או חוסמים דרך חומת האש.

    • תנועה נכנסת מתארת מנות שנכנסות לממשק רשת של יעד.

    • תנועה יוצאת מתארת מנות שיוצאות מממשק רשת של יעד.

    • אם לא מציינים כיוון, Google Cloud משתמשת בתנועה נכנסת.

    עדיפות

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

    תכונה כלל מדיניות חומת אש כלל חומת אש של VPC
    טווח ‫0 עד 2,147,483,547 ‫0 עד 65,535
    מספר העדיפות שמוגדר כברירת מחדל ללא ‫1,000 (ברירת מחדל)
    ייחודיות חייב להיות ייחודי במסגרת המדיניות אפשר לשתף בין כללים

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

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

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

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

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

    דוגמה: קיימים שני כללים לחומת האש:

    • כלל כניסה ממקורות 0.0.0.0/0 (כל כתובת IPv4) שחל על כל היעדים, כל הפרוטוקולים וכל יציאות היעד, עם פעולה deny ועדיפות 1000.

    • כלל תעבורת נתונים נכנסת ממקורות 0.0.0.0/0 (כל כתובת IPv4) שחל על יעדים ספציפיים עם תג הרשת webserver, לתעבורה ב-TCP 80, עם פעולה allow.

    העדיפות של הכלל השני קובעת אם תנועת TCP ליציאה 80 מותרת ליעדי webserver:

    • אם העדיפות של הכלל השני מוגדרת למספר גדול מ 1000, העדיפות שלו נמוכה יותר, ולכן הכלל הראשון שדוחה את כל התנועה חל.

    • אם העדיפות של הכלל השני מוגדרת כ-1000, לשני הכללים יש עדיפות זהה, ולכן חל הכלל הראשון שחוסם את כל התנועה.

    • אם העדיפות של הכלל השני מוגדרת למספר נמוך מ-1000, העדיפות שלו גבוהה יותר, ולכן הוא מאפשר תנועה ב-TCP 80 ליעדים webserver. אם אין כללים אחרים, הכלל הראשון עדיין יחסום סוגים אחרים של תנועה ליעדי webserver, והוא גם יחסום את כל התנועה, כולל TCP 80, למופעים ללא תג הרשת webserver.

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

    פעולה במקרה של התאמה

    רכיב הפעולה של כלל חומת האש קובע אם הכלל מתיר או חוסם תעבורה, בהתאם לרכיבים האחרים של הכלל:

    • פעולת allow מאפשרת חיבורים שתואמים לרכיבים האחרים שצוינו.

    • deny פעולה חוסמת חיבורים שתואמים לרכיבים האחרים שצוינו.

    אכיפה

    אפשר לבחור אם כלל חומת האש יאכף על ידי הגדרת המצב שלו ל-enabled או ל-disabled. מגדירים את מצב האכיפה כשיוצרים כלל או כשמעדכנים כלל.

    אם לא מגדירים מצב אכיפה כשיוצרים כלל חומת אש חדש, כלל חומת האש מוגדר אוטומטית למצב enabled.

    תרחישים לדוגמה

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

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

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

    השפעות על תנועה קיימת

    כשמשנים את מצב האכיפה של כלל חומת אש, יוצרים כלל חדש של enforced או משנים כללים של חומת אש כדי לדחות תעבורה שאושרה קודם, Cloud NGFW אוכף את השינוי הזה רק על חיבורים חדשים. החיבורים הקיימים יישארו, והתעבורה שמשויכת אליהם לא תושפע.

    פרוטוקולים ויציאות

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

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

    אפשר להשתמש בשמות הפרוטוקולים הבאים בכללי חומת האש: tcp,‏ udp,‏ icmp (ל-IPv4 ICMP),‏ esp,‏ ah,‏ sctp ו-ipip. בכל שאר הפרוטוקולים, צריך להשתמש במספרי הפרוטוקולים של IANA.

    הרבה פרוטוקולים משתמשים באותו שם ובאותו מספר גם ב-IPv4 וגם ב-IPv6, אבל יש פרוטוקולים, כמו ICMP, שלא משתמשים באותו שם ובאותו מספר.

    אין תמיכה בפרוטוקול IPv6 Hop-by-Hop בכללי חומת האש.

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

    מפרט דוגמה הסבר
    אין פרוטוקול ויציאה — אם לא מציינים פרוטוקול, כלל חומת האש חל על כל הפרוטוקולים ועל יציאות היעד הרלוונטיות שלהם.
    פרוטוקול tcp אם מציינים פרוטוקול בלי פרטי יציאה, כלל חומת האש חל על הפרוטוקול הזה ועל כל היציאות הרלוונטיות שלו.
    פרוטוקול ויציאה יחידה tcp:80 אם מציינים פרוטוקול ויציאת יעד אחת, כלל חומת האש חל על יציאת היעד של הפרוטוקול.
    פרוטוקול וטווח יציאות tcp:20-22 אם מציינים פרוטוקול וטווח יציאות, כלל חומת האש חל על טווח יציאות היעד של הפרוטוקול.
    שילובים icmp,tcp:80
    tcp:443
    udp:67-69    		 אפשר לציין שילובים שונים של פרוטוקולים ויציאות יעד שכלל חומת האש חל עליהם. מידע נוסף זמין במאמר יצירת כללים של חומת אש.

    יעד, מקור, יעד

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

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

    פרמטר של יעד

    הפרמטר target מזהה את ממשקי הרשת של מופעי Compute Engine, כולל צומתי GKE ומופעים של הסביבה הגמישה של App Engine.

    אפשר להגדיר את היעדים הבאים לכללים של תעבורת נתונים נכנסת (ingress) או יוצאת (egress). הפרמטרים target,‏ source ו-destination פועלים יחד כמו שמתואר במאמר מקור, יעד, טירגוט.

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

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

    • Instances by target service accounts (מופעים לפי חשבונות שירות של היעד). כלל חומת האש חל רק על מקרים עם ממשקי רשת ברשת ה-VPC של כלל חומת האש, אם המקרים משתמשים בחשבון שירות שתואם לפחות לאחד מחשבונות השירות של יעד כלל חומת האש. למידע על המספר המקסימלי של חשבונות שירות יעד שאפשר לציין לכל כלל של חומת אש, אפשר לעיין במאמר מגבלות לכל כלל של חומת אש.

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

    יעדים וכתובות IP לכללים לתעבורת נתונים נכנסת (ingress)

    העיבוד של המנות שמנותבות לממשק הרשת של מכונת יעד וירטואלית מתבצע על סמך התנאים הבאים:

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

    • אם כלל חומת האש של התנועה הנכנסת לא כולל טווח כתובות IP ליעד, היעד של המנה צריך להיות זהה לאחת מכתובות ה-IP הבאות:

      • כתובת ה-IPv4 הפנימית הראשית שהוקצתה ל-NIC של המכונה.

      • כל טווח כתובות IP של כינוי שהוגדר בכרטיס הרשת של המופע.

      • כתובת ה-IPv4 החיצונית שמשויכת ל-NIC של המכונה.

      • אם מוגדר IPv6 ברשת המשנה, כל אחת מכתובות ה-IPv6 שהוקצו ל-NIC.

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

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

      • כתובת IP בטווח היעד של מסלול סטטי בהתאמה אישית שמשתמש במכונה הווירטואלית כצעד הבא (next-hop-instance או next-hop-address).

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

    יעדים וכתובות IP לכללים לתעבורת נתונים יוצאת (egress)

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

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

      • כתובת ה-IPv4 הפנימית הראשית של כרטיס הרשת של המכונה.

      • כל טווח כתובות IP של כינוי שהוגדר בכרטיס ה-NIC של מופע.

      • אם מוגדר IPv6 ברשת המשנה, כל אחת מכתובות ה-IPv6 שהוקצו ל-NIC.

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

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

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

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

    פרמטר של מקור

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

    מקורות לכללים לתעבורת נתונים נכנסת (ingress)

    אפשר להשתמש במקורות הבאים לכללים של חומת אש לתעבורה נכנסת:

    • טווח ברירת המחדל של המקור: כשמשמיטים את הגדרת המקור בכלל כניסה,Google Cloud משתמש בטווח כתובות IPv4 של ברירת המחדל של המקור 0.0.0.0/0 (כל כתובת IPv4). ערך ברירת המחדל לא כולל מקורות IPv6.

    • טווחים של כתובות IPv4 של המקור: רשימה של כתובות IPv4 בפורמט CIDR.

    • טווחים של כתובות IPv6 של המקור: רשימה של כתובות IPv6 בפורמט CIDR.

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

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

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

      • שילוב של טווחים של כתובות IPv4 של המקור ותגי רשת של המקור.
      • שילוב של טווחים של כתובות IPv6 של המקור ותגי רשת של המקור.
      • שילוב של טווחים של כתובות IPv4 של המקור וחשבונות שירות של המקור.
      • שילוב של טווחים של כתובות IPv6 של המקור וחשבונות שירות של המקור.

    איך תגי רשת של מקור וחשבונות שירות של מקור מרמזים על מקורות של מנות

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

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

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

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

    בנוסף לציון ממשק רשת, כשכלל חומת אש של תעבורת נכנס משתמש בתג רשת של מקור או בחשבון שירות של מקור, חבילות שמועברות מממשק הרשת של המכונה הווירטואלית חייבות להשתמש באחת מכתובות ה-IP המקוריות התקפות הבאות:

    • כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת הזה.
    • כל כתובות ה-IPv6 שהוקצו לממשק הרשת הזה.

    אם כלל חומת אש של תעבורת נתונים נכנסת (ingress) מכיל גם טווחים של כתובות IP ליעד, ממשק הרשת שקשור לתג רשת יומר לאותה גרסת IP כמו טווח כתובות ה-IP של היעד.

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

    מקורות לכללים לתעבורת נתונים יוצאת (egress)

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

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

    • טווחי IPv4 של המקור. רשימה של כתובות IPv4 בפורמט CIDR.

    • טווחי IPv6 של המקור. רשימה של כתובות IPv6 בפורמט CIDR.

    כדי להוסיף טווחים של כתובות IP של מקור לכללי תעבורת נתונים יוצאת (egress), צריך לפעול לפי ההנחיות הבאות:

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

    • אם מציינים גם פרמטרים של מקור וגם פרמטרים של יעד בכלל יציאה, צריך להשתמש באותה גרסת IP לשני הפרמטרים. אפשר להשתמש בטווח כתובות IPv4 או בטווח כתובות IPv6, אבל לא בשניהם. פרטים נוספים מופיעים במאמר בנושא יעדים לכללי תעבורת נתונים יוצאת (egress).

    פרמטר יעד

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

    יעדים לכללי תעבורת נתונים נכנסת (ingress)

    אפשר להשתמש ביעדים הבאים לכללים של חומת אש לתעבורה נכנסת:

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

    • טווחי IPv4 של היעד. רשימה של כתובות IPv4 בפורמט CIDR.

    • טווחי IPv6 של היעד. רשימה של כתובות IPv6 בפורמט CIDR.

    כדי להוסיף טווחים של כתובות IP ליעד לכללי תעבורה נכנסת, צריך לפעול לפי ההנחיות הבאות:

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

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

    יעדים לכללים לתעבורת נתונים יוצאת (egress)

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

    • טווח יעד שמוגדר כברירת מחדל כשמשמיטים את הגדרת היעד בכלל יציאה, Google Cloud משתמשים בטווח כתובות IPv4 של היעד שמוגדר כברירת מחדל0.0.0.0/0 (כל כתובת IPv4). ערך ברירת המחדל לא כולל יעדי IPv6.

    • טווחי IPv4 של היעד. רשימה של כתובות IPv4 בפורמט CIDR.

    • טווחי IPv6 של היעד. רשימה של כתובות IPv6 בפורמט CIDR.

    סינון של מקור ויעד לפי חשבון שירות

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

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

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

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

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

    סינון לפי חשבון שירות לעומת תג רשת

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

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

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

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

    אי אפשר לשלב בין חשבונות שירות ותגי רשת בכל כלל חומת אש:

    • אי אפשר להשתמש יחד בחשבונות שירות ליעד ובתגי רשת ליעד בכל כלל חומת אש (תנועה נכנסת או יוצאת).

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

      יעדים מקורות לא תקינים
      תגי טירגוט לרשת חשבונות שירות של המקור

      שילוב של טווחי כתובות IP של המקור וחשבונות שירות של המקור
      חשבון שירות יעד תגי רשת של המקור

      שילוב של טווחי כתובות IP של המקור ותגי רשת של המקור

    הנה כמה שיקולים תפעוליים לגבי חשבונות שירות ותגי רשת:

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

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

    • אם מזהים מכונות באמצעות תג רשת, כלל חומת האש חל על כתובת ה-IP הפנימית הראשית של המכונה.

    • כללי חומת האש של חשבון השירות חלים על הצומת של GKE ולא על ה-Pod של GKE.

    תפקידים והרשאות

    בטבלה הבאה מתוארות הרשאות ה-IAM שנדרשות כדי לעבוד עם כללי חומת אש של VPC.

    משימה ההרשאה הנדרשת תפקיד לדוגמה
    יצירת כלל לחומת האש compute.firewalls.create תפקיד Security Admin ב-Compute (roles/compute.securityAdmin)
    מחיקת כלל לחומת האש compute.firewalls.delete Security Admin ב-Compute
    (roles/compute.securityAdmin)
    ביצוע שינויים בכללים של חומת האש compute.firewalls.update תפקיד Security Admin ב-Compute (roles/compute.securityAdmin)
    הצגת פרטים על כלל חומת אש compute.firewalls.get צפייה ברשת ב-Compute (roles/compute.networkViewer)
    הצגת רשימה של כללים לחומת האש compute.firewalls.list צפייה ברשת ב-Compute (roles/compute.networkViewer)

    תרחישים לדוגמה

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

    מקרים של תעבורת נתונים נכנסת (ingress)

    כללי חומת אש לתעבורה נכנסת (ingress) שולטים בחיבורים נכנסים ממקור למופעי יעד ברשת ה-VPC. המקור של כלל תעבורה נכנסת יכול להיות אחד מהבאים:

    • טווח של כתובות IPv4 או IPv6. ברירת המחדל היא כל כתובת IPv4‏ (0.0.0.0/0)
    • מכונות וירטואליות אחרות ברשת ה-VPC שזוהו באמצעות תגי רשת
    • מכונות וירטואליות אחרות ברשת ה-VPC שזוהו על ידי חשבון שירות
    • מקרים אחרים ברשת ה-VPC שזוהו לפי טווח של כתובות IPv4 או IPv6 וגם לפי תג רשת
    • מכונות אחרות ברשת ה-VPC שלכם שמזוהות לפי טווח של כתובות IPv4 או IPv6 וגם לפי חשבון שירות

    מקור ברירת המחדל הוא כל כתובת IPv4‏ (0.0.0.0/0). אם רוצים לשלוט בחיבורים נכנסים ממקורות מחוץ לרשת ה-VPC, כולל מקורות אחרים באינטרנט, צריך להשתמש בטווח של כתובות IP בפורמט CIDR.

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

    דוגמאות ל-Ingress

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

    בדוגמה הזו של רשת VPC, כללי חומת האש שמאפשרים תעבורת נתונים נכנסת (ingress) מבטלים את כלל ברירת המחדל שחוסם תעבורת נתונים נכנסת (ingress) עבור חלק מהמכונות הווירטואליות.
    איור 1. בדוגמה הזו של רשת VPC, כללי חומת האש שמאפשרים תעבורה נכנסת מבטלים את כלל הדחייה המרומז של תעבורה נכנסת עבור חלק מהמכונות הווירטואליות (אפשר ללחוץ כדי להגדיל).

    • כלל תנועה נכנסת עם עדיפות 1000 חל על מכונה וירטואלית 1. הכלל הזה מאפשר תעבורת TCP נכנסת מכל מקור IPv4‏ (0.0.0.0/0). תעבורת TCP ממכונות אחרות ברשת ה-VPC מותרת, בכפוף לכללי היציאה הרלוונטיים למכונות האחרות האלה. ל-VM 4 יש אפשרות לתקשר עם VM 1 באמצעות TCP כי ל-VM 4 אין כלל תעבורת נתונים יוצאת (egress) שחוסם תקשורת כזו (רק כלל התעבורה היוצאת המשתמע חל). מכיוון של-VM 1 יש כתובת IP חיצונית, הכלל הזה מאפשר גם תעבורת TCP נכנסת ממארחים חיצוניים באינטרנט ומ-VM 2 דרך כתובות IP חיצוניות.

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

    • כלל לתעבורת נתונים נכנסת (ingress) עם עדיפות 1000 חל על מכונה וירטואלית 3. הכלל הזה מאפשר תעבורת TCP ממופעים ברשת עם תג הרשת client, כמו VM 4. תעבורת TCP ממכונה וירטואלית 4 אל מכונה וירטואלית 3 מותרת כי מכונה וירטואלית 4 לא כוללת כלל יציאה שחוסם תקשורת כזו (רק כלל היציאה המשתמע חל). מכיוון של-VM 3 אין כתובת IP חיצונית, אין נתיב אליה ממארחים חיצוניים באינטרנט.

    פניות בנושא תעבורת נתונים יוצאת (egress)

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

    לכל כלל יציאה צריך להיות יעד. יעד ברירת המחדל הוא כל כתובת IPv4 ‏ (0.0.0.0/0), אבל אפשר ליצור יעד ספציפי יותר באמצעות טווח של כתובות IPv4 או IPv6 בפורמט CIDR. כשמציינים טווח של כתובות IP, אפשר לשלוט בתעבורת הנתונים למופעים ברשת וליעדים מחוץ לרשת, כולל יעדים באינטרנט.

    דוגמאות לתעבורת נתונים יוצאת (egress)

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

    בדוגמה הזו של רשת VPC, כללי חומת האש שחוסמים תעבורת נתונים יוצאת מבטלים את הכלל המשתמע שמאפשר תעבורת נתונים יוצאת עבור חלק מהמכונות הווירטואליות.
    איור 2. בדוגמה הזו של רשת VPC, כללי חומת האש שחוסמים תעבורה יוצאת מבטלים את הכלל המשתמע שמאפשר תעבורה יוצאת עבור חלק מהמכונות הווירטואליות (אפשר ללחוץ כדי להגדיל).

    • ל-VM 1 לא הוגדר כלל ספציפי לחומת אש לתעבורת נתונים יוצאת, ולכן כלל ברירת המחדל המשתמע לתעבורת נתונים יוצאת מאפשר לו לשלוח תעבורה לכל יעד. מותרות התחברויות למופעים אחרים ברשת ה-VPC, בכפוף לכללי הכניסה הרלוונטיים למופעים האחרים האלה. מכונה וירטואלית 1 יכולה לשלוח תעבורה אל מכונה וירטואלית 4 כי מכונה וירטואלית 4 כוללת כלל של תעבורת נתונים נכנסת (ingress) שמאפשר תעבורה נכנסת מכל טווח של כתובות IP. מכיוון של-VM 1 יש כתובת IP חיצונית, היא יכולה לשלוח תעבורת נתונים למארחים חיצוניים באינטרנט. תגובות נכנסות לתעבורה שנשלחת על ידי מכונה וירטואלית 1 מורשות כי כללי חומת האש הם עם שמירת מצב.

    • כלל לתעבורת נתונים יוצאת (egress) עם עדיפות 1000 חל על מכונה וירטואלית 2. הכלל הזה חוסם את כל תעבורת הנתונים היוצאת לכל יעדי ה-IPv4 ‏ (0.0.0.0/0). תעבורת נתונים יוצאת למופעים אחרים ברשת ה-VPC נחסמת, ללא קשר לכללי הכניסה שחלים על המופעים האחרים. למרות של-VM 2 יש כתובת IP חיצונית, כלל חומת האש הזה חוסם את התעבורה היוצאת שלה למארחים חיצוניים באינטרנט.

    • כלל לתעבורת נתונים יוצאת (egress) עם עדיפות 1000 חל על מכונה וירטואלית 3. הכלל הזה חוסם את תעבורת ה-TCP היוצאת לכל יעד בטווח כתובות ה-IP‏ 192.168.1.0/24. למרות שכללי הכניסה של מכונה וירטואלית 4 מאפשרים את כל התנועה הנכנסת, מכונה וירטואלית 3 לא יכולה לשלוח תנועת TCP אל מכונה וירטואלית 4. עם זאת, VM 3 יכול לשלוח תעבורת UDP ל-VM 4 כי כלל היציאה חל רק על פרוטוקול TCP.

      בנוסף, VM 3 יכולה לשלוח תעבורה למופעים אחרים ברשת ה-VPC מחוץ לטווח כתובות ה-IP‏ 192.168.1.0/24, כל עוד למופעים האחרים יש כללי תעבורה נכנסת שמאפשרים תעבורה כזו. מכיוון שאין לה כתובת IP חיצונית, אין לה נתיב לשליחת תעבורה מחוץ לרשת ה-VPC.

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