העשורים האחרונים הפכו את חומת האש של יישומי האינטרנט (WAF) לחלק בלתי נפרד מכל פתרון הגנה מקוון. בכל ארגון המנהל אפליקציות רשת (כלומר רוב העסקים הגדולים), מותקן WAF, כדי להגן על האפליקציות והמידע שלהם מפני ניצול ותקיפה. השיטה הטובה ביותר לאבטחת יישומי אינטרנט התפתחה לפריסה פשוטה של WAF מול האפליקציה שלך. אך בשוק הנוכחי, כאשר מחזור החיים המודרני של היישומים מאפשר לצוותי DevOps לשחרר עדכונים בתדירות גבוהה בהרבה, האם ה- WAF המסורתי יכול לעמוד בקצב?
זה הסוד הכי פחות שמור בענף שה- WAF אינו כל מה שהוא טוען שהוא, בעולם המודרני של פיתוח זריז. WAF אינו יכול לעמוד בעדכוני היישומים, המתרחשים באופן קבוע, ותחזוקה של WAF הפכה להיות עתירת עבודה ומורכבת.
מה יכול לעשות איש המקצוע בתחום האבטחה, אם ה-WAF מת? מה ימנע מאפליקציית האינטרנט שלך להפוך לדלת הכניסה ל"כספות" הארגון? בידיעה ש- DevOps ימשיכו לפרוס קוד חדש, איך תוכל להבין אם ה- WAF שלך שווה את התחזוקה או שהוא סיים את דרכו? הבה נבחן מקרוב את מה שיידרש ל- WAF שלך כדי לעמוד בקצב המהירות של ה- DevOps.
הכל סביב ההקשר
כאשר אבטחת הרשת עסקה בניטור רשתות סטטיות, המשתמשות באותם פרוטוקולים, ה- WAF נועד להגן על יישומי אינטרנט השונים זה מזה באופן מובהק. כל אפליקציה היא ייחודית וכל פיסת קוד שונה וייחודית בפגיעותה להתקפות. עוד לפני כניסת האחסון בענן ויכולות הפריסה המהירה של צוותי DevOps, הוכר ה- WAF כפתרון אבטחה בינוני בלבד. באופן בלתי נמנע, שימוש בפתרון שיושב לפני האפליקציה במקום בשורה אחת איתה, פירושו שניתוח קשר השימוש באפליקציה אינו אפשרי. ללא הקשר להבנת התוכן באפליקציה שאיתה מתקיימת אינטראקציה, אי אפשר לשנות אוטומטית את ה- WAF במקביל להתפתחות היישום.
למידה, למידה, למידה
שיפורים בלמידת מכונה רק פתרו את הבעיה הזו במידה מסוימת. בעוד WAFs מתוחכמים זקוקים "רק" לחודש כדי לשבת וללמוד בשקט, כדי ליצור קו בסיס ליישום, חודש הוא זמן רב להשאיר אפליקציה ללא הגנה. אין מנוס מכך שבני אדם ייאלצו להתערב ולעזור בכיול ה- WAF, ואז התחזוקה הופכת למעמסה כבדה. אם ה- WAF זקוק לזמן ללמוד ולייצר קו בסיס בכל פעם שהתוכן או הקוד משתנים, נדרשת עבודה רבה של מנהל המערכת כדי להפחית את כמות ההתראות וליצור החרגות.
אוטומציה או סטגנציה
לשאלה הבאה: האם ה- WAF שלך יכול באמת להגן על יישום אינטרנט מפני התקפות לוגיות, ללא התערבות אנושית? התשובה היא שעם מסירה רציפה (Continuous Delivery), זה פשוט לא אפשרי. המציאות היא שרוב ה- WAF אינם במצב התראה. זה מסוכן מדי לאפשר להם חסימת יתר, מכיוון שהנפחים הגבוהים של ההתראות ייצרו עומסי התראות שלא יהיה ניתן להתמודד איתם. אולי מנהל המערכת יבצע כיוונון עדין, כך שחלקים רגישים באפליקציה יכוסו בכללי חסימה, אך שאר האפליקציה תוגן על-ידי ה- WAF במצב התראה, באמצעות התאמת תבניות וטכניקות גסות אחרות. זה מסתכם בפתרון אבטחה שלא יכול להיפרס אוטומטית, כדי להגן מפני התקפות לוגיות חדשות, ככל שהאפליקציה מתפתחת.
התקדם או הישאר מאחור
מחשוב ענן עוסק בזריזות. מה שלקח שבועיים ליצור עוד בשנת 2015, דורש עכשיו שניות ספורות. על-ידי שימוש במיקרו-שירותים, ניתן לשנות באופן דרמטי את האפליקציה שלכם בתוך מספר דקות. בסביבה חדשה זו, מגוחך לשקול שימוש בפתרון אבטחה סטנדרטי של אפליקציות טרום ענן, הנשען על תצורות למידה או תצורה ידנית.
בכל פעם שמפתח משנה קוד ושולח אותו לדרכו, זהו מהלך חד-צדדי ללא התייעצות עם אנשי אבטחת המידע.
אם אתה משתמש ב- WAF שמסתמך על ההנחה שכל דבר בסביבתך הוא דומה, ה- WAF שלך מושבת והגיע הזמן לקרוא לקברנים. ה- WAF מת ו- DevOps הרגו אותו. זה הזמן לערוך בדיקה מעמיקה כדי להבין אם ל- WAF שלך יש דופק, או שהפך למשקולת וירטואלית.
לכן מומלץ להתקדם להגנה מלאה על יישומי אינטרנט באמצעות CloudGuard AppSec של צ'ק פוינט. בעזרת מנוע הבינה המלאכותית להבנת הקשר השימוש ביישום (contextual AI), AppSec מספק הגנה אוטומטית ודינאמית על יישומים וממשקים.
הכותב הוא סמנכ"ל מוצרי אבטחת ענן בצ'ק פוינט
