כללי מדיניות היררכיים של חומת אש מאפשרים לכם ליצור ולאכוף מדיניות עקבית של חומת אש בכל הארגון. אפשר להקצות מדיניות היררכית של חומת אש לארגון כולו או לתיקיות בודדות. המדיניות הזו מכילה כללים שיכולים לאסור או לאשר חיבורים באופן מפורש, כמו כללי חומת אש של ענן וירטואלי פרטי (VPC).
בנוסף, כללים במדיניות היררכית של חומת אש יכולים להעביר את ההערכה למדיניות ברמה נמוכה יותר או לכללים של חומת אש ברשת VPC עם פעולת goto_next.
כללים ברמה נמוכה יותר לא יכולים לבטל כלל ממקום גבוה יותר בהיררכיית המשאבים. כך מנהלי מערכת בכל הארגון יכולים לנהל כללים חשובים של חומת אש במקום אחד.
מפרטים
- מדיניות חומת אש היררכית נוצרת ברמת הארגון והתיקייה. יצירת מדיניות לא מחילה באופן אוטומטי את הכללים על הארגון או על התיקייה.
- אחרי שיוצרים כללי מדיניות, אפשר להחיל אותם על כל המשאבים בארגון (לשייך אותם למשאבים).
- מדיניות חומת אש היררכית היא מאגר לכללים של חומת אש. כשמשייכים מדיניות לארגון או לתיקייה, כל הכללים מוחלים באופן מיידי. אפשר להחליף מדיניות של משאב, וכך להחליף באופן אטומי את כל כללי חומת האש שחלים על מכונות וירטואליות (VM) במסגרת אותו משאב.
- הערכת הכללים היא היררכית ומבוססת על היררכיית המשאבים. כל הכללים שמשויכים לארגון נבדקים, ואחריהם הכללים של הרמה הראשונה של התיקיות.
- לכללים של מדיניות חומת אש היררכית יש פעולה חדשה
goto_nextשאפשר להשתמש בה כדי להעביר את הערכת החיבור לרמות נמוכות יותר בהיררכיה.
- אפשר לטרגט כללים של מדיניות חומת אש היררכית לרשתות VPC ספציפיות ולמכונות וירטואליות באמצעות משאבי יעד לרשתות וחשבונות שירות יעד למכונות וירטואליות. כך אפשר ליצור חריגים לקבוצות של מכונות וירטואליות. כללים במדיניות חומת אש היררכית לא תומכים בטירגוט לפי תגי מופעים.
- מדיניות חומת אש היררכית לא תומכת ברשתות VPC שמשתמשות בפרופיל רשת של גישה ישירה לזיכרון (RDMA), כמו סוג המדיניות
RDMA_ROCE_POLICY. מידע נוסף זמין במאמר Cloud NGFW לרשתות VPC של RoCE. - כלל במדיניות חומת אש היררכית יכול לכלול טווחי כתובות IPv4 או IPv6, אבל לא את שניהם.
- כדי לעזור בתאימות ובניפוי באגים, אפשר לבדוק את כללי חומת האש שחלים על מכונה וירטואלית באמצעות דף הפרטים של רשת ה-VPC ודף הפרטים של ממשק הרשת של המכונה הווירטואלית.
היררכיית המשאבים
יוצרים ומחילים את כללי המדיניות של חומת האש בשלבים נפרדים. אפשר ליצור ולהחיל מדיניות חומת אש ברמת הארגון או התיקייה של היררכיית המשאבים. כלל במדיניות חומת אש יכול לחסום חיבורים, לאפשר חיבורים או לדחות את ההערכה של כלל חומת האש לתיקיות ברמה נמוכה יותר או לכללי חומת אש של VPC שמוגדרים ברשתות VPC.
הארגון הוא המשאב ברמה העליונה בהיררכיית המשאבים ב- Cloud de Confiance by S3NS , שבו אפשר ליצור או לשייך כללי מדיניות היררכיים של חומת אש. כל התיקיות ורשתות ה-VPC בארגון מקבלות בירושה את המדיניות הזו.
תיקיות הן משאבים ברמת הביניים ב Cloud de Confiance היררכיית המשאבים, בין הארגון לפרויקטים. אפשר ליצור או להקצות בהן מדיניות היררכית של חומת אש. כל התיקיות ורשתות ה-VPC בתיקייה מקבלות בירושה את המדיניות שמשויכת אליה.
פרויקט נמצא בתיקייה או בארגון. אפשר להעביר פרויקטים בין משאבים בארגון. הפרויקטים מכילים רשתות VPC. אי אפשר להקצות מדיניות חומת אש היררכית לפרויקטים, אלא רק לארגון או לתיקיות.
רשת VPC היא המחיצה לתקשורת מבודדת של מרחב כתובות IP פנימי. Cloud de Confiance ברמה הזו מציינים ומחילים מסלולים, מדיניות חומת אש ברשת וכללי חומת אש מסורתיים ב-VPC. כללים היררכיים של מדיניות חומת אש יכולים לבטל או להעביר את הערכת החיבור אל כללים ומדיניות של חומת אש בין רשתות גלובליות.
כברירת מחדל, כל הכללים של מדיניות חומת אש היררכית חלים על כל המכונות הווירטואליות בכל הפרויקטים שמתחת לארגון או לתיקייה שאליהם משויכת המדיניות. עם זאת, אפשר להגביל את המכונות הווירטואליות שחלים עליהן כללים מסוימים על ידי ציון רשתות יעד או חשבונות שירות יעד.
בתרשים הבא מוצגות הרמות בהיררכיה שבהן אפשר להחיל כללי חומת אש. התיבות הצהובות מייצגות כללי מדיניות היררכיים של חומת אש שמכילים כללים של חומת אש, והתיבות הלבנות מייצגות כללים של חומת אש ב-VPC.
פרטים על מדיניות חומת אש היררכית
כללים של מדיניות חומת אש היררכית מוגדרים במשאב של מדיניות חומת אש, שמשמש כמאגר לכללים של חומת אש. הכללים שמוגדרים במדיניות חומת אש לא נאכפים עד שהמדיניות משויכת למשאב (ארגון או תיקייה).
אפשר לשייך מדיניות אחת לכמה משאבים. אם משנים כלל במדיניות, השינוי הזה חל על כל המשאבים שמשויכים למדיניות.
אפשר לשייך למשאב רק מדיניות אחת של חומת אש. הערכה של כללים במדיניות חומת אש היררכית וכללים בחומת אש של VPC מתבצעת בסדר מוגדר.
מדיניות חומת אש שלא משויכת למשאב כלשהו היא מדיניות חומת אש היררכית לא משויכת.
שמות של כללי מדיניות
כשיוצרים מדיניות חדשה, Cloud de Confiance המערכת יוצרת באופן אוטומטי מזהה למדיניות. בנוסף, צריך לציין גם שם מקוצר למדיניות.
כשמשתמשים בממשק של gcloud כדי לעדכן מדיניות קיימת, אפשר להפנות למזהה שנוצר על ידי המערכת או לשילוב של השם הקצר ומזהה הארגון. כשמשתמשים ב-API כדי לעדכן את המדיניות, צריך לספק את המזהה שנוצר על ידי המערכת.
פרטי כלל מדיניות חומת אש היררכית
כללים של מדיניות חומת אש היררכית פועלים כמו כללים של מדיניות חומת אש וכללים של חומת אש ב-VPC, אבל יש כמה הבדלים:
מדיניות חומת אש היררכית תומכת ברשתות יעד, אבל מדיניות חומת אש בין רשתות גלובליות לא תומכת בהן. אפשר לציין רשתות יעד כדי להגביל כלל במדיניות חומת אש למכונות וירטואליות ברשתות שצוינו. כשמציינים רשתות VPC בכלל, אפשר לשלוט ברשתות שמוגדרות עם הכלל הזה.
בשילוב עם
goto_nextאוallow, ציון רשתות יעד מאפשר ליצור חריגים לרשתות ספציפיות כשרוצים להגדיר מדיניות מגבילה.מדיניות היררכית של חומת אש היא משאב ברמת הארגון, ומדיניות גלובלית של חומת אש ברשת היא משאב ברמת הפרויקט.
כללים במדיניות חומת אש היררכית תומכים במפתחות תגים מאובטחים בתור תגי מקור מאובטחים או תגי יעד מאובטחים. מידע נוסף זמין במאמר בנושא תגים מאובטחים לחומות אש.
כללים מוגדרים מראש
כשיוצרים מדיניות חומת אש היררכית, Cloud Next Generation Firewall מוסיף למדיניות כללים מוגדרים מראש עם העדיפות הכי נמוכה. הכללים האלה חלים על כל חיבור שלא תואם לכלל שהוגדר במפורש במדיניות, ולכן החיבורים האלה מועברים לכללי מדיניות או לכללי רשת ברמה נמוכה יותר.
במאמר כללים מוגדרים מראש למדיניות חומת אש מוסבר על הסוגים השונים של כללים מוגדרים מראש ועל המאפיינים שלהם.
תפקידים בניהול זהויות והרשאות גישה (IAM)
תפקידי IAM קובעים את הפעולות הבאות שקשורות למדיניות חומת אש היררכית:
- יצירת מדיניות שחלה על משאב מסוים
- שיוך מדיניות למשאב מסוים
- שינוי מדיניות קיימת
- הצגת כללי חומת האש בפועל עבור רשת או מכונה וירטואלית מסוימת
בטבלה הבאה מתוארים התפקידים הנדרשים לכל שלב:
| יכולת | תפקיד נדרש |
|---|---|
| יצירת מדיניות חדשה של חומת אש היררכית | התפקיד Organization Firewall Policy Admin (roles/compute.orgFirewallPolicyAdmin) במשאב שבו תתקיים המדיניות |
| שיוך מדיניות למשאב | התפקיד Organization Security Resource Admin (roles/compute.orgSecurityResourceAdmin) במשאב היעד, וגם התפקיד Organization Firewall Policy Admin (roles/compute.orgFirewallPolicyAdmin) או התפקיד Organization Firewall Policy User (roles/compute.orgFirewallPolicyUser) במשאב שבו המדיניות נמצאת או במדיניות עצמה. |
| שינוי המדיניות על ידי הוספה, עדכון או מחיקה של כללי מדיניות בחומת האש | תפקיד אדמין של מדיניות חומת אש בארגון (roles/compute.orgFirewallPolicyAdmin) במשאב שבו המדיניות נמצאת או במדיניות עצמה |
| מחיקת המדיניות | תפקיד אדמין של מדיניות חומת אש בארגון (roles/compute.orgFirewallPolicyAdmin) במשאב שבו המדיניות נמצאת או במדיניות עצמה |
| הצגת הכללים של חומת האש שחלים על רשת VPC | אחד מהתפקידים הבאים ברשת: תפקיד אדמין ברשת Compute ( roles/compute.networkAdmin)תפקיד משתמש ברשת Compute ( roles/compute.networkUser)תפקיד צפייה ברשת Compute ( roles/compute.networkViewer)תפקיד Security Admin ב-Compute ( roles/compute.securityAdmin)תפקיד צפייה ב-Compute ( roles/compute.viewer)
|
| הצגת הכללים התקפים של חומת האש למכונה וירטואלית ברשת | אחד מהתפקידים הבאים במכונה הווירטואלית: תפקיד Compute Instance Admin ( roles/compute.instanceAdmin)תפקיד סוכן שירות של Instance Group Manager ( roles/compute.instanceGroupManagerServiceAgent)תפקיד Security Admin של Compute ( roles/compute.securityAdmin)תפקיד צופה של Compute ( roles/compute.viewer)
|
התפקידים הבאים רלוונטיים למדיניות חומת אש היררכית.
| שם התפקיד | תיאור |
|---|---|
תפקיד אדמין במדיניות חומת האש של הארגון (roles/compute.orgFirewallPolicyAdmin)
|
אפשר להעניק אותה למשאב או למדיניות ספציפית. אם ההרשאה ניתנת ברמת משאב, היא מאפשרת למשתמשים ליצור, לעדכן ולמחוק מדיניות חומת אש היררכית ואת הכללים שלה. אם ההרשאה ניתנת במדיניות ספציפית, היא מאפשרת למשתמש לעדכן את כללי המדיניות, אבל לא ליצור או למחוק את המדיניות. התפקיד הזה מאפשר למשתמש גם לשייך מדיניות למשאב, אם יש לו גם את התפקיד compute.orgSecurityResourceAdmin במשאב הזה. |
התפקיד 'אדמין של משאבי אבטחה בארגון' (roles/compute.orgSecurityResourceAdmin)
|
ההרשאה ניתנת ברמת הארגון או לתיקייה, ומאפשרת לאדמינים ברמת התיקייה לשייך מדיניות למשאב הזה. כדי להשתמש במדיניות, האדמינים צריכים להיות בעלי תפקיד compute.orgFirewallPolicyUser או compute.orgFirewallPolicyAdmin במשאב שבבעלותו המדיניות או במדיניות עצמה. |
תפקיד המשתמש במדיניות חומת האש של הארגון (roles/compute.orgFirewallPolicyUser)
|
ההרשאה ניתנת במשאב או במדיניות ספציפית, ומאפשרת לאדמינים להשתמש במדיניות הספציפית או במדיניות שמשויכת למשאב. כדי לשייך מדיניות למשאב מסוים, המשתמשים צריכים גם לקבל את התפקיד compute.orgSecurityResourceAdmin במשאב היעד. |
תפקיד Security Admin ב-Compute (roles/compute.securityAdmin)תפקיד צפייה ב-Compute ( roles/compute.viewer)תפקיד משתמש ברשת Compute ( roles/compute.networkUser)תפקיד צפייה ברשת Compute ( roles/compute.networkViewer) |
מאפשר למשתמשים לראות את כללי חומת האש שחלים על הרשת או על המופע. כולל את ההרשאה compute.networks.getEffectiveFirewalls לרשתות ואת ההרשאה compute.instances.getEffectiveFirewalls למופעים. |
בדוגמה הבאה, ליוסי יש אפשרות ליצור, לשנות ולמחוק כל מדיניות חומת אש היררכית בתיקייה policies, אבל אין לו אפשרות לצרף את מדיניות חומת האש ההיררכית לתיקייה כי אין לו את התפקיד orgSecurityResourceAdmin באף תיקייה.
עם זאת, מכיוון שיוסף העניק למאי הרשאות להשתמש ב-policy-1, היא יכולה לפרט את מדיניות חומת האש ההיררכית הזו ולשייך אותה לתיקייה dev-projects או לכל אחת מהתיקיות שנגזרות ממנה. התפקיד orgFirewallPolicyUser לא מעניק הרשאה לשייך את המדיניות לתיקיות כלשהן. המשתמש צריך גם לקבל את התפקיד orgSecurityResourceAdmin בתיקיית היעד.
ניהול משאבים של מדיניות חומת אש היררכית
מדיניות חומת אש היררכית מגדירה רק קבוצה של כללי חומת אש, ולא את המקום שבו הם חלים. לכן, אפשר ליצור את המשאבים האלה בחלק אחר בהיררכיה מהמשאבים שהם חלים עליהם. כך אפשר לשייך משאב אחד של מדיניות חומת אש היררכית לכמה תיקיות בארגון.
בדוגמה הבאה, policy-1 מוחל על התיקיות dev-projects ו-corp-projects, ולכן הוא נאכף בכל הפרויקטים בתיקיות האלה.
שינוי הכללים של מדיניות
אפשר להוסיף, להסיר ולשנות כללים במדיניות. כל שינוי מתבצע בנפרד, ואין מנגנון לעדכון קבוצתי של כללים במדיניות. השינויים מוחלים בערך בסדר שבו הפקודות מבוצעות, אבל זה לא מובטח.
אם אתם מבצעים שינויים נרחבים במדיניות חומת אש היררכית ורוצים לוודא שהשינויים יחולו בו-זמנית, אתם יכולים לשכפל את המדיניות למדיניות זמנית ולהקצות את המדיניות הזמנית לאותם משאבים. אחר כך תוכלו לבצע את השינויים במקור, ואז להקצות את המקור בחזרה למשאבים. הוראות מפורטות מופיעות במאמר בנושא שיבוט כללים ממדיניות אחת לאחרת.
בדוגמה הבאה, policy-1 מצורף לתיקייה dev-projects, ואתם רוצים לבצע כמה שינויים שיחולו באופן אטומי. יוצרים מדיניות חדשה בשם scratch-policy, ואז מעתיקים את כל הכללים הקיימים מ-policy-1 אל scratch-policy כדי לערוך אותם. אחרי שמסיימים לערוך, מעתיקים את כל הכללים מ-scratch-policy בחזרה אל policy-1.
העברת מדיניות
מדיניות חומת אש היררכית, כמו פרויקטים, משויכת למשאב תיקייה או ארגון. ככל שסכימת התיקיות מתפתחת, יכול להיות שתצטרכו להעביר מדיניות חומת אש היררכית לתיקייה חדשה, אולי לפני מחיקת תיקייה. אם מוחקים תיקייה, נמחקות גם המדיניות שבבעלותה.
בתרשים הבא מוצגת דוגמה להעברת מדיניות בין שיוכים של משאבים או להערכת כללים במדיניות.
שיוך מדיניות חומת אש היררכית לתיקייה
מדיניות חומת אש היררכית לא נאכפת אלא אם היא משויכת לארגון או לתיקייה. אחרי השיוך, המדיניות חלה על כל מכונות ה-VM בכל הרשתות באותו ארגון או באותה תיקייה.
שינויים בהיררכיית המשאבים
יכול להיות שיעבור קצת זמן עד שהשינויים בהיררכיית המשאבים יתעדכנו במערכת. מומלץ להימנע מעדכונים בו-זמניים של קבצים מצורפים של מדיניות חומת אש היררכית ושל היררכיית המשאבים, כי יכול להיות שהרשתות לא יירשו באופן מיידי את מדיניות חומת האש ההיררכית שהוגדרה במיקום החדש בהיררכיה.
לדוגמה, אם מעבירים את התיקייה dept-A מהתיקייה dev-projects לתיקייה eng-projects ומשנים את השיוך של policy-1 ל-eng-projects במקום ל-dev-projects, חשוב לוודא שלא מבטלים את השיוך של policy-1 ל-dev-projects באותו הזמן. אם התיקייה dev-projects מאבדת את השיוך שלה למדיניות חומת האש ההיררכית לפני שכל רשתות ה-VPC שמתחתיה עודכנו, למשך זמן קצר רשתות ה-VPC האלה לא מוגנות על ידי dev-projects.policy-1
שימוש במדיניות חומת אש היררכית עם VPC משותף
בתרחישים של VPC משותף, ממשק של מכונה וירטואלית שמחובר לרשת של פרויקט מארח כפוף לכללים של מדיניות חומת האש ההיררכית של הפרויקט המארח, ולא של פרויקט השירות.
גם אם פרויקטי השירות נמצאים בתיקייה אחרת מזו של הפרויקט המארח, הממשקים של מכונות ה-VM ברשת המשותפת עדיין יורשים את הכללים של תיקיית הפרויקט המארח.
שימוש במדיניות חומת אש היררכית עם קישור בין רשתות VPC שכנות (peering)
בתרחישים של קישור בין רשתות VPC שכנות (peering), הממשק של המכונה הווירטואלית שמשויך לכל אחת מרשתות ה-VPC מקבל בירושה את הכללים בהיררכיה ברשתות ה-VPC המתאימות. בדוגמה הבאה מוצג קישור בין רשתות VPC שכנות ששייכות לארגונים שונים.
המאמרים הבאים
- כדי ליצור ולשנות כללים ומדיניות היררכית של חומת אש, אפשר לעיין במאמר בנושא שימוש במדיניות היררכית של חומת אש.
- דוגמאות להטמעה של מדיניות חומת אש היררכית