WEBVTT

00:00:00.000 --> 00:00:01.740
מהי רשת וירטואלית של Azure?

00:00:01.960 --> 00:00:06.720
רוב האנשים שומעים את המונח הזה וחושבים שזו עוד הגדרה שמפעילים כשפורסים מכונה וירטואלית,

00:00:06.940 --> 00:00:08.700
משהו שמסמנים בטבע ושוכחים ממנו.

00:00:08.820 --> 00:00:09.900
אבל האמת היא אחרת.

00:00:10.120 --> 00:00:14.660
רשת וירטואלית של Azure היא לא רק הגדרה, היא הבסיס לכל מה שאתם בונים באזר.

00:00:14.840 --> 00:00:20.240
כל מכונה וירטואלית, כל בסיס נתונים, כל שירות אפליקציה וכל פונקציה שתפרסו, כולם יושבים בתוכה.

00:00:20.340 --> 00:00:23.540
ואם אתם לא מבינים איך זה עובד, אתם עובדים בצורה עיוורת.

00:00:23.540 --> 00:00:29.500
עד סוף הפרק הזה, תבינו מהו וינט באמת, איך הוא עובד ולמה כל משווא שאתם פורסים תלוי בו.

00:00:29.620 --> 00:00:34.960
נזכור מהו וינט, איך כתובות IP עובדות, רשתות משנה, הבטחה, ניתוב ואיך לחבר רשתות וינט זו לזו.

00:00:35.080 --> 00:00:37.240
קחו את הקפה שלכם ובואו נצלול פנימה.

00:00:37.360 --> 00:00:39.500
מהו וינט? הרשת הפרטית בענן.

00:00:39.700 --> 00:00:41.520
נתחיל בהגדרה הפשוטה ביותר.

00:00:41.700 --> 00:00:46.260
רשת וירטואלית של Azure, או בקיצור וינט, היא הרשת הפרטית שלכם בתוך Azure.

00:00:46.260 --> 00:00:48.460
תחשבו על זה כמו על בניין משרדים פרטי.

00:00:48.580 --> 00:00:50.480
רק אנשים שאתם מאשרים יכולים להיכנס.

00:00:50.640 --> 00:00:54.500
אתם שולטים במי שנכנס בדלת, מי מגיע לאיזו קומה, ומי נשאר בחוץ לחלוטין.

00:00:54.640 --> 00:00:56.980
לפני שהיו VNets, הדברים נראו אחרת.

00:00:57.200 --> 00:01:01.240
הייתם פורסים מכונה וירטואלית בענן, והיא הייתה למעשה חשופה לאינטרנט כברירת מחדל.

00:01:01.360 --> 00:01:02.640
ללא רשת פרטית סביבה.

00:01:02.740 --> 00:01:05.160
כל מי שידע את כתובת ה-IP יכול היה לנסות להתחבר.

00:01:05.340 --> 00:01:06.440
זה היה סיוט הבטחה.

00:01:06.440 --> 00:01:10.540
מה השתנה, Azure נתנה לכם את היכולת ליצור מרחבי רשת פרטיים ומבודדים.

00:01:10.660 --> 00:01:11.660
אתם מגדירים גבול.

00:01:11.840 --> 00:01:13.300
אתם מחליטים מה נכנס בתוכו.

00:01:13.440 --> 00:01:16.500
שום דבר מחוץ לגבול הזה לא יכול להיכנס אלא אם אישרתם זאת במפורש.

00:01:16.680 --> 00:01:18.040
דבר אחד שכדאי לדעת מראש,

00:01:18.240 --> 00:01:19.980
הוונט שלכם חי באזור Azure ספציפי.

00:01:20.080 --> 00:01:20.760
הוא לא גלובלי.

00:01:20.940 --> 00:01:23.200
צרו VNets במערב אירופה ושם הוא נשאר.

00:01:23.200 --> 00:01:25.700
משאבים באזור אחר לא יכולים פשוט לקפוץ לתוכו.

00:01:25.700 --> 00:01:28.600
הם יצטרכו VNets משלהם או שתצטרכו לחבר ביניהם מאוחר יותר.

00:01:28.780 --> 00:01:31.720
כשאתם יוצרים VNets, אתם מגדירים את מרחב כתובות ה-IP בעצמכם.

00:01:31.880 --> 00:01:33.120
Azure לא בוחרת עבורכם.

00:01:33.280 --> 00:01:36.120
אתם מחליטים על טווח כתובות ה-IP שהמשאבים שלכם ישתמשו בו.

00:01:36.280 --> 00:01:39.340
זו אחריות גדולה ונדבר על איך לעשות זאת נכון בחלק הבא.

00:01:39.480 --> 00:01:40.800
הנה הנקודה העיקרית.

00:01:40.940 --> 00:01:42.240
VNets הם הבסיס.

00:01:42.240 --> 00:01:47.040
כל מכונה וירטואלית, כל בסיס נתונים וכל פונקציית Azure שאתם פורסים,

00:01:47.220 --> 00:01:48.340
יושבים בתוך אחד כזה.

00:01:48.500 --> 00:01:51.760
ללא VNets, למשאבים שלכם אין הקשר רשת פרטי.

00:01:51.880 --> 00:01:55.300
הם סתם צפים בענן ללא גבולות, ללא בידוד וללא הבטחה.

00:01:55.400 --> 00:01:56.600
אז מה זה אומר עבורכם?

00:01:56.760 --> 00:01:59.500
אם אתם בונים משהו באז'ר, התחילו קודם עם VNets,

00:01:59.700 --> 00:02:01.700
לא אחרי שפירסתם את המשאבים, אלא לפני.

00:02:01.880 --> 00:02:04.000
ה-VNets שלכם הוא הקרקע שעליה אתם בונים.

00:02:04.000 --> 00:02:06.600
לא הייתם בונים בית בלי לקנות את הקרקע קודם, נכון.

00:02:06.720 --> 00:02:07.500
אותו הרעיון.

00:02:07.680 --> 00:02:10.720
כתובות IP ו-CIDR, בחירת מרחב הכתובות שלכם.

00:02:10.840 --> 00:02:12.020
אז בואו נצלול פנימה.

00:02:12.020 --> 00:02:15.340
כשיוצרים VNets, ההחלטה הגדולה הראשונה היא בחירת טווח IP.

00:02:15.580 --> 00:02:17.480
עושים זאת באמצעות סימון CIDR.

00:02:17.640 --> 00:02:20.280
CIDR הוא קיצור של Classless Inter-Domain Routing.

00:02:20.580 --> 00:02:23.900
אבל המשמעות היא פשוט שאתם אומרים, אני צריך כמות כזו של כתובות IP.

