למה להגן על סיסמה אם אפשר לוותר עליה?

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

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

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

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

אבל מה קורה כשמספר הפרויקטים גדל לעשרה, לעשרים או לשלושים?

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

לכן, כל אחד מהם זקוק למנגנון גישה ניהולית.

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

זה עבד.

אבל בשלב מסוים תהיתי: למה בכלל עליי לשמור כל כך הרבה סיסמאות ניהול? למה אני צריך להגן לא רק על השרתים, אלא גם על האמצעים שמאפשרים לקבל גישה אליהם?

והאם אפשר לוותר על הצורך הזה?

הגעתי לרעיון שהפך בהמשך לבסיס הפתרון שלי:

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

ומה אם בכלל לא יהיה דף כניסה מוכר?

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

לא רק להסתיר את טופס הכניסה.

לא לשנות את כתובת הכניסה.

לא להחליף את הסיסמה בסיסמה מורכבת עוד יותר.

אלא להסיר את הצורך בנקודת כניסה מבוססת סיסמה שקיימת באופן קבוע.

כמובן, ממשקי הניהול לא נעלמו. הם עדיין נחוצים לניהול היישומים.

מה שהשתנה הוא אופן קבלת הגישה אליהם.

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

במקום זאת, אני משתמש במערכת זיהוי וניהול גישה משלי, MeldID.

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

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

יש להעניק את הזכות הזאת בנפרד.

גישה שלא הייתה קיימת לפני דקה

זו, כנראה, הנקודה המעניינת ביותר בכל הרעיון.

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

החלטתי לשנות את העיקרון הזה.

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

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

אבל עצם ההחזקה בקישור הזמני הזה עדיין לא מקנה גישה.

זו נקודה עקרונית.

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

במודל שלי, הקישור רק מאפשר להתחיל את תהליך האימות.

כדי להמשיך, נדרש אישור נפרד דרך מכשיר נייד מהימן של MeldID.

בלי האישור המתאים, לא נוצרת הפעלה ניהולית.

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

לדעת לאן לפנות ולהיות מורשה להיכנס — אלה שני דברים שונים לחלוטין.

הטלפון הופך לכלי לניהול גישה

במודל הזה, למכשיר הנייד יש תפקיד חשוב הרבה יותר מזה של מחולל קודים חד-פעמיים רגיל.

הוא משמש לאישור פעולות הקשורות לגישה ניהולית.

כשאני רוצה לפתוח את לוח הניהול, המערכת מבקשת אישור דרך MeldID.

אני רואה את הבקשה המתאימה במכשיר מהימן ומאשר את הפעולה.

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

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

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

הגישה הזאת מאפשרת לא להסתמך רק על סיסמה או על הודעה שלפיה המשתמש כביכול אישר את הכניסה.

וכאן מופיע יתרון נוסף: אפשר לנהל את המכשירים המהימנים.

אם אין עוד להשתמש במכשיר לאישור גישה, אפשר לבטל את מעמדו כמכשיר מהימן.

לאחר מכן הוא מפסיק לשמש אמצעי אימות תקף לפעולות הרלוונטיות.

מערכת אחת — פרויקטים עצמאיים רבים

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

לא רציתי לאחד את כל לוחות הניהול ליישום ענק אחד.

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

לכן הפרדתי בין שתי משימות.

MeldID אחראית לזיהוי ולהענקת הרשאה ניהולית.

הפרויקט עצמו אחראי לפונקציות הניהול שלו ולבדיקת ההרשאות התקפות.

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

בנוסף, ההרשאות ניתנות בנפרד.

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

אפשר להגדיר לכל תחום ניהול מעגל משתמשים מורשים משלו.

במקביל, זכויות של משתמשים רגילים והרשאות ניהוליות נשמרות בנפרד.

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

למה אני מעדיף גישה זמנית על פני גישה קבועה

יש עיקרון נוסף שהכנסתי למערכת במכוון.

גישה ניהולית לא צריכה להישמר ללא הגבלת זמן.

ההרשאה תקפה לזמן מוגבל ופוקעת גם אם המשתמש עדיין עובד בדפדפן.

כדי להמשיך לעבוד לאחר פקיעת התוקף, נדרש תהליך אישור חדש.

