הגדרת AWS VPC ובידוד רשתי מקצה לקצה

מדוע הגדרת AWS VPC נשברת עם גידול העומס

כל עוד בענן יש עמדה אחת ועשרה שרתים, הרשת נבנית בדיעבד: תת-רשת אחת, שער משותף אחד, מינימום כללי גישה. הכשל מתחיל מאוחר יותר — כאשר מופיע מתחם ייעודי לנתונים רגישים, אזור שני או עמדה לבדיקות עומס. אז הגדרת aws vpc הופכת מפורמליות לצוואר בקבוק שמעכב גם שחרורים וגם חקירת תקלות.

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

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

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

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

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

האפקט המדיד של בידוד רשתי מנוהל

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

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

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

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

• סוג התקלות שנמנעו. נעלמת משפחה שלמה של שגיאות מאותו סוג: סגמנט עם בסיס נתונים שנפתח בטעות החוצה; גישה מסביבת הבדיקה לסביבת העבודה; שירות עם יציאה ישירה לאינטרנט בעקיפין לנקודת היציאה.

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

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

אפשרויות בידוד: VPC אחת, חשבונות נפרדים, היברידי

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

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

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

שלבי תכנון והטמעת הבידוד

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

1. ספירת מלאי של התעבורה. אוספים יומני זרימה של שניים עד ארבעה שבועות, מסמנים מקורות, כיוונים ופורטים, מאתרים מנהרות נשכחות ופניות ישירות מהאינטרנט אל שירותים פנימיים.
2. תכנון תת-רשתות. מתחם ציבורי — רק מאזני עומסים והיקף, אפליקציות ונתונים — בתת-רשתות פרטיות, שירותי ניהול — בנפרד. טווחי הכתובות נלקחים עם מרווח לצמיחה.
3. מטריצת כללי גישה. מכנסים את הקשרים לטבלת «מקור — יעד — פורט» ומעבירים אותה לקבוצות אבטחה ולרשימות רשת. הרשאות מיותרות נסגרות מיד, ולא «לאחר כך».
4. פיילוט על עמדה. מרימים עותק של הטופולוגיה, מריצים תרחישים אופייניים, בודקים שכשל של תת-רשת אחת לא גורר אחריו את השכנות. כאן גם מודדים השהיות לפני ואחרי.
5. הגירה ללא השבתה. מעבירים שירותים בגלים: התעבורה עוברת זמנית בשני מתחמים, המיתוג — לפי מדדים, והחזרה לאחור — בדקות בכל שלב.
6. בדיקת כללי גישה. סורקים את ההיקף ומשווים את הקשרים בפועל למטריצה: כל מה שנפתח בפועל ולא לפי התכנון — מנקים לפני המסירה.
7. מסירה לתפעול. מוסרים את סכמת המיעון, מטריצת הגישה, תקנון השינויים ואת הנוהל לחיבור שירות חדש — כדי שהצוות ימשיך לתקן את הסכמה בעצמו.

ארטיפקטים שנמסרים לאחר ההטמעה

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

• תיעוד סכמת הרשת — דיאגרמות לפי אזורים ותת-רשתות, תוכנית מיעון, נקודות יציאה לאינטרנט ולשירותים פנימיים, טבלאות ניתוב עם הסבר לשם מה נדרש כל מסלול.
• מפת תלויות השירותים — איזה שירות חי באיזו תת-רשת, עם מי הוא מתקשר ובאיזה כיוון; לפיה רואים מה יקרה למערכת עם ניתוק של כלל מסוים.
• מדיניות גישה — תפקידים והרשאות, הפרדה לפי סביבות, מי הבעלים של המשאב ומי רשאי לשנות כללי רשת. עקרון ההרשאות המינימליות מקובע באופן מפורש, ולא «התגבש היסטורית».
• מטריצת זרימות — מקור, יעד, פורט, ייעוד הקשר. משמשת גם כתקנון לשירותים חדשים וגם כרשימת בדיקה בחקירת תקלה.
• תקנון שינויים — כיצד עריכת כלל רשת עוברת בדיקה בסביבה נפרדת, אישור, חלון יישום והחזרה לאחור. שינויים מפסיקים להיות הסכמה בעל פה בין שני מהנדסים.
• הוראות למשמרת התורנית — תרחישים אופייניים: אבד הקשר בין שירותים, כשל ערוץ חיצוני, שגיאה במסלול. עם פעולות שלב-אחר-שלב, פקודות אבחון ונקודות הסלמה.
• נוהל שמות ותגיות — עיקרון אחיד שלפיו מאתרים משאב בדקה, והבעלים והייעוד נקבעים בלי להתקשר למחבר ההגדרה.
• נקודות אינטגרציה עם הניטור — אילו אירועי רשת ולאן נשלחים כהתראות, ואילו ספים נחשבים לתקניים.

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

מקרה בוחן: סגמנטציה של מתחם המוצר וההרשאות

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

כיצד הפרידו בין הסביבות וההרשאות

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

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

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

מדדים לפני ואחרי

מה לעשות אם המתחם כבר פרוס ועובד?

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

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

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

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

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

שאלות טכניות בנושא בידוד רשתי

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

האם הבידוד יתאים לשירותים שלנו?

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

מה עם התחזוקה כשהרשת נמסרה?

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

היכן גבול האחריות?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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

מה להכין מצדכם:

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

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