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

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

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

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

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

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

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

הכביש המהיר-C והכביש המהיר-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 עבור אשכול של שני שרתי כביש מהיר נראית כך:

_sips._tcp.example.com מיקום שירות SRV:

עדיפות = 10

משקל = 10

יציאה = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com מיקום שירות SRV:

עדיפות = 10

משקל = 10

יציאה = 5062

svr hostname = us-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.

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

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

אם האימות ההדדי מופעל, Expressway-E תמיד מבקש את אישור הלקוח. כתוצאה מכך, גישה ניידת וגישה מרחוק (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 

גישה עסקית-לעסק, גישה ניידת ומרוחקת ותעבורת Webex באותו זוג כביש מהיר

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

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

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

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

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

   • תחום DNS של כביש מהיר-E

   • תחום URI של ספריה

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

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

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

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

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

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

לאחר מכן, היא נכנסת לאפליקציית 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 Services יעבדו על הדומיין שלה.

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

     

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

     

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

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

     

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

2. בדיקת בעלות שם DNS של כביש מהיר-E.

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

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

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

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

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

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

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

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

רשימה של אישורי רשות אישורים נדרשת גם עבור הכביש המהיר-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 הוא השיטה המומלצת של מיקרוסופט למשימה זו. מנהלי מערכת של כביש מהיר-C אינם צריכים לדעת את הסיסמה, מכיוון שמנהל מערכת של Exchange יכול להזין את הערך בממשק Expressway-C . הסיסמה אינה מוצגת בבירור, גם אם למנהל המערכת של Expressway-C יש גישה שורשית לתיבה Expressway-C . הסיסמה מאוחסנת מוצפנת באמצעות אותו מנגנון הצפנת אישורים כמו סיסמאות אחרות בכביש המהיר-C.

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

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