00:02:24.100 --> 00:02:24.860
למה זה משנה?

00:02:24.860 --> 00:02:29.580
כי הטווח שתבחרו קובע כמה משאבים תוכלו להכניס לרשת הווירטואלית שלכם.

00:02:29.740 --> 00:02:30.680
הנה איך זה עובד.

00:02:30.840 --> 00:02:34.180
CIDR משתמש בלוכסן ובמספר, כמו 16 או 24.

00:02:34.440 --> 00:02:36.840
המספר הזה אומר לכם את גודל מרחב הכתובות.

00:02:36.840 --> 00:02:40.120
16 נותן לכם בערך 65 אלף כתובות IP.

00:02:40.380 --> 00:02:40.920
זה המון.

00:02:41.100 --> 00:02:46.140
24 נותן לכם בערך 250, שזה מושלם לצוות קטן או לשכבת יישום בודדה.

00:02:46.300 --> 00:02:51.060
אז, כשמתכננים את הוונט, צריך לחשוב על כמות המשאבים ואיך תרצו לקבץ אותם.

00:02:51.060 --> 00:02:53.600
עכשיו, אי אפשר סתם לבחור כל טווח IP.

00:02:53.800 --> 00:02:58.980
Azure עוקבת אחרי תקן RFC 1918 שמקצה טווחי IP פרטיים לרשתות פנימיות.

00:02:59.180 --> 00:03:00.460
יש לכם שלוש אפשרויות.

00:03:00.640 --> 00:03:04.240
הטווח 10, XXX, הוא הגדול ביותר ונותן לכם הרבה מקום לצמוח.

00:03:04.240 --> 00:03:08.280
הטווח 172.16, X, X מעט קטן יותר, אך עדיין שימושי.

00:03:08.400 --> 00:03:12.960
והטווח 192.168, X, X, הוא זה שכנראה יש לכם בבית בינתיו.

00:03:13.080 --> 00:03:13.780
הנה העניין.

00:03:13.960 --> 00:03:18.000
מרחב הכתובות של הוונט לא יכול לחפוף עם שום רשת אחרת שאליה תרצו להתחבר.

00:03:18.000 --> 00:03:19.080
זו טעות נפוצה.

00:03:19.160 --> 00:03:23.720
אנשים רבים בוחרים טווח מוכר, רק כדי לגלות מאוחר יותר שהוא מתנגש עם הרשת הארגונית שלהם.

00:03:23.720 --> 00:03:29.500
אז אם רשת המשרד של החברה שלכם משתמשת בית 10.0.0.0.0 לוחסן 16, אל תשתמשו באותו טווח באז'ר.

00:03:29.640 --> 00:03:33.400
אם תנסו לחבר ביניהן מאוחר יותר, הן יתנגשו והתעבורה לא תדע לאן ללכת.

00:03:33.560 --> 00:03:35.200
תן לי לתת לכם דוגמה קונקרטית.

00:03:35.200 --> 00:03:43.820
תארו לעצמכם שאתם בונים מערך היברידי, שבו אז'ר מתחברת חזרה למרכז הנתונים המקומי, ומרכז הנתונים משתמש בית 10.0.0.0 לוחסן 16.

00:03:43.820 --> 00:03:48.460
אם תיצרו וי נט עם אותו טווח, יהיו לכם שתי רשתות שנלחמות על אותן כתובות IP.

00:03:48.660 --> 00:03:49.420
תחשבו על זה.

00:03:49.600 --> 00:03:53.140
שתי רשתות שמשתמשות באותו טווח IP לא יכולות לתקשר כמו שצריך.

00:03:53.320 --> 00:03:55.160
זה כמו שני בתים עם אותה כתובת.

00:03:55.160 --> 00:03:56.180
הדואר מתבלבל.

00:03:56.180 --> 00:03:58.220
זו בעיה שלא תרצו לפתור בדיעבד.

00:03:58.320 --> 00:04:00.380
אז תכננו מראש ובחרו טווח ייחודי.

00:04:00.480 --> 00:04:01.500
והנה טיפ לתכנון.

00:04:01.680 --> 00:04:04.000
בחרו טווח גדול יותר ממה שאתם חושבים שאתם צריכים.

00:04:04.140 --> 00:04:06.120
אתם אולי חושבים שתצטרכו רק 24 עכשיו.

00:04:06.320 --> 00:04:08.540
אבל כשהאפליקציה תגדל, תתחרטו שלא בחרתם 16.

00:04:08.740 --> 00:04:10.580
אי אפשר לשנות את זה בקלות אחר כך.

00:04:10.760 --> 00:04:14.660
ברגע שהעת נוצר ופרסתם משאבים, שינוי מרחב הכתובות הוא עסק מסובך.

00:04:14.820 --> 00:04:17.580
זה אפשרי, אבל זה לא משהו שתרצו לעשות במערכת חיה.

00:04:17.580 --> 00:04:19.440
לכן, תנו לעצמכם מקום לצמוח.

00:04:19.580 --> 00:04:20.640
מה זה אומר מבחינתכם?

00:04:20.780 --> 00:04:23.100
חישבו על מרחב הכתובות של אבנט שלכם כמו על קניית קרקע.

00:04:23.200 --> 00:04:24.420
קחו מספיק לצמיחה עתידית.

00:04:24.560 --> 00:04:26.880
אם אתם חושבים שאתם צריכים חלקה קטנה, קנו אחת בינוני.

00:04:27.040 --> 00:04:28.440
אתם תודו לעצמכם אחר כך.

00:04:28.620 --> 00:04:29.540
זו השורה התחתונה.

00:04:29.680 --> 00:04:32.400
תכננו את מרחב הכתובות שלכם מתוך מחשבה על צמיחה עתידית.

00:04:32.520 --> 00:04:34.760
רשתות משנה, סאבנט, חלוקת הרשת שלכם.

00:04:34.880 --> 00:04:37.200
אז יש לכם וינט ובחרתם את מרחב הכתובות.

00:04:37.200 --> 00:04:39.940
מה עכשיו? לא פשוט זורקים את הכל לתוך בריכה אחת גדולה.

00:04:40.020 --> 00:04:41.460
כאן נכנסות לתמונה רשתות המשנה.

00:04:41.600 --> 00:04:44.140
רשתות משנה הן מאבני הבניין הבסיסיות של אבנט שלכם.

00:04:44.260 --> 00:04:46.700
הן מאפשרות לכם לארגן ולהבטח את המשאבים שלכם.

00:04:46.880 --> 00:04:49.820
רשת משנה היא חלק קטן יותר ממרחב הכתובות של אבנט.

