Firewall

Check Point Identity Awareness: להפסיק לכתוב חוקים לפי IP ולהתחיל לכתוב אותם לפי אנשים — מדריך מלא בעברית

12 דק׳ קריאה•מכללת נטמי

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

Identity Awareness של Check Point נועדה בדיוק לפער הזה. במקום לנהל מדיניות לפי כתובות שמשתנות כל יום ב-DHCP, הגייטוואי לומד מי המשתמש שמאחורי כל כתובת ומאפשר לכתוב חוקים בשפה של בני אדם: "אנשי ה-SOC ניגשים לניהול המתגים", "סטודנטים מקבלים גלישה בלבד". במדריך הזה נעבור צעד־צעד על שלוש שיטות רכישת הזהות — Captive Portal, Identity Agent ו-Identity Collector — בדיוק כפי שאנחנו מקימים אותן במעבדה של מכללת נטמי, כולל צילומי מסך מכל שלב.

IP הוא כתובת. Identity הוא הקשר. פיירוול שמכיר רק כתובות מגן על רשת; פיירוול שמכיר זהויות מגן על ארגון.

שלוש הדרכים של Check Point לזהות משתמש

▸Web Captive Portal — דף התחברות שאליו מופנה משתמש לא מזוהה. הוא מקליד שם משתמש וסיסמה, וה-IP שלו נקשר לזהות. מושלם לאורחים, ל-BYOD ולתחנות שאין עליהן שליטה.
▸Identity Agent — סוכן קטן שמותקן על התחנה, מזדהה מול הגייטוואי ברקע (בדרך כלל ב-Kerberos SSO) ומספק זהות רציפה גם כשהמשתמש לא פותח דפדפן.
▸Identity Collector — שירות שמותקן על שרת בדומיין (בדרך כלל ה-DC), קורא את יומן האירועים של Active Directory ומדווח לגייטוואי מי התחבר ומאיזו תחנה. בלי סוכן על התחנות, בלי הקלדה, בלי שהמשתמש ירגיש דבר.
▸AD Query — שיטה ותיקה שבה הגייטוואי עצמו מושך את אירועי ההזדהות מה-DC ב-WMI. עדיין נפוצה, אך ברוב הפריסות החדשות מוחלפת ב-Collector בגלל עומס ותאימות.

טופולוגיית המעבדה של מכללת נטמי: גייטוואי Check Point עם Identity Awareness, שלוש תחנות ובקר דומיין — טופולוגיית המעבדה: cpsg1 מזהה שלושה משתמשים בשלוש שיטות שונות — Portal, Agent ו-Collector.

בכל התרחישים במאמר נעבוד מול אותה סביבה: דומיין netme.local עם בקר NETME-DC01, גייטוואי בשם cpsg1 בגרסה R81.20, ורשת פנימית 10.0.2.0/24. המשתמשים שלנו יושבים ב-OU בשם NetMe Users.

שלב 1: הפעלת Identity Awareness על הגייטוואי

נכנסים ל-SmartConsole, פותחים את אובייקט הגייטוואי ומסמנים את Blade ה-Identity Awareness. האשף מבקש לבחור מאיפה תגיע הזהות. לצורך ההתחלה מסמנים AD Query ו-Browser-Based Authentication; את ה-Agent ואת ה-Collector נוסיף בהמשך.

מסך הפעלת Identity Awareness ב-SmartConsole עם AD Query ו-Browser-Based Authentication מסומנים — צילום מסך מהמעבדה של מכללת נטמי — בחירת מקורות הזהות על cpsg1.

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

הגדרת דומיין netme.local ופרטי חשבון עבור AD Query ב-Check Point — הגדרת הדומיין netme.local ובקר הדומיין NETME-DC01.

לאחר מכן מגדירים את כתובת ה-Captive Portal. זו הכתובת שאליה יופנו משתמשים לא מזוהים, ולכן היא חייבת להיות נגישה מהרשת הפנימית — בדרך כלל כתובת הממשק הפנימי של הגייטוואי.

