HTTPS חלק ג': שיקולים ליישום באפליקציה

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

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

Default Port שונה

בניגוד ל HTTP בו פורט (port) ברירת המחדל הוא 80, ב HTTPS, פורט ברירת המחדל הוא 443. כלומר: אם ב URL של HTTPS לא צויין port – אזי מדובר בפורט 443.

Overhead

כפי שציינתי בפוסט הראשון בסדרה, ל TLS ,בסה"כ, אין תקורה משמעותית:

  • כ 6% יותר נתונים עוברים ברשת (Headers נוספים וחתימה דיגיטלית מוסיפים, TLS דוחס את ה HTTP headers – מה שקצת חוסך).
  • שרת מודרני, משקיע כ 2.5ms זמן CPU לצורך TLS handshake של מפתח א-סימטרי ארוך (2K) – לא זמן משמעותי. בעבר היה מקובל להוציא את משימת ה TLS handshake לחומרה חיצונית (Load Balancer או CDN) שעשתה עבודה זו בעלות נמוכה יותר – אך נראה שמגמה זו פוחתת.
  • עבודת ה CPU בצד הלקוח היא לא משמעותית, אולי מלבד מכשירי מובייל (?!)
הנקודה היחידה בה יש הבדל ביצועים משמעותי בין HTTP ל HTTPS הוא יצירת ה connection ההתחלתי.

בפוסט הקודם הסברתי על מנגנון שנקרא Session Ticket שפוטר מהצורך שלנו לבצע TLS handshake לכל connection, כך שבסך הכל אנו יכולים לצפות ל 2 roundtrips נוספים לכל origin איתו אנו יוצרים קשר.

האמנם?

מקור: הבלוג של איליה גריגוריק. שווה לעקוב.

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

הנה, בתרשים למעלה, רואים גישה לאותו המשאב ב HTTP (שורה עליונה) מול HTTPS (שורה תחתונה), בהינתן RTT של כ 380ms.
ע"פ התאוריה, ניתן לצפון לעלות נוספת של 760ms (פעמיים 380ms) בביצוע TLS handshake, אבל הנה בדוגמה למעלה, ההפרש בפועל הוא כמעט 2000ms, כמעט פי 3 (!) ממה שציפינו.

בפוסט מעניין ויפה איליה גריגוריק מראה כיצד הוא מנתח ומתקן את המצב המתואר לעיל. הוא מזהה, ומתקן, "באפר" (congestion window) שקונפג בשרת בצורה שלא מטיבה עם ה TLS Handshake ואז הוא מוסיף עוד אופטימיזציה של TLS בכדי לצמצם את התקורה ל roundtrip בודד. סה"כ 2000ms הופכים ל 380ms – שיפור מרשים מאוד!
לא צריך להכיר את nginx (השרת המדובר) בכדי לקרוא את הפוסט.

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

עוד גורם שיכול לעכב קריאות HTTPS הוא הפעלה של פרוטוקול בשם Online Certificate Status Protocol (בקיצור: OCSP). זהו פרוטוקול המגביר את אמינות וידוא הזהות של HTTPS – במחיר ביצועים. ע"פ הפרוטוקול, כאשר הדפדפן מקבל Certificate הוא פונה ל CA שהנפיק אותו ומבקש לוודא שה Certificate עדיין תקף. סיבה ש Certificate לא יהיה תקף הוא אם המפתח הפרטי שהיה בשימוש ליצירת ה Certificate נגנב איכשהו, או שהתגלה שבעל ה Certificate הוא מתחזה / פועל בצורה לא כשרה. בחלק ב' של הפוסט שעסק ב Certificates לא כיסיתי את נושא ביטול (revocation) של Certificates – מפאת חוסר מקום / עניין נמוך לקורא.
אם המשתמשים שלכם מפעילים OCSP – אתם יכולים לבדוק את ה CA שלכם, עד כמה הוא מהיר בתגובות שלו לבקשת OCSP באזורים הגאוגרפים הרלוונטיים עבורכם. במידת הצורך, ניתן להחליף CA באחד זמין / מהיר יותר.

