השאלה הקשה שהדירקטוריון שלכם ישאל בסוף
הארגון שלכם השקיע הון משמעותי ב-Data Diodes. החומרה עובדת. ההבטחה החד-כיוונית נאכפת פיזית. אף אחד לא חולק על תכונות האבטחה של מכשיר שממיר נתונים לאור ומסיר את נתיב החזרה ברמה הפוטונית.
אבל הדירקטוריון שלכם ישאל בסוף שאלה אחרת: למה יש לנו ארבעה מוצרים נפרדים שמנהלים קישוריות בין IT ל-OT, ולמה הצוותים התפעוליים שלנו עדיין מבקשים עוקפים לכל תרחיש שימוש שהדיודה לא מסוגלת לטפל בו?
זו השאלה שחושפת את הפער בין מה ש-Data Diodes תוכננו לעשות לבין מה שסביבות OT מודרניות באמת צריכות. הדיודה מטפלת בהעברת קבצים חד-כיוונית ושכפול נתונים – שיקוף historian, ייצוא לוגים, טלמטריית SCADA לאנליטיקה ארגונית. היא עושה את זה עם ודאות חומרתית שאף פתרון תוכנתי לא יכול להתחרות בה. על זה אין ויכוח.
הוויכוח הוא האם העברת קבצים חד-כיוונית מכסה את מלוא דרישות הקישוריות. ב-2026, עבור רוב הארגונים שפועלים באנרגיה, מים, תעשייה, ביטחון ותשתיות קריטיות – התשובה היא לא. המציאות התפעולית כוללת גישה אינטראקטיבית לאפליקציות (RDP לתחנות SCADA, SSH לשרתי הנדסה, HTTP ליישומי web פנימיים), שיתוף קבצים מבוקר בין סביבות (עדכוני קושחה, גיבויי הגדרות, משלוחי ספקים דרך SMB), וקישוריות API בין מכונות (סנכרון חיישנים בזמן אמת, Web Services חוצי אזורים, פלטפורמות אינטגרציה IT/OT). אף אחד מאלה לא עובד דרך מכשיר חד-כיווני. הפיזיקה מונעת את זה.
התוצאה היא מה שהתעשייה קוראת לו "ארכיטקטורת טלאים" – ומה שה-CFO שלכם קורא לו "הוצאה לא מתוכננת." Data Diode להעברות חד-כיווניות. SMB Proxy נפרד לשיתוף קבצים. מחבר TCP נקודתי לאפליקציה אחת ספציפית. VPN עם jump server לגישת RDP של ספקים. כל פתרון מספק אחר, עם קונסולה משלו, פורמט לוגים משלו, מחזור תחזוקה משלו, ושטח תקיפה משלו. דוח האיומים של Waterfall לשנת 2026 תיעד 57 מתקפות סייבר שגרמו לתוצאות פיזיות בתעשייה כבדה ב-2025. חברת Dragos דיווחה שקבוצות ransomware ניצלו באופן שיטתי פורטלי VPN וכלי גישה מרחוק – בדיוק המוצרים המשלימים שארגונים פורסים כי הדיודה שלהם לא מסוגלת לטפל בסשנים אינטראקטיביים.
המאמר הזה מספק את המסגרת האסטרטגית להערכה האם כדאי להחליף ארכיטקטורות של data diode בפלטפורמות zero trust שמאחדות את כל שלושת סוגי הקישוריות – קבצים, אפליקציות, וגישת רשת מבודרת – בפלטפורמה אחת עם אפס פורטים נכנסים. המאמר כתוב עבור ה-CISO שבונה business case ברמת דירקטוריון, לא עבור המהנדס שמגדיר את הפתרון.
על מה Data Diodes באמת מגנים – ואיפה הם נעצרים
Data Diode מספק תכונת אבטחה אחת בוודאות מוחלטת: שום מידע לא יכול לנסוע מהרשת המקבלת חזרה לרשת השולחת. זה נאכף על ידי פיזיקה – למשדר האופטי בצד השולח אין מקלט מקביל, אז פשוט אין נתיב פיזי לתעבורה חוזרת.
התכונה הזו בעלת ערך בתרחישים ספציפיים. תקן ISA/IEC 62443-3-3 מציין שהשגת Security Level 4 (הגנה מפני תוקפים ברמת מדינה עם יכולות מתוחכמות) דורשת "בידוד לוגי ופיזי של רשתות קריטיות." Data Diodes מספקים את דרישת הבידוד הפיזי באופן שחומות אש ופתרונות תוכנה לא מסוגלים. תקן NIST SP 800-82 Rev. 3 ממליץ על Data Diodes כחלק מארכיטקטורת רשת OT להעברת מידע יוצא. הנחיית RG 5.71 של הוועדה לפיקוח על גרעין בארה"ב מחייבת זרימת מידע חד-כיוונית ממערכות ברמת האבטחה הגבוהה ביותר לרמות נמוכות יותר, ממומשת בחומרה.
אלו דרישות אמיתיות עם משקל רגולטורי אמיתי. כל אסטרטגיית החלפה חייבת להתחשב בהן.
אבל ל-Data Diodes יש מגבלות מובנות שהן מבניות – לא ניתנות לתיקון באמצעות שיפור מוצר:
אי-תאימות לפרוטוקול TCP. Data Diodes שוברים פיזית את TCP/IP כי הפרוטוקול דורש אישורי קבלה (ACKs) מהמקלט חזרה לשולח. מכיוון שאין נתיב חזרה, אפליקציות מבוססות TCP סטנדרטיות לא יכולות לתפקד. חברת Waterfall Security עצמם מכירים בכך ש-Data Diodes "מוגבלים לפרוטוקולים חסרי חיבור כמו broadcast Ethernet ומערכות broadcast UDP/IP," מה שמקשה על שילוב ברשתות קונבנציונליות. שערים חד-כיווניים מוסיפים תוכנה כדי לשכפל שרתים בצד המקבל – אבל האפליקציות בצד ה-OT עצמן נשארות בלתי נגישות.
אין גישה אינטראקטיבית לאפליקציות. כשמהנדס OT צריך RDP לתחנת SCADA לצורך אבחונים, או ספק צריך SSH לתחנת הנדסה של PLC לעדכון קושחה, או מפעיל צריך להגיע ליישום web פנימי – הדיודה לא יכולה לעזור. אלו סשנים דו-כיווניים מטבעם. הדיודה מעולם לא תוכננה בשבילם. זו לא מגבלה שאפשר לתקן – זו הארכיטקטורה הבסיסית.
אין מודעות לזהויות. Data Diode מעביר ביטים. הוא לא יודע מי יזם את ההעברה, באיזה מכשיר משתמשים, האם עברו אימות רב-גורמי, או האם הגישה צריכה להיות מוגבלת בזמן ומוקלטת. תכונת האבטחה היא אכיפת כיוון – לא בקרת גישה מבוססת זהות. במודל Zero Trust – שבו כל בקשת גישה חייבת להיות מאומתת, מורשית ומאומתת באופן רציף – הדיודה מטפלת רק בממד אחד של הבעיה.
מודל פריסה לכל פרוטוקול. כל סוג מידע דורש בדרך כלל הגדרת דיודה משלו או מודול תוכנת gateway נפרד. שכפול historian צריך הגדרה אחת. שיקוף OPC-DA צריך אחרת. העברת קבצים צריכה שלישית. העברת Syslog צריכה רביעית. זה יוצר מורכבות פריסה ועלות שגדלות עם מספר סוגי המידע – לא עם מספר מדיניות האבטחה.
העלות הנסתרת: מה שצומח סביב הדיודה
הדיודה עצמה היא לא בעיית העלות. בעיית העלות היא כל מה שהארגון פורס כדי לטפל בקישוריות שהדיודה לא מסוגלת לספק.
ארגון תשתיות קריטיות טיפוסי עם Data Diodes בייצור מפעיל גם:
רכיב VPN ב-IDMZ – לגישת ספקים ועובדים מרחוק למערכות OT. זה הווקטור התקיפה המנוצל ביותר בסביבות OT. ניתוח Claroty לשנת 2026 מצא ש-82% מהפריצות המאומתות לסביבות OT השתמשו בכלי גישה מרחוק חשופים לאינטרנט כנקודת כניסה ראשונית. ה-VPN קיים כי הדיודה לא יכולה לספק גישה אפליקטיבית אינטראקטיבית כמו RDP למערכות SCADA.
Jump server – לגישת RDP לתחנות SCADA, שרתי historian ותחנות הנדסה. ל-jump server יש גישה ברמת רשת לאזור ה-SCADA, מה שיוצר נתיב תנועה רוחבית שמנטרל את המידור שהדיודה אמורה לאכוף.
SMB proxy או שער קבצים – לשיתוף קבצים דו-כיווני בין סביבות IT ו-OT. עדכוני קושחה, גיבויי הגדרות, משלוחי ספקים ומסמכי הנדסה – כולם דורשים העברה דו-כיוונית מבוקרת שהדיודה לא יכולה לתמוך בה.
מחברי TCP נקודתיים – לאפליקציות ספציפיות שדורשות תקשורת דו-כיוונית. אלו לרוב מוטמעים במוצרי ספקים, מתועדים בצורה גרועה, מנוהלים בצורה לא עקבית, ובלתי נראים למרכז תפעול האבטחה.
לכל אחד מהמוצרים המשלימים האלו יש ספק משלו, מחזור עדכונים משלו, פורמט לוגים משלו, ושטח תקיפה משלו. המציאות התפעולית של ה-CISO היא לא "יש לנו Data Diode שמגן על OT." זה "יש לנו Data Diode פלוס ארבעה מוצרים נוספים, וארבעת המוצרים הנוספים הם המקום שממנו המתקפות נכנסות."
חישוב ה-TCO שהדירקטוריון צריך לראות:
קטגוריית עלות | Data Diode + משלימים | פלטפורמה מאוחדת |
חומרה (מכשיר דיודה) | $80K–$250K לאתר | לא רלוונטי (מבוסס VM) |
רכיב VPN + רישוי | $15K–$40K לאתר | בוטל |
תשתית jump server | $10K–$25K לאתר | בוטל |
SMB proxy / שער קבצים | $20K–$50K לאתר | כלול בפלטפורמה |
מחברי TCP נקודתיים | $5K–$15K לאפליקציה | כלול בפלטפורמה |
תחזוקה שנתית (כל המוצרים) | $30K–$80K לאתר | חוזה אחד |
עבודת אינטגרציה (4+ קונסולות) | 0.5–1 FTE | קונסולה אחת |
שילוב SIEM (4+ פורמטי לוגים) | 40–80 שעות ראשוניות + שוטף | פיד Syslog אחד |
מורכבות תגובה לאירועים | 4+ נתיבי הסלמה לספקים | ספק אחד |
מספר ספקים | 4–6 | 1 |
הדיודה החומרתית היא הפריט היחיד היקר ביותר, אבל המוצרים המשלימים ביחד עולים יותר – והם המקום שבו הסיכון האבטחתי מרוכז.
האלטרנטיבה הארכיטקטונית: אפס פורטים נכנסים בלי חד-כיווניות
התובנה המרכזית מאחורי החלפת Data Diode בפלטפורמת קישוריות zero trust היא זו: תכונת האבטחה שה-CISO באמת צריך היא לא זרימת מידע חד-כיוונית. היא אפס שטח תקיפה נכנס.
Data Diode משיג אפס שטח תקיפה נכנס על ידי הסרת נתיב ההחזרה הפיזי. זה עובד – אבל זה גם מסיר את היכולת לעשות כל דבר דו-כיווני.
ארכיטקטורת reverse-access משיגה אפס שטח תקיפה נכנס בצורה אחרת: הרכיב בתוך רשת ה-OT יוזם את כל החיבורים החוצה (HTTPS 443, TLS 1.2/1.3) אל gateway ב-DMZ. ה-firewall נשאר ב-deny-all קבוע לתעבורה נכנסת. אין פורטים פתוחים פנימה. אין שירותים שמאזינים בצד ה-OT. אין כתובות IP שניתנות לגילוי מבחוץ. מנקודת המבט של התוקף, התוצאה זהה לדיודה: אין מה לסרוק, אין מה לבחון, אין מה לנצל.
מנקודת המבט של הארגון, התוצאה שונה מהותית: המנהרה היוצאת תומכת בסשנים אפליקטיביים דו-כיווניים – RDP, SSH, HTTP – כי הפרוטוקול רץ בתוך חיבור יוצא שכבר הוקם. הגישה התלת-שכבתית לאבטחת קישוריות IT-to-OT משלבת תשתית reverse-access (שכבה 1), שיתוף קבצים מבוקר עם סריקת CDR (שכבה 2), וגישה אפליקטיבית zero trust עם MFA לכל סשן והקלטה (שכבה 3) בפלטפורמה אחת עם אכיפת מדיניות אחידה.
השוואת אבטחה – מה שהדירקטוריון צריך להבין:
תכונת אבטחה | Data Diode | פלטפורמת קישוריות Zero Trust |
פורטים נכנסים ב-firewall של OT | אפס (פיזי) | אפס (ארכיטקטוני) |
שירותים גלויים ברשת OT | אין | אין |
נתיב חזרה מרשת מקבלת לשולחת | בלתי אפשרי פיזית | מונע ארכיטקטונית (חיבורים יוצאים בלבד) |
עקיפה דרך פגיעות תוכנה | בלתי אפשרי (נאכף בחומרה) | אפשרי בתיאוריה (מבוסס תוכנה) – ממותן בעדכונים שוטפים + הגנה בעומק |
גישה אינטראקטיבית לאפליקציות | לא נתמכת | נתמכת עם MFA לכל סשן, הקלטה, ואכיפת מדיניות |
בקרת גישה מבוססת זהות | לא רלוונטי | Zero Trust מלא: זהות, מצב מכשיר, חלון זמן, תהליך אישור |
הקלטת סשנים ועקבות ביקורת | לא רלוונטי | מובנה: וידאו, הקלדות, צילום מסך לכל סשן |
עמידה בבידוד פיזי IEC 62443 SL4 | כן – נאכף בחומרה | חלקי – בידוד לוגי, לא פיזי. דורש קבלת סיכון או בקרות מפצות |
התאמה ל-NIST SP 800-82 Rev. 3 | מלאה להעברת מידע יוצא | מלאה למידור, בקרת גישה וניטור; חלקית לדרישת חד-כיווניות |
ההערכה הכנה: פלטפורמת קישוריות zero trust לא מספקת את הבטחת האי-אפשרות הפיזית של דיודה חומרתית. היא מספקת הבטחה ארכיטקטונית – שנאכפת על ידי תצורת תוכנה, לא על ידי פוטוניקה. לסביבות שבהן הרגולציה מחייבת אכיפה חד-כיוונית פיזית (מתקנים גרעיניים תחת RG 5.71, סיווגי ביטחון מסוימים) – הדיודה נשארת הכרחית לאותה זרימת מידע ספציפית. ל-70%–80% הנותרים מקישוריות IT/OT – סשנים אינטראקטיביים, שיתוף קבצים דו-כיווני, אינטגרציית API, גישת ספקים – הפלטפורמה מכסה את מה שהדיודה מבנית לא מסוגלת.
ה-Business Case ברמת דירקטוריון: חמישה טיעונים
טיעון 1: צמצום שטח תקיפה דרך איחוד
ה-Data Diode מגן על סוג קישוריות אחד. ארבעת המוצרים המשלימים מכניסים כל אחד שטח תקיפה משלו. איחוד כל הקישוריות בפלטפורמה אחת עם אפס פורטים נכנסים מבטל את רכיב ה-VPN (הרכיב המנוצל ביותר), את ה-jump server (מאפשר התנועה הרוחבית), ואת המחברים הנקודתיים (הפערים הלא מנוהלים). שטח התקיפה הכולל אחרי האיחוד קטן מהמצב הנוכחי, גם אם הפלטפורמה מבוססת תוכנה ולא חומרה.
הציגו את זה כך: "אנחנו מחליפים חמישה שטחי תקיפה באחד – והאחד הזה עם אפס פורטים נכנסים."
טיעון 2: יעילות תפעולית ואיחוד ספקים
ארבעה עד שישה ספקים אומרים ארבעה עד שישה חוזים, ארבעה עד שישה מחזורי חידוש, ארבעה עד שישה נתיבי הסלמה במהלך אירוע, וארבעה עד שישה פורמטי לוגים שה-SOC חייב לנרמל. truePass Gravity מאחד העברת קבצים (SMB Proxy עם CDR), גישה אפליקטיבית (RDP, SSH, HTTP עם MFA והקלטת סשנים), ותשתית reverse-access בפלטפורמה אחת, קונסולה אחת, עקבות ביקורת אחידים, ופיד Syslog אחד ל-SIEM.
הציגו את זה כך: "אנחנו מורידים ספירת ספקים מחמישה לאחד, מבטלים עבודת אינטגרציה, ונותנים ל-SOC מקור אמת יחיד לכל קישוריות IT/OT."
טיעון 3: מהירות תגובה לאירועים
כשאירוע אבטחה מתרחש בגבול IT/OT, צוות ה-IR חייב כרגע לתאם לוגים מממשק הניהול של הדיודה, מרכיב ה-VPN, מ-Windows Event Logs של ה-jump server, מה-SMB proxy, ומכל מחבר נקודתי שפרוס. פורמטי זמן שונים, מזהים שונים, רמות פירוט שונות. פלטפורמה מאוחדת מספקת רשומה כרונולוגית אחת לכל סשן: מי הזדהה, מאיזה מכשיר, באיזו שעה, לאיזה משאב OT ספציפי, עם איזה אישור מדיניות, והקלטה מלאה של כל פעולה שבוצעה במהלך הסשן. זמן חקירה ממוצע יורד משעות לדקות.
הציגו את זה כך: "לוג אחד, ציר זמן אחד, הקלטה אחת לסשן. צוות ה-IR יכול לענות על 'מי עשה מה, מתי, ולאיזו תחנת SCADA' תוך פחות מחמש דקות."
טיעון 4: מסלול עמידה ב-Zero Trust
כל מסגרת רגולטורית משמעותית נעה לכיוון Zero Trust. משרד ההגנה האמריקאי הוציא DTM 25-003 ביולי 2025, שמורה לכל הרכיבים להשיג רמת יעד של Zero Trust בכל המערכות כולל OT. הנחיית Five Eyes מינואר 2026 (CISA, NCSC-UK, BSI, FBI ואחרים) קבעה עקרונות קישוריות מאובטחת ל-OT שמדגישים גישה מבוססת זהות, אימות רציף, ואכיפת מדיניות גרנולרית – שום דבר מזה Data Diode לא מספק. תקן NIST SP 800-207 (Zero Trust Architecture) דורש החלטות גישה לכל בקשה המבוססות על זהות, בריאות מכשיר, והקשר התנהגותי.
Data Diode עומד בדרישת המידור הפיזי אבל לא מספק זהות, אימות, הרשאה, או ניטור התנהגותי. המוצרים המשלימים עשויים לספק חלק מאלו בנפרד, אבל בלי אינטגרציה הם לא מסוגלים לספק את החלטות הגישה הרציפות לכל בקשה ש-Zero Trust מחייב. פלטפורמה מאוחדת שמשלבת reverse-access, מדיניות מבוססת זהות, MFA לכל סשן, אימות מצב מכשיר, ועקבות ביקורת אחידים – עומדת באופן טבעי בדרישות Zero Trust לכל סוגי הקישוריות.
הציגו את זה כך: "המסלול הרגולטורי הוא לכיוון Zero Trust, לא לכיוון עוד דיודות. אנחנו צריכים להיות לפני עקומת העמידה, לא מאחוריה."
טיעון 5: סקיילינג ופריסה רב-אתרית
חומרת Data Diode מתרחבת לפי אתר ולפי סוג מידע. כל אתר חדש דורש מכשירים פיזיים ($80K–$250K), התקנה, הגדרה ותחזוקה שוטפת. כל סוג מידע או אפליקציה חדשים עשויים לדרוש מודולי תוכנת gateway נוספים. פלטפורמה מבוססת תוכנה נפרסת על מכונות וירטואליות סטנדרטיות, מוגדרת דרך קונסולה מרכזית, ומתרחבת על ידי הוספת משתמשים ומדיניות – לא על ידי הוספת חומרה. לארגונים עם 10, 50, או 200 אתרי OT, הפער בעלויות פריסה ותפעול משמעותי.
הציגו את זה כך: "אנחנו יכולים לפרוס קישוריות מאובטחת לאתר חדש תוך ימים, לא חודשים – ובלי מחזור רכש חומרה."
נתיב ההגירה: הפעלה מקבילה, לא החלפה בן-לילה
אף CISO לא צריך להציע להסיר Data Diodes בן-לילה. ההגירה מדורגת, כשהדיודה והפלטפורמה רצות במקביל עד שהפלטפורמה הוכיחה כיסוי אבטחתי שווה ערך או עדיף לכל סוג קישוריות.
שלב 1: פרסו את הפלטפורמה לגישה אינטראקטיבית (חודשים 1–3)
החליפו את רכיב ה-VPN וה-jump server בפלטפורמת הקישוריות zero trust. זה מטפל ברכיבים בעלי הסיכון הגבוה ביותר קודם – ה-VPN החשוף לאינטרנט וה-jump server שמאפשר תנועה רוחבית – בעוד הדיודה ממשיכה לטפל בזרימות מידע חד-כיווניות ללא שינוי.
קריטריוני הצלחה: כל סשנים של RDP, SSH ו-HTTP למשאבי OT עוברים דרך הפלטפורמה עם MFA לכל סשן, הקלטת סשנים, ומדיניות ברמת תחנה. רכיב VPN הושבת. Jump server הושבת. סריקה חיצונית מאשרת אפס שירותים גלויים.
שלב 2: העבירו שיתוף קבצים לפלטפורמה (חודשים 3–6)
העבירו שיתוף קבצים דו-כיווני (עדכוני קושחה, גיבויי הגדרות, משלוחי ספקים) מה-SMB proxy העצמאי ל-SMB Proxy המשולב בפלטפורמה עם סריקת CDR. הדיודה ממשיכה לטפל בשכפול מידע חד-כיווני (historian, syslog) בשלב זה.
קריטריוני הצלחה: כל העברות הקבצים הדו-כיווניות עוברות דרך הפלטפורמה עם אימות Kerberos/NTLM, SMB Signing, הצפנה, וסריקת CDR. SMB proxy עצמאי הושבת.
שלב 3: הערכת החלפת דיודה לזרימות חד-כיוויות (חודשים 6–12)
לכל זרימת מידע חד-כיוונית שמטופלת כרגע על ידי הדיודה, העריכו האם ארכיטקטורת reverse-access של הפלטפורמה מספקת אבטחה מספקת. לשכפול historian והעברת syslog – שבהם הדרישה היא העברת מידע יוצא, לא חד-כיווניות פיזית – ארכיטקטורת ה-outbound-only של הפלטפורמה בדרך כלל מספקת הגנה שוות ערך עם היתרון הנוסף של בקרת גישה מבוססת זהות ועקבות ביקורת אחידים.
קריטריוני החלטה לכל זרימה:
סוג זרימה | דרישה רגולטורית | להחליף דיודה? |
שכפול historian לארגון | אין מנדט בידוד פיזי | כן – הפלטפורמה מספקת העברה יוצאת בלבד עם זהות וביקורת |
העברת Syslog ל-SIEM | אין מנדט בידוד פיזי | כן – הפלטפורמה מספקת Syslog יוצא עם ביקורת אחידה |
טלמטריית SCADA לאנליטיקה | תלוי ברגולציה מגזרית | להעריך לפי רגולציה |
מידע בטיחות גרעיני (RG 5.71) | מנדט חד-כיווניות פיזית | לא – לשמור דיודה לזרימה ספציפית זו |
מידע מסווג ביטחוני (SL4) | מנדט בידוד פיזי | לא – לשמור דיודה לזרימה ספציפית זו |
שלב 4: מצב יציב
מצב הקצה הטיפוסי הוא: הפלטפורמה מטפלת ב-80%–90% מקישוריות IT/OT (סשנים אינטראקטיביים, שיתוף קבצים, רוב העברות המידע). הדיודה נשמרת ל-10%–20% מהזרימות שבהן אכיפה חד-כיוונית פיזית מחויבת ברגולציה. ערימת הטלאים של VPN, jump server, SMB proxy ומחברים נקודתיים מבוטלת לחלוטין.
מה זה לא: טיעון שדיודות הן גרועות
Data Diodes מצוינים במה שהם עושים. הבטחת האבטחה מבוססת הפיזיקה היא אמיתית ובעלת ערך. שום פגיעות תוכנה לא יכולה לעקוף מכשיר שאין לו נתיב אופטי חוזר. למתקנים גרעיניים שפועלים תחת RG 5.71, למתקנים ביטחוניים שדורשים בידוד פיזי IEC 62443 SL4, ולכל סביבה שבה הרגולציה מחייבת מפורשות זרימת מידע חד-כיוונית מאוכפת בחומרה – הדיודה היא לא אופציונלית. היא דרישת עמידה.
הטיעון הוא לא "דיודות הן גרועות." הטיעון הוא "דיודות לבד לא מספיקות." ברגע שארגון צריך גישה אפליקטיבית אינטראקטיבית, שיתוף קבצים דו-כיווני, או קישוריות API בין מכונות לאורך הגבול IT/OT – וכמעט כל ארגון צריך – הדיודה לא יכולה לעזור, והמוצרים המשלימים שממלאים את הפער יוצרים יותר סיכון ממה שהדיודה מבטלת.
השאלה האסטרטגית של ה-CISO היא לא האם להשתמש בדיודות או בפלטפורמות. היא האם להמשיך להרחיב ערימת מוצרים נקודתיים סביב דיודה, או לאחד את רוב הקישוריות על פלטפורמה אחת שמשיגה את אותה תוצאת אבטחה של אפס פורטים נכנסים – ולשמור את הדיודה רק שם שהרגולציה דורשת חד-כיווניות פיזית.
סיכום
ה-Data Diode היה התשובה הנכונה לשאלה פשוטה יותר: איך להוציא מידע מ-OT בלי לאפשר לשום דבר לחזור פנימה? השאלה השתנתה. ארגונים צריכים היום קישוריות מלאה – קבצים, אפליקציות, APIs – בין IT ל-OT, עם אפס שטח תקיפה נכנס, בקרת גישה מבוססת זהות, ביקורת לכל סשן, ועמידה במנדטי Zero Trust שלא היו קיימים כשהדיודה נפרסה.
כדי להחליף ארכיטקטורות data diode בפלטפורמות zero trust, CISOs לא צריכים לנטוש את עקרונות האבטחה שדיודות מייצגות. הם צריכים להרחיב את העקרונות האלו – אפס פורטים נכנסים, תשתית בלתי נראית, deny-all כברירת מחדל – לסוגי קישוריות שדיודות מעולם לא תוכננו לטפל בהם. הפלטפורמה לא מחלישה את רמת האבטחה. היא מבטלת את המוצרים המשלימים שכן מחלישים.
המצגת לדירקטוריון היא שלושה שקפים: שקף ראשון – המצב הנוכחי (דיודה + 4 מוצרים, 5 ספקים, 5 שטחי תקיפה, לוגים מפוזרים). שקף שני – מצב היעד (פלטפורמה + דיודה רק שם שמחויב, 1–2 ספקים, שטח תקיפה אחד עם אפס פורטים נכנסים, ביקורת אחידה). שקף שלישי – נתיב ההגירה (הפעלה מקבילה, מעבר מדורג, קריטריוני הצלחה מדידים בכל שלב).
הדיודה נשארת שם שהרגולציה דורשת. כל השאר מתאחד. שטח התקיפה מצטמצם. ה-SOC מקבל לוג אחד. הדירקטוריון מקבל ספק אחד. ומהנדסי ה-OT שלכם מקבלים קישוריות מלאה למערכות שהם צריכים – בלי אף פורט נכנס אחד.


