ענן אחד – שתי תפיסות הגנה
ארגונים רבים מתלבטים בין שתי התפיסות הנהוגות כיום להגנה על מערכות מבוססות ענן – שרתי Proxy או גישת API. אז מה עדיף לארגון שלכם?
אורי קרן
| 01/12/2015
מקור: יחצ
הגידול הרב במערכות ארגוניות מבוססות ענן הוביל גם לגידול רב בהיקף איומי הסייבר על מערכות אלו. במקביל ליישומים הטכנולוגיים התפתחו בשנים האחרונות מודלים שונים להגנה על מערכות אלה שניתן לחלק אותם לשתי קטגוריות עיקריות.
הראשונה, אבטחה מבוססת שרתי proxy והקטגוריה השנייה של מערכות הגנה מבוססות API. אין המדובר רק בהבדלים טכנולוגיים אלא בתפיסת עולם הנוגעת למהות אבטחת המידע בתוך הארגון והשאלה היא מהו המודל המתאים לארגון.
הפרוקסי 'לא סוחב'
תפיסת האבטחה שמבוססת על ה – Proxy מנסה עדיין להשתמש בעקרונות אבטחה שמתאימים לעשור הקודם ולתפיסתנו אינה יכולה לעמוד במבחן הזמן בעידן הטכנולוגי שלנו. ביסודה של תפיסה זו עומד העיקרון שמסמן את גבולות האיום לפיו ״כל מה שנמצא בתוך גבולות הרשת הארגונית צריך להיות מוגן ומה שמעבר לו לא״. כך, גישה זו מנטרת את הפעילות שעובדים מהארגון מבצעים מול הענן ובמידת הצורך יחסמו אותה או יתריעו עליה. לא ניתן לפתור את הבעיה כך בשל העובדה שהמידע הארגוני העכשווי מבוזר. אך גם בשל מספר בעיות בסיסות נוספות:
גבולות ה-perimeter מטושטשים. מציאות ה-BYOD והניידות של המשתמשים מקשה עליהם להתחבר ב-VPN בכל רגע נתון ולכן משתמשים ארגוניים לא תמיד נמצאים בתוך הרשת הארגונית.
שרתי ה-Proxy אינם מצליחים לנטר תעבורה שמקורה ביישום ענן אחר. ניתוחים מראים שפוטנציאל החיבוריות שהענן טומן בתוכו מביא לכך שמשתמשים רבים מאפשרים גישה לנכסיהם הדיגיטליים הארגוניים בענן ליישומי צד שלישי רבים, אך גם ליישומים פנימיים של החברה שנמצאים היום בענן. במילים אחרות ״המפעל עצמו עובר לענן״ ושרתי ה-Proxy עיוורים לתעבורה הזו שמתחילה ומסתיימת בענן.
שרתי ה-Proxy מותאמים לנתונים במעבר (data in transit) ואין להם פתרון טוב לנתונים במנוחה (data at rest. כלומר, הם פועלים מרגע הפעלת הפתרון ואינם מכילים מענה להיסטוריה של הארגון.
לעתים קרובות שרתי ה-Proxy ייגרמו לירידה בחוויית המשתמש.
עולם מבוזר
ברמה התפיסתית, גישת האבטחה המבוססת על API מתאימה יותר לעולם המבוזר והחדש הזה, כי בבסיס מדובר בשירותים מבוססי ענן בעצמם שניגשים לשורש ולמקור של הבעיה. תפיסת זו משתמשת ב-API שיש לשירות הענן על מנת להתעדכן לגבי המידע ועל התנהגות המשתמשים ולחסום ולבטל גישה במקרים של פעילות חריגה. בדגש מיוחד שכל זה נעשה בענן עצמו (Cloud Native) כך שאין משמעות אם המידע החדש או הגישה החריגה היא מגע יד אדם שיושב ברשת הארגונית או משתמש חיצוני ששיתף משהו, או שבכלל מדובר ביישום ענן אחר שאחד המשתמשים נתן לו גישה בתמימות והוא בעצם תכונה זדונית שיכולה לשאוב מידע רגיש.
אין ספק שבמבחן הזמן גישת ה – API היא זו שתתפוס. מול הגישה הראשונה עומד צונאמי של מידע ושל כושר התפוקה שהענן מקפל בתוכו, שאף אחד לא יוכל לעמוד מולו. הבעיה בתפיסה השנייה שמכירה במציאות החדשה היא התלות בשירותי הענן ובעושר של ה-APIs שהם מציעים. כלומר, אם שירות הענן לא תומך במתן API שיאפשר רמת אבטחה גבוהה (זמינות של הנתונים בזמן אמת, אפשרות למגר סיכונים וכו׳), אז האתגר של הגישה השנייה יהיה גדול יותר. זו הסיבה שכיום אנו רואים כי יצרני שירותי הענן המובילים ערים לבעיה זאת ומוציאים שירותי ענן חדשים עם API מובנה ועשיר.
לסיכום, הניסיון מלמד כי כדאי ללקוחות להתחיל בקטן, לבדוק את המענה עם שירות ענן ספציפי אחד, בין אם על סביבת אמת או בין אם על סביבה מבודדת באמצעות sandbox, זאת במקביל לפתרונות המסורתיים שקיימים בארגון. משם, הדרך סלולה ליישום מלא של פתרון cybersecurity as a service כוללני מבוסס API המאפשר הגנה אופטימלית על מערכות המידע בענן.
הכותב הוא סמנכ"ל בחברת Cyber Intelligence בחברת CloudLock.
ארגונים רבים מתלבטים בין שתי התפיסות הנהוגות כיום להגנה על מערכות מבוססות ענן – שרתי Proxy או גישת API. אז מה עדיף לארגון שלכם?
הגידול הרב במערכות ארגוניות מבוססות ענן הוביל גם לגידול רב בהיקף איומי הסייבר על מערכות אלו. במקביל ליישומים הטכנולוגיים התפתחו בשנים האחרונות מודלים שונים להגנה על מערכות אלה שניתן לחלק אותם לשתי קטגוריות עיקריות.
הראשונה, אבטחה מבוססת שרתי proxy והקטגוריה השנייה של מערכות הגנה מבוססות API. אין המדובר רק בהבדלים טכנולוגיים אלא בתפיסת עולם הנוגעת למהות אבטחת המידע בתוך הארגון והשאלה היא מהו המודל המתאים לארגון.
הפרוקסי 'לא סוחב'
תפיסת האבטחה שמבוססת על ה – Proxy מנסה עדיין להשתמש בעקרונות אבטחה שמתאימים לעשור הקודם ולתפיסתנו אינה יכולה לעמוד במבחן הזמן בעידן הטכנולוגי שלנו. ביסודה של תפיסה זו עומד העיקרון שמסמן את גבולות האיום לפיו ״כל מה שנמצא בתוך גבולות הרשת הארגונית צריך להיות מוגן ומה שמעבר לו לא״. כך, גישה זו מנטרת את הפעילות שעובדים מהארגון מבצעים מול הענן ובמידת הצורך יחסמו אותה או יתריעו עליה. לא ניתן לפתור את הבעיה כך בשל העובדה שהמידע הארגוני העכשווי מבוזר. אך גם בשל מספר בעיות בסיסות נוספות:
גבולות ה-perimeter מטושטשים. מציאות ה-BYOD והניידות של המשתמשים מקשה עליהם להתחבר ב-VPN בכל רגע נתון ולכן משתמשים ארגוניים לא תמיד נמצאים בתוך הרשת הארגונית.
שרתי ה-Proxy אינם מצליחים לנטר תעבורה שמקורה ביישום ענן אחר. ניתוחים מראים שפוטנציאל החיבוריות שהענן טומן בתוכו מביא לכך שמשתמשים רבים מאפשרים גישה לנכסיהם הדיגיטליים הארגוניים בענן ליישומי צד שלישי רבים, אך גם ליישומים פנימיים של החברה שנמצאים היום בענן. במילים אחרות ״המפעל עצמו עובר לענן״ ושרתי ה-Proxy עיוורים לתעבורה הזו שמתחילה ומסתיימת בענן.
שרתי ה-Proxy מותאמים לנתונים במעבר (data in transit) ואין להם פתרון טוב לנתונים במנוחה (data at rest. כלומר, הם פועלים מרגע הפעלת הפתרון ואינם מכילים מענה להיסטוריה של הארגון.
לעתים קרובות שרתי ה-Proxy ייגרמו לירידה בחוויית המשתמש.
עולם מבוזר
ברמה התפיסתית, גישת האבטחה המבוססת על API מתאימה יותר לעולם המבוזר והחדש הזה, כי בבסיס מדובר בשירותים מבוססי ענן בעצמם שניגשים לשורש ולמקור של הבעיה. תפיסת זו משתמשת ב-API שיש לשירות הענן על מנת להתעדכן לגבי המידע ועל התנהגות המשתמשים ולחסום ולבטל גישה במקרים של פעילות חריגה. בדגש מיוחד שכל זה נעשה בענן עצמו (Cloud Native) כך שאין משמעות אם המידע החדש או הגישה החריגה היא מגע יד אדם שיושב ברשת הארגונית או משתמש חיצוני ששיתף משהו, או שבכלל מדובר ביישום ענן אחר שאחד המשתמשים נתן לו גישה בתמימות והוא בעצם תכונה זדונית שיכולה לשאוב מידע רגיש.
אין ספק שבמבחן הזמן גישת ה – API היא זו שתתפוס. מול הגישה הראשונה עומד צונאמי של מידע ושל כושר התפוקה שהענן מקפל בתוכו, שאף אחד לא יוכל לעמוד מולו. הבעיה בתפיסה השנייה שמכירה במציאות החדשה היא התלות בשירותי הענן ובעושר של ה-APIs שהם מציעים. כלומר, אם שירות הענן לא תומך במתן API שיאפשר רמת אבטחה גבוהה (זמינות של הנתונים בזמן אמת, אפשרות למגר סיכונים וכו׳), אז האתגר של הגישה השנייה יהיה גדול יותר. זו הסיבה שכיום אנו רואים כי יצרני שירותי הענן המובילים ערים לבעיה זאת ומוציאים שירותי ענן חדשים עם API מובנה ועשיר.
לסיכום, הניסיון מלמד כי כדאי ללקוחות להתחיל בקטן, לבדוק את המענה עם שירות ענן ספציפי אחד, בין אם על סביבת אמת או בין אם על סביבה מבודדת באמצעות sandbox, זאת במקביל לפתרונות המסורתיים שקיימים בארגון. משם, הדרך סלולה ליישום מלא של פתרון cybersecurity as a service כוללני מבוסס API המאפשר הגנה אופטימלית על מערכות המידע בענן.
הכותב הוא סמנכ"ל בחברת Cyber Intelligence בחברת CloudLock.