00:04:49.980 --> 00:04:53.000
אם אבנט הוא הבניין, רשתות המשנה הן החדרים הנפרדים.

00:04:53.200 --> 00:04:57.500
לא הייתם שמים את חדר השרתים, עמדת הקבלה וחדר ההפסקה באותו חלל פתוח, נכון.

00:04:57.500 --> 00:05:02.100
אותו רעיון כאן. זה מושג פשוט, אבל הוא עושה הבדל עצום בדרך שבה אתם מנהלים את הרשת.

00:05:02.200 --> 00:05:04.240
משאבים שונים הולכים לרשת משנה שונות.

00:05:04.240 --> 00:05:09.280
שרתי האינטרנט שלכם ברשת אחת, בסיסי הנתונים בשנייה, והלוגיקה של האפליקציה בשלישית.

00:05:09.420 --> 00:05:10.640
למה? שתי סיבות.

00:05:10.800 --> 00:05:11.820
אבטחה וארגון.

00:05:12.020 --> 00:05:15.060
בואו נדבר קודם על אבטחה, כי היא בדרך כלל הכי חשובה.

00:05:15.160 --> 00:05:16.140
קודם כל אבטחה.

00:05:16.140 --> 00:05:20.300
אם מי שהוא פורץ לשרת האינטרנט שלכם, אתם לא רוצים שתהיה לו גישה ישירה לבסיס הנתונים.

00:05:20.460 --> 00:05:22.680
רשתות משנה נפרדות יוצרות מחסום טבעי.

00:05:22.760 --> 00:05:26.180
התוקף יצטרך לעבור את הגבול הזה, ואתם יכולים לשלוט בדיוק על מה שעובר.

00:05:26.180 --> 00:05:30.020
אתם יכולים גם להשתמש בקבוצות אבטחת רשת כדי לשלוט בתעבורה בין רשתות משנה.

00:05:30.200 --> 00:05:34.560
זה נושא לסרטון אחר, אבל כדאי לדעת שרשתות משנה הן הבסיס להבטחה הזו.

00:05:34.680 --> 00:05:35.700
שנית, ארגון.

00:05:35.880 --> 00:05:38.560
כשלכל דבר יש את המקום שלו, הניהול קל יותר.

00:05:38.560 --> 00:05:43.640
אתם יודעים איזו רשת מכילה את משאבי היי פרונט אנד, ואיזו מחזיקה את נתוני היי בק אנד.

00:05:43.660 --> 00:05:48.880
ניתן להכיל מדיניות וחוקים על כל רשת המשנה בבת אחת, במקום להגדיר כל משאב בנפרד.

00:05:49.040 --> 00:05:50.780
זה חוסך זמן ומפחית שגיאות.

00:05:50.920 --> 00:05:53.320
עכשיו, הנה פרט שתופס אנשים לא מוכנים.

00:05:53.520 --> 00:05:58.260
ארגון שומרת 5 כתובות IP בכל רשת משנה לצרכים פנימיים שלה כמו ניתוב ו-DNS.

00:05:58.260 --> 00:06:04.500
אז, אם אתם יוצרים רשת משנה עם טווח 24 שנותן לכם 256 כתובות, אתם מקבלים בפועל רק 251 שמישות.

00:06:04.620 --> 00:06:05.440
זה מכשול נפוץ.

00:06:05.580 --> 00:06:08.100
אתם מתכננים 256, אבל מקבלים רק 251.

00:06:08.280 --> 00:06:10.860
לכן, תמיד תוסיפו קצת מעבר כשאתם מגדירים גודל של רשתות משנה.

00:06:10.860 --> 00:06:13.900
החדשות הטובות הן שאפשר להוסיף רשתות משנה אחרי יצירת אבנת.

00:06:14.020 --> 00:06:16.460
אתם לא נעולים על אלו שהגדרתם בזמן היצירה.

00:06:16.540 --> 00:06:21.400
אז אם הבנתם שאתם צריכים רשת משנה נפרדת לכלי ניהול או מערכות ניטור, הוסיפו אותה אחר כך.

00:06:21.400 --> 00:06:24.140
אין בעיה, אבל עדיין עדיף לתכנן אותן מראש.

00:06:24.300 --> 00:06:28.640
הוספת רשתות משנה מאוחר יותר אפשרית, אבל ייתכן שתצטרכו להזיז משאבים, מה שיכול להפריע.

00:06:28.760 --> 00:06:30.240
אבל הנה השיטה הטובה ביותר.

00:06:30.240 --> 00:06:33.440
השתמשו ברשתות משנה נפרדות עבור שכבות שונות של האפליקציה שלכם מההתחלה.

00:06:33.580 --> 00:06:35.480
חישבו על ארכיטקטורת האפליקציה שלכם.

00:06:35.640 --> 00:06:42.320
בדרך כלל, יש לכם שכבת חזית שמטפלת בבקשות משתמשים, שכבת צד שרת לאיבוד לוגיקה עסקית, ושכבת נתונים שמאכסנת מידע.

00:06:42.320 --> 00:06:44.620
לכל אחת מהן צריכה להיות רשת משנה משלה.

00:06:44.740 --> 00:06:47.640
אל תחכו עד שתגיעו לסביבת הייצור כדי להבין שצריך להפריד דברים.

00:06:47.840 --> 00:06:49.960
זה הרבה יותר קשה כשהמשאבים כבר פעוסים.

00:06:50.100 --> 00:06:51.200
מה זה אומר מבחינתכם?

00:06:51.340 --> 00:06:54.080
רשתות משנה הן הדרך שלכם לשמור על הרשת מאורגנת ומאובטחת.

00:06:54.220 --> 00:06:55.560
הן החדרים בבניין שלכם.

00:06:55.700 --> 00:06:58.540
תכננו אותן מוקדם ותנו לכל שכבה באפליקציה את המרחב שלה.

00:06:58.640 --> 00:07:00.700
ככה שומרים על הרשת נקייה ומאובטחת.

00:07:00.700 --> 00:07:02.920
כתובות IP ציבוריות לעומת פרטיות.

00:07:03.060 --> 00:07:03.960
מי יכול לראות מה?

00:07:04.140 --> 00:07:07.160
בואו נדבר על כתובות IP, כי לא כל כתובות ה-IP זהו.

00:07:07.280 --> 00:07:11.480
כשאתם פורסים משאב בתוך V-Net, הוא מקבל כתובת IP פרטית כברירת מחדל.

00:07:11.640 --> 00:07:14.920
זו הכתובת שבה הוא משתמש כדי לתקשר עם משאבים אחרים בתוך אבנט.

