Дякуємо за відгук.

Мільйони користувачів у всьому світі покладаються на Webex для безпечної співпраці. Від залів засідань корпоративних засідань та урядових законодавчих сесій до чутливих консультацій лікаря та пацієнта, Webex служить надійною платформою для важливих комунікацій.

Зі збільшенням попиту на віддалену роботу зростає потреба в надійних, конфіденційних інструментах співпраці. Webex вирішує цю потребу довше, ніж будь-який інший постачальник. Зі зростанням видавання себе за допомогою штучного інтелекту та складних глибоких загроз вимога до перевірки ідентичності та співпраці на основі політики є першорядною. Для наших клієнтів безпека — це не просто функція — це інтегрований компонент всього життєвого циклу нарад, що охоплює планування, ідентичність учасників та захист вмісту.

Webex має довгу історію підтримки надійного наскрізного шифрування (E2EE). Наша модель Webex Zero Trust Security розвиває цю спадщину за допомогою трьох основних стовпів:

• Створення основи стандартної, офіційно перевіреної криптографії
• Розширення наскрізного шифрування за допомогою наскрізної перевірки ідентичності
• Розширення підтримки на поточні пристрої Webex, а також на додаток Webex

Цей технічний документ містить довідкову інформацію про наскрізну безпеку та викладає технічні основи того, як працює WebExZero Trust Security. Щодо оперативної безпеки нарад, таких як типи сеансів нарад, відмінності в безпеці між запланованими зустрічами та особистими кімнатами нарад, контроль адміністратора та господаря, обмін та збереження вмісту нарад, а також ширша стійкість до штучного інтелекту та глибокої фіксації у роботі нарад, див. супровідний технічний документ WSMP Meetings Security.

18-річна спадщина забезпечення безпеки E2E

У 2008 році Webex запровадив шифрування E2E для нарад. За визначенням, безпека E2E гарантує, що вміст шифрується з моменту його надсилання до його відображення одержувачем, запобігаючи хмарному провайдеру або будь-якій третій стороні отримати доступ або втручатися в дані.

Залежно від того, скільки інвестицій робить постачальник відеоконференцій у механізми безпеки E2E, вони можуть забезпечити різний рівень захисту, як показано на малюнку 1. Будь-яка безпека E2E краще, ніж лише шифрування під час транзиту та в стані спокою.

Рівень захисту	мережеві зловмисники	Пасивні атаки (підслуховування)	Активні атаки (видача за себе)	Приклади
Шифрування під час транзиту та в стані спокою	Так	Ні	Ні	Програми, що не належать до E2EE
Шифрування E2E	Так	Так	Ні	Застарілі E2EE та споживчі додатки
Шифрування E2E та ідентичність E2E	Так	Так	Так	Безпека нульової довіри Webex

Більшість додатків, які стверджують, що забезпечують безпеку E2E, забезпечують захист лише від пасивних атак. Тільки пасивний захист все ще є цінним, оскільки вони роблять так, що погані актори можуть підслуховувати зустріч лише під час її проведення. Найкращий підхід, однак, полягає в захисті як від пасивних, так і від активних атак, коли сам постачальник конференцій може прикидатися законним учасником для участі в зустрічі. Для цього на додаток до шифрування E2E потрібен рівень ідентичності E2E.

Завдяки Zero Trust Security Webex забезпечує більш надійну криптографію для нарад та розширює наскрізне шифрування наскрізною верифікацією ідентичності, щоб допомогти захистити зустрічі від повного спектру атак.

Перш ніж зануритися в технічні деталі, корисно зрозуміти досвід користувача. Щоб створити зашифровану нараду E2E, господар вибирає відповідний тип наради під час планування в програмі Webex (Малюнок 2).

Коли учасники приєднуються, вони бачать значок «щит із замком», що вказує на те, що зустріч зашифрована E2E (Малюнок 3). Торкнувшись цієї піктограми, ви отримаєте детальну інформацію про захист наради.

Нарешті, у списку учасників наради програма Webex вказує, чи була особа учасника перевірена захищеним E2E-захищеним способом, тобто чи хтось інший, крім Cisco, поручив особу учасника (Малюнок 4).

Учасники також можуть перевірити, чи всі вони мають однаковий код безпеки, щоб підтвердити, що всі вони мають однаковий погляд на зустріч, і таким чином захищені від атак видачі себе. У розгортаннях, які використовують надані клієнтом наскрізні сертифікати ідентифікації, стан списку забезпечує прозорість щодо забезпечення ідентичності.

