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

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

למה מודל האמון הישן כבר לא עובד

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

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

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

הטמעת גישת Zero Trust ארגונית מתחילה במיפוי, לא ברכש

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

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

כדאי להתחיל מארבע שאלות תפעוליות:

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

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

הזהות היא נקודת הבקרה הראשונה

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

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

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

בדיקת מכשיר לפני גישה אינה מותרות

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

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

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

צמצמו הרשאות ותנועה רוחבית

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

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

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

לוגים ללא תהליך תגובה אינם הגנה

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

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

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

רישוי הוא חלק מהבקרה, לא משימה של רכש בלבד

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

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

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

מדדו התקדמות לפי סיכון שהצטמצם

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

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