00:07:15.120 --> 00:07:17.060
חישבו על זה כמו שלוחה טלפונית פנימית.

00:07:17.280 --> 00:07:19.320
רק אנשים בתוך הבניין יכולים להגיע אליה.

00:07:19.320 --> 00:07:23.220
כתובות IP פרטיות נגישות רק מתוך האובנט או מרשתות שמחוברות אליו.

00:07:23.340 --> 00:07:27.220
אם אתם יושבים בבית עם המחשב הנייד, לא תוכלו להגיע לכתובת IP פרטית באז'ר.

00:07:27.360 --> 00:07:28.480
היא לא נמצאת באינטרנט.

00:07:28.620 --> 00:07:30.320
היא בתוך הרשת הפרטית שלכם.

00:07:30.460 --> 00:07:32.460
אז איך הופכים משאב לנגיש מהאינטרנט?

00:07:32.640 --> 00:07:34.300
נותנים לו כתובת IP ציבורית.

00:07:41.480 --> 00:07:46.780
אתם מקצים אותם במפורש, כי Azure לעולם לא נותנת למשאבים שלכם IP ציבורי, אלא אם כן תבקשו.

00:07:46.900 --> 00:07:47.760
זה מתוכנן כך.

00:07:47.900 --> 00:07:50.940
ברירת המחדל צריכה להיות פרטית, וציבורית צריכה להיות בחירה מודעת.

00:07:51.040 --> 00:07:52.440
וכאן הרבה מתחילים עושים טעות.

00:07:52.620 --> 00:07:54.540
הם נותנים כתובות IP ציבוריות להקל.

00:07:54.700 --> 00:07:57.900
שרת האינטרנט שלהם, מסעד הנתונים, ה-API של צד השרת, כולם מקבלים אחת.

00:07:58.000 --> 00:07:58.880
זה סיכון הבטחה.

00:07:59.000 --> 00:08:03.220
מסעד הנתונים שלכם לא צריך להיות נגיש מהאינטרנט, וגם לא ה-API של צד השרת שלכם.

00:08:03.220 --> 00:08:07.220
רק למשאבי חזית שמשתמשים באמת מתקשרים איתם צריכות להיות כתובות IP ציבוריות.

00:08:07.400 --> 00:08:10.700
כעת, כתובות IP ציבוריות מגיעות בשני סוגים, סטטיות ודינמיות.

00:08:10.860 --> 00:08:14.200
כתובת IP ציבורית סטטית נשארת קבועה גם אם עוצרים ומפעילים מחדש את המשאב.

00:08:14.340 --> 00:08:16.460
כתובת IP ציבורית דינמית יכולה להשתנות.

00:08:16.600 --> 00:08:20.900
אם אתה מריץ יישום בסביבת ייצור, כנראה תרצה כתובות סטטיות כדי שהמשתמשים תמיד ימצאו אותך.

00:08:21.020 --> 00:08:23.720
אם אתה בודק משהו, כתובת דינמית עשויה להספיק.

00:08:33.220 --> 00:08:37.220
שימושי אם אתה יודע שתזדקק למספר כתובות IP ציבוריות עבור פרויקט.

00:08:37.220 --> 00:08:38.220
מה זה אומר עבורך?

00:08:38.220 --> 00:08:40.220
כתובות IP פרטיות הן ברירת המחדל הבטוחה.

00:08:40.220 --> 00:08:42.220
הן כמו שלוחת טלפון פנימית.

00:08:42.220 --> 00:08:46.220
כתובות IP ציבוריות הן בחירה מכוונת שעושים רק כשצריך משהו שיהיה נגיש מבחוץ.

00:08:46.220 --> 00:08:50.220
וכשאתה צריך אותן, חשוב האם דרושה לך כתובת סטטית או דינמית,

00:08:50.220 --> 00:08:51.220
והאם קידומת היא הגיונית.

00:08:51.220 --> 00:08:53.220
קבוצות הבטחת רשת שולטות בתעבורה.

00:08:53.220 --> 00:08:57.220
אז סידרת את העת שלך את רשתות המשנה ואת כתובות IP.

00:08:57.220 --> 00:09:00.220
אבל איך אתה באמת שולט איזו תעבורה מורשת להיכנס ולצאת?

00:09:00.220 --> 00:09:03.220
כאן נכנסות לתמונה קבוצות הבטחת רשת NSG.

00:09:03.220 --> 00:09:06.220
NSG הוא השומר שמבקר איזו תעבורה נכנסת ויוצאת מהמשאבים שלך.

00:09:06.220 --> 00:09:10.220
חשוב על זה כעל מאבטח בפתח של מועדון שבודק תעודות זהות,

00:09:10.220 --> 00:09:13.220
מסתכל ברשימת המוזמנים ומסרב לכל מי שלא אמור להיות שם.

00:09:13.220 --> 00:09:17.220
כל פיסת תעבורה שמנסה להגיע למשאב שלך חייבת לעבור קודם דרך המאבטח הזה.

00:09:17.220 --> 00:09:19.220
קבוצות NSG עובדות לפי כללים.

00:09:19.220 --> 00:09:26.220
כל כלל אומר אפשר או מנה על סמך ארבעה דברים, כתובת IP מקור, כתובת IP יעד, מספר פורט והפרוטוקול.

00:09:26.220 --> 00:09:34.220
אז אתה יכול לומר אפשר תעבורה מכתובת ה-IP של המשרד שלי בפורט 443 או מנע כל תעבורה מהאינטרנט בפורט 22.

00:09:34.220 --> 00:09:35.220
סוג כזה של שליטה.

00:09:35.220 --> 00:09:37.220
כעת, הנה תכונה עוצמתית.

00:09:37.220 --> 00:09:41.220
ניתן להצמיד NSG לרשת משנה או ישירות לממשק הרשת של מכונה וירטואלית בודדת.

00:09:41.220 --> 00:09:43.220
אם אתה מצמיד אותו לרשת משנה,

00:09:43.220 --> 00:09:45.220
ה-NSG הזה חל על כל מה שבתוכה.

00:09:45.220 --> 00:09:47.220
כל מכונה וירטואלית, כל מסד נתונים, כל משיו.

00:09:47.220 --> 00:09:49.220
זו מדיניות גורפת.

00:09:49.220 --> 00:09:51.220
אם אתה מצמיד אותו לממשק רשת של מכונה ספציפית,

00:09:51.220 --> 00:09:53.220
הוא חל רק על אותה מכונה.

00:09:53.220 --> 00:09:55.220
אתה אפילו יכול לעשות את שניהם.

