Пользователи выбирают новый тип совещания при планировании совещания. При допуске участников из холла и во время совещания организатор может видеть состояние проверки идентификации каждого участника. Кроме того, существует код совещания, который является общим для всех текущих участников совещания. Они могут использовать его для проверки друг друга.
Поделитесь информацией по следующим темам с организаторами совещаний.
Присоединиться к совещанию Webex со сквозным шифрованием
Проверка идентификации
Сквозная проверка удостоверений обеспечивает дополнительную безопасность совещания со службой шифрования.
Когда участники или устройства присоединяются к совместной группе MLS (защита на уровне обмена сообщениями), они представляют свои сертификаты другим участникам группы, которые затем проверяют сертификаты с помощью выпустивших их органов сертификации (CA). Подтвердив, что сертификаты действительны, центр сертификации проверяет идентификацию участников, и после этого участники или устройства отображаются как подтвержденные.
Пользователи приложения Webex Meetings проходят аутентификацию с помощью хранилища удостоверений Webex, в котором после успешного получения доступа им будет выдан маркер доступа. Если им необходим сертификат для проверки их идентификации во время совещания со сквозным шифрованием, ЦС Webex выдает им сертификат на основе маркера доступа. В настоящий момент мы не предоставляем пользователям Webex Meetings возможность получения сертификата, выданного сторонним или внешним ЦС.
Устройства могут самостоятельно проходить аутентификацию с помощью сертификата, выданного внутренним ЦС (ЦС Webex), или сертификата, выданного внешним ЦС.
Если применяется внутренний ЦС, ЦС Webex выдает внутренний сертификат на основе маркера доступа учетной записи устройства. Сертификат подписывается ЦС Webex. У устройств нет таких же идентификаторов, как у пользователей, поэтому Webex использует домен (или один из доменов) вашей организации при выдаче удостоверения сертификата устройства (общее имя (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 для каждого устройства. К примеру, для организации, которая владеет доменом example.com, это может быть "meeting-room-1.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. У организаций 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
Пример больших двоичных объектов JWE
Пример корректно зашифрованного JWE на основе заданных параметров (приложение)
Webex Meetings 41.7.
Устройства Webex Room и Webex Desk, зарегистрированные в облаке, запущены
10.6.1-RoomOS_August_2021
.Административный доступ к веб-сайту совещания в Control Hub для подключения нового типа сеанса для пользователей.
Один или несколько проверенных доменов в организации Control Hub (если вы используете центр сертификации Webex для выдачи сертификатов устройств для проверки идентификации).
Чтобы участники могли присоединиться с помощью видеосистемы, необходимо включить функцию совместных комнат совещаний. Дополнительную информацию см. в статье Разрешение для видеосистем на присоединение к совещаниям и event-совещаниям Webex на веб-сайте Webex.
Этот этап можно пропустить, если внешняя проверка идентификации не требуется.
Для обеспечения высочайшего уровня безопасности и проверки удостоверений каждое устройство должно иметь уникальный сертификат, выданный доверенным общедоступным ЦС.
Для запроса, приобретения и получения цифровых сертификатов и создания связанных с ними закрытых ключей необходимо взаимодействовать с ЦС. При запросе сертификата используйте указанные параметры.
Сертификат должен быть выдан и подписан широко известным общедоступным ЦС.
Уникальный: Настоятельно рекомендуется использовать уникальный сертификат для каждого устройства. Если для всех устройств используется один сертификат, вы ставите под угрозу безопасность.
Общее имя (CN) и альтернативное имя (имена) субъекта (SAN): Они не играют никакой роли для Webex, но должны быть значениями, которые люди могут прочитать и связать с устройством. CN будет показываться другим участникам совещания в качестве основной проверенной идентификации устройства. Если пользователи проверяют сертификат с помощью интерфейса пользователя совещания, они будут видеть одно или несколько SAN. Можно использовать такие имена, как
name.model@example.com
но это ваш выбор.Формат файла. Сертификаты и ключи должны быть в формате .pem.
Назначение Назначением сертификата должна быть идентификация Webex.
Создание ключей Сертификаты должны быть основаны на парах ключей ECDSA P-256 (алгоритм цифровых подписей на основе эллиптических кривых с помощью кривой P-256).
Это требование не распространяется на ключ подписи. Для подписания сертификата ЦС может использовать ключ RSA.
Этот этап можно пропустить, если вы не хотите использовать внешнюю проверку идентификации для ваших устройства.
Если вы используете новые устройства, пока не регистрируйте их в Webex. Чтобы обеспечить безопасность, их не стоит подключать к сети сразу же.
Если необходимо модернизировать существующие устройства для использования внешних удостоверений, потребуется сбросить настройки этих устройств до заводских.
Сохраните существующую конфигурацию, если не хотите потерять ее.
Запланируйте окно, когда устройства не используются, или используйте поэтапный подход. Сообщите пользователям об ожидаемых изменениях.
Обеспечьте физический доступ к устройствам. Если вам необходимо иметь доступ к устройствам по сети, следует помнить о том, что секреты пересылаются открытым текстом и что это ставит под угрозу безопасность.
После выполнения этих действий предоставьте разрешение видеосистемам присоединяться к совещаниям и event-совещаниям на вашем веб-сайте Webex.
Чтобы обеспечить возможность шифрования мультимедиа устройства только самим устройством, необходимо зашифровать закрытый ключ на устройстве. Мы разработали API, чтобы обеспечить управление зашифрованным ключом и сертификатом с помощью шифрования JSON Web Encryption (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. К параметрам, которые необходимо включить при создании двоичных объектов 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 | Щелкните имя своего веб-сайта, чтобы открыть панель конфигурации веб-сайта. |
||
3 | Щелкните Настроить веб-сайт. |
||
4 | В области Общие настройки щелкните Типы сеанса. На этой странице вы увидите один или несколько типов сеансов со сквозным шифрованием. Обратитесь к списку Идентификаторы типа сеанса в разделе Справочные материалы этой статьи. К примеру, может отображаться название Pro-End to End Encryption_VOIPonly.
|
||
5 | Если у вас еще нет новых типов сеанса, обратитесь к представителю Webex. |
Дальнейшие действия
Включите этот тип сеанса/права для совещания для некоторых или всех пользователей.
1 | Щелкните Пользователи и выберите пользователя, чтобы открыть панель конфигурации пользователя. |
2 | В области Службы выберите Cisco Webex Meetings. |
3 | Выберите веб-сайт (если пользователь присутствует в более чем одном) и щелкните Организатор. |
4 | Установите флажок напротив записи Webex Meetings с названием Pro-End to End Encryption_VOIPonly. |
5 | Закройте панель конфигурации пользователя. |
6 | При необходимости повторите эту процедуру для других пользователей. Чтобы назначить этот тип многим пользователям, воспользуйтесь возможностью пакетной обработки в CSV. |
1 | Войдите в Control Hub на https://admin.webex.com и откройте страницу Совещание. |
||
2 | Щелкните имя своего веб-сайта, чтобы открыть панель конфигурации веб-сайта. |
||
3 | В разделе Лицензии и пользователи щелкните Массовое управление. |
||
4 | Щелкните Экспорт и подождите, пока идет подготовка файла. |
||
5 | Когда файл будет готов, щелкните Экспорт результатов, а затем Скачать. (Это всплывающее окно необходимо закрыть вручную после нажатия кнопки Скачать.) |
||
6 | Откройте скачанный файл CSV для редактирования. Для каждого пользователя есть строка, а столбец |
||
7 | Для каждого пользователя, которому нужно предоставить новый тип сеанса, добавьте В статье О формате файлов CSV для Cisco Webex приведены сведения о назначении и содержимом файла CSV. |
||
8 | Откройте панель конфигурации веб-сайта совещания в Control Hub.
|
||
9 | В разделе Лицензии и пользователи щелкните Массовое управление. |
||
10 | Щелкните Импорт и выберите отредактированный CSV, затем щелкните Импорт. Дождитесь загрузки файла. |
||
11 | По завершению импорта можно щелкнуть Результаты импорта, чтобы проверить, есть ли ошибки. |
||
12 | Перейдите на страницу Пользователи, откройте страницу одного из пользователей и проверьте, доступен ли им новый тип сеанса. |
Если ваши устройства уже были связаны с организацией Control Hub и вы хотите использовать центр сертификации Webex для автоматического создания сертификатов идентификации, не нужно сбрасывать настройки устройств до заводских.
В этой процедуре выбирается домен, который устройство использует для идентификации себя. Она требуется только в том случае, если в вашей организации Control Hub имеется несколько доменов. Если у вас несколько доменов, рекомендуется сделать это для всех устройств с идентификацией, проверенной Cisco. Если вы не сможете сообщить Webex, какой домен идентифицирует устройство, домен будет выбран нами. Однако это может показаться неправильным другим участникам совещания.
Прежде чем начать
Если ваши устройства еще не были перенесены, можно следовать инструкциям в статьях Регистрация устройства в Cisco Webex с помощью API или локального веб-интерфейса или Перенос устройств в облачную среду. Кроме того, необходимо проверить домены, которые будут использоваться для идентификации устройств, в статье Управление устройствами.
1 | Войдите в Control Hub (https://admin.webex.com) и откройте страницу Устройства. |
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. Для параметра |