למה CISOs מעריכים מחדש ארכיטקטורות Data Diode ב-2026?
שוק ה-Data Diode צפוי להגיע ל-1.37 מיליארד דולר ב-2026, בצמיחה של 11.2% CAGR. ארגונים קונים יותר דיודות, לא פחות. אז למה CISOs מתכננים במקביל מיגרציות הרחק מארכיטקטורות מרכזיות-דיודה?
כי הדיודה היא לא הבעיה. הטלאים סביבה – כן.
Dragos עקבו אחרי 119 קבוצות ransomware שתקפו ארגונים תעשייתיים ב-2025 – עלייה של 64% מ-80 קבוצות ב-2024. הקבוצות האלו לא תקפו Data Diodes. הן תקפו את רכיבי ה-VPN, ה-jump servers, וכלי הגישה מרחוק שארגונים פורסים לצד דיודות כי הדיודה לא מסוגלת לטפל בסשנים אינטראקטיביים, שיתוף קבצים דו-כיווני, או גישת ספקים מרחוק. דוח האיומים של Waterfall לשנת 2026 תיעד 57 מתקפות סייבר שגרמו לתוצאות פיזיות בתעשייה כבדה ב-2025. אירוע ה-ransomware של Jaguar Land Rover בספטמבר 2025 השבית את הייצור הגלובלי ליותר מחודש בעלות מדווחת של 2.5 מיליארד דולר.
מדריך ה-CISO למיגרציה מ-Data Diode הוא לא על נטישת עקרונות האבטחה שדיודות מייצגות. הוא על הרחבת העקרונות האלו – אפס פורטים נכנסים, תשתית בלתי נראית, deny-all כברירת מחדל – אל 70%–80% מקישוריות IT/OT שדיודות מבנית לא מסוגלות לטפל בהן.
המדריך הזה מספק תוכנית ביצוע שבוע-אחר-שבוע להשלמת המיגרציה ב-6 חודשים, עם הפעלה מקבילה, קריטריוני rollback בכל שלב, ומדדי הצלחה מדידים.
איך נראה המצב הנוכחי ברוב הארגונים?
לפני שבונים תוכנית מיגרציה, CISOs צריכים מלאי כנה של מה שבאמת פרוס בגבול IT/OT. ברוב ארגוני התשתיות הקריטיות, התמונה כוללת:
שכבת הדיודה – מטפלת בזרימות מידע חד-כיווניות: שכפול historian, העברת syslog, טלמטריית SCADA לאנליטיקה ארגונית. זה עובד. הפיזיקה תקינה. זה נשאר עד שמוכיחים שאפשר להחליף.
השכבה המשלימה – כל מה שהדיודה לא מסוגלת לטפל בו:
מוצר | מה מטפל | למה קיים | סיכון אבטחתי |
רכיב VPN | גישת עובדים וספקים מרחוק | דיודה לא תומכת בסשנים אינטראקטיביים | הווקטור המנוצל ביותר ב-OT (Claroty: 82% מפריצות OT) |
Jump server | RDP ל-SCADA, historian, תחנות הנדסה | VPN נותן גישת רשת; jump server מספק RDP | מאפשר תנועה רוחבית – גישת רשת לאזור SCADA |
SMB proxy / שער קבצים | שיתוף קבצים דו-כיווני (קושחה, הגדרות, משלוחי ספקים) | דיודה חד-כיוונית; קבצים חייבים לזרום לשני הכיוונים | מוצר נפרד, לוגים נפרדים, מדיניות נפרדת |
מחברי TCP נקודתיים | אינטגרציות אפליקטיביות ספציפיות | כל אפליקציה דו-כיוונית צריכה מחבר משלה | לרוב לא מתועדים, לא מנוטרים, מוטמעים במוצרי ספקים |
שכבת הפערים – קישוריות שקיימת אבל אף אחד לא אחראי עליה: מנהרות ספקים מוטמעות, סשנים SSH קבועים שהיו "זמניים" לפני שלוש שנים, חיבורי TCP ישירים בין אפליקציות IT למסדי נתונים ב-OT ללא מדיניות גישה.
מדריך ה-CISO למיגרציה מ-Data Diode מתחיל בתיעוד כל שלוש השכבות – לא רק שתי הראשונות.
אפשר לעשות מיגרציה מ-Data Diodes ל-Zero Trust בלי השבתה?
כן. המיגרציה מתוכננת כהפעלה מקבילה – הדיודה והפלטפורמה רצות במקביל לאורך כל התהליך. בשום שלב ה-CISO לא מסיר בקרת אבטחה לפני שההחלפה שלה הוכחה תפעולית. הדיודה ממשיכה לטפל בזרימות חד-כיווניות ללא שינוי בזמן שהפלטפורמה לוקחת אחריות על גישה אינטראקטיבית, שיתוף קבצים וקישוריות ספקים.
המיגרציה היא לא cutover. היא העברה הדרגתית של סוגי קישוריות ממוצרים משלימים (VPN, jump server, SMB proxy, מחברי TCP) לפלטפורמה המאוחדת – כשהדיודה נשמרת לזרימות חד-כיוויות מוסדרות.
מה התנאים המקדימים לפני שמתחילים?
יש לכם מפת קישוריות מלאה?
רוב ה-CISOs מגלים שהקישוריות IT/OT שלהם גדולה ב-30%–50% ממה שמתועד. לפני שמתחילים את המיגרציה, השלימו מלאי קישוריות שמכסה:
- כל כלל firewall שמתיר תעבורה נכנסת לאזורי OT (לא רק הכללים שאתם מכירים – ייצאו את כל סט הכללים)
- כל מנהרת VPN שמסתיימת ב-OT או קרוב אליו
- כל jump server עם גישת RDP או SSH למשאבי OT
- כל מנגנון העברת קבצים: שיתופי SMB, שרתי SFTP, סקריפטים של SCP, העברות USB ידניות
- כל מחבר ספק מוטמע או סשן קבוע
- כל חשבון משתמש ושירות עם גישה למשאבי OT
המלאי הזה לוקח בדרך כלל 2–3 שבועות ומייצר הפתעות. סקר ICS/OT של SANS לשנת 2025 מצא ש-40% מאירועי אבטחת OT גרמו להפרעה תפעולית – ורבים מאירועים אלו נכנסו דרך נתיבי קישוריות שהארגון לא ידע שקיימים.
יש לכם חסות הנהלה?
המיגרציה נוגעת בתשתית IT (VPN), בתפעול OT (גישה ל-SCADA), בניהול ספקים (גישת צד שלישי), בעמידה רגולטורית (עקבות ביקורת), וברכש (איחוד ספקים). ללא חסות ברמת C – בדרך כלל CISO עם תמיכת CIO – החלטות חוצות-ארגון ייתקעו.
זיהיתם את המגבלות הרגולטוריות?
לכל זרימת מידע חד-כיוונית שמטופלת כרגע על ידי הדיודה, קבעו האם הרגולציה הרלוונטית מחייבת אכיפה חד-כיוונית פיזית או רק דורשת העברת מידע יוצא עם בקרות מתאימות. ההבחנה הזו קובעת אילו זרימות יכולות לעבור לפלטפורמה ואילו חייבות להישאר על הדיודה.
דרישה רגולטורית | דיודה פיזית מחויבת? | מתאים לפלטפורמה? |
NRC RG 5.71 (גרעיני) | כן – חד-כיוונית מאוכפת בחומרה | לא – לשמור דיודה |
IEC 62443 SL4 (איום ברמת מדינה) | כן – בידוד פיזי נדרש | לא – לשמור דיודה |
IEC 62443 SL3 (תוקף מסור) | לא – בידוד לוגי מספיק | כן |
NIST SP 800-82 Rev. 3 (מידור OT) | לא – ממליץ על דיודות, לא מחייב | כן – reverse-access עומד בדרישות מידור |
NERC CIP (אנרגיה) | לא – דורש בקרות גישה אלקטרוניות | כן |
NIS2 (גופים חיוניים באירופה) | לא – דורש בקרות גישה מבוססות סיכון | כן |
DoD DTM 25-003 (Zero Trust ל-OT) | לא – מחייב יישום Zero Trust |
ברוב הארגונים, 80%–90% מזרימות קישוריות IT/OT מתאימות לפלטפורמה. ה-10%–20% הנותרים נשארים על הדיודה כי הרגולציה דורשת את זה.
ה-Playbook ל-6 חודשים: ביצוע שבוע-אחר-שבוע
חודש 1: בניית תשתית (שבועות 1–4)
מה קורה בחודש 1?
חודש 1 הוא הערכה ופריסה – שום תעבורת ייצור לא עוברת לפלטפורמה עדיין. המטרה היא לפרוס את התשתית, לשלב זהויות ולאמת קישוריות בתצורת בדיקה.
שבועות 1–2: פריסת תשתית
משימה | פרטים | קריטריון הצלחה |
פריסת Access Controller | IDMZ או אזור SCADA; HTTPS יוצא בלבד | Controller מקים מנהרת TLS יוצאת ל-Gateway |
פריסת Access Gateway | DMZ; HTTPS ציבורי לזיהוי | Gateway נגיש לזיהוי; אין כללים נכנסים ל-OT |
הגדרת PKI | Mutual TLS בין Controller ל-Gateway | אמון מבוסס תעודות מוקם; ללא תעודות self-signed בייצור |
אימות firewall | וודאו שלא נוצרו כללים נכנסים חדשים | ייצוא כללי firewall תואם baseline – יוצא 443 בלבד |
שבוע 3: שילוב זהויות
חברו את ה-Access Gateway לספק הזהויות של הארגון (Active Directory, Okta, Entra ID). מפו קבוצות משתמשים קיימות למדיניות גישה למשאבי OT. הגדירו MFA (מפתח FIDO2 מועדף; אפליקציית אימות כגיבוי; SMS OTP לספקים שלא יכולים להשתמש בטוקנים).
שבוע 4: תצורת בדיקה
הגדירו 3–5 סשנים של RDP למשאבי OT שאינם ייצור (תחנת SCADA לבדיקות, מופע historian לפיתוח). אמתו את הנתיב המלא: זיהוי ← MFA ← בדיקת מצב מכשיר ← הערכת מדיניות ← סשן RDP ← הקלטת סשן ← סגירה אוטומטית במגבלת הזמן. אל תיגעו בתעבורת ייצור עדיין.
קריטריוני rollback לחודש 1: אם לא ניתן להקים את המנהרה היוצאת ללא פתיחת כללי firewall נכנסים – עצרו ותקנו. אם שילוב MFA נכשל עם ספק הזהויות – עצרו ותקנו. הפלטפורמה חייבת לעבוד עם אפס פורטים נכנסים, אחרת המיגרציה לא ממשיכה.
חודש 2: מיגרציית גישה אינטראקטיבית (שבועות 5–8)
מה הרכיב בעל הסיכון הגבוה ביותר שמחליפים קודם?
רכיב ה-VPN – כי הוא חשוף לאינטרנט, הוא הווקטור הראשוני המרכזי ל-ransomware בסביבות OT, והסרתו מייצרת את הצמצום הגדול ביותר בשטח תקיפה.
שבועות 5–6: העברת גישת RDP/SSH של עובדים
העבירו סשנים אינטראקטיביים של עובדים (RDP לתחנות SCADA, SSH לשרתי הנדסה, HTTP ליישומי web פנימיים) מהנתיב VPN + jump server לפלטפורמה. מדיניות ברמת תחנה מחליפה גישת VPN ברמת רשת. כל סשן דורש עכשיו זהות אישית + MFA + מצב מכשיר + הקלטת סשן.
סוג סשן | לפני (VPN + Jump Server) | אחרי (פלטפורמה) |
RDP ל-SCADA-HMI-01 | VPN ← jump server ← RDP (ברמת רשת) | RDP ישיר דרך מנהרה יוצאת (ברמת אפליקציה) |
SSH ל-ENG-SERVER-03 | VPN ← jump server ← SSH (ברמת רשת) | SSH ישיר דרך מנהרה יוצאת (ברמת אפליקציה) |
HTTP ליישום web פנימי | VPN ← דפדפן (ברמת רשת) | HTTPS ישיר דרך מנהרה יוצאת (ברמת אפליקציה) |
שבוע 7: העברת גישת ספקים
גישת ספקים דורשת מדיניות שונה מעובדים: חשבונות אישיים (לא משותפים), חלונות זמן מאושרים מראש, הקלטת סשנים חובה, תהליכי אישור, וסגירה אוטומטית בגבול חלון התחזוקה.
שבוע 8: השבתת VPN ו-Jump Server
ברגע שכל הסשנים האינטראקטיביים עוברים דרך הפלטפורמה:
- הסירו כללי firewall נכנסים של VPN
- השביתו רכיב VPN
- הסירו כללי firewall נכנסים של jump server
- השביתו jump server
- הריצו סריקה חיצונית (Shodan, Censys) – וודאו אפס שירותים גלויים
קריטריוני rollback לחודש 2: אם משתמש כלשהו לא מצליח להקים סשן RDP דרך הפלטפורמה בסף השהייה מקובל (בדרך כלל < 10ms נוספים), ה-VPN נשאר פעיל עבור אותו משתמש עד לפתרון. Rollback הוא ברמת משתמש, לא ברמת מערכת.
מדדי הצלחה בסוף חודש 2:
מדד | יעד |
מדד חשיפת פורטים נכנסים | ירד ב-60%–80% (פורטים של VPN ו-jump server הוסרו) |
סטטוס רכיב VPN | הושבת |
סטטוס jump server | הושבת |
כיסוי שיוך סשנים | 90%+ לסשנים אינטראקטיביים |
תוצאות סריקה חיצונית | אפס שירותים גלויים הקשורים ל-VPN או jump server |
חודשים 3–4: מיגרציית שיתוף קבצים (שבועות 9–16)
איך מעבירים שיתוף קבצים דו-כיווני בלי לשבש תפעול?
מיגרציית שיתוף קבצים היא השלב הרגיש ביותר תפעולית כי הוא נוגע בתהליכי עבודה יומיומיים: עדכוני קושחה, גיבויי הגדרות, משלוחי ספקים, חילופי מסמכי הנדסה. נתיב המיגרציה הוא מקבילי: ה-SMB Proxy של הפלטפורמה רץ לצד שער הקבצים הקיים 4 שבועות לפני המעבר.
שבועות 9–10: הגדרת SMB Proxy על הפלטפורמה
הגדירו את ה-SMB Proxy המשולב בפלטפורמה עם אימות Kerberos/NTLM, SMB Signing, הצפנה מקצה לקצה, וסריקת CDR (Content Disarm & Reconstruction). מפו שיתופי SMB קיימים ל-proxy החדש.
שבועות 11–12: הפעלה מקבילה
גם שער הקבצים הקיים וגם ה-SMB Proxy של הפלטפורמה פועלים בו-זמנית. העברות קבצים חדשות עוברות דרך הפלטפורמה. העברות אוטומטיות קיימות ממשיכות על השער הישן. עקבו אחר בעיות תאימות, הבדלי ביצועים, והשפעת סריקת CDR על שלמות קבצים.
שבועות 13–14: מעבר
העבירו את שאר העברות הקבצים לפלטפורמה. הגישה התלת-שכבתית לאבטחת קישוריות IT-to-OT מטפלת עכשיו גם בסשנים אינטראקטיביים (שכבה 3) וגם בשיתוף קבצים (שכבה 2) דרך פלטפורמה אחת.
שבועות 15–16: השבתת שער קבצים ישן
הסירו SMB proxy / שער קבצים עצמאי. עדכנו כללי firewall. וודאו שכל העברות הקבצים עוברות בהצלחה דרך הפלטפורמה עם סריקת CDR, הצפנה ועקבות ביקורת מלאים.
קריטריוני rollback לחודשים 3–4: אם סריקת CDR פוגעת בסוג קובץ ספציפי שקריטי לתפעול (פורמטים קנייניים מסוימים של הגדרות SCADA), צרו כלל חריג ל-CDR עבור אותו סוג קובץ עם בקרות מפצות (סריקת אנטי-וירוס בלבד) – במקום לבטל את כל המיגרציה.
חודש 5: הערכת זרימות חד-כיוויות (שבועות 17–20)
האם כדאי להחליף את הדיודה עבור שכפול historian והעברת syslog?
זו החלטה מקרה-למקרה על בסיס דרישות רגולטוריות. לכל זרימה חד-כיוונית שנמצאת כרגע על הדיודה, העריכו:
שאלה | אם כן | אם לא |
האם הרגולציה מחייבת אכיפה חד-כיוונית פיזית לזרימה הזו? | שמרו דיודה לזרימה הזו | המשיכו להערכה |
האם ארכיטקטורת ה-outbound-only של הפלטפורמה מספקת אבטחה שקולה? | העבירו לפלטפורמה | שמרו דיודה |
האם העברה לפלטפורמה מוסיפה בקרת גישה מבוססת זהות וביקורת אחידה? | טיעון חזק למיגרציה | טיעון חלש – העריכו תועלת תפעולית |
לשכפול historian והעברת syslog – שבהם הדרישה היא העברת מידע יוצא, לא חד-כיווניות פיזית – ארכיטקטורת reverse-access של הפלטפורמה מספקת בדרך כלל הגנה שקולה עם היתרון הנוסף של זהות, מדיניות וביקורת אחידה. רוב הארגונים מעבירים את הזרימות האלו.
למידע בטיחות גרעיני (RG 5.71) ומידע מסווג ביטחוני (SL4) – שמרו את הדיודה. זה לא אופציונלי. הרגולציה מחייבת זרימה חד-כיוונית מאוכפת בחומרה.
חודש 6: מצב יציב והקשחה (שבועות 21–24)
איך נראה מצב הקצה?
סוג קישוריות | איפה רץ | בקרות אבטחה |
סשנים אינטראקטיביים (RDP, SSH, HTTP) | פלטפורמה | זהות אישית + MFA + מצב מכשיר + מדיניות ברמת תחנה + הקלטת סשן |
שיתוף קבצים דו-כיווני (SMB) | פלטפורמה | Kerberos/NTLM + SMB Signing + הצפנה + סריקת CDR + עקבות ביקורת |
שכפול historian (לא מוסדר) | פלטפורמה | העברה יוצאת בלבד + זהות + ביקורת אחידה |
העברת syslog (לא מוסדרת) | פלטפורמה | העברה יוצאת בלבד + ביקורת אחידה |
זרימות חד-כיווניות גרעיניות/ביטחוניות (מוסדרות) | Data Diode | חד-כיוונית מאוכפת בחומרה – ללא שינוי |
שבועות 21–22: הקשחה סופית
- הגדירו את כל firewalls של אזורי OT ל-deny-all נכנס – ללא חריגים מעבר לזרימות המוסדרות של הדיודה
- הריצו סריקה חיצונית מקיפה על כל טווחי כתובות ה-IP של המתקנים – יעד: אפס שירותים גלויים
- מבדק חדירה ממוקד בקישוריות גבול IT/OT
- אמתו שלמות הקלטות סשנים לכל סוג קישוריות
שבועות 23–24: תיעוד ועמידה רגולטורית
- השלימו מיפוי IEC 62443 FR לכל סוגי הקישוריות
- תעדו את ההחלטה הרגולטורית לכל זרימה (פלטפורמה לעומת שמירת דיודה)
- ייצאו דגימות עקבות ביקורת אחידים לסוקרי עמידה
- סיימו את המצגת לדירקטוריון: מצב נוכחי ← מצב יעד ← ראיות מיגרציה ← שיפורי KPI
מה הכשלונות הנפוצים ביותר במיגרציה ואיך מונעים אותם?
כשלון 1: מלאי קישוריות חלקי
מה משתבש: תוכנית המיגרציה מכסה מנהרות VPN ו-jump servers ידועים אבל מפספסת מחברי ספק מוטמעים, סשנים SSH קבועים, וחיבורי מסד נתונים ישירים. אחרי השבתת VPN, נתיבי ה-"קישוריות הצל" האלו נשארים – לא מנוטרים ולא מוגנים.
איך מונעים: בשבוע 1, ייצאו את כל סט כללי ה-firewall (לא רק הכללים שאתם מכירים) והריצו ניתוח זרימות רשת פנימי למשך 7 ימים כדי ללכוד את כל החיבורים הפעילים שחוצים את גבול IT/OT. כל זרימה שמופיעה בניתוח התעבורה אבל לא במלאי המתועד היא פער מיגרציה.
כשלון 2: התנגדות ספקים לחשבונות אישיים
מה משתבש: ספקים מסרבים להשתמש בחשבונות אישיים כי הטכנאים שלהם מתחלפים תדיר. הם מתעקשים על הרשאות משותפות "כמו תמיד." ה-CISO מתפשר, וגישת הספקים נשארת לא משויכת.
איך מונעים: כתבו את דרישת החשבון האישי בחידוש חוזה הספק. ספקו לספק פורטל שירות עצמי להקמת חשבונות אישיים. אם הספק לא מסוגל לעמוד בדרישה, העבירו את זה לניהול ספקים – לא לחריג הרשאות משותפות.
כשלון 3: השארת VPN "ליתר ביטחון"
מה משתבש: אחרי העברת כל הסשנים האינטראקטיביים לפלטפורמה, רכיב ה-VPN נשאר דולק עם כללי ה-firewall הנכנסים שלו כי מישהו "לא בטוח" שכל הסשנים הועברו. שטח התקיפה נשאר.
איך מונעים: קריטריון ההצלחה לחודש 2 מפורש: סריקה חיצונית מאשרת אפס שירותים גלויים. אם ה-VPN עדיין רץ, הסריקה תמצא אותו. תנו לסריקה להיות הסמכות להחלטה, לא לתחושת הנוחות של הצוות.
כשלון 4: דילוג על CDR בהעברות קבצים
מה משתבש: סריקת CDR מושבתת במהלך מיגרציית שיתוף הקבצים כי היא "מאטה העברות" או "פוגעת בסוגי קבצים מסוימים." קבצים נכנסים לאזור OT בלי סריקה.
איך מונעים: בדקו תאימות CDR עם כל סוגי קבצי OT בשלב ההפעלה המקבילה (שבועות 11–12). צרו כללי חריג צרים לסוגי קבצים ספציפיים שדורשים סריקה חלופית – אל תשביתו CDR באופן גורף.
כשלון 5: אין תוכנית rollback לכל שלב
מה משתבש: המיגרציה מתוכננת כתהליך חד-כיווני. כשבעיה צצה בחודש 3, לצוות אין דרך מתועדת לחזור למצב הקודם בלי לפרוס מחדש תשתית שהושבתה.
איך מונעים: לכל שלב יש קריטריוני rollback מפורשים שמוגדרים לפני הביצוע. הגדרות VPN ו-jump server שהושבתו נשמרות בארכיון (לא נמחקות) למשך 90 יום. הדיודה ממשיכה לפעול ללא שינוי לאורך כל התהליך – היא תמיד זמינה כגיבוי לזרימות חד-כיוויות.
איך מודדים הצלחת מיגרציה?
דשבורד: לפני ואחרי
KPI | לפני מיגרציה | אחרי מיגרציה (חודש 6) | שינוי |
מדד חשיפת פורטים נכנסים | 18+ | 0 (פלטפורמה) + פורטים ייעודיים לדיודה בלבד | -95%+ |
מספר ספקים | 4–6 | 1–2 (פלטפורמה + דיודה אם נשמרת) | -70% |
מוצרים שמנהלים קישוריות IT/OT | 5+ (דיודה, VPN, jump server, SMB proxy, מחברי TCP) | 1–2 | -70% |
כיסוי שיוך סשנים | 40–60% (פערים בספקים ומערכות ישנות) | 95%+ | +50 נקודות |
MTTI-OT (זמן חקירה) | 3–4 שעות | < 15 דקות | -95% |
כיסוי Zero Trust | 30–40% | 90%+ | +55 נקודות |
סריקה חיצונית: שירותי OT גלויים | 2–5 שירותים | 0 | -100% |
מקורות לוג SIEM לקישוריות IT/OT | 4–6 פורמטים נפרדים | פיד Syslog אחד | -80% |
איך מציגים את זה לדירקטוריון?
שלושה שקפים:
שקף 1 – לפני: תרשים שמראה דיודה + 4 מוצרים משלימים, 5 ספקים, 5 שטחי תקיפה, לוגים מפוזרים. כללו את טבלת העלויות: הוצאה שנתית כוללת על כל המוצרים ועבודת אינטגרציה.
שקף 2 – אחרי: תרשים שמראה פלטפורמה + דיודה (נשמרת רק שם שמחויב), 1–2 ספקים, שטח תקיפה אחד עם אפס פורטים נכנסים, ביקורת אחידה. כללו את השוואת העלויות המאוחדת.
שקף 3 – ראיות: דשבורד KPI שמראה ערכים לפני/אחרי לכל המדדים. תוצאות סריקה חיצונית. דגימת הקלטת סשן. מיפוי עמידה רגולטורית.
הדירקטוריון לא צריך תרשימי ארכיטקטורה טכניים. הם צריכים: פחות ספקים, עלות נמוכה יותר, שטח תקיפה קטן יותר, חקירות מהירות יותר, התקדמות עמידה מדידה.
שאלות נפוצות
כמה זמן המיגרציה באמת לוקחת?
לוח הזמנים של 6 חודשים מכסה מהערכה ועד מצב יציב. השלב בעל הסיכון הגבוה ביותר (השבתת VPN ו-jump server) מסתיים בחודש 2. מיגרציית שיתוף קבצים מסתיימת בחודש 4. שני החודשים הנותרים מיועדים להערכת זרימות חד-כיוויות והקשחה. ארגונים עם פחות סוגי קישוריות או ארכיטקטורות פשוטות יותר יכולים לדחוס ל-4 חודשים; ארגונים עם סביבות רגולטוריות מורכבות עשויים להאריך ל-9 חודשים עבור שלב הערכת הדיודה.
אפשר להשאיר את הדיודה לכל הזרימות ולהוסיף את הפלטפורמה רק לגישה אינטראקטיבית?
כן – וזו נקודת ההתחלה המומלצת לארגונים עם מגבלות רגולטוריות חזקות. הפלטפורמה מטפלת ב-RDP, SSH, HTTP ושיתוף קבצים. הדיודה מטפלת בכל הזרימות החד-כיוויות. המוצרים המשלימים (VPN, jump server, SMB proxy עצמאי) מבוטלים. עם הזמן, ה-CISO מעריך אם זרימות חד-כיוויות לא מוסדרות יכולות גם הן לעבור לפלטפורמה.
מה קורה אם לפלטפורמה יש פגיעות תוכנה?
בניגוד ל-Data Diode (שאין לו שטח תקיפה תוכנתי), לפלטפורמה מבוססת תוכנה יכולות להיות פגיעויות. המענה הארכיטקטוני הוא שהפלטפורמה פועלת עם אפס פורטים נכנסים – ה-Access Controller יוזם את כל החיבורים החוצה. תוקף יצטרך לפרוץ את המנהרה היוצאת עצמה (TLS 1.2/1.3 מוצפנת) ממצב שהוא כבר בתוך רשת ה-OT. זה פרופיל סיכון שונה מהותית מרכיב VPN חשוף לאינטרנט עם פורט נכנס.
המיגרציה דורשת השבתת OT?
לא. הפלטפורמה נפרסת במקביל לתשתית הקיימת. מערכות SCADA בייצור לא מותאמות. ה-Access Controller הוא רכיב חדש שמתחבר החוצה – הוא לא דורש שינויים בתחנות OT, בקרים או תשתית רשת קיימים. משתמשים עוברים מ-VPN + jump server לפלטפורמה; תחנת ה-SCADA לא מודעת לשינוי.
מה עם סביבות air-gapped?
סביבות air-gapped אמיתיות (ללא קישוריות רשת בין IT ל-OT) הן מחוץ לתחום המיגרציה הזו – מעצם הגדרתן, אין להן קישוריות להעביר. ה-playbook חל על סביבות שטוענות שהן air-gapped אבל בפועל יש להן מנהרות VPN, jump servers, או גישת ספקים מרחוק שמגשרת על הפער. בסקר ICS/OT של SANS לשנת 2025, לרוב הארגונים שדיווחו על אירועי אבטחת OT הייתה צורה כלשהי של קישוריות IT/OT.
איך זה משפיע על עמידה ב-IEC 62443?
המיגרציה מחזקת עמידה ב-IEC 62443 עבור FR1 (זיהוי ואימות), FR2 (בקרת שימוש), FR3 (שלמות מערכת), FR5 (הגבלת זרימת מידע), ו-FR6 (תגובה בזמן לאירועים) על ידי הוספת בקרת גישה מבוססת זהות, הקלטת סשנים וביקורת אחידה לקישוריות שלא היה לה שום דבר מזה. עבור FR4 (סודיות מידע) ו-FR7 (זמינות משאבים), ארכיטקטורת אפס פורטים נכנסים מספקת הגנה שוות ערך או עדיפה על המוצרים המשלימים שהיא מחליפה. התחום היחיד שבו הדיודה מספקת עמידה חזקה יותר הוא בידוד פיזי IEC 62443 SL4 – ולכן הדיודה נשמרת לאותן זרימות ספציפיות.
מה הפרש העלות?
אתר תשתיות קריטיות טיפוסי שמפעיל דיודה + VPN + jump server + SMB proxy + מחברי TCP מוציא $160K–$380K על חומרה ועוד $30K–$80K בשנה על תחזוקה ל-4–6 ספקים. הפלטפורמה המאוחדת מבטלת את ה-VPN, jump server, SMB proxy עצמאי ומחברי TCP – ומצמצמת את ההוצאה המשלימה ב-70%–80%. עלות הדיודה נשארת לאתרים שמשמרים אותה לזרימות מוסדרות. החיסכון התפעולי בעבודת אינטגרציה (קונסולה אחת לעומת 4+) ובמהירות תגובה לאירועים (עקבות ביקורת אחידים לעומת לוגים מפוזרים) בדרך כלל גדול יותר מהחיסכון בחומרה.
סיכום
מדריך ה-CISO למיגרציה מ-Data Diode הוא לא פרויקט החלפת טכנולוגיה. הוא איחוד ארכיטקטוני שמבטל את המוצרים המשלימים – VPN, jump server, SMB proxy, מחברי TCP – שיוצרים יותר שטח תקיפה ממה שהדיודה מבטלת. הדיודה נשארת שם שהרגולציה דורשת. כל השאר מתאחד על פלטפורמה אחת עם אפס פורטים נכנסים, אכיפת מדיניות אחידה, MFA והקלטה לכל סשן, ועקבות ביקורת אחידים.
שישה חודשים. ארבעה שלבים. קריטריוני הצלחה מדידים בכל גבול שלב. נהלי rollback מפורשים בכל צעד. ובסוף: פחות ספקים, שטח תקיפה קטן יותר, חקירות מהירות יותר, ועמידה רגולטורית שמיושרת עם לאן כל מסגרת רגולטורית משמעותית הולכת – לא איפה שהיא הייתה כשהדיודה נפרסה.
התחילו עם מלאי קישוריות. פרסו את הפלטפורמה במקביל. העבירו את הרכיב בעל הסיכון הגבוה ביותר קודם. מדדו. המשיכו.
