מכללת טרביצקי| פרק רביעי - הזדהות פנים ארגונית

שוב שלום לכולם,

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

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

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

אז בוא נתחיל. ראשית, חשוב להבין מה ההגדרה של הזדהות.בהגדרה, הזדהות היא דרך או שיטה לזהות את הישות (שיכולים להיות משתמש או מחשב) שמנסה לגשת למערכת. בנוסף, שיטת הזדהות צריכה לכלול מנגנונים שימנעו התחזות לאחר, שכפול והתקפה של Man in the Middle. בפועל, המצב לא כזה וורוד, אני אראה לכם בהמשך. בתקשורת מחשבים יש מושג שראשי תיבות שלו באנגלית AAA - Authentication Authorization Accounting. למעשה המושג הזה בא לאחד את כל התהליך מרגע ההתחברות לרשת ועד לקבלת גישה באמצעות הזדהות. התהליך כולל הזדהות, מתן הרשאות (אוטוריזציה) וניהול רישום של ההזדהות מתחילת החיבור ועד סופו (בד״כ לצורך חיוב או תיעוד).
היום אני הולך לדבר על טכנולוגיות הזדהות שנועדו בעיקר לשימוש בתוך הארגון, זאת אומרת ברשתות הפנימיות שלו. בגדול, חלוקה כזאת לא קיימת, אני המצאתי אותה כאן על מנת איכשהו לחלק את כל שיטות ההזדהות, ויש הרבה, יש שיטות להזדהות של משתמש בתחנה, יש שיטות הזדהות של התחנה עצמה, לפני שהמשתמש בכלל פתח אותה, יש התחבות ורשתות אלחוט, יש חיבור מהבית, שעון נוכחות ואיפלו תלושי ארוחת צהריים צריכים הזדהות. וזאת רק ההתחלה. כפי שאתם רואים, כשלמודים את כל הדברים האלה בבת אחת, או שהולכים לעשות CCIE, או שהולכים לאשפוז, לכן החלטתי לחלק את הטכנולוגיות לפי הטופולוגיה הארגונית (למתקשים, לפי מיקומו של מי שצריך להזדהות). כשאני אומר פנים ארגוני, אני מתכוון למצבים בהם משתמש או מכונה שנמצאים בתוך הרשת הארגונית מנסים להזדהות מול המערכת ולקבל גישה או משאב. תרחיש נוסף הוא שציוד proxy שולח הזדהות בשם משתמש או מחשב שנמצא מחוץ לרשתות פנימיות. זה מצב שכיח בהתחברות מרחוק או בהתחברות בwifi. בפוסט הזה אנו נתיחס רק לחלק שבין הproxy לבין הישות המזהה, זאת אומרת לתעבורה שעוברת בתוך הארגון. באזורים האלה של הרשת בדרך כלל שולטים הפרוטוקולים הבאים:

• RADIUS או +TACACS
• LDAP
• KERBEROS
• SQL שלא כלכך נחשב לפרוטוקול הזדהות, אך קשור להזדהות בweb application. אני אתיחס בקצרה גם אליו.

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

RADIUS או +TACACS

הסיבה ששמתי אותם ביחד היא בגלל שהם בסופו של דבר שני גישות שונות לאותה בעיה.
מדובר בשני פרוטוקולים הכי ״טפישיים״ מבין כל אלה שאנו סוקרים היום. למה ״טיפשיים״, משום שכל תפקידם הוא לשלוח בקשת הזדהות לשרת ולקבל תשובה ממנו. הפרוטוקולים הללו לא מגדירים בסיס נתונים של משתמשים או קבוצות או מידור. לרוב, שרת RADIUS מחזיק רשימת משתמשים מקומית או מתחבר לשרתי משתמשים חיצוניים כגון LDAP או Active Directory. מה שכן, הפרוטוקולים הללו ״גמישים״ וניתן, בנוסף לתשובה ״מורשה״ או ״לא מורשה״ להוסיף תוכן או הרשאות בעזרת attributes שזה בעצם שדות שנשלחים בתוך הפאקטים של הפרוטוקול. למשל, אם נדרש לאחר ההזדהות, למקם את המשתמש בvlan מסויים, אז אחרי שליחת בקשת הזדהות (ע״י בקר אלחוטי למשל) השרת מחזיר בתשובה שלו את מס׳ הvlan והבקר ממקם את המשתמש בהתאם לattribute הזה. הפרוטוקולים הללו נמצאים בד״כ בשימוש ע״י מה שנקרה authenticators. אלו הם proxies של הזדהות כגון RASים, מתגים, נתבים, בקרי אלחוט ובקרי גישה מרחוק. משתמשים בד״כ לא פונים ישירות לשרתים הללו.
אז מה ההבדלים בין RADUIS לTACACS - בעצם אין כל כך הרבה,

