משבר הסייבר במגזר הממשלתי – במספרים

גופים ממשלתיים הם המטרה המועדפת על שחקני סייבר מדינתיים. לפי נתוני Microsoft, 79% ממתקפות הסייבר המדינתיות בין 2020 ל-2024 כוונו נגד גופי ממשל, ארגונים לא-ממשלתיים ומכוני מחקר. רוב המתקפות הגיעו מרוסיה (58%) ומסין, כשמאמצי הריגול הסיני עלו ב-150% ב-2024 לעומת השנה הקודמת, ומתקפות ממוקדות על מגזרי ממשל, פיננסים, ייצור ותעשייה זינקו ב-300%.

האיום לא נחלש. ביולי 2025, שלוש קבוצות תקיפה סיניות פרצו ליותר מ-400 ארגונים דרך חולשות ב-Microsoft SharePoint – כולל משרד האנרגיה האמריקאי, המשרד לביטחון המולדת ומשרד הבריאות. מרכז הסייבר הבריטי (NCSC) טיפל ב-204 אירועי סייבר משמעותיים עד ספטמבר 2025 – בממוצע אירוע משמעותי אחד כל יומיים – עלייה של 129% מ-89 אירועים בשנה הקודמת. לפחות 44 מדינות בארה"ב דיווחו על אירועי סייבר שפגעו במערכות ממשל מקומיות ב-2025.

מול האיום הגובר, המנדט הפדרלי ליישום Zero Trust הוא לא המלצה – הוא חובה. צו נשיאותי 14028 ומזכר OMB M-22-09 קבעו דרישות ארכיטקטורת Zero Trust לכל הסוכנויות האזרחיות הפדרליות. אסטרטגיית ה-Zero Trust של משרד ההגנה מכוונת ליישום מלא עד 2027. ה-NSA פרסם בינואר 2026 את מדריך היישום Zero Trust Implementation Guideline Primer, עם שלבי פעילות מדורגים.

ZTNA הוא לא אחד מתוך כמה מענים אפשריים – הוא רכיב יסוד. אבל סביבות ממשלתיות מציבות אילוצים שרוב פתרונות ה-ZTNA המסחריים לא תוכננו לעמוד בהם: טיפול במידע מסווג ורגיש, דרישות הרשאת FedRAMP, תלות במערכות ישנות בנות עשרות שנים, שילוב כרטיסים חכמים PIV/CAC, דרישות פריסה מנותקת (air-gap) וריבונית, ופעילות ברמות סיווג מרובות. לזהות את פתרון ה-ZTNA הטוב ביותר לגופים ממשלתיים מחייב להעריך ספקים מול הדרישות הייחודיות של המגזר הציבורי – לא מול קריטריונים גנריים של שוק הארגונים.

המסגרת הרגולטורית שמניעה אימוץ ZTNA בממשל

צו נשיאותי 14028 ומזכר OMB M-22-09

OMB M-22-09 מחייב סוכנויות להשיג יעדי Zero Trust שמאורגנים סביב מודל הבשלות של CISA בחמישה עמודים: זהות (זהויות מנוהלות ארגונית עם MFA עמיד לפישינג), התקנים (מלאי מלא עם יכולות זיהוי ותגובה לאירועים), רשתות (תעבורת DNS ו-HTTP מוצפנת, מפולחת לסביבות מבודדות), אפליקציות (בדיקות אבטחה שוטפות כולל תוכניות בדיקה חיצוניות), ומידע (סיווג מידע מעמיק עם תגובות אבטחה אוטומטיות).

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

NIST SP 800-207 (ארכיטקטורת Zero Trust)

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

אסטרטגיית Zero Trust של משרד ההגנה האמריקאי

משרד ההגנה פרסם את אסטרטגיית ה-Zero Trust שלו ב-2022 ועדכן את ארכיטקטורת הייחוס בשנים שלאחר מכן. האסטרטגיה מתארת 152 פעילויות על פני שבעה עמודים (משתמשים, התקנים, אפליקציות ועומסי עבודה, מידע, רשת וסביבה, אוטומציה ותזמור, נראות וניתוח). CMMC 2.0, שנכנס לתוקף ב-16 בדצמבר 2024, כולל עקרונות Zero Trust בדרישות אבטחת הסייבר של התעשייה הביטחונית, עם אכיפה מלאה בחוזים צפויה עד אוקטובר 2026.

