Безопасность и Skype для бизнеса Online

Важно!

Поддержка Skype для бизнеса Online прекратится 31 июля 2021 г. Если до этой даты пользователи Skype для бизнеса Online не будут переведены в Microsoft Teams, для них будет автоматически запланирован переход с помощником. Если вы хотите самостоятельно обновить организацию до Teams, настоятельно рекомендуем начать планирование пути обновления уже сегодня. Необходимо помнить, что успешный переход требует и технической подготовки, и подготовки пользователей, поэтому для подготовки перехода на Microsoft Teams обязательно воспользуйтесь нашим руководством по обновлению.

Skype для бизнеса Online (SfBO), как часть служб Microsoft 365 и Office 365, соблюдает все советы и процедуры по обеспечению безопасности на уровне службы, а также глубокое управление безопасностью в службе, ужесточить безопасность и оперативные методики. Подробные сведения см. в центре управления доверием https://microsoft.com/trustcenter) (.

Защищенность, обеспечиваемая дизайном

Skype для бизнеса Online разработан и разработан в соответствии с жизненным циклом разработки надежной вычислительной безопасности Microsoft (SDL), который описан в https://www.microsoft.com/sdl/default.aspx. Первым этапом создания более безопасной системы объединенных коммуникаций была разработка моделей угроз и тестирование каждого компонента по мере проектирования. Различные улучшения, связанные с обеспечением безопасности, были включены в технологический процесс разработки исходного кода. Переполнения буфера и другие угрозы безопасности обнаруживаются средствами разработки на этапе сборки, прежде чем код будет внесен в окончательную версию продукта. Конечно, невозможно спроектировать защиту от всех неизвестных угроз безопасности. Ни одна система не может гарантировать полную безопасность. Однако поскольку разработка продукта с самого начала была защищена, Skype для бизнеса Online включает в себя отраслевые стандартные технологии безопасности в качестве основной части архитектуры.

Защищенность по умолчанию

Сетевая связь в Skype для бизнеса Online зашифровывается по умолчанию. Так как все серверы должны использовать сертификаты и использовать OAUTH, TLS, протокол SRTP secure Real-Time и другие отраслевые методы шифрования, включая 256-битное шифрование AES, все данные Skype для бизнеса Online будут защищены в сети.

Как SfBO обрабатывает общие угрозы безопасности

В этом разделе указаны наиболее распространенные угрозы безопасности службы SfBO и то, как Корпорация Майкрософт устраняет каждую из них.

Атака с использованием скомпрометированного ключа

Ключ — это секретный код или число, используемые для шифрования, расшифровки или проверки секретных сведений. В инфраструктуре открытого ключа (PKI) есть два чувствительных ключа: закрытый ключ, который имеет каждый владелец сертификата, и ключ сеанса, который используется после успешного обмена идентификационными данными и сеансом партнерами обмена. Атака с использованием скомпрометированного ключа происходит, когда злоумышленнику удается получить закрытый ключ или ключ сеанса. После этого он может использовать полученный ключ для расшифровки зашифрованных данных без ведома отправителя.

Skype для бизнеса В Online для защиты ключевых данных, используемых для шифрования подключений TLS, используются функции PKI в операционной системе Windows Server. Ключи, используемые для шифрования, передаются по подключениям TLS.

Атака на сеть типа "отказ в обслуживании"

Атака типа "отказ в обслуживании" осуществляются, когда злоумышленник препятствует нормальной работе сети и ее использованию проверенными пользователями. С помощью атаки типа "отказ в обслуживании" злоумышленник может выполнять следующее:

  • Отправка недействительных данных приложениям и службам, работающим в атакуемой сети, для нарушения их нормальной работы.
  • Отправка больших объемов трафика, перегружающего систему, пока она не прекратит реагировать на нормальные запросы либо время реакции не замедлится.
  • Сокрытие следов атаки.
  • Нарушение доступа пользователей к ресурсам сети.

SfBO устраняет эти атаки за счет запуска защиты сети Azure DDOS и регулирования клиентских запросов от тех же конечных точек, подсетей и федеративных организаций.

Прослушивание

Прослушивание осуществляется, когда злоумышленнику удается получить доступ к каналам передачи данных в сети с возможностью контролировать и просматривать трафик. Такой тип атаки также называется сканированием или слежением. Если трафик передается в виде обычного текста, злоумышленник может прочитать его, получив доступ к каналу обмена данными. Примером такой атаки является контроль маршрутизатора в составе такого канала.

