שרת וירטואלי יכול לארח מערכת הנהלת חשבונות, תיקי לקוחות, מערכת רפואית, אתר מכירות או סביבת עבודה שלמה. לכן השאלה איך להגן על שרתים וירטואליים אינה טכנית בלבד. היא נוגעת ישירות להמשכיות העסקית, לזמינות העובדים וליכולת להמשיך לתת שירות גם כאשר מתרחשת תקלה או מתקפת סייבר.
היתרון של וירטואליזציה הוא גמישות: ניתן להקים שרתים במהירות, להרחיב משאבים ולגשת למערכות מרחוק. אבל אותה גמישות יוצרת גם סיכון. טעות בהרשאות, ממשק ניהול חשוף לאינטרנט או גיבוי שנגיש מאותו חשבון שנפרץ עלולים להשפיע על מספר מערכות בבת אחת. ההגנה הנכונה מתחילה בהבנה שהשרת עצמו הוא רק שכבה אחת במערך רחב יותר.
הגנה על שרתים וירטואליים מתחילה במיפוי
לפני שמתקינים כלי אבטחה, צריך לדעת מה קיים. בארגונים רבים מוקמים שרתים לפרויקט זמני, לבדיקת מערכת או לשימוש של ספק, ונשארים פעילים גם לאחר שהצורך הסתיים. שרת כזה עלול להיות לא מעודכן, ללא ניטור וללא בעלים עסקי ברור.
מיפוי תקין כולל את כל המכונות הווירטואליות, מערכת ההפעלה בכל שרת, היישומים שפועלים עליו, כתובות הרשת, חשבונות הניהול, החיבורים לשירותי ענן והמידע המאוחסן בו. לכל שרת כדאי להגדיר בעלים – אדם או מחלקה שיודעים להסביר מדוע הוא נחוץ ומה יקרה אם יפסיק לפעול.
במקביל, יש לסווג את רמת הקריטיות. שרת שמפעיל מערכת ליבה של העסק דורש רמת זמינות, גיבוי ובקרה שונה משרת בדיקות. הסיווג מאפשר להשקיע נכון: לא כל מערכת זקוקה לאותה תצורה, אך אף מערכת לא צריכה להישאר ללא הגנה בסיסית.
הפרידו בין הגישה לניהול לבין העבודה היומיומית
אחת מנקודות התורפה הנפוצות היא שימוש בחשבון מנהל לכל פעולה. כאשר חשבון בעל הרשאות גבוהות נפרץ, לתוקף עשויה להיות גישה לשרתים, לגיבויים ולמערכת הווירטואליזציה עצמה. מכאן הדרך להצפנת מידע או למחיקת מכונות קצרה מאוד.
יש להעניק הרשאות לפי עקרון המינימום הנדרש. עובד שזקוק לגישה ליישום מסוים אינו צריך להיות מנהל מקומי של השרת. גם אנשי IT צריכים לעבוד בחשבונות משתמש רגילים, ולעבור לחשבון ניהולי רק כשנדרשת פעולה כזו. כך מצמצמים את הנזק האפשרי מפישינג, סיסמה שנחשפה או פעולה שגויה.
אימות רב-שלבי צריך להיות חובה בגישה לממשקי הניהול, ל-VPN, לפלטפורמת הענן ולחשבונות ניהול מרכזיים. עדיף להשתמש בחשבונות אישיים ולא בחשבון משותף של צוות. כשכל פעולה משויכת לאדם מסוים, קל יותר לעקוב אחר שינויים, לחקור אירועים ולבטל גישה בעת סיום העסקה.
ממשק הניהול אינו שרת רגיל
מערכת הניהול של סביבת הווירטואליזציה היא נכס רגיש במיוחד. באמצעותה אפשר להדליק, לכבות, לשכפל, למחוק ולשנות הגדרות של מכונות רבות. יש להגביל את הגישה אליה לרשת ניהול ייעודית או דרך VPN מאובטח, ולא לאפשר גישה פתוחה מהאינטרנט.
כדאי גם להפריד בין רשת הניהול, רשת השרתים ורשת עמדות המשתמשים. הפרדה זו אינה מבטלת סיכון, אך היא מקשה על תוקף שעבר מעמדת עובד נגועה להגיע ישירות לשרתים הקריטיים או לממשקי הניהול שלהם.
עדכונים אינם משימה חד-פעמית
שרתי Windows, Linux, מערכות ניהול וירטואליזציה, מסדי נתונים ותוכנות גיבוי מתגלים מדי שנה כפגיעים לחולשות חדשות. תוקפים מנצלים לעיתים קרובות חולשות מוכרות, במיוחד בארגונים שדחו עדכונים מחשש לפגיעה בפעילות.
החשש מובן. עדכון לא מבוקר עלול ליצור בעיית תאימות או לעצור שירות. לכן הפתרון אינו לדחות עדכונים ללא הגבלת זמן, אלא לנהל תהליך מסודר: לבדוק עדכונים משמעותיים בסביבת בדיקה כאשר אפשר, לקבוע חלונות תחזוקה, לבצע גיבוי לפני שינוי ולתעד את התהליך. עבור חולשות קריטיות שנמצאות בניצול פעיל, יש לקצר את זמני התגובה ולהפעיל אמצעי צמצום סיכון גם אם העדכון המלא עדיין בבדיקה.
חשוב לכלול בתהליך גם רכיבים שנוטים להישכח: קושחה, כלי גישה מרחוק, תוספים, סוכני ניטור, מערכות אחסון ופתרונות אבטחה. שרת מעודכן אינו מוגן אם שכבת הניהול או התוכנה שמחוברת אליו נותרה חשופה.
גיבוי טוב חייב לשרוד גם פריצה
גיבוי הוא קו ההגנה שמאפשר לחזור לפעילות לאחר הצפנה, מחיקה, כשל חומרה או טעות אנוש. אולם גיבוי שמחובר קבוע לאותה רשת ונגיש באותן הרשאות של השרתים עלול להיות יעד ראשון במתקפת כופרה. אם התוקף יכול למחוק את הגיבויים, קיומם לא יסייע בשעת משבר.
מדיניות נכונה משלבת כמה שכבות: עותקים במספר נקודות זמן, אחסון באתר נפרד או בענן, והעתק מבודד שלא ניתן לשנות או למחוק בקלות. בהתאם למערכת ולרגולציה, ניתן לשלב מנגנוני אי-שינוי לתקופה מוגדרת, כך שגם חשבון שנפרץ לא יוכל למחוק מיד את העותקים הקיימים.
לא פחות חשוב הוא לבצע בדיקות שחזור. גיבוי שנראה תקין בדוח אינו בהכרח גיבוי שניתן להפעיל ממנו שרת, מסד נתונים או קובץ בודד. יש לבדוק מדי תקופה שחזור של מערכות קריטיות לסביבה נפרדת, למדוד כמה זמן נדרש לחזרה לפעילות ולוודא שהמידע המשוחזר עדכני מספיק לצורכי העסק.
הגדירו יעדי התאוששות עסקיים
שני נתונים עוזרים לקבל החלטות נכונות. יעד זמן התאוששות מגדיר כמה זמן העסק יכול להסתדר ללא מערכת מסוימת. יעד נקודת התאוששות מגדיר כמה מידע מותר לאבד במקרה קיצון. מרפאה עשויה להידרש לחזרה מהירה במיוחד למערכת תורים, בעוד שמערכת ארכיון יכולה להתאושש בקצב אחר.
החלטות אלו אינן רק של מחלקת ה-IT. הנהלה, תפעול ובעלי התהליכים העסקיים צריכים לקבוע מה באמת קריטי. כך ניתן לתכנן את תדירות הגיבוי, סוג התשתית ותקציב ההתאוששות על בסיס צורך עסקי ולא על בסיס ניחוש.
ניטור, הגנה בתחנה ותיעוד אירועים
מערכת הגנה על שרתים אינה יכולה להסתמך רק על חומת אש. יש להתקין הגנת נקודות קצה מתקדמת על השרתים, כולל יכולת לזהות התנהגות חריגה כמו הצפנה מהירה של קבצים, הרצת כלי תקיפה או תהליכים לא מוכרים. בחלק מהסביבות נדרשות החרגות עבור יישומים רגישים, ולכן יש להגדיר אותן בזהירות ולבחון את השפעתן.
ניטור רציף צריך להתריע על אירועים שיש להם משמעות תפעולית ואבטחתית: ניסיונות התחברות כושלים רבים, כניסה ממיקום חריג, שינוי בהרשאות, כיבוי של שירות הגנה, גידול חריג בצריכת משאבים או כשל בגיבוי. התראה שלא נבדקת בזמן הופכת במהירות לרעש. לכן כדאי לקבוע מי מקבל כל התרעה, מתי מסלימים אותה ומהו זמן התגובה המצופה.
גם לוגים הם נכס. שמירת תיעוד של התחברויות, שינויים והודעות אבטחה מסייעת לזהות דפוס חריג ולחקור אירוע לאחר מכן. בארגון ללא צוות פנימי ייעודי, שירות מנוהל יכול להבטיח שהבקרה אינה נעצרת בשעות הערב, בסופי שבוע או בזמן עומס.
תוכנית תגובה מצמצמת נזק בזמן אמת
בעת אירוע סייבר, הבלבול עולה כסף. עובד שמזהה הודעת כופרה או שרת שאינו מגיב צריך לדעת למי לפנות, מי מוסמך לנתק מערכת מהרשת ומי אחראי לעדכן את ההנהלה והלקוחות במקרה הצורך.
תוכנית תגובה מעשית כוללת זיהוי, בידוד, בדיקה, שחזור וחזרה מבוקרת לעבודה. אין למהר לשחזר שרת לפני שמבינים כיצד התרחשה החדירה. אחרת אפשר להחזיר את אותה חולשה לסביבה החדשה. במקרים מסוימים עדיף לבודד שרת, לשמר ראיות ולבנות אותו מחדש מתבנית נקייה, גם אם הדבר דורש יותר זמן.
יש לתרגל את התוכנית לפחות סביב המערכות הקריטיות. תרגול אינו חייב להיות אירוע מורכב: אפשר לבחור תרחיש של כשל שרת או חשד להצפנה, לבדוק את זמינות אנשי הקשר, לשחזר שירות ולתעד פערים. כל תרגול כזה הופך החלטות תאורטיות ליכולת פעולה אמיתית.
האחריות בענן מתחלקת בין הספק לעסק
כאשר השרתים נמצאים בענן, קל להניח שהספק מטפל בכל היבטי ההגנה. בפועל, הספק אחראי בדרך כלל על תשתית הענן הפיזית, בעוד שהעסק נשאר אחראי להגדרות השרת, לניהול המשתמשים, לנתונים, לעדכוני מערכת ההפעלה ולגיבויים, בהתאם לשירות שנרכש.
לכן יש לבדוק מי מנהל את ההרשאות, מי עוקב אחר גיבויים, היכן נשמרים הנתונים, כיצד מוגנת הגישה מרחוק ומה קורה אם צריך לשחזר מערכת במהירות. סביבת ענן מאובטחת היטב יכולה לשפר זמינות וגמישות, אך רק כאשר ההגדרות והניהול השוטף מקבלים את אותה תשומת לב כמו שרת מקומי.
עבור עסקים שרוצים גורם אחד שאחראי על התשתית, האבטחה והתגובה לתקלות, Tuzali יכולה ללוות את ניהול השרתים, הגיבוי וההגנה באופן מתמשך. הערך אינו רק בהתקנת מוצר, אלא בבדיקה שוטפת שהמערכות פועלות, מוגנות וניתנות לשחזור.
ההגנה הטובה ביותר אינה פעולה בודדת שנעשית פעם בשנה. היא שגרה של אחריות, בקרה ושיפור: לדעת אילו שרתים קיימים, לצמצם גישה, לעדכן, לגבות, לנטר ולתרגל התאוששות. כששגרה זו מנוהלת היטב, גם אירוע בלתי צפוי הופך ממשבר מאיים לאירוע שניתן לשלוט בו.