מדריך היישום של NSA (ינואר 2026)

ה-ZIG Primer של NSA מכסה יישום בשלבים: שלב גילוי (מלאי נכסים, מיפוי זרימות מידע, הערכת זהויות), שלב ראשון (36 פעילויות התומכות ב-30 יכולות – ביסוס בקרות יסוד), שלב שני (41 פעילויות התומכות ב-34 יכולות – שילוב פתרונות ZT נפרדים), ושלבים נוספים לקראת הבשלה מלאה.

FedRAMP והרשאת ענן

FedRAMP מספק את מסגרת ההרשאה לשירותי ענן שמשמשים סוכנויות פדרליות. FedRAMP Moderate דורש 325 בקרות אבטחה למידע אישי/קנייני. FedRAMP High מחייב כ-421 בקרות למידע רגיש מאוד. פתרונות ZTNA שמסופקים כשירותי ענן לסוכנויות פדרליות דורשים בדרך כלל הרשאת FedRAMP – אם כי מזכר המדיניות של FedRAMP מ-2024 הציג פטורים אפשריים לפתרונות ZTNA עם ניתוב ישיר שאינם מעבדים או מאחסנים מידע פדרלי בענן.

תשע דרישות שמבדילות ZTNA ממשלתי מכל ZTNA אחר

קריטריוני הערכה רגילים ל-ZTNA ארגוני – כמות נקודות נוכחות (PoP), שילוב SSE, חוויית משתמש – הם הכרחיים אך לא מספיקים למגזר הציבורי. פתרון ה-ZTNA הטוב ביותר לגופים ממשלתיים חייב לענות על דרישות שרוכשים מסחריים אף פעם לא נתקלים בהן. תשעת הקריטריונים הבאים מגדירים את הפער בין ZTNA ארגוני לבין ZTNA ברמה ממשלתית.

1. טיפול במידע מסווג ורגיש

גופים ממשלתיים פועלים במספר רמות סיווג – לא מסווג, CUI (מידע לא-מסווג מבוקר), סודי, וסודי ביותר/SCI. פתרון ה-ZTNA חייב לאכוף מדיניות גישה שמכבדת את גבולות הסיווג ומונעת דליפת מידע בין רמות. לסביבות מסווגות, זה בדרך כלל אומר פריסה מקומית ללא כל ניתוב תעבורה דרך תשתית ענן מסחרית.

2. הרשאת FedRAMP או פטור

פתרונות ZTNA מבוססי ענן שמשמשים סוכנויות פדרליות דורשים בדרך כלל הרשאת FedRAMP ברמת Moderate או High. נכון לתחילת 2026, Zscaler קיבלה הרשאת FedRAMP High JAB ו-Moderate Agency. ל-Palo Alto Prisma Access יש הרשאות FedRAMP. ל-Fortinet ואחרים יש רמות הרשאה שונות. על הסוכנויות לוודא סטטוס הרשאה עדכני ב-FedRAMP Marketplace. פתרונות ZTNA עם ניתוב ישיר שמשאירים את כל התעבורה בתשתית הסוכנות עשויים לזכות בפטור מ-FedRAMP במסגרת מזכר המדיניות של 2024.

3. שילוב כרטיסים חכמים PIV/CAC

עובדי ממשל פדרליים מזדהים באמצעות כרטיסי PIV (Personal Identity Verification). אנשי משרד ההגנה משתמשים בכרטיסי CAC (Common Access Card). פתרונות ZTNA חייבים להשתלב עם מנגנוני זיהוי אלו באופן מובנה – לא כתוספת בדיעבד. זה כולל זיהוי מבוסס תעודות דרך שרשרת האישורים של PIV/CAC, שילוב עם תשתית Active Directory/LDAP של הסוכנות שממפה זהויות PIV, ותמיכה ב-derived credentials בהתקנים ניידים.

4. פריסה מקומית ומנותקת

מערכות ממשלתיות רבות – בעיקר אלו שמטפלות במידע מסווג, פועלות ב-SCIF, או תומכות במשימות ביטחון ומודיעין – לא יכולות להתחבר לתשתית ענן מסחרית. פתרון ה-ZTNA חייב להיות ניתן לפריסה בשלמותו בתוך מרכז הנתונים של הסוכנות, בתשתית GovCloud, או בסביבות air-gap מלאות. פתרונות ZTNA שפועלים אך ורק בענן פסולים לשימושים אלו.

