הבעיה שאתם כבר מכירים

אתם צריכים גישת RDP לתחנת SCADA. אולי זה HMI בתחנת שאיבה מרוחקת. אולי שרת Wonderware InTouch במתקן טיהור שפכים. אולי תחנת הנדסה Siemens PCS 7 במפעל כימי שספק צריך להגיע אליה לתחזוקה רבעונית.

ואתם יודעים מה קורה אחרי זה. מישהו מבקש מ-IT לפתוח פורט נכנס. IT מתנגדים. מגיעים לפשרה: רכיב VPN נכנס ל-IDMZ, פורט 443 נפתח פנימה, ומקימים jump server עם RDP. הספק מתחבר דרך ה-VPN, נוחת על ה-jump server, ומשם עושה RDP לתחנת ה-SCADA.

זה עובד. זה גם יוצר שטח תקיפה חשוף לאינטרנט שכל דוח מודיעין סייבר ב-2025 אומר שזה הווקטור הכי מנוצל בסביבות OT. חברת Dragos דיווחה שקבוצות ransomware השתמשו באופן עקבי בהרשאות תקפות כדי להתחבר לפורטלי VPN, ומשם ניצלו RDP, SMB ו-WinRM כדי לנוע לרוחב לעבר תחנות SCADA ו-HMI. חברת Claroty מצאה ש-82% מהפריצות המאומתות לסביבות OT ב-2025 השתמשו בכלי גישה מרחוק חשופים לאינטרנט – VNC, RDP דרך VPN, TeamViewer – כנקודת כניסה ראשונית. הכלים היו זמינים בחינם. המתקפות לא היו מתוחכמות. הפורטים היו פתוחים.

באוגוסט 2025, נתוני GreyNoise הראו כ-2,000 כתובות IP זדוניות שסרקו בו-זמנית נקודות קצה של Microsoft RD Web Access ו-RDP Web Client. עד אוקטובר 2025, חוקרים זיהו בוטנט של מעל 100,000 כתובות IP שביצע ניסיונות כניסה שיטתיים נגד שירותי RDP. וחולשה CVE-2025-48817 – פגיעות קריטית בצד הלקוח של RDP שנחשפה ביולי 2025 – הוכיחה שגם צד הלקוח של RDP הפך לווקטור תקיפה, לא רק צד השרת.

המאמר הזה מספק מדריך הגדרה צעד-אחר-צעד לאפשור גישת RDP מלאה למערכות SCADA בלי לפתוח שום פורט נכנס ב-firewall, בלי לפרוס VPN, ובלי לחשוף שום שירות לאינטרנט. הארכיטקטורה משתמשת בטכנולוגיית reverse-access – שבה הרכיב בצד ה-OT יוזם את כל החיבורים החוצה – כך שה-firewall נשאר ב-deny-all קבוע לתעבורה נכנסת.

איך RDP עם Reverse-Access נראה בפועל

ארכיטקטורה מסורתית (נכנסת)

[משתמש מרוחק] ← אינטרנט ← [Firewall: פורט 443 פתוח] ← [VPN ב-IDMZ] ← [Jump Server] ← [RDP ל-SCADA]

 

ה-firewall חייב לפתוח לפחות פורט נכנס אחד. רכיב ה-VPN חשוף לאינטרנט וניתן לגילוי. ל-jump server יש גישה ברמת רשת לאזור ה-SCADA. כל רכיב בשרשרת הזו הוא מטרה.

ארכיטקטורת Reverse-Access (יוצא בלבד)

[אזור SCADA] ← [Access Controller: HTTPS יוצא 443] ← [Access Gateway ב-DMZ] ← [משתמש מרוחק מזדהה כאן]

 

ה-Access Controller בתוך רשת ה-OT יוזם חיבור TLS יוצא אל ה-Access Gateway ב-DMZ. המשתמש המרוחק מזדהה ב-Gateway – זהות, MFA, מצב מכשיר – וה-Gateway מנתב את סשן ה-RDP המורשה דרך המנהרה היוצאת הקיימת אל תחנת ה-SCADA הספציפית. ה-firewall אף פעם לא פותח פורט נכנס. לרשת ה-SCADA אין כתובת IP ציבורית, אין שירות מאזין, ואין שטח תקיפה שניתן לגלות.

מה משתנה עבור מהנדסי ה-OT

