הסיסמה לחשבון הענן נמצאת בקובץ Excel של הצוות. סיסמת ה-VPN נשלחת לעובד חדש בהודעת צ'אט. לחשבון ספק חיצוני נכנסים עם משתמש אחד, כי "זה רק זמני". אלו דפוסים מוכרים, ולעיתים הם נוצרים מתוך צורך תפעולי אמיתי. בפועל, סיכוני סיסמאות משותפות הופכים גישה נוחה לכשל אבטחה, תאימות ובקרה שקשה מאוד לתחקר לאחר אירוע.
הבעיה אינה רק עצם החשיפה של הסיסמה. ברגע שכמה אנשים משתמשים באותו חשבון, הארגון מאבד את היכולת לדעת מי עשה מה, מתי ומדוע. כאשר אותו חשבון מחזיק גישה למידע רגיש, למערכות ייצור או לפורטלים של ספקים, המחיר יכול להיות שעות חקירה, השבתת שירות, סיכון למידע עסקי ולעיתים גם חריגה מדרישות רגולטוריות.
למה סיסמה משותפת היא בעיית ניהול, לא רק בעיית אבטחה
קל לראות בסיסמה משותפת עניין טכני: מחליפים אותה מדי פעם, שומרים אותה במקום "מאובטח" וממשיכים לעבוד. אבל בארגון בינוני או גדול מדובר קודם כל בכשל של ניהול זהויות. זהות דיגיטלית אמורה להיות משויכת לאדם, לתפקיד או לתהליך מוגדר. סיסמה משותפת מטשטשת את שלושתם.
כאשר עובד עוזב, למשל, אין דרך פשוטה להסיר רק את הגישה שלו. יש להחליף את הסיסמה לכל המשתמשים, לעדכן אינטגרציות שעשויות להסתמך עליה ולוודא שלא נשאר עותק במערכת תיעוד, בדפדפן או בטלפון אישי. בפועל, ארגונים רבים דוחים את ההחלפה כדי לא להפריע לעבודה. כך נוצרת גישה עודפת שנשארת חודשים ואף שנים לאחר שהצורך המקורי נעלם.
גם באירוע אבטחה, הלוגים מאבדים מערכם. אם התחברות חשודה בוצעה מחשבון צוותי, אפשר לדעת שהחשבון שימש, אך קשה להוכיח אם הפעולה בוצעה על ידי עובד, ספק, משתמש שהודלף לו הסוד או גורם חיצוני. עבור CISO, זו אינה שאלה תיאורטית. זו נקודת עיוורון בזמן תגובה לאירוע.
סיכוני סיסמאות משותפות: איפה הנזק מתחיל
התרחיש הבולט הוא דליפה. סיסמה שמועברת בצ'אט, בדוא"ל או בגיליון משותף עשויה להגיע בקלות ליעד הלא נכון, להישמר בתחנת קצה לא מנוהלת או להיכלל בגיבוי. אבל דליפה היא רק חלק מהתמונה.
הסיכון השני הוא הרשאות יתר. חשבונות משותפים נבנים לרוב לפי המכנה המשותף הגבוה ביותר: כדי שכל חברי הצוות יוכלו לבצע את עבודתם, כולם מקבלים את אותה גישה. עובד שזקוק לצפייה בלבד מקבל לעיתים גם יכולת למחוק, לייצא או לשנות הגדרות. העיקרון של Least Privilege נשאר על הנייר.
הסיכון השלישי הוא שימוש חוזר. אותה סיסמה משותפת נוטה להופיע ביותר ממערכת אחת - פורטל רכש, חשבון ענן, כלי תמיכה מרחוק או ממשק ניהול. דליפה של מערכת אחת הופכת במהירות לניסיון גישה רוחבי. MFA מצמצם משמעותית את הסיכון, אך הוא לא פותר אותו כאשר גורם שני משותף, מאושר אוטומטית או נמצא בשליטתו של אדם שכבר אינו אמור להיות בתהליך.
יש גם עלות תפעולית שקשה למדוד בתחילת הדרך. כל החלפת סיסמה ידנית יוצרת קריאות שירות, תקלות התחברות, חוסר ודאות אצל ספקים ועיכובים במשימות דחופות. ככל שהסוד משותף ליותר אנשים וליותר מערכות, כך עלות השינוי גבוהה יותר - ולכן השינוי נדחה.
מתי חשבון משותף הוא סימפטום לתהליך חסר
לא כל מצב של גישה משותפת מעיד על רשלנות. לעיתים צוות NOC צריך גישת חירום, צוות תמיכה זקוק לכניסה למערכת ספק, או שירות אוטומטי נדרש להתחבר לממשק שאינו תומך בזהויות אישיות. הבעיה מתחילה כשמשתמשים בסיסמה אנושית משותפת כתחליף לתכנון.
כדאי להבחין בין חשבון משותף של בני אדם לבין חשבון שירות. חשבון שירות נועד לתהליך או לאינטגרציה, צריך להיות בעל הרשאות מינימליות, מתועד, מנוטר ומנוהל במחזור חיים מסודר. חשבון אנושי משותף, לעומתו, כמעט תמיד מקשה על אחריותיות ועל ביטול גישה.
גם חשבון Break-Glass עשוי להיות מוצדק. זהו חשבון חירום למקרה שבו שירות הזהויות המרכזי או ה-SSO אינם זמינים. אלא שחשבון כזה צריך להיות חריג, לא דרך העבודה הרגילה: מוגן ב-MFA נפרד ככל האפשר, מאוחסן בכספת, עם נוהל שימוש, התרעות ובדיקות תקופתיות. אם משתמשים בו פעם בשבוע, הוא אינו חשבון חירום אלא סימן לבעיה בארכיטקטורת הגישה.
מעבר מסיסמאות משותפות לבקרת גישה אמיתית
הפתרון אינו בהכרח פרויקט זהויות ארוך ומורכב. בארגונים רבים אפשר להתחיל במיפוי ממוקד של החשבונות המשותפים בעלי ההשפעה הגבוהה ביותר: גישת אדמין, מערכות פיננסיות, מערכות ענן, כלי אבטחה, גיבויים, VPN ופורטלים של ספקים.
לכל חשבון יש להגדיר בעלים עסקי ובעלים טכני. הבעלים העסקי מאשר מי צריך גישה ולמה. הבעלים הטכני אחראי על ההגדרה, על אכיפת MFA, על ניהול ההרשאות ועל תיעוד שינויי הגישה. ללא בעלות ברורה, חשבונות כאלה הופכים במהירות ליתומים.
