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

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

הם סתם צפים בענן ללא גבולות, ללא בידוד וללא הבטחה. אז מה זה אומר עבורכם? אם אתם בונים משהו באז'ר, התחילו קודם עם VNets, לא אחרי שפירסתם את המשאבים, אלא לפני. ה-VNets שלכם הוא הקרקע שעליה אתם בונים. לא הייתם בונים בית בלי לקנות את הקרקע קודם, נכון. אותו הרעיון. כתובות IP ו-CIDR, בחירת מרחב הכתובות שלכם. אז בואו נצלול פנימה. כשיוצרים VNets, ההחלטה הגדולה הראשונה היא בחירת טווח IP. עושים זאת באמצעות סימון CIDR. CIDR הוא קיצור של Classless Inter-Domain Routing. אבל המשמעות היא פשוט שאתם אומרים, אני צריך כמות כזו של כתובות IP. למה זה משנה? כי הטווח שתבחרו קובע כמה משאבים תוכלו להכניס לרשת הווירטואלית שלכם. הנה איך זה עובד. CIDR משתמש בלוכסן ובמספר, כמו 16 או 24. המספר הזה אומר לכם את גודל מרחב הכתובות. 16 נותן לכם בערך 65 אלף כתובות IP. זה המון. 24 נותן לכם בערך 250, שזה מושלם לצוות קטן או לשכבת יישום בודדה. אז, כשמתכננים את הוונט, צריך לחשוב על כמות המשאבים ואיך תרצו לקבץ אותם. עכשיו, אי אפשר סתם לבחור כל טווח IP.

Azure עוקבת אחרי תקן RFC 1918 שמקצה טווחי IP פרטיים לרשתות פנימיות. יש לכם שלוש אפשרויות. הטווח 10, XXX, הוא הגדול ביותר ונותן לכם הרבה מקום לצמוח. הטווח 172.16, X, X מעט קטן יותר, אך עדיין שימושי. והטווח 192.168, X, X, הוא זה שכנראה יש לכם בבית בינתיו. הנה העניין. מרחב הכתובות של הוונט לא יכול לחפוף עם שום רשת אחרת שאליה תרצו להתחבר. זו טעות נפוצה. אנשים רבים בוחרים טווח מוכר, רק כדי לגלות מאוחר יותר שהוא מתנגש עם הרשת הארגונית שלהם. אז אם רשת המשרד של החברה שלכם משתמשת בית 10.0.0.0.0 לוחסן 16, אל תשתמשו באותו טווח באז'ר. אם תנסו לחבר ביניהן מאוחר יותר, הן יתנגשו והתעבורה לא תדע לאן ללכת. תן לי לתת לכם דוגמה קונקרטית. תארו לעצמכם שאתם בונים מערך היברידי, שבו אז'ר מתחברת חזרה למרכז הנתונים המקומי, ומרכז הנתונים משתמש בית 10.0.0.0 לוחסן 16. אם תיצרו וי נט עם אותו טווח, יהיו לכם שתי רשתות שנלחמות על אותן כתובות IP. תחשבו על זה. שתי רשתות שמשתמשות באותו טווח IP לא יכולות לתקשר כמו שצריך. זה כמו שני בתים עם אותה כתובת.

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

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