SfBO использует общие TLS (MTLS) для взаимодействия между серверами в Microsoft 365 или Office 365 и TLS из клиентов в службу, из-за чего эту атаки очень трудно было бы достичь в течение периода, в течение которого могла быть совершена атака на данную беседу. TLS проверяет подлинность всех участников и шифрует весь трафик. Это не защищает от прослушивания, однако злоумышленнику не удастся прочитать передаваемые данные, если только он не взломает систему шифрования.

Протокол TURN используется для целей мультимедиа в реальном времени. Протокол TURN не требует шифрования трафика, и отправляемая с его использованием информация защищается посредством контроля целостности сообщений. Хотя этот протокол открыт для прослушивания, передаваемые по нему данные (IP-адреса и порт) можно получить непосредственно путем простого анализа исходного и конечного адресов пакета. Служба SfBO гарантирует, что данные действительны, проверив целостность сообщения с помощью ключа, полученного из нескольких элементов, включая пароль TURN, который никогда не отправляется в виде четкого текста. SRTP используется для медиа-трафика и также зашифрован.

Подделка удостоверения (спуфинг IP-адреса)

Спуфинг происходит, когда злоумышленнику удается несанкционированно определить IP-адрес сети, компьютера или элемента сети. Успешная атака позволяет злоумышленнику действовать от имени обычного участника, определенного по IP-адресу. В контексте Microsoft Lync Server 2010 эта ситуация возникает только в том случае, если администратор сделал следующее:

  • Настроил подключения, поддерживающие только протокол TCP (делать этого не рекомендуется, так как данные, передаваемые по протоколу TCP, не шифруются).
  • Отметил IP-адреса участников таких подключений как надежные узлы.

Эта проблема менее актуальна для подключений по протоколу TLS, так как при обмене данными по этому протоколу производится проверка подлинности всех участников и шифрование всей информации. Использование TLS не позволяет злоумышленнику выполнить IP-спуфинг для определенного подключения (например, для соединений, оба участника которых работают по этому протоколу). Однако злоумышленник все равно может подовать адрес DNS-сервера, который использует SfBO. Однако поскольку проверка подлинности в SfBO выполняется с помощью сертификатов, злоумышленник не имеет действующего сертификата, необходимого для подменить одну из сторон сообщения.

Атака "злоумышленник в середине"

Атака типа "злоумышленник в середине" происходит, когда злоумышленнику удается перенаправить данные, которыми обмениваются два пользователя, через свой компьютер без ведома этих пользователей. В результате злоумышленник получает возможность контролировать и просматривать трафик перед его отправкой предполагаемому получателю. Каждый из участников обмена данными на самом деле обменивается трафиком со злоумышленником, думая при этом, что информация передается второму пользователю. Такая ситуация может возникнуть, если злоумышленнику удается внести изменения в доменные службы Active Directory и добавить свой сервер в качестве доверенного либо изменить систему доменных имен (DNS) таким образом, чтобы клиенты подключались к серверу через компьютер злоумышленника.

Атака "злоумышленник в середине" также может возникать при использовании медиа-трафика между двумя клиентами, за исключением того, что в потоках аудио, видео и приложений совместного доступа SfBO шифруются с помощью SRTP, используя криптографические ключи, которые согласовываются между одноранговыми участниками используя протокол инициирования сеанса (SIP) через TLS.

Атака с повторением RTP

Атака с повторением осуществляется, когда действительная передача мультимедиа между двумя участниками перехватывается и повторно передается со злонамеренными целями. SfBO использует протокол SRTP в сочетании с защищенным сигнальным протоколом, который защищает передачу от воспроизведения атак, позволяя приемнику поддерживать индекс уже полученных пакетов RTP и сравнивать каждый новый пакет с теми, которые уже указаны в индексе.

Нежелательные мгновенные сообщения

Нежелательные мгновенные сообщения — это нежелательные мгновенные сообщения коммерческого характера либо запросы подписки на сведения о присутствии. Хотя такие сообщения сами по себе не нарушают безопасность сети, они как минимум раздражают пользователей, ухудшают их доступность и производительность и в перспективе могут привести к нарушению сетевой безопасности. Примером является отправка пользователями нежелательных запросов друг другу. Чтобы избавиться от таких запросов, пользователи могут блокировать друг друга, однако защититься от скоординированной атаки нежелательными мгновенными сообщениями в федеративной среде сложно без отключения федерации партнера.

