Дякуємо за відгук.
Надіслати відгук?
Користувачі вибирають тип наради, коли вони планують зустріч. При прийомі учасників з лобі, а також під час зустрічі, господар може побачити статус підтвердження особи кожного учасника. Існує також код зустрічі, який є спільним для всіх поточних учасників зустрічі, який вони можуть використовувати для перевірки того, що їх зустріч не була перехоплена небажаною атакою сторонньої Meddler In The Middle (MITM).
Поділіться наступною інформацією з організаторами зустрічі:
-
Приєднуйтесь до зустрічі Webex з наскрізним шифруванням
Підтвердити особу
Наскрізне шифрування з перевіркою особистості забезпечує додаткову безпеку наскрізної зашифрованої зустрічі.
Коли учасники або пристрої приєднуються до спільної групи MLS (Безпека рівня обміну повідомленнями), вони представляють свої сертифікати іншим членам групи, які потім перевіряють сертифікати у відповідності з органами сертифікатів, що видають сертифікати (CA). Підтверджуючи дійсність сертифікатів, CA перевіряє особу учасників, а зустріч показує учасників/пристрої як перевірені.
Користувачі програми Webex автентифікують себе у сховищі ідентифікацій Webex, який видає їм маркер доступу, коли аутентифікація проходить успішно. Якщо їм потрібен сертифікат для підтвердження своєї особи під час наскрізної зашифрованої наради, сертифікат Webex видає їм сертифікат на основі їх токена доступу. Наразі ми не надаємо користувачам можливість отримати сертифікат, виданий третьою стороною/зовнішньою CA. Webex Meetings
Пристрої можуть здійснювати аутентифікацію за допомогою сертифіката, виданого внутрішньою (Webex) CA, або сертифіката, виданого зовнішньою CA:
-
Внутрішня CA—WebEx видає внутрішній сертифікат на основі токена доступу облікового запису машини пристрою. Сертифікат підписаний Webex CA. Пристрої не мають ідентифікаторів користувачів так само, як і користувачі, тому Webex використовує (один з) доменів вашої організації під час написання ідентифікатора пристрою (Common Name (CN)).
-
Зовнішня CA — запитуйте та купуйте сертифікати пристроїв безпосередньо у вибраного емітента. Ви повинні зашифрувати, безпосередньо завантажувати та авторизувати сертифікати, використовуючи секрет, відомий тільки вам.
Cisco не бере участі, що робить це способом гарантувати справжнє наскрізне шифрування та підтверджену ідентичність, а також запобігти теоретичній можливості того, що Cisco може підслуховувати вашу зустрічі/розшифрувати ваші медіа.
Внутрішньо виданий сертифікат пристрою
Webex видає сертифікат пристрою, коли він реєструється після запуску, і поновлює його, коли це необхідно. Для пристроїв сертифікат включає ідентифікатор облікового запису та домен.
Якщо ваша організація не має домену, сертифікат сертифіката Webex видає сертифікат без домену.
Якщо ваша організація має кілька доменів, ви можете використовувати Центр керування, щоб повідомити Webex, який домен пристрій використовувати для ідентифікації. Ви також можете використовувати інтерфейс XConfiguration Conference endToEndEncryption PreferredDomain ідентифікатор: «example.com».
Якщо у вас кілька доменів і не встановлено бажаний домен для пристрою, Webex вибирає один для вас.
Сертифікат пристрою, виданий зовні
Адміністратор може надати пристрою власний сертифікат, підписаний одним із загальнодоступних сертифікатів.
Сертифікат повинен базуватися на парі ключів ECDSA P-256, хоча він може бути підписаний ключем RSA.
Значення в сертифікаті знаходяться на розсуд організації. Загальне ім'я (CN) та Альтернативне ім'я теми (SAN) відображатимуться в інтерфейсі користувача зустрічі Webex, як описано в розділі Наскрізне шифрування з перевіркою особистості для Webex Meetings.
Ми рекомендуємо використовувати окремий сертифікат для кожного пристрою та мати унікальний CN для кожного пристрою. Наприклад, «конференц-room-1.example.com» для організації, якій належить домен «example.com».
Для того, щоб повністю захистити зовнішній сертифікат від підробки, використовується функція секрету клієнта для шифрування та підписання різних xкоманд.
При використанні секрету клієнта можна безпечно керувати зовнішнім сертифікатом ідентифікації Webex через xAPI. Наразі це обмежено онлайн-пристроями.
Наразі Webex надає команди API для управління цим.
Пристрої
Зареєстровані в хмарі пристрої Cisco Board, Desk та Room Series можуть приєднатися до зустрічей E2EE.
Наступні пристрої не можуть приєднатися до зустрічей E2EE:
-
Сторонні SIP-пристрої
Програмні клієнти
-
Додаток Webex для настільних і мобільних клієнтів може приєднатися до зустрічей E2EE.
-
Веб-клієнт Webex не може приєднатися до зустрічей E2EE.
-
Сторонні клієнти SIP не можуть приєднатися до зустрічей E2EE.
Ідентичність
-
За задумом ми не надаємо опцій Control Hub для керування зовнішнім підтвердженням ідентичності пристрою. Для справжнього наскрізного шифрування тільки ви повинні знати/отримувати доступ до секретів і ключів. Якщо ми запровадили хмарний сервіс для управління цими ключами, є ймовірність їх перехоплення.
-
Наразі ми пропонуємо вам «рецепт» для розробки власних інструментів, заснованих на стандартних галузевих методах шифрування, щоб допомогти запитувати або шифрувати сертифікати ідентифікації вашого пристрою та їх приватні ключі. Ми не хочемо мати реального чи сприйнятого доступу до ваших секретів чи ключів.
Зустрічі
-
Наразі зустрічі E2EE підтримують максимум 1000 учасників.
- Ви можете ділитися новими дошками під час зустрічей E2EE. Є деякі відмінності від дощок на регулярних зустрічах:
- Під час нарад E2EE користувачі не можуть отримати доступ до дощок, створених поза нарадою, включаючи приватні дошки, дошки, якими користуються інші особи, та дошки з просторів Webex.
- Дошки, створені під час зустрічей E2EE, доступні лише під час зустрічі. Вони не зберігаються і недоступні після закінчення зустрічі.
- Якщо хтось ділиться вмістом під час зустрічі E2EE, ви можете додати до нього анотації. Для отримання додаткової інформації про анотації див. Дод аток Webex | Позначення спільного вмісту анотаціями.
Інтерфейс управління
Настійно рекомендуємо використовувати Центр керування для керування сайтом зустрічей, оскільки організації Control Hub мають централізовану ідентифікацію для всієї організації.
Пов'язана інформація
-
Безпека нульової довіри для Webex (технічний документ про безпеку)
-
Веб-шифрування JSON (JWE) (проект стандарту IETF)
-
Webex Meetings41.7.
-
Зареєстровані в хмарі пристрої Cisco Board, Desk та Room серії, що працюють
10.6.1-RoomOS_August_2021 або новішої версії. -
Адміністративний доступ до сайту наради в Контрольному центрі.
-
Один або кілька перевірених доменів у вашій організації Центру керування (якщо ви використовуєте сертифікацію Webex для видачі сертифікатів пристроїв для підтвердженої особи).
-
Переговорні кімнати для співпраці повинні бути увімкнені, щоб користувачі могли приєднатися зі своєї відеосистеми. Докладніші відомості див. у статті Дозволити відеосистемам приєднуватися до нарад та подій на вашому сайті Webex.
Ви можете пропустити цей крок, якщо вам не потрібні зовнішньо підтверджені особи.
Для забезпечення найвищого рівня безпеки та перевірки особистості кожен пристрій повинен мати унікальний сертифікат, виданий довіреною громадсь Certificate Authority кістю (CA).
Для запиту, придбання та отримання цифрових сертифікатів та створення пов'язаних приватних ключів потрібно взаємодіяти з сертифікатором сертифіката. При запиті сертифіката використовуйте такі параметри:
-
Сертифікат повинен бути виданий і підписаний відомою громадською CA.
-
Унікальний: Ми настійно рекомендуємо використовувати унікальний сертифікат для кожного пристрою. Якщо ви використовуєте один сертифікат для всіх пристроїв, ви ставите під загрозу свою безпеку.
-
Загальна назва (CN) та Альтернативна назва предмета (SAN/s): вони не важливі для Webex, але мають бути значеннями, які люди можуть прочитати та пов'язувати з пристроєм. CN відображатиметься іншим учасникам наради як основну підтверджену особу пристрою, і якщо користувачі перевірять сертифікат через інтерфейс зустрічі, вони побачать SAN/s. Можливо, ви захочете використовувати такі імена, як
name.model@example.com. -
Формат файлу: сертифікати та ключі повинні бути у форматі
.pem. -
Призначення: Метою сертифіката має бути ідентичність Webex.
-
Генерування ключів: Сертифікати повинні базуватися на парах ключів ECDSA P-256 (алгоритм цифрового підпису еліптичної кривої з використанням кривої P-256).
Ця вимога не поширюється на підписуючий ключ. Сертифікат сертифіката може використовувати ключ RSA для підписання сертифіката.
Ви можете пропустити цей крок, якщо не хочете використовувати зовнішньо підтверджену особу на своїх пристроях.
Якщо ви використовуєте нові пристрої, ще не реєструйте їх у Webex. Щоб бути в безпеці, не підключайте їх до мережі в цей момент.
Якщо у вас є існуючі пристрої, які ви хочете оновити, щоб використовувати зовнішньо підтверджену особу, вам потрібно скинути налаштування пристроїв до заводських налаштувань.
-
Збережіть існуючу конфігурацію, якщо хочете зберегти її.
-
Заплануйте вікно, коли пристрої не використовуються, або використовуйте поетапний підхід. Повідомте користувачів про зміни, які вони можуть очікувати.
-
Забезпечити фізичний доступ до пристроїв. Якщо вам потрібно отримати доступ до пристроїв через мережу, пам'ятайте, що секрети поширюються у звичайному тексті, і ви ставите під загрозу свою безпеку.
Після виконання цих кроків дозвольте відеосистемам приєднуватися до зустрічей та подій на вашому сайті Webex.
Щоб гарантувати, що носій вашого пристрою не може бути зашифрований ніким, крім пристрою, ви повинні зашифрувати приватний ключ на пристрої. Ми розробили API для пристрою, щоб забезпечити управління зашифрованим ключем та сертифікатом, використовуючи веб-шифрування JSON (JWE).
Щоб забезпечити справжнє наскрізне шифрування через нашу хмару, ми не можемо брати участь у шифруванні та завантаженні сертифіката та ключа. Якщо вам потрібен такий рівень безпеки, ви повинні:
-
Запитуйте свої сертифікати.
-
Створіть пари ключів сертифікатів.
-
Створіть (і захистіть) початковий секрет для кожного пристрою, щоб закріпити можливість шифрування пристрою.
-
Розробляйте та підтримуйте власний інструмент для шифрування файлів за допомогою стандарту JWE.
Процес і (несекретні) параметри, які вам знадобляться, пояснюються нижче, а також рецепт, який слід дотримуватися у вибраних інструментах розробки. Ми також надаємо деякі тестові дані та отримані JWE краплі, як ми їх очікуємо, щоб допомогти вам перевірити ваш процес.
Реалізація посилань, що не підтримується за допомогою Python3 та бібліотеки JWCrypto, доступна від Cisco за запитом.
-
Об'єднайте та шифруйте сертифікат та ключ за допомогою вашого інструменту та початкового секрету пристрою.
-
Завантажте отриманий JWE blob на пристрій.
-
Встановіть мету зашифрованого сертифіката, який буде використовуватися для ідентифікації Webex, і активуйте сертифікат.
-
(Рекомендовано) Забезпечте інтерфейс для вашого інструменту (або розповсюдження), щоб користувачі пристроїв могли змінювати початковий секрет та захистити свої носії від вас.
Як ми використовуємо формат JWE
У цьому розділі описано, як ми очікуємо, що JWE буде створено як вхід на пристрої, щоб ви могли створити власний інструмент для створення блоб із ваших сертифікатів та ключів.
Зверніться до веб-шифрування JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 та веб-підпис JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.
Ми використовуємо компактну серіалізацію документа JSON для створення блобів JWE. Параметри, які потрібно включити при створенні блобів JWE, є:
-
JOSE Заголовок (захищений). У заголовку JSON Object Signing and Encryption потрібно включити наступні пари ключ-значення:
-
«alg» :"каталог»Прямий алгоритм є єдиним, який ми підтримуємо для шифрування корисного навантаження, і ви повинні використовувати початковий секрет клієнта пристрою.
-
«енц»: «А128ГСМ» або «енц»: «А256ГСМ»Ми підтримуємо ці два алгоритми шифрування.
-
«cisco-action»: «додати» або «циско-дія»: «заповнити» або «циско-дію»: «активувати»або«циско-дію»: «деактивувати»Це фірмовий ключ і чотири значення він може приймати. Ми ввели цей ключ, щоб сигналізувати про призначення зашифрованих даних на цільовий пристрій. Значення названі на честь команд xAPI на пристрої, на якому ви використовуєте зашифровані дані.
Ми назвали це
cisco-action, щоб пом'якшити потенційні зіткнення з майбутніми розширеннями JWE. -
«cisco-kdf»: {«версія»: «1", «сіль»: «базова64URLEnCodeDrandom4+байт»}Ще один фірмовий ключ. Ми використовуємо значення, які ви надаєте, як вхідні дані для виведення ключів на пристрої. Вер
сіяповинна бути1(версія нашої функції виведення ключа). Значеннямsaltповинна бути послідовність, кодована URL-адресою base64 щонайменше 4 байт, яку ви повинні вибрати випадковим чином.
-
-
За@@ шифрований ключ JWE. Це поле порожнє. Пристрій отримує його від початкового
клієнтуSecret. -
Вектор ініціалізації JWE. Для розшифровки корисного навантаження потрібно ввести вектор ініціалізації, кодований base64url. IV МАЄ бути випадковим значенням 12 байтів (ми використовуємо сімейство шифрів AES-GCM, яке вимагає, щоб IV мав довжину 12 байтів).
-
JWE AAD (додаткові ав тентифіковані дані). Ви повинні пропустити це поле, оскільки воно не підтримується в компактній серіалізації.
-
JWE Ciphertext: Це зашифроване корисне навантаження, яке ви хочете зберегти в таємниці.
Корисне навантаження може бути порожнім. Наприклад, щоб скинути секрет клієнта, потрібно перезаписати його порожнім значенням.
Існують різні типи корисних навантажень, залежно від того, що ви намагаєтеся зробити на пристрої. Різні команди xAPI очікують різного корисного навантаження, і ви повинні вказати призначення корисного навантаження за допомогою ключа
cisco-actionнаступним чином:-
За допомогою«cisco-action» :"заповнити» шифртекст є новим ClientSecret. -
За допомогою "
«cisco-action» :"add» зашифрованийтекст є блобом PEM, що містить сертифікат та його приватний ключ (об'єднаний). -
За допомогою "
«cisco-action» :"activate» шифртекст є відбитком пальця (шістнадцяткове представлення sha-1) сертифіката, який ми активуємо для перевірки ідентичності пристрою. -
За допомогою "
«cisco-action» :"деактивувати»шифртекст є відбитком пальця (шістнадцяткове представлення sha-1) сертифіката, який ми деактивуємо від використання для перевірки ідентичності пристрою.
-
-
Тег ав@@ тентифікації JWE: Це поле містить тег автентифікації для встановлення цілісності всього JWE компактно серіалізованого блобу
Як ми отримуємо ключ шифрування з ClientSecret
Після першого поповнення секрету ми не приймаємо і не виводимо секрет як простий текст. Це для запобігання потенційним словниковим атакам з боку когось, хто міг отримати доступ до пристрою.
Програмне забезпечення пристрою використовує секрет клієнта як вхід до функції виведення ключа (kdf), а потім використовує похідний ключ для розшифровання/шифрування вмісту на пристрої.
Для вас це означає, що ваш інструмент для створення блобів JWE повинен дотримуватися тієї ж процедури, щоб отримати той самий ключ шифрування/розшифровки з секрету клієнта.
Пристрої використовують scrypt для виведення ключів (див. https://en.wikipedia.org/wiki/Scrypt) з наступними параметрами:
-
Коефіцієнт витрат (N) дорівнює 32768
-
Розмір блокуАктор (r) дорівнює 8
-
Коефіцієнт паралелізації (p) дорівнює 1
-
Salt є випадковою послідовністю не менше 4 байтів; ви повинні ввести цю саму
сільпри вказівці параметраcisco-kdf. -
Довжина ключів становить або 16 байт (якщо вибрати алгоритм AES-GCM 128), або 32 байт (якщо вибрати алгоритм AES-GCM 256)
-
Максимальний розмір пам'яті - 64 МБ
Цей набір параметрів є єдиною конфігурацією scrypt, сумісною з функцією виведення ключів на пристроях. Цей kdf на пристроях називається «version» :"1", що є єдиною вер сією, яка наразі використовується параметром cisco-kdf.
Робочий приклад
Ось приклад, за яким ви можете слідувати, щоб переконатися, що ваш процес шифрування JWE працює так само, як процес, який ми створили на пристроях.
Прикладом сценарію є додавання блобу PEM до пристрою (імітує додавання сертифіката з дуже коротким рядком замість повного ключа cert +). Клієнтський секрет у прикладі - осиф раж.
-
Виберіть шифр шифрування. У цьому прикладі використовується
A128GCM(AES з 128-бітними клавішами в режимі лічильника Галуа). Ваш інструмент може використовуватиA256GCM, якщо ви віддаєте перевагу. -
Виберіть сіль (повинна бути випадкова послідовність не менше 4 байтів). У цьому прикладі використовується (шестигранні байти)
E5 E6 53 08 03 F8 33 F6. Base64URL кодує послідовність, щоб отримати5eztcap4m_y (видалити підкладку base64). -
Ось приклад виклику
scrypt длястворення ключа шифрування вмісту (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)Похідний ключ повинен бути 16 байт (шестигранник) наступним чином:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac, який base64url кодує до LZ66bdeiaqv4_mqdinj_ra. -
Виберіть випадкову послідовність 12 байтів для використання в якості вектора ініціалізації.
У цьому прикладі використовується (hex)34 b3 5d dd 5f 53 7b af 2d 92 95 83, який base64url кодує до nLnd3v9te68tkpwd. -
Створіть заголовок JOSE з компактною серіалізацією (дотримуйтесь того ж порядку параметрів, які ми використовуємо тут), а потім base64url кодуйте його:
{"alg» :"dir», "циско-дія» :"додати», "cisco-kdf»: {"salt» :"5eztcap4M_y», "версія» :"1"}, "enc» :"A128GCM "}Заголовок JOSE, кодований base64url, є EyJhbGcioIJkAxiiLcJjaXnJbY1hy3rpb24ioiJhzgqILcJjaXnJbY1rzGyionSiC2fsdCi6iJvLwLrdqVA0tV9ziiWIDmVyc2LvBii6iJeiFsWiZw5jiJoiqtEyoeDtSJ9Це буде перший елемент JWE blob.
-
Другий елемент блобу JWE порожній, оскільки ми не надаємо ключ шифрування JWE.
-
Третім елементом блобу JWE є вектор ініціалізації nLnd3v9TE68tkpwd. - Використовуйте інструмент шифрування JWE для створення зашифрованого корисного навантаження та тегу. Для цього прикладу незашифрованим корисним навантаженням буде фальшивим блобом PEM, це
файлPEMПараметри шифрування, які ви повинні використовувати:
Корисне навантаження
це файл PEMШифр шифрування AES 128 GCM
Заголовок JOSE, закодований base64url як додаткові автентифіковані дані (AAD)
Base64URL кодує зашифроване корисне навантаження, що повинно призвести до f5llVUWNfkfmzyco1yjfodhqЦе четвертий елемент (JWE Шифровий текст) у блобі JWE.
-
Base64URL кодує тег, який ви створили на кроці 8, що повинно призвести до PE-wdfwgxffbeo928cfz1qЦе п'ятий елемент у блобі JWE.
-
Об'єднайте п'ять елементів JWE крапками (JoseHeader.. iv.CipherText.tag), щоб отримати:
EyjHBgCIoIJkaxiiLcJaxNjbY1HY3rpb24ioiJhZgQiLcJaxNjbY1rZgYionSiC2FsdCi6iVwLrdQva0tv9ZiiWIDmVyC2LvBiI6iJiJifswizw5jijoIQtEyoeDdTsJ.. 9nLnd3v9TE68pWIDmVyc2LvBiI6iJiJsWiZw5JioIQtEYoeDdTsJ.. 9nLnd3V9TE68pWd.pW5tKf5tqlld.pW5tKf5TkLd.tKf5tKf5tLlLVUWNFKFMZYCO1YJFODHQ.ПЕ-WDFWGXFFBEO928CFZ1Q -
Якщо ви отримали ті самі кодовані значення base64url, як ми показуємо тут, використовуючи власні інструменти, ви готові використовувати їх для захисту шифрування E2E та підтвердженої ідентичності ваших пристроїв.
-
Цей приклад насправді не спрацює, але в принципі наступним кроком буде використання JWE blob, створеного вище, як введення до xcommand на пристрої, який додає сертифікат:
Серти@@
фікати безпеки XCommand Додати EYJhbgCIoIJkAXiiLcJjaXnJBY1HY3rpb24ioiJHZgQiLCJjaXnJbY1rZgYionSiC2fsdci6iVvlWLrdQva0tv9ziiWIDmVyc2LvBii6iJiIFswizw5jiJoiqT eyoeDdTsJ.. 9nLnND3v9t9tTE68tTEtSj.. ПВД.Ф5LLVUWNFKFMzyCo1YJFODHQ.ПЕ-WDFWGXFFBEO928CFZ1Q
Типи сеансів для зустрічей з нульовою довірою доступні для всіх сайтів нарад без додаткових витрат. Один з таких типів сеансів називається Pro-End to End Encryption_ VoipOnly. Це назва державної служби, яку ми можемо змінити в майбутньому. Поточні назви типів сеансів див. Іденти фікатори типів сеан сів у розділі Дов ідка цієї статті.
Вам нічого не потрібно робити, щоб отримати цю можливість для вашого сайту; вам потрібно надати користувачам новий тип сеансу (також званий привілеєм зустрічі). Ви можете зробити це окремо через сторінку конфігурації користувача або масово за допомогою експорту/імпорту CSV.
| 1 |
Увійдіть у Центр керування та перейдіть до . |
| 2 |
Натисніть Сай ти, виберіть сайт Webex, для якого потрібно змінити налаштування, а потім натисніть Налаштування. |
| 3 |
У розділі Загальні параметри виберіть Ти пи сеансів. Ви повинні побачити один або кілька типів сеансів наскрізного шифрування. Зверніться до списку ідентифікаторів типу сеан су в розділі Дов ідка цієї статті. Наприклад, ви можете побачити End-to- End Encryption_ VoipOnly.
Існує більш старий тип сеансу з дуже схожою назвою: шифрування Pro-End to End. Цей тип сеансу включає незашифрований доступ PSTN до нарад. Переконайтеся, що у вас є версія _VoIPOnly, щоб забезпечити наскрізне шифрування. Ви можете перевірити, наводячи курсор на посилання PRO у стовпці коду сеансу; для цього прикладу ціллю посилання має бути Ми можемо змінити імена публічних служб для цих типів сеансів у майбутньому. |
| 4 |
Якщо у вас ще немає нового типу сеансу, зв'яжіться зі своїм представником Webex. |
Що робити далі
Увімкніть цей тип сеансії/привілей зустрічі деяким або всім вашим користувачам.
| 1 |
Увійдіть у Центр керування та перейдіть до меню . |
| 2 |
Виберіть обліковий запис користувача, який потрібно оновити, а потім виберіть «Зустрічі». |
| 3 |
У спадному списку Параме три застосувати до виберіть сайт зустрічі, який потрібно оновити. |
| 4 |
Поставте прапорець біля пункту Pro-End, щоб закінчити шифрування_Vo ipOnly. |
| 5 |
Закрийте панель конфігурації користувача. |
| 6 |
Повторіть для інших користувачів, якщо це необхідно. Щоб призначити це багатьом користувачам, скористайтеся наступним параметром, У вімкнути зустрічі E2EE для кількох користувачів. |
| 1 |
Увійдіть у Центр керування та перейдіть до . |
| 2 |
Натисніть Сай ти, виберіть сайт Webex, для якого потрібно змінити налаштування. |
| 3 |
У розділі Ліцензії та користувачі натисніть Масов е керування. |
| 4 |
Натисніть Створити зві т, і зачекайте, поки ми підготуємо файл. |
| 5 |
Коли файл буде готовий, натисніть Експортувати результати, а потім Завантажити. (Після натискання кнопки Завантажити потрібно закрити спливаюче вікно вручну.) |
| 6 |
Відкрийте завантажений файл CSV для редагування. Для кожного користувача є рядок, а стовпець |
| 7 |
Дов ідка про формат файлів CSV Webex містить детальну інформацію про призначення та вміст файлу CSV. |
| 8 |
Відкрийте панель конфігурації сайту зустрічі в Центрі керування. Якщо ви вже перебували на сторінці списку сайтів нарад, можливо, вам доведеться оновити його. |
| 9 |
У розділі Ліцензії та користувачі натисніть Масов е керування. |
| 10 |
Натисніть Імпор тувати, виберіть відредагований CSV, а потім натисніть Імпортувати. Зачекайте, поки файл буде завантажений. |
| 11 |
Після завершення імпорту можна натиснути кнопку Імпортувати результати, щоб перевірити, чи не були помилки. |
| 12 |
Перейдіть на сторінку Користува чі та відкрийте одного з користувачів, щоб переконатися, що у них новий тип сеансу. |
Ви можете додати водяний знак до записів нарад за допомогою типу сеан Webex Meetingsсу Pro-End to End Encryption_VoipOnly, який дозволяє ідентифікувати вихідний клієнт або пристрій несанкціонованих записів конфіденційних зустрічей.
Якщо ця функція увімкнена, аудіо наради містить унікальний ідентифікатор для кожного клієнта або пристрою, що бере участь. Ви можете завантажувати аудіозаписи в Control Hub, який потім аналізує запис і шукає унікальні ідентифікатори. Ви можете переглянути результати, щоб побачити, який клієнт-джерело або пристрій записали зустріч.
- Для аналізу запис повинен бути файлом AAC, MP3, M4A, WAV, MP4, AVI або MOV розміром не більше 500 Мб.
- Запис повинен бути довше 100 секунд.
- Ви можете аналізувати лише записи для нарад, які проводяться людьми у вашій організації.
- Інформація про водяний знак зберігається протягом тієї ж тривалості, що й інформація про нараду організації.
Додавання звукових водяних знаків до зустрічей E2EE
- Увійдіть до центру керування, а потім у розділі Кер ування виберіть Параметри організації.
- У розділі Водя ні знаки зустрічі увімкніть Додати звуковий водяний знак.
Через деякий час після цього ввімкнення користувачі, які планують зустрічі з типом сеансу
Webex MeetingsPro-End to End Encryption_VoipOnly, бачать параметр Цифровий водяний знак у розділі Безпека.
Завантаження та аналіз наради з водяними знаками
- У Центрі керування у розділі Моні торинг виберіть Усунення не справностей.
- Натисніть Ан аліз водяних зна ків.
- Знайдіть або виберіть зустріч у списку, а потім натисніть «Аналіз».
- У вікні «Аналіз зву кового водяного знака» введіть назву для аналізу.
- (Необов'язково) Введіть примітку для аналізу.
- Перетягніть аудіофайл, який потрібно аналізувати, або клацніть Вибрати файл, щоб переглянути аудіофайл.
- Натисніть кнопку Зак рити.
Після завершення аналізу він відобразиться у списку результатів на сторінці Аналіз водяного зна ка.
- Виберіть зустріч у списку, щоб побачити результати аналізу. Клацніть
щоб завантажити результати.
Особливості та обмеження
Фактори, що беруть участь у успішному декодуванні записаного водяного знака, включають відстань між пристроєм запису та динаміком, що виводить аудіо, гучність цього звуку, шум навколишнього середовища тощо. Наша технологія водяних знаків має додаткову стійкість до багаторазового кодування, як це може статися під час спільного використання носія.
Ця функція призначена для успішного декодування ідентифікатора водяного знака в широкому, але розумному наборі обставин. Наша мета полягає в тому, щоб пристрій запису, такий як мобільний телефон, який лежить на столі біля особистої кінцевої точки або ноутбукового клієнта, завжди повинен створювати запис, який призводить до успішного аналізу. Оскільки записуючий пристрій віддаляється від джерела або затьмарюється від чуття повного звукового спектру, шанси на успішний аналіз зменшуються.
Для успішного аналізу запису необхідний розумний запис аудіо зустрічі. Якщо аудіо зустрічі записано на тому ж комп'ютері, на якому розміщується клієнт, обмеження не повинні застосовуватися.
Якщо ваші пристрої вже підключені до організації Центру керування, і ви хочете використовувати сертифікацію Webex для автоматичного створення ідентифікаційних сертифікатів, вам не потрібно скидати пристрої до заводських налаштувань.
Ця процедура визначає домен, який пристрій використовує для ідентифікації себе, і потрібна лише в тому випадку, якщо у вашій організації Control Hub є кілька доменів. Якщо у вас більше одного домену, радимо зробити це для всіх ваших пристроїв, які матимуть ідентичність «підтверджена Cisco». Якщо ви не повідомите Webex, який домен ідентифікує пристрій, один із них буде автоматично вибрано, і для інших учасників наради він може виглядати неправильним.
Перш ніж почати
Якщо ваші пристрої ще не включені, дотримуйтесь інструкцій За реєструвати пристрій для Cisco Webex використання API або локального веб-інтерфейсу або хмарного інтеграції для серії Board, Desk та Room. Ви також повинні підтвердити домен/або домени, які ви хочете використовувати для ідентифікації пристроїв у розділі Керування до менами.
| 1 |
Увійдіть до центру керування та в розділі Керування виберіть П ристрої. |
| 2 |
Виберіть пристрій, щоб відкрити його панель конфігурації. |
| 3 |
Виберіть домен, який потрібно використовувати для ідентифікації цього пристрою. |
| 4 |
Повторіть для інших пристроїв. |
Перш ніж почати
-
Отримайте сертифікат з підписом CA та приватний ключ у формат
і.pemдля кожного пристрою. -
На вкладці «Під готов ка» прочитайте тему Розуміння процесу зовнішньої ідентифікації пристроїв,
-
Підготуйте інструмент шифрування JWE щодо інформації там.
-
Переконайтеся, що у вас є інструмент для створення випадкових послідовностей байтів заданої довжини.
-
Переконайтеся, що у вас є інструмент для кодування base64url байтів або тексту.
-
Переконайтеся, що у вас є реалі
зація scrypt. -
Переконайтеся, що у вас є секретне слово або фраза для кожного пристрою.
| 1 |
Заповніть Перший раз, коли ви заповнюєте Пристрій має свій початковий секрет. Не забувайте про це; ви не можете відновити його, і ви повинні скинути пристрій на заводі, щоб запустити знову.
|
| 2 |
Об'єднайте свій сертифікат і приватний ключ: |
| 3 |
Створіть JWE blob для використання в якості введення до команди додавання сертифіката: |
| 4 |
Відкрийте TShell на пристрої і запустіть команду (multiline) add: |
| 5 |
Перевірте, чи додано сертифікат, запустивши службу Скопіюйте відбиток нового сертифіката. |
| 6 |
Активуйте сертифікат з метою Пристрій має зашифрований активний сертифікат, виданий CA, готовий до використання для його ідентифікації на наскрізно зашифрованих нарадах Webex.
|
| 7 |
Введіть пристрій до організації Control Hub. |
| 1 |
Заплануйте зустріч правильного типу (Webex MeetingsPro-End to End Encryption_ VoipOnly). |
| 2 |
Приєднуйтесь до зустрічі як ведучий, від Webex Meetings клієнта. |
| 3 |
Приєднуйтесь до зустрічі з пристрою, ідентичність якого підтверджена сертифікатором Webex CA. |
| 4 |
Як господар, перевірте, що цей пристрій з'являється у лобі з правильною піктограмою ідентифікації. |
| 5 |
Приєднуйтесь до наради з пристрою, ідентичність якого підтверджена зовнішньою сертифікатором. |
| 6 |
Як господар, перевірте, що цей пристрій з'являється у лобі з правильною піктограмою ідентифікації. Дізнайтеся більше про піктограми ідентифікації. |
| 7 |
Приєднуйтесь до зустрічі як неавтентифікований учасник нарад. |
| 8 |
Як господар, перевірте, що цей учасник з'являється у лобі з правильною піктограмою особи. |
| 9 |
Як господар, визнайте або відхиляйте людей/пристрої. |
| 10 |
Перевірте ідентифікацію учасника/пристрою, де це можливо, шляхом перевірки сертифікатів. |
| 11 |
Переконайтеся, що всі учасники зустрічі бачать один і той же код безпеки наради. |
| 12 |
Приєднуйтесь до зустрічі з новим учасником. |
| 13 |
Переконайтеся, що всі бачать один і той же новий код безпеки наради. |
-
Чи збираєтеся ви зробити наскрізні зашифровані зустрічі параметром наради за замовчуванням, або увімкнути його лише для деяких користувачів, або дозволити всім хостам вирішувати? Коли ви вирішили, як ви збираєтеся використовувати цю функцію, підготуйте тих користувачів, які будуть нею користуватися, особливо щодо обмежень та чого очікувати на зустрічі.
-
Чи потрібно переконатися, що ні Cisco, ні хтось інший не можуть розшифрувати ваш вміст або видавати себе за ваші пристрої? Якщо так, вам потрібні сертифікати від загальнодоступної CA.
-
Якщо у вас є різні рівні перевірки особистості, надайте користувачам можливість підтверджувати один одного за допомогою сертифікатів особи. Незважаючи на те, що є обставини, коли учасники можуть з'являтися як Неперевірені, і учасники повинні знати, як перевірити, неперевірені люди можуть не бути самозванцями.
Якщо ви використовуєте зовнішню сертифікацію сертифіката для видачі сертифікатів пристрою, ви повинні контролювати, оновлювати та повторно застосовувати сертифікати.
Якщо ви створили початковий секрет, зрозумійте, що ваші користувачі можуть захотіти змінити секрет свого пристрою. Можливо, вам доведеться створити інтерфейс/розподілити інструмент, щоб дозволити їм це зробити.
|
Ідентифікатор типу сеансу |
Назва державної служби |
|---|---|
|
638 |
Шифрування E2E+тільки VoIP |
|
652 |
Професійне шифрування від кінця до кінця шифрування_VoipOnly |
|
660 |
Шифрування Pro 3 від кінця до кінця шифрування_VoipOnly Шифрування E2E+ідентичність |
|
672 |
Pro 3 Free50-від кінця до кінця шифрування_VoipOnly |
|
673 |
Інструктор з освіти E2E Шифрування_VoipOnly |
|
676 |
Стандарт Broadworks плюс шифрування від кінця до кінця |
|
677 |
Broadworks Premium плюс шифрування від кінця до кінця |
|
681 |
Schoology Free плюс шифрування від кінця до кінця |
Ці таблиці описують команди API пристроїв Webex, які ми додали для наскрізного зашифрованого наради та підтвердженої ідентичності. Для отримання додаткової інформації про використання API див. До ступ до API для пристроїв серії Board, Desk та Room.
Ці команди xAPI доступні лише на пристроях, які:
-
Зареєстровано в Webex
-
Зареєстрований локально та пов'язаний з Webex за допомогою для пристроїв Webex Edge
|
Виклик API |
Опис |
|---|---|
|
|
Ця конфігурація здійснюється, коли адміністратор встановлює бажаний домен пристрою з Control Hub. Необхідний тільки в тому випадку, якщо організація має більше одного домену. Пристрій використовує цей домен, коли запитує сертифікат від CA Webex. Потім домен ідентифікує пристрій. Ця конфігурація не застосовується, якщо пристрій має активний сертифікат, виданий зовнішньо, для ідентифікації себе. |
|
|
Вказує, чи може пристрій приєднатися до наскрізної зашифрованої наради. Хмарний API викликає його, щоб парна програма знала, чи може вона використовувати пристрій для приєднання. |
|
|
Вказує, чи використовується пристрій |
|
|
Ідентичність пристрою, прочитана із загальної назви зовнішнього сертифіката. |
|
|
Зчитує конкретну інформацію із зовнішньо виданого сертифіката. У наведеній команді замінити
|
|
|
Статус зовнішнього ідентифікатора пристрою (наприклад, |
|
|
Вказує, чи має пристрій дійсний сертифікат, виданий сертифікатором Webex. |
|
|
Ідентичність пристрою, прочитана із загальної назви сертифіката, виданого Webex. Містить доменне ім'я, якщо організація має домен. Порожній, якщо організація не має домену. Якщо пристрій знаходиться в організації, яка має кілька доменів, це значення з |
|
|
Читає конкретну інформацію з сертифіката, виданого Webex. У наведеній команді замінити
|
|
Виклик API |
Опис |
|---|---|
|
|
|
Виклик API |
Опис |
|---|---|
або
| Приймає кодоване значення звичайного тексту base64url для першого позначення секрету клієнта на пристрої. Щоб оновити секрет після цього першого разу, ви повинні надати блоб JWE, що містить новий секрет, зашифрований старим секретом. |
| Додає сертифікат (з закритим ключем). Ми розширили цю команду, щоб прийняти блоб JWE, що містить зашифровані дані PEM. |
| Активує певний сертифікат для WebExIdentity. Для |
| Деактивує певний сертифікат для WebExIdentity. Для |
