העברת חוות שרתים לענן – זווית אבטחת הרשת

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

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

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

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

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

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

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

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

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

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

הכותב הינו היזם והמדען הראשי של אלגוסק

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

אירועים קרובים