• RADIUS הינו תקן פתוח וTACACS שייך לחברת סיסקו . 
• RADIUS מצפין רק את הססמאות (MD5 hash לא בדיוק הצפנה), כשהTACACS מצפין את כל התעבורה שלו.
• RADIUS עבור על פרוטוקול UDP ודורש שני פורטים - אחד עבור ההזדהות ואחד עבוד הרישום - accounting, כאשר TACACS עובד על TCP פורט 49.

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

LDAP

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

על אף שהפרוטוקול עצמו בינרי, המבנה של העץ נהוג להציג בפרומט LDIF שנראה כך:

 dn: cn=John Doe,dc=example,dc=com

 cn: John Doe

 givenName: John

 sn: Doe

 telephoneNumber: +1 888 555 6789

 telephoneNumber: +1 888 555 1232

 mail: john@example.com

 manager: cn=Barbara Doe,dc=example,dc=com

 objectClass: inetOrgPerson

 objectClass: organizationalPerson

 objectClass: person

 objectClass: top

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

• LDAP מעביר ססמאות בתווך, בצורה מוצפנת או לא מוצפנת. OpenLDAP תומך בSHA1,MD5 וcrypt. מיקרוספוט תומכים בNT hash. בכל מקרה, להעביר ססמאות על גבי הרשת זה רעיון לא כל כך טוב.
• LDAP תומך רק בהזדהות בשם משתשמש וססמה. גם אם אתם מזדהים עם תעודה, בסופו של דבר, הauthenticator יחלץ מתוך התעודה את שם המשתמש ויזדהה איתו.
• LDAP לא מודע לשכובות שמתחתיו, מה שחושף אותו להתקפות מסוג replay.
• LDAP לא מספק SSO. אם רוצים להפעיל SSO, יש צורך להעזר בספקי הSSO, אשר משתשמש בשאילתות LDAP.
• LDAP לא תומך באצילת סמכויות (delegation). זאת אומרת שמשתמש או מכונה מסויים יכולים להזדהות בשם משתמש אחר.
• לLDAP אין תוקף להזדהות מוצלחת. LDAP לא באמת יודע מה עושים ולכמה זמן עם התשובה החיובית שהוא החזיר לauthenticator.

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

• anonymous - כל בקשה תקבל שתובה.
• simple - בנוסף לקשה, נדרש לספק פרטי משתמש bind. זאת צורת עבודה מקובלת ברוב המקרים.
• SASL - הזדהות יותר חזקה בעזרת challenge מאובטח.בד״כ נמצא בשימוש ע״י Kerberos לצורך שאילתות.

בתצורת simple אנו בד״כ נכניס את כתובת שרת LDAP, פורט שהוא מאזין (389tcp/udp לLDAP ו636 לLDAPS) , נאפשר SSL, ניתן שם משתמש bind וססמתו וגמרנו את ההגדרות. בשונה משרתי RADIUS/TACACS שבהם נדרש להגדיר את כתובות הauthenticatorים וססמאותיהם, כאן לא נדרש לבצע כל שינוי בצד השרת.

ואם אני רוצה יותר security ? יותר אופציות ? יותר נוחות ??? - בשביל זה יש לי את Kerberos !!!

Kerberos

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

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

