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

מה משתנה כשמיישמים Zero Trust בפועל?

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

עקרון ה-zero trust הלכה למעשה מתחיל במיפוי

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

קודם כל: זהויות והרשאות

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

MFA הוא תנאי בסיס, לא כל התוכנית

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

עמדת הקצה היא חלק מהחלטת הגישה

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

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

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

מדידה, תחקור ורישוי: החלק שפחות מדברים עליו

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

תוכנית התחלה מעשית ל-90 יום

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