5. תמיכה במערכות ישנות

הממשל הפדרלי מפעיל חלק מהמערכות הוותיקות ביותר בכל מגזר. אפליקציות מיינפריים (TN3270), מסדי נתונים ותיקים, אפליקציות thick-client מותאמות, ומערכות שרצות על מערכות הפעלה שאינן נתמכות עוד – כל אלו שכיחים מאוד. פתרון ה-ZTNA חייב לתמוך בפרוטוקולים ובאפליקציות האלה – לא רק בשירותי ווב מודרניים. אם הפריסת ZTNA מכסה אפליקציות ענן אבל מאלצת חזרה ל-VPN עבור מערכות ישנות, יתרון האבטחה נחתך לחצי ומורכבות התפעול מוכפלת.

6. היעלמות מהרשת וביטול שטח התקיפה

רשתות ממשלתיות הן מטרה קבועה לסיור מדינתי. סוכנויות ברמות האיום הגבוהות ביותר זקוקות לארכיטקטורה שהופכת את תשתית האפליקציות לבלתי נראית מהאינטרנט. ZTNA רגיל מסתיר אפליקציות מאחורי ברוקר, אבל משאיר את התשתית של הברוקר עצמו גלויה. ארכיטקטורת reverse-access מבטלת גם חשיפה זו – רכיבים פנימיים יוזמים חיבורים יוצאים בלבד, ה-firewall נשאר ב-deny-all קבוע לתעבורה נכנסת, ואין שום שירות גלוי. עבור סוכנויות שמתמודדות מול יריבים כמו Volt Typhoon, Salt Typhoon ו-APT29, ההבדל הארכיטקטוני הזה קובע אם סיור אפשרי או בלתי אפשרי.

7. מיקרו-סגמנטציה ברשתות ממשלתיות

רשתות ממשלתיות הן גדולות, מורכבות, ולעיתים קרובות לא מפולחות מספיק. OMB M-22-09 דורש במפורש מסוכנויות "לפרק היקפים לסביבות מבודדות." ZTNA שולט בתעבורה צפון-דרום (משתמש-לאפליקציה). מיקרו-סגמנטציה שולטת בתעבורה מזרח-מערב (אפליקציה-לאפליקציה). שניהם נדרשים כדי לעמוד בעמוד הרשתות של מודל הבשלות Zero Trust.

ההבחנה הזו קריטית מבחינה תפעולית. בלי בקרות מזרח-מערב, סשן שנפרץ יכול לנוע לרוחב פלחי הרשת של הסוכנות – בדיוק הטכניקה שנוצלה בפריצת SolarWinds כדי לעבור משרת Orion שנפרץ למערכות דוא"ל, תשתית זהויות, ובסופו של דבר לרשתות מסווגות. פילוח מבוסס זהות שמנהל תקשורת בין עומסי עבודה סוגר את הפער הזה – על ידי הבטחה שכל אפליקציה מתקשרת רק עם עמיתים מורשים במפורש, ללא תלות במיקום ברשת.

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

8. ניהול גישת קבלנים וצדדים שלישיים

סוכנויות פדרליות נסמכות על קבלנים, אינטגרטורים ונותני שירותים מנוהלים. כל קשר עם קבלן הוא וקטור גישה פוטנציאלי – כפי שהוכיחו פריצת SolarWinds ב-2020 ופרצות שרשרת אספקה רבות מאז. ZTNA ממשלתי חייב לספק גישה ללא סוכן עבור קבלנים על מכשירים שאינם ממשלתיים, סשנים מוגבלים בזמן עם ביטול אוטומטי, מדיניות גישה לכל קבלן שמוגבלת לאפליקציות ספציפיות, הקלטת סשנים לכל הפעילות של קבלנים, ועקבות ביקורת שעומדים בבחינת IG ו-GAO.

9. הרשאה רציפה וניטור עמידה

עמידה רגולטורית פדרלית היא לא הסמכה חד-פעמית – היא דורשת ניטור רציף. פתרון ה-ZTNA חייב לייצר נתוני עמידה באופן רציף: מי ניגש למה, מתי, מאיזה מכשיר, לפי איזו מדיניות, ואילו פעולות בוצעו. הנתונים חייבים להשתלב עם SIEM של הסוכנות (Splunk, Microsoft Sentinel, QRadar) ופלטפורמות GRC כדי לתמוך בדרישות Authority to Operate (ATO) שוטפות.

