צלילה עמוקה לאבטחת Salesforce: אימות והרשאה בהסבר
ברוכים הבאים לתחילתו של מסע מקיף באבטחת Salesforce, שמתחיל באבני היסוד: אימות (authentication) והרשאה (authorization). המאמר הזה הוא הראשון בסדרה שמטרתה לפרום את רשת מנגנוני האבטחה של Salesforce.
היסודות: אימות והרשאה
אימות הוא התהליך שמוודא שישות, בין אם זה משתמש בדפדפן ובין אם זו מכונה שניגשת למערכת, היא באמת מי שהיא טוענת שהיא. הרשאה, לעומת זאת, קובעת אילו פעולות מותר לישות המאומתת לבצע בתוך Salesforce. שניהם קריטיים כדי להבטיח שהנתונים שלכם ב-Salesforce יישארו מאובטחים, ושרק משתמשים וישויות מורשים יוכלו לגשת אליהם.
מדפדפנים ועד ממשקי API: הבנת נקודות הכניסה
Salesforce מוודאת שכל התעבורה הנכנסת משתמשת ב-SSL וב-TLS להעברת נתונים מאובטחת. (נרחיב על המונחים האלה במאמר עתידי.)
כשמדמיינים איך נתונים נכנסים ל-Salesforce, כדאי לחשוב על שני מסלולים עיקריים:
- ישירות דרך דפדפן, על ידי משתמש
- דרך אפליקציית לקוח של API, כמו אפליקציה לנייד או שרת אחר
שני המסלולים מתחילים את דרכם בתקשורת עם שרת האימות של Salesforce.
[caption id="" align=“alignnone” width=“1800”]
תרשים שמציג את הדרכים השונות שבהן מערכות חיצוניות יכולות לגשת ל-Salesforce Core [/caption]
בואו נפרק את זה עוד:
גישה מבוססת דפדפן
עבור בני אדם שעובדים עם Salesforce דרך דפדפן:
[caption id="" align=“alignnone” width=“1840”]
תהליכי אימות מהדפדפן אל Salesforce [/caption]
- שכבות אבטחה נוספות לאימות: אימות רב-שלבי (MFA), טווחי IP ותעודות בצד הלקוח.
- ספקי זהויות: Salesforce יכולה לשמש כספק הזהויות (Identity Provider, IDP) שמאמת את המשתמש. לאחר האימות, השרת של Salesforce מספק אסימון סשן (session token) למופע ה-ORG של הלקוח.
- ספק זהויות צד שלישי: במקום Salesforce, ספק זהויות צד שלישי, שמוגדר ביחסי SSO עם Salesforce, יכול לטפל באימות. במקרה כזה ספק הזהויות שולח טענת SAML (SAML assertion) ל-Salesforce, וזו מנפיקה את אסימון הסשן אחרי שהיא מאמתת אותה.
לאחר מכן, מנגנוני ההרשאה שולטים בגישה לדפים ולמשאבים.
גישה של לקוחות API
עבור מכונות שמנסות לגשת ל-Salesforce:
[caption id="" align=“alignnone” width=“1820”]
תהליכי לקוח שמתאמתים מול ממשקי ה-API של Salesforce [/caption]
תהליכי OAuth: מכונות יכולות להשתמש באחד מכמה תהליכי OAuth כדי לקבל גישה, מתהליך שרת האינטרנט (web server flow) שמתאים לשרתי אינטרנט חיצוניים ועד תהליך פרטי הגישה של הלקוח (client credentials flow), ועוד רבים ביניהם. לכל אחד מהם רצף ומטרה משלו.
יצירת סשן: לאחר האימות, שרת האימות של Salesforce מוסר אסימון סשן שמעניק ללקוח ה-API גישה למשאבים של Salesforce.
ואז נכנסים לתמונה כללי ההרשאה.
לסיכום: איך הכול מתחבר
לא משנה מה נקודת הגישה, דפדפן או לקוח API, התהליך כולל:
אבטחה ברמת התעבורה: שימוש ב-TLS, ואולי הוספת שכבות כמו רשימה לבנה של כתובות IP ותעודות בצד הלקוח לאבטחה משופרת.
אימות: בשלב הזה מזהים את המשתמש או את המערכת. כאן נכנסים רכיבים כמו MFA או ספקי זהויות צד שלישי.
הנפקת אסימון סשן: לאחר האימות, הישות מקבלת אסימון סשן, שמשמש כדרכון למשאבים של Salesforce.
הרשאה: המחסום האחרון. גם עם אסימון סשן תקף, ההרשאה היא שקובעת לאילו משאבים הישות יכולה לגשת.
עם הידע הבסיסי הזה, אנחנו מוכנים לצלול עמוק יותר לדקויות של אבטחת Salesforce במאמרים הבאים. הישארו איתנו לבחינה מפורטת עוד יותר של כל אחד מהרכיבים שהוזכרו למעלה.
תודה שקראתם, ואני מקווה שמצאתם את זה מועיל. חכו לפרק הבא לתובנות נוספות על אבטחת Salesforce.
הישארו איתנו
צאו לדרך עם Salesforce Identity בביטחון! לתובנות ולטיפים נוספים, הישארו איתנו כאן ב-www.SteveTechArc.com ובערוץ ה-YouTube @SteveTechArc (opens in a new tab). הירשמו והעמיקו את ההבנה שלכם ב-Salesforce Identity.
עוזרים לשנות את העולם בשיתוף מידע על אינטגרציה עם עמיתים ארכיטקטים ועם מי שנמצאים במסע שלהם לארכיטקטורה!
STA 3.1