Zero Trust Security побудована на стандартних галузевих криптографічних протоколах, які Cisco керує разом з іншими лідерами в галузі безпеки та конфіденційності, включаючи Google, Cloudflare, Wickr та Wire. Cisco очолила перше покоління захищеного голосу через IP (VoIP) з такими технологіями, як Secure Real-Time Protocol (SRTP), DTLS-SRTP, STIR/SHAKEN та WebRTC, а Cisco робить те ж саме з нульовою безпекою довіри (Малюнок 5).

Шар	Сьогодні	Безпека нульової довіри
Ідентичність	SSO (SAML, OpenID)	Сертифікат X.509
Обмін ключами	SDES/DTLS	Безпека рівня обміну повідомленнями (MLS)
Шифрування медіа	SRTP	Безпечні рамки (SFrame)

В основному в системі є три шари, і на кожному шарі ми беремо стару технологію hop-by-hop і підкріплюємо її додатковим наскрізним шаром захисту. Три шари включають:

• Ідентичність — ідентичність E2E вимагає, щоб клієнти мали облікові дані, які підтверджують їхню особу. Завдяки ідентифікації Zero Trust E2E облікові дані клієнтів надаються незалежним Webex. Certificate Authority
• Обмін ключами — клієнти, які беруть участь у нараді E2E, повинні налаштувати ключі для шифрування E2E без доступу постачальника конференцій до цих ключів. Протокол захисту рівня обміну повідомленнями (MLS) - це ратифікований стандарт, RFC 9420, який базується на технологіях, розроблених у спільноті з відкритим кодом, і ставить їх у суворі, офіційно перевірені умови.
• Захист вмісту — нарешті, фактичний медіаконтент наради потребує наскрізного захисту. SFrame (для «захищених кадрів») - це RFC 9605. Це швидка та проста структура шифрування для шифрування носіїв у режимі реального часу, що дозволяє додавати додатковий шар шифрування з мінімальними накладними витратами.

Давайте розглянемо ці технології трохи докладніше, починаючи знизу вгору.

Схема шифрування медіа — це спосіб взяти ключ, яким користуються учасники наради, і використовувати його для захисту фактичного вмісту, який поділяється на нараді, наприклад аудіо, відео та спільний доступ до екрана. На рівні протоколу схема шифрування повинна надсилати додаткову інформацію з кожною одиницею зашифрованих даних, головне:

1. Заголовок, який повідомляє одержувачу, як розшифрувати пакет, і
2. Тег автентифікації, який приймач використовує для перевірки того, що пакет не був підроблений.

Наприклад, в SRTP одиницею шифрування є пакет RTP; SRTP покладається на заголовок RTP для його налаштування і додає тег аутентифікації до кінця пакета.

Оскільки вся ця додаткова інформація збільшує пропускну здатність, необхідну для зашифрованої зустрічі E2E, SFrame забезпечує мінімальну кількість необхідного кадрування. Заголовок sFrame вказує, який ключ слід використовувати, дозволяючи обертати ключ, і надає унікальний порядковий номер, який визначає вектор ініціалізації. Далі йде вміст, зашифрований ключем E2E та тегом аутентифікації. Потім заголовок, вміст і тег sFrame загортаються в пакет SRTP, щоб SRTP захищав від перевірки або модифікації мережевими зловмисниками, а SFrame захищає від медіа-елементів постачальника конференцій (див. приклад на малюнку 6).

Цей мінімалістичний підхід має й інші переваги. SFrame не залежить від основного транспорту, тому він сумісний з новими технологіями, такими як RTP через QUIC та RIPT. Також можна налаштувати sFrame так, щоб він працював на багатопакетних одиницях, таких як цілі кадри, щоб ще більше зменшити витрати на шифрування.

Налаштування секретного ключа серед групи, коли група має доступ лише до ненадійного каналу, здається магічним. Методи для цього були вперше розроблені в 1980-х роках, і сьогодні понад 90 відсотків веб-перегляду використовують транспортний рівень безпеки (TLS) для цього. Безпека рівня обміну повідомленнями (MLS) розширює цю функцію на групи, тоді як TLS працює лише точка в точку, тому Webex може використовувати MLS для налаштування ключів конференції, навіть якщо постачальник конференції не довіряє.

MLS надає три критичні функції безпеки:

1. Спільний клю ч — ключ відомий лише автентифікованим учасникам групи.
2. Послі довність - Забезпечує, що всі члени мають послідовне уявлення про список груп.
3. Поворот — Автоматично оновлює ключі, коли член приєднується або виїжджає.

