Data Diode - לא חומת אש, ולא מה שרוב המפתחים מצפים לו

כשמנהל מחשוב במפעל שומע לראשונה על Data Diode, הדימוי הראשון שעולה הוא לרוב של Firewall - רכיב שיושב על הרשת, מסנן, ומחליט מה עובר. למעשה, זה ממש לא מה שזה.

ההבדל הזה, בין Firewall לבין Data Diode, הוא גם ההסבר למה פרויקטים כאלה דורשים מפתח שמכיר את התחום, לא סתם מישהו שיודע לכתוב אפליקציה.

רשת Air-Gap - למה היא קיימת

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

בסביבות האלה, רמת האבטחה לא נקבעת לפי מדיניות - היא נקבעת לפי דרישות רגולטוריות, לפעמים לפי דרישות לקוח, ולפעמים לפי לקח שנלמד ממקרה אמיתי.

Air-Gap פותר בעיה אחת לחלוטין: אין כניסה. אבל הוא יוצר בעיה שניה: אין יציאה! ולפעמים הצורך בנתונים או בהתראות הנובעות מהם, חיוניים מאוד לאנשים שנמצאים מחוצה לה.

מה Data Diode עושה ומה הוא לא עושה

ה-Data Diode הוא רכיב שמאפשר העברת נתונים בכיוון אחד בלבד: מהרשת הסגורה החוצה, ללא אפשרות פיזית לזרימה הפוכה. לא תוכנתית - פיזית!
זה ההבדל המהותי מ-Firewall. חומת אש היא תוכנה עם כללים. אם הכללים שגויים, אם יש פגיעות, אם מישהו שינה הגדרה - יש פתח. Data Diode לא יכול לשלוח נתונים חזרה כי הוא לא בנוי לזה ברמת החומרה.

אבל כאן מגיע הדבר שהרבה מנהלים מגלים רק כשמתחילים לעבוד:
Data Diode לא מעביר "תעבורה". הוא מעביר struct.
הרכיב לא פועל כצינור כללי שמעביר כל packet שנכנס אליו. הוא עובד עם מבנה נתונים מוגדר מראש - פורמט קבוע, שדות ידועים, גודל מוסכם. מה שלא תואם את המבנה - לא עובר.

וזה שינוי מהותי בדרישות הפיתוח!

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

מי שמגיע לפרויקט כזה ומצפה לכתוב API שמחזיר JSON ומחבר לאפליקציה - נתקל בקיר!

הפיתוח נדרש משני הצדדים:

בתוך הרשת הסגורה, צריך לבנות שירות שיודע לאסוף נתונים ממקורות שונים: PLCs, SCADA, בסיסי נתונים תפעוליים ויישומי OnPrem נוספים. בשלב הבא צריך לנרמל אותם, לארוז אותם בפורמט שה-Diode מצפה לו, ולדחוף אותם בקצב מבוקר. הפיתוח הזה חי בסביבה מוגבלת: אין גישת אינטרנט לספריות, אין debug מרחוק, ולעיתים יש אילוצי OS ישנים.

בצד החיצוני, צריך לבנות שירות שמקבל את ה-stream, מפרק את ה-struct, מוודא תקינות, ומתרגם אותו לאירועים ולרשומות שהשאר המערכות יכולות לצרוך. אין ACK. אין אפשרות לבקש שליחה מחדש - הנתון עבר או לא עבר, ואין תקשורת חזרה כדי לברר.

רק אחרי שני השלבים האלה יש API. רק אחרי ה-API יש אפליקציה.

הנגשה סלקטיבית - לא הכל לכולם

הנתונים שיוצאים מהמפעל לא שייכים לכולם באותה מידה.

לקוח שרכש ציוד צריך לראות סטטוס ותקינות - לא נתוני ייצור פנימיים. מנהל קו צריך KPI של המשמרת - לא לוגי תקינות של פרוטוקולים. איש שירות שטח שמוקפץ לאירועי תחזוקה, צריך לראות היסטוריית תקלות של המכשיר הספציפי - לא יותר!

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

כל זה חי מחוץ לרשת הסגורה, אבל ניזון מהנתונים שיצאו ממנה.

הניסיון שלנו

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

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

זה בדיוק אחד ההבדלים שמפרידים בין מפתח שיודע לכתוב אפליקציה לבין מי שמבין מה הפרויקט הזה באמת דורש.

אם אתם מנהלי מחשוב במפעל עם רשת מבודדת, או שוקלים להקים כזאת ויש לכם נתונים שאנשים מחוץ לגדר צריכים לגשת אליהם - נשמח לדבר. צרו איתנו קשר.