מעבר לרישום גישה, הפתרון צריך לתמוך בבקרות הגנה והצפנת מידע שאוכפות הצפנת AES-256 למידע במנוחה ובתנועה, בקרות גישה ברמת קובץ עם הגבלות צפייה בלבד והורדה, ואכיפת מדיניות DLP שמתואמת לדרישות סיווג המידע של הסוכנות. יכולות אלו תומכות ישירות בדרישות דיווח FISMA ובמשפחות בקרות האבטחה של NIST SP 800-53: AC (בקרת גישה), AU (ביקורת ואחריות), ו-SC (הגנת מערכת ותקשורת).

לסוכנויות שעוברות תהליכי ATO רציף, פתרון ה-ZTNA צריך לייצר באופן אוטומטי חפצי עמידה קריאים למכונה – כדי לתמוך בדרישת תאימות OSCAL (Open Security Controls Assessment Language) ש-OMB מחייב עד יולי 2026.

איך ספקי ZTNA מובילים עונים על דרישות הממשל

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

תרחיש: קבוצת APT מדינתית שמבצעת מיצוב מוקדם בתשתית הסוכנות. קבוצות כמו Volt Typhoon שומרות על גישה מתמשכת לרשתות ממשלתיות לצורך יכולת שיבוש עתידית. הסיור שלהן תלוי בגילוי שירותים חשופים לאינטרנט. פתרונות ZTNA עם ארכיטקטורת reverse-access מבטלים שירותים גלויים לחלוטין – שלב הסיור של ה-APT מחזיר אפס מטרות. ZTNA מבוסס ענן מסתיר אפליקציות מאחורי הברוקר, אבל תשתית הברוקר עצמה נשארת גלויה ותקיפה.

תרחיש: פריצת הרשאות קבלן שמובילה לתנועה רוחבית. הרשאות קבלן נגנבות דרך פישינג. בסביבת VPN, התוקף מקבל גישה ברמת רשת לפלח הסוכנות ונע לרוחב למערכות בעלות ערך גבוה. ZTNA מגביל את הסשן שנפרץ לאפליקציה הספציפית שהקבלן היה מורשה לגשת אליה – ללא תנועה רוחבית. הוספת מיקרו-סגמנטציה מגבילה את התקשורת מזרח-מערב עוד יותר ומכילה את הפריצה לאפליקציה בודדת.

תרחיש: גישה למערכת ישנה ממתקן מסווג מרוחק. אנליסט ב-SCIF מרוחק צריך גישה לאפליקציית מיינפריים ישנה (TN3270) שמאוחסנת במרכז הנתונים של הסוכנות. ZTNA ענני לא יכול להגיע לרשת מנותקת. ZTNA מקומי עם תמיכה בפרוטוקולים ישנים וארכיטקטורת reverse-access מספק את נתיב הגישה תוך שמירה על מצב אפס-פורטים-נכנסים של הרשת המסווגת.

Zscaler Private Access (ZPA)

מיצוב ממשלתי: הרשאת FedRAMP High JAB ו-Moderate Agency. משרת 14 מתוך 15 משרדי הממשלה ברמת Cabinet. הרשאת DoD IL5. תשתית נקודות הנוכחות (PoP) הגדולה ביותר בין ספקי ZTNA ענניים.

היכן מתאים: אפליקציות מאוחסנות בענן לסוכנויות אזרחיות פדרליות. איחוד SASE (ZTNA + SWG + CASB + DLP) תחת פלטפורמה אחת מורשית FedRAMP. פריסות בקנה מידה גדול עם עשרות אלפי משתמשים.

היכן פחות מתאים: מסירה עננית בלבד – כל התעבורה עוברת דרך הענן של Zscaler. לא מתאים לסביבות מסווגות, רשתות מנותקות, או סוכנויות עם דרישות ריבונות מידע מחמירות. מיקרו-סגמנטציה דורשת מוצר נפרד (Zscaler Workload Segmentation). תמחור גבוה ($15–25 למשתמש לחודש). תמיכה מוגבלת בפרוטוקולים ישנים מעבר לווב, RDP ו-SSH.

Palo Alto Networks Prisma Access