Вирусы и черви

Вирус — это часть кода, предназначенная для воспроизведения дополнительных похожих фрагментов кода. Для работы вирусу требуется носитель, например файл, электронная почта или программа. Подобно вирусу, вирус-червь представляет собой единицу кода, которая кодируется для воспроизведения дополнительных похожих единиц кода, но в отличие от вируса не требуется основного приложения. Вирусы и черви в основном появляются при обмене файлами между клиентами, а также при получении URL-адресов от других пользователей. Если вирус находится на компьютере, он может, например, использовать идентификационные данные хозяина для отправки мгновенных сообщений от его имени. Стандартные рекомендации по безопасности клиентов, такие как периодическое сканирование вирусов, могут уменьшить эту проблему.

Личные сведения

SfBO может раскрыть информацию по открытой сети, которая может быть связана с отдельным лицом. Сведения можно отнести к двум категориям.

  • Расширенные данные о присутствии       Расширенные сведения о присутствии — это сведения, которые пользователь может делиться (или не делиться) по ссылке федераированному партнеру или контактам в организации. Эти данные не передаются пользователям в общедоступной сети обмена мгновенными сообщениями. Администратор может в определенной мере контролировать доступ к такой информации с помощью политик и других настроек клиентов. В службе SfBO можно настроить расширенный режим конфиденциальности присутствия для отдельного пользователя, чтобы запретить пользователям SfBO, которые не в списке контактов этого пользователя, видеть сведения о присутствии пользователя.
  • Mandatory data   Обязательные данные - это данные, необходимые для правильной работы сервера или клиента. Это сведения, которые необходимы на уровне сервера или сети для осуществления маршрутизации, поддержки состояния и передачи сигналов. В следующих таблицах перечислены данные, необходимые для работы SfBO.

Таблица 1 - Расширенные данные присутствия

Данные Возможные настройки
Личные данные Имя, должность, компания, адрес электронной почты, часовой пояс
Номера телефонов Рабочий, мобильный, домашний
Данные календаря Уведомление о доступности, уведомление о вне городе, сведения о собрании (для тех, у кого есть доступ к вашему календарю)
Состояние присутствия Отсутствует, доступен, занят, не беспокоить, не в сети

Таблица 2. Обязательные данные

Категория Возможные параметры
IP-адрес Фактический адрес компьютера или адрес NAT
Универсальный код ресурса SIP david.campbell@contoso.com
Имя Дмитрий (в доменных службах Active Directory)

Структура безопасности для SfBO

В этом разделе представлен обзор основных элементов, которые образуют структуру безопасности Microsoft SfBO. Ниже представлены эти элементы.

  • Azure Active Directory (AAD) предоставляет единый надежный репозиторий для пользовательских учетных записей.
  • Инфраструктура PKI использует сертификаты, выданные доверенными центрами сертификации (CAS), для проверки подлинности серверов и обеспечения целостности данных.
  • Безопасность на транспортном уровне (TLS), передача HTTPS по SSL (HTTPS) и взаимные подключения по протоколу TLS (MTLS) позволяют выполнять проверку подлинности конечной точки и шифровать обмен мгновенными сообщениями. Потоки одноранговых сеансов обмена аудио- и видеоданными и общего доступа к приложениям шифруются и проверяются на целостность с использованием протокола SRTP.
  • Протоколы отраслевых стандартов для проверки подлинности пользователя (по мере возможности).

В этом разделе описано, как работает каждый из этих базовых элементов для повышения безопасности службы SfBO.

Azure Active Directory

Azure Active Directory функционирует как служба каталогов для Microsoft 365 и Office 365. В ней хранятся все сведения каталога пользователей и назначения политик.

Инфраструктура открытого ключа для SfBO

Служба SfBO использует сертификаты для проверки подлинности сервера и создает цепочку доверия между клиентами и серверами, а также между различными ролями сервера. Инфраструктура открытого ключа Windows Server (PKI) предоставляет инфраструктуру для установления и проверки этой цепи доверия. Сертификаты представляют собой цифровые идентификаторы. Они определяют сервер по имени и указывают его свойства. Чтобы убедиться в том, что сведения о сертификате действительны, сертификат должен быть выдан доверенным клиентом или другим сервером, который подключается к серверу. Если сервер подключается только к другим клиентам и серверам в частной сети, ЦС может являться корпоративным ЦС. Если сервер взаимодействует с объектами за пределами частной сети, может потребоваться общедоступный ЦС.

