איזון בין הקלטה וחסימה ב-WAF

Informatec Digital » משאבים » איזון רישום וחסימה ב-WAF

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

במאמר זה, נעמיק כיצד להשיג איזון זה באמצעות יכולות WAF מודרניות (רשימות היתרים, כללים מבוססי תדרים, מצבי למידה, שילוב SIEM, למידת מכונה וכו'), נתמך על ידי דוגמאות קונקרטיות מ- AWS WAF, ModSecurity, WAFs מבוססי ענן ופתרונות מקומיים . תראו כיצד להגביל תוצאות חיוביות שגויות מבלי להוריד את רמת ההגנה, כיצד לארגן מדיניות לפי אפליקציה, וכיצד להשתמש ברישום כבעל ברית, לא כמקור רעש קבוע ובלתי ניתן לניהול.

מהו WAF ומדוע רישום כה חשוב?

חומת אש של יישומי אינטרנט פועלת כשכבה חכמה בין המשתמש לשרת , ומנתחת תעבורת HTTP/HTTPS בזמן אמת. בניגוד לחומת אש רשת מסורתית, המנטרת פורטים וכתובות IP, חומת אש של רשת WAF מתעמקת: כתובות URL, פרמטרים, גופי בקשה, כותרות, קובצי Cookie, שיטות HTTP ועוד.

משימתה היא לזהות ולעצור התקפות אופייניות בשכבה 7 : הזרקת SQL, XSS, LFI/RFI, התקפות נגד בקרת גישה, שימוש לרעה ב-API, גירוד אגרסיבי, כוח גס ואפילו דפוסי DDoS מסוימים ברמת האפליקציה. לשם כך, היא מסתמכת על קבוצות של כללים, חתימות ומדיניות אבטחה המתעדכנות כל הזמן.

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

• לחקור אירועים: לשחזר מה קרה וכיצד נעשה ניסיון לנצל פגיעות.
• התאמת כללים: לזהות תוצאות חיוביות שגויות על ידי בדיקת אילו בקשות לגיטימיות ה-WAF חוסם.
• לציית לתקנות: להדגים שקיימות בקרות פעילות (PCI DSS, GDPR, ביקורות פנימיות וכו').
• האכלת SIEM: לקשר התקפות יישומים עם אירועי רשת, מערכת, זהות וכו'.

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

מודלי אבטחה ב-WAF: רשימות חסימה, רשימות היתרים וגישה היברידית

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

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

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

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

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

WAF ברשת, במארח ובענן: השפעה על רישום ונעילה

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

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

שרתים מבוססי מארח ( WAFs ) פועלים על אותם שרתים (או קונטיינרים) שבהם נמצאת האפליקציה, בדרך כלל כמודול או סוכן (לדוגמה, ModSecurity משולב ב-Nginx או Apache; שילובו עם הקשחת לינוקס באמצעות SELinux משפר את מצב האבטחה). מודל זה מאפשר הקשר אפליקציה גדול יותר וכללים ספציפיים ביותר לכל שירות, במחיר של צריכת משאבים מקומיים ודורש ניהול יומני רישום מבוזרים יותר. ניתן לאחסן יומני רישום בקבצים מקומיים ולאחר מכן להעבירם, או לשלב אותם עם שירותי רישום מרכזיים.

רשתות WAF מבוססות ענן (Cloudflare, Akamai, Imperva Cloud, AWS WAF וכו') משתלבות עם מאזני עומסים, CDN או רשתות וירטואליות. ספקים בדרך כלל מציעים לוחות מחוונים וייצוא יומני רישום ל-S3, BigQuery, יומני סיסטם מרוחקים או SIEM. הן בדרך כלל קלות יותר להגדרה, אך עליך להתאים את מדיניות הרישום שלך למודל של הספק: סוגי אירועים, תקופות שמירה, מסנני חומרה וכו'.

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

תנאים, כללים ו-ACL של האינטרנט: כיצד ה-WAF מחליט אם לחסום, לאפשר או רק להירשם

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

התנאים מתארים איזה חלק של הבקשה נבדק: כתובת IP של המקור, כותרות HTTP ספציפיות (Host, User-Agent, Accept, Content-Type…), פרמטרי שאילתה, גוף הבקשה, קובצי Cookie, שיטת HTTP, מדינת מוצא וכו'. לדוגמה, ב-AWS WAF Classic ניתן להגדיר תנאי IP עם עד 10.000 כתובות או טווחים, או תנאי התאמת מחרוזות על חלק מכתובת ה-URL.

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

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

• מלא כוח ברוט בטפסי התחברות.
• הגבל גירוד אגרסיבי או בוטים גסים.
• הפחתת סוגים מסוימים של התקפות DDoS ברמת האפליקציה.

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

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

רשימות לבנות והפחתת רעשים ביומנים

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

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

• מניעת ממשקי API פנימיים המשתמשים בתבניות "מוזרות" לייצר חיוביים שגויות קבועים.
• הפחת את ההשהיה שנוצרת על ידי בדיקה מעמיקה בתעבורה שאתה כבר מחשיב כאמינה.
• הפחת את כמות הרשומות המיותרות ביומני WAF.

בפלטפורמות כמו ModSecurity, הגישה המומלצת אינה לשנות כללים סטנדרטיים (למשל, OWASP Core Rule Set), אלא ליצור החרגות ספציפיות לפי מזהה כלל עבור פרמטרים, נתיבים או משתמשים מסוימים. זה מאפשר לך לשמור על הגנה כוללת מבלי ליצור פגיעויות גדולות על ידי השבתת כללים שלמים ברחבי האתר.

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

כללי פרוטוקול ומגבלות: מתי לחסום, מתי להזהיר

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

כמה דוגמאות נפוצות מאוד:

• חסרה כותרת קבלה (כותרת קבלה חסרה): זו אינה הפרת RFC באופן מובהק, אך בקשות רבות ללא כותרת זו מגיעות מכלים אוטומטיים או מסקריפטים שנכתבו בצורה גרועה. הדבר יכול להשפיע על ממשקי API מותאמים אישית או לקוחות שלא שולחים אותה. בסביבות רבות, רישום וספירה עדיפים על פני חסימה מוחלטת.
• כותרת מארח חסרהלפי תקני HTTP/1.1, כותרת ה-Host היא חובה. WAFs זקוקים לה גם כדי לקבוע איזו מדיניות להחיל. חסימה כאן היא בדרך כלל סבירה, אך היא עלולה לייצר תוצאות חיוביות שגויות במהלך הבדיקה או עקב תעבורה פנימית שתצורתה שגויה; מומלץ לנטר את היומנים לפני הפעלת חסימה קפדנית.
• כותרת סוכן משתמש חסרהכלל זה מנסה לרסן בוטים בסיסיים ותעבורה לא מזוהה. הבעיה היא שרוב ממשקי ה-APIs לגיטימיים עשויים שלא לשלוח סוכן משתמש. הגישה ההגיונית ביותר היא בדרך כלל לבצע רישום, ואם מזוהה API עקבי ולגיטימי, הוספת כתובת ה-IP או התבנית שלהם לרשימת היתרים.
• אימות GET/HEAD עם גוףלמרות ש-RFC אינו אוסר בתוקף שליחת גוף ה-call עם בקשות GET או HEAD, זה לא נוהג נפוץ ועשוי להצביע על ניסיונות התחמקות. במקרים רבים, הצעד הראשון הוא לתעד את כל הבקשות הללו, ואם הן מתגלות כאנומליות חשודות, להמשיך ולחסום אותן.
• חסר סוג תוכן עם גוףאם יש גוף אך אין סוג תוכן, זוהי אינדיקציה ברורה לשימוש לא תקין בפרוטוקול או ניסיון להתחמק מניתוח. במקרים אלה, גישת חסימה אגרסיבית יותר בדרך כלל הגיונית, במיוחד בסביבות הפונות לאינטרנט.

בנוסף לכללי פרוטוקול אלה, מגבלות ארגומנטים נמצאות לעיתים קרובות כמגנות מפני הצפות ברמת האפליקציה והתקפות DoS. לדוגמה:

• מספר מרבי של ארגומנטים לכל בקשה (כברירת מחדל, 255 בחלק מ-WAFs).
• אורך מקסימלי של ארגומנט בודד (לדוגמה, 400 תווים).
• הגודל הכולל המשולב של כל הארגומנטים (לדוגמה, 64.000 בתים).

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

תוצאות חיוביות שגויות: כיצד לזהות אותן ולא למות בניסיון

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

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

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

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

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

אסטרטגיות להתאמת כללים ושימוש מושכל ברישום

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

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

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

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

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

אוטומציה, למידת מכונה וכללים אדפטיביים ב-WAF

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

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

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

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

לבסוף, בדיקות אוטומטיות רציפות (באמצעות כלים כמו OWASP ZAP, סקריפטים מותאמים אישית או צינורות CI/CD) מאפשרות לך לאמת ששינויים ב-WAF אינם פוגעים בפונקציונליות קריטית או משאירים פגיעויות ברורות. שילוב בדיקות אלו במחזור הפריסה הופך את האבטחה לחלק טבעי מתהליך הפיתוח, ולא לתיקון של הרגע האחרון.

עיצוב מדיניות לפי יישום ורשימות שחורות לפי שירות

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

דוגמה להמחשה היא מאזן עומסים של HTTP/S הפועל כ- Reverse Proxy עבור מספר אתרים (למשל, www.company1.com ו-www.company2.com) מאחורי כתובת IP וירטואלית אחת. בתרחיש זה, ניתן להגדיר את ה-WAF להעריך את כותרת המארח ואת כתובת ה-IP של המקור ברגע שהבקשה מגיעה, עוד לפני שהיא מגיעה למודול איזון העומסים.

ההיגיון יהיה בערך כך: ה-WAF בודק אם השילוב של SERVER_NAME (Host) וכתובת ה-IP של הלקוח תואם לרשימה שחורה ספציפית לאתר. אם ה-IP רשום כחסום עבור www.company2.com אך לא עבור www.company1.com, תגובת 403 Forbidden נשלחת רק במקרה הראשון. התעבורה ה"נקייה" מועברת לאחר מכן למודול איזון העומסים, אשר מחליט איזה backend משרת את הבקשה.

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

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

מעבר ל-WAF הקלאסי: הגנה על WAAP ו-API

נוף האיומים לא עמד מלכת. כיום, יישומים רבים הם מבוססי ענן, משתמשים בארכיטקטורות של מיקרו-שירותים וחושפים ממשקי API ציבוריים ופרטיים , מה שהופך אותם למטרות עיקריות לתוקפים. רשתות WAF מסורתיות התפתחו לפלטפורמות רחבות יותר המכונות WAAP (Web Application and API Protection) או WAAS (Web Application & API Security).

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

ברמת הרישום, WAAP נוטה לייצר אירועים עשירים בהקשר : איזו נקודת קצה מדויקת של ה-API הותקפה, איזו פעולה (GET, POST, PUT…), איזה משתמש או טוקן היה מעורב, איזה חלק מהמפרט הופר וכו'. זה מאפשר קבלת החלטות חסימה מדויקות יותר, במקום להסתמך אך ורק על דפוסי מטען גנריים.

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

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