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

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

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

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

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

ביקורת אבטחת רשת

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

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

• ביקורת תצורת ציוד (התקשות)
• ביקורת עיצוב אבטחה
• ביקורת גישה
• ביקורת תהליך

ביקורת תצורת ציוד (התקשות)

נראה שברוב המקרים זוהי נקודת ההתחלה הטובה ביותר לביקורת ושיפור האבטחה של הרשת שלך. IMHO, זו הדגמה טובה לחוק פארטו (20% מהמאמץ מייצרים 80% מהתוצאה, ו-80% המאמץ הנותרים מייצרים רק 20% מהתוצאה).

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

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

מספר דוגמאות לכמה מערכות הפעלה של סיסקו.

התקשות התצורה של Cisco IOS
הקשחת תצורת Cisco IOS-XR
הקשחת תצורת Cisco NX-OS
רשימת בדיקות אבטחה בסיסית של Cisco

בהתבסס על מסמכים אלה, ניתן ליצור רשימה של דרישות תצורה עבור כל סוג של ציוד. לדוגמה, עבור Cisco N7K VDC דרישות אלה עשויות להיראות כך.

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

ביקורת עיצוב אבטחה

בדרך כלל, רשת ארגונית מכילה את הפלחים הבאים בצורה כזו או אחרת:

• DC (שירותים ציבוריים DMZ ומרכז נתונים אינטראנט)
• גישה לאינטרנט
• גישה מרחוק VPN
• קצה WAN
• סניף
• קמפוס (משרד)
• ליבה

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

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

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

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

מרכז נתונים

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

האם יש צורך בחומת אש או לא?

נראה שהתשובה ברורה, אבל הכל לא ממש ברור כמו שזה נראה. והבחירה שלך יכולה להיות מושפעת לא רק מחיר.

דוגמא 1. עיכובים.

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

דוגמא 2. ביצועים.

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

דוגמא 3. אמינות

חומות אש, במיוחד NGFW מודרניות (Next-Generation FW) הן מכשירים מורכבים. הם הרבה יותר מורכבים ממתגי L3/L2. הם מספקים מספר רב של שירותים ואפשרויות תצורה, כך שאין זה מפתיע שהאמינות שלהם נמוכה בהרבה. אם המשכיות השירות היא קריטית לרשת, אז אולי תצטרך לבחור מה יוביל לזמינות טובה יותר - אבטחה עם חומת אש או הפשטות של רשת הבנויה על מתגים (או סוגים שונים של בדים) באמצעות ACLs רגילים.

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

• אם תחליט לא להשתמש בחומת אש בתוך מרכז הנתונים, אז אתה צריך לחשוב איך להגביל את הגישה סביב ההיקף ככל האפשר. לדוגמה, אתה יכול לפתוח רק את היציאות הנחוצות מהאינטרנט (לתעבורת לקוח) וגישה מנהלתית למרכז הנתונים רק ממארחי קפיצה. במארחי קפיצה, בצע את כל הבדיקות הנדרשות (אימות/הרשאה, אנטי וירוס, רישום,...)
• אתה יכול להשתמש במחיצה לוגית של רשת מרכז הנתונים למקטעים, בדומה לתכנית המתוארת ב-PSEFABRIC דוגמה p002. במקרה זה, הניתוב חייב להיות מוגדר בצורה כזו שתעבורה רגישה לעיכוב או בעוצמה גבוהה עוברת "בתוך" קטע אחד (במקרה של p002, VRF) ולא עוברת דרך חומת האש. תנועה בין מקטעים שונים תמשיך לעבור דרך חומת האש. אתה יכול גם להשתמש בדליפת נתיב בין VRFs כדי למנוע הפניית תנועה דרך חומת האש
• אתה יכול גם להשתמש בחומת אש במצב שקוף ורק עבור אותם VLANs שבהם הגורמים הללו (השהייה/ביצועים) אינם משמעותיים. אבל אתה צריך ללמוד בקפידה את ההגבלות הקשורות לשימוש במוד זה עבור כל ספק
• אולי תרצה לשקול להשתמש בארכיטקטורת שרשרת שירות. זה יאפשר רק לתעבורה הכרחית לעבור דרך חומת האש. נראה נחמד בתיאוריה, אבל מעולם לא ראיתי את הפתרון הזה בייצור. בדקנו את שרשרת השירות עבור Cisco ACI/Juniper SRX/F5 LTM לפני כ-3 שנים, אבל באותו זמן הפתרון הזה נראה לנו "גס".

