אילו שערי אבטחה ישנים עדיין רצים ברשתות ביטחוניות?
רשתות ביטחוניות עובדות על מחזורי חיי ציוד שארגונים מסחריים נטשו לפני שנים. רכיבי VPN שנפרסו ב-2014. שרתי jump שרצים Windows Server 2012 R2. שערי SSL/TLS עם קושחה מ-2018. Data Diodes עצמאיים מחוברים ל-SMB proxies מחוברים למחברי TCP נקודתיים – כל אחד מספק אחר, כל אחד עם מחזור עדכונים משלו (או היעדר אחד כזה), כל אחד יוצר שטח תקיפה שיריבים תוקפים באופן פעיל.
זה לא חשש תיאורטי. נכון לתחילת 2025, רק 14% מפעילויות Zero Trust ברמת היעד של ה-DoD הושלמו. דדליין ספטמבר 2027 של הפנטגון ל-Zero Trust ברמת יעד על מערכות IT מתקרב, עם דדליינים ייעודיים ל-OT שנקבעו לשנות הכספים 2030 ו-2033. הנחיית ה-DoD מנובמבר 2025 "Zero Trust for Operational Technology Activities and Outcomes" פירטה 84 פעילויות ברמת יעד ו-21 ברמה מתקדמת ספציפית ל-OT ומערכות בקרה – שמכסות הכל ממערכות בקרת מתקנים ורשתות חשמל ועד מתקני טיהור מים ותשתיות תחבורה.
בינתיים, הפעילות העוינת מתעצמת. Dragos עקבו אחרי 119 קבוצות ransomware שתקפו ארגונים תעשייתיים ב-2025, עלייה של 64% שנה-על-שנה. חוק תקציב הביטחון לשנת הכספים 2026 הקצה כ-15 מיליארד דולר ליוזמות סייבר שקשורות למודרניזציה ו-Zero Trust. המסר מהקונגרס, מהפנטגון ומנוף האיומים הוא אותו מסר: להחליף ארכיטקטורות שערי אבטחה ישנים ב-zero trust עכשיו, לא אחר כך.
המאמר הזה מספק מדריך החלפה פרקטי לקציני אבטחה ביטחוניים שצריכים להשבית תשתית שערים ישנה ולהקים קישוריות Zero Trust שעומדת בדרישות DoD – בלי לשבש מערכות תפעוליות.
מה בדיוק צריך להחליף?
השאלה היא לא "האם כדאי להחליף שערים ישנים?" המנדט ברור. השאלה היא מה ספציפית מהווה תשתית שערים ישנה ברשת ביטחונית, ומה מחליף כל רכיב.
ערימת השערים הישנה
רוב ההתקנות הביטחוניות מפעילות שילוב כלשהו של הרכיבים האלו בגבול בין רשתות מסווגות/לא-מסווגות, בין IT ל-OT, או בין ההתקנה לשותפים חיצוניים:
רכיב ישן | מה עושה | למה זו בעיה ב-2026 |
רכיב VPN | מספק מנהרה מוצפנת לגישה מרחוק | פותח פורטים נכנסים; נותן גישת רשת; וקטור כניסה עיקרי ל-ransomware; דורש עדכון קבוע של קושחה חשופה לאינטרנט |
Jump server / bastion host | מספק גישת RDP/SSH למערכות פנימיות | יוצר נתיב תנועה רוחבית; בדרך כלל עם גישת רשת רחבה; הרשאות משותפות שכיחות; הקלטת סשנים מוגבלת או לא קיימת |
שער SSL/TLS | מסיים סשנים מוצפנים בגבול הרשת | לרוב רץ גרסאות TLS מיושנות; עשוי לא לתמוך ב-TLS 1.3; גרנולריות מדיניות מוגבלת |
Data Diode עצמאי | אוכף העברת מידע חד-כיוונית | מטפל רק בקבצים; לא מסוגל לתמוך בסשנים אינטראקטיביים, שיתוף קבצים דו-כיווני, או קישוריות API |
SMB proxy / שער קבצים | מספק שיתוף קבצים דו-כיווני בין אזורים | מוצר נפרד מבקרות הגישה; לוגים, מדיניות וספק משלו |
מחברי TCP נקודתיים | מאפשר חיבורי אפליקציה דו-כיווניים ספציפיים | לרוב לא מתועדים; מוטמעים במוצרי ספקים; בלתי נראים ל-SOC; ללא שילוב זהויות |
רכיב MFA ישן | מספק אימות דו-שלבי | עשוי לא לתמוך ב-FIDO2/PIV/CAC באופן טבעי; לרוב SMS או טוקן בלבד; לא לכל סשן |
פלטפורמת truePass מאחדת את הפונקציות של כל שבעת הרכיבים בארכיטקטורה אחת. רכיב ה-VPN, ה-jump server, ה-SMB proxy העצמאי, מחברי TCP הנקודתיים ורכיב ה-MFA הישן – כולם מבוטלים. הדיודה נשמרת רק שם שהרגולציה מחייבת אכיפה חד-כיוונית פיזית.
איך מזהים מה באמת יש לכם
קציני אבטחה ביטחוניים מגלים לא פעם שמלאי השערים המתועד חלקי. תשתית ישנה מצטברת – מחבר שהותקן לאינטגרציית ספק ב-2019, מנהרת SSH קבועה שהייתה "זמנית," חיבור מסד נתונים ישיר שעוקף את ה-DMZ לגמרי.
לפני שמתחילים כל החלפה, השלימו את המלאי הזה:
- ייצאו את כל סט כללי ה-firewall לכל גבול בין אזורי סיווג, בין IT ל-OT, ובין ההתקנה לרשתות חיצוניות
- הריצו ניתוח זרימות רשת ל-14 ימים בכל גבול כדי ללכוד את כל החיבורים הפעילים – לא רק המתועדים
- זהו כל חשבון משתמש ושירות עם גישה חוצת-גבולות
- תעדו כל מנגנון גישה מרחוק של ספק – כולל מנהרות מוטמעות בציוד שסופק על ידי ספקים
- רשמו את גרסת הקושחה/תוכנה של כל רכיב שער – ציינו כל דבר שנמצא end-of-life או end-of-support
המלאי הזה חושף בדרך כלל 30%–50% יותר קישוריות ממה שמתועד. כל חיבור לא מתועד הוא נתיב תקיפה לא מנוטר.
מה מסגרת ה-Zero Trust של ה-DoD דורשת להחלפת שערים?
DTM 25-003 (יולי 2025) מורה לכל רכיבי ה-DoD להשיג Zero Trust ברמת יעד בכל המערכות. ההנחיה הייעודית ל-OT מנובמבר 2025 מוסיפה 84 פעילויות ברמת יעד. הנחיות יישום Zero Trust של ה-NSA (ינואר 2026) מספקות מימוש מדורג מ-Discovery דרך Phase Two.
לקציני אבטחה ביטחוניים שמתכננים החלפת שערים, הדרישות הרלוונטיות ממופות להחלטות ארכיטקטוניות ספציפיות:
דרישת ZT של DoD | מה זה אומר להחלפת שערים |
אימות רציף | כל סשן חייב לאמת זהות מחדש – לא רק הכניסה הראשונית ל-VPN. MFA לכל סשן מחליף אימות ברמת VPN |
גישה במינימום הרשאות | גישה ברמת אפליקציה למשאבים ספציפיים מחליפה גישת VPN ברמת רשת. משתמשים מגיעים לתחנה אחת, לא לכל אזור ה-SCADA |
מידור רשת | מיקרו-סגמנטציה ברמת אפליקציה מחליפה מידור מבוסס VLAN. כל סשן הוא סגמנט מבודד |
deny-by-default | אפס פורטים נכנסים מחליף "חסום רוב, התר חלק." ל-firewall אין כללים נכנסים – נקודה |
ניטור רציף | עקבות ביקורת אחידים עם הקלטה לכל סשן מחליפים לוגים מפוצלים מ-4–6 מוצרים ישנים |
בקרות ברמת מידע | סריקת CDR ואכיפת מדיניות ברמת קובץ מחליפים שיתוף קבצים SMB לא מבוקר |
תאימות מכשירים | בדיקת מצב מכשיר בכל סשן מחליפה בדיקה חד-פעמית של לקוח VPN |
91 תוצאות היכולת
אסטרטגיית Zero Trust של ה-DoD מגדירה 91 תוצאות יכולת ברמת יעד ל-IT ו-61 לרמה מתקדמת. ל-OT, ההנחיה מנובמבר 2025 מגדירה 84 ברמת יעד ו-21 ברמה מתקדמת. פלטפורמה מאוחדת אחת שמטפלת בזהות, גישה, שיתוף קבצים, הקלטת סשנים וביקורת עונה באופן טבעי על יותר תוצאות מערימה של 5–6 מוצרים ישנים – כי התוצאות מניחות קבלת החלטות משולבת לכל בקשה, שארכיטקטורות מפוצלות לא מסוגלות לספק.
איך מחליפים שערי אבטחה ישנים ב-Zero Trust: רכיב-אחרי-רכיב
החלפת רכיב ה-VPN
מה מסירים: רכיב VPN חשוף לאינטרנט עם פורט נכנס 443 או 1194, תוכנת לקוח VPN על נקודות קצה, תצורת split-tunnel או full-tunnel, אימות ברמת VPN (בדרך כלל שם משתמש/סיסמה + טוקן).
מה פורסים: Access Gateway ב-DMZ (אימות ואכיפת מדיניות בלבד) + Access Controller בתוך הרשת המוגנת (יוזם HTTPS יוצא 443 ל-Gateway). ה-Access Controller מושך סשנים מורשים פנימה דרך המנהרה היוצאת. ללא כללי firewall נכנסים. ללא שטח תקיפה חשוף לאינטרנט.
מה משתנה למשתמש: הוא מזדהה ב-Gateway עם PIV/CAC + MFA, ומקבל גישה ברמת אפליקציה למשאב הספציפי שהוא מורשה לו. הוא לא מקבל גישת רשת לשום דבר.
מה משתנה לתוקף: אין מה לסרוק. אין פורטל VPN לבחון. אין פורט נכנס לנצל. אין דף כניסה לפריצת brute-force. הרשת המוגנת בלתי נראית.
קריטריון הצלחה: סריקה חיצונית (Shodan, Censys, Nmap) מחזירה אפס תוצאות לטווח כתובות ה-IP של ההתקנה. מחזורי עדכון קושחת VPN נמחקים מלוח התחזוקה.
החלפת ה-Jump Server
מה מסירים: שרת jump מבוסס Windows Server עם גישת RDP למספר מערכות פנימיות. בדרך כלל עם קישוריות רשת רחבה לאזור SCADA או הסגמנט המסווג. לרוב הרשאות משותפות. לעתים נדירות עם הקלטת סשנים.
מה פורסים: מדיניות RDP ברמת תחנה דרך הפלטפורמה המאוחדת. כל משתמש מקבל גישת RDP לתחנה המורשית הספציפית שלו בלבד – לא ל-jump server, ולא לרשת. הקלטת סשנים (וידאו + הקלדות) היא חובה. הפניית Clipboard, כוננים ומדפסות מושבתת לפי מדיניות.
מה משתנה למשתמש: סשן ה-RDP נראה ומתנהג בדיוק כמו קודם. המשתמש כבר לא נכנס ל-jump server קודם – הוא מזדהה פעם אחת ב-Gateway ומקבל סשן RDP ישיר (דרך מנהרה) לתחנת היעד שלו.
מה משתנה ל-SOC: במקום לתאם לוגי VPN + לוגי Windows Event של jump server + לוגי תחנת יעד משלוש מערכות שונות, הם רואים רשומת ביקורת אחת לכל סשן עם זהות מלאה, מצב מכשיר, אישור מדיניות, והקלטה מלאה.
החלפת ה-SMB Proxy / שער קבצים
מה מסירים: SMB proxy עצמאי או שער קבצים שמטפל בשיתוף קבצים דו-כיווני בין אזורים. ספק נפרד, קונסולה נפרדת, לוגים נפרדים, ללא שילוב זהויות.
מה פורסים: SMB Proxy משולב עם אימות Kerberos/NTLM, SMB Signing, הצפנה מקצה לקצה, וסריקת CDR (Content Disarm & Reconstruction). העברות קבצים מאוכפות-מדיניות, משויכות לזהות, ומבוקרות במלואן דרך אותה פלטפורמה שמטפלת בגישה אפליקטיבית.
מה משתנה בהעברות קבצים: כל קובץ שחוצה גבול אזור נסרק (CDR מפשיט תוכן זדוני), מוצפן, משויך לזהות אישית, ומתועד בעקבות הביקורת האחידים. עדכוני קושחה, גיבויי הגדרות ומשלוחי ספקים – הכל עובר דרך נתיב מבוקר אחד.
החלפת מחברי TCP נקודתיים
מה מסירים: מחברים ייעודיים לאפליקציות שמספקים קישוריות TCP דו-כיוונית ליישומים ספציפיים. לרוב מוטמעים במוצרי ספקים, לא מתועדים, ובלתי נראים ל-SOC.
מה פורסים: Zero Trust Application Access ליישומי HTTP, SSH ו-TCP מותאמים. כל חיבור אפליקטיבי מאוכף-מדיניות, משויך לזהות, ומנותב דרך מנהרת reverse-access. ללא חיבורי TCP ישירים בין אזורים.
מה משתנה לאפליקציה: כלום – פרוטוקול האפליקציה רץ בתוך המנהרה ללא שינוי. מה שמשתנה הוא שכל חיבור עכשיו נראה, משויך, מבוקר-מדיניות, וניתן לביקורת.
מה רצף הפריסה להתקנה ביטחונית?
ההחלפה עוקבת אחרי סדר עדיפות סיכון: רכיבים ישנים בעלי הסיכון הגבוה ביותר מוחלפים קודם, עם הפעלה מקבילה שמבטיחה שאין פער קישוריות.
שלב | שבועות | מה קורה | מה מושבת |
1: תשתית | 1–4 | פריסת Access Controller + Gateway; שילוב עם AD/LDAP של ההתקנה; הגדרת אימות PIV/CAC; אימות מנהרה יוצאת | כלום עדיין – הערימה הישנה נשארת פעילה |
2: החלפת VPN | 5–8 | העברת כל הסשנים האינטראקטיביים (RDP, SSH, HTTP) מ-VPN + jump server לפלטפורמה; אכיפת MFA לכל סשן והקלטה | רכיב VPN; jump server |
3: שיתוף קבצים | 9–16 | העברת שיתוף קבצים דו-כיווני מ-SMB proxy עצמאי ל-SMB Proxy של הפלטפורמה עם CDR; הפעלה מקבילה ל-4 שבועות | SMB proxy עצמאי / שער קבצים |
4: מחברי TCP | 17–20 | זיהוי והעברת מחברי TCP נקודתיים לגישה אפליקטיבית של הפלטפורמה; תיעוד חיבורים שהיו בלתי נראים | מחברי TCP נקודתיים; מנהרות ספק מוטמעות |
5: הערכת דיודה | 21–24 | הערכה של כל זרימה שמטופלת על ידי דיודה: שמירה למוסדרות, העברה לפלטפורמה לא-מוסדרות | דיודה נשמרת לזרימות מוסדרות בלבד |
6: הקשחה | 25–26 | deny-all נכנס על כל firewalls של אזורים; סריקה חיצונית לאימות; מבדק חדירה; תיעוד עמידה | רכיבי MFA ישנים |
Rollback בכל שלב: הגדרות תשתית ישנה נשמרות בארכיון (לא נמחקות) למשך 90 יום. הדיודה רצה ללא שינוי לאורך כל התהליך. אם שלב כלשהו מייצר תוצאות לא מקובלות, המצב הקודם ניתן לשחזור ללא רכש מחדש.
לארגונים שעוקבים אחרי מדריך מיגרציה מובנה, כל ההחלפה מסתיימת ב-6 חודשים עם קריטריוני הצלחה מדידים בכל גבול שלב.
איך זה ממופה לשבעת העמודים של Zero Trust של ה-DoD?
עמוד ZT של DoD | כיסוי שערים ישנים | כיסוי פלטפורמה מאוחדת |
משתמשים | VPN מאמת בכניסה בלבד; jump server עשוי להשתמש בהרשאות משותפות | MFA לכל סשן עם PIV/CAC; זהות אישית לכל סשן; מצב מכשיר בכל גישה |
מכשירים | בדיקת לקוח VPN בחיבור; ללא בדיקת מצב רציפה | תאימות מכשיר נבדקת לכל סשן: OS, EDR, הצפנה, רמת עדכונים |
אפליקציות ועומסים | ללא בקרת גישה ברמת אפליקציה; VPN נותן גישת רשת | מדיניות ברמת אפליקציה/תחנה; בידוד ברמת אפליקציה |
מידע | SMB proxy מעביר קבצים ללא זהות; ללא שילוב CDR | SMB Proxy עם CDR, שיוך זהות, הצפנה, וביקורת לכל קובץ |
רשת וסביבה | כללי firewall עם חריגים נכנסים; מידור VLAN | אפס פורטים נכנסים; מיקרו-סגמנטציה ברמת אפליקציה; deny-all כברירת מחדל |
אוטומציה ותזמור | הקצאה ידנית ב-4–6 מוצרים | מנוע מדיניות אוטומטי; תהליכי אישור; ניהול מקונסולה אחת |
נראות ואנליטיקה | לוגים מפוצלים מ-4–6 מוצרים בפורמטים שונים | פיד Syslog אחיד; עקבות ביקורת לכל סשן; הקלטת סשנים; שילוב SIEM אחד |
הערימה הישנה מכסה את עמוד המשתמשים באופן חלקי (אימות VPN) ואת עמוד הרשת באופן חלקי (כללי firewall). חמשת העמודים הנותרים או שאינם מטופלים או מפוצלים בין מספר מוצרים. פלטפורמה מאוחדת מכסה את כל שבעת העמודים דרך ארכיטקטורה אחת – שזה בדיוק מה ש-91 תוצאות היכולת של אסטרטגיית ZT של ה-DoD מניחות.
מה החששות המרכזיים שקציני אבטחה ביטחוניים מעלים – והתשובות?
"אנחנו לא יכולים לשנות תשתית רשת מסווגת"
ה-Access Controller נפרס כרכיב חדש שמתחבר החוצה. הוא לא משנה תשתית רשת קיימת, תחנות עבודה, בקרים, או מערכות שמירת סיווג. הרשת המוגנת לא מודעת לקיום הפלטפורמה עד שסשן מורשה. ללא שינויים למערכות SCADA קיימות, ללא שינויים למערכות שמירת סיווג, ללא שינויים לכללי firewall מעבר להסרת כללים נכנסים ישנים.
"מערכות ה-OT שלנו מריצות פרוטוקולים ישנים שפלטפורמות מודרניות לא תומכות בהם"
הפלטפורמה תומכת ב-RDP, SSH, SFTP, HTTP/HTTPS ו-SMB – שביחד מכסים את דרישות הגישה האינטראקטיבית לתחנות הנדסה OT, שרתי historian וקונסולות HMI. מכשירי ה-OT עצמם (PLCs, RTUs, בקרי DCS) לא נגישים ישירות דרך הפלטפורמה – הם מנוהלים דרך תחנות ההנדסה שהפלטפורמה מספקת אליהן גישה מאובטחת. הפרוטוקולים הישנים שרצים בין PLCs לתחנות על רשת ה-OT לא מושפעים כלל.
"אנחנו צריכים לשמר אכיפה חד-כיוונית פיזית לזרימות מידע מסוימות"
נכון – והפלטפורמה לא מחליפה את הדיודה לזרימות האלו. מסגרת ההערכה לסביבות ביטחון פנים חלה באופן שווה על ביטחון: שמרו את הדיודה שם שהרגולציה מחייבת חד-כיווניות פיזית (גרעיני תחת RG 5.71, מסווג IEC 62443 SL4). העבירו את כל השאר – סשנים אינטראקטיביים, שיתוף קבצים דו-כיווני, גישת ספקים, זרימות חד-כיוויות לא מוסדרות – לפלטפורמה. מצב הקצה הטיפוסי הוא פלטפורמה שמטפלת ב-80%–90% מהקישוריות, דיודה ב-10%–20%.
"יש לנו מגבלות תקציב שנתיות ולא יכולים לרכוש הכל בבת אחת"
הפריסה המדורגת מותאמת למציאות התקציבית של ביטחון. שלבים 1–2 (החלפת VPN ו-jump server) מספקים את ההשפעה האבטחתית הגבוהה ביותר ויכולים להיות ממומנים כפעולת רכש אחת. שלבים 3–6 יכולים להיות ממומנים בשנות כספים עוקבות. הפלטפורמה נפרסת על מכונות וירטואליות סטנדרטיות – ללא צורך ברכש חומרה מיוחדת.
"איך מדגימים עמידה בפני ה-AO?"
עקבות הביקורת האחידים מייצרים רשומות עמידה ניתנות לייצוא שממופות לתוצאות יכולת ZT של ה-DoD. הקלטות סשנים מספקות ראיות פורנזיות לכל גישה חוצת-גבולות. מיפוי IEC 62443 FR, התאמה ל-NIST 800-207, ובקרות FISMA מתועדים כחלק מהקשחת שלב 6. הגורם המסמיך (AO) מקבל חבילת עמידה אחת במקום תיעוד נפרד מ-4–6 ספקים.
מה קורה אם לא מחליפים שערים ישנים?
זו לא שאלה תיאורטית. ההשלכות של שמירה על תשתית שערים ישנה ברשתות ביטחוניות מתועדות בדוחות אירועים ומודיעין איומים:
ניצול רכיבי VPN הוא שיטתי, לא אופורטוניסטי. Dragos דיווחו שקבוצות ransomware ב-2025 נכנסו באופן עקבי לפורטלי VPN עם הרשאות תקפות שהושגו מ-infostealers, ומשם ניצלו RDP ו-SMB כדי לנוע לרוחב לעבר מערכות OT. ל-Ivanti, Fortinet, Palo Alto Networks ו-Cisco – לכולן היו חולשות VPN/firewall שנוצלו באופן פעיל ב-2024–2025, רבות עם exploit codes ציבוריים תוך ימים מהחשיפה. התקנה ביטחונית שמריצה רכיב VPN לא מעודכן היא לא בסיכון תיאורטי – היא בסיכון פעיל, מתמשך ומתועד.
ה-jump server הוא מאפשר התנועה הרוחבית. כש-VPN נפרץ, התוקף נוחת על ה-jump server. ל-jump server יש גישת רשת למערכות מסווגות או OT. משם, תנועה רוחבית לתחנות SCADA, שרתי historian ותחנות הנדסה היא טריוויאלית – כי ה-jump server תוכנן להגיע אליהם. בקרת האבטחה שהייתה אמורה לבלום גישה הופכת לנתיב ההתרחבות.
לוגים מפוצלים מעכבים תגובה לאירועים עד כדי חוסר רלוונטיות. עם 4–6 מוצרים ישנים שמייצרים לוגים בפורמטים שונים, אזורי זמן שונים, ומזהים שונים, צוות ה-IR מבלה שעות בתיאום נתונים לפני שהוא יכול לענות על שאלות בסיסיות: מי התחבר, לאן, מתי. Dragos דיווחו על 42 ימים זמן שהייה ממוצע ל-ransomware בסביבות OT ב-2025 – ונראות מפוצלת היא גורם מרכזי. כל שעה שצוות ה-IR מקדיש לתיאום לוגים ממוצרים ישנים היא שעה שהתוקף מקדיש לתנועה רוחבית.
שחיקת תקציב היא רציפה. תחזוקת שערים ישנים היא לא עלות חד-פעמית. אלו חידושי רישוי שנתיים ל-4–6 ספקים, מחזורי עדכון קושחה לרכיבים חשופים לאינטרנט, עבודת אינטגרציה כדי לשמור על זרימת לוגים ל-SIEM, ומחזורי עדכון חירום כשה-CVE הבא של VPN נופל. חוק הביטחון לשנת הכספים 2026 הקצה 15 מיליארד דולר למודרניזציה סייבר – ארגונים שמוציאים את התקציב הזה על שמירת שערים ישנים במקום פריסת פלטפורמות Zero Trust מוציאים דולרי מודרניזציה על שימור.
איך נראה מצב לפני/אחרי להתקנה ביטחונית טיפוסית?
מדד | לפני (ערימה ישנה) | אחרי (פלטפורמה מאוחדת) |
פורטים נכנסים ב-firewall לאזורים מסווגים/OT | 3–8 (VPN, RDP, מותאמים) | 0 |
רכיבים חשופים לאינטרנט | רכיב VPN + שער SSL | אין – אפס שירותים גלויים |
מוצרים שמנהלים קישוריות חוצת-גבולות | 5–7 | 1–2 (פלטפורמה + דיודה אם נשמרת) |
ספקים | 4–6 | 1–2 |
שיוך סשנים | 40–60% (הרשאות משותפות, ללא הקלטה) | 95%+ (זהות אישית, MFA, הקלטה מלאה) |
זמן חקירה ממוצע לסשן חוצה-גבולות | 3–6 שעות (4+ מקורות לוגים) | < 15 דקות (עקבות ביקורת אחידים + הקלטה) |
עמודי ZT של DoD שמכוסים | 2 מתוך 7 (חלקי) | 7 מתוך 7 |
דחיפות עדכון לרכיבים חשופים לאינטרנט | קריטית (חולשות VPN מנוצלות בפועל) | בוטלה (אין רכיבים חשופים לאינטרנט) |
תוצאות סריקה חיצונית | 2–5 שירותים גלויים | 0 |
סיכום
מנדט ה-Zero Trust של ה-DoD הוא לא דרישה עתידית – DTM 25-003 בתוקף עכשיו, ל-91 תוצאות היכולת ברמת יעד יש דדליינים, וההנחיה הייעודית ל-OT מוסיפה עוד 84. שערי אבטחה ישנים – רכיבי VPN, jump servers, שערי SSL, מתווכי קבצים עצמאיים, מחברי TCP נקודתיים – לא תוכננו ל-Zero Trust ולא ניתן לשפץ אותם כדי לעמוד בדרישות האלו. הם תוכננו למודל היקפי שה-DoD נטש במפורש.
כדי להחליף ארכיטקטורות שערי אבטחה ישנים ב-zero trust, קציני אבטחה ביטחוניים לא צריכים לבנות ערימה חדשה ממספר ספקים. הם צריכים פלטפורמה אחת שמבטלת פורטים נכנסים, אוכפת אימות זהות לכל סשן, מספקת גישה ברמת אפליקציה במקום ברמת רשת, משלבת שיתוף קבצים עם סריקת CDR, מקליטה כל סשן, ומייצרת עקבות ביקורת אחידים עבור הגורם המסמיך.
השער הישן נשאר במתלה עד שההחלפה שלו מוכחת. ההחלפה רצה במקביל עד שכל סוג קישוריות מאומת. הדיודה נשארת שם שהרגולציה דורשת. ובסוף המיגרציה, להתקנה יש פחות ספקים, פחות שטחי תקיפה, פחות פורטים נכנסים (אידיאלית אפס), חקירות מהירות יותר, ועמידה רגולטורית שמיושרת עם לאן אסטרטגיית ZT של ה-DoD הולכת – לא איפה שהיא הייתה כשהשער הישן נפרס.
תיק הפתרונות של TerraZone לסוכנויות ביטחון פדרליות מספק סקירות ארכיטקטורה, תכנון פריסה מדורג, והנדסת שילוב המותאמים לדרישות סיווג ועמידה ביטחוניות.