00:09:55.220 --> 00:09:57.220
NSG ברמת רשת משנה לכללים רכבים

00:09:57.220 --> 00:09:59.220
ו-NSG ברמת כרטיס רשת ניק לחריגים.

00:09:59.220 --> 00:10:02.220
כללי ברירת המחדל ש-Azure יוצרת הם די הגיוניים.

00:10:02.220 --> 00:10:04.220
הן מאפשרות את כל התעבורה בתוך אבנט,

00:10:04.220 --> 00:10:06.220
כך שהמשאבים שלך יכולים לתקשר זה עם זה.

00:10:06.220 --> 00:10:08.220
והן חוסמות את כל התעבורה מהאינטרנט,

00:10:08.220 --> 00:10:10.220
כך ששום דבר מבחוץ לא יכול להגיע למשאבים שלך,

00:10:10.220 --> 00:10:11.220
אלא אם כן תאפשר זאת במפורש.

00:10:11.220 --> 00:10:13.220
זו נקודת התחלה טובה.

00:10:13.220 --> 00:10:14.220
תן לי לתת לך דוגמה נפוצה.

00:10:14.220 --> 00:10:16.220
נניח שאתה מנהל מכונה וירטואלית,

00:10:16.220 --> 00:10:18.220
מבוססת לינוקס ואתה צריך להתחבר אליה ב-SSH.

00:10:18.220 --> 00:10:21.220
תיצור כלל NSG שמאפשר תעבורה נכנסת בפורט 22,

00:10:21.220 --> 00:10:23.220
אבל אתה לא רוצה לאפשר SSH מכל מקום.

00:10:23.220 --> 00:10:24.220
זה לבקש צרות.

00:10:24.220 --> 00:10:26.220
לכן, אתה מגביל את זה לכתוב את האיפ שלך,

00:10:26.220 --> 00:10:28.220
כך שרק אתה תוכל להתחבר ב-SSH,

00:10:28.220 --> 00:10:29.220
וכל השאר יחסמו.

00:10:29.220 --> 00:10:33.220
אותו רעיון תקף ל-RDP בפורט 3389 עבור מכונות וווינדוס.

00:10:33.220 --> 00:10:34.220
מה זה אומר מבחינתך?

00:10:34.220 --> 00:10:35.220
קבוצות אבטחה, NSGS,

00:10:35.220 --> 00:10:36.220
הן קו ההגנה הראשון שלך,

00:10:36.220 --> 00:10:38.220
והחלק הטוב ביותר הוא שהן בחינם.

00:10:38.220 --> 00:10:39.220
אין עלות נוספת לשימוש בהן,

00:10:39.220 --> 00:10:41.220
אז אין תירוץ לא להגדיר אותן.

00:10:41.220 --> 00:10:42.220
לכל רשת משנה, סבנט,

00:10:42.220 --> 00:10:44.220
ולכל משאב צריכה להיות מוצמדת NSG.

00:10:44.220 --> 00:10:45.220
התחל עם, חסום הכל,

00:10:45.220 --> 00:10:47.220
ופתח רק את מה שאתה צריך.

00:10:47.220 --> 00:10:49.220
תבלאות ניתוב וניתוב, הכוונת תעבורה.

00:10:49.220 --> 00:10:51.220
עכשיו, בוא נדבר על ניתוב,

00:10:51.220 --> 00:10:53.220
כי ברגע שהחלטת איזו תעבורה מותרת,

00:10:53.220 --> 00:10:55.220
אתה צריך להחליט לאן היא באמת הולכת.

00:10:55.220 --> 00:10:56.220
העניין הוא ש-Azure יוצרת באופן אוטומטי

00:10:56.220 --> 00:10:58.220
מסלולי מערכת עבור כל רשת משנה.

00:10:58.220 --> 00:11:00.220
אתה לא צריך לעשות כלום.

00:11:00.220 --> 00:11:01.220
חשוב על זה כמו על GPS,

00:11:01.220 --> 00:11:03.220
מובנה שמכיר את הכבישים הבסיסיים.

00:11:03.220 --> 00:11:04.220
תעבורה בתוך אבנט,

00:11:04.220 --> 00:11:06.220
תעבורה לבנץ מקושרים,

00:11:06.220 --> 00:11:07.220
תעבורה לאינטרנט.

00:11:07.220 --> 00:11:08.220
הכל פשוט עובד מהרגע הראשון,

00:11:08.220 --> 00:11:10.220
אבל לפעמים ה-GPS המובנה לא לוקח אותך

00:11:10.220 --> 00:11:11.220
לאן שאתה רוצה להגיע.

00:11:11.220 --> 00:11:13.220
זה המקום שבו אתה צריך מסלולים מוגדרים

00:11:13.220 --> 00:11:14.220
על ידי משתמש .

00:11:14.220 --> 00:11:16.220
אלה מאפשרים לך לעקוף את מסלולי המערכת של Azure

00:11:16.220 --> 00:11:18.220
ולקחת שליטה על הנתיב שהתעבורה עוברת בו.

00:11:18.220 --> 00:11:19.220
איך זה עובד?

00:11:19.220 --> 00:11:20.220
אתה יוצר תבלת ניתוב.

00:11:20.220 --> 00:11:22.220
אתה מוסיף את המסלולים המותאמים אישית שלך.

00:11:22.220 --> 00:11:24.220
לאחר מכן, אתה משייך את תבלת הניתוב הזו לרשת משנה.

00:11:24.220 --> 00:11:26.220
מרגע זה, תעבורה שעוזבת את אותה רשת משנה

00:11:26.220 --> 00:11:28.220
פועלת לפי הכללים שלך במקום לפי ברירת המחדל.

00:11:28.220 --> 00:11:29.220
תן לי לתת לך דוגמה קונקרטית.

00:11:29.220 --> 00:11:31.220
נניח שאתה רוצה שכל תעבורת האינטרנט

00:11:31.220 --> 00:11:33.220
מהבנית שלך תעבור קודם דרך חומת אש.

00:11:33.220 --> 00:11:35.220
אולי אתה צריך לבדוק אותה, לתעד אותה

00:11:35.220 --> 00:11:36.220
או לחסום אתרים זדוניים.

00:11:36.220 --> 00:11:37.220
מסלול המערכת המובנה

00:11:37.220 --> 00:11:39.220
שולח תעבורת אינטרנט ישירות החוצה.

00:11:39.220 --> 00:11:40.220
זה לא מה שאתה רוצה,

00:11:40.220 --> 00:11:41.220
אז אתה יוצר מסלול שאומר

00:11:41.220 --> 00:11:44.220
שכל תעבורה שמיועדת ל-0.0.0.0

