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

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

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

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

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

• לאחר טיפול בפריטים אלה בסביבה שלך, שאר תצורת השירותים ההיברידיים שלך תעבור בצורה חלקה.

פרי@@ סת זוג Expressway-C ו- Expressway-E מאפשרת שיחות לאינטרנט וממנה באמצעות טכנולוגיות חציית חומ ת אש. פריסה זו היא מה שלו קח בצורה מאובטחת את בקרת השיחות המקומית שלך וקו שר אותה ל- Webex.

Expressway-C ו- Expressway-E אינם דורשים פתיחת יציאה נכנסת בחומת האש של אזור מפורז (DMZ) בגלל ארכיטקטורת חציית חומת האש. אבל יש לפתוח יציאות איתות TCP SIP ויציאות מדיה UDP נכנסות בחומת האש של האינטרנט כדי לאפשר לשיחות נכנסות לעבור. עליך להקדיש זמן לפתיחת היציאה המתאימה בח ומת האש הארגונית שלך.

ארכיטקטורת חציית חומת האש מוצגת בתר שים הבא:

לדוגמה, עבור שיחות נכנסות בין עסקים לעסקים (B2B) באמצעות פרוטוקול SIP, יש לפתוח יציאות TCP 5060 ו- 5061 (5061 משמש עבור SIP TLS) בחומת האש החיצ ונית, יחד עם יציאות מדיה UDP המשמשות ל שירותים כגון קול, וידאו, שיתוף תוכן, וידאו כפול וכן הלאה. אילו יציאות מדיה לפתוח תלויות במספר השיחות במקביל ובמספר השי רותים.

באפשרותך להגדיר את יציאת ההאזנה של SIP ב- Expressway להיות כל ערך בין 1024 ל- 65534. יחד עם זאת, יש לפרסם ערך זה וסוג הפרוטוקול ברש DNS SRV ומות הציבוריות, ויש לפתוח את אותו ערך בחומת האש של האינטרנט.

למרות שהתקן עבור SIP TCP הוא 5060 ועבור SIP TLS 5061, שום דבר לא מונע שימוש ביציאות שונות, כפי שמראה ה דוגמה הבאה.

דוגמה

בדוגמה זו, אנו מניחים כי יציאה 5062 מש משת לשיחות SIP TLS נכנסות.

הר DNS SRV שומה של אשכול של שני שר תי Expressway נראית כך:

_לגימות. _tcp.example .com מיקום שירות SRV:

priority = 10

weight = 10

port = 5062

שם מארח svr = אוס-expe1.example.com

_לגימות. _tcp.example .com מיקום שירות SRV:

priority = 10

weight = 10

port = 5062

שם מארח svr = אוס-expe2.example.com

משמעות רשומות אלה היא שהשיחות מופנות אל us-expe1.example.com ו- us-expe2.example.com עם חלוקת עומסים שווה (עדיפות ומשקל) תוך שימוש ב- TLS כסוג התחבורה ו- 5062 כמספר יציאת ההאזנה.

התקן חיצוני לרשת (באינטרנט) ומבצע שיחת SIP למשתמש של הת חום הארגוני (user1@example.com) חייב לשאול את ה- DNS כדי להבין באיזה סוג תחבורה להשתמש, מספר היציאה, כיצד להעמיס ולשיתוף התנועה ולאילו שרתי SIP לשלוח את השיחה.

אם ערך ה- DNS כולל _sips. _tcp, הערך מציין SIP TLS.

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

לחיצת יד TLS מוצגת בתרשים הבא:

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

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

הענן בודק את זהות הכביש המהיר, ו- Expressway בודק את זהות הענן. לדוגמה, אם זהות הענן באישור (CN או SAN) אינה תואמת את מה שהוגדר ב- Expressway, החי בור יבוטל.

אם אימות הדדי מופעל, Expressway-E תמיד מבקש את אישור הלקוח. כתוצאה מכך, Mobile ו - Remote Access (MRA) לא יעבדו, מכיוון שברוב המקרים אישורים אינם נפרסים בלקוחות Jabber . בתרחיש של עסק לעסק, אם הי שות המתקשרת אינה מסוגלת לספק אישור, השיחה מנותקת.