כך ניתן להימנע מהפיכת אימות שבוצע פעם אחת לזכות קבועה.

אבל הגבלת זמן לבדה אינה מספיקה.

חשובה גם האפשרות להפסיק מוקדם את הגישה שכבר ניתנה.

לכן MeldID כוללת מנגנון מרכזי לביטול הרשאות ניהוליות.

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

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

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

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

מה השתנה בעבודה היומיומית?

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

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

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

בוחר את הפרויקט הדרוש, מאשר את הגישה ועובד.

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

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

מספיק לחבר אותו למודל הקיים ולהגדיר את ההרשאות הנדרשות.

כמובן, אין פירוש הדבר שכל סיכוני האבטחה נעלמו.

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

אבל כבר אין צורך לפתור בנפרד את אותה בעיה של ניהול סיסמאות ניהוליות בכל יישום.

וזו הייתה אחת המטרות הראשוניות שלי.

האם טכנולוגיות כאלה כבר קיימות?

כמובן.

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

גישות כאלה קיימות במערכות לניהול זהויות וגישה (Identity and Access Management), בניהול גישה מיוחסת (Privileged Access Management) ובתפיסות Zero Trust.

אינני מתיימר להמציא את העקרונות האלה.

המשימה שלי הייתה אחרת.

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

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

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

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

MeldID לא מיועדת רק ללוחות ניהול

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

MeldID לא נוצרה רק ככלי לגישה הניהולית שלי.

היא גם מספקת למפתחים SDK לשילוב מנגנוני זיהוי ואישור כניסה ביישומים שלהם.

ה-SDK הזה זמין בחינם.

למשל, מפתח חיצוני יכול להשתמש ב-MeldID כשכבת אישור נוספת לאימות משתמשים.

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

המשתמש מקבל בקשה במכשיר נייד מהימן, ושם הוא מאשר או דוחה את ניסיון הכניסה.

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

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

הם נשענים על עקרונות משותפים של אמון ואישור פעולות, אך נותנים מענה למשימות שונות.

אבטחה אינה רק הגנה על מה שכבר קיים

העבודה על המערכת הזאת גרמה לי להתבונן אחרת במנגנוני האימות המוכרים.

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

מוסיפים בדיקות חדשות, הגבלות, סיסמאות נוספות ושכבות הגנה.

לפעמים זה אכן נחוץ.

אבל לפעמים כדאי לשאול שאלה אחרת:

האם המנגנון שעליו אנחנו מגינים חייב בכלל להמשיך להתקיים באותה צורה?

במקרה שלי, התשובה הייתה שלילית.

לא הייתי זקוק לטופס כניסה ניהולית שזמין כל הזמן.

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

אלה שתי משימות שונות.

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

לא נקודת סיום, אלא כיוון שבחרתי

כיום הארכיטקטורה הזאת כבר פועלת בחלק ניכר מהאקוסיסטם של DigiMeld.

הפרויקטים שנותרו עוברים בהדרגה למודל החדש של גישה ניהולית.

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

פרטים מסוימים בממשק וכללים לניהול הפעלות עדיין עשויים להשתנות.

אבל הרעיון המרכזי כבר ברור.

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

עם זאת, אינני רואה במימוש שלי פתרון אוניברסלי שמתאים לכולם.

לארגונים שונים יש דרישות, תשתיות, מודלי איומים ושיטות ניהול שונות.

מה שנוח ומתאים לאקוסיסטם של DigiMeld לא בהכרח יהיה אופטימלי עבור מפתח אחר.

עם זאת, עקרון הענקת ההרשאות הזמנית ראוי לתשומת לב.

לסיכום

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

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

אבטחה מוחלטת אינה קיימת.

פשוט נראה לי שהשאלה עצמה מעניינת.

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

במקום לשמור הרבה סיסמאות — להשתמש בהרשאות זמניות.

במקום לתת אמון אוטומטי אחרי האימות הראשון — לאשר הענקה של הרשאות מסוימות.

במקום להמתין לפקיעת ההפעלה — לאפשר ביטול מרכזי של הגישה.

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

אינני טוען שהגישה הזאת מונעת לחלוטין אפשרות של פריצה.

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

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

זאת הייתה המחשבה שממנה התחיל עבורי הסיפור של MeldID Admin Gateway.