ניתן להכיל מדיניות וחוקים על כל רשת המשנה בבת אחת, במקום להגדיר כל משאב בנפרד. זה חוסך זמן ומפחית שגיאות. עכשיו, הנה פרט שתופס אנשים לא מוכנים. ארגון שומרת 5 כתובות IP בכל רשת משנה לצרכים פנימיים שלה כמו ניתוב ו-DNS. אז, אם אתם יוצרים רשת משנה עם טווח 24 שנותן לכם 256 כתובות, אתם מקבלים בפועל רק 251 שמישות. זה מכשול נפוץ. אתם מתכננים 256, אבל מקבלים רק 251. לכן, תמיד תוסיפו קצת מעבר כשאתם מגדירים גודל של רשתות משנה. החדשות הטובות הן שאפשר להוסיף רשתות משנה אחרי יצירת אבנת. אתם לא נעולים על אלו שהגדרתם בזמן היצירה. אז אם הבנתם שאתם צריכים רשת משנה נפרדת לכלי ניהול או מערכות ניטור, הוסיפו אותה אחר כך. אין בעיה, אבל עדיין עדיף לתכנן אותן מראש. הוספת רשתות משנה מאוחר יותר אפשרית, אבל ייתכן שתצטרכו להזיז משאבים, מה שיכול להפריע. אבל הנה השיטה הטובה ביותר. השתמשו ברשתות משנה נפרדות עבור שכבות שונות של האפליקציה שלכם מההתחלה. חישבו על ארכיטקטורת האפליקציה שלכם. בדרך כלל, יש לכם שכבת חזית שמטפלת בבקשות משתמשים, שכבת צד שרת לאיבוד לוגיקה עסקית, ושכבת נתונים שמאכסנת מידע.

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

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

שימושי אם אתה יודע שתזדקק למספר כתובות IP ציבוריות עבור פרויקט. מה זה אומר עבורך? כתובות IP פרטיות הן ברירת המחדל הבטוחה. הן כמו שלוחת טלפון פנימית. כתובות IP ציבוריות הן בחירה מכוונת שעושים רק כשצריך משהו שיהיה נגיש מבחוץ. וכשאתה צריך אותן, חשוב האם דרושה לך כתובת סטטית או דינמית, והאם קידומת היא הגיונית. קבוצות הבטחת רשת שולטות בתעבורה. אז סידרת את העת שלך את רשתות המשנה ואת כתובות IP. אבל איך אתה באמת שולט איזו תעבורה מורשת להיכנס ולצאת? כאן נכנסות לתמונה קבוצות הבטחת רשת NSG. NSG הוא השומר שמבקר איזו תעבורה נכנסת ויוצאת מהמשאבים שלך. חשוב על זה כעל מאבטח בפתח של מועדון שבודק תעודות זהות, מסתכל ברשימת המוזמנים ומסרב לכל מי שלא אמור להיות שם. כל פיסת תעבורה שמנסה להגיע למשאב שלך חייבת לעבור קודם דרך המאבטח הזה. קבוצות NSG עובדות לפי כללים. כל כלל אומר אפשר או מנה על סמך ארבעה דברים, כתובת IP מקור, כתובת IP יעד, מספר פורט והפרוטוקול. אז אתה יכול לומר אפשר תעבורה מכתובת ה-IP של המשרד שלי בפורט 443 או מנע כל תעבורה מהאינטרנט בפורט 22.

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

אותו רעיון תקף ל-RDP בפורט 3389 עבור מכונות וווינדוס. מה זה אומר מבחינתך? קבוצות אבטחה, NSGS, הן קו ההגנה הראשון שלך, והחלק הטוב ביותר הוא שהן בחינם. אין עלות נוספת לשימוש בהן, אז אין תירוץ לא להגדיר אותן. לכל רשת משנה, סבנט, ולכל משאב צריכה להיות מוצמדת NSG. התחל עם, חסום הכל, ופתח רק את מה שאתה צריך. תבלאות ניתוב וניתוב, הכוונת תעבורה. עכשיו, בוא נדבר על ניתוב, כי ברגע שהחלטת איזו תעבורה מותרת, אתה צריך להחליט לאן היא באמת הולכת. העניין הוא ש-Azure יוצרת באופן אוטומטי מסלולי מערכת עבור כל רשת משנה. אתה לא צריך לעשות כלום. חשוב על זה כמו על GPS, מובנה שמכיר את הכבישים הבסיסיים. תעבורה בתוך אבנט, תעבורה לבנץ מקושרים, תעבורה לאינטרנט. הכל פשוט עובד מהרגע הראשון, אבל לפעמים ה-GPS המובנה לא לוקח אותך לאן שאתה רוצה להגיע. זה המקום שבו אתה צריך מסלולים מוגדרים על ידי משתמש . אלה מאפשרים לך לעקוף את מסלולי המערכת של Azure ולקחת שליטה על הנתיב שהתעבורה עוברת בו. איך זה עובד? אתה יוצר תבלת ניתוב.

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

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