Даже при условии действительности сведений сертификата необходим способ проверки того, что представляющий сертификат сервер фактически является тем, который представлен сертификатом. Именно в этом случае используется Windows PKI. Каждый сертификат связан с открытым ключом. Сервер, который указан в сертификате, содержит соответствующий известный только ему закрытый ключ. Подключаемый клиент или сервер использует открытый ключ для шифрования произвольной части сведений и отправляет его на сервер. Если сервер расшифровывает эти сведения и возвращает их в виде обычного текста, подключаемый объект может быть уверен в том, что сервер содержит закрытый ключ для сертификата и, следовательно, является указанным в сертификате сервером.

Точки распространения CRL

Для SfBO требуется, чтобы все сертификаты сервера содержали одну или несколько точек распространения списка отзыва сертификатов (CRL). Точки распространения списка отзыва сертификатов (CDP) представляют собой местоположения, из которых можно загрузить CRL для проверки того, что сертификат не был отозван с момента выдачи и его срок действия не истек. Точка распространения списка отзыва сертификатов CRL указывается в свойствах сертификата в виде URL-адреса и является безопасным протоколом HTTP. Служба SfBO проверяет CRL с каждой проверкой подлинности сервера сертификата.

Расширенное использование ключа

Все компоненты службы SfBO требуют, чтобы все сертификаты сервера поддерживали расширенное использование ключа (EKU) для проверки подлинности сервера. Настройка поля EKU для проверки подлинности сервера означает, что сертификат действителен для проверки подлинности сервера. Использование EKU важно для MTLS.

TLS и MTLS для SfBO

Протоколы TLS и MTLS обеспечивают зашифрованный обмен данными и проверку подлинности конечной точки в Интернете. SfBO использует эти два протокола для создания сети надежных серверов и обеспечения шифрования всех сообщений по этой сети. Весь обмен данными по протоколу SIP между серверами происходит по протоколу MTLS. Обмен данными по протоколу SIP от клиента к серверу выполняется по протоколу TLS.

TLS позволяет пользователям с помощью клиентского программного обеспечения проходить проверку подлинности серверов SfBO, к которым они подключаются. При подключении по протоколу TLS клиент запрашивает от сервера действительный сертификат. Чтобы сертификат был действительным, он должен быть выдан ЦС, который также является доверенным объектом клиента, а имя DNS должно соответствовать имени сертификата. Если сертификат действительный, клиент использует открытый ключ в сертификате для шифрования симметричных ключей шифрования, которые будут использоваться для обмена данными, поэтому только исходный владелец сертификата может использовать закрытый ключ для шифрования содержимого сеанса обмена данными. Результатом является доверенное подключение, которое после этого уже не проверяется другими доверенными серверами или клиентами. В рамках этого контекста протокол SSL, используемый веб-службами, может быть связан как протокол на базе TLS.

Соединения между серверами основаны на взаимном TLS (MTLS) для взаимной проверки подлинности. В подключениях по протоколу MTLS создавший сообщение сервер и сервер, который получает его, обмениваются сертификатами из ЦС со взаимным доверием. Сертификаты подтверждают идентичность каждого из серверов с другим. В службе SfBO, выполняется следующая процедура.

TLS и MTLS помогают предотвратить как перехватывание, так и атаки "злоумышленник в середине". В атаке "злоумышленник в середине" злоумышленник перенаправляет связь между двумя сетевыми объектами через компьютер злоумышленника без ведома любой из сторон. Спецификация TLS и SfBO доверенных серверов снижает риск атаки "злоумышленник в середине" частично на уровне приложения, используя сквозное шифрование, скоординированное с использованием криптографии с открытым ключом между двумя конечными точками, и злоумышленник должен будет иметь действительный и доверенный сертификат с соответствующим закрытым ключом и выданный от имени службы, которой клиент сообщает о дешифровании сообщения.

Шифрование для SfBO