מיצוב ממשלתי: מורשה FedRAMP. ZTNA 2.0 עם בחינה רציפה לאחר החיבור. משולב עם Cortex XDR וחומות אש Strata שכבר מותקנות בסביבות פדרליות רבות.

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

היכן פחות מתאים: מסירה עננית – לא ניתנת לפריסה מקומית לסביבות מסווגות. תמחור מבוסס שימוש יוצר אי-ודאות תקציבית. מיקרו-סגמנטציה דורשת רישיון Prisma Cloud נפרד. עקומת למידה תלולה לסוכנויות בלי תשתית Palo Alto קיימת.

Fortinet Universal ZTNA

מיצוב ממשלתי: ZTNA מובנה בהתקני FortiGate ללא רישוי נוסף. FortiClient כסוכן אחיד מכסה ZTNA, VPN ו-EDR. FortiSASE מרחיב ZTNA לענן. נפרס באופן נרחב ברשתות פדרליות ושל משרד ההגנה.

היכן מתאים: סוכנויות עם תשתית FortiGate קיימת – הפעלת ZTNA בעלות הנמוכה ביותר. פריסה מקומית דרך התקני FortiGate. מסלול מעבר חלק מ-VPN ל-ZTNA.

היכן פחות מתאים: ערך מלא דורש מחויבות למערכת האקולוגית של Fortinet. יכולות ענן מתקדמות פחות בשלות מ-Zscaler או Palo Alto. מיקרו-סגמנטציה לא משולבת ב-ZTNA – דורשת מדיניות פילוח נפרדת ב-FortiGate.

Appgate SDP

מיצוב ממשלתי: Software-Defined Perimeter עם ארכיטקטורת ניתוב ישיר. נוכחות חזקה בסביבות פדרליות וביטחוניות. מדיניות גישה דינמית ומודעת הקשר שנבנתה למגזרים מוסדרים. יכולת פריסה מקומית.

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

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

TerraZone truePass

מיצוב ממשלתי: פלטפורמת Zero Trust אחודה שמשלבת ZTNA, מיקרו-סגמנטציה, בידוד זהויות, וחילופי מידע מאובטחים. טכנולוגיית reverse-access מוגנת בפטנט (חיבורים יוצאים בלבד, אפס פורטים נכנסים). פריסה מלאה מקומית, ענן או היברידית. משרדים בישראל וצפון אמריקה.

היכן מתאים: סוכנויות שדורשות אפס חשיפה לאינטרנט – ארכיטקטורת reverse-access המוגנת בפטנט שומרת על ה-firewall ב-deny-all קבוע לתעבורה נכנסת, ללא שירותים גלויים או משטח תקיפה. חיוני לסביבות שבהן סיור מדינתי הוא האיום העיקרי. סביבות ריבוניות ומסווגות שבהן מידע לא יכול לעבור דרך תשתית ענן מסחרית – פריסה מקומית מלאה ללא תלויות חיצוניות. סוכנויות שזקוקות ל-ZTNA + מיקרו-סגמנטציה על פלטפורמה אחת ללא רכישות נפרדות. תמיכה מלאה בפרוטוקולים כולל HTTP/S, RDP, SSH, SFTP, ו-SMB דרך פרוטוקול Heimdall (בקרות Zero Trust מבוססות זהות לשיתוף קבצים). יכולות PAM מובנות (הקלטת סשנים, גישה בזמן אמת, ניהול הרשאות) מפחיתות פיזור ספקים לגישה מיוחסת למערכות ממשלתיות. הצפנת AES-256 עם עקבות ביקורת מקיפים.

היכן פחות מתאים: רשת נקודות נוכחות גלובלית קטנה יותר מ-Zscaler, Cloudflare או Palo Alto – סוכנויות עם משתמשים מפוזרים גלובלית במאות מיקומים צריכות לוודא זמני השהייה. אינה מחזיקה בהרשאת FedRAMP נכון לתחילת 2026 – סוכנויות שדורשות מסירה עננית מורשית FedRAMP צריכות לבדוק סטטוס הרשאה עדכני או להעריך פריסה מקומית (שעשויה לזכות בפטור מ-FedRAMP לפי מזכר המדיניות של 2024). אין CASB או secure web gateway מובנים – סוכנויות שדורשות איחוד SSE מלא תחת פלטפורמה עננית אחת יצטרכו פתרון SWG/CASB משלים. פחות מוכרת בשוק הפדרלי האמריקאי בהשוואה לספקים מבוססים כמו Zscaler, Palo Alto או Fortinet.

