מהו מקור ומה בדיוק רוצים למנוע
המקור הוא השירות שמגיש את האתר מאחורי שכבת התיווך. אם המסלול הישיר עדיין מקבל בקשות שאמורות לעבור דרך ההגנות בקצה, ייתכן שאותן הגנות אינן חלות על כל התעבורה. חשיפה של כתובת אינה לבדה הוכחת פגיעה, ותשובת שרת אינה מוכיחה אילו פעולות הותרו.
הגדירו מראש את השאלה: האם רק תיווך מותר, האם קיימים שותפים הזקוקים למסלול אחר ואילו שירותים משותפים לאותו שרת. תכנון לא נכון יכול לפגוע גם בדואר, בבדיקות בריאות או בתחזוקה. אל תסיקו שתעודה או WAF לבדם סוגרים כל דרך אל המקור.
מפו מסלולי תעבורה לפני הגבלת גישה
השוו את אזור ה-DNS, הגדרות הפרוקסי, הגדרות האחסון והמסלולים שמנהל המערכת מאשר. הבדיקות הטכניות צריכות להישאר ברשימת הנכסים והמטרות שהוגדרו; אין צורך במדריך לסריקת כתובות כדי להכין מפת אחריות.
| מסלול | מה מאמתים | תלות שצריך לשמור |
|---|---|---|
| תעבורת גולשים | דרך הפרוקסי המתוכננת | שמות מארח וחיבור מאובטח |
| אינטגרציה או שותף | מקור בקשה ושיטה מאושרים | טפסים, תשלומים או API |
| ניטור ותחזוקה | מי צריך לבדוק או לנהל | יכולת התאוששות וגישה מורשית |
| שירות אחר בשרת | גבול נפרד מהאתר | דואר או יישום שאינם בפרוקסי |
בחרו בקרה שמתאימה לתשתית
Cloudflare מציגה שכבות שונות להגנת מקור, ובהן הגבלת גישה ברשת ושיטות נוספות לאימות הנתיב. בחירת הבקרה תלויה בארכיטקטורה, בתמיכת האחסון ובפעילות לגיטימית שצריכה להישאר. רשימת כתובות מותרות דורשת תחזוקה ואינה זהה לאימות כל בקשה.
אלה דוגמאות מוצר, לא הוראות להחלת כלל גורף בכל שרת. מנהל מורשה צריך להבין מה ייחסם, איזה גיבוי תפעולי קיים ואיך בודקים את החיבורים לפני הרחבה. אחסון משותף ושירות מנוהל עשויים להגביל את סוג השינוי שניתן לבצע.
בדקו TLS וזהות חיבור בנפרד מחומת אש
חיבור מוצפן למקור עונה על שאלה שונה מהשאלה מי רשאי להגיע אליו. ב-Cloudflare, Full (strict) מוסיף דרישות לתעודת המקור. הוא אינו לבדו רשימת הרשאות רשת או מדיניות שמונעת כל מסלול ישיר.
לא פותרים תקלה על ידי החלשה אוטומטית של אימות תעודה. בדקו איזה רכיב נכשל ומהו שם המארח הנדרש, והבחינו בין תעודת קצה לתעודת מקור. מסלול שעובד ללא השכבה המתוכננת צריך להיבחן מול המדיניות, לא להיות מוכרז תקין רק מפני שמופיע בו HTTPS.
דוגמה: כלל חדש מפסיק עדכון סטטוס הזמנה
זו המחשה ולא מקרה לקוח. העסק מגביל גישה למקור ואז מגלה שחיבור של ספק תשלום אינו מעדכן הזמנה. האחראי חוזר למפת המסלולים, מזהה את התלות ובודק מסלול נתמך ומאושר מול הספק, במקום לפתוח את השרת לכל כתובת כדי להעלים את הסימפטום.
בחלון השינוי בודקים פעולה עסקית בנתוני ניסיון ובאישור המתאים. לא מבצעים חיוב לקוח לצורך בדיקה ללא תיאום. הדרך חזרה צריכה לשמור גישה ניהולית ולהיות מתועדת, אחרת תיקון תקלה ביישום עלול להפוך לנעילת תחזוקה.
איך נראה סיכום בדיקה שימושי
הסיכום צריך לציין נכסים שנכללו, נתיב מותר, תצפית על גישה שנועדה להיחסם ובדיקות תפקוד לאחר שינוי. מסלול שלא ניתן לבדוק נשאר מגבלה. קבעו מי מתחזק הגדרות ומי מקבל דיווח כאשר חיבור חיוני נכשל.
אל תציגו אי-נגישות מבדיקה אחת כהוכחה שאין עוד חשיפה. הגדרות ספק, תתי-דומיין או שינוי שירות יכולים להשפיע בעתיד. במצב של חשד לפגיעה משמרים ראיות ומתאמים טיפול מתאים; הקשחת נתיב אינה מחליפה ניקוי או בירור של אירוע.