• בקרברוס סיסמת הגורם המאומת אף בעם לא עוברת בתווך. למעשה הקליינט מצפין את שאילתת הבקשה עם הססמה שלו, והשרת מחזיר את התשובה שכוללת את כל מאפייני המשתמש מוצפנת עם הססמה של הקליינט. אם הקליינט הצליח לפענח את התשובה, אזהי הססמה תקינה וההזדהות עברה בצורה תקינה, אחרת הקלייט מניח שהססמה שגויה.לאחר התחברות מוצלחת הקליינט מקבל מהשרת session key שמוצפן בעזרת סיסמת המשתמש, בעזרתו הקליינט יצפין את התעבורה של אותו session. 
• אחרי שהגורם המאומת קיבל אישר חיובי עבור ההזדהות, נפתח עבורו ״כרטיס״ ובו פרטי המשתשמ שכוללים כתובת המשתמש - client network address, שם משתמש - client ID, תאריך התחברות ותוקף הכרטיס, כלומר כל הזדהות בקרברוס יש תוקף. בחלונות, למשל תוקף כרטיס משתמש הוא 10 שעות. הערה: למעשה, לקרברוס יש שני סוגי תוקף כרטיס - תוקף הכרטיס, ticket lifetime, ותוקף החידוש, renewal lifetime. כאשר נגמר תוקף הכרטיס, המשתמש או האפליקצייה יכולות לבקש משרת הקרברוס להאריך את תוקף הכרטיס ובמידה ותוקף החידוש לא פג, השרת יאריך את תוקף שכרכיס. בחלונות, ברירת המחדל לתוקף החידוש הינו 7 ימים, כלומר כעבור 10 שעות אחרי ההתחברות, המשתמש יכול לבקש להאריך את הsession שלו כל פעם בעוד 10 שעות ולעשות זאת למשך שבוע. במידה והקליינט לא ביקש הערכה, הכרטיס פג תוקף ונדרשת הזדהות מחדש.   
• יש הזדהות הדדית בין השרת לקליינט, כלומר השרת מוודא שהוא עובד מול משתמש נכון, אך גם הקליינט יודע לוודא כי הוא עובד מול השרת הנכון. בLDAP, למשל, אין יכולת כזאת.
• יכולת לעבוד עם אצילת סמכויות. Constrained delegation או KCD נמצאה כתכונה מאוד שימושית בקרב אנשי החלונות, ולא רק הם.למשל, constrained delegation מאפשרת לשרת ווב שנמצא באיזור אחר ברשת, לבצע אימות מול שרת הActive Directory (שזה בעצם LDAP) בפרוטוקול קרברוס בשם המשתמש שמנסה להתחבר לשרת הווב. כך אותו שרת יכול לעבוד מול כמה דומיינים בו זמנית, פר משתמש. את זה ניתן לבצע רק בקרברוס.
• יכולת (SSO (single sign-on מובנית.ביכולת הזאת מיקרוסופט עושה שימוש כבד בכל השירותים אשר מספקים שרתי חלונות למינהם, למשל שרת קבצים, exchange וכו׳. זה חוסך מהמשתמש להכניס את פרטי ההזדהות מחדש, כל פעם שהוא עובר לאפליקצייה אחרת שמזדהה מול אותו שרת קרברוס.
• יכולת עבודה מובנית עם מס׳ מנגנוני אימות כגון כרטיסי חכמים, קוראים ביאומטרים, טוקנים ועוד. 
• לקרברוס יש מנגנונים למניעת התקפות replay. למי שלא מכיר על מה אני מדבר כאן, ורואה את זה פעם שנייה בפוסט, אסביר, מדובר במצב שהתוקף הקליט תעבורה של הזדהות תקינה מבעוד מועד, ועכשיו הוא שולח את אותה תעבורה שהוא הקליט שוב לכיוון השרת במטרה שלקבל גישה מחדש.
• בפיירוולים מהדור החדש נעשה שימוש בקרברוס לצורך הפעלת יכולת של User Awarness, זאת אומרת, כתיבת החוקה לפי משתמשים או קבוצות ולא לפי כתבותIP, כמו בפיירוול הקלאסי. זה מאפשר למשתמש לקבל את אותה רמת גישה ללא התלות במיקום גאוגרפי.

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

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

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

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

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

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

קובי.