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

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

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

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

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

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

סיכוני סיסמאות משותפות: איפה הנזק מתחיל

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

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

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

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

מתי חשבון משותף הוא סימפטום לתהליך חסר

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

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

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

מעבר מסיסמאות משותפות לבקרת גישה אמיתית

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

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

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

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

מה לעשות עם מערכות שלא תומכות במשתמשים אישיים

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

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

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

מדדים שמראים אם התהליך באמת משתפר

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

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

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

תהליך קטן שמקטין סיכון גדול

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

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