SfBO использует TLS и MTLS для шифрования мгновенных сообщений. Для трафика от сервера к серверу требуется MTLS, независимо от того, ограничивается ли трафик внутренней сетью или пересекает внутренний периметр сети.

В следующей таблице представлен протокол, используемый SfBO.

Таблица 3 - Защита трафика

Тип трафика Защита
Сервер-сервер MTLS
Клиент-сервер TLS
Мгновенные сообщения и присутствие TLS (если настроено для TLS)
Аудио/видео и рабочий стол для общего доступа к мультимедиа SRTP
Общий доступ к рабочему столу (передача сигналов) TLS
веб-конференции TLS
Загрузка содержимого собрания, загрузка адресной книги, расширение группы рассылки HTTPS

Шифрование мультимедиа

Трафик мультимедиа шифруется по протоколу SRTP, профилю протокола RTP, который обеспечивает конфиденциальность, проверку подлинности и защиту от атак с повторением пакетов для трафика RTP. SRTP использует ключ сеанса, сгенерированный с использованием защищенного генератора случайных чисел и обмениваемый с использованием канала TLS сигнализации. Кроме того, потоки мультимедиа в обоих направлениях между сервером-посредником и его внутренним узлом следующего прыжка также шифруются с помощью SRTP.

SfBO генерирует имя пользователя/пароли для безопасного доступа к мультимедийным реле через TURN. Мультимедийное реле обмениваются именем пользователя/паролем через SIP-канал с поддержкой TLS.

FIPS

SfBO использует алгоритмы FIPS (Federal Information Processing Standard) для обмена ключами шифрования.

Проверка подлинности пользователей и клиентов

Доверенным пользователем является пользователь, учетные данные которого были проверки подлинности AAD в Microsoft 365 или Office 365.

Проверка подлинности представляет собой предоставление учетных данных пользователя доверенному серверу или службе. В зависимости от состояния и расположения пользователя SfBO использует следующие протоколы проверки подлинности:

  • Современная проверка подлинности является реализацией Microsoft OAUTH 2.0 для взаимодействия клиента с сервером. Он включает такие функции безопасности, как проверка подлинности на основе сертификатов, многофакторная проверка подлинности и условный доступ. Чтобы использовать MA, для онлайн-арендатора и клиентов необходимо включить MA. У арендаторов SfBO, созданных после мая 2017 года, MA включен по умолчанию. Для арендаторов, созданных до этого времени, следуйте инструкциям здесь, чтобы включить его. Следующие клиенты поддерживают MA: Skype для бизнеса 2015 или 2016, Skype для бизнеса on Mac, Lync 2013 client, IP-телефоны 3PIP, iOS и Android.
  • ИД организации используется, если современная проверка подлинности не включена (или недоступна).
  • Дайджест-проверка для так называемых анонимных пользователей. Анонимные пользователи — это внешние пользователи, которые не имеют распознанных учетных данных Active Directory, но были приглашены в локальную конференцию и обладают действительным ключом конференции. Дайджест-проверка подлинности не используется для других клиентских взаимодействий.

Проверка подлинности SfBO состоит из двух этапов:

  1. Между клиентом и сервером устанавливается сопоставление безопасности.
  2. Клиент и сервер используют существующее сопоставление безопасности для подписи сообщений, которые они отправляют, и для проверки получения сообщений. Не прошедшие проверку подлинности сообщения от клиента не принимаются при включенной на сервере проверке подлинности.

Доверие пользователя прикрепляется к каждому сообщению, которое исходит от пользователя, но не к удостоверению пользователя. Сервер проверяет каждое сообщение на наличие действительных учетных данных пользователя. Если учетные данные пользователя действительны, сообщение не является нежелательным не только первым сервером, который его получает, но и всеми другими серверами sfBO.

Пользователи с действительными выданными федеративным партнером учетными данными являются доверенными, но к ним могут применяться другие ограничения привилегий, которые полностью доступны внутренним пользователям.

Для проверки подлинности файлов мультимедиа протоколы ICE и TURN также используют требование Digest, описанное в документе IETF TURN RFC. Подробные сведения см. в области обхода мультимедиа.

Клиентские сертификаты предоставляют пользователям альтернативный способ проверки подлинности с помощью SfBO. Вместо предоставления имени пользователя и пароля пользователи имеют сертификат и закрытый ключ, соответствующий необходимому для решения криптографической задачи сертификату.

Средства управления Windows PowerShell и SfBO

