הגדרת AWS WAF להגנת יישומי אינטרנט

מה מסוכן בתעבורה לא מסוננת: הגדרת AWS WAF

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

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

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

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

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

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

מה נותן סינון בקשות מנוהל בפרימטר

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

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

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

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

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

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

אפשרויות להגנת הפרימטר: מה בוחרים ולמה

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

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

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

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

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

שלבי הטמעה: מביקורת תעבורה ועד מסירת נהלים

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

1. ביקורת תעבורה ונקודות כניסה. אוספים סטטיסטיקה לפי כתובות, שיטות, כותרות ושיעור לקוחות אוטומטיים — מקבלים קו בסיס שמולו משווים את כל ההמשך.
2. סכמת כללים. ממיינים איומים לפי עדיפויות: מה חוסמים באופן קשיח, מה מגבילים לפי תדירות בקשות, ומה לעת עתה רק רושמים ביומן.
3. הפעלה במצב תצפית. הכללים סופרים התאמות אך אינם מפריעים למבקרים: רואים את מי החסימה הייתה פוגעת, בלי להשפיע על המרה וזמינות.
4. ניתוח התראות שווא. לפי היומנים מוציאים מהסינון כתובות שירות, תקשורת עם מערכות חיצוניות והחזרים מספקי תשלומים.
5. מעבר לחסימה. מפעילים כללים אחד אחד, עם תוכנית חזרה לאחור וסף שאחריו חוזרים אוטומטית לתצפית.
6. בדיקה על תעבורה חיה. עוקבים אחרי שיעור הכשלים, זמן התגובה ומעבר תרחישי מפתח תחת עומס ובשעות שיא.
7. מסירת נהלים. מוסרים מפת כללים, סדר הוספת חריגים, תרחישי תורנות ונקודות הסלמה.

תצורות כללים, סכמת תעבורה ונהלי תגובה

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

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

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

הטמעה בפרויקט חי: מדדים לפני ואחרי

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

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

מה שינינו ומה התקבל

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

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

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

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

במה WAF שונה מהגנה מפני תקיפות המוניות ומחומת אש ברשת?

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

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

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

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

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

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

התנגדויות טכניות נפוצות לפני תחילת העבודה

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

חסימות שווא ינתקו לקוחות חיים?

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

האם נדרשת גישה לקוד ולמאגר?

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

מי מנתח את ההפעלות לאחר ההרצה?

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

נדון במשימה ונחזור עם תוכנית הטמעה

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

בשיחה נבהיר ונבקש לשלוח:

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

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

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