תעבורה ביניהן תישאר ברשת הפרטית של מייקרוסופט ללא שערי VPN ללא כתובות IP ציבוריות פשוט חיבור פרטי עשיר אבל יש חוק שאסור בתכלית האיסור להפר לרשתות וינט מקושרות אסור שיהיו מרחבי כתובות חופפים אם שתי רשתות וינט מנסות להשתמש בטווח 10.0.0.0 לוחסן 16 לא ניתן לקשר ביניהן כתובות ה-IP התנגשו ו-Azure לא תדע לאיזו רשת שייכת חבילת הנתונים אז זוכרת טיפ התכנון המוקדם על בחירה זהירה של מרחב הכתובות זו הסיבה אם אתה חושב שאולי תצטרך לקשר רשתות וינט בהמשך הוודא שהטווחים שלהן לא חופפים מההתחלה כעת, הנה פרט שמכשיל אנשים קישור הוא לא טרנזיטיבי מה זה אומר? נניח ש-VNETM מקושר ל-VNETB ו-VNETB מקושר ל-VNETC רשת A לא מגיעה אוטומטית לצ'י דרך B הן לא מחוברות כל קישור הוא חיבור ישיר בין שתי רשתות VNET בלבד VNET בלבד אם אתה רוצה שאת תתקשר עם C הלך ליצור קישור נפרד בין LSE אז איך מטפלים בזה בקנה מידה גדול? משתמשים בארכיטקטורת Hub & Spock VNET מרכזי אחד ה-Hub מחובר בפירינג עם VNETS רבים אחרים הספויקס ה-Hub עשוי להכיל שירותים משותפים כמו חומת אש שער VPN או קלי ניטור הספויקס מכילים את עומסי העבודה האישיים שלך כל ספוק מחובר ישירות ל-Hub אך הספויקס אינה מחוברים זה לזה אם ספוק צריך להגיע לספוק אחר התעבורה עוברת דרך ה-Hub זה שומר על סדר ומספק לך מקום מרכזי להחלת מדיניות הבטחה מה זה אומר מבחינתך?

