גישה מ-VPN ל-VLAN: בונים את המטריצה לפני הכללים
תפקידים בצד אחד, שירותים בצד השני. חמש בדיקות הופכות תכנון מעורפל של גישה מ-VPN ל-VLAN לטבלה שבעל חומת האש יכול ליישם.
מתחילים במטריצה, לא בתחביר של חומת האש. טבלה עם תפקידים בצד אחד ושירותים בצד השני יכולה להיבדק על ידי בעל אפליקציה, להידון על ידי בעל אבטחה ולהיושם על ידי מי שמחזיק בשער. הסקירה הזאת זולה יותר מניפוי תקלות בכללים שאיש לא הסכים עליהם.
שעה של כתיבה חוסכת אחר כך שבוע של ארכאולוגיה של כללים. התכנון מדבר על מי מגיע לאיזה שירות, וזה החלק ששורד מספור מחדש.
שלב 1: נותנים שמות לתפקידים לפני הרשתות
מתחילים באנשים, לא במתג. רושמים כל קבוצה שמתחברת מרחוק ואת המשפט היחיד שמתאר מה הקבוצה עושה, למשל עובדי מחסן שקוראים רמות מלאי או קבלן שמתחזק אינטגרציה אחת. אם שתי קבוצות יקבלו גישה זהה, הן תפקיד אחד למטרה הזאת.
עוצרים כאן אם תפקיד קיים רק בגלל תרשים ארגוני. תפקיד בלי צורך ייחודי בשירות הופך לשורה של תאים זהים, ושורות זהות מזמינות מישהו להעניק אחר כך תת-רשת שלמה מטעמי נוחות. מחלקים לפי מה שאנשים עושים, לא לפי מי שחותם על ההוצאות שלהם. שישה תפקידים זה בדרך כלל יותר מדי למשרד קטן ושלושה זה לרוב נכון.
שלב 2: הופכים כל תא להצהרת שירות
תא שכתוב בו „אפליקציות“ אינו ניתן לבדיקה. תא שכתוב בו „HTTPS למארח ה-ERP בפורט 443, ממאגר העובדים“ כן ניתן לבדיקה. מחליפים כל שם רשת ביעד, בפרוטוקול ובפורט, ואז מוסיפים את התלות שבלעדיה השירות לא עובד, כמו הפותר הפנימי או ספק הזהות.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
עמודת הכיוון תופסת את הטעויות היקרות ביותר. הרשאה לעובדים לפתוח אפליקציה אינה מרמזת על הרשאה לשרתי אפליקציה לפתוח חיבורים חזרה למחשבים הניידים של העובדים, וכלל עם מצב שמתיר את הכיוון הראשון נקרא לעתים קרובות כאילו הוא מתיר את השני.
שלב 3: מחליטים איפה זהות הופכת למדיניות
מישהו חייב להפוך הפעלה מאומתת לתפקיד שהשער יכול לאכוף. האפשרויות הנתמכות כוללות מדיניות קבוצה שמספק ה-backend של האימות, מאפייני הפעלה מהימנים, או מאגרי כתובות נפרדים לכל תפקיד. שלושתם עובדים; תווית שהלקוח שולח לא. בוחרים במנגנון שהשער שלכם מתעד, לא בזה שפוסט בפורום מתאר.
הקצאת כתובת שרק נראית כאילו היא שייכת ל-VLAN היא אותה תשובה לא-תשובה בתחפושת אחרת. המדריך של Netgate לכללי חומת אש של OpenVPN מבהיר את ההפרדה: לאפשר למנהרה לעלות הוא החלטה שונה מלאפשר לתעבורה לעבור דרכה.
רושמים איזה מנגנון בחרתם ואיפה הוא מוגדר. כשתפקיד משתנה, ההערה הזאת היא ההבדל בין עריכה אחת לבין מרדף אחרי שלושה ממשקים. היא גם אומרת למבקר איפה להסתכל קודם.
שלב 4: שמים לב לכתובת המקור שהיעד רואה
מדיניות ההעברה חייבת להתאים למקור האמיתי בגבול. אם השער מתרגם לקוחות VPN לכתובת שלו, כל חומת אש במורד רואה מקור אחד ומאבדת את היכולת להחליט לפי תפקיד. אם הוא משמר את כתובת הלקוח, נתיב החזרה חייב להתקיים עבור המאגר הזה.
בודקים את שני הכיוונים לפני שכותבים את הכללים הסופיים, ואז רושמים את המקור הנצפה לצד כל תא. מריצים את אותה בדיקה משני תפקידים שונים ומשווים את התוצאה. אם שניהם מראים את כתובת השער, הבחנת התפקידים כבר אבדה. מטריצה שמניחה כתובות משומרות בזמן שהשער מבצע תרגום מקור נכשלת ב-ACL הראשון במורד.
שלב 5: בודקים כל תא לפני שמשחררים
הופכים כל תא מותר לפעולה מייצגת אחת וכל תא אסור למקרה שלילי. מריצים את שניהם מלקוח בתפקיד האמיתי, לא ממסוף השער, כי המסוף עוקף את הנתיב שאתם בודקים.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'מקרה שלילי שמתחבר הוא ממצא, לא מקריות, ומקומו במטריצה כתא כושל עד שהכלל יתוקן. משאירים את פקודות הבדיקה לצד הטבלה כדי שהסוקר הבא יריץ אותן שוב במקום לבנות מחדש את הנימוק.
הטבלה המוגמרת שורדת את השער שלמענו נכתבה. כללים משתנים עם קושחה וספק, אבל השורה שאומרת שקבלן מגיע לשירות פרויקט אחד נשארת נכונה עד שהעבודה הזאת משתנה.