הגדרת כתובת ה-Captive Portal בגייטוואי Check Point — כתובת ה-Portal מוגדרת על הממשק הפנימי שמשרת את רשת NetMe.

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

מסך Publish Changes ב-SmartConsole עם סיכום השינויים בגייטוואי — Publish — ורק אחר כך Install Policy.

שלב 2: Access Role — האובייקט שמחליף את ה-Subnet

Access Role הוא האובייקט שהופך זהות לחוק. הוא מורכב משלושה ממדים: מי המשתמש (משתמש, קבוצה או OU שלם), מאיזו רשת הוא מגיע, ומאיזו מכונה. אפשר לשלב את שלושתם — למשל "משתמש מקבוצת SOC, מרשת הניהול, ממחשב מצורף לדומיין" — וזה בדיוק המקום שבו מתחילה מדיניות אמיתית ברוח Zero Trust.

יצירת Access Role בשם NetmeUsers_OU שמצביע על ה-OU בשם NetMe Users — Access Role בשם NetmeUsers_OU, שמצביע על ה-OU בשם NetMe Users בדומיין netme.local.

צילום מסך של Active Directory Users and Computers עם המשתמשים ב-OU של NetMe — אלה המשתמשים שיקבלו גישה לאינטרנט — כל השאר ייתקלו בחוק ה-Cleanup.

עכשיו מכניסים את ה-Access Role לעמודת ה-Source בחוק. מרגע זה, המקור בחוק אינו רשת אלא זהות: כל מי שהגייטוואי זיהה כחבר ב-NetMe Users יקבל גישה, ולא משנה איזו כתובת IP קיבל היום מה-DHCP.

חוק מדיניות ב-SmartConsole שבו המקור הוא Access Role ולא כתובת IP — המקור בחוק 2 הוא זהות — לא Subnet ולא טווח כתובות.

שלב 3: Captive Portal — הזדהות דרך הדפדפן

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

דף ה-Captive Portal הממותג של NetMe עם שדות שם משתמש וסיסמה — ה-Captive Portal הממותג של מכללת נטמי — כך זה נראה למשתמש.

מסך אישור ב-Captive Portal שבו הכתובת נקשרה למשתמש בדומיין — אחרי ההזדהות, הכתובת 10.0.2.21 נקשרה למשתמש ember ולתפקיד NetmeUsers_OU.

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

לוגים ב-SmartConsole שמציגים את שם המשתמש ואת מקור הזהות Captive Portal — Logs & Monitor: אותה תעבורה, רק שעכשיו יש לה שם.

שלב 4: Identity Agent — זהות רציפה בלי הקלדה

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

הגדרת שרת בסוכן Identity Agent של Check Point עם כתובת הגייטוואי — הסוכן מופנה ל-cpsg1.

חלון הזנת פרטי דומיין בסוכן Identity Agent — בפעם הראשונה מזינים פרטי דומיין; לאחר מכן ה-SSO עושה את העבודה.

מסך סטטוס של Identity Agent שמראה חיבור מוצלח וזיהוי משתמש — סטטוס Connected: המשתמש yaniv.l והמכונה NETME-WS07 מזוהים מול הגייטוואי.

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

לוגים שמציגים זיהוי משתמש באמצעות Identity Agent — Identity Source = Identity Agent, בלי שהמשתמש עשה דבר.

שלב 5: Identity Collector — זהות בלי סוכן ובלי Portal

בארגונים גדולים אף אחד לא רוצה להתקין סוכן על אלפי תחנות. כאן נכנס ה-Collector: הוא יושב על שרת בדומיין, קורא את אירועי ההזדהות (4624, 4768, 4769) מיומן האבטחה של ה-DC ושולח לגייטוואי את הצמד משתמש–כתובת. קודם כול מגדירים בצד הגייטוואי מי רשאי להתחבר אליו ובאיזה סוד משותף.

הגדרת Identity Collector בצד הגייטוואי עם Trusted Client וסוד משותף — NETME-DC01 מוגדר כ-Trusted Client, עם Secret ייעודי — לא סיסמה שחוזרת בשירותים אחרים.