Перша функція надає нам ключі, які ми використовуємо для шифрування носіїв за допомогою SFrame. Разом з другою функцією він забезпечує відправну точку для ідентичності E2E. Третя функція гарантує, що єдиними людьми, які можуть розшифрувати медіа, є люди, які зараз перебувають на зустрічі - ви не можете розшифрувати медіа до того, як ви приєдналися або після того, як ви пішли (або були вигнані).

Щоб досягти всього цього, клієнти на нараді обмінюються повідомленнями MLS у критичних точках зустрічі, щоб підтримувати групу MLS, яка містить саме учасників зустрічі в будь-який момент часу. Webex маршрутизує повідомлення між клієнтами, але MLS захищає ці повідомлення, щоб Webex було безпечно обробляти їх. На малюнку 7 показано, як протікають повідомлення.

Створення: Перша людина, яка приєднується до зустрічі, приймаюча чи ні, створює групу MLS для зустрічі і стає «лідером» для цілей MLS. У будь-який момент часу лідером призначається один учасник зборів. У більшості випадків цей учасник буде ведучим зустрічі. Після початку сеансу MLS запевняє, що кожен учасник зустрічі має криптографічну інформацію, щоб виступати лідером; Webex просто призначає одного лідера, щоб уникнути плутанини.

Приєдну@@ йтесь: коли новий учасник хоче приєднатися до зустрічі, він просить його впустити, надіславши повідомлення про пакет ключів MLS керівнику, яке містить його відкритий ключ та інформацію про автентифікацію. Керівник відповідає вітальним повідомленням, яке повідомляє столяру про інших учасників зустрічі. Керівник також транслює повідомлення «Додати» і повідомлення «Підписати» групі. Повідомлення Додати повідомляє про нового столяра тим, хто вже є на зустрічі. Повідомлення Commit змушує всіх поточних учасників хешувати старий ключ групи, щоб отримати новий ключ для розширеної групи. Повідомлення привітання надає цей ключ об'єднаному учаснику.

Зали ште: Коли хтось залишає зустріч, завдання лідера - заблокувати їх. Лідер робить це, транслюючи повідомлення MLS Remove та Commit всім, хто залишився на зустрічі. Повідомлення «Видалити» повідомляє іншим учасникам, які пішли, а Коміт шифрує новий ключ для всіх учасників, що залишилися, але не для особи, яка пішла. Решта учасників хешірує новий ключ зі старим ключем групи, щоб отримати ключ, якого немає у особи, яка пішла. Якщо учасник, який пішов, є лідером, Webex призначає нового лідера, а новий лідер видаляє старого лідера.

Ротація ключів може означати, що для приєднання до наради або видалення когось потрібно кілька додаткових секунд, але це дає чітку гарантію безпеки: якщо хтось не з'являється у списку учасників наради, у нього немає ключів для розшифровки вмісту.

Список учасників зашифрованої зустрічі E2E показує перевірку особистості кожного користувача. Використання сертифікатів, виданих клієнтом, забезпечує справжню ідентичність, підтверджену E2E, у тому сенсі, що Cisco не може втручатися в неї. У цих випадках у списку учасників синім текстом відображається домен, до якого належить учасник. Наприклад, на нараді, показаній на малюнку 8, ви можете побачити, що Кевін має підтверджену адресу електронної пошти з example.com, а Ізабелла має підтверджену адресу електронної пошти від company.com.

Сертифікати ідентифікації, видані WebexCertificate Authority, такі як ідентифікація відеопристрою, забезпечують більш обмежений захист. Тільки зловмисник, який компрометує Webex, Certificate Authority може видавати себе за користувача. Незважаючи на те, що це краще, ніж взагалі не мати захисту особистості, такі учасники зустрічі не позначені синім кольором як наскрізна перевірка ідентичності Zero Trust. Вони відображаються сірим текстом, що вказує на перевірку довіри Webex.

Як резервний пункт для цих процедур, Webex також надає код безпеки для зустрічі. Код безпеки - це короткий рядок, що читається людиною, обчислений як вихід процесу MLS. Код безпеки узагальнює криптографічний стан наради, включаючи ключі групи та сертифікати, представлені учасниками. Цей код може бути використаний для виявлення атаки видавання себе за особу, оскільки така атака призведе до того, що принаймні один учасник матиме інший криптографічний стан, ніж усі інші. Але це виключає видавання себе за особу лише в тому випадку, якщо всі перевіряють, що у них однаковий код. Якщо якась підмножина учасників перевірить, що вони мають однаковий код, вони знають, що їхні ідентичності вірно представлені один одному, але хтось, хто не підтверджує їх код, міг бути видаваний. На малюнку 9 наведено приклад того, як код безпеки відображається на нараді.