В SfBO ИТ-администраторы могут управлять своим сервисом через портал администратора O365 или с помощью Tenant Remote PowerShell (TRPS). Для проверки подлинности в TRPS администраторы клиента используют современную проверку подлинности.

Настройка доступа к SfBO на границе вашего интернета

Чтобы функция SfBO правильно работает (пользователи могут присоединяться к собраниям и т. д.), клиентам необходимо настроить доступ к Интернету таким образом, чтобы в службы в облаке SfBO разрешен исходящие трафики UDP и TCP. Дополнительные сведения см. здесь: https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo

UDP 3478-3481 и TCP 443

Порты UDP 3478-3481 и TCP 443 используются клиентами для запроса службы из службы A/V Edge. Клиент использует эти два порта для распределения портов UDP и TCP соответственно для удаленной стороны для подключения. Для доступа к службе A/V Edge клиент должен сначала установить сеанс проверки подлинности SIP с регистратором SfBO, чтобы получить учетные данные проверки подлинности службы A/V Edge. Эти значения отправляются по сигнальному каналу, защищенному TLS, и генерируются компьютером для уменьшения рисков атак перебором по словарю. Затем клиенты могут использовать эти учетные данные для аутентификации дайджеста с помощью службы A/V Edge для распределения портов для использования в сеансе мультимедиа. Первоначальный запрос на распределение отправляется от клиента и отвечает сообщением 401 nonce/challenge от службы A/V Edge. Клиент отправляет второй запрос на распределение, содержащий имя пользователя, и хэш сообщение кода проверки подлинности (HMAC) хэш-имени пользователя и nonce.

Для предотвращения повторных атак используется механизм последовательности номеров. Сервер вычисляет ожидаемый HMAC на основе собственных знаний о имени пользователя и пароле, и если значения HMAC совпадают, выполняется процедура распределения. В противном случае пакет будет удален. Этот же механизм HMAC также применяется к последующим сообщениям в рамках этого сеанса вызова. Срок действия этого имени пользователя/пароля составляет не более восьми часов, после чего клиент повторно запрашивает новое имя пользователя/пароль для последующих вызовов.

UDP/TCP 50 000–59 999

Исходный протокол TCP 50 000 используется для SfBO, в том числе для совместного использования приложений и компьютеров, передачи файлов. Диапазоны портов UDP/TCP 50 000-59 999 используются для сеансов мультимедиа с партнерами Microsoft Office Communications Server 2007, которым требуется служба обхода NAT/брандмауэра из службы A/V Edge. Поскольку служба A/V Edge является единственным процессом, использующим эти порты, размер диапазона портов не указывает на потенциальную поверхность атаки. Хорошая практика безопасности заключается в том, чтобы всегда минимизировать общее количество прослушивающих портов, не запуская ненужных сетевых сервисов. Если сетевая услуга не запущена, она не может быть использована удаленным злоумышленником, а поверхность атаки главного компьютера будет уменьшена. Однако, в рамках единой службы, сокращение количества портов не дает такой же выгоды. Программное обеспечение сервисного обслуживания A/V Edge больше не подвергается атаке, при этом 10 000 портов открыты, как и в случае с 10. Выделение портов в этом диапазоне выполняется произвольно, а порты, которые в настоящее время не выделены, не прослушивают пакеты.

Обход A/V трафика по внешнему пользователю

Для включения внешних пользователей и внутренних пользователей для обмена носителями требуется служба Access Edge для обработки сигнализации SIP, необходимой для настройки и срыва сеанса. Он также требует, чтобы служба A/V Edge выступала в качестве реле для передачи мультимедиа. Последовательность вызовов показана на следующем рисунке.

