כללי מדיניות היררכיים של חומת אש מאפשרים ליצור ולאכוף מדיניות עקבית של חומת אש בכל הארגון. אפשר להקצות כללי מדיניות היררכיים של חומת אש לארגון כולו או לתיקיות ספציפיות. המדיניות הזו מכילה כללים שיכולים לדחות או לאשר חיבורים באופן מפורש, כמו כללי חומת האש של ענן וירטואלי פרטי (VPC).
בנוסף, כללים של מדיניות חומת אש היררכית יכולים להעביר את ההערכה למדיניות ברמה נמוכה יותר או לכללים של חומת אש ברשת VPC באמצעות פעולת goto_next.
כללים ברמה נמוכה יותר לא יכולים לשנות כלל ממקום גבוה יותר בהיררכיית המשאבים. כך אדמינים ברמת הארגון יכולים לנהל כללים קריטיים של חומת אש במקום אחד.
מפרטים
- כללי מדיניות היררכיים של חומת אש נוצרים ברמת הארגון וברמת התיקייה. כשיוצרים מדיניות, הכללים לא חלים באופן אוטומטי על הארגון או התיקייה.
- אחרי שיוצרים כללי מדיניות, אפשר להחיל אותם על (לשייך אותם ל-) כל המשאבים בארגון.
- מדיניות חומת אש היררכית היא קונטיינר לכללים של חומת אש. כשמשייכים מדיניות לארגון או לתיקייה, כל הכללים מופעלים באופן מיידי. אתם יכולים להחליף כללי מדיניות של משאב, וכך להחליף באופן אטומי את כל כללי חומת האש שחלים על מכונות וירטואליות (VM) באותו משאב.
- הערכת הכללים היא היררכית ומבוססת על היררכיית המשאבים. המערכת בודקת את כל הכללים שמשויכים לארגון, ואז את הכללים של התיקיות ברמה הראשונה.
- לכללי מדיניות היררכית של חומת אש יש פעולה חדשה,
goto_next, שמאפשרת להעביר את הערכת החיבור לרמות נמוכות יותר בהיררכיה.
- אפשר לטרגט כללים של מדיניות היררכית של חומת אש לרשתות VPC ולמכונות וירטואליות ספציפיות, באמצעות משאבי יעד לרשתות וחשבונות שירות של יעדים למכונות וירטואליות. כך אפשר ליצור חריגים לקבוצות של מכונות וירטואליות. בכללים של מדיניות חומת אש היררכית אי אפשר להגדיר טירגוט לפי תגי מכונות.
- במדיניות היררכית של חומת אש אי אפשר להשתמש ברשתות VPC עם פרופיל רשת של גישה ישירה מרוחקת לזיכרון (RDMA), כמו סוג המדיניות
RDMA_ROCE_POLICY. מידע נוסף זמין במאמר Cloud NGFW לרשתות VPC של RoCE. - כלל היררכי של מדיניות חומת אש יכול לכלול טווחים של IPv4 או של IPv6, אבל לא את שניהם.
- כדי לעזור בתאימות ובניפוי באגים, אפשר לבדוק את כללי חומת האש שחלים על מכונה וירטואלית באמצעות דף הפרטים של רשת ה-VPC ודף הפרטים של ממשק הרשת של המכונה הווירטואלית.
היררכיית המשאבים
יצירה והחלה של מדיניות חומת אש מתבצעות בשלבים נפרדים. אפשר ליצור ולהחיל מדיניות חומת אש ברמת הארגון או התיקייה בהיררכיית המשאבים. כלל מדיניות חומת אש יכול לחסום חיבורים, לאפשר חיבורים או לדחות את הערכת כללי חומת האש לתיקיות ברמה נמוכה יותר או לכללי חומת אש של VPC שמוגדרים ברשתות VPC.
Organization הוא המשאב ברמה העליונה בהיררכיית המשאבים ב- Google Cloud , שבו אפשר ליצור או לשייך כללי מדיניות היררכיים של חומת אש. כל התיקיות ורשתות ה-VPC בארגון יורשות את המדיניות הזו.
תיקיות הן משאבים ברמת הביניים ב Google Cloud היררכיית המשאבים, בין הארגון לפרויקטים, שבהם אפשר ליצור או להקצות מדיניות חומת אש היררכית. כל התיקיות ורשתות ה-VPC בתיקייה יורשות את המדיניות שמשויכת אליה.
פרויקט נמצא בתיקייה או בארגון. אתם יכולים להעביר פרויקטים בין משאבים בארגון. הפרויקטים מכילים רשתות VPC. אי אפשר להקצות כללי מדיניות היררכיים של חומת אש לפרויקטים, אלא רק לארגון או לתיקיות.
רשת VPC היא המחיצה של Google Cloud לתקשורת מבודדת במרחב כתובות IP פנימיות. ברמה הזו מציינים ומחילים מסלולים, מדיניות חומת אש ברשת וכללים מסורתיים של חומת אש ב-VPC. כללים של מדיניות חומת אש היררכית יכולים לבטל או להעביר את הערכת החיבור לכללים ולמדיניות של חומת אש בין רשתות גלובליות.
כברירת מחדל, כל הכללים של מדיניות חומת האש ההיררכית חלים על כל המכונות הווירטואליות בכל הפרויקטים שבארגון או בתיקייה שאליהם משויכת המדיניות. עם זאת, אתם יכולים להגביל את המכונות הווירטואליות שמקבלות כלל מסוים על ידי ציון רשתות יעד או חשבונות שירות של יעד.
בתרשים הבא מוצגות הרמות בהיררכיה שבהן אפשר להחיל עכשיו כללים של חומת אש. התיבות הצהובות מייצגות כללי מדיניות היררכיים של חומת אש שמכילים כללים של חומת אש, והתיבות הלבנות מייצגות כללים של חומת אש ב-VPC.
פרטי מדיניות חומת האש ההיררכית
כללי מדיניות היררכית של חומת אש מוגדרים במשאב מדיניות חומת אש, שפועל כמאגר לכללי חומת אש. הכללים שמוגדרים במדיניות חומת האש לא נאכפים עד שהמדיניות משויכת למשאב (ארגון או תיקייה).
אפשר לשייך מדיניות אחת לכמה משאבים. אם משנים כלל במדיניות, השינוי חל על כל המשאבים שמשויכים אליה.
אפשר לשייך למשאב רק מדיניות אחת של חומת אש. הכללים של מדיניות חומת האש ההיררכית וכללי חומת האש של VPC נבדקים בסדר מוגדר היטב.
מדיניות חומת אש שלא משויכת לאף משאב היא מדיניות חומת אש היררכית לא משויכת.
שמות של כללי מדיניות
כשיוצרים מדיניות חדשה, המערכת של Google Cloud יוצרת באופן אוטומטי מזהה למדיניות. בנוסף, אתם מציינים שם מקוצר למדיניות.
כשמשתמשים בממשק של gcloud כדי לעדכן מדיניות קיימת, אפשר להפנות למזהה שנוצר על ידי המערכת או לשילוב של השם המקוצר ומזהה הארגון. כשמשתמשים ב-API כדי לעדכן את המדיניות, צריך לספק את המזהה שנוצר על ידי המערכת.
פרטי הכללים של מדיניות חומת האש ההיררכית
הכללים של מדיניות חומת אש היררכית פועלים כמו הכללים של מדיניות חומת אש והכללים של חומת אש ב-VPC, אבל יש כמה הבדלים:
כללי מדיניות היררכיים של חומת אש תומכים ברשתות יעד, אבל כללי מדיניות גלובליים של חומת אש לא תומכים בהן. אתם יכולים לציין רשתות יעד כדי להגביל כלל מדיניות חומת אש למכונות וירטואליות ברשתות שצוינו. אם תציינו רשתות VPC בכלל, תוכלו לקבוע אילו רשתות יוגדרו עם הכלל הזה.
בשילוב עם
goto_nextאוallow, ציון רשתות יעד מאפשר ליצור חריגים לרשתות ספציפיות כשרוצים להגדיר מדיניות מגבילה.כללי מדיניות היררכיים של חומת אש הם משאבים ברמת הארגון, וכללי מדיניות גלובליים של חומת אש ברשת הם משאבים ברמת הפרויקט.
כללים במדיניות חומת אש היררכית תומכים במפתחות של תגי אבטחה בתור תגי אבטחה של מקור או תגי אבטחה של יעד. מידע נוסף זמין במאמר תגים מאובטחים לחומות אש.
כללים מוגדרים מראש
כשיוצרים מדיניות חומת אש היררכית, Cloud Next Generation Firewall (Cloud NGFW) מוסיף למדיניות כללים מוגדרים מראש עם העדיפות הנמוכה ביותר. הכללים האלה חלים על כל החיבורים שלא תואמים לכלל שהוגדר במפורש במדיניות, וכתוצאה מכך החיבורים האלה מועברים למדיניות או לכללי רשת ברמה נמוכה יותר.
במאמר כללים מוגדרים מראש למדיניות של חומת אש מוסבר על הסוגים השונים של הכללים המוגדרים מראש והמאפיינים שלהם.
ניהול משאבים של מדיניות חומת אש היררכית
מדיניות היררכית של חומת אש מגדירה רק קבוצה של כללי חומת אש, ולא את המקום שבו הם חלים. לכן, אפשר ליצור את המשאבים האלה בחלק אחר של ההיררכיה, ולא במשאבים שהם חלים עליהם. כך אפשר לשייך משאב אחד של מדיניות חומת אש היררכית לכמה תיקיות בארגון.
בדוגמה הבאה, המדיניות policy-1 חלה על התיקיות dev-projects ו-corp-projects, ולכן היא נאכפת בכל הפרויקטים שבתיקיות האלה.
שינוי הכללים של מדיניות
אתם יכולים להוסיף, להסיר ולשנות כללים במדיניות. כל שינוי מתבצע בנפרד, ואין מנגנון לביצוע חבילת עדכונים של כללים במדיניות. השינויים מיושמים פחות או יותר לפי סדר הפקודות, אבל זה לא מובטח.
אם אתם מבצעים שינויים נרחבים במדיניות היררכית של חומת אש, ורוצים לוודא שהם יחולו בו-זמנית, אתם יכולים לשכפל את המדיניות למדיניות זמנית ולהקצות את המדיניות הזמנית לאותם משאבים. אחרי זה תוכלו לבצע את השינויים במקור, ואז להקצות את המקור בחזרה למשאבים. במאמר שכפול כללים ממדיניות אחת לאחרת מוסבר איך עושים את זה.
בדוגמה הבאה, policy-1 מצורף לתיקייה dev-projects, ואתם רוצים לבצע כמה שינויים שיחולו באופן אטומי. יוצרים מדיניות חדשה בשם scratch-policy, ואז מעתיקים את כל הכללים הקיימים מ-policy-1 אל scratch-policy כדי לערוך אותם. אחרי שמסיימים לערוך, מעתיקים את כל הכללים מ-scratch-policy בחזרה אל policy-1.
העברת מדיניות
בדומה לפרויקטים, מדיניות חומת אש היררכית היא הורה של תיקייה או של משאב ארגון. ככל שסכימת התיקיות מתפתחת, יכול להיות שתצטרכו להעביר מדיניות חומת אש היררכית לתיקייה חדשה, למשל לפני מחיקת תיקייה. כללי מדיניות שבבעלות תיקייה נמחקים אם התיקייה נמחקת.
בתרשים הבא מוצגת העברה של מדיניות בין שיוכים של משאבים או הערכה של כללים במדיניות.
שיוך מדיניות חומת אש היררכית לתיקייה
מדיניות חומת אש היררכית נאכפת רק אם היא משויכת לארגון או לתיקייה. אחרי השיוך, המדיניות חלה על כל המכונות הווירטואליות בכל הרשתות באותו ארגון או באותה תיקייה.
שינויים בהיררכיית המשאבים
יכול להיות שיעבור קצת זמן עד שהשינויים בהיררכיית המשאבים יתעדכנו במערכת. מומלץ להימנע מעדכונים בו-זמניים של הקבצים המצורפים למדיניות חומת האש ההיררכית ושל היררכיית המשאבים, כי יכול להיות שהרשתות לא יקבלו בירושה באופן מיידי את מדיניות חומת האש ההיררכית שמוגדרת במיקום החדש בהיררכיה.
לדוגמה, אם אתם מעבירים את התיקייה dept-A מהתיקייה dev-projects לתיקייה eng-projects ומשנים את השיוך של policy-1 ל-eng-projects במקום ל-dev-projects, חשוב לוודא שאתם לא מבטלים את השיוך של policy-1 ל-dev-projects באותו זמן. אם התיקייה dev-projects תאבד את השיוך שלה למדיניות חומת האש ההיררכית לפני שכל רשתות ה-VPC שמתחתיה יעודכנו, למשך פרק זמן קצר רשתות ה-VPC האלה לא יהיו מוגנות על ידי policy-1.
שימוש במדיניות היררכית של חומת אש עם VPC משותף
בתרחישים של VPC משותף, ממשק של מכונה וירטואלית שמחובר לרשת של פרויקט מארח כפוף לכללי המדיניות ההיררכית של חומת האש של הפרויקט המארח, ולא של פרויקט השירות.
גם אם פרויקטי השירות נמצאים בתיקייה אחרת מהפרויקט המארח, ממשקי ה-VM ברשת המשותפת עדיין יורשים את הכללים של תיקיית הפרויקט המארח.
שימוש בכללי מדיניות היררכיים של חומת אש עם קישור בין רשתות VPC שכנות (peering)
בתרחישים של קישור בין רשתות VPC שכנות (peering), ממשק ה-VM שמשויך לכל אחת מרשתות ה-VPC מקבל בירושה את כללי המדיניות בהיררכיה של רשתות ה-VPC המתאימות. בדוגמה הבאה מוצג קישור בין רשתות VPC שכנות, שבה הרשתות המקושרות שייכות לארגונים שונים.
המאמרים הבאים
- כדי ליצור ולשנות כללים ומדיניות חומת אש היררכיים, קראו את המאמרים יצירת כללים ומדיניות חומת אש היררכיים וניהול כללים ומדיניות חומת אש היררכיים.
- דוגמאות להטמעות של מדיניות היררכית של חומת אש