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

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

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

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

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

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

מורכבות אינה זהות משתמש

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

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

שכבות ההגנה שצריכות להחליף את ההסתמכות על סיסמה

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

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

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

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

איפה להתחיל בלי להפוך את הפרויקט למבצע אינסופי

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

1. מיפוי החשבונות בעלי הסיכון הגבוה ביותר: מנהלי דומיין, מנהלי ענן, דוא"ל, VPN, מערכות כספים, מערכות גיבוי וחשבונות של ספקים.
2. בדיקה אילו חשבונות מוגנים בסיסמה בלבד, אילו משתמשים חולקים גישה, ואיפה קיימים חשבונות שירות ללא בעלים עסקיים מוגדרים.
3. החלת MFA עמיד לפישינג תחילה על בעלי הרשאות, ולאחר מכן על כלל המשתמשים לפי קבוצות ויישומים.
4. הטמעת מנהל סיסמאות ארגוני עם מדיניות ברורה: סיסמאות ייחודיות, איסור שיתוף דרך דוא"ל או גיליונות, והעברת בעלות מסודרת בעת שינוי תפקיד.
5. בניית נוהל תגובה לחשד להשתלטות: ביטול סשנים פעילים, איפוס גורמי אימות, בדיקת כללי העברת דואר, סקירת הרשאות אפליקציות ובחינת פעילות חריגה.

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

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

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

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

אבטחת זהויות היא גם עניין של רישוי ותפעול

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

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

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

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