אבטחת מידע בענן בשלושה מימדים

 

  • ניהול זהויות IDP ו- SSO

    Identity Safe

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

    קרא עוד
  • ניהול תחנות קצה UEM

    Outsafe

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

    קרא עוד
  • ניהול גישה מאובטחת SDP

    SafeEdge

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

    קרא עוד

המשימה שלנו

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

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

קרא עוד

הלקוחות בטוחים

"בשיתוף פעולה עם Teraworks ומרכז הפיתוח של okta, העלנו לענן מערכת פיננסית עם SSO מבוסס okta העומדת בדרישות הפרטיות של הרגולטור בזמן שיא"

NEX | גיא נאור

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

ZIM | סנדרה לוי

"איכות העבודה והשירות שקיבלנו במהלך הפרויקט היו מצויינים במידה ונצטרך לבצע פרויקט נוסף בעתיד נבחר ב Teraworks"

 

SOLI | מיה ברוורמן

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

VMWare | רן עטיה

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

Fundbox | אלכס אוסוב

הסמכות ורשיונות

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

מאמרים

  • MobileIron & Microsoft – שילוב מנצח

    מאת: Muli Motola | 09/12/2019

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

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

    תשתית מחשוב היברידית זקוקה לגמישות שמספק MobileIron

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


    תשתית היברידית לניהול ניידים ותחנות קצה מול שירותי רשת ושירותי ענן

    זה לא מסתיים במיקרוסופט 

    שוק שירותי הענן לא זהה לשווקי התוכנה המסורתיים שמיקרוסופט צמחה מהם. בעבר, מיקרוסופט הייתה יכולה למכור את Windows לארגון בציפייה שתוכל לנעול את הלקוח בפלטפורמה שלה בעשר השנים הבאות או יותר. בעידן הענן זה  פשוט לא עובד. אמנם האינטגרציות של מיקרוסופט עשויות להיות הדוקות יותר וחוויות משתמשי הקצה חלקות יותר עם הפתרונות שלהם, אך ארגונים רבים מעוניינים להשתמש באפליקציות ושירותים Best of Breed על מנת לאפשר לעובדים את חוויית משתמש הקצה המיטבית. בסקר של גרטנר שנעשה בנובמבר 2019 נמצאה מערכת mobileiron חביבת הקהל ומובילה בפער גדול על intune בכל ההיבטים כולל: סולמיות (scalability), קלות השימוש, אינטגרציה, והתאמות.


    פרס הלקוחות הממליצים הוענק למוביילאיירון

    חווית משתמש-קצה UX וגמישות בבחירת המכשירים

    הלקוחות בוחרים ב- MobileIron כאשר נדרשת חוויית Onboard פשוטה של משתמשים ולממשק הניהולי הטוב ביותר. MobileIron מציעה את הגמישות לעבוד בכל מכשיר עם כל אפליקציה של כל ספק שהוא, ואילו ב- Microsoft Intune עליכם לבחון את פרטי המקרה על פי השימוש. לדוגמה Mobileiron תומך בצורה מלאה בתרחישים הבאים:

    • מכשירי אנדרואיד עם פרופיל אישי מנוהל, Android with a managed personal profile.
    • מכשירי סמסונג וזברה עם עדכוני Firmware Over-the-Air.
    • שליטת macOS מלאה.

    MobileIron הוא הפתרון הטוב ביותר עבור ארגונים שצריכים לנהל מכשירים מעבר ל- Windows ו- iOS על ידי מתן תמיכה בכל מקרי השימוש במכשירי הקצה האפשריים.

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

    גישת האמון האפסי Zero-Trust של MobileIron מספקת את הנראות ואת בקרות ה- IT הנחוצות כדי לאבטח, לנהל ולפקח על כל מכשיר, משתמש, אפליקציה ורשת המשמשים לגישה לנתונים עסקיים. הוא מגן על הנתונים על דרכי הגישה והשימוש בהם – לא משנה היכן הוא נמצא, או מי הבעלים של המכשירים והשירותים המעורבים. יכולות קריטיות אלה נותנות את התשתית לתרחישים בהם  Intune לא יכול לתמוך באופן מלא וזאת לתשתית on-prem, SaaS, או היברידית.

    ניטור חסימה והסרת תוכן ממכשיר נגוע Threat Defence

    לאחרונה גילו חוקרים מאוניברסיטת פרדו ואוניברסיטת איווה (Purdue University and the University of Iowa) תחום שלם של פרצות מסוג man-in-the-middle בפרוטוקול ה-5G שעומד לכבוש את העולם בקרוב. פירוש הדבר, שאם עדיין לא עשית זאת, זה הזמן הנכון לעבור להזדהות מבוססת zero-trust. איננו יודעים מאיפה הפגיעות הבאה תגיע, אך אנו יכולים לנקוט צעדים להכנה. השלב הראשון הוא להפסיק לסמוך על מכשירים שאנו לא מפקחים עליהם כל העת. השלב הבא הוא לנקוט בפעולה ברגע שאנחנו מגלים חריגות כלשהן, פעולות כמו הסרת כל תוכן ארגוני רגיש, חסימת מכשיר מגישה לענן ולמשאבים ארגוניים, או אפילו מחיקת התוכן העסקי מהמכשיר לחלוטין. מעקב הוא חשוב, אך הגנה על הארגון שלך על ידי פעולה מהירה היא קריטית. לשם כך הוסיפה mobileiron את רכיב ה-Threat defence באמצעות שיתוף פעולה עם חברת Zimperium על מנת לאפשר הגנה אקטיבית על המכשירים. בניגוד למתחרים, Mobileiron מאפשר סגירת מעגל מזיהוי לחסימה ללא חיבור לשירות חיצוני באמצעות רכיב מובנה במכשיר.


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

    אבטחה מתקדמת עבור office 365 ממקום אחד מרכזי

    על מנת לנהל בצורה טובה את האבטחה של אפליקציות מנוהלות ב-iOS, פיתחו מייקרוסופט את ״מדיניות ההגנה על אפליקציות״ Intune app protection policies. מטרתו למנוע מעבר מידע מסביבה מנוהלת (container) לסביבה פרטית במכשיר. MobileIron יכולה לנהל את מדיניות ההגנה על אפליקציות וכך להנגיש את כל אמצעי ההגנה ממקום מרכזי ולפשט את העבודה. על ידי הוספת מדיניות ההגנה של אפליקציות Intune לרשימה הארוכה של פתרונות נתמכים, כולל  Android enterprise, Samsung Knox, iOS ו-Windows Information Protection ממשיכה Mobileiron לתת ללקוחות את הגמישות הדרושה להם כדי לעמוד בדרישות העסקיות ולתמוך בכל מגוון המכשירים הנדרש.

    הזדהות ללא סיסמא באמצעות MobileIron

    הזדהות באמצעות MobileIron device-as-identity היא הראשונה מסוגה בשוק. MobileIron מאפשרת גישה ללא סיסמה לשירותי ענן מכל מכשיר – מנוהל או לא מנוהל – באמצעות המכשיר הנייד כמזהה מאובטח של המשתמש, ואילו הגישה של מיקרוסופט מתחילה ומסתיימת בדפדפן. מיקרוסופט מספקת כעת אימות ללא סיסמה רק עבור Windows Hello.

    MobileIron proven leader 

    בחירה ב-Mobileiron היא בחירה ביצרן שכל התמחותו בניהול התקני קצה וניידים. ולראיה, הציונים הגבוהים שמשיגה החברה במדדים השונים כולל 9 שנים רצוף ברביע המובילים בגרטנר, במבחני יכולת ולאחרונה נבחרה להיות הנציג היחיד בין יצרני ה-MDM במבחני Zero Trust.

    המומחים שלנו ב teraworks יעזרו לכם לתכנן ולהטמיע את מאפייני הניהול ואבטחת המידע עבור התקני הקצה והניידים שלכם בסביבת מיקרוסופט Azure AD ו-Office 365 במהירות על מנת שתוכלו להנות מהאמינות, פשטות השימוש והגמישות של הפלטפורמה.

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

    מאת: Muli Motola | 19/11/2019

    פרוטוקול oauth 2.0 – בימינו, כשאתה שומע מישהו מדבר על OAuth, סביר להניח שהם מתכוונים ל- OAuth 2.0. גרסאות קודמות לתקן אינן מיושמות יותר.OAuth היא פרוטוקול הרשאה המאפשרת לך לעבוד עם מערכות חיצוניות בצורה מאובטחת באמצעות מזהים דיגיטליים הנקראים Tokens. סוג אחד של Tokens נקרא Access Token. תפקידו לאפשר לך לממש APIs בצורה מאובטחת. שירות ה- API יכול להשתמש ב- Access Token כדי לקבוע אם אתה רשאי לעשות את מה שאתה מנסה לעשות או לא.

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

    הגדרות חשובות להבנת התהליך:

    OAuth Term
    Definition

    Authorization Server 
    השרת האמון על ההרשאות והקצאת ה- Tokens


    Client Application

    האפליקציה אשר מבקשת בשם המשתמש גישה לנתונים

    Resource Owner

    המשתמש אשר מבקש הרשאת גישה לנתונים באמצעות האפליקציה
    Resource Server
    השרת אשר חושף נתונים באמצעות API ומסוגל לאמת
    Access Token שמגיעים משרת ההרשאות

    Authorization Flows

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

    1. Implicit Flow – מותאם לאפליקציות ״דף בודד״ SPA לא מהימנות (כמו Angular או Vue.js)

    2. Code Flow – עבור אפליקציות מהימנות (כמו Spring Boot או .NET)

    3. Code Flow with PKCE – עבור אפליקציות Untrusted Native או Mobile Apps.

    4. Client Credentials – עבור Server to Server בין שרתים מהימנים ללא משתמש קצה.

    5. Resource Owner Password – לא מומלץ – שימש בעבר עבור שירותי אינטרנט מהימנים עם דף כניסה מותאם אישית שמעבירים את סיסמת משתמש הקצה אל שרת ההרשאות.

    איזה תרחיש מתאים למערכת שאתם מפתחים? קבלו את עץ החלטה!

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

    Authorization Code Flow

    תרחיש זה מאפשר לשרת ההרשאות להתמודד עם ארכיטקטורה הכוללת רכיב דפדפן (שאינו מהימן) ורכיב מתווך מהימן כגון יישום Spring Boot או NET.

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

    Okta Authentication and MFA 

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

    Access Token

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

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

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

    JSON Web Tokens

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

    הטוקנים הם בפורמט JSON Web Token או בקיצור JWT וחתומים על ידי מפתחות אסימטרים JSON Web Keys או בקיצור JWK אותם ניתן לקבל משרת ההרשאות ולשמור בשרת הנתונים. על מנת לפענח אותם ולאמת את מקורם ניתן להשוות את המפתח ששימש להצפנת הטוקן עם המפתח שנשמר בשרת ההרשאות מקומית או לחזור בקריאת API, אל שרת ההרשאות על מנת לאמת את הטוקן (פחות מומלץ בתרחישים הדורשים ביצועים גבוהים).

    מקורות:

    • https://developer.okta.com/docs/guides/implement-auth-code/-/use-flow/
    • https://developer.okta.com/docs/concepts/auth-overview/#what-kind-of-client-are-you-building
    • https://developer.okta.com/blog/2018/12/13/oauth-2-for-native-and-mobile-apps

    קרא עוד
  • Single Sign On ל- Slack בחצי מחיר

    מאת: Itzik Hanan | 16/09/2019

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

    אז מדוע ארגונים מאמצים בצורה נמרצת שירותי SAAS אבל נמנעים מלאמץ באותה מהירות את רכיב האבטחה הראשון והחשוב ביותר – SSO? על כך במאמר זה.

    הזדהות Authentication – השער לשירותי הענן

    הזדהות אחידה –authentication Single sign on או בקיצור SSO הוא מנגנון ל"מיקור חוץ" של תהליך אימות המשתמשים באתר או באפליקציה ארגונית אל מול מנהל זהויות חיצוני identity Provider) IDP) כגון Google, Facebook, OKTA, וכדומה.
    בהקשר שלנו, SSO מתייחס ליכולת של יצרן מערכת SaaS כמו SLACK לאפשר ללקוח עסקי להנות ממספר מרכיבי אבטחת מידע קריטיים שמספקת מערכת ניהול זהויות כמו OKTA:

    • אימות Authentication מבוסס הקשר context כגון הרשת ממנה התחבר המשתמש, העיתוי, והמכשיר.
    • הפעלת הזדהות קשיחה באמצעות מגוון פקטורים חזקים Multi-Factor Authentication (MFA).

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

    אז מדוע ארגונים מאמצים בצורה נמרצת שירותי SaaS אבל נמנעים מלאמץ באותה מהירות את רכיב האבטחה הראשון והחשוב ביותר – SSO?

    בבדיקה שערך אתר האינטרנט https://sso.tax/ נמצא ששירות ה- SSO זמין ברוב שירותי ה-SaaS רק כחלק מתמחור "Enterprise". שירותים אלו בדרך כלל מתומחרים גבוה אל מול העלויות הבסיסיות, ומקפלים בתוכם פונקציונאליות נוספות, פעמים רבות הרבה מעבר לצרכים של החברה המשתמשת בתוכנה. לטענתם, חברות שמכריזות שהן "לוקחות את האבטחה שלך ברצינות", צריכות לוודא שה- SSO זמין ברישוי הבסיס או בעלות סבירה שאינה קשורה לפונקצינאליות האחרת שלו.


    תמונה 1: מדגם של שירותי ענן ותוספת העלות הנדרשת עבור SSO

    מהן העלויות הנסתרות של Single sign-on?

    בשלב התכנון של מוצר מסחרי מסוג שירות ענן ארגוני, נדרשת מצד מנהל המוצר התייחסות בסיסית לניהול המשתמשים ואבטחת הזהות שלהם. מרבית ספקי תשתיות הענן AWS, GCP, Azure מספקים במסגרת השירות גם מנגנון ניהול זהויות מובנה עמו אפשר להתחיל את הפיתוח. ישנם ארגונים אשר מתבססים על בסיס נתונים סטנדרטי כגון mySQL על מנת לממש מערכת ניהול זהויות ויוצאים לדרך. ככל שמספר המשתמשים גדל, ועל אחת כמה וכמה כאשר עסקים רבים מתחילים להשתמש בה, עולה הצורך בניהול פרטיות המשתמשים, רגולציה מורכבת, אבטחת מידע ופדרציה Federation של ההזדהות לארגונים אחרים. על מנת לממש את התכונות הללו יש לרכוש מערכת ניהול זהויות משודרגת כגון OKTA אשר מאפשרת לממש ניהול משתמשים, הזדהות חזקה, ופדרציה לעסקים (B2B) מסוג SAML או OpenID Connect.  באמצעות הטמעת ספריות מובנות ובזכות דוקומנטציה מפורטת (SDK), על ידי הפניית האבטחה למערכת המאובטחת של אוקטה ניתן לממש ניהול פשוט של פעולות ההזדהות וההרשאות (Authentication, authorization). תוספת העלות של מערכת כזו מהווה נטל שעל הארגון לבחור האם לספוג או להעביר ללקוח הקצה.


    תמונה 2: מחיר המדף של OKTA למערכת ניהול זהויות המוטמעת באפליקציית ענן

    מהן העלויות העיקריות של שירותי ניהול זהויות Identity management?

    ארגון IT  שמעוניין להתנהל בצורה מאובטחת ולתפעל את תשתיות הענן עם אוטומציה מלאה, רוכש שירות ניהול זהויות כגון אוקטה ומטמיע SSO בין שירותי הענן. ה-SSO מיושם באמצעות מגוון פרוטוקולים כגון: LDAP, RADIUS, SAML, OpenID Connect. העלות של המערכת מחושבת על פי מספר האפליקציות הדורשות חיבור, כמות המשתמשים ודרגת המדיניות שניתן להפעיל על החיבוריות. אבל העלות המצרפית איננה מסתכמת רק אל יצרן מערכת ההזדהות. כפי שראינו למעלה, גם יצרן האפליקציה דורש את הנתח שלו בעוגה. ומכאן מתחיל התסכול של הארגון, שלא תכנן תקציבית את העלויות המצרפיות ונשאר ללא תקציב לחבר את האפליקציות שתכנן ל-SSO.

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

    אז איך חוסכים את עלות ה-SSO של SLACK  ב-50%?

    באותיות הקטנות של חבילת Standard ניתן לראות את האפשרות המוצנעת:  OAuth with Google. המשמעות היא שניתן לממש SSO בין חבילת ה-slack לתכנית ה-g-suite הארגונית שלכם!

    Oauth הינו פרוטוקול מתקדם למימוש SSO בין מערכת ניהול זהויות לאפליקציית WEB. הפרוטוקול מבוסס API ומכיל תכונות מתקדמות שהופכות אותו לפרוטוקול המועדף כיום למימוש הזדהות. מימוש SSO במסגרת חבילת הבסיס של slack מאוד מוגבלת ובנויה עבור G-suite בלבד. אבל זוהי התקדמות משמעותית ברמת אבטחת המידע הארגונית ומומלץ מאוד ליישמה.
    חבילת ה-Plus לעומת זאת מכילה אפשרות למימוש SSO  באמצעות SAML. זהו הפרוטוקול הוותיק יותר ונפוץ במיוחד במערכות ההזדהות. הפרוטוקול SAML מכיל אומנם פחות אפשרויות אינטגרציה ואבטחה מפרוטוקול Oauth אבל מהווה האפשרות היחידה במקרים רבים עבור ארגונים רבים.  


    תמונה 3: מחיר המדף של Slack וחלק מהתכונות שמכילה החבילה

    חיבור slack ל- g-suite באמצעות oauth יעביר את ניהול המשתמשים תחת accounts.google.com של הארגון שלכם, משם הדרך קצרה ל-OKTA. במידה ואתם משתמשים במערכת ניהול זהויות ארגונית כגון OKTA כל שנותר לעשות הוא לחבר אותה אל סביבת ה-g-suite שלכם אם לא ביצעתם זאת עד כה.  בצורה כזו, בקשת הזדהות של משתמש אל מול ה-slack הארגוני, תועבר מייד לאימות במערכת OKTA ללא צורך באינטגרציה נוספת.

    מה אנחנו מרוויחים בחיבור SLACK ל-SSO  הארגוני?

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


    תמונה 4: ממשק הניהול המרכזי של אוקטה עבור g-suite

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

    • Single sign-on – הזדהות אחודה בהתאם לפרוטוקול הנתמך
    • Provisioning – הקמה והסרת משתמשים באפליקציית הקצה
    • Assignment – ניהול הרשאות ורישיונות באפליקציית הקצה
    • Push group – דחיפת משתמשים אל תוך קבוצות (כגון Distribution lists) באפליקציה

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

    קרא עוד
לעמוד הבלוג

בואו נדבר על הענן שלכם.

דברו איתנו, התקשרו לטלפון:073-3236441

או מלאו פרטיכם כאן, מבטיחים לחזור בהקדם

צור קשר hlink
X

צור קשר

דילוג לתוכן