00:11:44.220 --> 00:11:46.220
שזה עומר לכל מקום באינטרנט

00:11:46.220 --> 00:11:47.220
צריכה לעבור לחומת האש במקום.

00:11:47.220 --> 00:11:49.220
זהו מסלול מוגדר על ידי משתמש.

00:11:49.220 --> 00:11:51.220
טבלאות ניתוב משתמשות במה שהוא שנקרא

00:11:51.220 --> 00:11:52.220
הקפיצה הבאה, Next Hop.

00:11:52.220 --> 00:11:54.220
זהו היעד שאליו התעבורה נשלחת בהמשך.

00:11:54.220 --> 00:11:55.220
יש לך כמה אפשרויות.

00:11:55.220 --> 00:11:57.220
אתה יכול לשלוח אותה להתקן וירטואלי

00:11:57.220 --> 00:11:58.220
כמו חומת אש.

00:11:58.220 --> 00:12:00.220
אתה יכול לשלוח אותה לגטאווי של רשת וירטואלית

00:12:00.220 --> 00:12:02.220
שזו הדרך שבה אתה מתחבר לרשתות מקומיות

00:12:02.220 --> 00:12:03.220
on-premises.

00:12:03.220 --> 00:12:04.220
ניתן לשלוח אותו ישירות לאינטרנט

00:12:04.220 --> 00:12:06.220
או לא לשלוח אותו כלל

00:12:06.220 --> 00:12:07.220
מה שבעצם חוסם את התעבורה.

00:12:07.220 --> 00:12:09.220
הדבר העיקרי שצריך להבין

00:12:09.220 --> 00:12:11.220
הוא שניתוב הוא הדרך שבה אתה שולט בנתיב

00:12:11.220 --> 00:12:13.220
שהתעבורה לוקחת ברשת שלך.

00:12:13.220 --> 00:12:15.220
ניתוב מערכת הוא ברירת מחדל טובה

00:12:15.220 --> 00:12:17.220
אך הוא לא תמיד מתאים למצבך.

00:12:17.220 --> 00:12:19.220
אם אתה צריך שהתעבורה תעבור דרך נקודת ביקורת

00:12:19.220 --> 00:12:21.220
לשאר ספציפי או שתחסם לחלוטין

00:12:21.220 --> 00:12:23.220
עליך להשתמש בניתובים וגדרי משתמש.

00:12:23.220 --> 00:12:24.220
מה זה אומר מבחינתך?

00:12:24.220 --> 00:12:26.220
ניתוב הוא האופן שבו אתה אומר לתעבורה

00:12:26.220 --> 00:12:28.220
לאן ללכת ויש לך את הכוח לעקוף

00:12:28.220 --> 00:12:30.220
את ברירות המחדל של Azure בכל אה.

00:12:30.220 --> 00:12:31.220
התחל עם ניתוב המערכת

00:12:31.220 --> 00:12:32.220
הבין מה הוא עושה

00:12:32.220 --> 00:12:34.220
ולאחר מכן הוסף ניתובים מותאמים אישית

00:12:34.220 --> 00:12:36.220
כשהארכיטקטורה שלך דורשת זאת.

00:12:36.220 --> 00:12:37.220
וינט פירין

00:12:37.220 --> 00:12:38.220
חיבור רשתות

00:12:38.220 --> 00:12:39.220
עד כה דיברנו על וינט בודד

00:12:39.220 --> 00:12:40.220
בניין אחד

00:12:40.220 --> 00:12:41.220
רשת פרטית אחת

00:12:41.220 --> 00:12:43.220
אבל מה קורה כשיש לך מספר רשתות וינט?

00:12:43.220 --> 00:12:45.220
אולי יש לך אחת לסביבת הייצור

00:12:45.220 --> 00:12:46.220
ואחרת לבדיקות

00:12:46.220 --> 00:12:49.220
או שאתה מריץ אפליקציות באזורי Azure שונים

00:12:49.220 --> 00:12:50.220
כברירת מחדל

00:12:50.220 --> 00:12:51.220
רשתות הוונט הללו מבודדות לחלוטין

00:12:51.220 --> 00:12:53.220
הן לא יכולות לתקשר זו עם זו

00:12:53.220 --> 00:12:55.220
הן כמו בניינים נפרדים ללא כבישים ביניהם

00:12:55.220 --> 00:12:57.220
כאן נכנס לתמונה הוונט פירין

00:12:57.220 --> 00:12:59.220
ומאפשר לחבר שתי רשתות וינט באופן פרטי

00:12:59.220 --> 00:13:00.220
ואני מתכוון לפרטי לחלוטין

00:13:00.220 --> 00:13:01.220
תעבורה בין רשתות וינט

00:13:01.220 --> 00:13:03.220
מקושרות נשארת ברשת הליבה של מייקרוסופט

00:13:03.220 --> 00:13:05.220
היא לעולם לא נוגעת באינטרנט הציבורי

00:13:05.220 --> 00:13:06.220
זה אומר שיהוי נמוך

00:13:16.220 --> 00:13:19.220
תעבורה ביניהן תישאר ברשת הפרטית של מייקרוסופט

00:13:19.220 --> 00:13:21.220
ללא שערי VPN

00:13:21.220 --> 00:13:22.220
ללא כתובות IP ציבוריות

00:13:22.220 --> 00:13:23.220
פשוט חיבור פרטי עשיר

00:13:23.220 --> 00:13:25.220
אבל יש חוק שאסור בתכלית האיסור להפר

00:13:25.220 --> 00:13:28.220
לרשתות וינט מקושרות אסור שיהיו מרחבי כתובות חופפים

00:13:28.220 --> 00:13:33.220
אם שתי רשתות וינט מנסות להשתמש בטווח 10.0.0.0 לוחסן 16

00:13:33.220 --> 00:13:34.220
לא ניתן לקשר ביניהן

00:13:34.220 --> 00:13:35.220
כתובות ה-IP התנגשו

00:13:35.220 --> 00:13:38.220
ו-Azure לא תדע לאיזו רשת שייכת חבילת הנתונים

00:13:38.220 --> 00:13:42.220
אז זוכרת טיפ התכנון המוקדם על בחירה זהירה של מרחב הכתובות

00:13:42.220 --> 00:13:43.220
זו הסיבה

00:13:43.220 --> 00:13:46.220
אם אתה חושב שאולי תצטרך לקשר רשתות וינט בהמשך

00:13:46.220 --> 00:13:48.220
הוודא שהטווחים שלהן לא חופפים מההתחלה

00:13:48.220 --> 00:13:50.220
כעת, הנה פרט שמכשיל אנשים

