מבוא
בשנים האחרונות (הרבה שנים..) יוצא י לא מעט לתכנן רשתות תקשורת ואבטחה של רשתות תקשורת, כאשר כל פעם אני רואה כמה חשוב לבצע תהליך מסודר, וכמה תהליך מסודר ימנע הוצאות מיותרות וגם בעיות טכניות. במאמר זה אני רוצה לעבור על תהליך התכנון של רשת תקשורת.
במאמר זה אעבור על שלבי התכנון – תכנון פונקציונלי שמגדיר מה אנחנו רוצים מהרשת, תכנון ארכיטקטורת רשת ותכנון מפורט, כאשר נעבור על מה אנחנו נעשה בכל אחד מהשלבים, ואיך נוודא ניהול נכון של הפרויקט.
במאמרים הבאים אכנס גם לתכנון כלכלי, איך לבצע רכש בצורה נכונה, על מה לשים דגש ואיך לנהל את כל זה נכון, טכנית וכלכלית.
שלבי התכנון
כמו בכל תחום, בתכנון רשת תקשורת ואבטחת מידע לרשת יש שלושה שלבים עיקריים:
- דרישות פונקציונליות (Functional Specifications)
- תכנון ארכיטקטורת רשת (High Level Design / HLD)
- תכנון מפורט (Low Level Design / LLD)
בדרישות הפונקציונליות נגדיר מה מטרות התכנון, בתכנון הארכיטקטורה נגדיר את קווי המתאר (Guidelines) לתכנון, ובתכנון המפורט ניתן הוראות לבנייה מעשית של הרשת.
שיטת התכנון שאציג כאן אינה מוגדרת בתקינה, ויצרנים שונים לפעמים יגדירו מטרות וסוגי תכנון בצורה קצת שונה – ישנן דוגמאות רבות למסמכי תכנון למוצרים שונים באתרים של יצרנים (למשל ב- Cisco) ואם תעשו גוגל תמצעו אלפי דוגמאות למסמכים שונים.
בסעיפים הבאים נעבור על השלבים, מה נדרש בכל אחד מהם, ומה התוצאות שאנחנו צריכים לקבל מכל אחד מהם. תהליך זה נכון לכל תכנון – שרתים, תוכנה, אבטחת מידע וכד. אנחנו נתמקד ברשת התקשורת באבטחת רשת התקשורת.
דרישות פונקציונליות (Functional Specification)
מטרת התכנון הפונקציונלי הינה לתרגם את הדרישות העסקיות לדרישות טכניות. במילים פשוטות, להגדיר ה בעצם אנחנו צריכים.
תכנון פונקציונלי יגדיר קודם כל את מטרות הפרויקט – הא המטרה היא שיפור בביצועי היישומים ברשת, שיפור בביצועים של יישום מסוים, דרשה לחסכון בעלויות, דרישה לעמידה ברגולציית אבטחת מידע מסוימת וכד'.
דרישות פונקציונליות יכולות להיות למשל (דוגמאות אמיתיות מפרויקטים):
- צורך בהחלפת ציוד ברשת התקשורת עקב סיום חיי המוצרים וסיום שירות למוצר (EOL)
- דרישה עסקית לגיבוי ברמה גבוהה עם העלאת רמת הזמינות לחמש תשיעיות (99.999% זמינות או כ- 5 דקות לכל היותר של Down time בשנה)
- דרישה עמידה ברגולציה של הרשות להגנת הפרטיות הדורשת שמירה והפרדה בין מאגרי מידע
- דרישות לרוחב פס גבוה שנדרש על ידי בית תוכנה עבור הפעלת יישום חדש ברשת
- דרישה רגולטורית להפרדת רשתות IT ו- OT
- דרישה לחסכון בעלויות תקשורת
התוצאה של הדרישות הפונקציונליות צריכה להיות מה אנחנו רוצים מהרשת, כאשר הדרישות יוגדרו בצורה מדויקת שיאפשר למתכנן לגשת לתכנון ארכיטקטורת הרשת (תכנון Green field) או תכנון השינוי ברשת הקיימת (Brown field). חשוב מאוד לא לדלג על שלב זה, ולהגדיר באופן מדויק מה אנחנו צריכים, כדי שבהמשך נתכנן את הרשת לפי צרכי החברה, ולא נתכנן (ובעיקר נשלם..) על דברים שאנחנו לא צריכים. הכנת הדרישות הפונקציונליות אנחנו נכין, שכ רק אנחנו יודעים מה אנחנו צריכים.
ארכיטקטורת רשת (High Level Design / HLD)
קיבלנו את הדרישות הפונקציונליות, ועכשיו אנחנו יודעים למה צריך לתת מענה. המענה יהיה תכנון ארכיטקטורת רשת, או ארכיטקטורת אבטחת מידע, לפי הדרישות שהגדרנו. תכנון זה יכלול את כל הנדרש להבנת דרך העבודה של המערכת, כולל מסמכים, שרטוטים ב- VISIO, טבלאות וכד', ובכלל זה (בתלות בפרויקט, רשימה חלקית):
- כל מרכיבי המערכת/הרשת הנדרשת, ובכלל זה מתגים, נתבים, שרתים עבור מערכות בקרה וכד', לדוגמא:
- מערכת בקרה תופעל על שרת שיותקן במרכז הרשת
- FWsמרכזיים יופעלו להגנה על ה- Data Center, ו- FWs נוספים יופעלו להגנה ביציאה לאינטרנט
- על ה- FWs המרכזיים יופעלו הגנות FW+IDPS, ועל ה- FWs ביציאה לאינטרנט יופעל UTM מלא
- מיקום רכיבי תקשורת, כולל מתגים, נתבים, WAFs, Load Balancers, רכבי הגנה וכד', כולל שרטוט עקרוני של הרשת הנדרשת, לדוגמא:
- מיקום נתבים ברשת, סכמת שרידות ביניהם (HSRP, VRRP וכד'), פרוטוקולי ניצוב שעמן ממליצים לעבוד, זמני שרידות נדרשים וכד'.
- דרישות VLANs (ללא VLAN IDs), מעבר תנועה, תרשימי תנועה, למשל בין איזה VLANs יוגדר ניתוב ובין איזה לא יוגדר וכד'.
- באיזה פרוטוקולים נשתמש, כולל המלצות והסבר מדוע נבחרו פרוטוקולים אלו (למקרה שמוציאים את המסמך לספקים פוטנציאליים ורוצים לקבל חוו"ד נוספות על התכנון), לדוגמא:
- פרוטוקול ניתוב OSPF יופעל ברשתות הפנימיות, יוגדרו VRFs שונים עבור רשתות מנהלה ושיווק, ויוגדר PIM לטובת הפצת מידע מסווג ברשת
- יופעלו מנגנוני סינון ברמה 7 ב- FWs עבור מידע מסווג, עבור מידע רגיל יוגדר מעבר מידע בנתיב חלופי ישירות דרך מתגי הליבה.
מסמך ה- HLD ייתן את עקרונות העבודה שלפיהם יוכן התכנון המפורט (ה- LLD). מי יכין את המסמך? זה נושא קצת רגיש, וישנן שתי אפשרויות.
האפשרות הראשונה היא שאנחנו נכין את הדרישות הפונקציונליות, ונדרום מהספק (במקרה של בל"מ או מכרז מהספק הזוכה) להכין את התכנון. כאן נוכל לדרוש למשל זמני גיבוי שקטנים מ- 50mS, לדרוש עמידה בפרמטרי רשת מסוימים (Bandwidth/Throughput, Delay, Jitter, Packet loss), והספק יצטרך לעשות את התכנון כדי לעמוד בדרישות אלו. היתרון בשיטה זו הוא כמובן שאנחנו דורשים מהספק עמידה בתנאים מסוימים, והוא חייב לעמוד בהם (ובעיה של הספק איך יעשה את זה..). החיסרון הוא כמובן שאנחנו צריכים לבדוק שקיבלנו פתרון שעונה על הצרכים, ולא יותר מכך.
האפשרות השנייה היא שאנחנו נעשה את התכנון, והספק יצטרך לתת פתרון העומד בתכנון זה. במקרה זה אנחנו יכולים לתת גם גמישות מסוימת בתכנון, למשל שתי תצורות רשת שונות, אפשרות מימוש פתרון על ידי פרוטוקולים שונים וכד'. היתרון כאן הוא שאנחנו מגדירים מה אנחנו רוצים, והמענים שנקבל מספקים יהיו למה שאנחנו צריכים ולא יותר מזה. החיסרון כאן הוא כמובן שצריך לוודא עם הספקים שאומנם הפתרון הוא לפי התכנון, אבל לא יספרו לנו אח"כ "שזה לא עובד כי הספק לא אחראי למה שהוא לא תכנן..".
הפתרון הוא כמו תמיד באמצע. אפשר להגדיר תכנון ראשוני ולבקש הערות והצעות (למשל על ידי RFI), אפשר להגדיר דרישות פונקציונליות וקווים כלליים (Guidelines) לתכנון שזה HLD ראשוני וכד', הכול לפי המקרה והדרישות. על תהליך הרכש אגיד כמה מילים בחלק האחרון של במאמר כי זה כבר נושא למאמר בפני עצמו.
דוגמא לשרטוט רשת בשלב ה- HLD:
בשרטוט מתואר דוגמא למבנה רשת הנדרש, מיקום מוצע ל- FWs, רוחבי פס של הממשקים, מיקומי VLANs ב- L3 וחיבור לשרתים. מכאן ניתן להמשיך לתכנון מפורט
תכנון מפורט (Low Level Design / LLD)
התכנון המפורט הוא הכולל את כל הנדרש להפעלה של המערכת, החל משלב הרכש ועד לשלב שלפני בדיקות הקבלה ובכלל זה: מפרטי ציוד, מסמכים, תצורות של ציוד, גרסאות תוכנה, שרטוטים ב- VISIO, טבלאות וכד', ובכלל זה:
- תכנון שרתים מפורט כולל שמות שרתים, תפקיד כל שרת, כתובת IP ולאיזה VLAN שייך, איזה שירותים ותוכנות מופעלים עליו, מי שרת ראשי ומי שרת גיבוי, לדוגמא:
- רשימת שרתים, על איזה ESXi מותקן כל אחד, כתובת IP, שרת ראש או גיבוי
- תכנון מפורט של רשת התקשורת כולל VLANs, כתובות IP, טבלאות ניתוב, פרוטוקולים וכד', לדוגמא:
- מתגים ונתבים – תצורה (ממשקים, ACLs, פרוטוקולים וכל הנדרש להפעלה והגנה מלאה על הציוד)
- תרשימי זרימה עם מספור VLANs, טבלאות ניתוב, כתובות, תרשימי זרימה של Unicast/Multicast flows
- תכנון מפורט לאבטחת מידע כולל הגדרות Rules ב- FWs, הגדרות רכיבי הגנה נוספים, הגדרת Rules במערכות Anomaly detection וכד', לדוגמא:
- קבצי תצורה מלאים של ציוד התקשורת
- קבצי Rule base מלאים של ה- Firewalls
- הגדרת Policies ובכלל זה מי מורשה לדבר עם מי, באיזה יישומים וכד'
- מפרטי חומרה ותוכנה מלאים, מה מותקן על כל רכיב, תרשימי קשר בין רכיבים וכד', לדוגמא:
- תרשימי זרימה של מידע בתוך המערכות השונות
- תרשימי זרימה שלמידע בין מערכות
כל נושא הקשור באופן עבודת המערכת וכל מרכיביה, בכלל זה הסברים, שרטוטים או טבלאות, ככל הנדרש להפעלת הפרויקט במלואו על ידי מהנדסי תקשורת מוסמכים.
הרבה פעמים אני נשאל האם קונפיגורציה הינם חלק מה- LLD. מכיוון שההגדרה של LLD היא שטכנאי/מהנדס מיומן יוכל לקחת את המסמך, ולפי זה להתקין, להגדיר ולהפעיל את הרשת באופן מלא, וללא צורך במסמכים נוספים, אפשר לצרף למסמך קבצי קונפיגורציה (show run) ואפשר שלא לצרף אותם ולהכין אותם בנפרד, במקביל או אחרי ההפעלה. כל עוד ה-LLD מגדיר באופן מדויק את מה שצריך לעשות כדי שהכול יעבוד, אז זה בסדר (ובכל מקרה תמיד יש שינויים מסוימים בתצורה שנעשים במהלך הפרויקט).
בדוגמא הבא אנחנו רואים טבלת כתובות (מצומצמת, חלק מפרויקט גדול):
בטבלה זו ובטבלאות נוספות מוסבר בדיוק אילו כתובות להגדיר, וביחד עם שרטטים נלווים מי שיתקין את הרשת יודע בדיוק אילו כתבות להגדיר. אם ניקח לדוגמא את הטבלה הראשונה (R-Site-1), אנחנו רואים את הממשקים של הנתב, היכן מוגדר LAG / MC-LAG, אילו ממשקים מוגדרים ב- TRUNK, טווחי כתובות, כתובות, והסברים.
תהליכים ומסמכים נוספים
בתהליך מסודר של תכנון וביצוע פרויקט יהיו מספר נקודות ציון נוספות שאותן נצטרך לעבור.
בתחילת הפרויקט ניתן, ועבור פרויקטים עם דרישות ייחודיות גם מומלץ, לבקש הוכחת יכולת עבודה של מה שנדרש (Proof Of Concept / POC), שמיועד לבדוק האם המענה שקיבלנו אכן עומד בדרישה.
בתחילת פרויקט ניתן, ולפי מורכבות הפרויקט גם מומלץ, לבצע פיילוט (Pilot), ולפעמים גם פיילוט ראשון ושני, שבהם ניכנס בהדרגה לפריסה של כל הפרויקט. פיילוט יכול להיות בדיקה של עבודה במחלקה או בסניף בארגון, לבדיקה של יכולות מסוימות וכד'.
בסיום ההתקנה, חייבים להגדיר תוכנת בדיקות (Acceptance Tests Plan / ATP), שבמהלכה נבדוק אם הפרויקט שבוצע עומד בדרישות. כאן נגדר בדיקות תקינות (Go / No-Go), בדיקות פונקציונליות (האם עומדים בדרישות שרידות למשל) ובדיקות ביצועים
מונחים נוספים שניתקל בהם, מגיעים מתחום ניהול פרויקטים, כאשר בניהול פרויקט הקמה של רשת תקשורת ו/או פרויקטים באבטחת מידע נתחיל בד"כ עם סקירה ראשונית (Preliminary Design review / PDR), ובהמשך סקירה מקיפה/קריטית (Critical Design Review / CDR). בד"כ ה- HLD יוצג בשלב ה- PDR וה- LLD בשלב ה- CDR. יש עוד שלבי רבים בניהול פרויקט אולם המטרה כאן היא לתאר את תהליך התכנון בלבד.
איך כל זה משתלב בתהליך הרכש
תהליך הרכש הינו תהליך מורכב (ושווה מאמר בפני עצמו), אבל חשוב להגיד כאן מספר מילים. בהרבה מהפרויקטים שהייתי מעורב בתכנונם, לאחר הגדרה מדויקת של הדרישות בשלב הראשון תכולת הפרויקט השתנתה לחלוטין. פרויקט שהתחיל בדרישה להחלפת עשרות נתבים בסניפים ל- FWs הסתכם בהגדרות ACLs כי הה צריך לקרוא את דרישות הרגולציה ולהבין אותן, פרויקט שהתחיל כפרויקט SD-WAN המשיך כפרויקט נתבים רגיל כי הלקוח לא היה צריך יותר מזה, פרויקט שו"ב בהרבה עשרות אלפי דולרים השתנה לפרויקט הגנה פשוט ברמת תוכנות בסיסיות למחשבים, והקמת רשת סלולרית עם תשתית MPLS ו- BGP-VPNs המשכה כרשת עם הגדרות OSPF פשוטות.
חשוב להגדיר במדויק מה צריכים, לוודא, להתייעץ, לבדוק, שוב פעם לבדוק, ולא להשתולל בהוצאות. הבדל של רישוי, בדיקת עומסים לא מדויקת, כסת"ח מוגזם, כל דבר כזה יכול להכפיל ויותר עלויות פרויקט.
סיכום
היה קצת ארוך הפעם, אבל לסיכום, היה חשוב לי להסביר בצורה מסודרת את תהליך התכנון לפרויקט תקשורת/אבטחה, מה עושים בכל שלב, על מה לשים דגשים וגם מה לא עושים. מקווה שעזרתי, להתראות בפעם הבאה.