תובנה בענף: כיצד תתפתח אבטחת הענן בשנת 2017?

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

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

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

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

PCMag: כיצד בדיוק רואה Rackspace את תפקידה לעומת זה של עובדי ה- IT של לקוחותיה בכל הקשור לבטיחות ואבטחת מידע?

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

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

PCMag: האם יש לך עצות למומחי IT ולקוחות עסקיים לגבי מה הם יכולים לעשות בנוסף למה שמספק מספק כדי להגן על הנתונים מבוססי הענן שלהם בעצמם?

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

PCMag: שאלה מרכזית אחת שראינו שקוראים שואלים היא בנושא הגנה אפקטיבית מפני מתקפות מניעת שירות המופצות באמצעות Internet of Things (IoT), בדומה לאירוע שעבר באוקטובר האחרון, שם ספק IoT סיני תרם בשגגה רבות למקרה ההתקפה. האם מתקפות כאלה עובדות עם ספקי שירותי אינטרנט במעלה הזרם? ואיך הם מונעים מהתקפה של לקוח אחד להוריד את כולם במתקן?

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

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

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

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

לחץ על תמונה לקבלת אינפוגרפיקה מלאה. קרדיט תמונה: טוויסטלוק

PCMag: שאלה נוספת שקוראים שואלים אותנו היא בנושא אבטחת מכולות. האם אתה דואג למכולות נשק שעשויות להכיל מערכות התקפה מורכבות או שאתה חושב שהארכיטקטורה מגנה מפני מעלולים כאלה?

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

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

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

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

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

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

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

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

BK: MSSPs צריכים לקבל שהביטחון לא עבד ולהתאים את האסטרטגיה והפעולות שלהם כך שיהיו יעילים יותר בנוף האיום של ימינו - המכיל יריבים מתוחכמים ומתמידים יותר. ב- Rackspace, הכרנו בשינוי איום זה ופיתחנו יכולות חדשות הדרושות כדי להקל עליהם. Rackspace Managed Security היא פעולת איתור ותגובה מתקדמת 24/7/365. הוא תוכנן לא רק כדי להגן על חברות מפני התקפות, אלא כדי למזער את ההשפעה העסקית כאשר מתרחשות התקפות, גם לאחר שסביבה נפרצת בהצלחה.

כדי להשיג זאת, התאמנו את האסטרטגיה שלנו בשלושה דרכים:

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

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

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

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

PCMag: Rackspace הוא תומך גדול, אכן מייסד בעל זיכוי, של OpenStack. חלק מקוראי ה- IT שלנו שאלו האם פיתוח אבטחה לפלטפורמה פתוחה כל כך אטית ופחות יעילה מזו של מערכת סגורה כמו Amazon Web Services (AWS) או Microsoft Azure בגלל הדילמה ה"יותר מדי מבשלות "הנתפסות שמכות הרבה פרויקטים גדולים עם קוד פתוח. איך אתה מגיב לזה?

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

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

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

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

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

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

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

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