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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיפור שיציג את החשיבות של בדיקת הבעלות על הדומיין

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

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

חברה עם תחום DNS המוגדר כ"hacker.com" קונה את השירותים ההיברידיים של Cisco 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 מאפליקציית Cisco Webex Teams שלה . ג'ון יושב במשרדו ורואה שיחה במכשיר הווידאו שלו שמגיעה jane.roe@example.com; זהו ה- URI של הספרייה המשויך לחשבון הדוא"ל הזה.

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

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

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

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

1. להוכיח שהחברה היא הבעלים של תחום הדוא"ל, תחום Expressway-E, דומיין URI מדריך.

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

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

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

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

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

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

     

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

     

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

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

     

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

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

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

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

יש לרשום את מארח המחברים של הכביש המהיר-C ב-Cisco Webex על מנת ששירותים היברידיים יפעלו.

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

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

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

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

באמצעות העלאה ידנית, באפשרותך להעלות את כל אישורי רשות האישורים הרלוונטיים לחנות הנאמנות של Expressway-C.

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

אם תאפשר התקנה אוטומטית של אישורי רשות אישורים, תופנה אל https://admin.webex.com (פורטל הניהול). הניתוב מחדש נעשה על ידי הכביש המהיר-C עצמו ללא כל התערבות המשתמש. אתה, כמנהל Cisco Webex , חייב לבצע אימות באמצעות חיבור HTTPS. זמן קצר לאחר מכן, הענן דוחף את אישורי ה- CA לכביש המהיר-C.

עד שהאישורים יועלו למאגר הנאמנות של Expressway-C, לא ניתן יהיה ליצור את חיבור HTTPS.

כדי למנוע בעיה זו, הכביש המהיר-C מותקן מראש עם אישורי CA מהימנים של Cisco Webex. אישורים אלה משמשים רק כדי להגדיר ולאמת את חיבור HTTPS הראשוני, והם אינם מופיעים ברשימת האמון של Expressway-C. לאחר שהאישורים של רשויות האישורים המהימנים נשלפים מהענן באמצעות חיבור HTTPS ראשוני זה, אישורים אלה זמינים לשימוש בכל הפלטפורמה; לאחר מכן, הם מופיעים ברשימת האמון של הכביש המהיר-C.

רשימה זו מציגה את אישורי רשות האישורים שבהם משתמש כעת ענן Cisco Webex . רשימה זו עשויה להשתנות בעתיד:

• C=IE, O=בולטימור, OU=CyberTrust, CN=בולטימור CyberTrust Root

• C = ארה"ב, O = GTE תאגיד, OU = GTE CyberTrust פתרונות, Inc., CN = GTE CyberTrust שורש גלובלי

• C = ארה"ב, O = קבוצת Go Daddy, Inc., OU = Go Daddy Class 2 רשות אישורים

• C = ארה"ב, ST = אריזונה, L = סקוטסדייל, O = GoDaddy.com, Inc., CN = Go Daddy Root Certificate Authority - G2

• C = BM, O = QuoVadis מוגבלת, CN = QuoVadis שורש CA 2

• C = US, O = thawte, Inc., OU = חטיבת שירותי הסמכה, OU = (c) 2006 thawte, Inc. - לשימוש מורשה בלבד, CN = להפשיר שורש ראשי CA

• C = ארה"ב, O = VeriSign, Inc., OU = מחלקה 3 רשות התעודה הראשית הציבורית

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

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

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

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