אנו ממליצים להשתמש בערך שאינו 5061 עבור TLS עם אימות הדדי, כגון יציאה 5062. השירותים ההיברידיים של Webex משתמשים באותה רשומת SIP TLS המשמשת עבור B2B. במקרה של יציאה 5061, שירותים אחרים שאינם יכולים לספק אישור לקוח TLS לא יעבדו.

אם רשומה קיימת כבר משמשת לתקשורת בין עסקים לעסק, מומלץ לציין תת-ד ומיין של התחום הארגוני כיעד SIP ב- Control Hub, וכתוצאה מכך רשומה ציבור ית, כדלק DNS SRV מן:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

תנועה מעסק לעסק, נייד ו Remote Access - Webex באותו צמד כבישים מהירים

שיחות עסקיות לעסקים (B2B) ושיחות ניידות ו- Remote Access (MRA) משתמשות ביציאה 5061 עבור SIP TLS, ותעבורת Webex משתמשת ביציאה 5062 עבור SIP TLS עם אימות הדדי.

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

בדיקת הזהות מתבצעת בשני שלבים:

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

   • דומיין דוא"ל

   • תחום DNS אקספרסווי-E

   • דומיין URI של ספרייה

2. בדיקת בעלות על שם DNS של Expressway-E. שלב זה מבוצע באמצעות יישום TLS עם אימות הדדי וכרוך בשימוש באישורים ציבוריים הן בענן והן בכביש המהיר. שלא כמו בדיקת זהות הדומיין, שלב זה מבוצע במהלך כל שיחה שמתבצעת ומתקבלת מהענן.

חשיבות בדיקת הבעלות על הדומיין

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

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

חברה עם דומיין DNS מוגדר כ- "hacker.com" קונה שירותים היברידיים של Webex. חברה אחרת, עם דומיין משלה מוגדר ל- "example.com", משתמשת גם בשירותים היברידיים. אחד המנהלים הכלליים של חברת Example.com נקרא ג'יין רו ויש לו את המדריך URI jane.roe@example.com.

המנהלת של חברת Hacker.com מגדירה את אחד מהמדריכים שלה ל- jane.roe@example.com ואת כתובת הדוא"ל ל- jane.roe@hacker.com. היא יכולה לעשות זאת מכיוון שהענן אינו בודק את תחום ה- URI SIP בדוגמה זו.

לאחר מכן, היא נכנסת לאפליקציית Webex באמצעות jane.roe@hacker.com. מכיוון שהיא הבעלים של הדומיין, דוא"ל האימות נקרא ונענה, והיא יכולה להיכנס. לבסוף, היא מתקשרת לעמית, ג'ון דו, על ידי חיוג john.doe@example.com מאפליקציית Webex שלה. ג'ון יושב במשרדו ורואה שיחה במכשיר הווידאו שלו מגיעה מ- jane.roe@example.com; זהו ה- URI של הספרייה המשויכת לחשבון הדוא"ל הזה.

"היא בחו"ל", הוא חושב. אולי היא זקוקה למשהו חשוב". הוא עונה לטלפון, וג'יין רו המזויפת מבקשת מסמכים חשובים. היא מסבירה שהמכשיר שלה שבור, ומכיוון שהיא נוסעת, היא מבקשת ממנו לשלוח את המסמכים לכתובת הדוא"ל הפרטית שלה, jane.roe@hacker.com. בדרך זו החברה מבינה רק לאחר שג'יין רו חוזרת למשרד כי מידע חשוב הודלף מחוץ לחברה.

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

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

כדי להבטיח בעלות זו, נדרשים שני שלבי אימות הדומיין:

1. להוכיח כי החברה מחזיקה בדומיין הדוא"ל, תחום Expressway-E, תחום URI של ספרייה.

   • כל התחומים הללו חייבים להיות ניתנים לניתוב וידועים על ידי שרתי DNS ציבוריים.

   • כדי להוכיח את הבעלות, מנהל ה- DNS חייב להכניס רשומת טקסט DNS (TXT). רשומת TXT היא סוג של רשומת משאבים ב- DNS המשמשת לספק את היכולת לשייך טקסט שרירותי ולא מעוצב למארח או לשם אחר.

   • על מנהל ה- DNS להכניס את רשומת ה- TXT באזור שיש להוכיח את בעלותו. לאחר שלב זה, ענן Webex מבצע שאילתת רשומות TXT עבור תחום זה.

   • אם שאילתת TXT מוצלחת והתוצאה תואמת לאסימון שנוצר מענן Webex, התחום מאומת.

   • כדוגמה, על המנהל להוכיח שהיא הבעלים של הדומיין "example.com", אם היא רוצה ששירותי Webex Hybrid יעבדו על הדומיין שלה.

   • דרך https://admin.webex.com, היא מתחילה את תהליך האימות על ידי יצירת רשומה TXT שתתאים לאסימון שיצר ענן Webex:

     

   • לאחר מכן מנהל ה- DNS יוצר רשומת TXT עבור תחום זה עם הערך המוגדר ל 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, כמו בדוגמה הבאה:

     

   • בשלב זה, הענן יכול לוודא שרשומת ה- TXT עבור התחום example.com תואמת את האסימון.

   • הענן מבצע בדיקת DNS של TXT:

     

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

2. בדיקת בעלות על שם DNS של Expressway-E.

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

   • שיחות אל הענן וממנו תלויות בתעודה שהונפקה ל- Expressway-E. אם האישור אינו תקף, השיחה בוטלה.

מחבר ההתקנים של Webex חייב לתקשר עם Webex כדי שיחה היברידית תפעל.

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

תקשורת לענן Webex משתמשת ב- TLS. מחבר ההתקנים של Webex הוא לקוח ה- TLS, וענן Webex הוא שרת ה- TLS. ככזה, מחבר ההתקנים של Webex בודק את אישור השרת.

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

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

בעת תקשורת עם התקנים, הכלי משתמש באישורים מהימנים שאתה מספק. נכון לעכשיו הדרך לעשות זאת היא על ידי הצבתם [home folder]/.devicestool/certs.

רשימה של אישורי רשות אישורים נדרשת גם עבור Expressway-E בצמד החוצה. Expressway-E מתקשר עם ענן Webex באמצעות SIP עם TLS, שנאכף על ידי אימות הדדי. Expressway-E בוטח בשי חות המגיעות מענן והולכות אליו, רק אם ה- CN או ה-SAN של האישור המוצג על ידי הענן במהלך הגדרת חיבור TLS תואם לשם הנושא שהו גדר עבור אזור ה- DNS ב- Expressway ("callservice.webex.com"). רשות האישורים משחררת אישור רק לאחר בדיקת זהות. יש להוכיח את הבעלות על הדומיין callservice.webex.com כדי לקבל אישור חתום. מכיוון שאנו (סיסקו) מחזיקים בד ומיין זה, שם ה- DNS "callservice.webex.com" הוא הוכחה ישירה לכך שהעמית המרוחק הוא באמת Webex.

מחבר לוח השנה משלב את Webex עם Microsoft Exchange 2013, 2016, 2019 או Office 365 באמצעות חשבון התחזות. תפקיד ניהול התחזות היישומים ב- Exchange מאפשר ליישומים להתחזות למשתמשים בארגון כדי לבצע משימות בשם המשתמש. תפקיד התחזות ליישום חייב להיות מוגדר ב- Exchange ומשמש במחבר לוח השנה כחלק מתצורת Exchange בממשק Expressway-C.

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

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

לקבלת אבטחה נוספת, בצע את השלבים בפרי סת מחבר לוח השנה של Expressway Microsoft Exchange כדי להפעיל TLS על מנת לאבטח חיבורי EWS בחוט.