מנקודת המבט של המשתמשים – כמעט כלום. אתם פותחים דפדפן או לקוח קל, מזדהים עם הפרטים שלכם + MFA, וסשן RDP מופיע לתחנת ה-SCADA הספציפית שאתם מורשים לגשת אליה. הסשן נראה ומרגיש כמו RDP רגיל. אתם יכולים לעבוד עם ה-HMI, להריץ אבחונים, לגשת לנתוני תהליך.

מה שמשתנה הוא הכל מאחורי הסשן: תחנת ה-SCADA בלתי נראית מהאינטרנט, הסשן ברמת אפליקציה ספציפית (לא ברמת רשת), וה-firewall נשאר ב-deny-all.

למה RDP לבד לא מספיק – ומה ארכיטקטורה רב-שכבתית פותרת

אבטחת גישת RDP ל-SCADA היא חלק אחד מבעיה גדולה יותר. ברוב סביבות ה-OT, הגבול בין IT ל-OT נושא שלושה סוגי תעבורה במקביל: סשנים אפליקטיביים אינטראקטיביים (RDP, SSH, HTTP), העברות קבצים (עדכוני קושחה, גיבויי הגדרות, ייצוא historian), ושיתוף קבצים דרך SMB בין תחנות הנדסה לאחסון משותף. לפתור רק את ה-RDP ולהשאיר את שני האחרים חשופים – משאיר פרצות שתוקפים מנצלים.

truePass Gravity נותן מענה לכך על ידי שילוב כל שלוש הפונקציות בפלטפורמה אחת שבנויה על ארכיטקטורת reverse-access. שכבה 1 (Reverse Access) מספקת את הבסיס של אפס פורטים נכנסים שהמאמר הזה מתאר – חיבורים יוצאים בלבד, firewall ב-deny-all קבוע, תשתית SCADA בלתי נראית. שכבה 2 (SMB Proxy) מתווכת שיתוף קבצים בין סביבות עם אימות Kerberos/NTLM, SMB Signing, הצפנה מקצה לקצה, וסריקת CDR משולבת. שכבה 3 (Zero Trust Application Access) מספקת את גישת ה-RDP, SSH ו-HTTP ברמת תחנה עם MFA, הקלטת סשנים, ובקרות הפניה מפורטות – כמתואר בשלבי ההגדרה בהמשך. שלוש השכבות חולקות מנוע מדיניות אחד, עקבות ביקורת אחידים, וקונסול ניהול אחד – וכך מבטלות את בעיית ה"טלאי על טלאי" שבה כלים נפרדים לקבצים, אפליקציות ומידור יוצרים פערים ביניהם.

השוואה מהירה: ארבע דרכים להגיע ב-RDP ל-SCADA – והמחירים שלהן

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

גישה	איך עובדת	פורטים נכנסים	סיכון תנועה רוחבית	הקלטת סשנים	בקרת גישת ספקים	המציאות בשטח
RDP ישיר	פורט 3389 פתוח לאינטרנט	1 (3389)	מוחלט – כל הרשת	אין	אין	התאבדות. אף פעם.
VPN + Jump Server	רכיב VPN ב-IDMZ, RDP מ-jump server	1+ (443/1194)	גבוה – ל-jump server יש גישת רשת L3	ידני (אם הוגדר)	הרשאות VPN משותפות, בלי מגבלת זמן	הסטנדרט היום. מנוצל כל הזמן.
Cloud ZTNA	ברוקר ענני מתווך גישה דרך connector	0 בצד OT	נמוך – ברמת אפליקציה	תלוי ספק	מדיניות per-user אפשרית	טוב, אבל כל התעבורה עוברת דרך ענן הספק
Reverse Access מקומי	connector ב-OT יוזם חיבור יוצא ל-gateway מקומי	0 – deny-all קבוע	אפס – בידוד ברמת תחנה	מובנה (וידאו + הקלדות)	חשבונות אישיים, מוגבלים בזמן, דורשים אישור	החזק ביותר לסביבות מוסדרות ומסווגות

למהנדסי OT בסביבות מוסדרות (אנרגיה, מים, ביטחון, ממשל) שבהן מידע לא יכול לעבור דרך תשתית ענן מסחרית – reverse access מקומי הוא הארכיטקטורה שמספקת גם את הצורך התפעולי (RDP ל-SCADA) וגם את דרישת האבטחה (אפס פורטים נכנסים, ביקורת סשנים מלאה, ללא תלות בענן).

הגדרה צעד-אחר-צעד

שלב 1: פרסו את ה-Access Controller בתוך רשת ה-OT