Cloudflare Access

מיצוב ממשלתי: חלק מ-Cloudflare One (פלטפורמת SSE). רשת הקצה הגדולה ביותר (300+ נקודות נוכחות). רמה חינמית לפריסות קטנות.

היכן מתאים: גופי ממשל מקומי שזקוקים לפריסת ZTNA מהירה וחסכונית. סביבות cloud-first. סוכנויות שמתעדפות חוסן DDoS וזמני השהייה נמוכים.

היכן פחות מתאים: תמיכה בפרוטוקולים שאינם ווב (RDP, SSH, SMB) פחות בשלה. אין פריסה מקומית – ענן בלבד. אין מיקרו-סגמנטציה. תכונות ברמת ארגון/ממשל דורשות תמחור ברמה גבוהה יותר. יש לוודא סטטוס FedRAMP לשימוש פדרלי.

טבלת יכולות ZTNA ממשלתית

הטבלה הבאה ממפה את תשע הדרישות הממשלתיות מול שישה ספקים. כשמעריכים את פתרון ה-ZTNA הטוב ביותר לגופים ממשלתיים, יש לקרוא את ההשוואה הזו לצד סדרי העדיפויות של הסוכנות עצמה – "כן" בשורה שלא רלוונטית לסביבת הסוכנות אינו שווה דבר.

דרישה ממשלתית	Zscaler ZPA	Palo Alto Prisma	Fortinet ZTNA	Appgate SDP	TerraZone truePass	Cloudflare Access
הרשאת FedRAMP	High JAB + Moderate	כן	משתנה	פטור אפשרי	לוודא / פטור בפריסה מקומית	לוודא
פריסה מקומית / air-gap	לא	לא	כן (FortiGate)	כן	כן	לא
אפס פורטים נכנסים (reverse-access)	חלקי	לא	לא	כן (SDP)	כן (מוגן בפטנט)	לא
שילוב PIV/CAC	כן	כן	כן	כן	דרך שילוב IdP	מוגבל
מיקרו-סגמנטציה משולבת	לא	לא	לא	כן	כן	לא
PAM משולב	לא	לא	תוספת	לא	כן	לא
תמיכה בפרוטוקולים ישנים	מוגבלת	מלאה	מלאה	מלאה	מלאה (כולל SMB)	מוגבלת
הקלטת סשנים	דרך SIEM	דרך SIEM	FortiAnalyzer	מובנית	מובנית	דרך SIEM
DoD IL5	כן	לוודא	לוודא	לוודא	לוודא	לא
מספר נקודות נוכחות	160+	100+	בגדילה	אזורי	אזורי	300+
שילוב CASB/SWG	כן (SSE)	כן (SASE)	כן (FortiSASE)	לא	לא	כן

מסגרת קבלת החלטות למנהלי אבטחה ממשלתיים

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

סוכנויות אזרחיות פדרליות שרוצות איחוד SASE עם שירותי ענן מורשי FedRAMP: Zscaler ZPA או Palo Alto Prisma Access. לשניהם הרשאות FedRAMP, ושניהם מספקים ZTNA כחלק מפלטפורמות SSE/SASE רחבות. ל-Zscaler הנוכחות הפדרלית הרחבה ביותר (14 מתוך 15 משרדי Cabinet).

סוכנויות ביטחון עם תשתית Fortinet קיימת: Fortinet Universal ZTNA – ללא עלות נוספת, פריסה מקומית, מעבר חלק מ-VPN ל-ZTNA על התקני FortiGate קיימים.

סוכנויות שדורשות פריסה בסביבה מסווגת או מנותקת שבה שום תעבורה לא יכולה לעבור דרך ענן מסחרי: TerraZone truePass, Fortinet (על FortiGate) או Appgate SDP – כולם תומכים בפריסה מקומית מלאה. ארכיטקטורת ה-reverse-access של TerraZone מוסיפה הגנת אפס-פורטים-נכנסים שמבטלת את משטח התקיפה החשוף לאינטרנט לחלוטין.