אחר כך מתקינים את ה-Collector על שרת בדומיין — התקנה קצרה של Next-Next-Finish.

סיום אשף ההתקנה של Check Point Identity Collector — צילום מסך מהמעבדה של מכללת נטמי — סיום התקנת ה-Identity Collector.

עכשיו מגדירים Identity Source — כלומר מאיפה ה-Collector קורא את אירועי ההזדהות.

הגדרת Identity Source מסוג Active Directory ב-Identity Collector — מקור הזהות: הדומיין netme.local, השרת 198.18.134.2 — ואימות מוצלח של ההרשאות.

יצירת Query ב-Identity Collector שאוסף את כל ההזדהויות בדומיין — ה-Query מגדיר אילו אירועים נאספים — כאן כל ההזדהויות בדומיין.

קישור ה-Query לגייטוואי Check Point בתוך Identity Collector — לבסוף מקשרים את ה-Query לגייטוואי — והסטטוס הופך ל-Connected.

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

לוגים שמציגים זיהוי משתמשים ממקור Identity Collector — שלושה משתמשים, שלוש תחנות, אפס התערבות של המשתמש.

אימות מהיר בשורת פקודה

כשמשהו לא עובד, אל תנחשו מול ה-GUI. שתי פקודות ב-Expert Mode פותרות את רוב המקרים: אחת שמציגה אילו זהויות הגייטוואי מכיר כרגע, ואחת שמראה אם ה-Collector בכלל מחובר.

cpsg1 — בדיקת זהויות

# אילו משתמשים מוכרים לגייטוואי כרגע
pdp monitor all

# בדיקת זהות של כתובת ספציפית
pdp monitor ip 10.0.2.112

# מצב החיבור מול Identity Collector
pdp connections idc

# ניקוי זהות תקועה (למשל אחרי החלפת משתמש על אותה תחנה)
pdp control revoke_ip 10.0.2.112

ארבע הפקודות שמלוות כל תקלת Identity Awareness בשטח.

פלט הפקודה pdp monitor all על גייטוואי Check Point עם שלוש זהויות — הפלט מהמעבדה: שלוש כתובות, שלושה משתמשים, שלוש שיטות זיהוי שונות.

ארבע טעויות שחוזרות בכל פריסה

▸חשבון Domain Admin לשירות — עבירה קלאסית. חשבון שירות עם הרשאות קריאה בלבד מספיק לחלוטין.
▸שכחו Install Policy. Publish שומר את השינוי במסד הניהול; רק התקנת מדיניות מעבירה אותו לגייטוואי.
▸זהות תקועה על כתובת. משתמש התנתק, מישהו אחר קיבל את אותה כתובת מה-DHCP וירש הרשאות. הגדירו Session Timeout הגיוני והכירו את revoke_ip.
▸Captive Portal לא נגיש. אם הכתובת שהגדרתם לא מנותבת מהרשת הפנימית, המשתמש פשוט יראה שגיאת דפדפן ולא יבין למה אין אינטרנט.

למה זה קריטי דווקא היום

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

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

מבחנון + הגרלה

מבחנון Identity Awareness — עשר שאלות

כל מי שמקבל 80 ומעלה נכנס אוטומטית להגרלה על קורס קורס Check Point במתנה. משאירים פרטים, עונים על השאלות — ואם עברתם, אתם בהגרלה.

תגיות ומילות מפתח

#Check_Point
#קורס_Check_Point
#קורס_צ׳ק_פוינט
#Identity_Awareness
#Access_Role
#Captive_Portal
#Identity_Agent
#Identity_Collector
#AD_Query
#Active_Directory
#SmartConsole
#R81.20
#אבטחת_מידע
#קורס_אבטחת_מידע
#מכללת_נטמי

רוצים להתמקצע?

הפוסט הזה הוא רק טעימה. הקורס המלא של Check Point Firewall ילמד אתכם הכל מא׳ עד ת׳.

לפרטים על הקורס ייעוץ בוואטסאפ