ה-Access Controller הוא רכיב קל שנפרס באזור ה-SCADA או ב-IDMZ. הוא לא מקבל חיבורים נכנסים. הוא יוזם חיבור HTTPS יוצא (פורט 443, TLS 1.2/1.3) אל ה-Access Gateway.

אפשרויות מיקום:

מיקום	מתי להשתמש	רמת אבטחה
בתוך אזור SCADA (רמה 3)	קרבה מקסימלית לתחנות היעד	החזקה ביותר – אין תעבורה נכנסת שמגיעה לרמה 3
ב-IDMZ (רמה 3.5)	כשמדיניות אזור SCADA אוסרת רכיבים חדשים	חזקה – יוצא מ-IDMZ, deny-all נכנס מ-IT
בסגמנט גישה ייעודי	כשמספר אזורי OT צריכים גישה	חזקה – סגמנט מבודד עם קישוריות יוצאת בלבד

דרישות:

• שרת Windows או מכונה וירטואלית Linux (משאבים מינימליים – 2 vCPU, 4 GB RAM בדרך כלל)
• קישוריות HTTPS יוצאת ל-Access Gateway (פורט 443 בלבד)
• לא נדרשים כללי firewall נכנסים
• קישוריות רשת לתחנות SCADA על פורט RDP 3389 (פנימי בלבד – אף פעם לא חשוף כלפי חוץ)

שלב 2: פרסו את ה-Access Gateway ב-DMZ

ה-Access Gateway יושב ב-DMZ או בקצה ענן. הוא הרכיב היחיד שנגיש מבחוץ – והוא משמש רק כנקודת זיהוי ואכיפת מדיניות. הוא לא מספק גישה ישירה לשום משאב OT.

הגדרה:

• נקודת קצה HTTPS ציבורית לזיהוי משתמשים
• חיבור לספק הזהויות של הארגון (Active Directory, Okta, Entra ID)
• אכיפת MFA (מפתח FIDO2, אפליקציית אימות, או טוקן חומרה)
• מנוע מדיניות שמגדיר כללי גישה ברמת משתמש ואפליקציה
• תעודות PKI ל-mutual TLS בין Gateway ל-Controller

שלב 3: הגדירו מדיניות גישה לכל תחנת עבודה

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

מבנה מדיניות לדוגמה:

רכיב מדיניות	ערך לדוגמה
משתמש / קבוצה	OT-Engineers-Shift-A (מ-AD)
אפליקציית יעד	RDP ל-SCADA-HMI-01 (192.168.10.50:3389)
זיהוי	הרשאת AD + מפתח FIDO2
מצב מכשיר	Windows 10/11, EDR פעיל, דיסק מוצפן, OS מעודכן ב-30 הימים האחרונים
חלון זמן	ראשון–חמישי, 06:00–22:00
משך סשן	עד 8 שעות, ניתוק אוטומטי אחרי 30 דקות חוסר פעילות
הקלטת סשן	מופעלת (וידאו + הקלדות)
הפניית Clipboard	מושבתת (אין העתק/הדבק בין מקומי למרוחק)
הפניית כוננים	מושבתת (אין העברת קבצים דרך כונני RDP ממופים)
הפניית מדפסות	מושבתת

מדיניות תחזוקת ספק (שונה ממדיניות עובד):

רכיב מדיניות	ערך ספק
משתמש	Vendor-Siemens-Tech-001 (חשבון אישי, לא משותף)
יעד	RDP ל-PCS7-ENG-WS-03 בלבד
זיהוי	הרשאת AD + SMS OTP (ספק לא יכול להשתמש ב-FIDO2)
חלון זמן	חלון תחזוקה מאושר מראש של 4 שעות בלבד
משך סשן	4 שעות, לא ניתן להארכה ללא אישור מחדש
הקלטת סשן	חובה (וידאו מלא + הקלדות + צילום מסך)
Clipboard / כוננים / מדפסות	הכל מושבת
תהליך אישור	דורש אישור מפקח OT לפני שהסשן מופעל

שלב 4: הקשיחו RDP על תחנת ה-SCADA

ארכיטקטורת reverse-access מאבטחת את נתיב החיבור, אבל גם תחנת ה-SCADA עצמה חייבת להיות מוקשחת ל-RDP:

• הפעילו Network Level Authentication (NLA): דורש זיהוי לפני שסשן ה-RDP מוקם – מונע צריכת משאבים ללא אימות.
• הגבילו גישת RDP לחשבונות ספציפיים: רק קבוצות ה-AD שממופות במדיניות הגישה צריכות זכויות כניסה RDP בתחנה.
• השביתו RDP על הממשק החיצוני: RDP צריך להאזין רק על ממשק הרשת הפנימי – הוא אף פעם לא חשוף לשום רשת מחוץ לאזור ה-SCADA.
• הגדירו מגבלות סשן: מספר סשנים מקסימלי, timeout בחוסר פעילות, ו-timeout לסשנים מנותקים – חייבים להתאים למדיניות הגישה.
• אכפו TLS לתעבורת RDP: הגדירו את התחנה לדרוש TLS 1.2+ לכל חיבורי RDP – ללא נסיגה ל-SSL/TLS ישנים.
• השביתו תכונות RDP שלא בשימוש: הפניית Clipboard, מיפוי כוננים, הפניית מדפסות, הפניית אודיו, והפניית פורטים סריאליים – הכל צריך להיות מושבת ברמת התחנה כהגנה בעומק (בנוסף לבקרות המדיניות).

שלב 5: הגדירו את ה-Firewall ל-Deny-All נכנס

ברגע שארכיטקטורת reverse-access עובדת:

• הסירו את כל כללי ה-firewall הנכנסים לאזור ה-SCADA שהיו בשימוש עבור VPN, RDP, או jump server
• הגדירו את מדיניות ברירת המחדל הנכנסת ל-deny-all ללא חריגים
• וודאו: רק HTTPS יוצא (443) מה-Access Controller ל-Access Gateway נשאר
• הריצו סריקה חיצונית (Shodan, Censys, Nmap) נגד טווח כתובות ה-IP של המתקן – וודאו אפס תוצאות

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

שלב 6: אמתו את הנתיב המלא

עברו על רצף הגישה המלא כדי לוודא:

• [ ] המשתמש מזדהה ב-Access Gateway עם הרשאות + MFA
• [ ] מצב המכשיר מאומת (מערכת הפעלה, EDR, הצפנה, רמת עדכונים)
• [ ] מנוע המדיניות מעריך את הבקשה מול כללים ברמת תחנה
• [ ] סשן RDP מוקם דרך המנהרה היוצאת לתחנת SCADA הספציפית
• [ ] הקלטת הסשן לוכדת את הסשן המלא (וידאו + הקלדות)
• [ ] הסשן מסתיים אוטומטית בהגעה למגבלת הזמן
• [ ] סשנים של ספקים דורשים תהליך אישור לפני הפעלה
• [ ] סריקה חיצונית מאשרת אפס שירותים גלויים בטווח ה-IP של המתקן
• [ ] עקבות ביקורת מראים רשומה מלאה: מי, מתי, איזו תחנה, אילו פעולות, משך סשן

מה אתם מרוויחים לעומת מה שאתם מפסידים

מימד	VPN + Jump Server	RDP עם Reverse-Access
פורטים נכנסים	1+ (VPN פורט 443 או 1194)	אפס
שירותים חשופים לאינטרנט	רכיב VPN + jump server	אין – בלתי נראה
גישת רשת לאחר זיהוי	כל אזור SCADA (רמה 3)	תחנת עבודה אחת ספציפית בלבד
סיכון תנועה רוחבית	גבוה – כל מכשיר ב-L3 נגיש	אין – הסשן מבודד ברמת אפליקציה
חשיפה לניחוש הרשאות	כניסת VPN חשופה לאינטרנט	הזיהוי ב-Gateway; ה-SCADA בלתי נראה
בקרת גישת ספקים	אותה מנהרת VPN כמו עובדים	מדיניות נפרדת, מוגבלת בזמן, מוקלטת, דורשת אישור
הקלטת סשנים	בדרך כלל לא זמינה	מובנית: וידאו, הקלדות, צילום מסך
בקרת Clipboard/כוננים	תלוי בהגדרת jump server	נאכפת ברמת שכבת הגישה
עקבות ביקורת	חלקי (לוגי VPN + לוגי RDP, מערכות שונות)	אחיד: עקבות ביקורת אחד לסשן עם הקשר מלא
דחיפות עדכון VPN	קריטית – חולשות VPN חשופות לאינטרנט מנוצלות בפועל	לא רלוונטי – אין VPN בארכיטקטורה
מה מפסידים	כלום מבחינה תפקודית	היכולת לסרוק את המתקן מהאינטרנט (זו המטרה)

