Sicherheit und Skype for Business Online

  • Artikel
  • Gilt für::
    Skype for Business, Skype for Business Online, Microsoft Teams

Wichtig

Skype for Business Online, das von 21Vianet in China betrieben wird, wird am 1. Oktober 2023 eingestellt. Wenn Sie Ihre Skype for Business Online-Benutzer noch nicht aktualisiert haben, wird für sie automatisch ein unterstütztes Upgrade geplant. Wenn Sie Ihr organization selbst auf Teams aktualisieren möchten, empfehlen wir Dringend, dass Sie noch heute mit der Planung Ihres Upgradepfads beginnen. Denken Sie daran, dass ein erfolgreiches Upgrade die technische und die Benutzerbereitschaft ausrichtet. Nutzen Sie daher unseren Upgradeleitfaden , wenn Sie auf Ihrem Weg zu Teams navigieren.

Skype for Business Online wurde mit Ausnahme des von 21Vianet in China betriebenen Diensts am 31. Juli 2021 eingestellt.

Skype for Business Online (SfBO) als Teil der Microsoft 365- und Office 365-Dienste befolgt alle bewährten Sicherheitsmethoden und -verfahren, z. B. Sicherheit auf Serviceebene durch tiefgehende Verteidigung, Kundenkontrollen innerhalb des Diensts, Sicherheitshärtung und bewährte Betriebsmethoden. Ausführliche Informationen finden Sie im Microsoft Trust Center (https://microsoft.com/trustcenter).

Vertrauenswürdiges Design

Skype for Business Online wurde in Übereinstimmung mit dem Microsoft Trustworthy Computing Security Development Lifecycle (SDL) entwickelt, der unter https://www.microsoft.com/sdl/default.aspx beschrieben wird. Der erste Schritt beim Erstellen eines sicheren Unified Communications-Systems bestand in der Entwicklung von Gefahrenmodellen und im Testen jedes einzelnen Features während seines Entwurfs. Mehrere sicherheitsbezogene Verbesserungen wurden in Codierungsprozess und -methoden integriert. Mit Buildzeittools werden Pufferüberläufe und andere potenzielle Sicherheitsbedrohungen erkannt, bevor der Code in das Endprodukt übernommen wird. Es ist unmöglich, gegen alle unbekannten Sicherheitsbedrohungen zu entwerfen. Kein System kann 100-prozentige Sicherheit garantieren. Da sich die Produktentwicklung jedoch von Anfang an auf sichere Designprinzipien einbezieht, enthält Skype for Business Online Sicherheitstechnologien nach Industriestandard als grundlegenden Bestandteil seiner Architektur.

Standardmäßig vertrauenswürdig

Die Netzwerkkommunikation in Skype for Business Online ist standardmäßig verschlüsselt. Durch die Verwendung von Zertifikaten für alle Server und die Verwendung von OAUTH, TLS, SRTP (Secure Real-Time Transport Protocol) und anderen Verschlüsselungstechniken nach Branchenstandard, einschließlich der 256-Bit-AES-Verschlüsselung (Advanced Encryption Standard), werden alle Skype for Business Online-Daten im Netzwerk geschützt.

So geht SfBO mit allgemeinen Sicherheitsbedrohungen um

In diesem Abschnitt werden die häufigeren Bedrohungen für die Sicherheit des SfBO-Diensts und die Entschärfung der einzelnen Bedrohungen durch Microsoft beschrieben.

Angriff mit kompromittiertem Schlüssel

Ein Schlüssel ist ein geheimer Code oder eine geheime Nummer zur Verschlüsselung, Entschlüsselung oder Überprüfung geheimer Informationen. In der Public-Key-Infrastruktur (PKI) werden zwei sensible Schlüssel verwendet, die berücksichtigt werden müssen: der private Schlüssel, den jeder Zertifikatsinhaber besitzt, und der Sitzungsschlüssel, der nach einer erfolgreichen Identifizierung und dem Austausch von Sitzungsschlüsseln durch die kommunizierenden Partner verwendet wird. Ein Angriff mit kompromittierten Schlüsseln liegt vor, wenn der Angreifer den privaten Schlüssel oder den Sitzungsschlüssel ermittelt. Gelingt dem Angreifer die Ermittlung des Schlüssels, kann er den Schlüssel zum Entschlüsseln verschlüsselter Daten ohne Wissen des Absenders verwenden.

Skype for Business Online verwendet die PKI-Features im Windows Server-Betriebssystem, um die Schlüsseldaten zu schützen, die für die Verschlüsselung für tls-Verbindungen (Transport Layer Security) verwendet werden. Die für die Medienverschlüsselungen verwendeten Schlüssel werden über TLS-Verbindungen ausgetauscht.

Denial-of-Service-Angriff auf Netzwerke

Bei einem Denial-of-Service-Angriff werden die normale Netzwerknutzung und -funktion durch legitime Nutzer vom Angreifer verhindert. Durch einen Denial-of-Service-Angriff eröffnen sich den Angreifern folgende Möglichkeiten:

  • Er kann ungültige Daten an Anwendungen und Dienste senden, die in dem angegriffenen Netzwerk ausgeführt werden, um ihre Funktionsweise zu beeinträchtigen.
  • Er kann große Datenmengen senden, um das System zu überlasten, bis es nicht mehr oder nur noch verzögert auf legitime Anforderungen reagiert.
  • Er kann die Spuren seines Angriffs vertuschen.
  • Er kann Benutzer vom Zugriff auf die Netzwerkressourcen abhalten.

SfBO entschärft diese Angriffe, indem der Azure DDOS-Netzwerkschutz ausgeführt und Clientanforderungen von denselben Endpunkten, Subnetzen und Verbundentitäten gedrosselt werden.

Abhörschutz

Abhöraktionen sind Aktionen, bei denen sich Angreifer Zugriff auf den Datenpfad in einem Netzwerk verschaffen und anschließend den Datenverkehr überwachen und lesen können. Dies wird auch als „Schnüffeln“ (auch „Lauschangriff“, englisch Sniffing oder Snooping) bezeichnet. Wenn der Datenverkehr aus reinem Text besteht, können Angreifer ihn lesen, sobald sie Zugriff auf den Pfad haben. Ein Beispiel wäre ein Angriff, bei dem ein Router auf dem Datenpfad kontrolliert wird.

SfBO verwendet gegenseitiges TLS (MTLS) für die Serverkommunikation innerhalb von Microsoft 365 oder Office 365 und TLS von Clients zum Dienst, sodass dieser Angriff innerhalb des Zeitraums, in dem eine bestimmte Konversation angegriffen werden könnte, nur schwer bis unmöglich zu erreichen ist. TLS authentifiziert alle Parteien und verschlüsselt den gesamten Datenverkehr. Dies verhindert keine Lauschangriffe, aber der Angreifer kann den Datenverkehr nicht lesen, es sei denn, die Verschlüsselung ist beschädigt.

Das TURN-Protokoll wird für Echtzeit-Medienzwecke verwendet. Das TURN-Protokoll schreibt keine Verschlüsselung des Datenverkehrs vor, und die von ihm gesendeten Informationen sind durch die Nachrichtenintegrität geschützt. Obwohl es für Lauschangriffe offen ist, können die gesendeten Informationen (d. h. IP-Adressen und Port) direkt extrahiert werden, indem die Quell- und Zieladressen der Pakete betrachtet werden. Der SfBO-Service stellt sicher, dass die Daten gültig sind, indem er die Nachrichtenntegrität der Nachricht anhand des Schlüssels überprüft, der aus einigen wenigen Elementen einschließlich eines TURN-Kennworts abgeleitet wurde, das niemals im Klartext gesendet wird. SRTP wird für den Medienverkehr verwendet und ist ebenfalls verschlüsselt.

Identitätsspoofing (Spoofing der IP-Adresse)

Spoofing liegt vor, wenn Angreifer unbefugt die IP-Adresse eines Netzwerks, Computers oder einer Netzwerkkomponente ermitteln und verwenden. Bei einem erfolgreichen Angriff kann der Angreifer sich so verhalten, als sei er der normalerweise durch die IP-Adresse identifizierte Benutzer. Im Kontext von Microsoft Lync Server 2010 kommt diese Situation nur ins Spiel, wenn ein Administrator beide der folgenden Aktionen ausgeführt hat:

  • Konfigurierte Verbindungen, die nur TCP (Transmission Control Protocol) unterstützen (was nicht empfohlen wird, da die TCP-Kommunikation unverschlüsselt ist).
  • Er hat die IP-Adressen dieser Verbindungen als vertrauenswürdige Hosts markiert.

Dies ist für TLS-Verbindungen (Transport Layer Security) weniger ein Problem, da TLS alle Parteien authentifiziert und den gesamten Datenverkehr verschlüsselt. Die Verwendung von TLS verhindert Spoofingangriffe auf bestimmte Verbindungen (Mutual TLS-Verbindungen). Ein Angreifer könnte jedoch weiterhin die Adresse des DNS-Servers spoofen, den SfBO verwendet. Da die Authentifizierung in SfBO jedoch mit Zertifikaten erfolgt, verfügt ein Angreifer nicht über ein gültiges Zertifikat, das zum Spoofen einer der Parteien in der Kommunikation erforderlich ist.

Man-in-the-Middle-Angriff

Von einem „Man-in-the-Middle-Angriff“ spricht man, wenn Angreifer die Kommunikation zwischen zwei Nutzern ohne deren Wissen über ihren eigenen Computer leiten. Die Angreifer können die übertragenen Daten überwachen und lesen, ehe sie an den eigentlichen Empfänger weitergeleitet werden. Jeder Benutzer in der Kommunikation sendet unwissentlich Datenverkehr an den Angreifer und empfängt ihn, während er denkt, dass er nur mit dem beabsichtigten Benutzer kommuniziert. Dies kann passieren, wenn es Angreifern gelingt, die Active Directory-Domänendienste so zu ändern, dass ihr Server als vertrauenswürdiger Server hinzugefügt wird, oder wenn sie den DNS-Eintrag (Domain Name System) so ändern können, dass Clients auf ihrem Weg zum Server über den Computer der Angreifer geleitet werden.

Ein Man-in-the-Middle-Angriff kann auch bei Medienverkehr zwischen zwei Clients auftreten, außer dass in SfBO Punkt-zu-Punkt Audio-, Video- und Application-Sharing-Streams mit SRTP verschlüsselt werden, wobei kryptographische Schlüssel verwendet werden, die zwischen den Peers über das Session Initiation Protocol (SIP) über TLS ausgehandelt werden.

RTP Replay-Angriff

Ein Replay-Angriff liegt vor, wenn eine gültige Medienübertragung zwischen zwei Parteien abgefangen und für böswillige Zwecke erneut übertragen wird. SfBO verwendet SRTP in Verbindung mit einem sicheren Signalisierungsprotokoll, das Übertragungen vor Replay-Angriffen schützt, indem es dem Empfänger ermöglicht wird, einen Index der bereits empfangenen RTP-Pakete zu verwalten und jedes neue Paket mit den bereits im Index aufgeführten Paketen zu vergleichen.

Spim

Spim sind unaufgeforderte kommerzielle Chatnachrichten oder Anwesenheitsabonnementanforderungen. Das an sich ist zwar keine Kompromittierung des Netzwerks, aber es ist dennoch mindestens ärgerlich, kann Ressourcenverfügbarkeit und Produktion verringern und möglicherweise zu einer Beeinträchtigung des Netzwerks führen. Ein Beispiel dafür sind Angreifer, die sich gegenseitig durch das Senden von Anforderungen überbieten. Benutzer können sich gegenseitig blockieren, um dies zu verhindern, aber in einem Partnerverbund kann dies schwierig sein, wenn ein koordinierter Spim-Angriff erfolgt, sei denn, Sie deaktivieren den Verbund für den Partner.

Viren und Würmer

Ein Virus ist eine Codeeinheit, deren Zweck die Reproduktion weiterer, ähnlicher Codeeinheiten ist. Ein Virus benötigt, um zu funktionieren, einen Host, z. B. eine Datei, eine E-Mail oder ein Programm. Wie ein Virus ist ein Wurm eine Codeeinheit, die codiert ist, um mehr, ähnliche Codeeinheiten zu reproduzieren, aber im Gegensatz zu einem Virus keinen Host benötigt. Viren und Würmer treten vor allem bei Dateiübertragungen zwischen Clients oder beim Versenden von URLs von anderen Benutzern auf. Wenn sich ein Virus auf Ihrem Computer befindet, kann er beispielsweise Ihre Identität verwenden und Sofortnachrichten in Ihrem Namen versenden. Standardmäßige bewährte Methoden für die Client-Sicherheit, wie z. B. die regelmäßige Überprüfung auf Viren, können dieses Problem entschärfen.

Informationen zur Identifikation von Personen

SfBO hat das Potenzial, Informationen über ein öffentliches Netzwerk offenzulegen, die möglicherweise mit einer Person verknüpft werden können. Bei diesen Informationen kann es sich um zwei Kategorien von Angaben handeln:

  • Erweiterte Anwesenheitsdaten Erweiterte Anwesenheitsdaten sind Informationen, die ein Benutzer über einen Link für einen Verbundpartner oder mit Kontakten innerhalb eines organization freigeben oder nicht freigeben kann. Diese Daten werden nicht für Benutzer in einem öffentlichen Chatnetzwerk freigegeben. Client-Richtlinien und andere Client-Konfigurationen können dem Systemadministrator eine gewisse Kontrolle verschaffen. Im SfBO-Dienst kann der erweiterte vertrauliche Anwesenheitsmodus für einen einzelnen Benutzer konfiguriert werden, um zu verhindern, dass SfBO-Benutzer, die nicht in der Kontaktliste des Benutzers aufgeführt sind, die Anwesenheitsinformationen des Benutzers sehen.
  • Obligatorische Daten Obligatorische Daten sind Daten, die für den ordnungsgemäßen Betrieb des Servers oder clients erforderlich sind. Es handelt sich um Informationen, die auf Server- oder Netzwerkebene für das Routing, die Statuspflege und die Signalübermittlung erforderlich sind. Die folgenden Tabellen listen die Daten auf, die für den Betrieb von SfBO benötigt werden.

Tabelle 1 - Erweiterte Anwesenheitsdaten

Daten MöglicheEinstellungen
Persönliche Daten Name, Titel, Unternehmen, Email Adresse, Zeitzone
Telefonnummern Geschäftlich, mobil, privat
Kalenderdaten Frei/Gebucht, Out-of-Town-Benachrichtigung, Besprechungsdetails (für diejenigen, die Zugriff auf Ihren Kalender haben)
Anwesenheitsstatus Weg, Verfügbar, Beschäftigt, Nicht stören, Offline

Tabelle 2 - Plichtdaten

Daten MöglicheEinstellungen
IP-Adresse Tatsächliche Computer- oder NAT-Adresse
SIP-URI david.campbell@contoso.com
Name David Campbell (wie in Active Directory Domain Services definiert)

Sicherheitsframework für SfBO

Dieser Abschnitt enthält eine Übersicht über die grundlegenden Elemente, die das Sicherheitsframework für Microsoft SfBO bilden. Es handelt sich um die folgenden Elemente:

  • Microsoft Entra ID stellt ein einzelnes vertrauenswürdiges Back-End-Repository für Benutzerkonten bereit.
  • Die Public Key-Infrastruktur (PKI) verwendet Zertifikate, die von vertrauenswürdigen Zertifizierungsstellen (CAs) ausgestellt wurden, um Server zu authentifizieren und die Datenintegrität sicherzustellen.
  • Transport Layer Security (TLS), HTTPS über SSL (HTTPS) und Mutual TLS (MTLS) ermöglichen die Endpunktauthentifizierung und IM-Verschlüsselung. Punkt-zu-Punkt-Audio-, Video- und Anwendungsfreigabestreams werden verschlüsselt und die Integrität mithilfe des Secure Real-Time Transport Protocol (SRTP) überprüft.
  • Branchenstandardprotokolle für die Benutzerauthentifizierung, falls möglich.

In den Artikeln in diesem Abschnitt wird beschrieben, wie jedes dieser grundlegenden Elemente funktioniert, um die Sicherheit des SfBO-Diensts zu erhöhen.

Microsoft Entra ID

Microsoft Entra ID fungiert als Verzeichnisdienst für Microsoft 365 und Office 365. Es speichert alle Nutzerverzeichnisinformationen und Richtlinienzuweisungen.

Public-Key-Infrastruktur für SfBO

Der SfBO-Dienst basiert auf Zertifikaten für die Serverauthentifizierung und zum Einrichten einer Vertrauenskette zwischen Clients und Servern sowie zwischen den verschiedenen Serverrollen. Die Windows Server Public-Key-Infrastruktur (PKI) stellt die Infrastruktur für den Aufbau und die Validierung dieser Vertrauenskette zur Verfügung. Zertifikate sind digitale IDs. Sie identifizieren einen Server nach Namen und geben seine Eigenschaften an. Um sicherzustellen, dass die Informationen auf einem Zertifikat gültig sind, muss das Zertifikat von einer Zertifizierungsstelle ausgestellt werden, die von Clients oder anderen Servern, die eine Verbindung mit dem Server herstellen, als vertrauenswürdig eingestuft wird. Wenn sich der Server nur mit anderen Clients und Servern in einem privaten Netzwerk verbindet, kann die Zertifizierungsstelle eine Unternehmenszertifizierungsstelle sein. Wenn der Server mit Entitäten außerhalb des privaten Netzwerks interagiert, ist möglicherweise eine öffentliche Zertifizierungsstelle erforderlich.

Selbst wenn die Informationen auf dem Zertifikat gültig sind, muss es eine Möglichkeit zum Überprüfen geben, ob der Server, der das Zertifikat präsentiert, tatsächlich der Server ist, der von dem Zertifikat repräsentiert wird. Hier kommt die Windows PKI ins Spiel. Jedes Zertifikat ist mit einem öffentlichen Schlüssel verbunden. Der auf dem Zertifikat benannte Server verfügt über einen entsprechenden privaten Schlüssel, der nur ihm bekannt ist. Ein sich verbindender Client oder Server verwendet den öffentlichen Schlüssel, um eine beliebige Information zu verschlüsseln und sendet diese an den Server. Wenn der Server die Information entschlüsselt und als Klartext zurückgibt, kann die sich verbindende Entität sicher sein, dass der Server über den privaten Schlüssel zum Zertifikat verfügt und es sich daher um den auf dem Zertifikat benannten Server handelt.

CRL-Verteilungspunkte

SfBO erfordert, dass alle Serverzertifikate einen oder mehrere CRL-Verteilungspunkte (Certificate Revocation List) enthalten. CRL-Verteilungspunkte sind Speicherorte, von denen Zertifikatsperrlisten heruntergeladen werden können, um zu prüfen, ob das Zertifikat seit seiner Ausstellung gesperrt wurde und es sich noch im Gültigkeitszeitraum befindet. Ein CRL-Verteilungspunkt wird in den Eigenschaften des Zertifikats als URL angegeben und ist sicheres HTTP. Der SfBO-Dienst prüft die Sperrliste bei jeder Zertifikatsauthentifizierung.

Erweiterte Schlüsselverwendung

Alle Komponenten des SfBO-Diensts erfordern, dass alle Serverzertifikate die erweiterte Schlüsselverwendung (Enhanced Key Usage, EKU) für die Serverauthentifizierung unterstützen. Die Konfiguration des EKU-Felds für die Serverauthentifizierung bedeutet, dass das Zertifikat für den Zweck der Serverauthentifizierung gültig ist. Diese EKU ist wesentlich für MTLS.

TLS und MTLS für SfBO

TLS- und MTLS-Protokolle bieten verschlüsselte Kommunikation und Endpunktauthentifizierung im Internet. SfBO verwendet diese beiden Protokolle, um das Netzwerk von vertrauenswürdigen Servern zu erstellen und sicherzustellen, dass die gesamte Kommunikation über dieses Netzwerk verschlüsselt ist. Die gesamte SIP-Kommunikation zwischen Servern findet über MTLS statt. SIP-Kommunikation vom Client zum Server findet über TLS statt.

MIT TLS können Benutzer über ihre Clientsoftware die SfBO-Server authentifizieren, mit denen sie eine Verbindung herstellen. Bei einer TLS-Verbindung fordert der Client vom Server ein gültiges Zertifikat an. Damit das Zertifikat gültig ist, muss es von einer Zertifizierungsstelle ausgestellt sein, die auch für den Client vertrauenswürdig ist, und der DNS-Name des Servers muss dem DNS-Namen auf dem Zertifikat entsprechen. Wenn das Zertifikat gültig ist, verwendet der Client den öffentlichen Schlüssel im Zertifikat, um die symmetrischen Verschlüsselungsschlüssel, die für die Kommunikation verwendet werden, zu verschlüsseln, sodass nur der ursprüngliche Eigentümer des Zertifikats seinen privaten Schlüssel für die Entschlüsselung der Inhalte der Kommunikation verwenden kann. Die resultierende Verbindung ist vertrauenswürdig und wird von diesem Punkt an nicht von anderen vertrauenswürdigen Servern oder Clients abgefragt. In diesem Zusammenhang kann Secure Sockets Layer (SSL) bei der Verwendung mit Webdiensten als TLS-basiert zugeordnet werden.

Server-zu-Server-Verbindungen basieren auf gegenseitigem TLS (MTLS) zur gegenseitigen Authentifizierung. Bei einer MTLS-Verbindung tauschen der Server, von dem eine Nachricht stammt, und der Server, der diese empfängt, Zertifikate von einer beiderseits vertrauenswürdigen Zertifizierungsstelle aus. Die Zertifikate beweisen jedem Server die Identität des anderen. Im SfBO-Dienst wird diese Prozedur befolgt.

TLS und MTLS verhindern Lauschangriffe und Man-in-the-Middle-Angriffe. Ein Man-in-the-Middle-Angriff leitet die Kommunikation zwischen zwei Netzwerkeinheiten ohne Wissen einer der beiden Parteien über den Computer des Angreifers um. Die Spezifikation von TLS und SfBO für vertrauenswürdige Server verringern das Risiko eines Man-in-the-Middle-Angriffs teilweise mithilfe der Verwendung einer End-to-End-Verschlüsselung auf der Anwendungsebene, die mithilfe der Public Key-Kryptografie zwischen den beiden Endpunkten koordiniert wird, und ein Angreifer müsste über ein gültiges und vertrauenswürdiges Zertifikat mit dem entsprechenden privaten Schlüssel verfügen und auf den Namen des Dienstes ausgestellt sein, an den der Client kommuniziert, um die Kommunikation zu entschlüsseln.

Verschlüsselung für SfBO

SfBO verwendet TLS und MTLS zum Verschlüsseln von Chatnachrichten. Der gesamte Server-zu-Server-Datenverkehr erfordert MTLS – unabhängig davon, ob der Datenverkehr auf das interne Netzwerk beschränkt ist oder den internen Netzwerkperimeter überschreitet.

Die folgende Tabelle fasst das von SfBO verwendete Protokoll zusammen.

Tabelle 3 - Datenverkehrsschutz

Datenverkehrstyp Geschützt durch
Server-zu-Server MTLS
Client-zu-Server TLS
Chat und Anwesenheit TLS (falls für TLS konfiguriert)
Audio und Video und Desktopfreigaben von Medien SRTP
Desktopfreigabe (Signal) TLS
Webkonferenzen TLS
Herunterladen von Besprechungsinhalten, Herunterladen des Adressbuchs, Erweiterung der Verteilergruppe HTTPS

Medienverschlüsselung

Mediendatenverkehr wird über Secure RTP (SRTP) verschlüsselt, ein Profil von RTP (Real-Time Transport-Protokoll), das Vertraulichkeit, Authentifizierung und Schutz vor Replay-Angriffen für RTP-Datenverkehr bereitstellt. SRTP verwendet einen Sitzungsschlüssel, der mithilfe eines sicheren Zufallszahlengenerators generiert und über den signalisierenden TLS-Kanal ausgetauscht wird. Darüber hinaus werden Medien, die in beide Richtungen zwischen dem Vermittlungsserver und seinem internen nächsten Hop übertragen werden, ebenfalls über SRTP verschlüsselt.

SfBO generiert Benutzernamen/Kennwörter für den sicheren Zugriff auf Medienrelais über TURN. Medienrelays tauschen den Benutzernamen/Kennwort über einen TLS-gesicherten SIP-Kanal aus.

FIPS

SfBO verwendet FIPS (Federal Information Processing Standard) konforme Algorithmen für den Austausch von Verschlüsselungsschlüsseln.

Benutzer- und Client-Authentifizierung

Ein vertrauenswürdiger Benutzer ist ein Benutzer, dessen Anmeldeinformationen von Microsoft Entra ID in Microsoft 365 oder Office 365 authentifiziert wurden.

Authentifizierung bedeutet die Bereitstellung von Benutzeranmeldeinformationen für einen vertrauenswürdigen Server oder Dienst. SfBO verwendet je nach status und Standort des Benutzers die folgenden Authentifizierungsprotokolle.

  • Moderne Authentifizierung ist die Microsoft-Implementierung von OAUTH 2.0 für die Client-Server-Kommunikation. Sie ermöglicht Sicherheitsfeatures wie zertifikatbasierte Authentifizierung, Mehrstufige Authentifizierung und bedingten Zugriff. Für die Nutzung von MA müssen sowohl der Onlinemandant als auch die Clients für MA aktiviert sein. SfBO-Mandanten, die nach Mai 2017 erstellt wurden, haben MA standardmäßig aktiviert. Folgen Sie diesen Anweisungen hier für Mandanten, die vor dieser Zeit erstellt wurden, um diese einzuschalten. Die folgenden Clients unterstützen MA: Skype for Business 2015 oder 2016 Client, Skype for Business für Mac, Lync 2013 Client, 3PIP IP-Telefone, iOS und Android.
  • Die Organisations-ID wird verwendet, wenn die moderne Authentifizierung nicht aktiviert (oder nicht verfügbar) ist.
  • Das Digestprotokoll für sogenannte anonyme Benutzer. Anonyme Benutzer sind externe Benutzer, die keine Active Directory-Anmeldeinformationen erkannt haben, aber zu einer lokalen Konferenz eingeladen wurden und über einen gültigen Konferenzschlüssel verfügen. Die Digestauthentifizierung wird nicht für andere Clientinteraktionen verwendet.

Die SfBO-Authentifizierung besteht aus zwei Phasen:

  1. Zwischen dem Client und dem Server wird eine Sicherheitszuordnung eingerichtet.
  2. Client und Server verwenden die vorhandene Sicherheitszuordnung, um Nachrichten, die sie senden, zu signieren, und Nachrichten, die sie empfangen, zu überprüfen. Nicht authentifizierte Nachrichten von einem Client werden nicht akzeptiert, wenn die Authentifizierung auf dem Server aktiviert ist.

Die Benutzervertrauenswürdigkeit ist mit jeder Nachricht verbunden, die von einem Benutzer stammt, nicht mit der Benutzeridentität selbst. Der Server überprüft jede Nachricht auf gültige Benutzeranmeldeinformationen. Wenn die Benutzeranmeldeinformationen gültig sind, wird die Nachricht nicht nur vom ersten Server, der sie empfängt, sondern auch von allen anderen Servern in SfBO nicht angefochten.

Benutzer mit gültigen Anmeldeinformationen, die von einem Verbundpartner ausgegeben wurden, sind vertrauenswürdig, erhalten aber optional aufgrund zusätzlicher Einschränkungen nicht sämtliche Berechtigungen, die internen Benutzern erteilt werden.

Für die Medienauthentifizierung verwenden die ICE- und TURN-Protokolle auch die Digest-Challenge, wie im IETF TURN RFC beschrieben. Weitere Informationen finden Sie unter Mediendurchlauf.

Clientzertifikate bieten eine alternative Möglichkeit für die Authentifizierung von Benutzern durch SfBO. Anstelle der Angabe eines Benutzernamens und eines Kennworts haben die Benutzer ein Zertifikat und den privaten Schlüssel, der dem Zertifikat entspricht, das zum Auflösen einer kryptografischen Aufforderung benötigt wird.

Windows PowerShell und SfBO-Verwaltungstools

In SfBO können IT-Administratoren ihren Dienst über das O365 Admin-Portal oder über Remote-PowerShell (TRPS) des Mandanten verwalten. Mandantenadministratoren verwenden die moderne Authentifizierung, um sich bei TRPS zu authentifizieren.

Konfigurieren des Zugriffs auf SfBO an Ihrer Internetgrenze

Damit SfBO ordnungsgemäß funktioniert (Benutzer, die an Besprechungen teilnehmen können usw.), müssen Kunden ihren Internetzugriff so konfigurieren, dass ausgehender UDP- und TCP-Datenverkehr zu Diensten in der SfBO-Cloud zulässig ist. Weitere Informationen finden Sie hier: https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo

UDP 3478-3481 und TCP 443

Die Client verwenden die Ports UDP 3478-3481 und TCP 443, um Dienste vom A/V Edge-Dienst anzufordern. Ein Client verwendet diese beiden Ports, um UDP- bzw. TCP-Ports für die Verbindung zum Remote-Teilnehmer zuzuweisen. Für den Zugriff auf den A/V-Edgedienst muss der Client zunächst eine authentifizierte SIP-Signalsitzung bei der SfBO-Registrierungsstelle eingerichtet haben, um Anmeldeinformationen für die Authentifizierung des A/V-Edgediensts zu erhalten. Diese Werte werden über den TLS-geschützten Signalisierungskanal gesendet und sind computergeneriert, um gegen Schlüsselverzeichnisangriffe zu schützen. Clients können diese Anmeldeinformationen dann für die Hashwert-Authentifizierung mit dem A/V Edge-Dienst verwenden, um Ports für die Verwendung in einer Mediensitzung zuzuweisen. Eine erste Zuordnungsanforderung wird vom Client gesendet und mit einer 401 Nonce/Aufforderung-Nachricht vom A/V Edge-Dienst beantwortet. Der Client sendet eine zweite Zuweisung, die den Benutzernamen und einen Hash Message Authentication Code (HMAC) Hash des Benutzernamens und nonce enthält.

Ein Sequenznummern-Mechanismus zum Verhindern von Replay-Angriffen ist ebenfalls vorhanden. Der Server berechnet den erwarteten HMAC basierend auf seiner eigenen Kenntnis des Benutzernamens und des Kennworts. Wenn die HMAC-Werte übereinstimmen, wird die Zuweisungsprozedur durchgeführt. Andernfalls wird das Paket gelöscht. Der gleiche HMAC-Mechanismus wird auch auf nachfolgende Nachrichten innerhalb dieser Aufrufsitzung angewendet. Die Lebensdauer dieses Benutzername/Kennwortes beträgt maximal acht Stunden, in denen der Client einen neuen Benutzername/ein neues Kennwort für nachfolgende Aufrufe erhält.

UDP/TCP 50.000–59.999

TCP 50.000 wird ausgehend für SfBO verwendet, einschließlich für Anwendungs- und Desktopfreigabe und Dateiübertragung. UDP/TCP 50.000-59.999 Portbereiche werden für Mediensitzungen mit Microsoft Office Communications Server 2007-Partnern verwendet, die den NAT/Firewallüberquerungsdienst des A/V Edge-Diensts benötigen. Da der A/V Edge-Dienst der einzige Prozess ist, der diese Ports verwendet, gibt die Größe des Portbereichs nicht auf die potenzielle Angriffsfläche hin. Eine gute Sicherheitspraxis besteht darin, die Gesamtzahl der Lauschports zu minimieren, indem keine unnötigen Netzwerkdienste ausgeführt werden. Wenn ein Netzwerkdienst nicht ausgeführt wird, kann er von einem Remoteangreifer nicht ausgenutzt werden, und die Angriffsfläche des Hostcomputers wird reduziert. Innerhalb eines einzelnen Diensts bietet die Reduzierung der Anzahl von Ports jedoch nicht den gleichen Vorteil. Die A/V Edge-Dienstsoftware ist mit 10.000 offenen Ports nicht so angreifbar wie mit 10. Die Zuordnung von Ports innerhalb dieses Bereichs erfolgt nach dem Zufallsprinzip, und derzeit nicht zugeordnete Ports lauschen nicht auf Pakete.

Externer Benutzer A/V-Verkehrdurchlauf

Damit externe und interne Benutzer Medien austauschen können, ist ein Access Edge-Dienst erforderlich, der die SIP-Signalisierung übernimmt, die zum Auf- und Abbau einer Sitzung benötigt wird. Der A/V Edge-Dienst muss auch als Relais für die Übertragung der Medien agieren. Die Aufrufsequenz wird in der folgenden Abbildung dargestellt.

Anrufsequenz in Besprechungsbeitritt.

  1. Ein Benutzer erhält eine E-Mail mit einer Einladung zur Teilnahme an einer SfBO-Besprechung. Die E-Mail enthält einen Konferenzschlüssel und eine HTTP-basierte URL, die mit der Konferenz verlinkt. Sowohl der Schlüssel als auch die URL sind für eine bestimmte Besprechung eindeutig.

    Der Benutzer initiiert die Teilnahmeprozedur, indem er in der E-Mail auf die Besprechungs-URL klickt, wodurch ein Clienterkennungsprozess auf dem Computer des Benutzers initiiert wird. Wenn der Client erkannt wird, startet dieser Client. Wenn dies nicht erkannt wird, wird der Benutzer an den Webclient umgeleitet.

  2. Der SfBO-Client sendet eine SIP-EINLADUNG mit den Anmeldeinformationen des Benutzers. Ein Verbund- oder Remotebenutzer tritt mit seinen Unternehmensanmeldeinformationen einer Konferenz bei. Für einen Verbundbenutzer wird die SIP-EINLADUNG zunächst an seinen Heimserver gesendet, der den Benutzer authentifiziert und die EINLADUNG an SfBO weiterleitet. Ein anonymer Benutzer wird für das Durchlaufen der Digest-Authentifizierung benötigt.

    SfBO authentifiziert den Remote- oder anonymen Benutzer und benachrichtigt den Client. Wie in Schritt 2 erwähnt, werden Verbundbenutzer, die einer Konferenz beitreten, von ihrem Unternehmen authentifiziert.

  3. Der Client sendet eine INFO-Anforderung, um den Benutzer der A/V-Konferenz hinzuzufügen.

    Die A/V-Konferenzen senden eine Antwort zum Hinzufügen von Benutzern, die unter anderem das Token enthält, das dem A/V-Konferenz-Edgedienst präsentiert werden soll.

    [Hinweis] Der gesamte vorangehende SIP-Datenverkehr fließt über den Access Edge-Dienst.

    Der Client verbindet sich mit dem A/V-Konferenzserver, der das Token validiert und die Anforderung, die ein anderes Autorisierungstoken enthält, an den internen A/V-Konferenzserver weiterleitet. Der A/V-Konferenzserver validiert das Autorisierungstoken, das er ursprünglich über den SIP-Kanal ausgegeben hat, um sicherzustellen, dass ein gültiger Benutzer an der Konferenz teilnimmt.

  4. Zwischen dem Client und dem A/V-Konferenzserver wird eine Medienverbindung ausgehandelt und über SRTP eingerichtet.

  5. Ein Benutzer erhält eine E-Mail mit einer Einladung zur Teilnahme an einer SfBO-Besprechung. Die E-Mail enthält einen Konferenzschlüssel und eine HTTP-basierte URL, die mit der Konferenz verlinkt. Sowohl der Schlüssel als auch die URL sind für eine bestimmte Besprechung eindeutig.

Verbundsicherungen für SfBO

Verbund bietet Ihrer Organisation die Möglichkeit, mit anderen Organisationen zu kommunizieren, um IM und Anwesenheit zu teilen. In SfBO ist der Verbund standardmäßig aktiviert. Mandantenadministratoren haben jedoch die Möglichkeit, dies über das Microsoft 365- oder Office 365 Admin-Portal zu steuern. Mehr sehen.

Handhaben von Bedrohungen für SfBO-Konferenzen

Mit SfBO können Unternehmen Webkonferenzen in Echtzeit erstellen und daran teilnehmen. Unternehmensbenutzer können auch externe Benutzer, die nicht über ein Microsoft Entra ID-, Microsoft 365- oder Office 365-Konto verfügen, zur Teilnahme an diesen Besprechungen einladen. Benutzer, die von Verbundpartnern mit einer sicheren und authentifizierten Identität angestellt sind, können auch an Besprechungen teilnehmen und, wenn sie dazu befördert werden, als Referenten fungieren. Anonyme Benutzer können keine Besprechungen als Moderator erstellen oder ihnen beitreten. Sie können jedoch nach ihrem Beitritt zum Moderator ernannt werden.

Die Möglichkeit für externe Benutzer, an SfBO-Meetings teilzunehmen, erhöht den Wert dieser Funktion erheblich, birgt aber auch einige Sicherheitsrisiken. SfBO bietet folgende zusätzlichen Sicherheitsmaßnahmen, um diesen Risiken zu begegnen:

  • Teilnehmerrollen bestimmen die Berechtigungen für die Konferenzsteuerung.
  • Mithilfe der Teilnehmertypen können Sie den Zugriff auf bestimmte Besprechungen einschränken.
  • Definierte Besprechungstypen legen fest, welche Teilnehmertypen teilnehmen können.
  • Die Konferenzplanung ist auf Benutzer beschränkt, die über ein Microsoft Entra-Konto und eine SfBO-Lizenz verfügen.
  • Anonyme, d. h. nicht authentifizierte Benutzer, die an einer Einwahlkonferenz teilnehmen möchten, wählen eine der Konferenzzugriffsnummern und werden dann aufgefordert, die Konferenz-ID einzugeben. Nicht authentifizierte anonyme Benutzer werden ebenfalls aufgefordert, ihren Namen aufzuzeichnen. Der aufgezeichnete Name identifiziert nicht authentifizierte Benutzer in der Konferenz. Anonyme Benutzer werden erst zur Konferenz zugelassen, wenn mindestens ein Leiter oder ein authentifizierter Benutzer beigetreten ist und ihnen keine vordefinierte Rolle zugewiesen werden kann.

Teilnehmerrollen

Die Besprechungsteilnehmer gliedern sich in drei Gruppen mit jeweils eigenen Privilegien und Einschränkungen:

  • Organisator Der Nutzer, der ein Besprechung erstellt, sei es spontan oder durch Terminplanung. Ein Organisator muss ein authentifizierter Unternehmensbenutzer sein und die Kontrolle über alle Endbenutzeraspekte einer Besprechung haben.
  • Moderator Ein Nutzer, der berechtigt ist, Informationen in einer Besprechung zu präsentieren, unabhängig davon, welches Medium unterstützt wird. Ein Besprechungsorganisator ist per Definition auch ein Referent und bestimmt, wer sonst noch ein Referent sein kann. Ein Organisator kann diese Entscheidung treffen, wenn eine Besprechung geplant ist oder während die Besprechung stattfindet.
  • Teilnehmer Ein Benutzer, der zu einer Besprechung eingeladen wurde, aber nicht berechtigt ist, als Referent zu fungieren.

Ein Referent kann auch einen Teilnehmer während der Besprechung für die Rolle des Referenten befördern.

Teilnehmertypen

Die Besprechungsteilnehmer werden auch nach Aufenthaltsort und Anmeldeinformationen kategorisiert. Mit diesen beiden Merkmalen können Sie festlegen, welche Benutzer Zugriff auf bestimmte Besprechungen haben. Die Benutzer lassen sich grob in die folgenden Kategorien einteilen:

  1. Benutzer, die zum Mandanten gehören Diese Benutzer verfügen über Anmeldeinformationen in Microsoft Entra ID für den Mandanten.
    a. Innerhalb des Unternehmensnetzwerks : Diese Benutzer werden innerhalb des Unternehmensnetzwerks beitreten.
    b. Remotebenutzer – Diese Nutzer treten von außerhalb des Unternehmensnetzwerks bei. Dazu gehören Mitarbeiter, die zu Hause oder unterwegs arbeiten, und andere, wie Mitarbeiter von vertrauenswürdigen Anbietern, denen für ihre Vertragsbedingungen ein Unternehmenszertifikat erteilt wurde. Remotebenutzer können Konferenzen erstellen und daran teilnehmen und als Referenten fungieren.
  2. Benutzer, die nicht zum Mandanten gehören Diese Benutzer verfügen nicht über Anmeldeinformationen in Microsoft Entra ID für den Mandanten.
    a. Verbundbenutzer : Verbundbenutzer verfügen über gültige Anmeldeinformationen bei Verbundpartnern und werden daher von SfBO als authentifiziert behandelt. Verbundbenutzer können an Konferenzen teilnehmen und zu Referenten heraufgestuft werden, nachdem sie an der Besprechung teilnehmen, aber sie können keine Konferenzen in Unternehmen erstellen, mit denen sie verbunden sind.
    b. Anonyme Benutzer : Anonyme Benutzer verfügen nicht über eine Active Directory-Identität und sind nicht mit dem Mandanten verbunden.

Kundendaten zeigen, dass viele Konferenzen externe Benutzer einbeziehen. Dieselben Kunden möchten sich auch über die Identität der externen Benutzer vergewissern, bevor sie an einer Konferenz teilnehmen können. Wie im folgenden Abschnitt beschrieben, beschränkt SfBO den Zugriff auf die Benutzertypen, die explizit zugelassen wurden, und verlangt von allen Benutzertypen, dass sie bei der Teilnahme an einer Besprechung entsprechende Anmeldeinformationen vorlegen.

Teilnehmerzulassung

In SfBO werden anonyme Benutzer in einen Wartebereich, die Lobby, weitergeleitet. Referneten können diese Benutzer dann entweder zur Besprechung zulassen oder ablehnen. Diese Benutzer werden in die Lobby übertragen, der Leiter wird benachrichtigt, und die Benutzer warten dann, bis ein Leiter sie entweder akzeptiert oder ablehnt oder ihre Verbindungszeit abgelaufen ist. In der Lobby hören die Benutzer Musik.

Standardmäßig gehen Teilnehmer, die sich aus dem PSTN einwählen, direkt zur Besprechung, aber diese Option kann geändert werden, um die Einwahl der Teilnehmer in die Lobby zu erzwingen.
Besprechungsorganisatoren steuern, ob Teilnehmer an einer Besprechung teilnehmen können, ohne in der Lobby zu warten. Jede Besprechung kann so eingerichtet werden, dass der Zugriff mit einer der folgenden Methoden möglich ist:

  • Nur ich, der Besprechungsorganisator Jeder außer dem Veranstalter muss im Wartebereich warten, bis er zugelassen wird.
  • Personen ich von meinem Unternehmen einlade Jeder aus Ihrem Unternehmen kann direkt an der Besprechung teilnehmen, auch wenn er nicht eingeladen ist.
  • Jeder aus meinem organization Alle SfBO-Benutzer im Microsoft 365- oder Office 365-Mandanten können an der Besprechung teilnehmen, ohne im Wartebereich zu warten, auch wenn diejenigen, die nicht in der Verteilerliste sind. Alle anderen, einschließlich aller externen und anonymen Benutzer, müssen in der Lobby warten, bis sie zugelassen werden.
  • Jemand Jeder (es gibt keine Einschränkungen), der Zugriff auf den Besprechungslink hat, gelangt direkt in die Besprechung. Wenn eine beliebige Methode außer Nur Organisator (gesperrt) angegeben ist, kann der Organisator der Besprechung auch Personen angeben, die sich per Telefon einwählen, um die Lobby zu umgehen.

Referentenfunktion

Die Organisatoren der Besprechung kontrollieren, ob die Teilnehmer während einer Besprechung anwesend sein können. Jede Besprechung kann so eingerichtet werden, dass die Referenten auf einen der folgenden Punkte beschränkt sind:

  • Nur Organisator Nur der Organisator kann Referent sein.
  • Personen aus meinem Unternehmen Alle internen Benutzer können teilnehmen.
  • Jeder, der Personen außerhalb meines Unternehmens einbezieht Jeder (es gibt keine Einschränkungen), der der Besprechung beitritt, kann teilnehmen.
  • Personen Ich wähle Der Besprechungsorganisator an, welche Benutzer präsentieren können, indem sie einer Liste von Referenten hinzugefügt werden.

Microsoft Trust Center