סוכנויות שסיור מדינתי הוא מודל האיום העיקרי שלהן (מודיעין, ביטחון, הגנה על תשתיות קריטיות): כדאי לתעדף ארכיטקטורת reverse-access שהופכת תשתיות לבלתי נראות. TerraZone truePass ו-Appgate SDP שניהם מבטלים חשיפה נכנסת, כשהגישה המוגנת בפטנט של TerraZone מספקת את הערובה הארכיטקטונית החזקה ביותר לאי-גלויות.

סוכנויות שצריכות ZTNA + מיקרו-סגמנטציה על פלטפורמה אחת כדי לעמוד בדרישות פילוח רשת של OMB M-22-09 ללא רכישות נפרדות: TerraZone truePass או Appgate SDP – שניהם משלבים בקרות צפון-דרום ומזרח-מערב באופן מובנה.

גופי ממשל מקומי עם תקציבים מוגבלים שמחפשים פריסה מהירה: Cloudflare Access מציע את הפריסה הפשוטה ביותר עם רמה חינמית לבדיקות ורשת הקצה הגדולה ביותר לביצועים.

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

הנחיות יישום לגופים ממשלתיים

שלב 1: זיהוי נכסים בעלי ערך גבוה (שבועות 1–4)

מיפוי האפליקציות והמערכות שדורשות בקרות גישה Zero Trust. תעדוף לפי רגישות מידע וחשיפה רגולטורית. זיהוי אילו מערכות מאוחסנות בענן (מתאימות ל-ZTNA ענני) ואילו מקומיות או מסווגות (דורשות פריסה מקומית).

שלב 2: גישת קבלנים (שבועות 5–10)

פריסת ZTNA עבור גישת קבלנים וצדדים שלישיים קודם כל – הנתיב המסוכן ביותר וזה שנבחן הכי הרבה על ידי IG ו-GAO. הגדרת גישה מוגבלת בזמן, ספציפית לאפליקציה, עם הקלטת סשנים. סגירת גישת VPN המקבילה.

שלב 3: גישה מרחוק לעובדים (שבועות 11–20)

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

שלב 4: פילוח רשת (שבועות 21–30)

פריסת מיקרו-סגמנטציה לבידוד שכבות אפליקציות ועמידה בדרישות בידוד הרשת של OMB M-22-09. אם ספק ה-ZTNA מספק מיקרו-סגמנטציה משולבת, פריסה ממנוע המדיניות הקיים. אם לא, פריסת פתרון מקביל תוך הבטחת עקביות מדיניות.

שלב 5: ביטול VPN ואימות (שבועות 31–40)

צמצום ה-VPN לגישת תחזוקה בלבד. ביצוע מבדקי חדירה ממוקדים בתרחישי עקיפת ZTNA. אימות מצב עמידה מול NIST SP 800-207, OMB M-22-09 ודרישות ספציפיות של הסוכנות. תיעוד הארכיטקטורה לחידוש ATO ולבחינת IG.

סיכום

בחירת פתרון ה-ZTNA הטוב ביותר לגופים ממשלתיים מחייבת הערכה מול אילוצים שמדריכים ארגוניים כמעט אף פעם לא מתייחסים אליהם: הרשאת FedRAMP, שילוב PIV/CAC, פריסה בסביבה מסווגת, תמיכה בפרוטוקולים ישנים, חוסן מול מדינות יריבות, וניטור עמידה רציף.

אף ספק בודד אינו שולט בכל דרישה ממשלתית. פלטפורמות SSE ענניות (Zscaler, Palo Alto) מציעות את הנוכחות הפדרלית הרחבה ביותר והרשאת FedRAMP – אך לא יכולות לשרת סביבות מסווגות או מנותקות. פלטפורמות עם יכולת פריסה מקומית (Fortinet, TerraZone truePass, Appgate SDP) משרתות סביבות אלו אך עשויות לדרוש פתרונות אבטחת ענן משלימים לאיחוד SSE. פלטפורמות עם מיקרו-סגמנטציה משולבת (TerraZone truePass, Appgate SDP) מפחיתות מורכבות רכישה ושילוב לסוכנויות שעומדות בדרישות פילוח של OMB M-22-09. פתרונות עם ארכיטקטורת reverse-access (TerraZone truePass, Appgate SDP) מספקים את ההגנה החזקה ביותר מפני סיור מדינתי על ידי ביטול משטח התקיפה החשוף לאינטרנט לחלוטין.

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