В модели безопасности Zero Trust от Webex обеспечивается сквозное шифрование и строгая проверка удостоверений во время запланированных совещаний и совещаний в персональной комнате.
Пользователи выбирают тип совещания при запланировать совещание. При допуске участников из холла, а также во время совещания организатор может видеть статус проверки личности каждого участника. Кроме того, существует код совещания, который является общим для всех текущих участников совещания. Они могут использовать его для проверки друг друга.
Поделитесь информацией по следующим темам с организаторами совещаний.
Присоединиться к совещанию Webex со сквозным шифрованием
Подтвердить личность
Сквозное шифрование с проверкой личности обеспечивает дополнительную безопасность для совещаний с сквозным шифрованием.
Когда участники или устройства присоединяются к совместно используемой группе MLS (обмен сообщениями Layer Security), они представляют свои сертификаты другим членам группы, которые затем проверяют сертификаты в выдающих центрах сертификации (CA). Подтверждая, что сертификаты действительны, ЦС проверяет личность участников, и совещание показывает участников / устройства как проверенные.
Пользователи приложения Webex аутентифицируются в хранилище удостоверений Webex , которое выдает им маркер доступа при успешной аутентификации. Если им нужен сертификат для подтверждения своей личности на совещании с непрерывным шифрованием, Webex CA выдает им сертификат на основе их маркера доступа. В настоящее время мы не предоставляем пользователям Webex Meetings возможность получить сертификат, выданный сторонним центром сертификации.
Устройства могут самостоятельно проходить аутентификацию с помощью сертификата, выданного внутренним ЦС (ЦС Webex), или сертификата, выданного внешним ЦС.
Внутренний ЦС. Webex выдает внутренний сертификат на основе маркера доступа учетной записи устройства. Сертификат подписывается ЦС Webex. У устройств нет идентификаторов пользователей, как у пользователей, поэтому Webex использует (один из) доменов вашей организации при записи идентификатора сертификата устройства (Common Name (CN)).
Внешний ЦС - запрашивайте и приобретайте сертификаты устройств непосредственно у выбранного эмитента. Для шифрования, непосредственной загрузки и авторизации сертификатов необходимо использовать секретный код, известный только вам.
Cisco не участвует, что позволяет гарантировать истинное сквозное шифрование и подтвержденную личность, а также предотвратить теоретическую возможность того, что Cisco может подслушать ваше совещание / расшифровать ваши мультимедийные данные.
Сертификат устройства, выпущенный внутренним ЦС
Webex выдает сертификат на устройство при его регистрации после запуска и при необходимости обновляет его. Сертификат для устройств включает в себя идентификатор учетной записи и домен.
Если у вашей организации нет домена, Webex CA выдает сертификат без домена.
Если у вашей организации несколько доменов, можно использовать Control Hub, чтобы сообщить Webex, какой домен устройство будет использовать для идентификации. Кроме того, можно использовать API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"
.
Если у вас несколько доменов и предпочтительный домен для устройства не установлен, Webex выберет этот домен за вас.
Сертификат устройства, выпущенный внешним ЦС
Администратор может снабдить устройство собственным сертификатом, подписанным одним из общедоступных ЦС.
Сертификат должен быть основан на паре ключей ECDSA P-256, хотя он может быть подписан ключом RSA.
Значения сертификата задаются по усмотрению организации. Общее имя (CN) и альтернативное имя субъекта (SAN) будут отображаться в интерфейс пользователя совещание Webex , как описано в Сквозное шифрование с проверкой личности для Webex Meetings .
Мы рекомендуем использовать отдельный сертификат для каждого устройства и иметь уникальный CN для каждого устройства. Например, «meeting-room-1.example.com» для организации, которой принадлежит домен «example.com».
Для полной защиты внешнего сертификата от несанкционированного вмешательства используется функция шифрования и подписи различных xcommand секретом клиента.
При использовании секрета клиента можно безопасно управлять внешним удостоверением личности Webex через xAPI. В настоящее время эта функция доступна только для сетевых устройств.
В настоящее время Webex предоставляет команды API для управления этим.
Устройства
Следующие устройства серии Webex Room и Webex Desk, зарегистрированные в облаке, могут присоединяться к совещаниям с непрерывным шифрованием:
Webex Board
Webex Desk Pro
Webex Desk
Webex Room Kit
Webex Room Kit Mini
Следующие устройства не могут присоединиться к совещаниям со сквозным шифрованием:
Серия Webex C
Серия Webex DX
Серия Webex EX
Серия Webex MX
Устройства SIP сторонних поставщиков
Программные клиенты
Начиная с версии 41.6, клиент Webex Meetings для настольных ПК может присоединяться к совещаниям со сквозным шифрованием.
Если ваша организация позволяет приложение Webex присоединяться к совещаниям, запустив настольное приложение Meetings, вы можете использовать этот параметр для присоединения к совещаниям с непрерывным шифрованием.
Веб-клиент Webex не может присоединяться к совещаниям со сквозным шифрованием.
Клиенты SIP сторонних поставщиков не могут присоединяться к совещаниям со сквозным шифрованием.
Идентификационный код
По умолчанию мы не предоставляем возможности Control Hub для управления удостоверениями устройств, подтвержденными извне. Для истинного сквозного шифрования только вы должны знать секреты и ключи и иметь к ним доступ. Если бы мы ввели облачную службу для управления этими ключами, они могли бы быть перехвачены.
В настоящее время мы предоставляем вам «рецепт» для разработки собственных инструментов на основе стандартных методов шифрования, которые помогут запросить или зашифровать сертификаты личности вашего устройства и их закрытые ключи. Мы не хотим иметь какой-либо реальный или предполагаемый доступ к вашим секретам или ключам.
Совещания
В совещаниях со сквозным шифрованием в настоящий момент может участвовать не более 200 пользователей.
Из этих 200 участников могут присоединиться не более 25 устройств, прошедших внешнюю проверку. должен быть первым, кто присоединится к совещанию .
Когда к совещанию присоединяется большее количество устройств, наши внутренние службы мультимедиа пытаются перекодировать потоки мультимедиа. Если нам не удается расшифровать, перекодировать и повторно зашифровать мультимедиа (поскольку мы не имеем и не должны иметь ключей шифрования устройств), перекодирование не выполняется.
Для уменьшения последствий этого ограничения рекомендуется использовать совещания меньшего масштаба для устройств или отрегулировать рассылку приглашений между устройствами и клиентами Meetings соответствующим образом.
Интерфейс управления
Мы настоятельно рекомендуем использовать Control Hub для управления сайтом совещаний, поскольку организации Control Hub имеют централизованную идентификацию для всей организации, а в системе администрирование веб-сайта идентификация контролируется на уровне каждого сайта.
Пользователи, управляемые с помощью администрирование веб-сайта , не могут иметь параметр удостоверения, подтвержденный Cisco. Этим пользователям выдается анонимный сертификат для присоединения к совещанию с непрерывным шифрованием, и они могут быть исключены из совещаний, на которых организатор хочет обеспечить проверку личности.
Связанная информация
Zero-Trust Security для Webex (техническая документация по безопасности). https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Презентация Cisco Live 2021 (требуется регистрация на Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Веб-шифрование JSON (JWE) (проект стандарта IETF). https://datatracker.ietf.org/doc/html/rfc7516
Документация, предназначенная для пользователя: https://help.webex.com/5h5d8ab
Webex Meetings 41.7.
Устройства Webex Room и Webex Desk, зарегистрированные в облаке, запущены
10.6.1-RoomOS_August_2021
.Административный доступ к веб-сайту совещания в Control Hub для подключения нового типа сеанса для пользователей.
Один или несколько проверенных доменов в организации Control Hub (если вы используете центр сертификации Webex для выдачи сертификатов устройств для проверки идентификации).
Чтобы участники могли присоединиться с помощью видеосистемы, необходимо включить функцию совместных комнат совещаний. Дополнительную информацию см. в статье Разрешение для видеосистем на присоединение к совещаниям и event-совещаниям на веб-сайте Webex.
Вы можете пропустить этот шаг, если вам не нужны удостоверения, подтвержденные извне.
Для обеспечения наивысшего уровня безопасности и проверки личности каждое устройство должно иметь уникальный сертификат, выданный доверенным общедоступным центр сертификации (ЦС).
Для запроса, приобретения и получения цифровых сертификатов и создания связанных с ними закрытых ключей необходимо взаимодействовать с ЦС. При запросе сертификата используйте следующие параметры:
Сертификат должен быть выдан и подписан широко известным общедоступным ЦС.
Уникальный: Настоятельно рекомендуется использовать уникальный сертификат для каждого устройства. Если для всех устройств используется один сертификат, вы ставите под угрозу безопасность.
Общее имя (CN) и альтернативное имя (имена) субъекта (SAN): Они не играют никакой роли для Webex, но должны быть значениями, которые люди могут прочитать и связать с устройством. CN будет показываться другим участникам совещания в качестве основной проверенной идентификации устройства. Если пользователи проверяют сертификат с помощью интерфейса пользователя совещания, они будут видеть одно или несколько SAN. Можно использовать такие имена, как
name.model@example.com
.Формат файла. Сертификаты и ключи должны быть в
.pem
формат.Назначение Назначением сертификата должна быть идентификация Webex.
Создание ключей Сертификаты должны быть основаны на парах ключей ECDSA P-256 (алгоритм цифровых подписей на основе эллиптических кривых с помощью кривой P-256).
Это требование не распространяется на ключ подписи. Для подписания сертификата ЦС может использовать ключ RSA.
Вы можете пропустить этот шаг, если не хотите использовать на своих устройствах удостоверение личности, подтвержденное извне.
Если вы используете новые устройства, пока не регистрируйте их в Webex. На всякий случай не подключайте их к сети на этом этапе.
Если у вас есть устройства, которые вы хотите обновить для использования удостоверений, подтвержденных извне, необходимо выполнить сброс устройств до заводских.
Сохраните существующую конфигурацию, если хотите ее сохранить.
Запланируйте окно, когда устройства не используются, или используйте поэтапный подход. Сообщите пользователям об ожидаемых изменениях.
Обеспечьте физический доступ к устройствам. Если вам необходимо иметь доступ к устройствам по сети, следует помнить о том, что секреты пересылаются открытым текстом и что это ставит под угрозу безопасность.
Выполнив эти шаги, разрешить видеосистемам присоединяться к совещаниям и мероприятиям на веб- веб-сайт Webex .
Чтобы обеспечить возможность шифрования мультимедиа устройства только самим устройством, необходимо зашифровать закрытый ключ на устройстве. Мы разработали API-интерфейсы для устройства, позволяющие управлять зашифрованным ключом и сертификатом с помощью веб шифрования JSON (JWE).
Чтобы обеспечить действительное сквозное шифрование в облаке, мы не можем участвовать в шифровании и загрузке сертификата и ключа. Если вам необходим такой уровень безопасности, вы должны:
Запрос сертификатов.
Генерация пар ключей для ваших сертификатов.
Создание (и защита) исходного секретного кода для каждого устройства, чтобы инициировать возможность шифрования для устройства.
Разработка и поддержание собственного инструмента для шифрования файлов с помощью стандарта JWE.
Процесс и (не секретные) параметры, которые вам понадобятся, описаны ниже, а также рецепт, которому следует следовать в выбранных вами инструментах разработки. Кроме того, мы предоставляем некоторые тестовые данные и итоговые двоичные объекты JWE, которые, как мы предполагаем, помогут вам проверить процесс.
Неподдерживаемая справочная реализация на Python3 с применением библиотеки JWCrypto доступна в Cisco по запросу.
Объедините сертификат и ключ в цепочку и зашифруйте их с помощью инструмента и исходного секретного кода устройства.
Загрузите получившийся двоичный объект JWE на устройство.
Задайте назначение зашифрованного сертификата, который будет использоваться для идентификации Webex, и активируйте сертификат.
(Рекомендуется) Предоставьте интерфейс (или распространите) свой инструмент, чтобы пользователи устройства могли изменять начальный секрет и защищать свои носители от вас.
Использование формата JWE
В этом разделе описываются наши ожидания от процесса создания JWE в качестве входных данных для устройств, чтобы вы могли создать собственный инструмент для создания двоичных объектов из сертификатов и ключей.
Обратитесь к веб шифрование JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516и веб подпись JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Мы используем Компактная сериализация документа JSON для создания больших двоичных объектов JWE. При создании BLOB-объектов JWE необходимо указать следующие параметры:
Заголовок JOSE (защищенный). Заголовок подписи и шифрования объекта JSON ДОЛЖЕН включать следующие пары ключ-значение:
"alg":"dir"
Для шифрования полезной нагрузки поддерживается только прямой алгоритм. Необходимо использовать исходный секрет клиента устройства.
"enc":"A128GCM"
или"enc":"A256GCM"
Поддерживаются эти два алгоритма шифрования.
"cisco-action": "add"
или"cisco-action": "populate"
или"cisco-action": "activate"
или"cisco-action": "deactivate"
Это закрытый ключ и четыре значения, которые он может принимать. Мы ввели этот ключ для обозначения назначения зашифрованных данных целевому устройству. Значения именуются в соответствии с именем команд xAPI на устройстве, на котором используются зашифрованные данные.
Мы присвоили ему имя
cisco-action
для уменьшения воздействия потенциальных конфликтов с будущими расширениями JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }
Другой закрытый ключ. Мы используем значения, которые вы предоставляете в качестве входных данных для формирования ключей на устройстве. Файл
version
должен быть1
(версия нашей функции формирования ключа). Значениеsalt
должно представлять собой базовую последовательность с кодированием base64 длиной не менее 4 байт, которую необходимо выбрать случайным образом.
Ключ шифрования JWE. Это поле остается пустым. Устройство извлекает его из исходного
ClientSecret
.вектора инициализации JWE. Необходимо предоставить вектор инициализации с кодированием base64url для расшифровки полезной нагрузки. Вектор инициализации ДОЛЖЕН быть случайным значением длиной 12 байт (используется семейство шифров AES-GCM, которое требует, чтобы вектор инициализации имел длину 12 байт).
JWE AAD (дополнительные данные об аутентификации). Необходимо пропустить это поле, поскольку оно не поддерживается в компактной сериализации.
ШифротекстJWE: Это зашифрованная полезная нагрузка, которую необходимо сохранять в тайне.
Полезные данные МОГУТ быть пустыми. Например, чтобы сбросить секрет клиента, необходимо перезаписать его пустым значением.
Существуют различные типы полезной нагрузки, в зависимости от того, что вы пытаетесь сделать на устройстве. Различные команды xAPI ожидают различную полезную нагрузку. Вам нужно указать назначение полезной нагрузки с помощью
cisco-action
ключа следующим образом:С
"cisco-action":"populate"
шифротекст является новымClientSecret
.С "
"cisco-action":"add"
зашифрованный текст представляет собой большой двоичный объект PEM, содержащий сертификат и его закрытый ключ (объединенный).С "
"cisco-action":"activate"
Шифрованный текст - это отпечаток пальца (шестнадцатеричное представление sha-1) сертификата, который мы активируем для проверки подлинности устройства.С "
"cisco-action":"deactivate"
зашифрованный текст - это отпечаток пальца (шестнадцатеричное представление sha-1) сертификата, который мы деактивируем, от использования для проверки подлинности устройства.
Тег аутентификации JWE: В этом поле содержится тег проверки подлинности, применяемый для установления целостности компактно сериализованного двоичного объекта JWE
Как мы получаем ключ шифрования из ClientSecret
После первого заполнения секрета он не принимается и не выводится открытым текстом. Это необходимо для предотвращения возможных словарных атак со стороны любых пользователей, которые могут получить доступ к устройству.
Программное обеспечение устройства использует секрет клиента в качестве входных данных для функции формирования ключа (kdf), а затем применяет полученный ключ для расшифровки и шифрования контента на устройстве.
Для вас это означает, что инструмент, который будет создавать двоичные объекты JWE, должен выполнить ту же процедуру, чтобы создать тот же ключ шифрования/дешифрования из секрета клиента.
Устройства используют scrypt для формирования ключей (см. https://en.wikipedia.org/wiki/Scrypt) с помощью следующих параметров:
CostFactor (N) – 32768
BlockSizeFactor (r) – 8
ParallelizationFactor (p) – 1
Соль – это случайная последовательность из по меньшей мере 4 байт; необходимо предоставить ее
salt
при указанииcisco-kdf
.Длина ключа составляет 16 байт (при выборе алгоритма AES-GCM 128) или 32 байта (при выборе алгоритма AES-GCM 256)
Максимальный объем памяти – 64 МБ
Этот набор параметров является единственной конфигурацией scrypt, совместимой с функцией формирования ключей на устройствах. Эта функция формирования ключа на устройствах называется "version":"1"
и является единственной версией, совместимой в настоящее время с cisco-kdf
.
Рабочий пример
Ниже приводится пример, за которым можно проследить, чтобы убедиться, что процесс шифрования JWE работает так же, как и процесс на устройствах.
Сценарий примера добавляет к устройству двоичный объект PEM (имитирует добавление сертификата с очень короткой строкой вместо полного сертификата + ключа). Секрет клиента в этом примере: ossifrage
.
Выберите шифр для шифрования. В этом примере используется
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 байт для использования в качестве вектора инициализации. В этом примере используется (в шестнадцатеричном представлении)
34 b3 5d dd 5f 53 7b af 2d 92 95 83
которые в кодировании base64url представляют собойNLNd3V9Te68tkpWD
.Создайте заголовок JOSE с компактной сериализацией (следуйте тому же порядку параметров, что и мы в этом примере) и затем закодируйте в base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}
Заголовок JOSE в кодировании base64url –
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
Это будет первый элемент двоичного объекта JWE.
Второй элемент двоичного объекта JWE пуст, поскольку мы не поставляем ключ шифрования JWE.
Третий элемент двоичного объекта JWE – вектор инициализации
NLNd3V9Te68tkpWD
.- Используйте инструмент шифрования JWE для получения зашифрованной полезной нагрузки и тега. В этом примере незашифрованная полезная нагрузка будет являться поддельным двоичным объектом PEM
this is a PEM file
Следует использовать такие параметры шифрования:
Полезная нагрузка
this is a PEM file
Шифр – AES 128 GCM
Заголовок JOSE, закодированный в base64url, выступает в качестве дополнительных аутентифицированных данных (AAD)
Base64url кодирует зашифрованную полезную нагрузку, что приводит к
f5lLVuWNfKfmzYCo1YJfODhQ
Это четвертый элемент (JWE Ciphertext) в двоичном объекте BWE.
Base64url кодирует тег, который вы создали на этапе 8, что должно привести к
PE-wDFWGXFFBeo928cfZ1Q
Это пятый элемент в двоичном объекте JWE.
Объедините пять элементов бинарного объекта JWE в цепочку с помощью точек (JOSEheader. IV.Ciphertext.Tag), чтобы получить:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Если вы сформировали те же кодированные в base64url значения, что и мы в этом примере, с помощью собственных инструментов, можно использовать их для шифрования E2E и проверки идентификации устройств.
В действительности этот пример работать не будет, но в целом вашим следующим шагом будет использование созданного выше двоичного объекта JWE в качестве входных данных xcommand на устройстве, в которое добавляется сертификат:
xCommand Security Certificates Add
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Типы сеансов для совещаний с нулевым доверием доступны на всех веб-сайтах совещаний без дополнительной платы. Один из этих типов сеанса называется Pro-End to End Encryption_VOIPonly
. Это название государственной службы, которое мы можем изменить в будущем. Текущие названия типов сеансов см. в секции Типы сеансов в разделе Справочные материалы этой статьи.
Чтобы получить эту возможность для вашего веб-сайта, необходимо предоставить пользователям новый тип сеанса (также называемый привилегией совещания). Сделать это можно для каждого отдельного пользователя на странице его настроек или массово посредством экспорта и импорта в формате CSV.
1. | Войдите в Control Hub и перейдите к меню . | ||
2. | Щелкните Веб-сайты, выберите веб-сайт Webex, для которого необходимо изменить настройки, и щелкните Настройки. | ||
3. | В разделе Общие настройки выберите Типы сеансов. | ||
4. | Вы должны увидеть один или несколько типов сеансов сквозного шифрования. Обратитесь к списку Идентификаторы типа сеанса в разделе Справочные материалы этой статьи. К примеру, может отображаться название Pro-End to End Encryption_VOIPonly.
| ||
5 | Если у вас еще нет новых типов сеанса, обратитесь к представителю Webex. |
Дальнейшие действия
Включите этот тип сеанса/права для совещания для некоторых или всех пользователей.
1. | Войдите в Control Hub , и перейдите к . |
2. | Выберите учетная запись пользователя для обновления, затем выберите Встречи . |
3. | В раскрывающемся списке Настройки применить выберите веб-сайт совещания, который необходимо обновить. |
4. | Установите флажок рядом с От конца до конца Encryption_ VOIPonly . |
5 | Закройте панель конфигурации пользователя. |
6 | При необходимости повторите эту процедуру для других пользователей. Чтобы назначить это многим пользователям, используйте следующую опцию, Включение совещаний E2EE для нескольких пользователей . |
1. | Войдите в Control Hub и перейдите к меню . | ||
2. | Щелкните Веб-сайты, выберите веб-сайт Webex, для которого необходимо изменить настройки. | ||
3. | В разделе Лицензии и пользователи щелкните Массовое управление. | ||
4. | Щелкните Создать отчет и подождите, пока мы подготовим файл. | ||
5 | Когда файл будет готов, щелкните Экспорт результатов, а затем Скачать. (Вы должны вручную закрыть это всплывающее окно после того, как нажмете Скачать .) | ||
6 | Откройте скачанный файл CSV для редактирования. Для каждого пользователя есть строка, а столбец | ||
7. | Для каждого пользователя, которому нужно предоставить новый тип сеанса, добавьте В Справочник по формату файла Webex CSV содержит подробную информацию о назначении и содержании файл CSV. | ||
8 | Откройте панель конфигурации веб-сайта совещания в Control Hub.
| ||
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
- Войдите в Control Hub, затем в разделе Управление выберите Настройки организации.
- В Встреча с водяными знаками раздел, включить Добавить звуковой водяной знак .
Через некоторое время после включения этого параметра пользователи планируют совещания с помощью
Webex Meetings Pro-End to End Encryption_VOIPonly
тип сеанса см. параметр Digital Watermarking в разделе Безопасность.
Загрузите и проанализируйте встречу с водяными знаками
- В Control Hub под Мониторинг выберите Устранение неполадок .
- Щелкните Анализ водяных знаков .
- Выполните поиск или выберите совещание в списке, затем щелкните Анализ.
- В Анализировать звуковой водяной знак В окне введите имя для анализа.
- (Необязательно) Введите примечание для анализа.
- Перетащите аудиофайл для анализа или щелкните Выбрать файл для перехода к аудиофайлу.
- Нажмите кнопку Закрыть.
Когда анализ будет завершен, он будет показан в списке результатов на Анализировать водяной знак страница.
- Выберите совещание в списке, чтобы просмотреть результаты анализа. Щелкните кнопкудля загрузки результатов.
Функции и ограничения
Факторы, участвующие в успешной расшифровке записанного водяного знака, включают расстояние между записывающим устройством и динамиком, выводящим аудио, громкость этого аудио, шум окружающей среды и т.д. Наша технология водяного маркировки имеет дополнительную устойчивость к многократной кодировке, как это может произойти при совместном доступе к мультимедиа.
Эта функция предназначена для успешного декодирования идентификатора водяного знака в широком, но разумном наборе обстоятельств. Наша цель состоит в том, чтобы записывающее устройство, такое как мобильный телефон, который лежит на столе рядом с персональной конечной точкой или клиентом ноутбука, всегда должно создавать запись, которая приводит к успешному анализу. Поскольку устройство записи удалено от источника или затемнено от прослушивания всего спектра аудио, шансы на успешный анализ уменьшаются.
Для успешного анализа записи необходима разумная запись аудио совещания. Если аудио совещания записывается на том же компьютере, на котором размещен клиент, ограничения не должны применяться.
Если ваши устройства уже подключены к вашей организации Control Hub и вы хотите использовать Webex CA для автоматического создания их идентифицирующих сертификатов, вам не нужно выполнять сброс до заводских настроек .
В этой процедуре выбирается домен, который устройство использует для идентификации себя. Она требуется только в том случае, если в вашей организации Control Hub имеется несколько доменов. Если у вас несколько доменов, рекомендуется сделать это для всех устройств с идентификацией, проверенной Cisco. Если вы не Webex , какой домен идентифицирует устройство, он будет выбран автоматически и другим участникам совещания он может показаться неверным.
Перед началом работы
Если ваши устройства еще не подключены, следуйте инструкциям Зарегистрируйте устройство в Cisco Webex с помощью API или локального веб интерфейса или Подключение к облаку для серий Board, Desk и Room . Вам также следует подтвердить домен (а), который вы хотите использовать для идентификации устройств в Управляйте своими доменами .
1. | Войдите в Control Hub , и под Управление выберите Устройства . |
2. | Выберите устройство, чтобы открыть его панель конфигурации. |
3. | Выберите домен, который необходимо использовать для идентификации этого устройства. |
4. | Повторите эту процедуру для других устройств. |
Перед началом работы
Вам потребуется:
Чтобы получить сертификат, подписанный ЦС, и закрытый ключ, в
.pem
формат для каждого устройства.Прочесть тему О процедуре внешней идентификации для устройств в разделе Подготовка этой статьи.
Подготовить инструмент шифрования JWE для доступной информации.
Средство создания случайных последовательностей байтов заданной длины.
Средство кодирования base64url для байтов или текста.
Одна из реализаций
scrypt
.Секретные слова или фразы для каждого устройства.
1. | Заполните При первом заполнении Устройство обладает исходным секретом. Не забывайте об этом; вы не можете восстановить его, и для повторного запуска необходимо выполнить сброс настроек устройства.
|
2. | Объедините сертификат и закрытый ключ в цепочку: |
3. | Создайте двоичный объект JWE для использования в качестве вводных данных команды добавления сертификата: |
4. | Откройте TShell на устройстве и запустите (многострочную) команду добавления:
|
5 | Убедитесь, что сертификат добавлен, запустив Скопируйте идентификационную метку нового сертификата. |
6 | Активируйте сертификат для назначения Устройство имеет зашифрованный активный сертификат, выданный ЦС, готовый к его идентификации в совещаниях Webex со сквозным шифрованием.
|
7. | Подключите устройство к вашей организации в Control Hub. |
1. | Запланируйте совещание необходимого типа (Webex Meetings Pro-End to End Encryption_VOIPonly). |
2. | Присоединитесь к совещанию в качестве организатора из клиента Webex Meetings. |
3. | Присоединитесь к совещанию с устройства, идентификация которого проверена ЦС Webex. |
4. | Будучи организатором, убедитесь, что это устройство отображается в холле с необходимой пиктограммой идентификации. |
5 | Присоединитесь к совещанию с устройства, идентификация которого проверена внешним ЦС. |
6 | Будучи организатором, убедитесь, что это устройство отображается в холле с необходимой пиктограммой идентификации. Получить более подробные сведения о пиктограммах удостоверений можно по этой ссылке. |
7. | Присоединитесь к совещанию в качестве участника, не прошедшего аутентификацию. |
8 | Будучи организатором, убедитесь, что этот участник появится в холле с необходимой пиктограммой идентификации. |
9 | Будучи организатором, попробуйте допустить пользователей или устройства на совещание или отклонить их. |
10 | По возможности проверяйте удостоверения участников / устройств, проверяя сертификаты. |
11 | Убедитесь, что все присутствующие на совещании видят одинаковый код безопасности совещания. |
12 | Присоединитесь к совещанию с новым участником. |
13 | Убедитесь, что все присутствующие видят одинаковый новый код безопасности совещания. |
Вы собираетесь сделать совещания со сквозным шифрованием вариантом по умолчанию, включить их только для некоторых пользователей или дать всем организаторам возможность принять решение самостоятельно? После того как вы решили использовать эту функцию, подготовьте пользователей, которые будут ее использовать. Обратите особое внимание на ограничения и то, чего можно ожидать на совещании.
Вам необходимо убедиться, что Cisco и другие компании не могут расшифровывать контент или выдать себя за ваши устройства? В этом случае вам потребуется сертификат из общедоступного ЦС. В безопасном совещании может быть не более 25 устройств. Если вам необходим такой уровень безопасности, не разрешайте клиентам совещаний присоединяться.
Разрешите пользователям с безопасными устройствами присоединиться в первую очередь, а также сообщите пользователям, что они могут не присоединиться, если прибудут на совещание с опозданием.
Если вы используете разные уровни проверки идентификации, дайте пользователям возможность проверить друг друга, проверив удостоверение с помощью сертификатов и кода безопасности совещания. Несмотря на то, что в определенных обстоятельствах участники могут выглядеть как непроверенные и участники должны знать, как это проверить, непроверенные люди могут оказаться не самозванцами.
Если для выдачи сертификатов устройства используется внешний ЦС, контроль, обновление и повторное применение сертификатов находится в зоне вашей ответственности.
Если вы создали исходный секрет, помните, что пользователи могут захотеть изменить секрет своего устройства. Для этого может потребоваться создать интерфейс или распределить инструмент.
Идентификатор типа сеанса | Название общедоступной службы |
---|---|
638 | E2E Encryption+VoIP only |
652 | Pro-End to End Encryption_VOIPonly |
660 | Pro 3 Free-End to End Encryption_VOIPonly E2E Encryption + Identity |
672 | Pro 3 Free50-End to End Encryption_VOIPonly |
673 | Education Instructor E2E Encryption_VOIPonly |
676 | Broadworks Standard со сквозным шифрованием |
677 | Broadworks Premium со сквозным шифрованием |
681 | Schoology Free со сквозным шифрованием |
В этих таблицах описываются команды API для устройств Webex, добавленные для совещаний со сквозным шифрованием и проверкой идентификации. Дополнительную информацию об использовании API см. в статье Доступ к API для Webex Room, настольных устройств и Webex Board.
Эти команды xAPI доступны только на устройствах, которые:
зарегистрированы в Webex;
зарегистрированы локально и связаны с Webex с помощью Webex Edge для устройств.
Вызов API | Описание |
---|---|
| Эта конфигурация используется, если администратор задает предпочтительный домен устройства в Control Hub. Требуется только в том случае, если у организации несколько доменов. Устройство использует этот домен при запросе сертификата от ЦС Webex. Затем домен идентифицирует устройство. Эта конфигурация неприменима, если устройство имеет активный внешний сертификат для самоидентификации. |
| Указывает, может ли устройство присоединиться к совещанию со сквозным шифрованием. API в облаке вызывает его, чтобы сопряженное приложение определило, может ли оно использовать устройство для присоединения. |
| Указывает на то, использует ли устройство проверку |
| Идентификация устройства, как указано в общем имени внешнего сертификата. |
| Считывает конкретные сведения из сертификата, выданного внешней организацией. В показанной команде замените
|
| состояние внешнего удостоверения устройства (например, |
| Указывает, имеет ли устройство действительный сертификат, выданный ЦС Webex. |
| Удостоверение устройства, как указано в общем имени сертификата, выданного Webex. Содержит имя домена, если у организации есть домен. Это поле пусто, если у организации нет домена. Если устройство находится в организации с несколькими доменами, это значение из |
| Считывает конкретные сведения из сертификата, выданного Webex. В показанной команде замените
|
Вызов API | Описание |
---|---|
| Теперь эти три события включают |
Вызов API | Описание |
---|---|
или
| Принимает значение закодированного в base64url открытого текста, чтобы в первый раз задать секрет клиента на устройстве. Чтобы обновить секрет после первого раза, необходимо предоставить двоичный объект JWE, содержащий новый секрет, зашифрованный с помощью старого. |
| Добавляет сертификат (с закрытым ключом). Эта команда была расширена и теперь принимает двоичный объект JWE, содержащий зашифрованные данные PEM. |
| Активирует определенный сертификат для объекта WebexIdentity. Для параметра |
| Деактивирует определенный сертификат для объекта WebexIdentity. Для параметра |