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

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

למה vpn כבר לא מספיק במבנה עבודה מודרני

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

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

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

הגישה הנכונה: זהות, מכשיר ויישום

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

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

אימות חזק הוא נקודת פתיחה, לא קו סיום

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

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

מצב המכשיר חייב להשפיע על ההחלטה

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

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

גישה ברמת היישום במקום פתיחת הרשת

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

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

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

איפה ארגונים נכשלים בפועל

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

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

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

איך מתחילים בלי להפוך את הפרויקט לשנתיים של דיונים

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

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

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

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