Безопасность и Skype для бизнеса в Сети
Важно!
Skype для бизнеса Online, эксплуатируемый компанией 21Vianet в Китае, будет прекращен 1 октября 2023 года. Если вы еще не обновили пользователей Skype для бизнеса Online, они будут автоматически запланированы для вспомогательного обновления. Если вы хотите обновить организацию до Teams самостоятельно, настоятельно рекомендуется начать планирование пути обновления уже сегодня. Помните, что успешное обновление соответствует технической готовности и готовности пользователей, поэтому обязательно используйте наше руководство по обновлению при переходе в Teams.
Skype для бизнеса Online, за исключением службы 21Vianet в Китае, была прекращена 31 июля 2021 года.
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, протокол Real-Time SRTP и другие стандартные отраслевые методы шифрования, включая 256-разрядное шифрование AES, все данные Skype для бизнеса Online защищаются в сети.
Как SfBO обрабатывает общие угрозы безопасности
В этом разделе описываются наиболее распространенные угрозы безопасности службы SfBO и способы устранения каждой угрозы корпорацией Майкрософт.
Атака с использованием скомпрометированного ключа
Ключ — это секретный код или число, используемые для шифрования, расшифровки или проверки секретных сведений. В инфраструктуре открытого ключа (PKI) есть два чувствительных ключа: закрытый ключ, который имеет каждый владелец сертификата, и ключ сеанса, который используется после успешного обмена идентификационными данными и сеансом партнерами обмена. Атака с использованием скомпрометированного ключа происходит, когда злоумышленнику удается получить закрытый ключ или ключ сеанса. После этого он может использовать полученный ключ для расшифровки зашифрованных данных без ведома отправителя.
Skype для бизнеса Online использует функции PKI в операционной системе Windows Server для защиты ключевых данных, используемых для шифрования подключений TLS. Ключи, используемые для шифрования, передаются по подключениям TLS.
Атака на сеть типа "отказ в обслуживании"
Атака типа "отказ в обслуживании" осуществляются, когда злоумышленник препятствует нормальной работе сети и ее использованию проверенными пользователями. С помощью атаки типа "отказ в обслуживании" злоумышленник может выполнять следующее:
- Отправка недействительных данных приложениям и службам, работающим в атакуемой сети, для нарушения их нормальной работы.
- Отправка больших объемов трафика, перегружающего систему, пока она не прекратит реагировать на нормальные запросы либо время реакции не замедлится.
- Сокрытие следов атаки.
- Нарушение доступа пользователей к ресурсам сети.
SfBO устраняет эти атаки, запустив защиту сети DDOS Azure и регулив клиентские запросы из одних и того же конечных точек, подсетей и федеративных сущностей.
Прослушивание
Прослушивание осуществляется, когда злоумышленнику удается получить доступ к каналам передачи данных в сети с возможностью контролировать и просматривать трафик. Такой тип атаки также называется сканированием или слежением. Если трафик передается в виде обычного текста, злоумышленник может прочитать его, получив доступ к каналу обмена данными. Примером такой атаки является контроль маршрутизатора в составе такого канала.
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, не указанным в списке контактов пользователя, просматривать сведения о присутствии пользователя.
- Обязательные данные Обязательные данные — это данные, необходимые для правильной работы сервера или клиента. Это сведения, которые необходимы на уровне сервера или сети для осуществления маршрутизации, поддержки состояния и передачи сигналов. В следующих таблицах перечислены данные, необходимые для работы SfBO.
Таблица 1 - Расширенные данные присутствия
| Данные | Возможные параметры |
|---|---|
| Личные данные | Имя, название, компания, адрес Email, часовой пояс |
| Номера телефонов | Рабочий, мобильный, домашний |
| Данные календаря | "Свободная или занятая", уведомление о загороде, сведения о собрании (для тех, кто имеет доступ к вашему календарю) |
| Состояние присутствия | Прочь, Доступно, Занят, Не беспокоить, Вне сети |
Таблица 2. Обязательные данные
| Данные | Возможные параметры |
|---|---|
| IP-адрес | Фактический адрес компьютера или адрес NAT |
| Универсальный код ресурса SIP | david.campbell@contoso.com |
| Имя | Дэвид Кэмпбелл (как определено в доменные службы Active Directory) |
Платформа безопасности для SfBO
В этом разделе представлен обзор основных элементов, формируемых платформой безопасности для Microsoft SfBO. Ниже представлены эти элементы.
- Microsoft Entra ID предоставляет единый доверенный внутренний репозиторий для учетных записей пользователей.
- Инфраструктура открытых ключей (PKI) использует сертификаты, выданные доверенными центрами сертификации (ЦС) для проверки подлинности серверов и обеспечения целостности данных.
- Безопасность на транспортном уровне (TLS), передача HTTPS по SSL (HTTPS) и взаимные подключения по протоколу TLS (MTLS) позволяют выполнять проверку подлинности конечной точки и шифровать обмен мгновенными сообщениями. Потоки одноранговых сеансов обмена аудио- и видеоданными и общего доступа к приложениям шифруются и проверяются на целостность с использованием протокола SRTP.
- Протоколы отраслевых стандартов для проверки подлинности пользователя (по мере возможности).
В статьях этого раздела описывается, как каждый из этих основных элементов работает для повышения безопасности службы SfBO.
Microsoft Entra ID
Microsoft Entra ID работает как служба каталогов для 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.
Соединения между серверами основаны на протоколе Mutual 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) для обмена ключами шифрования.
Проверка подлинности пользователей и клиентов
Доверенным пользователем является пользователь, учетные данные которого прошли проверку подлинности Microsoft Entra ID в 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 состоит из двух этапов:
- Между клиентом и сервером устанавливается сопоставление безопасности.
- Клиент и сервер используют существующее сопоставление безопасности для подписи сообщений, которые они отправляют, и для проверки получения сообщений. Если на сервере включена проверка подлинности, сообщения, не прошли проверку подлинности от клиента, не принимаются.
Доверие пользователя прикрепляется к каждому сообщению, которое исходит от пользователя, но не к удостоверению пользователя. Сервер проверяет каждое сообщение на наличие действительных учетных данных пользователя. Если учетные данные пользователя действительны, сообщение не вызывает опечаток не только первым сервером, который его получит, но и всеми остальными серверами в SfBO.
Пользователи с действительными выданными федеративным партнером учетными данными являются доверенными, но к ним могут применяться другие ограничения привилегий, которые полностью доступны внутренним пользователям.
Для проверки подлинности файлов мультимедиа протоколы ICE и TURN также используют требование Digest, описанное в документе IETF TURN RFC. Дополнительные сведения см. в разделе Обход мультимедиа.
Сертификаты клиента предоставляют альтернативный способ проверки подлинности пользователей с помощью SfBO. Вместо предоставления имени пользователя и пароля пользователи имеют сертификат и закрытый ключ, соответствующий необходимому для решения криптографической задачи сертификату.
Средства управления Windows PowerShell и SfBO
В SfBO ИТ-администраторы могут управлять своим сервисом через портал администратора O365 или с помощью Tenant Remote PowerShell (TRPS). Для проверки подлинности в TRPS администраторы клиента используют современную проверку подлинности.
Настройка доступа к SfBO на границе вашего интернета
Для правильной работы SfBO (пользователи могут присоединяться к собраниям и т. д.), клиенты должны настроить доступ к Интернету таким образом, чтобы разрешить исходящий трафик UDP и TCP к службам в облаке SfBO. Дополнительные сведения см. здесь: 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, клиент сначала должен установить сеанс передачи сигналов SIP, прошедший проверку подлинности, с регистратором SfBO, чтобы получить учетные данные проверки подлинности пограничной службы A/V. Эти значения отправляются по сигнальному каналу, защищенному 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 выступала в качестве реле для передачи мультимедиа. Последовательность вызовов показана на следующем рисунке.
Пользователь получает электронное письмо с приглашением присоединиться к собранию SfBO. В электронном письме содержится ключ конференции и URL-адрес, основанный на HTTP и ссылaющийся на конференцию. И ключ, и URL-адрес уникальны для конкретного собрания.
Пользователь инициирует процедуру присоединения, щелкнув URL-адрес собрания в сообщении электронной почты, что инициирует процесс обнаружения клиента на компьютере пользователя. Если клиент обнаружен, этот клиент запускается. Если он не обнаружен, пользователь перенаправляется на веб-клиент.
Клиент SfBO отправляет SIP INVITE, содержащий учетные данные пользователя. Федеративный или удаленный пользователь присоединяется к конференции, используя корпоративные учетные данные. Для федеративного пользователя SIP INVITE сначала отправляется на его или ее домашний сервер, который проверяет подлинность пользователя и перенаправляет INVITE на SfBO. Анонимный пользователь должен пройти проверку подлинности дайджеста.
SfBO проверяет подлинность удаленного или анонимного пользователя и уведомляет клиента. Как упомянуто в шаге 2, федеративные пользователи, присоединяющиеся к конференции, аутентифицируются своим предприятием.
Клиент отправляет запрос INFO для добавления пользователя на конференцию A/V.
Аудио-видеоконференции отправляют ответ "Добавить пользователя", содержащий маркер для представления в пограничной службе аудио-видеоконференций, помимо прочей информации.
[Примечание] Весь предыдущий трафик SIP проходил через службу Access Edge.
Клиент подключается к серверу конференций A/V, который проверяет маркер и проксирует запрос, который содержит другой маркер авторизации, на внутренний сервер конференций A/V Сервер конференций A/V Conferencing Server проверяет маркер авторизации, который он изначально выдал по каналу SIP, чтобы гарантировать, что действительный пользователь присоединится к конференции.
Между клиентом и сервером аудио- и видеоконференций соединение мультимедиа согласовывается и настраивается через SRTP.
Пользователь получает электронное письмо с приглашением присоединиться к собранию SfBO. В электронном письме содержится ключ конференции и URL-адрес, основанный на HTTP и ссылaющийся на конференцию. И ключ, и URL-адрес уникальны для конкретного собрания.
Меры безопасности федерации для SfBO
Федерация предоставляет вашей организации возможность общаться с другими организациями для обмена мгновенными сообщениями и присутствием. В SfBO федерация включена по умолчанию. Однако администраторы клиентов могут управлять этим с помощью Microsoft 365 или портала Администратор Office 365. См. больше.
Устранение угроз в конференциях SfBO
SfBO предоставляет возможность корпоративным пользователям создавать и присоединяться к веб-конференциям в режиме реального времени. Корпоративные пользователи также могут приглашать внешних пользователей, у которых нет Microsoft Entra ID, Microsoft 365 или Office 365 учетной записи, принять участие в этих собраниях. Пользователи, нанятые федеративными партнерами с надежной и аутентифицированной личностью, также могут участвовать в собраниях и, если они будут повышены уровнем, могут выступать в качестве докладчиков. Анонимные пользователи не могут создавать собрания или присоединяться к ним в качестве докладчиков, но им можно присвоить роль докладчика после присоединения.
Включение внешних пользователей для участия в собраниях SfBO значительно увеличивает ценность этой функции, но также влечет за собой некоторые риски для безопасности. Чтобы устранить эти риски, SfBO предоставляет следующие дополнительные гарантии:
- Роли участников определяют права на управление конференцией.
- Типы участников позволяют ограничить доступ к определенным собраниям.
- Определенные типы собраний определяют, какие типы участников могут принимать участие.
- Планирование конференций ограничено пользователями с Microsoft Entra учетной записью и лицензией SfBO.
- Анонимные, то есть не прошедшие проверку подлинности, пользователи, которые хотят присоединиться к конференции с телефонным подключением, набирают один из номеров доступа к конференции, а затем им будет предложено ввести идентификатор конференции. Неавторизованным (не прошедшим проверку подлинности) анонимным пользователям также предлагается записать свое имя. Записанные имена идентифицируют неавторизованных пользователей в конференции. Анонимные пользователи не допускаются в конференцию до тех пор, пока не присоединится по крайней мере один руководитель или пользователь, прошедший проверку подлинности, и им не удастся назначить предопределенную роль.
Роли участников
Участники собраний разделяются на три группы с собственными правами и ограничениями:
- Организатор. Пользователь, создающий собрание (незапланированное или запланированное). Организатор должен быть прошедшим проверку подлинности корпоративным пользователем и иметь контроль над всеми аспектами собрания.
- Докладчик. Пользователь, которому разрешено демонстрировать информацию на собрании с помощью любых поддерживаемых файлов мультимедиа. Организатор собрания по определению также является докладчиком и определяет, кто еще может быть докладчиком. Организатор может принимать это решении при планировании собрания или при его проведении.
- Участник Пользователь, который был приглашен для участия в собрании, но не имеет прав выступать в качестве докладчика.
Докладчик также может перевести участника в роль докладчика во время собрания.
Типы участников
Участники собрания также классифицируются по местоположению и учетным данным. Вы можете использовать обе эти характеристики, чтобы указать, какие пользователи могут иметь доступ к конкретным собраниям. Пользователей в общем смысле можно разделить на несколько категорий:
Пользователи, принадлежащие клиенту Эти пользователи имеют учетные данные в Microsoft Entra ID для клиента.
- Внутри корпоративной сети — эти пользователи присоединяются из корпоративной сети.
- Удаленные пользователи. Эти пользователи присоединяются из-за пределов корпоративной сети. К ним относятся сотрудники, которые работают дома или в дороге, и другие, например, сотрудники доверенных поставщиков, которым были предоставлены полномочия предприятия на их условиях обслуживания. Удаленные пользователи могут создавать и присоединяться к конференциям и выступать в качестве докладчиков.
Пользователи, не принадлежащие клиенту У этих пользователей нет учетных данных в Microsoft Entra ID для клиента.
- Федеративные пользователи . Федеративные пользователи имеют действительные учетные данные федеративных партнеров и, следовательно, рассматриваются как прошедшие проверку подлинности по SfBO. Федеративные пользователи могут присоединяться к конференциям и быть повышены до выступающих после присоединения к собранию, но они не могут создавать конференции на предприятиях, с которыми они федеративны.
- Анонимные пользователи . Анонимные пользователи не имеют удостоверения Active Directory и не являются федеративными с клиентом.
Данные клиентов показывают, что во многих конференциях участвуют внешние пользователи. Те же клиенты также хотят получить подтверждение об удостоверении внешних пользователей, прежде чем позволить этим пользователям присоединиться к конференции. Как описано в следующем разделе, SfBO ограничивает доступ тем пользовательским типам, которые были явно разрешены, и требует, чтобы все типы пользователей представляли соответствующие учетные данные при входе в совещание.
Прием участника
В SfBO анонимные пользователи переносятся в зону ожидания, называемую "зал ожидания". Затем участники могут либо допустить этих пользователей на совещание, либо отклонить их. Эти пользователи переносятся в "зал ожидания", лидер уведомляется, и затем пользователи ждут, пока лидер либо примет, либо отклонит их, либо их время соединения истечёт. Тем временем в"зале ожидания" пользователи слышат музыку.
По умолчанию участники, набирающие номер из PSTN, отправляются непосредственно на совещание, но этот параметр можно изменить, чтобы заставить участников набора номера перейти в "зал ожидания".
Организаторы собраний контролируют, могут ли участники присоединиться к собранию, не отправляясь в "зал ожидания". Каждое собрание может быть настроено на обеспечение доступа с использованием любого из следующих способов:
- Только я, организатор собрания Все, кроме организатора, должны ждать в зале ожидания, пока не допустим.
- Люди я приглашаю из моей компании Любой из вашей компании может войти на собрание напрямую, даже если не приглашен.
- Любой пользователь из моей организации Все пользователи SfBO в клиенте Microsoft 365 или Office 365 могут присоединиться к собранию, не дожидаясь в зале ожидания, даже если пользователи, которых нет в списке рассылки. Все остальные, включая всех внешних и анонимных пользователей, должны ожидать в "зале ожидания" до тех пор, пока не будут допущены.
- Всякий Любой пользователь (нет ограничений), у которого есть доступ к ссылке на собрание, напрямую попадает на собрание. Если указан какой-либо метод, кроме Организатора (заблокирован), организатор совещания также может указать, что люди набирают номер по телефону в обход "зала ожидания".
Возможности докладчика
Организаторы собраний контролируют, могут ли участники демонстрировать сведения во время собрания. Каждое собрание может быть настроено на ограничение докладчиков одним из следующих способов:
- Только организатор Может присутствовать только организатор совещания.
- Люди из моей компании Все внутренние пользователи могут представлять доклад.
- Все, включая людей вне моей компании Все (нет ограничений), которые могут присоединиться к совещанию.
- Люди я выбираю. Организатор собрания указывает, какие пользователи могут представлять, добавляя их в список выступающих.