00:13:50.220 --> 00:13:51.220
קישור הוא לא טרנזיטיבי

00:13:51.220 --> 00:13:52.220
מה זה אומר?

00:13:52.220 --> 00:13:55.220
נניח ש-VNETM מקושר ל-VNETB

00:13:55.220 --> 00:13:57.220
ו-VNETB מקושר ל-VNETC רשת A

00:13:57.220 --> 00:13:59.220
לא מגיעה אוטומטית לצ'י דרך B

00:13:59.220 --> 00:14:00.220
הן לא מחוברות

00:14:00.220 --> 00:14:02.220
כל קישור הוא חיבור ישיר בין שתי רשתות VNET בלבד

00:14:02.220 --> 00:14:03.220
VNET בלבד

00:14:03.220 --> 00:14:04.220
אם אתה רוצה שאת תתקשר עם C

00:14:04.220 --> 00:14:06.220
הלך ליצור קישור נפרד בין LSE

00:14:06.220 --> 00:14:07.220
אז איך מטפלים בזה בקנה מידה גדול?

00:14:07.220 --> 00:14:09.220
משתמשים בארכיטקטורת Hub & Spock

00:14:09.220 --> 00:14:10.220
VNET מרכזי אחד

00:14:10.220 --> 00:14:11.220
ה-Hub

00:14:11.220 --> 00:14:12.220
מחובר בפירינג עם VNETS רבים אחרים

00:14:12.220 --> 00:14:13.220
הספויקס

00:14:13.220 --> 00:14:15.220
ה-Hub עשוי להכיל שירותים משותפים כמו חומת אש

00:14:15.220 --> 00:14:17.220
שער VPN או קלי ניטור

00:14:17.220 --> 00:14:19.220
הספויקס מכילים את עומסי העבודה האישיים שלך

00:14:19.220 --> 00:14:21.220
כל ספוק מחובר ישירות ל-Hub

00:14:21.220 --> 00:14:22.220
אך הספויקס אינה מחוברים זה לזה

00:14:22.220 --> 00:14:24.220
אם ספוק צריך להגיע לספוק אחר

00:14:24.220 --> 00:14:26.220
התעבורה עוברת דרך ה-Hub

00:14:26.220 --> 00:14:27.220
זה שומר על סדר

00:14:27.220 --> 00:14:29.220
ומספק לך מקום מרכזי להחלת מדיניות הבטחה

00:14:29.220 --> 00:14:30.220
מה זה אומר מבחינתך?

00:14:30.220 --> 00:14:32.220
פירינג היא הדרך לבנות רשתות המסתראות

00:14:32.220 --> 00:14:34.220
על פני VNETS ואזורים מרובים

00:14:34.220 --> 00:14:36.220
זהו הגשר בין הבניינים שלך

00:14:36.220 --> 00:14:37.220
תכנן את מרחבי הכתובות

00:14:37.220 --> 00:14:38.220
כך שלא תהיה חפיפה ביניהם

00:14:38.220 --> 00:14:40.220
זכור ש-פירינג אינו טרנזיטיבי

00:14:40.220 --> 00:14:41.220
ושקול תכנון Hub & Spock

00:14:41.220 --> 00:14:43.220
כשאתה מתחיל לצמוח מעבר ל-VNET בודד

00:14:43.220 --> 00:14:45.220
איך הכל מתחבר התמונה הגדולה

00:14:45.220 --> 00:14:47.220
אז בואו ניקח צעד אחורה

00:14:47.220 --> 00:14:48.220
ונראה איך החלקים האלה משתלבים יחד

00:14:48.220 --> 00:14:50.220
שם נמצא הכוח האמיתי

00:14:50.220 --> 00:14:51.220
אתה מתחיל עם VNET

00:14:51.220 --> 00:14:53.220
זהו המרחב הפרטי שלך ב-Azure

00:14:53.220 --> 00:14:54.220
תחשוב על זה כעל השטח שלך

00:14:54.220 --> 00:14:55.220
בתוך השטח הזה

00:14:55.220 --> 00:14:56.220
אתה יוצר תת רשתות

00:14:56.220 --> 00:14:57.220
אלה החדרים שלך

00:14:57.220 --> 00:14:58.220
אחד לשרתי אינטרנט

00:14:58.220 --> 00:14:59.220
אחד לבסיסי נתונים

00:14:59.220 --> 00:15:00.220
ואחד לכלי ניהול

00:15:00.220 --> 00:15:02.220
כל סאבנט מקבל בלוק כתובות משלו

00:15:02.220 --> 00:15:03.220
שנגזר ממרחב הכתובות של ה-VNET

00:15:03.220 --> 00:15:04.220
לאחר מכן

00:15:04.220 --> 00:15:06.220
לאחר מכן אתה מוסיף הבטחה

00:15:06.220 --> 00:15:07.220
קבוצות הבטחת רשת

00:15:07.220 --> 00:15:08.220
מצורפות לסאבנט שלך

00:15:08.220 --> 00:15:10.220
הן שולטות איזו תעבורה מורשת להיכנס ולצאת

00:15:10.220 --> 00:15:11.220
הסובנט של האינטרנט שלך

00:15:11.220 --> 00:15:13.220
מאפשר תעבורה מהרשת בפורט 443

00:15:13.220 --> 00:15:15.220
הסובנט של בסיס הנתונים

00:15:15.220 --> 00:15:16.220
מאפשר רק תעבורה מהסובנט

00:15:16.220 --> 00:15:18.220
של האינטרנט בפורט 1433

00:15:18.220 --> 00:15:19.220
המאבטח בכל דלת

00:15:19.220 --> 00:15:20.220
יודע בדיוק מרשאי לעבור

00:15:20.220 --> 00:15:21.220
בשלב הבא

00:15:21.220 --> 00:15:22.220
אתה מגדיר ניתוב

00:15:22.220 --> 00:15:24.220
אולי תרצה שכל תעבורת האינטרנט

00:15:24.220 --> 00:15:26.220
היוצאת תעבור דרך חומת אש לבדיקה

00:15:26.220 --> 00:15:27.220
אתה יוצר תבלת ניתוב

00:15:27.220 --> 00:15:28.220
מוסיף נתיב מותאם אישית

00:15:28.220 --> 00:15:29.220
ומקשר אותו לסאבנט שלך

00:15:29.220 --> 00:15:30.220
כעת

00:15:30.220 --> 00:15:31.220
התעבורה עוקבת אחר הנתיב

00:15:31.220 --> 00:15:33.220
שתכננת במקום ברירת המחדל של Azure

00:15:33.220 --> 00:15:34.220
ולבסוף

