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

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

 שירות ופרוטוקול: _sips._tcp.mtls.example.com עדיפות: משקל 1: מספר יציאה 10: יעד 5062: us-expe1.example.com 

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

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

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

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

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

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

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

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

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

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

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

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

חברה עם דומיין DNS המוגדר ל-"hacker.com" קונה שירותים היברידיים של Webex. חברה אחרת, עם דומיין משלה המוגדר ל"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 יפעלו על הדומיין שלה.

   • באמצעות 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.

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

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

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

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

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

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