Цей код забезпечує дуже сильний захист від атак уособлення. Він є частиною протоколу MLS, тому він мав надійний аналіз безпеки. Оскільки він тісно пов'язаний зі станом наради, код безпеки змінюється щоразу, коли хтось приєднується до зустрічі. В результаті учасникам зустрічі потрібно повторно перевіряти свої коди безпеки щоразу, коли хтось приєднується. Код не обертається, коли хтось йде, тому що вихід не може ввести імітатора.

Безпека Webex Zero Trust була запущена в 2021 році. У 2026 році Ultra Secure Webex Meetings запровадили підтримку додаткових кінцевих точок у зашифрованих E2E нарадах Webex, повнофункціональні зустрічі Zero Trust E2EE з вершиною Video Mesh (VMN), а також можливості наскрізного шифрування та ідентифікації для стандартних нарад:

• Формально перевірена криптографія на основі стандартів
• Шифрування нульової довіри E2E
• Zero Trust E2E підтверджена особа
• Підтримка всіх пристроїв Webex, доступних для продажу
• Підтримка програми Webex на настільних комп'ютерах, мобільних пристроях та веб-пристроях
• Підтримка веб-програми Webex та веб-SDK (планується для Q1CY27)
• Підтримка Webex Calling телефонів (планується для Q3CY26)
• Підтримка вузла відеосітки
• Підтримка шифрування E2E в запланованих зустрічах і особистих конференц-залах

Нульова довіра має деякі обмеження. Зашифровані наради E2E не підтримують:

• Функції, що надаються хмарними сервісами Cisco, які потребують доступу до носіїв звичайного тексту, зокрема:
  • Хмарні записи та AI Assistant сервіси Webex. Ці послуги можуть бути надані за допомогою гібридних розгортань з Video Mesh Node (VMN).
  • Збереження чату для нарад, файлів, дощок та анотацій.
  • Суперсумісність PSTN або SIP.

У майбутньому Webex вдосконалюватиме зашифровані зустрічі E2E у кількох вимірах, керуючись принципами надання хмарі найменших необхідних привілеїв та надання клієнтам контролю над своїми даними.

Повсюдна безпека E2E: Все повинно бути захищеним E2E, а не лише окремі зустрічі. Перший крок до досягнення цього бачення був досягнутий завдяки безпеці E2E для телефонів Cisco Webex Web App та підключених до хмари. Зрештою, відкрита архітектура E2E на основі стандартів повинна дозволити Webex також впровадити інфраструктуру протоколу ініціації сеансу (SIP).

Нововведення, розглянуті в цій роботі, показують чіткий шлях до довгострокового бачення завжди активного шифрування E2E. Після того, як користувачі зможуть підключатися з будь-якого місця, а клієнти можуть безпечно використовувати функції, які вони хочуть під час зустрічі, шифрування E2E можна використовувати для кожної зустрічі Webex — від неформальних спеціальних зустрічей з увімкненими всіма функціями до заблокованих нарад із високою безпекою. Шифрування E2E завжди гарантує, що вміст зустрічі доступний лише уповноваженим учасникам, а клієнти та користувачі вирішуватимуть, який набір учасників підходить для даної зустрічі.

Видача за особу з підтримкою штучного інтелекту та стійкість до глибоких підробків

Webex вирішує загрози видавати себе за допомогою штучного інтелекту за допомогою багатошарового підходу, який доповнює наскрізну модель шифрування Zero Trust. Хоча ця стаття зосереджена на технічних основах наскрізної перевірки ідентичності, включаючи перевірку на основі сертифікатів, наданих клієнтом, та перевірки криптографічної цілісності, Webex також забезпечує контроль оперативної безпеки під час зустрічі, щоб зменшити ризик несанкціонованого доступу та шкідливих взаємодій.

Про типи сеансів нарад, відмінності в безпеці запланованих зустрічей та особистих конференц-залів, елементи керування господарями та адміністраторами в Центрі керування, а також додаткове виявлення та запобігання штучним інтелектом та глибоким підробкам у ширшому досвіді нарад див. супровідний технічний документ WSMP Meetings Security.

Webex визначає майбутнє безпечних зустрічей за допомогою стандартної криптографії та підтвердженої ідентичності. Прихильність до відкритої екосистеми гарантує, що клієнти зберігають абсолютний контроль над своїми даними, незалежно від сценарію зустрічі.