תרחיש אמיתי: מתקן טיהור מים

מתקן: מתקן טיהור מים עירוני עם 3 תחנות SCADA (Wonderware InTouch), 12 בקרים (Allen-Bradley ControlLogix), ו-2 שרתי historian.

לפני: Cisco AnyConnect VPN עם TCP 443 פתוח נכנס. jump server אחד ב-IDMZ עם גישת RDP לכל 3 תחנות ה-SCADA. 4 חשבונות ספק שחולקים 2 הרשאות VPN. ללא הקלטת סשנים. קושחת VPN לא עודכנה 11 חודשים. סריקת Shodan הציגה 2 שירותים גלויים.

אחרי:

• Access Controller נפרס ב-IDMZ, HTTPS יוצא ל-Access Gateway
• 3 מדיניות ברמת תחנה: כל מהנדס OT מורשה רק לתחנת SCADA הספציפית שלו
• 4 חשבונות ספק אישיים עם הרשאות ייעודיות, MFA, וסשנים מוגבלים ל-4 שעות
• כל הסשנים מוקלטים עם וידאו מלא והקלדות
• הפניית Clipboard, כוננים ומדפסות מושבתת לכל סשנים של ספקים
• רכיב VPN הושבת. Jump server הושבת.
• Firewall מוגדר ל-deny-all נכנס – ללא חריגים
• סריקת Shodan: אפס תוצאות

ההשפעה התפעולית: מהנדסי OT מדווחים שחוויית ה-RDP זהה. זמן החיבור דומה (המנהרה היוצאת מוסיפה מילישניות בודדות של השהייה). ההבדל בלתי נראה למשתמשים – אבל שטח התקיפה החשוף לאינטרנט של המתקן בוטל.

טיפול בחששות נפוצים של מהנדסי OT

"אנחנו צריכים השהייה נמוכה לעבודה בזמן אמת עם SCADA"

מנהרת ה-TLS היוצאת מוסיפה 2–8 מילישניות השהייה בהתאם לנתיב הרשת. לעבודה עם HMI, שאילתות historian ופעולות אבחון – זה בלתי מורגש. לגבי לולאות בקרה בזמן אמת – אלו פועלות מקומית על ה-PLC ולא מושפעות מארכיטקטורת הגישה מרחוק בכלל. הסשן המרוחק מיועד לניטור והגדרה, לא לבקרת לולאה סגורה.

"ספק ה-SCADA שלנו אומר שהוא צריך RDP ישיר"

הוא צריך RDP לתחנת העבודה. הוא לא צריך פורט נכנס ב-firewall שלכם. ארכיטקטורת reverse-access מספקת לספק סשן RDP רגיל – מנקודת המבט שלו, זה נראה ומתנהג בדיוק כמו חיבור דרך VPN. ההבדל הוא שהחיבור מתווך דרך מנהרה יוצאת במקום דרך פורט נכנס. לקוח ה-RDP של הספק עובד כרגיל.

"אנחנו צריכים להעביר קבצים לתחנת SCADA במהלך תחזוקה"

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

"מה אם החיבור היוצא נופל באמצע חלון תחזוקה קריטי?"

הסשן נסגר. תחנת ה-SCADA חוזרת למצב הפעולה הרגיל שלה – היא לא תלויה בסשן המרוחק לבקרת תהליכים. מהנדס ה-OT מזדהה מחדש ומתחבר מחדש. עיצוב fail-closed אומר ששיבוש בקישוריות לא יכול ליצור פתח ב-firewall או להשאיר סשן במצב לא מבוקר.

"מבקר העמידה שלנו רוצה לראות מי ניגש לאיזו תחנת SCADA ומתי"

עקבות הביקורת האחידים מתעדים כל סשן עם: זהות המשתמש (חשבון אישי, לא משותף), שיטת הזיהוי ומצב המכשיר בזמן הגישה, כתובת IP ושם מארח של תחנת היעד, זמני התחלה וסיום ומשך הסשן, הקלטת וידאו מלאה עם הקלדות, והמדיניות הספציפית שאישרה את הסשן. זה הרבה יותר מלא מהפיצול בין לוג VPN + Windows Event Log + לוג jump server שרוב המבקרים עובדים איתם היום.

התאמה ל-IEC 62443

