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