שווה לציין ששירותי (CDN (Content Delivery Networks, יכולים לקצר את זמני ה TLS handshake. ל CDNs יש תחנות הקרובות גאוגרפית למשתמש הקצה (ולכן יש להן latency נמוך יותר). משתמש הקצה מבצע TLS handshake מול התחנה הקרובה, של ה CDN, בה כל round-trip הוא זול יותר. מרגע שנוצר ה connection התחנה משתמשת כפרוקסי (מאובטח) לשרת שלכם (על גבי connection מאובטח שנפתח מבעוד מועד) או סתם מעבירה לכם TLS Session Ticket שאתו תוכלו לעבוד. ייתכן ובכלל התוכן זמין על cache של ה CDN ואין טעם להגיע בכלל לשרת היעד.
שירות זה נקרא TLS Early Termination, כאשר הכוונה במילה Termination היא "קיצור המסלול" ולא "סיום התקשורת".
שירות זה, עולה כסף – כמובן, ולא תמיד הוא זמין בכל אתר (או Point of Presence, בקיצור PoP) בה ה CDN פעיל.

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

Connection Termination

מתי שהוא, סיימנו את העבודה המאובטחת מול השרת, ואנו רוצים לסיים את תקשורת ה HTTPS.
דרך מחשבה אחת אומרת כך: "HTTPS חי על גבי TCP, לכן פשוט אפשר לסיים את connection ה TCP בעזרת הודעת TCP FIN – ולסיים עניין".
אולם, הודעת TCP FIN יכולה בעצם להישלח ע"י כל אחד, גם תוקף פוטנציאלי המנסה לשבש את התקשורת. לצורך כך נקבע שתקשורת TLS תסתיים ע"י הודעה ברמת ה TLS (הדלקת flag בשם close_notify) ורק לאחר מכן TCP FIN.

לא לבלבל נושא זה עם Early Termination.

הימנעות מ Mixed Content

אם אתם זוכרים את הפוסט הקודם, נרצה להימנע באתר שלנו מ mixed content: תוכן HTTP בתוך דף HTTPS.
כיצד עושים זאת?
הרבה פעמים ראיתי שפשוט כותבים קוד דומה לזה:

var url = location.url.startsWith('https')) ? HTTPS_URL : HTTP_URL 

זה עובד, אבל זה מעט מסורבל. ניתן פשוט לכתוב url יחסי יחיד שלא מגדיר פרוטוקול – והוא ישתמש, בהגדרה, בפרוטוקול של הדף, יהיה זה HTTP או HTTPS. למשל:

var url = "//myserver/resources/style.css";

זה נראה קצת מוזר, אבל זה תקני לחלוטין. ניתן למצוא עוד פרטים על URL יחסי בפוסט שלי על URLs.
מעניין לציין ששירותים שונים (למשל Google Libraries API) מגישים לנוחיותכם את אותם המשאבים גם על גבי HTTP וגם על גבי HTTPS – וממליצים פשוט להשתמש בסכמה שתארתי.

כדאי לציין שחלק משירותי האירוח יציעו לינק HTTPS כברירת מחדל (כדי להבטיח שקיבלתם מהם אכן את הקובץ שביקשתם, ולא ממתחזה). HTTPS בתוך HTTP לא יוצר בעיית "Mixed Content" – אך הוא פוגע בביצועים של הדף (כפי שצוין למעלה בפוסט).

HTTPS כפרוטוקול "VPN"

למרות ש HTTPS הוא לא פרוטוקול VPN, יש לו יתרון שהוא "עובר מסך" אצל firewalls ורכיבי רשת שונים בקלות יחסית:
"אם הצלחת ליצור קשר על גבי TLS עם השרת שלי – אני סומך עליך. אפילו שאין לי מושג (או יכולת לדעת) מה אתם מדברים ביניכם" אומר ה Firewall או ה Transparent Proxy לעצמו.

לאחר שה TLS Connection נוצר הוא מוצפן – ולכן הוא שקול לפרוטוקול בינרי, low level, בין הצדדים. לדוגמה: ניתן להפוך את כיוון התקשורת, להעביר מידע בינרי, להעביר הודעות בחלקים לא מסודרים וכו'. סוג של "TCP על גבי HTTPS" (ה HTTPS משמש בעיקר ל handshake, אח"כ ניתן לרדת חזרה לרמת ה TLS היותר בסיסית).

תכונה זו של HTTPS בשימוש ע"י רכיבים של Content Delivery Networks, תקשורת בין Cloud למערכת ארגונית, ופרוטוקולים כגון SPDY (שהופך להיות HTTP 2.0) ו Web Sockets.

קצרים

  • האם זה נכון שהדפדפן לא עושה Caching לתוכן HTTPS?
    לא. לכו בדפדפן ל about:cache לראות בעצמכם. אפשר בעזרת HTTP Headers מתאימים להגביל את ה Cache ואת אופן השמירה שלו ע"י הדפדפן / ה CDN.
  • האם רכישת Certificate הוא דבר יקר? אלפי דולרים בשנה?
    תלוי בסוג ובמקור ה Certificate, אבל זה יכול להיות גם עשרות דולרים בשנה.
  • האם זה נכון ש HTTPS מונע Virtual Hosting (לארח כמה אתרים עם Hostnames שונים על אותו שרת פיסי)?
    לא. עקרונית יש בעייה, אבל פותרים אותה בעזרת הרחבה ל TLS בשם Server Name Indication (בקיצור SNI). אולי יש פתרונות נוספים.
  • האם HTTPS מבטיח פרטיות למשתמש הקצה?
    נו, אתם אמורים לענות על זה לבד בשלב זה: הוא מגן מפני sniffing ברשת, או בפני התחזות (phishing) – אבל אין לו קשר לאיזה מידע השרת שומר עליכם, כיצד הוא מגן על מידע זה או מה הוא עושה אותו (אולי הוא מפרסם אותו לכולם בגוגל על גבי HTTP …?)

סיכום

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

שיהיה בהצלחה!

—-

לינקים רלוונטים:

HTTPS – חלק ב': אימות זהות

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

תהליך ה Handshake

תקשורת HTTP מתבצעת על גבי TCP connection.
TCP Connection הוא של הסכמה הדדית בין 2 הצדדים כיצד לעבוד, כך שלא יהיה צריך להסכים עם כל הודעה מחדש. הסכמה על TCP connection נעשית בתהליך תלת-שלבי שנקרא "לחיצת ידיים משולשת" (three-way handshake). אני מניח שכל זה מוכר.

פרוטוקול TLS משתלב על גבי לחיצת הידיים של TCP ומוסיף את הבטי האימות וההצפנה. לצורף כך, TLS דורש עוד כארבע לחיצות ידיים בדרך. יש כמה אופטימיזציות שונות ללחיצת היד של TLS (אינני מכיר את הפרטים של רובן), והן יתרחשו אם התסריט מאפשר זאת ושני הצדדים מודעים לקיצור הדרך. בתרשים למעלה הצגתי פישוט דיי בסיסי בו ה Ack האחרון של "לחיצת-הידיים המשולשת" משמש גם להעברה של ההודעה הראשונה של ה TLS handshake, הרי הוא ה Client Hello.

הנה תקציר תהליך ה TLS handshake:

הודעה 1: Client Hello

ה Client מצהיר שהוא מוכן להתחיל בתהליך ה TLS handshake ושולח כמה פרטים: גרסאות ה TLS בהן הוא תומך, רשימה של הצפנות (סימטריות) בהן הוא תומך ועוד כמה פרטים טכניים.
כל התקשורת בשלב זה נעשית ב clear text, כלומר: ללא הצפנה.
הודעה 2: Server Hello + Certificate
השרת בוחר בגרסת TLS וההצפנה בהן הוא מעוניין לעבוד (בעצם: המקסימום שהוא תומך) ומצרף את המפתח הציבורי שלו עם Certificate – מספר שדות ("קובץ קצר") שמאמתים את זהותו שלו. מעין "צילום של תעודת הזהות שלו". הקובץ חתום ע"י חתימה דיגיטלית של גורם צד-שלישי מוכר. פרטים נוספים על Certificates – בהמשך הפוסט.
בשלב זה יכול השרת להחליט שהוא רוצה לאמת בעזרת HTTPS Authentication, את זהות המשתמש – ולבקש מה Client חזרה את ה Certificate שלו.
הודעה 3: העברת מפתח סימטרי
ה Client מאמת את ה Certificate של השרת (איך הוא עושה זאת – בהמשך) ומייצר מפתח סימטרי אקראי לצורך ה session הנוכחי עם השרת. אני מניח שמשימת יצירת המפתח הסימטרי ניתנה ל Client בכדי לשפר את ה scalability של השרת ("1000 מעבדים ממוצעים חזקים ממעבד-מפלצת של שרת אחד").
את המפתח הסימטרי, ה Client מצפין בעזרת המפתח הציבורי של השרת. רק בעל המפתח הפרטי המתאים – יוכל לפתוח את ההצפנה (בזמן סביר).
הודעה 4: שימוש במפתח הסימטרי לצורך אימות וסיום תהליך ה TLS handshake
בשלב זה השרת משתמש במפתח הפרטי שלו כדי לפענח את ההודעה הקודמת, לחלץ את המפתח הסימטרי – ולעבור להשתמש בו.
ההודעה הראשונה שנשלחת ל Client היא הודעת Finish, מוצפנת במפתח הסימטרי שה Client סיפק, הודעה שעוזרת לודא שתהליך העברת המפתח הסימטרי והשימוש בו ע"פ ההצפנה (chiper) הנכונה – הצליח.

נקודה משמעותית לשים לב אליה היא שאם ב HTTP יצירת connection הייתה תקורה של roundtrip אחד בין הדפדפן לשרת, ב HTTPS – התקורה ליצירת connection היא שלושה roundtrips. בתקשורת בין ישראל לארה"ב – מדובר על בערך שנייה (1000ms לפני שהעברנו ביט אחד של מידע בעל-ערך למשתמש).

Session Tickets
אם אתם זוכרים, הדפדפן פותח עד 6 או 8 connections במקביל מול כל שרת בכדי להאיץ את ההורדה.
כדי לא להגיע למצב בו משלמים את התקורה של TLS handshake מספר רב של פעמים, נוספה יכולת בשם Session Ticket (תקן: RFC 5077) המאפשרת ל connection שני, שלישי וכך הלאה, מול אותו השרת, לעשות שימוש חוזר ב: מפתח הסימטרי, אימות, הסכמה-על-הצפנות וכו'.
עם הודעת ה Finish, השרת שולח Session Ticket (מוצפן) ל Client. כל connection חדש יכול לצרף את ה ticket הזה בכדי "להצטרף" ל HTTPS session שמחזיק השרת – ולחסוך לעצמו תהליך handshake נוסף.

בניגוד ל HTTP שבברירת המחדל הוא stateless (מתנתק אחרי כל response), פרוטוקול HTTPS הוא תמיד statefull (במסגרת ה session).

לסיכום: התקורה הנוספת היא בהחלט משמעותית, אבל היא רלוונטית רק לטעינת הדף הראשונית. שרת מודרני (תקן ה Session Ticket הוא מ 2008) ידע לצמצם גם את התקורה הראשונית.

HTTPS Authentication

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

TLS תמיד כולל אימות של זהות השרת, והשרת יכול לבקש לאמת גם את זהות משתמש הקצה. מנגנון אימות הזהות ( Authentication) למשתמש הקצה הוא תחליפי לשיטות אחרות כגון SAML 2.0 או OpenID.

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

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

TLS משתמש בסטנדרט שנקרא X.509 לתיאור Certificates – "תעודות" המאמתות את זהותו של אדם / שרת.
ישנם Server Certificates לשרתים וישנם Client Certificates לזיהוי משתמשים. בסה"כ אלו מנגנונים דומים.

X.509 מסתמך על היררכיה של Certification Authorities (בקיצור CA) – גופים (לרוב עסקיים) שמורשים להנפיק Certificates. ה CA המוכר ביותר הוא כנראה זה של חברת VeriSign, שחטיבת אימות הזהות שלה נמכרה לפני כשלוש שנים ל Symantec, אך היא עדיין פועלת תחת השם VeriSign.

VeriSign מאמתת זהות של ארגונים ומנפיקה Certificates לשרתים (ליתר דיוק: ל DNS Entries – השרת הוא רק ה"בחור שנמצא שם כרגע"). היא עושה זאת באופן ישיר וגם הרבה בעזרת ספקי משנה שהיא מסמיכה.

הנה הדרך בה תוכלו לבדוק את ה Certificate של אתר אליו אתם גולשים (דוגמה = כרום):

צעדים 1-4 מביאים אותי למסך בו אני רואה את שרשרת (או היררכית) האמון של בנק הפועלים: VeriSign מאמתת זהות של תת-שירות או מחלקה של VeriSign שמאמתת את בנק הפועלים.

VeriSign בהכרח לא תיתן לחברת סטארטאפ מאוקראינה אימות של Bank Haopalim ל DNS שכתובתו http://www.bankhaopalim.com (זו נראית כמו הכנה להתקפת Phishing! [א]) – צריך להיות קשר ישיר בין השם שנחתם לעסק, ולכתובת ה DNS שאותה מבקשים לחתום.

בפינה הימנית למטה צרפתי עוד דוגמה של Certificate של אתר בשם buy2usa (השייך לחברה buy2) שאומת ע"י CA אחר – במקרה הזה Go Daddy.

ייתכן ותשאלו את עצמכם: מדוע רק לחלק מהאתרים יש רקע ירוק יפה בשם (מסומן בריבוע ירוק בתמונה למעלה)? האם זהו style ב CSS?

ובכן… לא. אתרים שחשובה להם יותר "הפגנת" הזהות שלהם (בנקים זו דוגמה טובה) עוברים תהליך יותר מקיף שנקרא Extended Validation. תהליך אימות הזהות מול ה CA הוא מקיף (ויקר) יותר, אם כי ההצפנה היא אותה ההצפנה.
כלומר: אתם יכולים להיות בטוחים במידה גבוהה יותר של בטחון שמי שבקצה הוא מי שהוא טוען שהוא (כל עוד ההצפנה לא נפרצה).

הנה האופן בו דפדפנים שונים מציגים Extended Validation Certificates:

לכל העניין של חוויית המשתמש יש חשיבות גדולה ב Security – הרי בסוף, אנשים הם חוליה בשרשרת האבטחה. חוליה חלשה – בד"כ.

ספציפית לגבי Extended Validation Certificates (בקיצור: EVC), חוקרים ממייקרוסופט ואוניברסיטת סטנפורד ביצעו מחקר משותף ב 2007 שהראה שמשתמש ממוצע פשוט לא שם לב להדגשה של ה EVC ולא מתייחס אליה כמידע נוסף. מצד שני, אנשים שעברו הדרכה ולמדו לחפש אחרי ההדגשה של ה EVC הצליחו לשים לב אליה ולבצע החלטות טובות יותר בהימנעות מהתקפות phishing.

אז מהם בדיוק ה Certificates ואיך הם מבטיחים וידוא אמין של זהות?

  • Certificate הוא צירוף של Public Key (א-סימטרי), זיהוי הישות, וכמה שדות מידע אחרים.
  • Certificate נחתם בחתימה דיגיטלית, לפחות בעזרת המפתח הפרטי העצמי.
  • X.509 Certificate הוא תקן שמכיל כמה שדות סטנדרטיים ומאפשר הרחבה לשדות נוספים – ללא הגבלות מסוימות על אורך / מבנה המידע.
  • Certificates נקראים לעתים בקיצור certs, בעיקר בפורומים מקצועיים של אבטחה.

הנה דוגמה למבנה של Certificate:

מקור: וויקיפדיה

הערה: Certificates שמועברים ב HTTPS מקודדים לרוב בפורמט בינרי, ASN.1, כך שלא תראו אותם בפורמט של clear text, כמו זה למעלה.

  1. Issuer זו הסמכות שאימתה את זהות השרת/משתמש, ה CA.
  2. כל Certificate מגיע עם תאריך תפוגה – ולא יהיה תקין אם תאריך זה חלף.
  3. אלו פרטי הישות שאותה ה Certificate מזהה. הרשומה החשובה ביותר היא ה CN (קיצור של Common Name, ע"פ פרומט X.501, כזה המוכר לכם אולי מ LDAP) שצריכה להתאים ל DNS Entry, במידה ומדובר בשרת.
  4. זהו המפתח הציבורי של הישות המזוהה.
  5. זוהי חתימה דיגיטלית שנוצרה על בסיס MD5 (פונקציית גיבוב) של כל ההודעה – ונחתמה ע"י המפתח הפרטי של ה CA (או חותם אחר: חתימה עצמית או ארגון). כדי לפתוח אותה המשתמש זקוק למפתח הציבורי של ה CA.

הנה הצורה בה ה Certificate מוצג בממשק המשתמש של "חלונות":

הערה: certificate זה לא מתואם עם הדוגמה מוויקיפדיה – הוא חדש הרבה יותר

מהיכן מגיעים Server Certificates למחשב?

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

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

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

ניתן לצפות ב Certificate Store בעזרת הפעלה של certmgr.msc מה command line בחלונות.

Root CAs בד"כ חותמים דיגיטלית על עצמם – כלומר בעזרת ה public key שב Certificate ניתן לאמת את החתימה הדיגיטלית.

CAs משניים (Intermediate) חתומים ע"י Root CAs. זו היא בעצם שרשרת האמון עליה דיברנו בתחילת הפוסט.

נחזור לדוגמה שהצגנו מוקדם יותר:

במקרה זה Go Daddy Class 2 הוא ה Root CA שחתם על ה Certificate של עצמו וחתם על Go Daddy Secure – שזהו CA משני (אפילו ששייך לאותה החברה. אולי מדובר בסניף אחר או חטיבה אחרת, למשל).
Go Daddy Secure הוא זה שחתם לנו על buy2 ואימת את זהותו.

בכדי שהדפדפן יאשר את זהותו של buy2, לפחות Certificate אחד בשרשרת צריך להיות trusted (קרי נמצא ב Certs store שלנו), מאומת ותקין.
בהמשך הפוסט נראה מה קורה כאשר Certificate הוא לא תקין.

שרשרת האמון ב certificates. מקור: איליה גריגוריק

מעניין לציין של JVM של ג'אווה יש Certificate Store נפרד מזה של מערכת ההפעלה(המורכב מ2 חלקים הנראים truststore ו keystore). ייתכן ויש בו Certificates שונים מאשר בדפדפן. כלומר: אנו יכולים לאמת ישות דרך הדפדפן ולא בעזרת קוד ג'אווה – או להיפך.
אם אתם "חוטפים" שגיאות של javax.net.ssl.SSLException: untrusted server cert chain בעוד אין לבם בעיה להתחבר לאתר עם הדפדפן – יש סיכוי גבוה של JVM אין את ה certificates שיש לדפדפן.

נאמר לי שעורקל נתקלה בבעיה טכנית בגינה היא לא עדכנה certificates בגרסאות הג'אווה זמן מה – אולם לא ראיתי זאת בעצמי.

מהיכן מגיע Client Certificate למחשב?

Client Certificate הוא כזה שמזהה את המשתמש הספציפי, ומשמש לצורך Authentication למערכות שתמוכות בשיטה זו. מאיפה אם כן הוא מגיע למחשב שלכם? האם איי פעם נפגשתם עם סוכן של Go Daddy או VeriSign ונדרשתם להוכיח את זהותכם? – אני מניח שלא.

יש כמה דרכים לייצר Client Certificate:

דרך פשוטה אחת היא בעזרת תוכנה שעושה זאת, ואז אתם חותמים על ה Certificate בעצמכם. למשל הפעלה ב command line של:

openssl genrsa -des3 -out server.key 1024

תייצר מפתח פרטי בשם server.key ואז הפעלה של

openssl req -new -key server.key -out my_cert.csr


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

דרך אחרת היא שהשרת מייצר certificate עבורכם וחותם עליו. אתם מורידים קובץ ועושים לו import לתוך ה Certificate Store.

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

כמובן שדרך זיהוי זו תקפה בעיקר לזיהוי (Authentication) פנים-ארגוני ולא למערכות אינטרנט, בהן כל תקשורת עוברת דרך תווך לא מאובטח / שקשה לדעת מה מקורו.

התנהגות הדפדפן וחיווי למשתמש

לא תמיד הכל הולך כמתוכנן ולפעמים אתר עובד עם HTTPS שנראה תקין… מלבד פרט אחד קטן. הדפדפנים מנסים לשקף למשתמש את מידת הסיכון ע"י חיווי מתאים בממשק המשתמש – חיווי שהם מנסים שיהיה אינטואיטיבי וברור גם למשתמש שלא מכיר את פרוטוקול TLS (קרי: כמעט כל המשתמשים).

עד כמה חיווים אלו ברורים? – תגידו אתם.

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

לפני שהדפדפן שולח את client certificate לשרת – הוא מבקש את פרטי המשתמש בעזרת dialog (שעשוי להראות מעט שונה בין דפדפנים שונים):

חלון אישור לשליחת Client Certificate בכרום

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

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

Mixed Content

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

אציין שיש חריגים בכלל של Mixed Content: תגיות img, video, audio ו object שלא כולל data attributes – לא נכללים בבדיקה. מאוד קשה לבצע התקפה עם תמונה – ויש מעט אתרים שמארחים תמונות על גבי HTTPS.

כלומר: אם אנו בונים אתר HTTPS אנו צריכים לוודא שכל ה scripts, css ועוד מגיעים גם ממקורות המאובטחים ע"י HTTPS. זה לא תמיד טריוויאלי.

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

ההזהרה, כפי שנראית בעת כתיבת הפוסט בכרום

IE, ולפני כחודשיים בערך החלו גם כרום ו FF לחסום כהתנהגות ברירת-מחדל את תוכן ה HTTP כאשר יש mixed content. כלומר: הדף נטען ללא רכיבי ה HTTP – מה שיכול לגרום לו לרוץ בצורה לא טובה / לא לרוץ בכלל.

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

הנה הדרך בה מוצג תוכן חסום והדרך לאפשר אותו בכרום:

והנה ב FF:

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

Certificate לא תקין:

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

בעצם, זה נראה דיי מפחיד – וזה יכול לקרות גם לאתר הבטוח שלכם. מספיק שללקוח שלכם אין Certificates מעודכנים של ה CA (כל מיני חברים שרצים על Win XP ו IE7) – וזה מה שהם יקבלו, גם אם האתר שלכם תקין לחלוטין. נדמה לי שפעם הדפדפן היה מגיב בצורה פחות אגרסיבית ל Certificate שהוא פג תוקף – אך זה לא המצב עכשיו.

הנה אתר בו תוכלו למצוא לינקים לדוגמה עם תקלות שונות ב Certificate שלהם: http://testssl.disig.sk/index.en.html

הנה שני אתרים שיכולים לעזור ולנתח מדוע יש תקלת Certificate:

סיכום

פו…. זו הייתה כתיבה ארוכה!
סקרנו את האופציה לבצע Authentication בעזרת HTTPS/TLS על בסיס Certificates וראינו בגדול כיצד המנגנון עובד.
נשארו עוד כמה נושאים שאני רוצה לדון בהם – על ההשלכות היותר קונקרטיות למפתח – אשמור חלק זה לפוסט המשך קצר.

שיהיה בהצלחה!

—-

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

HTTPS – חלק א': סקירה

HTTPS הוא HTTP עם SSL (קיצור של Secure Sockets Layer). ה "S" ב HTTP משמעה "Secure".

עד לפני מספר שנים, HTTPS היה פרוטוקול שהיה נפוץ בעיקר במערכות Enterprise, ו/או אתרים משעממים אחרים.
דברים השתנו, ויותר ויותר אתרים משתמשים ב HTTPS בתור פרוטוקול ברירת המחדל שלהן: גוגל, טוויטר, פייסבוק ועוד. ע"פ סקר SSL Pulse (לינק עם נתונים גרפיים), בשנה האחרונה אחוז האתרים שעובדים ב HTTPS עלה מ 15%, ל 52%! ייתכן והסקר מעט מוטה – אך בהחלט יש כאן מגמה.

ישנן כמה סיבות שבגללן השינוי מתרחש:

  1. HTTPS הוא "תואם" ל HTTP ואינו דורש (בתיאוריה) שינויי קוד בכדי לעבור אליו.
  2. החומרה נעשית חזקה יותר ויותר, והתקורה של עבודה ב HTTPS היא כבר לא-משמעותית*.
  3. מודעות גדלה לפרטיות ואבטחה ברשת.
* מלבד מקרה חשוב אחד – עליו נדבר בהמשך.
  • האם המעבר ל HTTPS הוא "טוב ליהודים"?
  • מה HTTPS בעצם עושה? היכן הוא מגן והיכן – לא?
  • מה המשמעות, בשבילי המפתח, ובכלל – לעבוד עם HTTPS?

על שאלות אלו, ואחרות – אנסה לענות בפוסט זה.

Context: היכן פרוטוקול HTTPS "מתרחש"?

הבהרה / היסטוריה: פרוטוקול ה SSL (קיצור של Secure Sockets Layer) הוגדר ע"י חברת Netscape עבור הדפדפן Netscape Navigator – שאיננו קיים עוד. הוא היה בגרסאות 1.0 עד 3.0, ואז הוא הועבר לגוף תקינה סטנדרטי ושמו שונה ל TLS (קיצור של Transport Layer Security). בשנת 1999 שוחרר TLS גרסה 1.0, הגרסה העדכנית של TLS היא 1.2 (שוחררה בשנת 2008).
למרות שהשם "TLS" קיים כבר יותר מעשור, השם SSL דבק ועדיין מוכר יותר / משתמשים בו לעתים קרובות בהחלפה ל TLS. ישנו עוד ציוד רשת (בעיקר שרתים) שעדיין תומכים ב SSL או גרסאות ישנות של TLS – מה שמחייב את הדפדפנים לעבוד בגרסה ישנה יותר (ופחות מאובטחת) של הפרוטוקול.

בסך הכל, TLS הוא פרוטוקול שרץ מעל TCP ומתחת ל HTTP (או פרוטוקולים אחרים ברמת ה"אפליקציה"), כך שבעקרון הוא לא משנה את אופן העבודה של HTTP:

כדאי לציין שיש עוד פתרונות הצפנה ל HTTP כגון VPN או IPSec שהם ברמת פרוטוקול ה IP – אך הם מחוץ ל scope של דיון זה.

אלו שירותים פרוטוקול HTTPS מספק?

"הצפנה!" – נכון. אבל הצפנה של מה?

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

  • הצפנה של המידע העובר בין הלקוח לשרת – כדי שצד שלישי לא יוכל להאזין לתקשורת.
  • Authentication: זיהוי השרת ו (אולי גם) הלקוח – כדי שנדע, למשל, ש"הבנק" שלנו הוא באמת הבנק שלנו, ולא אתר מתחזה [ב].
  • וידוא שלמות ההודעה, בעזרת "חתימה דיגיטלית" – כדי להתמודד עם התקפות מסוג Man in the Middle.
פרוטוקול TLS בפעולה בדפדפן כרום:
ורוד – אני רואה שיש אימות שאני אכן מחובר לבנק הפועלים. לפני כל הכנסה של כרטיס אשראי – כדאי מאוד לוודא שהשרת מאומת ושמו נשמע הגיוני.
תכלת – הממ…. 112-ביט הוא מפתח מעט חלש בימנו + חיבור 1.0 TLS הוא מעט לא מעודכן וחשוף להתקפות כגון BEAST (בהמשך)

על מפתחות סימטריים וא-סימטריים (הצפנה)

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

מפתחות סימטריים הם פשוטים יותר ונוחים לעבודה. בימינו הם לרוב באורך של 128 עד 256 ביט – כאשר מפתח ארוך יותר הוא בעקרון חזק יותר וקשה יותר לפיצוח ב "brute force" (כלומר: ניסיון כל הצירופים האפשריים, לעתים עם כמה קיצורים). יכולת הפיצוח תלויה כמובן גם בסביבה, באלגוריתם ההצפנה ובמידת האקראיות של המפתח.

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

לצורך כך הומצאו המפתחות הא-סימטריים. האלגוריתם הנחשב בתחום זה הוא אלגוריתם RSA (שאחד ממפתחיו הוא ישראלי) – אלגוריתם שמאפשר לסיטואציה המדהימה הבאה להתרחש:

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

כיצד זה קורה? זה קצת מסובך, אבל בגדול העיקרון מבוסס על הגרלה של 2 מספרים ראשוניים אקראיים גדולים מאוד והכפלה שלהם. המספר שנוצר מהמכפלה הוא ענק – ומאוד קשה לחשב ממנו את המספרים הראשוניים מהם הוא מורכב (במיוחד כשארכיטקטורת המחשב היא, 64 ביט, היא קטנה משמעותית מאורך המספרים). מתוך המכפלה מחלצים 2 מפתחות / מספרים:
מפתח ציבורי – מפתח שניתן לחלק לכל / לצעוק בתוך החדר.
מפתח פרטי – מפתח סודי שיש לשמור.

כדי להצפין ולפתוח מסרים ב RSA – זקוקים לשילוב של 2 המפתחות. ניתן לשלב אותם בשני האופנים הבאים:

  • כאשר רוצים להצפין מסר לבעל המפתח, מצפינים אותו בעזרת המפתח הציבורי – וניתן לפתוח אותו רק בעזרת המפתח הפרטי (שהוא סודי, בידי בעל המפתח).
  • כאשר בעל המפתח רוצה לאמת בפני אחרים שהוא שולח ההודעה ושהיא לא שונתה, מה שנקרא "חתימה דיגיטלית", הוא מצפין את ההודעה בעזרת המפתח הפרטי – שרק בעזרת המפתח הציבורי ניתן לפתוח. יש גם עוד checksum (או MAC) של ההודעה שמאמת שלא נעשו בה שינויים בדרך.

סה"כ מפתחות א-סימטריים היום הם באורך של 512 עד 2048 ביט – ודיי יקר למעבד לפענח אותם. דרך הפעולה של TLS הוא לבצע את התקשורת הראשונית בעזרת מפתח א-סימטרי (יקר להצפנה/פענוח). בערוץ המאובטח שנוצר – מעבירים מפתח סימטרי קצר יותר (קל להצפנה/פענוח) ושצריך פחות עבודת חישוב בו נשתמש מכאן והלאה. חתימה דיגיטלית יכולה לסייע לאמת את זהות המתקשרים (שרת / לקוח).

האם פרוטוקול ה SSL/TLS הוא מוגן לחלוטין?

לא.

למשל:
ממשלת ארה"ב (כמו ממשלות אחרות) מגבילה בחוק את גודל המפתחות בהן ניתן להשתמש להצפנה. מפתח גדול יותר = קשה יותר לפענוח. הסברה אומרת שממשלת ארה"ב מתאימה את החוק כך שיאפשר לאזרחים וחברות להתגונן מפני אזרחים וחברות אחרים, אך לא להתגונן בפני מחשבי העל של ה NSA או ה FBI.

כרגע החוק בארה"ב (למיטב ידיעתי) מגביל את גודל המפתחות ל 256 ביט להצפנה סימטרית ול 2048 ביט להצפנה אי-סימטרית (במקרה שלנו: RSA).

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

האם פרוטוקול RSA עליו מסתמכת חלק גדול מהאבטחה של HTTPS יכול ל"הפרץ" בצורה גנרית? כנראה שכן – אבל זה עדיין לא קרה.

יש גם באגים בפרוטוקול ה SSL עצמו.
התקפות מפורסמות אחרונות המבוססות על באגים אלו קרויות BEAST ו CRIME – וחלק גדול של משתמשי האינטרנט עדיין חשוף אליהן [ג]. חשוף, מכיוון ששרתי אינטרנט רבים הם לא מעודכנים ועדיין עובדים עם גרסאות ישנות של TLS או אפילו SSL (כלומר: גרסה ישנה הרבה יותר)
.
ע"פ שמועות, מומחי ה NSA "דחפו" באגים מתוחכמים לתוך התקן של TLS – כדי שהם יוכלו לנצל אותם בהמשך. יש פה הנחה, לא בהכרח נכונה, שהבאגים כ"כ מורכבים ופינתיים – שאף אחד לא ימצא אותם. ה NSA, בין היתר גם שילם ל RSA כדי שיחלישו את ההגנות שלהם.

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

מה בהמשך?

הפוסט מתארך ולכן אני מחלק אותו ל2 חלקים.
בחלק א' סקרנו את הפונקציונליות הכללית של HTTPS (קרי TLS/SSL) וקישרנו אותו ל TCP/IP Stack שכולנו מכירים.
בחלק ב' אנסה להתמקד ב HTTPS Authentication וה Certificates – צד חשוב מאוד בפרוטוקול ה HTTPS, ובהשפעה של HTTPS על מערכת / המתכנתים / Operations.
שיהיה בהצלחה!

לינקים:
מדוע השתנה שם הפרוטוקול מ SSL ל TLS?

[א] כדאי לזכור שחברות אלו שיתפו פעולה בעבר עם ה NSA בחשיפת מידע של משתמשיהן. כעת הן מנסות להפגין את שינוי הכיוון שחל במדיניותן כלפי הרשויות / לטובת המשתמשים.
[ב] שרתי DNS נחשבים כלא כ"כ מאובטחים, ולכן התקפה לא מורכבת כ"כ יכולה להפנות אותנו לאתר שונה ממה שהתכוונו אליו.

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

על Federated Identity

האינטרנט פורח – וזה דבר נהדר. במקום אתרים סטטיים יש לנו עכשיו "אפליקציות" שעושות דברים נפלאים. לעתים הולכות וקרבות אפליקציות משתפות פעולה זו-עם-זו בכדי לעשות משהו נפלא חדש.
בכדי לעשות את כל הדברים הנפלאים הללו, בצורה שתתאים לנו, האפליקציות שומרות פרטים עלינו. פרטים אישיים. פרטים חשובים.בכדי להגן על הפרטים האישיים של המשתמשים, העולם משתמש במנגנוני-אבטחה, שאחד מיסודותיהם הוא מנגנון הAuthentication (זיהוי). כשמדברים על האינטרנט ואפליקציות המדברות זו-עם-זו, אנו מדברים לרוב על Authentication בעזרת Federated Identity (= זהות בקבוצה מבוזרת).

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

זהות

אם אנו מדברים על Federated Identity (בפוסט זה אשתמש מעתה בקיצור FI), אולי כדאי להתחיל בכמה מילים על המושג "זהות".
אני מניח שכולם יודעים מהי "זהות" של אדם ביום-יום (כל עוד לא נגרר למישור הפילוסופי): המסמך שמתאר את הזהות שלנו יכול להיות ת"ז, דרכון או רשומה במשרד הפנים, אבל גם נתונים פיזיים: מראה, טביעת אצבע או אופן ההליכה (מסתבר שהוא דיי ייחודי) – כל אלו מתארים את הזהות שלנו.
מרכיב חשוב בזיהוי "יום-יומית" היא שהיא מבוססת על אמון (Trust): מישהו מאמין למדינת ישראל וסומך על תעודת הזהות שהיא הנפיקה (על אף שהיא עלולה להיות שקרית או מזויפת). אתם יכולים להאמין למישהו (למשל חבר לעבודה) שאומר "אני מכיר אותו, זהו משה!". האמון יפחת אם החבר לא מכיר היטב את האיש השלישי, או אם אתם לא מכירים היטב את החבר. למשל: אדם זר שניגש ברחוב ומספר לכם שאיש שלישי הוא משה, הוא לא מצב מעורר אמון (אפשר לפתוח ולומר: "מה בכלל רוצה ממני הבחור הזה?!")
אמון יכול להיות טרנזיטיבי: החבר ראה ת"ז של אדם שלישי. אתם סומכים על החבר שסומך על תעודת הזהות שראה.
זהות דיגיטלית, או זהות אינטרנט היא דומה – אך קצת שונה:
  • בעולם הדיגיטלי אין באופן טבעי מאפיינים ייחודיים (מראה, קול, או אפילו דרך הליכה) המזהים אדם שלישי – כולם נראים "אותו הדבר" מלבד כמה פרטים שהצהירו על עצמם.
    • מעניין לציין שיש עיקרון שנקרא "risk-based authentication" בו מאמתים זהות של משתמש (ליתר דיוק: מחשבים סיכון לגניבת זהות) ע"י איסוף ופענוח "ההתנהגות הדיגיטלית" הטיפוסית של המשתמש, למשל: מספר השניות שהוא מבלה בכל דף באתר וסדר הדפים שהוא ניגש אליהם. אם תתחברו לאתר הבנק ותנהגו בצורה שונה מאוד מבד"כ – יש סיכוי שתחסמו ותתבקשו לגשת לסניף להוציא ססמה חדשה.
  • מיקום גאוגרפי הוא קל ל"זיוף": כיצד אני יודע שהבחורה הנחמדה מאשדוד שמופיעה בפייסבוק היא לא האקר רוסי שנמצא 2000 קילומטר משם?
  • קל למדי לפורץ "לאמץ" מספר זהויות דיגיטליות, אפילו באותו האתר – דבר הרבה יותר מסובך בעולם הפיסי.
  • כמות הישויות (חברות / אפליקציות) שאוספות עלינו מידע הוא רב יותר, והמידע מפורט יותר. קשה להאמין שביה"ס שלמדתם בו במשך שנים שמר מידע שווה ערך למה שאתר אינטרנט שומר עליכם בתוך מספר ימים של שימוש.
    מספיק שרק אתר אחד ייפרץ – בכדי שפרטים אישיים כלשהם שלכם יהיו נגישים לאישיות לא רצויה.
  • אתרי אינטרנט יכולים לייצר בקלות יחסית חזות אמינה, או לפחות אנו נוהגים בפחות זהירות כלפיהם: לכמה אתרים נתתם את כתובת הדוא"ל שלכם והשתמשתם שם באותה הסיסמה כמו חשבון הדוא"ל? לכמה בתי עסק נתתם את הכתובת שלכם בבית, ומפתח?

Federated Identity

עקרונות ה FI אינם תקן או דרך-יחידה לבצע את הדברים, אולם אם נתבונן במנגנונים הנפוצים:
  • (Kerberos)
  • SAML 2.0
  • OAuth
  • OpenID
  • Claims-Based Authentication
נראה שיש בניהם המון דמיון. במשך שנים לארגונים ומערכות שונות היו מימושים פרטיים לאותם עקרונות. כל זה השתנה בשנות האלפיים שאפליקציות החלו יותר ויותר לדבר זו עם זו. עברו עוד מספר שנים עד שהארגונים הגדולים הצליחו להסכים על תקן (תקנים) אחידים ולהתיישר לפיהם. שלושת התקנים החשובים (SAML, OAuth ו OpenID) מציגים שוני עקרוני בפונקציונלית שלהם שמצדיק קיום 3 פרוטוקולים שונים.
Kerberos ו CBA הם פתרונות מוצלחים, שנפוצים כיום כמעט ורק בעולם של מייקרוסופט. מכיוון שההגמוניה של מייקרוסופט בסביבת המחשוב נפגעה מאוד במעבר לענן – ניתן להתייחס כיום ל2 תקנים אלו כתקנים בעלי חשיבות משנית.
תהליך אפשור גישה למשאב. אנו נתמקד בפוסט זה בשלב ה Verification

ניתן לקרוא עוד על שלב ה Authorization בפוסט קודם בנושא.
תהליך ה FI מנצל את העובדה שאימות (Authentication) וניהול הרשאות (Authorization) הם, מאז-ומעולם וע"פ תכנון, שלבים נפרדים בתהליך הגישה למשאב – בכדי להפוך את תהליך האימות לתהליך מבוזר שמתרחש בכלל על שרת אחר.

בשפה של FI מגדירים את המונחים הבאים:

  • Service Provider – את הישות נותנת את השירות, למשל שרת פייסבוק.
  • Identity Provider (בקיצור: IdP) – את הישות שמאמתת את זהות המשתמש (שלב Verification). ייתכן וה IdP הוא לא המערכת בה מנהלים את המשתמשים (קרי LDAP / Active Directory) אלא שירות חיצוני שנמצא ביחסי אמון עם ה User Repository.
  • Credential Store (לחלופין Authentication Store) – היכן ששומרים את ההרשאות מה משתמש מורשה לעשות (שלב ה Permission Check), לרוב זהו נותן השירות (למשל: פייסבוק), אך תאורטית זו יכולה להיות מערכת צד-שלישי שנותן השרות סומך עליה. פיזית, נתונים אלו נשמרים לרוב ב Directory Service או בסיס-נתונים.
בדומה לעולם הפיסי, המפתח לFI הוא אמון (Trust) בין השרתים השונים. אמון זה נוצר פעמים רבות תוך כדי החלפת מפתחות-הצפנה בין 2 השרתים. ברגע שיש אמון, האמון הוא "מוחלט"[א]: אין וידוא נוסף מעברת לאימות זהות השרת עליו סומכים (על בסיס הצפנה) ווידוא שמה שנשלח מהשרת המרוחק לא שונה (modified) בדרך.

הנה תרשים שמתאר בקירוב את האופן בו פרוטוקולים של FI עובדים:

תרשים A

הנחה מקדימה: ה SP מכיר וסומך על ה IdP (נעשה בעזרת קונפיגורציה ידנית).

  1. המשתמש פותח דף בדפדפן ומנווט ל SP.
  2. ה SP לא מזהה את המשתמש ומפנה אותו ל IdP. אופן ההפניה שונה מפרוטוקול לפרוטוקול, וכן זהות ה IdP.
  3. ה IdP מאמת את זהות המשתמש בדרכים שעומדות לפניו: הוא מכיר את המשתמש וצריך להיות מסוגל לאמת אותו.
  4. ה IdP מפנה את הדפדפן חזרה לדף המקור (פרטים הופיעו בבקשת האימות, בד"כ) ומייצר "מסמך" (token או ticket) המתאר פרטים שהוא יודע על המשתמש: id, מיקום, קבוצות שהוא שייך אליהן וכו'. פרטים אלו נקראים לרוב Assertions או Claims וה"מסמך" שמכיל אותם הוא מין וריאציה דיגיטלית של דרכון או ת"ז.
    ה"מסמך" נחתם ב חתימה דיגיטלית כדי לוודא שצד שלישי לא יוכל לעשות בו שינויים.
  5. ה SP מקבל את המסמך – הוא מאמת, לרוב בעזרת החתימה הדיגיטלית, את זהות ה IdP ואת שלמות/תקינות (integrity) המסמך.
  6. במידה והמסמך נמצא תקין, הוא מבצע log in למשתמש ע"פ הפרטים שבמסמך, כלומר: בד"כ יוצר session שמתאר את המשתמש.

בסיכום מהיר ניתן לציין ל FI את היתרונות והחסרונות הבאים:

יתרונות

  1. משתמש: כאשר משתמשים באותה סיסמה על ריבוי מערכות, ברגע שמערכת אחת נפרצת הפורץ יכול לנסות את הסיסמה ב 100 האתרים הנפוצים – אולי יתמזל מזלו. בעזרת FI אין צורך לנהל מספר-רב של ססמאות: אם מערכת (Service Provider) נפרצה – אין עליה את הסיסמה שלי.
  2. משתמש: חוויית משתמש טובה. מעבר לכמה שניות המתנה בזמן ה login, המשתמש לא מודע ש FI היה בכלל מעורב.
  3. מפתח ה SP: לא צריך להתעסק עם הנושא המורכב שקרוי Authentication. אנשי שיווק היו כבר ממציאים: "Authentication as a Service".
  4. מפתח, Admin ומשתמש: היכולת לספק (SSO (Single Sign-On בצורה אלגנטית (למשל: פרוטוקול SAML 2.0), הרבה יותר אלגנטיים ממשפחה נפוצה אחרת של פתרונות SSO שנקראת "Credential Storage" בה שרתים שונים / מכונת המשתמש שומרת שם וסיסמה לשרתים השונים. SSO הוא טוב כי:
    1. המשתמש – לא צריך לזכור הרבה ססמאות / לבצע Login שוב כאשר הוא מופנה למערכת אחרת.
    2. ה Administrator – לא צריך לנהל מנגנוני Authentication כפולים
    3. המפתח (של SP) – חוסך לעצמו התעסקות עם Authentication. שהמפתח של ה IdP – יעשה את זה!
  5. מפתח SP: מקבל אינטגרציה קלה בין מערכות, שכעת רק צריכות להסכים על פרוטוקול ה FI.
  6. מפתח, Admin: מנגנוני FI לרוב גמישים למדי, ומאפשרים ל IdP לספק כל סט של נתונים שהאפליקציה דורשת, למשל: מקום גאוגרפי של המשתמש, שפה מועדפת וכו'. זהו תחליף חלקי לשמירת מידע personalized על המשתמש, ויותר מזה – ניהול כפול שלו במספר מערכות (אני רוצה לכוון את השפה עברית במערכת אחת ולא בעשרה).

חסרונות

  1. החשש שפריצה ל IdP תספק לפורץ גישה לכל האפליקציות של המשתמש/ים על ה IdP, מה שנקרא "מפתח יחיד לממלכה".
    הסיכון קיים, אבל מכיוון שניהול של 20 ססמאות מוביל לרוב לסיסמה אחת על 20 שרתים שפחות מאובטחים מה IdP הממוצע – אין אלטרנטיבה טובה יותר לסיכון הזה, עדיין.
  2. פתרון מורכב להקמה. למרות שהרעיון אינו חדש, יש מחסור בבסיס ידע / חומר כתוב [ב] / מומחים בתחום ה FI, במיוחד כאשר מדובר בdeployments שאינם בסיסיים. לאחרונה צצים פתרונות של "IdP as a Service" (לדוגמה Azure ACS) – לא אתפלא לגלות שהם מצליחים לפשט רבות את מלאכת ההגדרה.
  3. אין סטנדרט יחיד ל FI (בעצם יש 3-4 נפוצים), מה שמחייב מערכות לתמוך בכמה תקנים / לא לתמוך ב FI עבור כל המשתמשים.

הפרוטוקולים

כמה מילים על ההבדלים בין הפרוטוקולים הנפוצים:

OpenID
מקצר / מפשט את תהליך ה Trust בין ה SP ל IdP. בעזרת OpenID, אתר (SP) יכול לסמוך על IdP מבלי שה IdP יכיר אותו. כלומר: אין צורך בהחלפת מפתחות / certificates. מתאים לאתרי אינטרנט שפתוחים לכולם, ושבעיקר רוצים לזהות את המשתמש מבלי להכביד עליו. לרוב חיבור של OpenID נראה למשתמש הקצה ככפתור "התחבר באמצעות… "
IdPs של OpenID כוללים את: Facebook, Google, Yahoo ועוד.

OpenId מאפשר שתי דרכים שונות לבצע Authentication:

  1. המשתמש נרשם ל IdP ומקבל OpenId. כשהוא מתחבר ל SP עליו להזין את ה OpenId שבתוכו מקודד URL ל IdP וכך ה SP יודע להיכן להפנות את הדפדפן לצורך Authentication (שלב 2 בתרשים A)
  2. (כנראה יותר נפוצה) כשהמשתמש ניגש ל SP, ניתן לו ב UI מבחר של IdP והוא בוחר אחד מבניהם אליו ה SP יפנה את הדפדפן לביצוע תהליך ה Authentication.
OAuth

הייחוד ב OAuth הוא שהוא כולל גם Authorization, Authorization שעושה משתמש הקצה לאתר מסוים – לגשת לפרטים שלו (קריאה ו/או כתיבה).
נגדיר את "אתר המקור", כאתר שמנהל פרטים אישיים של המשתמש ואתר ה Service Provider כנותן שירות מסוים נוסף.
התצוגה למשתמש הקצה תהיה הפנייה לאתר המקור ושאלה: "אתר SP מבקש לגשת ל… שלך, האם אתה מאשר?" האישור הוא כן/לא, לעתים עם יכולת לאשר רק חלק מהפעולות. לעתים השאלה מופיעה בתוך iFrame (יכולת שנחסמה בגרסה 2.0 של הפרוטוקול) בכדי לא לגרום למשתמש לאבד אוריינטציה (אבל מאפשר התקפות clickjacking).

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

SAML
פרוטוקול SAML (בעצם SAML 2.0, אף אחד לא משתמש בגרסה 1 בימנו…) הוא פרוטוקול FI "קלאסי".
על ה IdP וה SP לייצר trust ע"י החלפת מפתחות ומשתמש בעיקר תסריטים של Enterprise בהם חשוב להגביל גישה ל SP ממשתמשים לא רצויים. SAML 2.0 גם תומך ב SSO.
SAML, כדרך אגב, מתבסס על XML/SOAP (טכנולוגיות כמעט "מוקצות" בימנו) כבסיס.

שיהיה בהצלחה!

[א] בניגוד לעולם האמיתי בו יש לנו דרגות של ספק, גם באלו שאנו "מאמינים".

[ב] דוגמה פשוטה: התיעוד הכי מקיף שמצאתי לאחר חיפוש על SAML 2.0 (פרוטוקול נפוץ מאוד, במיוחד בעולם ה Enterprise) – הוא וויקיפדיה.

קישורים:

מיתוסים והבהרות לגבי SAML (מ 2003)

Enterprise Architecture: Authorization

קשה להגדיר מהי Enterprise Architecture, לרוב זוהי ארכיטקטורה של / ועבור ארגונים גדולים.

אחד מנושאי-הליבה שחוזר על עצמו ב Enterprise Architecture הם נושאי ה Authentication ו Authorization (בקיצור: A&A):

  • Authentication – אימות הזהות של משתמש ("האם הוא מי שהוא טוען שהוא?")
  • Authorization – כיצד שולטים בהרשאות מה המשתמש, לאחר שאימתנו את זהותו, יכול לעשות.
ישנם מעט Enterprise שלא כוללים A&A, למשל כמעט כל הגישות בווב יהיו על גבי HTTPS (הדורשת הזדהות) ולא HTTP.

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

בפוסט זה אני רוצה להתמקד בתחום ה Authorization ולהציג עקרון מעניין, שאני מניח שלא מוכר בקרב רבים, הנקרא Role-Based Authorization (בקיצור: RBA, נקרא גם Role-Based Access Control קרי RBAC).

הקדמה: המודל הנאיבי

ניהול המשתמשים הפשוט (והנאיבי) ביותר כולל טבלה בבסיס הנתונים של המשתמשים וססמותיהם. כשהמשתמש מתחבר למערכת עליו להקליד שם משתמש (כלומר: user id) וסיסמה ואז משווים את הפרטים למידע בטבלה. אם המידע נכון – שומרים את זהות המשתמש על ה session (באם זה server-side session, cookie וכו').
כמובן שכדאי שהססמאות יהיו "מגובבות" (hashed) ואולי גם "מטושטשות" (מה שנקרא salted [א]). נושא זה הוא תחום ה Authentication, אימות זהות המשתמש, נושא שאנני מתכוון לעסוק בו בפוסט זה.

עבור ה authorization, ניהול ההרשאות של כל משתמש, יוצרים טבלה נוספת "הרשאות" הכוללת user id, resource id, permission type (להזכיר: מימוש נאיבי לחלוטין). כל פעם שמשתמש ייגש למשאב, נבדוק בטבלה אם יש לו הרשאה לפעולה (למשל: read, write וכו') ואז נאפשר לו / נמנע ממנו את הפעולה.

ניתן לתאר את המודל הנאיבי באופן הבא:

מודל נאבי זה אינו scalable לניהול כאשר יש הרבה מאוד אובייקטים ו/או משתמשים. כדי שמודל Authorization "יעבוד כראוי" חשוב מאוד שיהיה נהיל (maintainable) ופשוט. מבחן בסיסי הוא לענות על שתי שאלות:

  1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" במקרה שלנו – ממש לא. הוא יכול לקבל הרשאות לעשרות, מאות, אולי אלפי אובייקטים. גם אם יש לנו את רשימה של האובייקטים זמינה בקלות – יכול לקחת זמן מה לפענח ולהבין מה הוא בדיוק כל אובייקט. לדוגמה: אם אלו מסמכים – מה מכילים המסמכים השונים שיש למשתמש הרשאות.
  2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" במקרה הזה – כן, זהו אובייקט ספציפי.

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

עוד בעיה של המודל הוא software scalability. הטבלה בבסיס הנתונים עלולה לצמוח במהירות. למשל: חשבו על שרת קבצים המאכסן כמיליון קבצים עבור כמה מאות משתמשים (תסריט סביר של חברה בינונית). אם עבור כל גישה לכל אובייקט נצטרך לסרוק טבלה של מיליוני שורות (אובייקטים x משתמשים) – אנחנו בבעיה.

יתרון של המודל שהוא בהחלט פשוט וקל להבנה – זוהי תכונת מפתח של המצופה ממודל Authorization.
למה אני חוזר ומדגיש נקודה זו? כי בסוף את ניהול ההרשאות עושים בני-אדם. מודל "מעולה מתמטית" שהמשתמשים לא מבינים  – שקול למודל גרוע. הנה 2 דוגמאות אופייניות:

  1. משתמש א' מנסה להגדיר הרשאות למשתמש ב' – אך לא מצליח לעשות זאת. אחרי כמה ניסיונות הוא נשבר, בוחר את הקבוצה "Everyone" ומסמן כל checkbox שהוא רואה ב UI בכדי לאפשר למשתמש ב' את הגישה המיוחלת.
    התוצאה: המידע חשוף לכולם ואיננו מאובטח.
  2. מנהל האבטחה / איש IT שאחראי על ההרשאות לא מצליח לעקוב למי יש גישה למה. עובדים עוברים תפקידים, עוזבים, מידע נוסף – אבל אין יכולת לעקוב אחרי מה שמתרחש. אין יכולת לאכוף חוקים אבטחה ארגוניים. מערכת האבטחה מסתמכת בעיקר על עובדים ללא הבנה בענייני אבטחה, שאבטחה היא בעיקר מעצור בשבילם "to get the job done".
    התוצאה: חוסר שליטה. לעתים מוסיפים מערכת אבטחה חיצונית שמגבילה את צעדי המשתמשים באופן דרקוני – בניסיונות להחזיר את השליטה.
מה הוא רואה: הכל, או כלום?

מודל: Access Control List

בואו נתקדם מהמודל הנאיבי 2 צעדים קדימה:

  1. ננהל את המשתמשים בקבוצות (בעזרת מערכת x.509/LDAP/Active Directory וכו') וננהל הרשאות לקבוצות, לא בודדים. התוצאה: הרבה פחות הרשאות לנהל.
  2. נקבע היררכיה בין המשאבים, כך שאם נתנו הרשאה למודל אב – האובייקטים הבנים יורשים אותה (אלא אם הוגדר אחרת במפורש) – שוב: פחות משאבים לנהל עליהם הרשאות.
המודל יראה בערך כך:

מודל זה פישט משמעותית את כמות הרשומות ב"טבלת ההרשאות" ושיפר את ה scalability של הניהול: במקום עשרות משאבים / משתמשים, אנו יכולים כעת לנהל מאות. במידה ויש אחידות גבוהה של המשתמשים / משאבים – אולי אפילו אלפים.
מודל ה Access Control Lists (בקיצור: ACL) – מפשט את יכולת הניהול אפילו קצת יותר: הוא מאגד את ה Permissions לאובייקט אחד שנקרא ACL. נובעים מכך כמה יתרונות:
  1. ה ACL הוא חלק מהמשאב. אם מזיזים את המשאב – ה ACL זז איתו, ואין צורך לנהל (ברמת הקוד) מעקב ושינויים בטבלת ההרשאות.
  2. בגלל שה ACL הוא אובייקט יחיד, יש פחות רשומות לנהל (יותר software scalability) / ניתן לנהל cache יותר יעיל.
יתרונות אלו נראים קטנים – אך הם, בסופו של דבר, חשובים.

לאחר התוספות, המודל יראה כך:

היכן משתמשים במודל זה?
  • מערכות קבצים כמו Windows NT או Unix
  • IBM Tivoli, Cisco Network Infrastructure ומערכות Enterprise אחרות
כמובן שיש וריאציות מעט-שונות של המודל.

עקרון מוסכם כיום הוא שהרשאות חייבות להיות חיוביות (positive) בלבד – כלומר: "מה המשתמש יכול לעשות" ולא "מה המשתמש לא יכול לעשות". זאת, בכדי למנוע סיבוכיות / דו-משמעות של ההרשאות שניתנו. במערכת הקבצים של "חלונות" עברו על כלל זה – מה שמסבך מאוד את ניהול ההרשאות.

  1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" – לא. מודל ה ACL שיפר את ה scalability של המודל הנאיבי, אך הוא עדיין נחשב מודל מאותגר-scalability מבחינת ניהול.
    ארגונים גדולים נוהגים לרכוש כלי ניתוח שסורקים את ה ACLs במערכות הקבצים, ומייצרות דוחות המקלים על ההבנה מה כל משתמש יכול לעשות.
  2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" – פחות או יותר כן, כל עוד המשאבים מנוהלים היררכית בצורה הגיונית (מה שלעתים קרובות קורה).
חולשה של מודל ה ACL הוא טיפול בהסרה של הרשאות – מה שעלול לדרוש עדכון של ACLs רבים והלוגיקה מאחוריו עלולה להיות בלתי-מובנת לחלק מהמשתמשים.

מודל: Policy-Based Authorization

במשך השנים ניסו ליצור מודל קל יותר לניהול, שיתאר יותר את צורכי האבטחה של הארגון ופחות ייצמד למבנה המשאבים הטכני במערכת. זהו מודל ה Policy-Based Authorization (בקיצור: PBA או PBAC).
הרעיון הוא שהארגון יקבע סט של כללי-אבטחה / מדיניות אבטחה (Policies), יכיל אותם על משאבים, והמערכת תאכוף אותם.
למשל: "לחשבוניות שנוצרו בשבוע האחרון יש הרשאות קריאה למשתמשים מסוג x, המתחברים מתוך הרשת הארגונית".
בהפשטה, המודל יכול להראות משהו כזה:
במודל זה יש וריאציות רבות יותר ממודלים אחרים.
היכן משתמשים במודל זה?
מודל זה מקובל בעולם ה Enterprise במערכות רבות, נפוץ גם בעולם אבטחה (דוגמה מאוד פשוטה: Firewall)
  1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" – !Hell No: למרות שיש הרבה פחות חוקים (policies) מ Permission במודלים הקודמים – הם עכשיו מורכבים הרבה יותר ומסובכים למעקב. ליתר דיוק ניתן לומר שמודל זה עשוי להיות מוצלח במקרים מסוימים, במיוחד כאשר כללים בסיסיים יכולים לתאר אוסף גדול מאוד של מקרים, משאבים או משתמשים (למשל: "אסור לגשת ל port 1433 בלי רשות של רגע ודודלי").
    קל במודל להגדיר Policies באופנים שונים, ברמות הפשטה שונות, ובסגנון שונה שיקשה על ההבנה שלהן.
  2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" – שוב, מאוד תלוי.
סה"כ, מודל ה PBA הוא שנוי במחלוקת לגבי היכולת שלו לפשט את ניהול ההרשאות במערכת ה Enterprise Scale.
כיצד אם כן מערכות אבטחה רבות משתמשות במודל זה? התשובה שלי היא שאנשי אבטחה רבים סובלים ממודל מסובך שקשה לנהל ולעקוב אחריו. עבור כמה מקרים – המודל היה מוצלח, ועבור רבים אחרים – הוא נבחר מ"סיבות היסטוריות".

מודל ה PBA יכול גם לסבול מבעיות software scalability קשות, כאשר מספר ה policies עולה. בחלק מהמערכות, "מקמפלים" את ה policies לאוטומט שיוכל לבצע את אימות ה policies בצורה יעילה יותר.

מודל ה Role-Based Authorization

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

מודל ה Role-Based Authorization (בקיצור: RBA) הוא מודל נוסף שמנסה לתאר את הארגון וצרכיו, ולא רק להיצמד למבנה המשאבים הטכני.

במודל ה RBA ממדלים Role ("תפקיד") כסט של מטלות (Tasks) לביצוע. אנשים שאמורים לבצע מטלות דומות, לרוב יהיו בתפקידים זהים או דומים. לאותם בעלי תפקידים דומים נותנים סט של הרשאות על משאבים.

בצורה הפשוטה ביותר ניתן לבטא את מודל ה RBA באופן הבא:

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

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

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

אחידות: מכיוון שמספר התפקידים בארגון הוא לא מאוד גדול (לא יותר מכמה עשרות, ברוב הארגונים), יחידת ההרשאות (שהן ה Role) הן Coarse-Grained, כלומר: מעט קבוצות המכילות הרבה משאבים.
לגישה זו יש מספר תוצרים:
  1. למשתמשים תהיה גישה למשאבים שהם לא זקוקים להם (כי עמיתים מקבילים להם היו זקוקים להם לעבודתם). כלומר: ההרשאות הן לא "מינימליות".
  2. הרבה יותר קל ופשוט לנהל את ההרשאות:
    1. אם ל"רופא" אחר יש הרשאה למשאב, מספיק שאוסיף אותך ל Role "רופא", כדי שתקבל "אותן הרשאות. "שכפול הרשאות" הוא פעולה דיי מסובכת עד בלתי-אפשרית במערכת שמנהלת הרשאות כ ACLs.
    2. כשעובדים מבצעים מעברי פרויקטים / תת-תפקיד, סיכוי גבוה שההרשאות שמוגדרות להם עכשיו – מספיקות. ==> תחזוקה קלה.
    3. מכיוון שיש מעט קבוצות, והן מתמפות ל"שפה הטבעית של הארגון", למי שמגדיר את ההרשאות ברור הרבה יותר טוב למי הן מיועדות.
    4. כאשר רוצים לבצע סקירה של המשאבים שזמינים לרופאים, קל מאוד לבדוק את ה Role של הרופאים ולראות מה זמין להם.

בואו נבחן את המודל:

  1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" – כן. ה Role מוכר בארגון ויש הרבה נקודות התייחסות.
  2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" – כן, ניתן לסקור את ה Role בקלות ולמצוא את כל המשאבים. סביר שהמשתמש מכיר את המשאבים כי הוא בעצמו חבר ב Role.
היכן ניתן למצוא את המודל?
שרתי ווב, JEE, Windows, .NET, מערכות שונות של SAP, Oracle, IBM ועוד.
סה"כ מודל ה RBA נחשב כ "Best Practice" בתעשיית ה Enterprise וכמודל מוצלח במיוחד. הוא מספק פשטות ניהול שהיא הדרך הכמעט-יחידה של ארגון לשלוט ולהבין אילו הרשאות יש לעובדים, מבלי לטרטר אותם יותר מדי.
הנה גרסה מעט יותר מורכבת של המודל (בכדי לסבר את העין):

כמובן שלמודל ה RBA יש גם כמה חסרונות:
  1. המודל לא מספק שליטה במידע רגיש שאמור להיות זמין לקבוצה קטנה של אנשים. במקרים אלו מספקים מודל הרשאות נוסף (למשל: ACL למשאבים רבים – כמו קבצים, PBA למקרים רוחביים / מופשטים כמו Ethical Wall [ב]) על גבי קבוצה מסוימת של משאבים ב Role, כלומר: מגבילים חלק מהמשאבים המשויכים ל Role לתת קבוצה של ה Role.
  2. מה קורה בארגון שבו אין בעלי תפקידים ברורים? ארגונים בהם מידע מוגש על בסיס "need to know"? – מודל ה RBA פשוט לא מתאים.

סיכום

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

שיהיה בהצלחה!

ליאור

[א] הנה הסבר מוצלח בנושא: https://crackstation.net/hashing-security.htm

[ב] המקרה בו 2 בעלי תפקידים לא מורשים לגשת למידע אחד של השני מסיבות אתיות. לדוגמא: משרד עו"ד שמייצג שתי חברות מתחרות בתיקים שונים. עדיין, אסור לעו"ד שמייצג את חברה א' למצוא מידע על החברה המתחרה ב'.