מול מפתחים: מודרניזציה של הענן הפרטי

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

משימה מס' 1. ענן עם חיבור לאינטרנט

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

הזרם המרכזי של פרויקט זה היה יצירת מכונות וירטואליות בקטע נוסף של אבטחת מידע - באזור המפורז (DMZ). כאן משולבים שירותי הבנק במערכות חיצוניות הממוקמות מחוץ לתשתית הבנקאית.

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

הגנת מיקרו-פילוח

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

זה משפר את האבטחה של המערכת כולה. גם אם תוקפים פורצים שרת DMZ אחד, יהיה להם קשה מאוד להפיץ את ההתקפה ברחבי הרשת - הם יצטרכו לפרוץ דרך "דלתות נעולות" רבות בתוך הרשת. חומת האש האישית של כל VM מכילה כללים משלה לגביו, הקובעים את הזכות להיכנס ולצאת. סיפקנו מיקרו-פילוח באמצעות VMware NSX-T Distributed Firewall. מוצר זה יוצר באופן מרכזי כללי חומת אש עבור מחשבי VM ומפיץ אותם על פני תשתית הוירטואליזציה. זה לא משנה באיזו מערכת הפעלה אורחת משתמשים, הכלל מיושם ברמת חיבור מכונות וירטואליות לרשת.

בעיה N2. בחיפוש אחר מהירות ונוחות

לפרוס מכונה וירטואלית? בְּקַלוּת! כמה קליקים וסיימת. אבל אז עולות שאלות רבות: כיצד לקבל גישה מ-VM זה לאחר או למערכת? או ממערכת אחרת חזרה ל-VM?

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

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

אתה לא יכול לעשות את זה עם כללים בענן. זה לא נוח ולא בטוח.

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

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

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

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

ציון סופי של הטבות

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

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

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

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

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

מחברים:
ויאצ'סלב מדבדב, ראש מחלקת מחשוב ענן, Jet Infosystems,
איליה קויקין, מהנדס מוביל של מחלקת מחשוב הענן של Jet Infosystems

מקור: www.habr.com