דרישת IEC 62443	איך הארכיטקטורה הזו עונה עליה
FR1 – זיהוי ואימות	MFA לכל סשן עם אימות מצב מכשיר לפני כל חיבור RDP
FR2 – בקרת שימוש	מדיניות גישה ברמת תחנה עם אכיפת הרשאות מינימליות – כל משתמש ניגש רק לתחנת SCADA שהוא מורשה אליה
FR3 – שלמות מערכת	הקלטת סשנים לוכדת את כל הפעולות; השבתת הפניית Clipboard/כוננים מונעת הכנסת קבצים לא מורשים
FR4 – סודיות מידע	הצפנת TLS 1.2/1.3 על המנהרה היוצאת; תעבורת RDP מוצפנת מקצה לקצה
FR5 – הגבלת זרימת מידע	חיבור יוצא בלבד; אין זרימת מידע נכנסת לאזור SCADA; נתיבי גישה מבודדים
FR6 – תגובה בזמן	עקבות ביקורת אחידים עם רשומות לכל סשן; שילוב SIEM דרך Syslog
FR7 – זמינות משאבים	אין שטח תקיפה נכנס = אין וקטור DDoS; אפס שירותים גלויים

צ'קליסט פריסה

לפני הפריסה

• [ ] מפו כל תחנת SCADA שדורשת גישת RDP מרחוק
• [ ] תעדו כל משתמש (פנימי + ספק) שצריך גישת RDP ולאיזו תחנה ספציפית
• [ ] רשמו את כללי ה-firewall הנכנסים הנוכחיים עבור VPN/RDP/jump server
• [ ] וודאו שתעבורת HTTPS יוצאת (443) מותרת מה-IDMZ או אזור ה-SCADA ל-DMZ

פריסה

• [ ] פרסו Access Controller (IDMZ או אזור SCADA)
• [ ] פרסו Access Gateway (DMZ)
• [ ] הקימו מנהרת TLS יוצאת בין Controller ל-Gateway
• [ ] חברו Gateway ל-Active Directory / ספק זהויות
• [ ] הגדירו MFA (מפתח FIDO2 או אפליקציית אימות)
• [ ] צרו מדיניות גישה ברמת תחנה לכל משתמש/קבוצה
• [ ] צרו מדיניות ספקים מוגבלת בזמן עם תהליכי אישור
• [ ] הפעילו הקלטת סשנים לכל הסשנים
• [ ] השביתו הפניית Clipboard, כוננים ומדפסות במדיניות
• [ ] הקשיחו RDP בכל תחנת SCADA (NLA, TLS, מגבלות סשן)

מעבר

• [ ] בדקו את נתיב הגישה המלא: זיהוי ← מדיניות ← סשן RDP ← הקלטה ← סגירה
• [ ] בדקו תהליך ספק: אישור ← זיהוי ← סשן מוגבל בזמן ← פקיעה אוטומטית
• [ ] הסירו כללי firewall נכנסים של VPN
• [ ] הסירו כללי firewall נכנסים של jump server
• [ ] הגדירו ברירת מחדל של firewall ל-deny-all נכנס – ללא חריגים
• [ ] השביתו רכיב VPN ו-jump server

אימות

• [ ] סריקה חיצונית (Shodan, Censys, Nmap) – וודאו אפס תוצאות
• [ ] מבדק חדירה ממוקד בנתיבי גישה מרחוק ל-SCADA
• [ ] בדיקת עקבות ביקורת: וודאו שלמות רשומות סשנים
• [ ] תיעוד עמידה: מיפוי IEC 62443 FR, דגימות הקלטות סשנים, ייצוא כללי firewall

סיכום

אתם צריכים RDP ל-SCADA. ה-firewall צריך להישאר סגור. אלה לא דרישות סותרות – שתיהן ניתנות למימוש עם ארכיטקטורת reverse-access שהופכת את כיוון החיבור כך שרשת ה-OT יוזמת את כל התקשורת החוצה.

סשן ה-RDP זהה מנקודת המבט של המשתמשים. החוויה של הספק לא משתנה. תחנת ה-SCADA ממשיכה לעבוד כרגיל. מה שנעלם הוא שטח התקיפה החשוף לאינטרנט – רכיב ה-VPN, ה-jump server, הפורט הנכנס, וכל קטגוריית המתקפות שתלויה בקיומם.

82% מהפריצות לסביבות OT ב-2025 השתמשו בגישה מרחוק חשופה לאינטרנט כנקודת כניסה. סגירת הפורט הנכנס סוגרת את נקודת הכניסה הזו. סשן ה-RDP ממשיך. המתקפות לא.