כמה חבילות זדוניות חומת האש שלכם חוסמת מדי יום? וכמה היא הייתה צריכה לחסום – אבל לא חוסמת?

ברוב רשתות הארגון, ACL בשכבה 3 (Layer 3 Access Control Lists) הם קו ההגנה הראשון נגד תעבורה לא רצויה. הם הבסיס לסינון מבוסס-IP – אבל הפשטות שלהם היא גם יתרון וגם עקב אכילס. ככל שהתוקפים משתכללים והרשתות נעשות דינמיות, ACL בשכבה 3 נדחפים עד קצה היכולת שלהם.

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

כיצד ACL בשכבה 3 קשורים ל-NIST SP 800-207

למרות ש-ACL בשכבה 3 לא תוכננו מראש עם Zero Trust בראש, עדיין יש להם תפקיד מוגבל בארכיטקטורות המיושרות לתקן NIST SP 800-207. המסגרת מדגישה אכיפת מדיניות דינמית, מודעת-זהות ומבוססת הקשר – תחומים שבהם ACL מסורתיים קצרים מלהספיק. עם זאת, כאשר משתמשים בהם בפרימטר הרשת או בסביבות ענן יליד (כמו Security Groups או NSGs), ACL יכולים לשמש כמסנן ברזולוציה גסה לפני שמיישמים מדיניות Zero Trust עמוקה יותר בערימה. הפשטות שלהם הופכת אותם למהירים, אבל כדי ליישר אותם עם עקרונות Zero Trust חייבים לצרף בקרות מודרניות כמו אימות זהות, בדיקות מצב מכשיר (Posture) ואימות רציף.

מדוע ACL לבדם אינם יכולים לתמוך בארכיטקטורת המיקרו-סגמנטציה

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

זרימת עבודה בשלבים

מהן ACL בשכבה 3?

רשימות בקרת גישה (ACL) בשכבה 3 הן מסננים מבוססי־כללים השולטים בזרימת תעבורה מבוססת-IP בשכבת הרשת (Layer 3 במודל OSI). בדרך כלל מיישמים אותן בנתבים, פיירוולים ומתגים כדי לאפשר/לחסום תעבורה לפי כתובות ה־IP של המקור והיעד.

רכיבים מעורבים

רכיב	תפקיד
נתב או פיירוול	מארח את ה־ACL
Control Plane	מנתח ושומר את כללי ה־ACL
Data Plane	מיישם את כללי ה־ACL על התעבורה בזמן אמת

 

קלטים ל־ACL

• כתובת IP מקור
  
  
• כתובת IP יעד
  
  
• פרוטוקול (TCP, UDP, ICMP)

פלטים

• החלטת Permit או Deny לחבילה
  
  
• רישום לוג/התראה (אופציונלי)
  
  

תחביר ומבנה טיפוסיים

ACL היא רשימה של כללים מסודרים. כל כלל מוערך לפי הסדר עד שנמצא התאמה.

דוגמת כלל (בסגנון Cisco):

access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255

 

מה זה אומר:
אפשר את כל תעבורת ה־IP מתת־הרשת ‎192.168.1.0/24‎ אל ‎10.0.0.0/24‎.

שימו לב: הסדר קובע – הכלל הראשון שמתאים קובע את גורל החבילה, וברוב המקרים קיים בסוף הרשימה “deny any” משתמע.

היכן פורסים ACLs – מקרי שימוש נפוצים

סביבה	שימוש ב־ACL
דאטה סנטר	סיגמנטציה בין VLANs/אזורים
רשת קמפוס	חסימת גישת אורחים לשרתי פנים
ענן (למשל AWS SG / NSG)	שליטה בתעבורה בין מופעים/שירותים
נתבי WAN	סינון מסלולים נכנסים/יוצאים

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

לוגיקת אכיפה ונתיב העיבוד (Enforcement Logic & Path)

כאשר חבילת נתונים (Packet) מגיעה לממשק, היא נבחנת בזמן אמת במישור הנתונים (Data Plane) של הנתב או הפיירוול. בדיקת ה-ACL חייבת להתבצע בקצב קו (Line-Rate) – אחרת ביצועי המכשיר נפגעים.

זרימת האכיפה:

1. חבילה מתקבלת בממשק כניסה (Ingress) או יציאה (Egress).
   
   
2. מישור הבקרה (Control Plane) טוען את סט כללי ה-ACL אל מישור הנתונים.
   
   
3. מישור הנתונים משווה את כותרות החבילה לכללים.
   
   
4. החלטה: permit / deny / log.
   
   

מדדים למעקב (Metrics to Track)

מדד	למה זה חשוב
Rule hit count	מצביע על אפקטיביות הכללים ומה באמת בשימוש
Packet drop rate	מרמז על איומים אפשריים או על שגיאות תצורה
Latency impact	כללי ACL לא יעילים עלולים להאריך זמני עיבוד
Rule overlap / conflict	עלול ליצור גישה לא רצויה או חסימות לא מכוונות
Rule utilization	מסייע לזהות כללים מיושנים/לא בשימוש

נקודות כשל: איפה ACLs קורסים

מדרוג (Scalability)

ככל שהסביבה גדלה, ניהול ACL בשכבה 3 הופך למסובך: אלפי כתובות IP וחריגים יוצרים נפיחות כללים (Rule Bloat) ושגיאות אנוש.

חוסר הקשר (Lack of Context)

ל-ACL אין מודעות ל:

• זהות משתמש
  
  
• סוג אפליקציה
  
  
• שעת היום
  
  
• מצב המכשיר (Posture)
  
  

לכן הם עיוורים לאיומים מודרניים שמשתמשים ב-IP לגיטימי למטרות זדוניות.

זיוף IP (IP Spoofing)

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

טבע סטטי (Static Nature)

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

שורשי כשל נפוצים:

• אין סימולציה של כללים לפני הפעלה.
  
  
• היעדר “deny by default” (דחייה כברירת מחדל) בראש המדיניות.
  
  
• שגיאות אנוש בסידור הכללים (Sequencing) שגורמות להתאמות מוקדמות שגויות.

האם ACLs עדיין חשובים בעידן Zero Trust?

כן-אבל כמרכיב, לא כאסטרטגיה.

תפקידי ACL בתוך Zero Trust

סוג ACL	תפקיד
Ingress ACL	שער ראשון לפני הגעה לעומסי עבודה
ACL נטו-ענני	בשילוב עם Security Groups או NSGs
ACL של מיקרו-סגמנטציה	אכיפה ברמת המארח לתעבורת מזרח–מערב

עם זאת, ב־Zero Trust זהות, התנהגות והקשר חשובים יותר מ־IP. לכן ACLים מוחלפים או מועצמים במדיניות מודעת-זהות.

ACL בשכבה 3 לעומת בקרת גישה מודעת זהות

מאפיין	ACL שכבה 3	גישה מבוססת זהות
היקף	IPs/תתי־רשתות	משתמשים, מכשירים, תפקידים
מודעות הקשר	❌	✅
הסתגלות דינמית	❌	✅
תמיכה נטו־עננית	חלקית	מלאה
חסימת תנועה רוחבית	בסיסית	מדויקת

המלצות לשימוש מודרני ב־ACL

• סגמנטו לפי Subnet רק כשצריך: הימנעו מטווחי IP רחבים שמחייבים כללי “allow all”.
  
  
• השתמשו בכלי סימולציית ACL: ולאמת מראש הצללה (Shadowing), חפיפות ופערי מדיניות.
  
  
• אוטומציה עם IaC: ניהול ACL בעזרת Terraform, Ansible או APIs ייעודיים.
  
  
• שלבו עם כלים מבוססי זהות: השתמשו ב־ACL כשער ראשון, ובמקביל ZTNA/EDR לאכיפה עמוקה.
  
  
• לוגים וביקורת שוטפת: הכשל ה"שקט" של ACL הוא היעדר נראות בלי לוגים אגרסיביים.
  
  

TL;DR – השורה התחתונה ב־30 שניות

• ACL בשכבה 3 מסננים תעבורה לפי כתובות IP ופרוטוקולים – מהירים ופשוטים, אבל עיוורים להקשר.
  
  
• הם מתקשים במדרוג, סביבות דינמיות ואיומי Insider.
  
  
• הם עדיין שימושיים ב־Zero Trust – רק יחד עם הקשר זהותי והתנהגותי.
  
  
• תצורות שגויות נפוצות; אוטומציה וסימולציית כללים קריטיות.