Последовательность вызовов в Meeting Join

  1. Пользователь получает электронное письмо с приглашением присоединиться к собранию SfBO. В электронном письме содержится ключ конференции и URL-адрес, основанный на HTTP и ссылaющийся на конференцию. И ключ, и URL-адрес уникальны для конкретного собрания.

    Пользователь инициирует процедуру соединения, щелкнув URL-адрес собрания в письме, которое инициирует процесс обнаружения клиента на машине пользователя. Если клиент обнаружен, этот клиент запускается. Если он не обнаружен, пользователь перенаправляется на веб-клиент.

  2. Клиент SfBO отправляет SIP INVITE, содержащий учетные данные пользователя. Федераированный или удаленный пользователь присоединяется к конференции, используя корпоративные учетные данные. Для федеративного пользователя SIP INVITE сначала отправляется на его или ее домашний сервер, который проверяет подлинность пользователя и перенаправляет INVITE на SfBO. Анонимный пользователь должен пройти проверку подлинности дайджеста.

    SfBO проверяет подлинность удаленного или анонимного пользователя и уведомляет клиента. Как упомянуто в шаге 2, федеративные пользователи, присоединяющиеся к конференции, аутентифицируются своим предприятием.

  3. Клиент отправляет запрос INFO для добавления пользователя на конференцию A/V.

    Конференции A/V отправляют ответ Add User (Добавить пользователя), содержащий маркер, который будет представляться в edge-службе A/V Conferencing, а также другие сведения.

    [Примечание] Весь предыдущий трафик SIP проходит через службу Access Edge.

    Клиент подключается к серверу конференций A/V, который проверяет маркер и проксирует запрос, который содержит другой маркер авторизации, на внутренний сервер конференций A/V Сервер конференций A/V Conferencing Server проверяет маркер авторизации, который он изначально выдал по каналу SIP, чтобы гарантировать, что действительный пользователь присоединится к конференции.

  4. Между клиентом и сервером A/V Conferencing Server на сервере SRTP заключено и настроено подключение к мультимедиа.

  5. Пользователь получает электронное письмо с приглашением присоединиться к собранию SfBO. В электронном письме содержится ключ конференции и URL-адрес, основанный на HTTP и ссылaющийся на конференцию. И ключ, и URL-адрес уникальны для конкретного собрания.

Защита федерации для SfBO

Федерация предоставляет вашей организации возможность общаться с другими организациями для обмена мгновенными сообщениями и присутствием. В SfBO федерация включена по умолчанию. Однако администраторы клиентов могут управлять этим с помощью Microsoft 365 или Администратор Office 365 портала. См. больше.

Устранение угроз в конференциях SfBO

SfBO предоставляет возможность корпоративным пользователям создавать и присоединяться к веб-конференциям в режиме реального времени. Enterprise пользователи также могут приглашать внешних пользователей, у которых нет учетной записи AAD, Microsoft 365 или Office 365 участвовать в этих собраниях. Пользователи, нанятые федеративными партнерами с надежной и аутентифицированной личностью, также могут участвовать в собраниях и, если они будут повышены уровнем, могут выступать в качестве докладчиков. Анонимные пользователи не могут создавать или присоединяться к собранию в качестве докладчика, но после того, как они присоединяются, они могут быть повышены уровнем в качестве докладчиков.

Включение внешних пользователей для участия в собраниях SfBO значительно увеличивает ценность этой функции, но также влечет за собой некоторые риски для безопасности. Чтобы устранить эти риски, SfBO предоставляет следующие дополнительные гарантии:

  • Роли участников определяют права на управление конференцией.
  • Типы участников позволяют ограничить доступ к определенным собраниям.
  • Определенные типы собраний определяют, какие типы участников могут принимать участие.
  • Планирование конференции ограничено пользователями, имеющими учетную запись AAD и лицензию SfBO.
  • Анонимные пользователи, которые хотят присоединиться к конференции с телефонным присоединением, набрать один из номеров доступа к конференции, а затем им будет предложено ввести ее ИД. Неавторизованным (не прошедшим проверку подлинности) анонимным пользователям также предлагается записать свое имя. Записанные имена идентифицируют неавторизованных пользователей в конференции. Анонимные пользователи не допускаются в конференцию, пока к ней не присоединится хотя бы один авторизованный пользователь или ведущий, и анонимным пользователям нельзя назначать предопределенную роль.

Роли участников

Участники собраний разделяются на три группы с собственными правами и ограничениями:

  •   Организатор   Пользователь, создавший собрание (импровизированный или запланированный). Организатор должен быть корпоративным пользователем, пройти проверку подлинности и иметь контроль над всеми аспектами собрания.
  • Presenter (Presenter)     Пользователь, которому разрешено представлять информацию на собрании, используя все поддерживаемые мультимедиа. Организатор собрания по определению также является докладчиком и определяет, кто еще может быть докладчиком. Организатор может принимать это решении при планировании собрания или при его проведении.
  •   Участник   Пользователь, который приглашен на собрание, но не имеет права выступать.