פירינג היא הדרך לבנות רשתות המסתראות על פני VNETS ואזורים מרובים זהו הגשר בין הבניינים שלך תכנן את מרחבי הכתובות כך שלא תהיה חפיפה ביניהם זכור ש-פירינג אינו טרנזיטיבי ושקול תכנון Hub & Spock כשאתה מתחיל לצמוח מעבר ל-VNET בודד איך הכל מתחבר התמונה הגדולה אז בואו ניקח צעד אחורה ונראה איך החלקים האלה משתלבים יחד שם נמצא הכוח האמיתי אתה מתחיל עם VNET זהו המרחב הפרטי שלך ב-Azure תחשוב על זה כעל השטח שלך בתוך השטח הזה אתה יוצר תת רשתות אלה החדרים שלך אחד לשרתי אינטרנט אחד לבסיסי נתונים ואחד לכלי ניהול כל סאבנט מקבל בלוק כתובות משלו שנגזר ממרחב הכתובות של ה-VNET לאחר מכן לאחר מכן אתה מוסיף הבטחה קבוצות הבטחת רשת מצורפות לסאבנט שלך הן שולטות איזו תעבורה מורשת להיכנס ולצאת הסובנט של האינטרנט שלך מאפשר תעבורה מהרשת בפורט 443 הסובנט של בסיס הנתונים מאפשר רק תעבורה מהסובנט של האינטרנט בפורט 1433 המאבטח בכל דלת יודע בדיוק מרשאי לעבור בשלב הבא אתה מגדיר ניתוב אולי תרצה שכל תעבורת האינטרנט היוצאת תעבור דרך חומת אש לבדיקה אתה יוצר תבלת ניתוב מוסיף נתיב מותאם אישית ומקשר אותו לסאבנט שלך כעת התעבורה עוקבת אחר הנתיב שתכננת במקום ברירת המחדל של Azure ולבסוף אתה מחבר הכל יחד אתה מחבר את ה-VNET שלך עם VNETS אחרים אולי VNET מרכזי שמחזיק את חומת האש והשירותים המשותפים כעת האפליקציה שלך מסתרת על פני רשתות מרובות אך הכל עובד כמערכת אחת מחוברת הנה האסימון שנופל אף אחד מהחלקים האלה לא עובד בווידוד VNET ללא Subnets הוא רק שטח רק Subnets ללא NSGS הם פרוצים לחלוטין ניתוב ללא תכנון ברור שולח תעבורה למקום הלא נכון Hearing ללא תכנון יוצר התנגשויות בכתובות הם מהווים מערכת כל חלק תלוי באחרים תן לי לתת לך דוגמה מוחשית תאר לעצמך אפליקציית אינטרנט שרתי האינטרנט שלך נמצאים בסובנט ציבורי עם NSG שמאפשר תעבורת HTTPS מהאינטרנט שרתי האפליקציה שלך נמצאים בסובנט פרטי שמקבל רק תעבורה מהסובנט של האינטרנט מסד הנתונים שלך נמצא בתת רשת פרטית אחרת שמקבלת תעבורה רק מטת רשת האפליקציה טבלת ניתוב מכריחה את כל התעבורה היוצאת לעבור דרך חומת אש בבנט המרכזי לצורכי רישום מובדיקה והכל מחובר לרשת הארגונית שלך כך שהצוות הפנימי שלך יכול לנהל את זה זה הערך האמיתי לא אף תכונה בודדת זה האופן שבו כולם עובדים יחד לפני 20 שנה היית קונה שרתים נפרדים מגדיר נתבים פיזיים ומנהל חומות אש לכל מכשיר הכל היה ידני איתי ויקר Azure נותנת לך את כל זה קשירות אתה מגדיר את זה בכמה לחיצות או בסקריפט וזה פשוט עובד מה זה אומר מבחינתך ברגע שתבין איך החלקים האלה משתלבים הרשות באז'ר הופך לצפוי אתה לא מנחש אתה מתכנן וכשמה שהוא משתבש אתה יודע בדיוק איפה לחפש כי אתה מבין את המערכת אז הנה מה שאני רוצה שתיקח מהפרק הזה ראשית הצעד החשוב ביותר שאתה יכול לנקוט צור וי נת עם מרחב כתובות מתוכנן היטב לפני שאתה פורס משהו ההחלטה הבודדת הזו משפיעה על הכל בהמשך שנית השתמש בתת רשתות כדי להפריד בין שכבות האפליקציה שלך שרתי אינטרנט שרתי אפליקציה מסדי נתונים תן לכל אחד את המרחב שלו ושלישית התחל עם NSGS הם בחינם הם עוצמתיים והם משפרים משמעותית את האבטחה שלך מהיום הראשון הבנת שלך הוא הבסיס לכל מה שאתה בונה באז'ר עשה זאת נכון והכל יהיה קל יותר עשה זאת לא נכון ותבלה את כל זמניך במאבק ברשת שלך הרשם בפלטפורמת הפודקסטים המועדפת עליך ושתף את זה עם מי שמתחיל את מסע האז'ר שלו השאר תגובה עם מה שהוא התחבר לך אני אראה אותך בפרק הבא תודה רבה