00:15:34.220 --> 00:15:35.220
אתה מחבר הכל יחד

00:15:35.220 --> 00:15:37.220
אתה מחבר את ה-VNET שלך עם VNETS אחרים

00:15:37.220 --> 00:15:38.220
אולי VNET מרכזי

00:15:38.220 --> 00:15:40.220
שמחזיק את חומת האש והשירותים המשותפים

00:15:40.220 --> 00:15:41.220
כעת

00:15:41.220 --> 00:15:42.220
האפליקציה שלך מסתרת

00:15:42.220 --> 00:15:43.220
על פני רשתות מרובות

00:15:43.220 --> 00:15:45.220
אך הכל עובד כמערכת אחת מחוברת

00:15:45.220 --> 00:15:46.220
הנה האסימון שנופל

00:15:46.220 --> 00:15:48.220
אף אחד מהחלקים האלה לא עובד בווידוד

00:15:48.220 --> 00:15:50.220
VNET ללא Subnets הוא רק שטח רק

00:15:50.220 --> 00:15:52.220
Subnets ללא NSGS הם פרוצים לחלוטין

00:15:52.220 --> 00:15:55.220
ניתוב ללא תכנון ברור שולח תעבורה למקום הלא נכון

00:15:55.220 --> 00:15:57.220
Hearing ללא תכנון יוצר התנגשויות בכתובות

00:15:57.220 --> 00:15:58.220
הם מהווים מערכת

00:15:58.220 --> 00:15:59.220
כל חלק תלוי באחרים

00:15:59.220 --> 00:16:01.220
תן לי לתת לך דוגמה מוחשית

00:16:01.220 --> 00:16:03.220
תאר לעצמך אפליקציית אינטרנט

00:16:03.220 --> 00:16:05.220
שרתי האינטרנט שלך נמצאים בסובנט ציבורי עם NSG

00:16:05.220 --> 00:16:08.220
שמאפשר תעבורת HTTPS מהאינטרנט

00:16:08.220 --> 00:16:10.220
שרתי האפליקציה שלך נמצאים בסובנט פרטי

00:16:10.220 --> 00:16:12.220
שמקבל רק תעבורה מהסובנט של האינטרנט

00:16:12.220 --> 00:16:15.220
מסד הנתונים שלך נמצא בתת רשת פרטית אחרת

00:16:15.220 --> 00:16:17.220
שמקבלת תעבורה רק מטת רשת האפליקציה

00:16:17.220 --> 00:16:20.220
טבלת ניתוב מכריחה את כל התעבורה היוצאת לעבור דרך חומת אש

00:16:20.220 --> 00:16:22.220
בבנט המרכזי לצורכי רישום מובדיקה

00:16:22.220 --> 00:16:24.220
והכל מחובר לרשת הארגונית שלך

00:16:24.220 --> 00:16:26.220
כך שהצוות הפנימי שלך יכול לנהל את זה

00:16:26.220 --> 00:16:28.220
זה הערך האמיתי לא אף תכונה בודדת

00:16:28.220 --> 00:16:30.220
זה האופן שבו כולם עובדים יחד

00:16:30.220 --> 00:16:33.220
לפני 20 שנה היית קונה שרתים נפרדים

00:16:33.220 --> 00:16:36.220
מגדיר נתבים פיזיים ומנהל חומות אש לכל מכשיר

00:16:36.220 --> 00:16:38.220
הכל היה ידני איתי ויקר

00:16:38.220 --> 00:16:40.220
Azure נותנת לך את כל זה קשירות

00:16:40.220 --> 00:16:43.220
אתה מגדיר את זה בכמה לחיצות או בסקריפט וזה פשוט עובד

00:16:43.220 --> 00:16:45.220
מה זה אומר מבחינתך

00:16:45.220 --> 00:16:47.220
ברגע שתבין איך החלקים האלה משתלבים

00:16:47.220 --> 00:16:49.220
הרשות באז'ר הופך לצפוי

00:16:49.220 --> 00:16:50.220
אתה לא מנחש

00:16:50.220 --> 00:16:51.220
אתה מתכנן

00:16:51.220 --> 00:16:52.220
וכשמה שהוא משתבש

00:16:52.220 --> 00:16:55.220
אתה יודע בדיוק איפה לחפש כי אתה מבין את המערכת

00:16:55.220 --> 00:16:57.220
אז הנה מה שאני רוצה שתיקח מהפרק הזה

00:16:57.220 --> 00:16:58.220
ראשית

00:16:58.220 --> 00:17:00.220
הצעד החשוב ביותר שאתה יכול לנקוט

00:17:00.220 --> 00:17:03.220
צור וי נת עם מרחב כתובות מתוכנן היטב לפני שאתה פורס משהו

00:17:03.220 --> 00:17:05.220
ההחלטה הבודדת הזו משפיעה על הכל בהמשך

00:17:05.220 --> 00:17:06.220
שנית

00:17:06.220 --> 00:17:08.220
השתמש בתת רשתות כדי להפריד בין שכבות האפליקציה שלך

00:17:08.220 --> 00:17:09.220
שרתי אינטרנט

00:17:09.220 --> 00:17:10.220
שרתי אפליקציה

00:17:10.220 --> 00:17:11.220
מסדי נתונים

00:17:11.220 --> 00:17:12.220
תן לכל אחד את המרחב שלו

00:17:12.220 --> 00:17:13.220
ושלישית

00:17:13.220 --> 00:17:14.220
התחל עם NSGS

00:17:14.220 --> 00:17:15.220
הם בחינם

00:17:15.220 --> 00:17:18.220
הם עוצמתיים והם משפרים משמעותית את האבטחה שלך מהיום הראשון

00:17:18.220 --> 00:17:21.220
הבנת שלך הוא הבסיס לכל מה שאתה בונה באז'ר

00:17:21.220 --> 00:17:23.220
עשה זאת נכון והכל יהיה קל יותר

00:17:23.220 --> 00:17:26.220
עשה זאת לא נכון ותבלה את כל זמניך במאבק ברשת שלך

00:17:26.220 --> 00:17:28.220
הרשם בפלטפורמת הפודקסטים המועדפת עליך

00:17:28.220 --> 00:17:30.220
ושתף את זה עם מי שמתחיל את מסע האז'ר שלו

00:17:30.220 --> 00:17:32.220
השאר תגובה עם מה שהוא התחבר לך

00:17:32.220 --> 00:17:34.220
אני אראה אותך בפרק הבא

00:17:34.220 --> 00:17:35.220
תודה רבה

00:17:35.220 --> 00:17:36.220
תודה רבה