מדוע אנטי וירוסים מסורתיים אינם מתאימים לעננים ציבוריים. אז מה עלי לעשות?

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

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

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

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

בנוסף, רוב פתרונות האנטי וירוס בשוק אינם מותאמים לפתרון בעיות ההגנה על משאבי IT בסביבת ענן ציבורי. ככלל, מדובר בפתרונות EPP כבדי משקל (Endpoint Protection Platforms), אשר יתר על כן, אינם מספקים את ההתאמה האישית הנדרשת בצד הלקוח של ספק הענן.

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

מה שאנטי וירוס בענן ציבורי אמור להיות מסוגל לעשות

אז, בואו נשים לב לפרטים הספציפיים של עבודה בסביבה וירטואלית:

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

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

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

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

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

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

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

איך אפשר להתיידד בין אנטי וירוס לענן?

כפי שהוכיח הניסיון שלנו, בחירת פתרון המבוסס על תיאור ותיעוד היא דבר אחד, אבל ליישם אותו הלכה למעשה בסביבת ענן שכבר עובדת היא משימה שונה לחלוטין מבחינת המורכבות. נספר לכם מה עשינו בפועל ואיך התאמנו את האנטי וירוס לעבוד בענן הציבורי של הספק. הספקית של פתרון האנטי וירוס הייתה קספרסקי, שהפורטפוליו שלה כולל פתרונות הגנה נגד וירוסים לסביבות ענן. הסתפקנו ב-"Kaspersky Security for Virtualization" (Light Agent).

הוא כולל קונסולת Kaspersky Security Center אחת. סוכן קל ומכונות וירטואליות אבטחה (SVM, Security Virtual Machine) ושרת אינטגרציה של KSC.

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

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

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

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

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

ארכיטקטורה של פתרון אבטחת מידע במסגרת גישה חדשה

תוכנית הפעולה הכללית של פתרון אנטי וירוס בסביבת ענן ציבורי היא כדלקמן:

תכנית הפעולה של פתרון אנטי וירוס בסביבת ענן ציבורי #CloudMTS

הבה נתאר את תכונות הפעולה של אלמנטים בודדים של הפתרון בענן:

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

יש לציין כי למרות שאנו ספקי שירות, אנו לא מתערבים בהגדרות שנקבעו על ידי הלקוחות. הדבר היחיד שאנחנו יכולים לעשות הוא לאפס את מדיניות האבטחה לסטנדרטים אם יש צורך בהגדרה מחדש. לדוגמה, זה עשוי להיות נחוץ אם הלקוח בטעות הידק אותם או החליש אותם באופן משמעותי. חברה יכולה תמיד לקבל מרכז בקרה עם מדיניות ברירת מחדל, שאותה היא יכולה להגדיר באופן עצמאי. החיסרון של Kaspersky Security Center הוא שהפלטפורמה זמינה כרגע רק למערכת ההפעלה של מיקרוסופט. למרות שסוכנים קלים יכולים לעבוד עם מחשבי Windows ו-Linux כאחד. עם זאת, מעבדת קספרסקי מבטיחה שבעתיד הקרוב KSC תעבוד תחת מערכת ההפעלה לינוקס. אחת הפונקציות החשובות של KSC היא היכולת לנהל הסגר. לכל חברת לקוח בענן שלנו יש חברה אישית. גישה זו מבטלת מצבים שבהם מסמך נגוע בווירוס הופך בטעות לגלוי לציבור, כפי שעלול לקרות במקרה של אנטי וירוס ארגוני קלאסי עם הסגר כללי.

• סוכני אור. כחלק מהמודל החדש, מותקן סוכן Kaspersky Security קל משקל בכל מכונה וירטואלית. זה מבטל את הצורך לאחסן את מסד הנתונים של האנטי-וירוס בכל VM, מה שמפחית את כמות שטח הדיסק הנדרשת. השירות משולב בתשתית הענן ועובד באמצעות SVM, מה שמגביר את צפיפות המכונות הווירטואליות במארח ESXi ואת הביצועים של מערכת הענן כולה. סוכן האור בונה תור של משימות לכל מכונה וירטואלית: בדוק את מערכת הקבצים, הזיכרון וכו'. אבל ה-SVM אחראי לביצוע הפעולות הללו, עליהן נדבר בהמשך. הסוכן גם מתפקד כחומה, שולט במדיניות האבטחה, שולח קבצים נגועים להסגר ומפקח על ה"בריאות" הכללית של מערכת ההפעלה עליה הוא מותקן. את כל זה ניתן לנהל באמצעות הקונסולה היחידה שהוזכרה כבר.

• מכונה וירטואלית אבטחה. כל המשימות עתירות המשאבים (עדכוני מסד נתונים של אנטי וירוס, סריקות מתוזמנות) מטופלות על ידי מכונת אבטחה וירטואלית נפרדת (SVM). היא אחראית על תפעול מנוע אנטי וירוס מלא ומסדי נתונים עבורו. תשתית ה-IT של חברה עשויה לכלול מספר SVMs. גישה זו מגבירה את אמינות המערכת - אם מכונה אחת נכשלת ואינה מגיבה במשך שלושים שניות, סוכנים מתחילים אוטומטית לחפש אחר.

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

אלגוריתם לעבודה בענן: הפחתת העומס על התשתית

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

הטמעת פתרון אנטי וירוס בענן הספק

התמונה מציגה תרשים כללי של יישום הפתרון בענן. מרכז האבטחה הראשי של קספרסקי פרוס באזור הבקרה של הענן, ו-SVM בודד נפרס על כל מארח ESXi באמצעות שרת האינטגרציה של KSC (לכל מארח ESXi יש SVM משלו מחובר עם הגדרות מיוחדות בשרת VMware vCenter). לקוחות עובדים בקטעי ענן משלהם, שם ממוקמים מכונות וירטואליות עם סוכנים. הם מנוהלים באמצעות שרתי KSC בודדים הכפופים ל-KSC הראשי. אם יש צורך להגן על מספר קטן של מכונות וירטואליות (עד 5), ניתן לספק ללקוח גישה לקונסולה הוירטואלית של שרת KSC ייעודי מיוחד. אינטראקציה ברשת בין KSCs של לקוח ל-KSC הראשי, כמו גם סוכני אור ו-SVMs, מתבצעת באמצעות NAT דרך נתבים וירטואליים של לקוח EdgeGW.

על פי ההערכות שלנו ותוצאות בדיקות של עמיתים בספק, Light Agent מפחית את העומס על התשתית הווירטואלית של הלקוחות בכ-25% (בהשוואה למערכת המשתמשת בתוכנת אנטי וירוס מסורתית). במיוחד, האנטי-וירוס הסטנדרטי של Kaspersky Endpoint Security (KES) לסביבות פיזיות צורך כמעט פי שניים יותר זמן CPU של השרת (2,95%) מאשר פתרון וירטואליזציה קל משקל מבוסס סוכנים (1,67%).

טבלת השוואת עומסי מעבד

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

גרף השוואת קצב גישה לדיסק

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

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

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

במאמר הבא בנושאי ענן נדבר על האבולוציה של WAFs בענן ומה עדיף לבחור: חומרה, תוכנה או ענן.

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

מקור: www.habr.com