רמת הגנה

עכשיו אתה צריך לענות על השאלה באילו כלים אתה רוצה להשתמש כדי לסנן תנועה. להלן כמה מהתכונות הקיימות בדרך כלל ב-NGFW (לדוגמה, כאן):

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

וגם לא הכל ברור. נראה שככל שרמת ההגנה גבוהה יותר, כך ייטב. אבל צריך גם לשקול את זה

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

כמו תמיד, אתה צריך למצוא את הפתרון הטוב ביותר עבור הרשת שלך.

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

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

הִתפַּלְגוּת

אנחנו מדברים על פילוח לוגי של רשת מרכז הנתונים. לדוגמה, חלוקה לרשתות VLAN ורשתות משנה היא גם פילוח לוגי, אך לא נשקול זאת בשל המובן מאליו. פילוח מעניין תוך התחשבות בישויות כגון אזורי אבטחה FW, VRFs (והאנלוגים שלהם ביחס לספקים שונים), מכשירים לוגיים (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

דוגמה לפילוח לוגי כזה ולעיצוב מרכזי הנתונים המבוקש כרגע מובאת ב p002 של פרויקט PSEFABRIC.

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

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

לעתים קרובות הפילוח מבוסס רק על אזורי אבטחה FW. לאחר מכן עליך לענות על השאלות הבאות:

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

TCAM

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

דוגמה 1. טבלת העברה TCAM.

בואו נסתכל על פאלו אלטו 7k חומת אש
אנו רואים שגודל טבלת העברות IPv4* = 32K
יתר על כן, מספר מסלולים זה משותף לכל VSYSs.

בוא נניח שלפי העיצוב שלך אתה מחליט להשתמש ב-4 VSYS.
כל אחד מה- VSYSs הללו מחובר באמצעות BGP לשני MPLS PEs של הענן שבהם אתה משתמש כ-BB. לפיכך, 4 VSYS מחליפים את כל המסלולים הספציפיים אחד עם השני ויש להם טבלת העברה עם אותן קבוצות של מסלולים (אך NHs שונים). כי לכל VSYS יש 2 מפגשי BGP (באותן הגדרות), ואז לכל מסלול שהתקבל באמצעות MPLS יש 2 NH ובהתאם, 2 כניסות FIB בטבלת ההעברה. אם נניח שזו חומת האש היחידה במרכז הנתונים והיא חייבת לדעת על כל המסלולים, אז זה אומר שמספר המסלולים הכולל במרכז הנתונים שלנו לא יכול להיות יותר מ-32K/(4*2) = 4K.

כעת, אם נניח שיש לנו 2 מרכזי נתונים (באותו עיצוב), ואנו רוצים להשתמש ב-VLAN "מתוח" בין מרכזי נתונים (לדוגמה, עבור vMotion), אז כדי לפתור את בעיית הניתוב, עלינו להשתמש בנתיבי מארח. . אבל זה אומר שעבור 2 מרכזי נתונים יהיו לנו לא יותר מ-4096 מארחים אפשריים, וכמובן שזה לא יספיק.

דוגמה 2. ACL TCAM.

אם אתם מתכננים לסנן תעבורה על מתגי L3 (או פתרונות אחרים המשתמשים במתגי L3, למשל, Cisco ACI), אז בבחירת ציוד כדאי לשים לב ל-TCAM ACL.

נניח שאתה רוצה לשלוט בגישה על ממשקי SVI של Cisco Catalyst 4500. לאחר מכן, כפי שניתן לראות מתוך במאמר זה, כדי לשלוט על תעבורה יוצאת (כמו גם נכנסת) בממשקים, אתה יכול להשתמש רק ב-4096 קווי TCAM. אשר בעת שימוש ב-TCAM3 ייתן לך כ-4000 אלף ACEs (קווי ACL).

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

זמינות גבוהה

השאלה היא: האם עלי להשתמש ב-HA עבור חומות אש או להתקין שתי תיבות עצמאיות "במקביל", ואם אחת מהן נכשלת, לנתב את התנועה דרך השנייה?

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

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

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

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

יכולת ניהול

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

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

• תצורות גיבוי
• עדכונים
• שדרוגים
• ניטור
• רישום

ואת כל זה ניתן לפתור על ידי מערכות ניהול מרכזיות.

אז, למשל, אם אתה משתמש בחומת אש של Palo Alto, אז לצפות הוא פתרון כזה.

המשך.

מקור: www.habr.com