Докладчик также может перевести участника в роль докладчика во время собрания.

Типы участников

Участники собрания также классифицируются по местоположению и учетным данным. Вы можете использовать обе эти характеристики, чтобы указать, какие пользователи могут иметь доступ к конкретным собраниям. Пользователей в общем смысле можно разделить на несколько категорий:

  1. Пользователи, в которые входит клиент     У этих пользователей есть учетные данные Azure Active Directory клиента.
    а) Inside corpnet — эти пользователи присоединяются из корпоративной сети.
    б) Удаленные пользователи. Эти пользователи присоединяются из-за пределов корпоративной сети. К ним относятся сотрудники, которые работают дома или в дороге, и другие, например, сотрудники доверенных поставщиков, которым были предоставлены полномочия предприятия на их условиях обслуживания. Удаленные пользователи могут создавать и присоединяться к конференциям и выступать в качестве докладчиков.
  2. Пользователи, принадлежащие арендатору  Эти пользователи имеют учетные данные в Azure Active Directory для арендатора.
    а) Федераированные пользователи. Федераированные пользователи обладают действительными учетными данными федерательных партнеров, поэтому они обрабатываются SfBO как аутентификация. Федеративные пользователи могут участвовать в конференциях и быть повышены уровнем в качестве докладчиков после того, как они присоединились к совещанию, но они не могут создавать конференции на предприятиях, с которыми они объединены.
    б) Анонимные пользователи. У анонимных пользователей нет удостоверения Active Directory, и они не объединены в федерацию с клиентом.

Данные клиента показывают, что во многих конференциях вовлечены внешние пользователи. Те же клиенты также хотят получить подтверждение об удостоверении внешних пользователей, прежде чем позволить этим пользователям присоединиться к конференции. Как описано в следующем разделе, SfBO ограничивает доступ тем пользовательским типам, которые были явно разрешены, и требует, чтобы все типы пользователей представляли соответствующие учетные данные при входе в совещание.

Прием участника

В SfBO анонимные пользователи переносятся в зону ожидания, называемую "зал ожидания". Затем участники могут либо допустить этих пользователей на совещание, либо отклонить их. Эти пользователи переносятся в "зал ожидания", лидер уведомляется, и затем пользователи ждут, пока лидер либо примет, либо отклонит их, либо их время соединения истечёт. Тем временем в"зале ожидания" пользователи слышат музыку.

По умолчанию участники, набирающие номер из PSTN, отправляются непосредственно на совещание, но этот параметр можно изменить, чтобы заставить участников набора номера перейти в "зал ожидания".
Организаторы совещания контролируют, могут ли участники присоединиться к совещанию, не ожидая в "зале ожидания". Каждое совещание может быть настроено для обеспечения доступа с использованием любого из следующих способов:

  • Только я, организатор совещания  Все, кроме организатора, должны ожидать в "зале ожидания" до тех пор, пока не будут допущены.
  • Людей, которых я приглашаю из своей компании  Любой человек из вашей компании может напрямую попасть на совещание, даже если его не пригласят.
  • Все, кто из моей организации     Все пользователи SfBO в клиенте Microsoft 365 или Office 365 могут присоединиться к собранию, не дожидаясь в зале ожидания, даже если пользователей нет в списке рассылки. Все остальные, включая всех внешних и анонимных пользователей, должны ожидать в "зале ожидания" до тех пор, пока не будут допущены.
  •   Все   Любой человек (нет ограничений), у которого есть доступ к ссылке на собрание, попадает в собрание напрямую. Если указан какой-либо метод, кроме Организатора (заблокирован), организатор совещания также может указать, что люди набирают номер по телефону в обход "зала ожидания".

Возможности докладчика

Организаторы собраний контролируют, могут ли участники демонстрировать сведения во время собрания. Каждое собрание может быть настроено на ограничение докладчиков одним из следующих способов:

  • Только организатор     Вы можете представить только организатор собрания.
  • Люди из моей компании     Все внутренние пользователи могут высмеять.
  • Все, включая людей за пределами организации     Выступать могут все (нет ограничений), которые присоединяются к собранию.
  • Люди, которых я выбираю  Организатор совещания определяет, какие пользователи могут присутствовать, добавив их в список докладчиков.

Центр управления безопасностью (Майкрософт)