Sicherheitsaspekte von VoIP-Lösungen – Schwerpunkt Microsoft Teams-Telefonie mit Firewall-Beispielen auf Basis Sophos XGS

1. Management Summary

Als IT-Leitung oder Sicherheitsverantwortlicher steht die Absicherung von Voice-over-IP (VoIP) Lösungen – insbesondere bei der Einführung von Microsoft Teams-Telefonie – an oberster Stelle. Das vorliegende Dokument bietet einen praxisnahen Leitfaden, um Risiken zu erkennen und Schutzmaßnahmen umzusetzen. Es beleuchtet alle relevanten Aspekte von der Identitätssicherung über Protokollverschlüsselung bis hin zur Firewall- und Session Border Controller (SBC) Konfiguration. Microsoft Teams-Telefonie in Unternehmen bringt neue Angriffsflächen mit sich, etwa durch die Öffnung von Echtzeit-Medien ins Internet und die Kopplung mit Telefonanbietern. Dem gegenüber stehen moderne Sicherheitsmechanismen wie End-to-End-Verschlüsselung und granulare Zugriffssteuerung, die es konsequent zu nutzen gilt.

Wichtigste Risiken: Zu den Top-Risiken zählen unautorisierte Auslandstelefonate (Toll Fraud), Abhören von Gesprächen durch unsichere Verbindungen, Ausfall der Telefonie durch DoS/DDoS-Angriffe sowie Kompromittierung von Benutzerkonten. Auch Fehler in der Konfiguration – etwa zu weit gefasste Firewall-Regeln oder unzureichend geschützte SIP-Trunks – können erhebliche Sicherheitslücken darstellen. Zentrale Maßnahmen zur Risikobehandlung sind unter anderem eine strikte Zugriffskontrolle (z.B. Multi-Faktor-Authentifizierung und Conditional Access für Admin-Konten), durchgängige Verschlüsselung der Signal- und Mediendaten, eine Netzwerksegmentierung mit restriktiven Firewalls, Härtung der SBC- und Client-Systeme, sowie laufendes Monitoring aller VoIP-Komponenten. Diese Maßnahmen reduzieren die Angriffsfläche erheblich und erhöhen die Resilienz der Kommunikationsinfrastruktur.

Reifegradmodell: Unternehmen sollten den Sicherheitsstatus ihrer VoIP-Umgebung regelmäßig bewerten. Ein einfaches Reifegradmodell kann helfen, vom Basisniveau (z.B. nur grundlegender Passwortschutz und einfache Firewall-Regeln) über Fortgeschritten (z.B. implementierte Verschlüsselung, segmentiertes Netzwerk, automatisierte Überwachung) hin zu einem führenden Niveau zu gelangen, bei dem eine ganzheitliche Sicherheitsstrategie samt Incident Response und kontinuierlicher Verbesserung verankert ist. Differenzen zwischen Ist- und Soll-Zustand gilt es systematisch zu schließen. Dabei unterstützen definierte Metriken und regelmäßige Audits, um Fortschritte messbar zu machen.

Quick Wins (0–30 Tage): Einige Sicherheitsverbesserungen lassen sich kurzfristig umsetzen:
– Aktivierung von Multi-Faktor-Authentifizierung (MFA) für alle Administrations- und Benutzerkonten in Microsoft 365.
– Überprüfung und Eingrenzung der Firewall-Regeln: unnötige Ports schließen, ausgehende Ziele auf Microsoft-365-Services beschränken.
– Einschalten von Protokollierung und Alerts für ungewöhnliche Vorgänge (z.B. viele fehlgeschlagene Anmeldeversuche oder abweichende Anrufmuster).
– Sensibilisierung des IT-Personals und der Benutzer für VoIP-bezogene Phishing-Angriffe (z.B. gefälschte Teams-Anmeldeseiten).
– Durchführung eines grundlegenden VoIP-Sicherheitsaudits, um offensichtliche Lücken zu identifizieren.

Roadmap (90/180 Tage): Mittelfristig sollte eine detaillierte Roadmap abgearbeitet werden:
– 90 Tage: Umsetzung einer rollenbasierten Zugriffssteuerung und minimaler Rechte (Least Privilege) für Teams-Telefonie-Administratoren. Einführung eines Session Border Controllers mit Härtung gemäß Best Practices (siehe Kapitel 7). Implementierung eines Monitoring-Dashboards für Qualitäts- und Sicherheitskennzahlen. Durchführung erster Notfalltests (z.B. Ausfall des Haupt-SBC und Fallback-Szenario).
– 180 Tage: Etablierung eines vollständigen Incident-Response-Prozesses für VoIP-Vorfälle inkl. geschulter Verantwortlichkeiten. Regelmäßige Pentests bzw. Schwachstellenanalysen der VoIP-Infrastruktur durchführen lassen. Verfeinerung der QoS- und SD-WAN-Konfiguration, um auch bei erhöhten Sicherheitsmaßnahmen (z.B. Deep Packet Inspection) eine hohe Sprachqualität sicherzustellen. Überprüfung der Compliance-Anforderungen im DACH-Raum und Anpassung der Aufbewahrungs- und Datenschutzrichtlinien.

Im weiteren Verlauf dieses Artikels werden alle genannten Punkte ausführlich behandelt. Die Leser – von der IT-Leitung bis zum Security-Team – erhalten konkrete Empfehlungen und Beispiele, um Microsoft Teams-Telefonie sicher und zuverlässig in ihre Unternehmensumgebung zu integrieren. Jetzt folgt zunächst eine Einführung in Begriffe und Architektur, um ein gemeinsames Verständnis zu schaffen.

2. Begriffe, Architektur und Rollen

Bevor in die spezifischen Sicherheitsmaßnahmen eingestiegen wird, ist ein gemeinsames Verständnis der VoIP-Grundlagen und der Microsoft Teams-Telefonie-Architektur notwendig. In diesem Abschnitt werden die wichtigsten Begriffe erläutert, sowie die Architektur und beteiligten Komponenten skizziert.

VoIP-Grundlagen: SIP, RTP, SDP, TLS/SRTP, ICE/STUN/TURN

Bei Voice-over-IP (VoIP) erfolgt die Sprach- und Videoübertragung über Computernetzwerke auf Basis des Internet-Protokolls. Zentrale Protokolle sind hier das Session Initiation Protocol (SIP) für die Signalisierung und das Real-time Transport Protocol (RTP) für den Transport der Mediendaten (Audio, Video). SIP dient zum Aufbau, Abbau und Steuern von Gesprächen. Dabei werden Sitzungsinformationen wie Teilnehmer und genutzte Medien über das Session Description Protocol (SDP) in den SIP-Nachrichten ausgetauscht. RTP überträgt die eigentlichen Sprachpakete in Echtzeit; in der Regel wird RTP über User Datagram Protocol (UDP) gesendet, um Latenzen gering zu halten. Zur Absicherung dieser Kommunikation kommt Transport Layer Security (TLS) für die SIP-Signalisierung zum Einsatz (SIP über TLS, meist Port 5061 statt 5060) und Secure RTP (SRTP) für die verschlüsselten Medienströme. Durch TLS werden SIP-Nachrichten vor Abhören und Manipulation geschützt, während SRTP die Sprach- und Videodaten vor unbefugtem Zugriff sichert.

Ein häufiges Herausforderung bei VoIP ist die NAT-Traversierung: Viele Teilnehmer befinden sich hinter Network Address Translation (NAT) in privaten Netzen. Hier kommen Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN) und Traversal Using Relays around NAT (TURN) ins Spiel. ICE ist ein Framework, das die beste Kommunikationsroute zwischen zwei Endpunkten ermittelt, auch wenn beide hinter NAT sind. STUN-Server erlauben Clients, ihre öffentliche IP-Adresse und Port herauszufinden (NAT-Public Endpoint Discovery). Klappt eine direkte Peer-to-Peer-Verbindung trotz STUN nicht, vermittelt ein TURN-Server als Relay die Medienverbindung über einen öffentlich erreichbaren Knoten. Diese Mechanismen sind insbesondere für mobile und externe Teams-Teilnehmer relevant, damit Audio und Video trotz strikter Firewall- und NAT-Regeln fließen können.

Architektur der Microsoft Teams-Telefonie

Microsoft Teams bietet Telefonie-Funktionen als Cloud-Dienst, der die klassische Telefonanlage (PBX) ersetzt. Jedes Unternehmen hat einen Microsoft 365 Tenant (Mandanteninstanz), in dem die Teams-Telefonie konfiguriert wird. Die Architektur umfasst Microsofts weltweite Rechenzentrums-Infrastruktur, über die Signalisierung und Medien geroutet werden. Teams-Clients (PCs, Smartphones oder dedizierte Teams-Telefone) registrieren sich nicht bei einer lokalen TK-Anlage, sondern beim Microsoft Phone System in der Cloud. Für interne Gespräche zwischen Teams-Nutzern verbleibt die Kommunikation meist innerhalb der Microsoft-Cloud (bzw. geht Peer-to-Peer sofern möglich), während für externe Anrufe ins öffentliche Telefonnetz (PSTN) eine Anbindung an einen Telefonie-Provider erforderlich ist.

Es gibt mehrere Wege, PSTN-Konnektivität bereitzustellen:
– Direct Routing: Das Unternehmen betreibt einen Session Border Controller (SBC) selbst (on-premises oder als gehostete Instanz). Dieser SBC verbindet einerseits zur Microsoft-Cloud (über das Internet, via SIP über TLS mit Microsofts PSTN-Hub), und andererseits zum Telefonieanbieter (z.B. SIP-Trunk des Carriers). Direct Routing bietet maximale Kontrolle und Flexibilität, erfordert aber die fachgerechte Härtung des SBC und der Netzwerkintegration.
– Operator Connect: Hierbei stellt ein zertifizierter Telekommunikationsanbieter die Verbindung zu Microsoft Teams her. Der Provider betreibt den SBC und kümmert sich um die Kopplung; das Unternehmen muss keinen eigenen SBC stellen, sondern verwaltet nur die Zuweisung der Rufnummern in Teams. Dies vereinfacht Betrieb und Wartung, verlangt aber Vertrauen in die Sicherheitsmaßnahmen des Operators.
– Calling Plans (Microsoft Calling): Microsoft selbst agiert als Telefonie-Provider. Rufnummern und Gesprächsminuten werden direkt von Microsoft bereitgestellt (gegen Gebühr). Aus Unternehmenssicht ist dies die einfachste Variante, da keine eigene Infrastruktur nötig ist. Allerdings sind Calling Plans nicht in allen Ländern verfügbar und weniger flexibel (z.B. bei Sonderrufnummern oder spezifischen Routingwünschen).

In allen Varianten fungiert Microsoft Teams als zentrales Cloud-Telefonsystem. Die Mediendaten (Sprache, Video) fließen je nach Szenario entweder direkt zwischen den Endpunkten (bei internem P2P) oder über Microsofts Media Relays. Bei PSTN-Anrufen mit Direct Routing nimmt der SBC die Medien vom Teams-Netz entgegen und sendet sie ins Telefonnetz und umgekehrt. Microsoft betreibt für Direct Routing globale PSTN-Media Gateways und SIP-Proxys (z.B. sip.pstnhub.microsoft.com und regionale Varianten). Die Signalisierung zwischen SBC und Microsoft erfolgt stets verschlüsselt und authentifiziert (mutual TLS mit Zertifikaten). Der gesamte Ablauf – von der Wählzeichenfolge im Teams-Client bis zum Klingeln beim externen Teilnehmer – durchläuft so mehrere Stationen, die alle sorgfältig gesichert sein müssen.

Komponenten und Rollen in einer Teams-Telefonie-Umgebung

Ein Session Border Controller (SBC) ist das Bindeglied zwischen dem Unternehmensnetz und dem externen Telefonnetz/Microsoft-Cloud. Er übernimmt Protokollumsetzungen, Filterung (z.B. SIP-Header-Moderation) und fungiert als Sicherheitsgateway speziell für VoIP. Der SBC sollte in einer entmilitarisierten Zone (DMZ) oder Cloud-Transitnetz positioniert und streng gehärtet sein. Auf Providerseite steht entweder ein SIP-Trunk (bei Festnetz über IP) oder andere Schnittstellen (ISDN/PRI über Gateways) bereit, die am SBC terminiert werden. Firewall-Systeme (z.B. Sophos XGS) regeln den Datenverkehr zwischen internen Netzen, DMZ und dem Internet. Sie müssen so konfiguriert sein, dass nur die erforderlichen Verbindungen (Signalisierung, Medien, DNS, etc.) zugelassen werden – sowohl für die Teams-Clients als auch für den SBC. Falls im Einsatz, können Proxy-Server oder Cloud-Proxy-Dienste eine Rolle spielen; für latenzkritische Dienste wie Teams ist jedoch meist eine direkte Verbindung unter Umgehung von HTTP-Proxys empfohlen.

Die Endpunkte sind die Teams-Clients auf Windows, macOS, iOS, Android oder dedizierte Tischtelefone und Konferenzsysteme. Sie kommunizieren über das lokale LAN/WLAN oder VPN mit der Microsoft-Cloud. Hier ist zu beachten, dass dedizierte Teams-Telefone (mit embedded Android) oft in separate VLANs gepackt werden wie klassische IP-Telefone, während Softclients auf PCs im normalen Unternehmens-LAN laufen. Netzwerkseitig sollte eine Segmentierung erfolgen: z.B. ein eigenes VLAN für Voice-Geräte, eigene Bereiche für SBC und andere Infrastruktur, und Management-Netze für die Administration. Auch Identitäts- und Zugriffsverwaltung spielt eine Rolle: Die Nutzer und Administratoren werden über Azure Active Directory (Azure AD) authentifiziert, und ihre Berechtigungen bestimmen, wer was in Teams-Telefonie tun darf (z.B. Call Queue Admin, Teams Communications Admin etc.). Diese Identitäten müssen besonders geschützt werden, da ein kompromittiertes Admin-Konto gravierenden Schaden anrichten könnte (dazu mehr in Kapitel 4).

3. Bedrohungsmodell & Angriffsflächen

Um wirksame Schutzmaßnahmen abzuleiten, muss zunächst das Bedrohungsmodell im Kontext von VoIP und Teams-Telefonie verstanden werden. Dieser Abschnitt beschreibt typische Angriffe auf VoIP-Umgebungen und zeigt auf, welche Angriffsflächen sich auf verschiedenen Ebenen ergeben.

Typische Angriffe auf VoIP-Systeme

VoIP-Systeme sehen sich einer Vielzahl von Angriffsmustern ausgesetzt, die sowohl auf die Infrastruktur als auch auf die Nutzer abzielen. Im Folgenden sind einige der häufigsten Angriffsarten skizziert:

• SIP-Scanning und Brute-Force: Angreifer scannen IP-Adressbereiche gezielt nach offenen SIP-Servern oder -Diensten. Wird ein SIP-Dienst gefunden, erfolgen oft Brute-Force-Versuche, um Standard-Passwörter oder schwache SIP-Accounts zu kompromittieren. Ziel ist es, Zugang zu erhalten, um Gespräche unbefugt umzuleiten oder kostenpflichtige Anrufe tätigen zu können.
• Toll Fraud (Gebührenbetrug): Hierbei nutzen Angreifer offene oder gestohlene VoIP-Zugangsdaten, um hochpreisige Telefonate (z.B. zu Auslands- oder Premium-Nummern) auf Kosten des Unternehmens zu führen. Oft geschieht dies außerhalb der Geschäftszeiten, um lange Gespräche unbemerkt zu lassen. Die finanziellen Schäden können erheblich sein.
• Call Hijacking (Gesprächsübernahme): Bei dieser Attacke versucht der Angreifer, eine laufende Verbindung zu kapern oder umzuleiten. Dies kann beispielsweise durch das Injizieren manipulierter SIP-Signalisierung passieren (z.B. eine falsche Re-INVITE-Nachricht, die das RTP-Medienziel umbiegt). Gelingt dies, kann der Angreifer das Gespräch mithören oder die Verbindung unterbrechen.
• RTP-Abgriff (Eavesdropping): Ohne adäquate Verschlüsselung kann ein Angreifer, der Zugang zum Netzwerk hat, die ungeschützten RTP-Pakete mitschneiden und so Gespräche abhören. Selbst wenn SRTP eingesetzt wird, besteht bei falscher Konfiguration (z.B. wenn auf einen unverschlüsselten Fallback ausgewichen wird) die Gefahr des Abhörens.
• Denial of Service (DoS/DDoS): Durch gezielte Überflutung der VoIP-Infrastruktur mit Signalisierungsnachrichten (z.B. massenhaft INVITE-Anfragen) oder mit Medienverkehr (UDP-Floods) kann die Telefonie gestört oder ganz lahmgelegt werden. Besonders gefährlich sind Distributed DoS-Angriffe von vielen verteilten Quellen, denen SBCs oder Firewalls ohne speziellen Schutz kaum standhalten können.
• Signalisierungs-Anomalien und Protokoll-Exploits: Angreifer senden absichtlich fehlerhafte oder unerwartete SIP-Nachrichten, um Schwachstellen in der Implementierung auszunutzen. Beispiele sind Buffer Overflows durch zu lange Header-Felder oder Protokollstates, die zu Crashs führen. Auch SIP-ALG-Funktionen in Firewalls können durch ungewöhnliche Nachrichten aus dem Tritt gebracht werden.
• Missbrauch von CLIP no screening: Wenn ein Telefonanschluss die Übermittlung beliebiger ausgehender Rufnummern erlaubt (Feature Calling Line Identification Presentation no screening), kann ein interner oder extern kompromittierter Teilnehmer falsche Absendernummern signalisieren. Dadurch lässt sich z.B. eine Behörden- oder Vertrauensnummer vortäuschen, um das Vertrauen des Angerufenen zu erschleichen (Spoofing). In regulierten Umgebungen ist dies ein ernstzunehmendes Missbrauchspotential.
• Identitätsangriffe (Phishing, Token-Diebstahl): Da Teams-Telefonie eng an die Microsoft-365-Identität geknüpft ist, zielen Angriffe oft auf Benutzer- oder Administratorkonten. Phishing-Mails oder gefälschte Teams-Loginseiten werden verwendet, um Passwörter oder Authentifizierungs-Codes zu erbeuten. Auch das Abgreifen von Access Tokens oder Session Cookies kann einem Angreifer ermöglichen, einen Account zu übernehmen und damit Telefonie-Funktionen zu missbrauchen.
• Supply-Chain-Risiken: Hierbei wird die Vertrauenskette der eingesetzten Systeme angegriffen. Beispielsweise könnten manipulierte Firmware-Updates für SBCs oder IP-Telefone Schadfunktionen enthalten. Auch Hintertüren in Hardware oder vom Hersteller eingeschleuste Schwachstellen (bewusst oder unbewusst) gehören zu diesem Szenario. Da Unternehmen oft auf Drittanbieter (Hersteller, Dienstleister) vertrauen müssen, ist dies besonders schwierig zu kontrollieren.

Angriffsflächen nach Ebenen

Die oben genannten Angriffe zielen auf unterschiedliche Ebenen der Lösung ab. Es ist hilfreich, die Angriffsflächen systematisch pro Ebene zu betrachten:

• Identitäts-Ebene: Betrifft Benutzer- und Admin-Konten in Microsoft 365/Azure AD. Eine erfolgreiche Kompromittierung (z.B. durch Phishing) erlaubt Angreifern, sich legitimen Zugang zu verschaffen und dann Konfigurationen zu ändern oder Gespräche zu führen. Schutz erfordert hier starke Authentisierung und Überwachungsmechanismen.
• Client-Ebene: Betrifft die Endgeräte und Anwendungen (Teams-Client auf PC/Mobilgerät oder dediziertes Teams-Telefon). Schwachstellen im Betriebssystem oder in der Teams-App selbst können als Einfallstor dienen. Ebenso können kompromittierte Geräte (Malware) Gespräche mitschneiden oder die App manipulieren. Endpoint-Security und Device-Management sind daher essenziell.
• Netzwerk-/Transport-Ebene: Hier geht es um die Datenübertragung im internen Netz und über das Internet. Angriffe wie Eavesdropping, Man-in-the-Middle oder DoS zielen auf diese Ebene. Ungesicherte Protokolle oder offene Firewalls bieten Angriffsfläche. Abhilfe schaffen Verschlüsselung (TLS/SRTP), Segmentierung und Netzwerküberwachung.
• Infrastruktur-Ebene (SBC/Firewall): Der SBC selbst und die Firewall/Router im Pfad stellen kritische Infrastruktur dar. Sie sind oft direkt aus dem Internet erreichbar (SBC am SIP-Trunk, Firewall an sich) und damit Angriffen wie Portscans, Exploit-Versuchen oder Überlastung ausgesetzt. Eine Härtung dieser Systeme, regelmäßige Updates und Begrenzung des Zugriffs sind hier entscheidend.
• Provider- und Cloud-Ebene: Sowohl der Telefonie-Provider als auch der Cloud-Dienst (Microsoft Teams) können Angriffsfläche bieten. Etwa könnten beim Provider Routing-Manipulationen auftreten oder bei Microsoft verbleibende Schwachstellen in der Cloud-Infrastruktur bestehen. Obwohl man auf die Sicherheit dieser externen Komponenten wenig direkten Einfluss hat, sollte man zumindest die Schnittstellen (z.B. Zertifikatsprüfung beim SIP-Trunk, redundante Provider) absichern und vertragliche Security-Vereinbarungen treffen.
• Administrations-Ebene: Ein oft vernachlässigter Aspekt ist die Sicherung der Betriebsprozesse. Fehler oder Insider-Angriffe bei Konfigurationsänderungen, unzureichende Rechteverwaltung oder fehlende Kontrolle über Änderungen können ebenfalls Risiken darstellen. Prinzipien wie Vier-Augen-Prinzip, Change Management und Protokollierung aller Admin-Aktionen mindern diese Gefahr.

Die folgende Tabelle zeigt exemplarisch verschiedene Angriffskategorien, die betroffene Ebene, sowie empfohlene Kontrollen und verbleibende Restrisiken:

Angriffskategorie	Betroffene Ebene	Wichtige Kontrollen	Restrisiko
SIP-Scanning & Brute-Force	SBC/Service	IP-Restriktionen, starke Passwörter/Kein Standard-Login, Rate-Limits	Gering (bei IP-Whitelist); sonst moderat
Toll Fraud (Gebührenbetrug)	Identität/Provider	Ausgehende Routen einschränken (z.B. Ausland), Anruflimits, Monitoring von Nutzungsverhalten	Mittel (wenn neue Lücken ausgenutzt oder interne Täter)
Call Hijacking	Signalisierung	Durchgehende TLS-Verschlüsselung, Message Authentication, SBC mit Session-Handling	Gering (bei lückenloser Verschlüsselung); intern weiterhin möglich
Abhören von RTP	Netzwerk	Einsatz von SRTP für alle Medien, physische Netzwerksicherheit	Sehr gering (bei erzwungener Verschlüsselung); sonst hoch
DoS/DDoS	Netzwerk/SBC	Firewall mit DoS-Schutz, Upstream-DDoS-Protection, Lastverteilung/Redundanz	Mittel bis hoch (Restrisiko durch volumetrische Angriffe bleibt)
SIP-Protokoll-Exploits	SBC/Client	Aktuelle Patches/Firmware, SIP-ALG deaktivieren wenn unnötig, IPS-Signaturen für VoIP	Gering (wenn Systeme aktuell); Zero-Days bleiben möglich
CLIP no screening Missbrauch	Policy/Provider	Strikte Begrenzung zulässiger Absendernummern, Monitoring aller ausgehenden CLI, Schulung	Mittel (bei Insider-Angriff oder gestohlenen Accounts weiterhin Risiko)
Identitätsdiebstahl	Identität/Benutzer	MFA und Conditional Access, Security-Awareness-Training, schnelles Sperren bei Verdacht	Mittel (Phishing-Methoden entwickeln sich weiter)
Supply-Chain Angriff	Infrastruktur	Signierte Software/Firmware, Lieferantenprüfung, Netzwerksegmentierung für Updates	Niedrig (selten, aber mit potenziell hoher Auswirkung)

4. Identität, Zugriff & Mandantensicherheit (Teams/Microsoft 365)

Die Sicherheit von Microsoft Teams-Telefonie hängt maßgeblich von der Sicherheit der Identitäten (Benutzer- und Administratorkonten) und einer robusten Mandantenkonfiguration in Microsoft 365 ab. In diesem Kapitel werden Maßnahmen zur Härtung von Identitäten und Zugriffswegen beschrieben, spezielle Telefonie-Policies beleuchtet sowie die wichtigen Logging- und Auditing-Möglichkeiten im Microsoft-365-Mandanten angesprochen.

Härtung von Identitäten und Zugriffswegen

Microsoft 365 und Teams setzen auf Azure Active Directory als Identitätsplattform. Es gilt der Grundsatz: Kein Zugriff ohne starke Identitätssicherung. Als erstes ist eine konsequente Multi-Faktor-Authentifizierung (MFA) für alle Benutzer durchzusetzen – insbesondere aber für Administratoren wie den Teams-Serviceadministrator, Telefon-Systemadministrator etc. MFA verhindert, dass ein geleaktes Passwort allein zum Kontoübernahme führt. Ergänzend sollte Conditional Access genutzt werden: Hierüber lässt sich der Zugriff z.B. auf vertrauenswürdige Netzwerkstandorte oder compliant Devices beschränken. So könnte man festlegen, dass Admin-Aktionen nur vom firmeninternen Netz oder per VPN zulässig sind, oder dass sich Benutzer der Telefonie-App nur auf verwalteten, aktuellen Geräten anmelden dürfen.

Wichtig ist auch das Prinzip der minimalen Rechte (Least Privilege): Administratorrollen in Teams/M365 sparsam vergeben und möglichst aufteilen (z.B. separate Rolle für Telefonie vs. allgemeine Admins). Funktionen wie Privileged Identity Management (PIM) in Azure AD helfen, dass höhere Rechte nur temporär und nach Genehmigung aktiviert werden. Für den Notfall sollten Break-Glass-Konten existieren (z.B. ein globaler Admin ohne MFA, dessen Zugang aber streng geschützt und nur offline hinterlegt ist), um bei Ausfall des normalen Identity-Providers handlungsfähig zu bleiben. Diese Konten müssen regelmäßig auf Funktion geprüft, aber ansonsten nicht benutzt werden.

Richtlinien für Teams-Telefonie und Benutzer

Die Microsoft-Teams-Plattform bietet diverse Sicherheitsrichtlinien, die speziell die Nutzung von Telefonie und Meetings betreffen. Eine Option ist beispielsweise die Ende-zu-Ende-Verschlüsselung (E2EE) für 1:1-Anrufe in Teams. Diese kann tenant-weit erlaubt oder verboten werden. Wenn höchstmögliche Vertraulichkeit einzelner Gespräche benötigt wird (z.B. in Vorstandstelefonaten), sollte E2EE erlaubt und entsprechend dokumentiert werden – man muss aber beachten, dass bei E2EE bestimmte Funktionen wie Aufzeichnung oder das Hinzuschalten weiterer Teilnehmer deaktiviert sind.

Weiterhin sind App-Berechtigungen in Teams im Blick zu behalten. Drittanbieter-Apps oder Bots könnten theoretisch auf Anrufdaten oder Voicemails zugreifen, wenn zu großzügig berechtigt. Es empfiehlt sich, nur vertrauenswürdige Apps im Tenant zuzulassen und Berechtigungen regelmäßig zu überprüfen. Bei Voicemail gilt: Wenn PINs oder Authentifizierung für die Abfrage der Mailbox eingerichtet werden können, sollten diese aktiviert und mit sicheren PINs versehen sein, um zu verhindern, dass Unbefugte Mailbox-Nachrichten abhören. Auch Funktionen wie Call Queues und Auto Attendants sollten mit Bedacht konfiguriert werden – z.B. sollten nur berechtigte Personen auf Voicemail-Aufzeichnungen in Warteschlangen zugreifen können und Durchwahlen für sensible Bereiche nicht öffentlich bekannt gemacht werden.

Überwachung und Protokollierung im Microsoft 365 Tenant

Die beste Prävention nützt wenig ohne Transparenz: Daher ist es unumgänglich, die verfügbaren Protokolle auszuwerten. Azure AD stellt Anmelde- und Sign-in-Logs bereit, aus denen ungewöhnliche Anmeldeversuche (z.B. mehrfach fehlgeschlagene Logins, Anmeldeversuche aus fremden Ländern) hervorgehen. Im Unified Audit Log von Microsoft 365 werden zudem Änderungen und Aktionen protokolliert – etwa wenn ein Administrator Routing-Einstellungen der Telefonie ändert oder ein neuer Nutzer mit Telefon-Lizenz angelegt wird. Diese Logs sollten in regelmäßigen Abständen geprüft oder idealerweise automatisiert auf Auffälligkeiten gescannt werden.

Speziell für Teams-Telefonie gibt es Anrufdatensätze und Qualitätsberichte (Call Detail Records, CDR sowie im Teams Admin Center abrufbare Informationen pro Call). Diese dienen primär der Qualitätssicherung, können aber auch bei der Forensik helfen – z.B. lässt sich nachvollziehen, wenn ein Konto plötzlich ungewöhnlich viele Auslandsanrufe initiiert hat. Eine Integration der Microsoft-Logs in ein zentrales SIEM-System (Security Information and Event Management) ist empfehlenswert. So können Korrelationen hergestellt und Alarme ausgelöst werden, wenn z.B. ein Admin-Login und kurz darauf eine Anrufweiterleitung auf eine externe Nummer eingerichtet wird (mögliches Indiz für Account Missbrauch). Die Mandantensicherheit erfordert somit nicht nur präventive Maßnahmen, sondern auch kontinuierliche Überwachung der Identitäten und Aktionen.

5. Protokolle, Verschlüsselung & Medienwege

In einer VoIP-Umgebung sind die richtigen Protokolle und ihre Konfiguration entscheidend für Sicherheit und Funktion. Dieser Abschnitt behandelt, wie Verschlüsselung in Signalisierung und Medienströmen umgesetzt wird, wie VoIP-Daten durch NAT-Traversal ihren Weg ins Internet finden und welche Zielkonflikte zwischen Quality of Service (QoS) und tiefgreifenden Sicherheitskontrollen bestehen.

Verschlüsselung von Signalisierung und Medien

Der Schutz der Vertraulichkeit und Integrität von Anrufen hat oberste Priorität. Daher sollten Signalisierungsdaten (die Gesprächsaufbau- und Steuerungsnachrichten via SIP/Teams) stets mit Transport Layer Security (TLS) verschlüsselt übertragen werden. Im Kontext von Microsoft Teams ist dies bereits fest verankert: Der Direct Routing-Signalisierungsverkehr zwischen dem SBC und dem Microsoft Phone System erfolgt ausschließlich über mutual TLS (mTLS) auf Port 5061, wobei sich beide Seiten anhand von Zertifikaten authentifizieren. Auch zwischen Teams-Client und Microsoft-Cloud wird die Kommunikation über HTTPS/TLS geschützt. Somit sind Abhörversuche oder Manipulationen der Signalisierung auf Transportebene weitgehend vereitelt.

Für die Medienströme (Audio, Video) kommt Secure RTP (SRTP) zum Einsatz, das die RTP-Pakete verschlüsselt und via Authentifizierung schützt. Die Schlüsselvereinbarung hierfür geschieht im Teams-Umfeld automatisch und für den Administrator transparent – z.B. im Rahmen von SIP/SDP-Aushandlung oder mittels DTLS (Datagram TLS) auf den Medienports. Wichtig ist, dass durchgängig Ende-zu-Ende bzw. Ende-zu-Server verschlüsselt wird: Vom Teams-Client bis zum Microsoft-Media-Relay und weiter bis zum SBC nutzt Teams standardmäßig SRTP. Zwischen SBC und eigenem Provider-Trunk hingegen ist Verschlüsselung nicht immer garantiert – hier sollte nach Möglichkeit ebenfalls TLS/SRTP eingesetzt werden (viele SIP-Provider bieten SIP über TLS an, ggf. kombiniert mit IPsec oder VPN-Tunneln bei MPLS-Anbindungen). Unverschlüsselte Verbindungen (z.B. SIP auf Port 5060 oder RTP ohne SRTP) sollten in einem modernen Enterprise-Setup grundsätzlich vermieden werden.

NAT-Traversal mit ICE, STUN und TURN

Wie in Abschnitt 2 erwähnt, nutzen VoIP/UC-Lösungen Mechanismen wie ICE, STUN und TURN, um Verbindungen über NAT-Grenzen hinweg aufzubauen. Aus Sicherheitssicht ist wichtig zu verstehen, welche Implikationen dies hat: Ein Teams-Client in einem internen Netzwerk wird versuchen, direkt mit dem Gegenüber (oder dem Microsoft Medien-Endpunkt) zu kommunizieren. Ist jedoch NAT im Spiel, werden über STUN öffentliche IP-Adressen ermittelt. Dies bedeutet, dass die internen IPs eines Clients an einen externen STUN-Server (z.B. stun.teams.microsoft.com über UDP 3478) gesendet und dort geloggt werden könnten. Zwar sind STUN-Pakete klein und enthalten kaum sensible Daten, dennoch offenbaren sie einem externen Dienst die Existenz eines internen Clients. Dies ist an sich kein gravierender Risikofaktor, sollte aber dokumentiert sein (Stichwort Datenschutz).

Kritischer kann TURN sein: Wenn direkte Verbindungen scheitern (was in strikten Firewalls häufig der Fall ist), leiten Teams-Clients ihre Medien über einen Microsoft-TURN-Server um (auch auf UDP 3478-3481 oder TCP 443). Dadurch fließen Audio/Video-Daten über einen dritten Knoten. Diese Verbindung ist zwar verschlüsselt (SRTP innerhalb von TLS), dennoch muss der Firewall diese Ausgänge erlauben. Eine potenzielle Gefahr besteht darin, dass ein Angreifer die Notwendigkeit von TURN ausnutzt, um Traffic umzulenken – zum Beispiel könnten misconfigurierte Clients einen falschen TURN-Server nutzen. In der Praxis ist dieses Risiko gering, solange nur von Microsoft vorgesehene TURN-Server genutzt werden (z.B. durch harte Vorgaben im Client oder in der Teams-Infrastruktur). Aus Admin-Sicht sollte man jedoch wissen, dass Firewalls entsprechend konfiguriert sein müssen: Sie müssen ausgehende STUN/TURN-Verbindungen zulassen (zu Microsofts IP-Bereichen), gleichzeitig aber alle nicht benötigten UDP-Ports sperren, um Missbrauch zu minimieren.

QoS vs. Security: Priorisierung ohne Sicherheitslücken

Quality of Service (QoS) Maßnahmen stellen sicher, dass Sprach- und Videoübertragung priorisiert über das Netzwerk laufen, um geringe Latenz und Paketverluste zu erreichen. In klassischen Netzwerken wird hierfür meist mit DSCP-Markierungen (Differentiated Services Code Point) gearbeitet – z.B. EF (Expedited Forwarding) für Sprache, AF41 für Video, etc., die von Switches und Routern entsprechend bevorzugt behandelt werden. Ein Problem entsteht, wenn Sicherheitsmechanismen (wie tiefgehende Paketinspektion oder Proxy-Decryption) die Latenz erhöhen oder bestimmte Verbindungen verzögern/unterbrechen. Beispielsweise kann das Entschlüsseln von TLS-Datenströmen für Content Inspection die Sprachqualität beeinträchtigen. Andererseits besteht die Gefahr, dass zu großzügige QoS-Regeln einem Angreifer erlauben, eigenen Traffic als high priority zu tarnen, um Filter zu umgehen.

Der Trade-off zwischen QoS und Security muss bewusst gesteuert werden: Kritische Sprach- und Videoströme sollten priorisiert werden, aber mit so wenig Sonderausnahmen wie möglich. In der Praxis werden Firewalls für bekannte Dienste wie Teams so eingestellt, dass sie den Traffic anhand von IPs/Ports identifizieren und priorisieren, ohne jedoch in die Verschlüsselung einzugreifen. TLS-Inspection wird für diese Kategorien oft deaktiviert (was ein kalkuliertes Risiko darstellt – siehe Abschnitt 8 zum Thema TLS-Bypass). Wichtig ist, die QoS-Regeln nur auf authentifizierte bzw. klar definierte Quellen anzuwenden (z.B. auf den SBC oder auf Geräte im Voice-VLAN), damit kein Fremdtraffic bevorzugt durchs Netz gelangen kann. Außerdem sollten trotz Priorisierung Basis-Sicherheitskontrollen aktiv bleiben – etwa Paketgrößen-Checks oder einfache SIP-Header-Prüfungen – um offensichtliche Angriffe nicht blind durchzuwinken. Die Kunst liegt darin, die Balance zu finden: maximale Sprachqualität bei gleichzeitig hoher Sicherheitsgarantie.

6. Netzwerk- und Perimeter-Sicherheit

Die Netzwerksicherheit bildet die Grundlage, um VoIP-Dienste vor unberechtigtem Zugriff und Überlast zu schützen. Gerade an der Perimeter-Firewall, welche das interne Netz mit dem Internet verbindet, müssen Regeln und Schutzmechanismen für VoIP richtig eingestellt sein. Hier werden Empfehlungen zur Netzwerk-Segmentierung, zum restriktiven Umgang mit ausgehendem Verkehr und zum Schutz vor Überlastungsangriffen gegeben.

Segmentierung der VoIP-Umgebung

Ein bewährtes Konzept ist die Segmentierung: Das VoIP-System sollte nicht im flachen Netzwerk mit allen anderen Diensten laufen. Stattdessen richtet man separate VLANs bzw. Subnetze ein, beispielsweise ein eigenes Voice-VLAN für IP-Telefone und ggf. separate Netze für Videokonferenzsysteme. Auch der SBC sollte in einem eigenen Netzwerksegment (z.B. DMZ) platziert sein, getrennt vom internen LAN. Dadurch erreicht man, dass ein kompromittiertes Gerät in einem Segment (etwa ein infiziertes Büro-PC) nicht direkt auf den SBC oder Telefoniegeräte zugreifen kann, weil die Firewall zwischen den Segmenten dies reguliert. Die Kommunikation zwischen den Segmenten (Voice-VLAN ↔ Daten-LAN ↔ SBC-DMZ ↔ Internet) erfolgt dann über definierte Firewall-Regeln, was die Angriffsfläche deutlich reduziert.

Darüber hinaus können Management-Netze eingerichtet werden: Administrative Zugriffe auf den SBC, die Telefonanlagen-Software oder andere UC-Komponenten sollten nur aus einem speziellen Admin-Netz (oder via Jump-Server) möglich sein. Dies verhindert, dass jemand aus dem normalen User-LAN auf Admin-Schnittstellen gelangt. Die Segmentierung sollte auch im WLAN und bei Remote-Zugriffen (VPN) durchgehalten werden – etwa indem Heimarbeitsplätze auf definierte VPN-Subnetze terminiert werden, die ebenfalls passenden Netzsegmenten zugeordnet sind.

Egress-Kontrolle und beschränkte Ports

Unter Egress-Kontrolle versteht man die Einschränkung des ausgehenden Datenverkehrs auf das Notwendige. Für Microsoft Teams und Microsoft 365 gibt es klare Anforderungen, welche Ziele (FQDNs und IP-Ranges) und Ports benötigt werden. Eine sichere Firewall-Policy erlaubt nur Verbindungen von internen Clients und dem SBC zu diesen definierten Zielen. Moderne Firewalls wie die Sophos XGS unterstützen FQDN-Hostobjekte oder Service-Tags für Microsoft-Dienste, wodurch sich dynamisch alle IP-Adressen hinter z.B. *.teams.microsoft.com erlauben lassen. Wo das nicht verfügbar ist, muss man die regelmäßigen Updates der IP-Listen von Microsoft manuell pflegen. In jedem Fall sollte die Firewall ausgehend nicht einfach alles ins Internet erlauben, sondern nur die Dienste: beispielhaft UDP 3478-3481 zu den Teams-Media-IP-Bereichen, TCP 443 zu den Teams- und 365-Frontdoor-FQDNs, DNS-Anfragen zu den vorgesehenen DNS-Servern etc. Alle anderen ausgehenden Ports (besonders 0-1024) können in der Regel für normale Clients geschlossen bleiben, was die Exploit-Möglichkeiten stark reduziert.

Bei der Egress-Kontrolle ist auch an Notfallszenarien zu denken: Falls z.B. ein Proxy oder Webfilter im Einsatz ist, muss sichergestellt sein, dass dieser die UDP-Medien nicht blockiert (meist müssen solche Filter für VoIP umgangen werden). Auch sollten alternative Pfade für wichtige Dienste definiert sein – etwa ein Fallback, falls der primäre Internetanschluss ausfällt, damit Telefonie noch möglich ist.

Schutz vor DoS- und DDoS-Angriffen

Einer der gravierendsten Angriffe auf VoIP-Systeme ist der Denial of Service. Eine Flut an sinnlosen Anfragen kann Sprachdienste unbrauchbar machen. Auf Netzwerkebene bieten Firewalls und Router verschiedene Mechanismen zum DoS-Schutz: z.B. Syn-Flood-Protection, Limitierung gleichzeitiger halboffener Verbindungen, oder Erkennung von gleichförmigen Traffic-Mustern (wie viele gleichzeitige UDP-Pakete auf den SIP-Port). Diese sollten für die relevanten VoIP-Services aktiviert und auf geeignete Schwellwerte gesetzt sein. Beispielsweise kann man einstellen, dass von einer einzelnen IP-Adresse nur eine bestimmte Anzahl SIP-Verbindungsaufbauversuche pro Sekunde akzeptiert werden. Auch der SBC selbst verfügt oft über eingebaute Rate Limits (z.B. maximale Calls per Second), die als Backstop konfiguriert werden können.

Gegen großvolumige DDoS-Angriffe aus dem Internet stößt allerdings jede Unternehmens-Firewall ab einer gewissen Größe an Grenzen. Hier sollte man im Vorfeld mit dem Internet-Provider abklären, ob DDoS-Mitigation bereitsteht – etwa Umleitung des Traffics durch Scrubbing-Center, solange ein Angriff andauert. Für die Telefonie kann es sinnvoll sein, dedizierte Bandbreite oder separate IP-Adressbereiche zu verwenden, damit im Ernstfall nicht das gesamte Firmennetz mit betroffen ist. Des Weiteren sollten Anomalien im Traffic via Monitoring erkannt werden (z.B. plötzlicher Anstieg von UDP-Daten auf ungewöhnlichen Ports), um schnell reagieren zu können. Insgesamt ist eine Kombination aus präventiven Limits, Überwachung und – im Worst Case – Notfallmaßnahmen (bis hin zum temporären Blockieren aller externen VoIP-Zugänge) erforderlich, um die Auswirkung von DoS/DDoS-Angriffen zu minimieren.

7. SBC-Sicherheit (Direct Routing)

Bei Einsatz von Direct Routing übernimmt ein unternehmenseigener oder gemieteter Session Border Controller die Vermittlung zwischen Microsoft Teams und dem Telefonnetz. Der SBC ist damit ein zentrales Element, dessen Sicherheit kritisch für die Gesamtinfrastruktur ist. In diesem Kapitel wird erläutert, wie ein SBC gehärtet wird, wie die Verbindung zum Telefonie-Provider sicher gestaltet ist und welche Vorkehrungen für Hochverfügbarkeit und Notrufe getroffen werden sollten.

Härtung des Session Border Controllers

Ein SBC sollte nach denselben Prinzipien wie ein sicherheitskritischer Server gehärtet werden. Dazu gehört erstens die Absicherung der Management-Zugänge: Administrative Interfaces (Web-GUI, SSH, API) sollten nur aus einem definierten Management-Netz oder über einen Jump-Host erreichbar sein. Falls möglich, sollte eine zusätzliche Authentifizierung (MFA oder zumindest IP-basierte Zugriffsliste) vorgeschaltet werden. Standard-Login-Konten und Passwörter sind nach Inbetriebnahme umgehend zu ändern. Wo es geht, sind auch Rollentrennung auf dem SBC zu nutzen (z.B. separate Accounts für Monitoring vs. Konfiguration, um nicht jedem Admin Vollzugriff zu geben).

Für den Signalisierungsverkehr mit Teams muss der SBC ein gültiges TLS-Zertifikat besitzen (von einer öffentlichen CA, die Microsoft vertraut). Dieses Zertifikat und der private Schlüssel sind auf dem SBC zu schützen (idealerweise Hardware-Sicherheitsmodule nutzen, sofern unterstützt). Die Kryptografie-Einstellungen des SBC sollten überprüft werden: Veraltete Protokolle wie TLS 1.0/1.1 und schwache Chiffren (z.B. RC4, 3DES) sind zu deaktivieren, sodass nur starke Suites (TLS 1.2+ mit AEAD-Chiffren) benutzt werden. Viele SBCs erlauben das Feintuning, welche Ciphers und Protokollversionen im SIP mTLS Handshake angeboten werden – hier sollte man sich an aktuellen BSI-/NIST-Empfehlungen orientieren. Auch für die SIP-Session selber gilt es unnötige Funktionen abzuschalten: z.B. keine anonymen SIP-Redirects erlauben, OPTIONS-Pings von unbekannten Quellen ignorieren und Debug-Interfaces (SIP-Traces) nicht offen im Netz laufen lassen.

Absicherung des SIP-Trunks zum Provider

Die zweite Schnittstelle des SBC ist Richtung Telefonie-Provider (SIP-Trunk oder Primärmultiplex-Anschluss). Wenn der Provider moderne SIP-Trunks anbietet, sollte auch hier SIP über TLS mit mutual Authentication eingesetzt werden, sodass die Signalisierung verschlüsselt und nur zwischen authentifizierten Endpunkten erfolgt. Allerdings setzen einige Provider noch auf unverschlüsseltes SIP über dedizierte Leitungen oder VPN. In solchen Fällen muss zumindest die Firewall auf IP-Ebene strikt einschränken, welche IPs/Ports auf den SBC zugreifen dürfen.

Ein wichtiger Punkt ist Anti-Spoofing: Der SBC darf nur Nachrichten von erwarteten IP-Adressen und mit korrekten Headern annehmen. Damit wird verhindert, dass jemand von außen Pakete einspeist, die vorgaukeln vom Provider zu kommen. Im SBC kann man oft sogenannte Ingress-Firewallregeln konfigurieren oder es überlässt dies der vorgeschalteten Firewall. Zusätzlich ist es sinnvoll, im SBC Anruf-Limits pro Zeit für den Trunk zu setzen, um bei einem kompromittierten Account oder Fehlverhalten auf Providerseite nicht unlimitiert Gespräche ins Netz zu lassen (Schutz vor Gebührenbetrug).

Weiterhin sollten beide Seiten – Provider und Unternehmen – klare Regeln zur Authentifizierung und Autorisierung der Rufnummern haben: z.B. nur bestimmte Rufnummernkreise akzeptieren, die dem Kunden zugewiesen sind, und ausgehende Anrufe mit nicht zugewiesenen Absendernummern blockieren. Hier schließt sich der Kreis zum Thema CLIP no screening (vgl. Kapitel 3 und 9): Durch technische und vertragliche Maßnahmen muss sichergestellt sein, dass die eigenen Durchwahlen nicht von Dritten benutzt werden können und umgekehrt.

Hochverfügbarkeit, Failover und Notrufkonzept

Telefonie gehört zu den geschäftskritischen Diensten – daher ist eine hochverfügbare Architektur anzustreben. Bei Direct Routing kann dies bedeuten, zwei SBCs redundant zu betreiben. Microsoft Teams erlaubt die Konfiguration von mehreren SBCs pro Tenant; fällt einer aus, werden eingehende Anrufe vom Microsoft-Cloud-PSTN automatisch zum zweiten SBC geleitet (nach dem Prinzip Failover). Die beiden SBCs sollten geografisch und netzwerktechnisch getrennt sein (z.B. in unterschiedlichen Rechenzentren oder Standorten), um auch Standortausfälle abzufangen. Intern ist sicherzustellen, dass die Firewalls und Router das Failover unterstützen (z.B. virtueller IP-Adresswechsel oder DNS-basiertes Lastverteilungsverfahren, je nach SBC-Fabrikat).

Neben der SBC-Redundanz ist auch die Provider-Seite oft redundant auslegbar: Viele SIP-Trunk-Anbieter bieten Backup-Routen oder Zweit-Pops an, die man im SBC als sekundären Proxy eintragen kann. Damit ließen sich z.B. Ausfälle im Netz des Providers umgehen, falls dieser über mehrere Gateways verfügt. Wichtig ist, solche Failover-Szenarien regelmäßig zu testen – etwa durch gezieltes Abschalten eines SBCs und Prüfen, ob laufende Gespräche gehalten werden oder zumindest neue automatisch umgeleitet werden.

Ein spezieller Aspekt ist die Notruf-Erreichbarkeit (z.B. 112/110 im DACH-Raum): Hier darf es kein Single Point of Failure geben. Beim Übergang von klassischer TK-Anlage zu Teams muss geplant werden, wie Notrufe auch bei Ausfall der Cloud oder Internetverbindung abgesetzt werden können. Optionen sind z.B. an größeren Standorten eine lokale Notfall-Leitung (analoger Anschluss oder Mobilfunk-Gateway), die über ein Notfalltelefon genutzt wird, falls der SBC oder die WAN-Verbindung down sind. In Teams selbst kann man für jeden Standort definieren, wie Notrufe geroutet werden (Emergency Address und Routing Policies), was sicherzustellen ist. Ein regelmäßiger Test der Notrufe – in Abstimmung mit der lokalen Leitstelle, um Fehlalarme zu vermeiden – sollte fest in den Betrieb integriert sein.

Die folgende Tabelle gibt Beispiele, wie Notruf-Szenarien über verschiedene Wege sichergestellt und geprüft werden können:

Standort/Szenario	Notruf-Routing	Testintervall	Fallback-Lösung	Nachweisführung
Zentrale (Hauptsitz)	Über primären SBC -> SIP-Trunk -> lokaler Leitstellen-Router (mit Standortinfo)	Vierteljährlich Testcall mit Polizei vereinbaren	Redundanter SBC am Hauptsitz; zusätzlich Mobiltelefon als Backup	Protokoll des Testanrufs (Datum, Uhrzeit, Ergebnis)
Zweigstelle A (andere Stadt)	Über VPN zum Hauptsitz-SBC, dann wie Zentrale	Halbjährlich interner Notruf-Test (Nummer zu interner Sicherheitsstelle)	Lokaler Analog-Anschluss in Zweigstelle für direkten Notruf bei WAN-Ausfall	Dokumentation in Notfallhandbuch, jährliche Bestätigung der Funktion
Home Office/Mobil	Über lokalen Mobilfunk/Telefonanschluss des Nutzers (Teams-Client wählt automatische 112 lokal)	Jährliche Sensibilisierung der Nutzer, kein direkter Test möglich	Hinweis an Benutzer, im Notfall Handy oder Festnetz vor Ort zu nutzen	Schulungsnachweis und Policy für mobiles Arbeiten

8. Sophos XGS – Konkrete Firewall-Beispiele

In diesem Kapitel werden praktische Firewall-Konfigurationen anhand einer Sophos XGS Firewall aufgezeigt, um die zuvor besprochenen Anforderungen umzusetzen. Dies umfasst die Definition passender Objekte, Regeln für Microsoft Teams-Telefonie, NAT-Einstellungen, IPS-Anpassungen, Ausnahmen für TLS-Inspektion, QoS-Konfiguration sowie High-Availability-Aspekte. Ziel ist es, ein klares Bild zu vermitteln, wie eine realitätsnahe Firewall-Policy für Teams-Telefonie aussehen kann – neutral und ohne Produktwerbung, aber mit typischen Einstellungen und Stolperfallen.

Firewall-Objekte und Dienste für Microsoft Teams

Zu Beginn empfiehlt es sich, in der Firewall alle relevanten Objekte anzulegen, um die Regeln übersichtlich gestalten zu können. Dazu gehören:
– FQDN-Hostgruppen für Microsoft-365/Teams-Dienste: z.B. eine Gruppe „Microsoft Teams Cloud“ mit Einträgen wie *.teams.microsoft.com, *.trafficmanager.net, *.azureedge.net und weiteren, die Microsoft für Teams-Medien nutzt. Diese FQDN-Objekte nutzt die Firewall, um dynamisch die IP-Adressen aufzulösen, die hinter den Cloud-Domains stecken.
– Netzwerkobjekte für eigene Komponenten: z.B. die lokale SBC-IP (oder IPs, falls mehrere), die IP-Bereiche des Voice-VLANs etc., um in Regeln gezielt diese Bereiche ansprechen zu können.
– Service-Objekte/-Gruppen für VoIP-Protokolle: Beispielsweise ein Service-Objekt „SIP_TLS_5061“ (TCP/5061) für SIP über TLS; ein Objekt „SIP_5060“ (UDP/5060) falls notwendig (für unverschlüsseltes SIP, sollte aber möglichst nicht offen sein); eine Gruppe „Teams_Media_Ports“ (UDP/3478-3481 und ggf. UDP/50.000-50.059 falls Teams solche Ports nutzt) usw. Auch RTP/SRTP-Portbereiche des eigenen SBC können als Service-Objekt definiert werden (häufig z.B. UDP 10.000-20.000).
– Anwendungsfilter (App Control): Sofern die Firewall über Application Control verfügt, kann man Microsoft Teams als Anwendung oder Kategorie markieren, um gezielt Traffic zu identifizieren. Dies ist insbesondere hilfreich, um den Webbrowser-Teams-Traffic von generischem HTTPS zu unterscheiden, falls Web-Proxy-Regeln im Spiel sind.

Mit solchen vordefinierten Objekten wird die eigentliche Regelkonfiguration deutlich einfacher und wartbarer.

Ports, Protokolle und Kommunikationsflüsse

Bevor einzelne Firewall-Regeln definiert werden, ist es wichtig, die erforderlichen Kommunikationsflüsse von Teams-Telefonie zu verstehen. Die folgende Tabelle stellt typische Ports und Richtungen dar, die freigeschaltet werden müssen:

Quelle	Ziel	Richtung	Protokoll/Port	Zweck	Anmerkung
Teams-Client (intern oder VPN)	Microsoft Teams Cloud (Microsoft 365)	Ausgehend	TCP 443	Teams-Signalisierung (Call Setup, Meetings)	Über HTTPS/TLS, inkl. Web-Services
Teams-Client (intern oder VPN)	Microsoft STUN/TURN-Server	Ausgehend	UDP 3478-3481	NAT-Traversal (STUN, Medienrelay)	Fallback auf TCP 443 möglich bei UDP-Blockade
SBC (DMZ)	Microsoft PSTN-Hub (*.pstnhub.teams.microsoft.com)	Ausgehend/ Eingehend	TCP 5061 (TLS)	SIP-Signalisierung Direct Routing	mTLS, feste FQDNs pro Region
SBC (DMZ)	Microsoft Media Processor (Azure)	Ausgehend/ Eingehend	UDP 50000-59999 (SRTP)	Audio/Video-Medienstrom zwischen SBC und Teams	Exakter Portbereich im SBC und MS Teams definiert
SBC (DMZ)	SIP-Trunk Provider (z.B. SIP-Proxy des Carriers)	Ausgehend/ Eingehend	TCP/UDP 5060-5061	SIP-Signalisierung zum Provider	Bei TLS wenn unterstützt, sonst UDP/TCP 5060
SBC (DMZ)	Telefonie-Provider Media Gateways	Ausgehend/ Eingehend	UDP 10000-20000 (RTP)	Audio-Medien zum/vom Provider-Netz	Portbereich je nach Provider-Absprache
Admin-PC (Jump-Host)	SBC-Management-IP (intern)	Ausgehend	TCP 22,443	Management (SSH, Web-GUI)	Nur aus MGMT-Netz erlaubt
Teams-Client (mobil, extern)	Microsoft Teams Cloud	Ein/ausgehend (via Internet)	UDP 3478-3481, TCP 443	Teams-Sprachverkehr von HomeOffice/Mobile	Nicht über Firmen-FW, aber erwähnenswert im Gesamtkontext

Die obige Übersicht verdeutlicht: Hauptsächlich muss die Firewall aus dem internen Netz bzw. der SBC-DMZ zu bestimmten Cloud-Services (Teams) und Providern kommunizieren lassen. Eingehende Verbindungen aus dem Internet direkt ins LAN sind bei Teams (ohne lokalen Server) nicht nötig – nur der SBC empfängt eingehende SIP/Media vom Provider und ggf. von Microsoft. Im Folgenden werden nun konkrete Regeln skizziert.

Beispiel-Regelwerke für Teams-Telefonie

Basierend auf den definerten Objekten und Flows können die Firewall-Policies entworfen werden. Eine Möglichkeit ist, die Regeln nach Zweck zu gruppieren, z.B.:
1. Teams/M365-Egress – steuert Verbindungen von internen Clients zu Microsoft 365/Teams.
2. SBC ↔ Provider/Teams – steuert Verbindungen zwischen dem SBC und dem Telefonie-Provider sowie zu Microsoft (Direct Routing).
3. VoIP-Management – steuert Administrative Zugriffe auf VoIP-Systeme.
4. Notfall/Break-Glass – eine deaktivierte Reserve-Regel für den Notfall.

Tabelle: Beispiel-Regelübersicht einer Sophos XGS Firewall:

Regel-ID	Zweck	Quelle -> Ziel	Dienste/Anwendungen	App-Control	Web/TLS-Ausnahme	Logging
10	Teams/M365-Egress: Teams-Client Traffic zu MS-Cloud	LAN/Voice VLAN -> Internet (nur Microsoft 365 FQDN-Gruppe)	MS Teams (App) oder Ports 443,3478-3481 (UDP/TCP)	Microsoft Teams Kategorie erlaubt	Ja (nicht inspizieren, da MS-Cloud)	An
20	SBC ↔ Provider/Teams: Signalisierung & Medien	SBC-DMZ -> Internet (Provider-IP + MS-FQDN) <br> Internet -> SBC-DMZ (Provider-IP + MS-IP)	SIP TLS 5061, SRTP Ports	Keine (nur Netzwerkregel)	Ja (keine DPI für SRTP)	An (alle Verbindungen loggen)
30	VoIP-Management: Adminzugriff	Admin-Jump-Host -> SBC/Phones (Mgmt-IP)	SSH (22), HTTPS (443), RDP (3389)	(nicht zutreffend)	n/a	An (bei Änderungen)
40	Notfall/Break-Glass: Backup-Regel	LAN/VLAN -> Internet (any)	Any	n/a	n/a	Aus (nur aktivieren bei Bedarf)

Erläuterungen zu den Regeln:
– Regel 10 (Teams/M365-Egress): Erlaubt Teams-Clients im internen Netzwerk, die für Teams erforderlichen Ziele in der Microsoft-Cloud zu erreichen. Die Nutzung einer FQDN-Gruppe stellt sicher, dass nur die offiziellen Microsoft-Endpunkte angesprochen werden. Auf Diensteebene sind UDP 3478-3481 (für STUN/TURN) sowie TCP 443 (HTTPS für Signalisierung) freigegeben. TLS-Inspection und Web-Filter sind für diese Regel deaktiviert, um die Performance und Funktion von Echtzeitverkehr nicht zu beeinträchtigen. Logging ist aktiviert, um nachvollziehen zu können, ob und wann Verbindungen geblockt wurden (z.B. falls ein unbekanntes Ziel auftaucht).
– Regel 20 (SBC ↔ Provider/Teams): Erlaubt die Kommunikation des SBC sowohl mit den Microsoft PSTN-Diensten (Signalisierung auf TCP 5061 zu definierten FQDNs, sowie Medien auf den vereinbarten UDP-Portbereichen) als auch mit dem SIP-Provider (hier exemplarisch ebenfalls TLS 5061 und RTP). Diese Regel ist bidirektional, da eingehende SIP-Anrufe vom Provider auf den SBC gelangen und ausgehende Gespräche vom SBC zum Provider. Wichtig: In der Destination sind ausschließlich die IP-Adressen des Providers sowie die Domain/FQDNs von Microsoft definiert. Die Regel nutzt keine Application Control (weil wir auf Port-/IP-Ebene arbeiten) – dafür ist TLS-Inspection wiederum deaktiviert (damit der SBC-Verkehr nicht von der Firewall entschlüsselt wird). Vollständiges Logging erlaubt spätere Analyse von Anrufversuchen oder Blockierungen.
– Regel 30 (VoIP-Management): Ermöglicht Administratoren vom gesicherten Jump-Host aus die Verwaltung des SBC und ggf. anderer VoIP-Komponenten. Hier sind protokollspezifisch nur SSH, HTTPS und ggf. RDP freigeschaltet, und zwar nur vom Admin-Netz zum SBC (oder zu IP-Telefonen, falls diese eine Weboberfläche haben sollten). Diese Regel wird idealerweise sehr restriktiv gefasst (einzelne Quell-IP, wenige Ziel-IPs). Sie ist immer zu loggen, um einen Audit-Trail der Adminzugriffe zu haben. Für diese interne Regel sind keine Webfilter oder App-Filter relevant.
– Regel 40 (Notfall/Break-Glass): Diese Regel bleibt im Normalbetrieb deaktiviert. Sie ist als Platzhalter gedacht, um im Krisenfall schnell alle ausgehenden Verbindungen zu erlauben, falls z.B. ein neues Teams-Ziel noch nicht in den FQDN-Gruppen enthalten war und dadurch Telefonie gestört wäre. Nur ein hoher Administrator darf diese Regel aktivieren, und jeder Einsatz muss dokumentiert werden. Im Idealfall wird sie nie benötigt – aber sie bietet eine Art „Sicherheitsventil“ für unerwartete Situationen.

NAT (Network Address Translation) für VoIP

In vielen Fällen befindet sich der SBC in einem privaten Netz und hat eine öffentliche IP-Adresse via NAT auf der Firewall. Für ausgehende Verbindungen muss die Firewall ein Source NAT (SNAT) durchführen: D.h. RTP- und SIP-Pakete vom SBC erhalten die öffentliche Absender-IP der Firewall, damit die Gegenstellen (Microsoft oder Provider) die Antworten an diese öffentliche IP schicken können. Hier ist auf Konsistenz zu achten: Der SBC muss diese öffentliche IP in den SIP-Nachrichten (SDP) als Kontaktadresse ankündigen, sonst kommen die Medien nicht zurück. In der Sophos XGS wird man hierfür eine SNAT-Regel einrichten, die den Absender des SBC-Verkehrs auf die zugewiesene öffentlichen IP umschreibt. Wenn mehrere SBCs oder Dienste die selbe IP teilen, ist sicherzustellen, dass die Portbereiche sich nicht überschneiden.

Eingehende Anrufe: Im Direct-Routing-Szenario initiiert Microsoft aus der Cloud heraus die eingehenden Anrufe zum SBC (über dessen öffentliche IP). Hier muss eine Destination NAT (DNAT) konfiguriert sein, die die öffentlichen SIP-Anfragen an die interne SBC-IP weiterleitet. Gleiches gilt für eingehende Anrufe vom Provider. Dabei sollte die DNAT-Regel wiederum nur von den bekannten Gegenstellen-Adressen aus gelten, um Missbrauch zu vermeiden. Ein Sonderfall ist Hairpin NAT: Falls interne Clients über den SBC telefonieren (z.B. ein örtliches analoges Fax an den SBC, der via Teams an einen anderen internen Teams-User anbindet), könnte Verkehr vom internen Netz an die eigene WAN-IP des SBC gehen und wieder zurück ins LAN. Die Firewall muss hierfür konfiguriert sein, solchen „Loop“-Traffic korrekt zu handeln. Bei Sophos lässt sich Hairpinning mittels entsprechender Reflexive-NAT-Regeln lösen. Wichtig in der Dokumentation ist, alle eingerichteten NAT-Regeln festzuhalten, da bei Fehlern in diesen die Telefonie oft nicht funktioniert.

IPS-Regeln und VoIP-spezifische Ausnahmen

Die Sophos XGS verfügt über ein Intrusion Prevention System (IPS) mit spezifischen Signaturen auch für VoIP-Protokolle. Es ist sinnvoll, dem VoIP-Datenverkehr (insbesondere dem SIP-Port 5060/5061 und RTP) ein angepasstes IPS-Profil zuzuweisen. Dieses sollte typische Angriffsmuster auf SIP erkennen (z.B. bekannte Exploits, ungewöhnliche Sequenzen) aber zugleich auf die Eigenheiten von Echtzeitverkehr abgestimmt sein. Ein Beispiel: Manche legitime SIP-Varianten oder längere Header könnten von generischen IPS-Regeln fälschlich als Angriff gewertet werden (False Positives). Daher gibt es oft vordefinierte VoIP-Profile vom Hersteller, die man nutzen oder anpassen kann.

Wichtig ist eine dokumentierte Ausnahmebehandlung: Sollte eine IPS-Regel regelmäßig legitimen Traffic blockieren (z.B. ein SIP OPTIONS Ping wird als Anomalie gesehen, obwohl normal), darf sie nicht einfach deaktiviert werden, ohne dies festzuhalten. Best Practice ist, die betreffende Signatur gezielt für den betroffenen Traffic auf der Firewall auszunehmen und dies im Regelwerk zu vermerken. Dies erhält den Schutz durch IPS grundsätzlich aufrecht, minimiert aber die Beeinträchtigung. Generell sollten alle Änderungen am IPS-Profil für VoIP mit dem Security-Team abgestimmt und getestet werden, um sicherzustellen, dass keine Sicherheitslücken aufgerissen werden.

TLS-Inspection: Ausnahmen für verschlüsselte Telefonie

Die Sophos XGS bietet wie viele Next-Gen Firewalls die Möglichkeit, ausgehende TLS-Verbindungen aufzubrechen und zu inspizieren (HTTPS Inspection). Für Teams-Telefonie ist das jedoch kontraproduktiv: Die Sprachqualität würde leiden und manche Verbindungen (etwa die mTLS-Verbindung vom SBC zu Microsoft) funktionieren gar nicht, da Microsoft keine Man-in-the-Middle-Zertifikate akzeptiert. Daher müssen für alle relevanten Teams- und SIP-Verbindungen TLS-Inspektions-Ausnahmen definiert werden. In Regel 10 und 20 oben wurde dies bereits vorgesehen.

Es empfiehlt sich, solche Ausnahmen zentral in einer Liste zu dokumentieren. Die folgende Tabelle zeigt ein Beispiel für ein TLS-Bypass-Register:

Ziel FQDN/Service	Grund für Ausnahme	Sicherheitsrisiko	Genehmigt von	Überprüfung am
*.teams.microsoft.com, *.skype.com	Inspektion bricht Audio/Video-Funktion, Microsoft verweigert Fremdzertifikate	Moderat (Traffic verschlüsselt, vertrauenswürdiger Cloud-Service)	CISO	01.09.2026
*.sip-trunk.provider.example	SIP-Trunk Signalisierung verschlüsselt (mTLS); Inspektion technisch nicht möglich	Gering (Punkt-zu-Punkt-Verbindung, Zertifikate geprüft)	Netzwerkleiter	01.09.2026
Kategorie „Voice over IP“ (vordefiniert)	Generelle Ausnahme aller VoIP-Protokolle von Inhaltsprüfung	Mittel (umfasst gesamten VoIP-Traffic, sollte eng gefasst bleiben)	Security Officer	01.01.2026

Hierbei ist festgehalten, welche Ziele nicht von der TLS-Inspection angerührt werden und warum, inklusive einer Bewertung des Restrisikos. Entscheidend ist, dass solche Ausnahmen nicht stillschweigend konfiguriert, sondern bewusst entschieden und regelmäßig überprüft werden.

Quality of Service (QoS) und SD-WAN

Um die Sprachqualität auch bei höherem Datenaufkommen sicherzustellen, bietet Sophos XGS sowohl Traffic Shaping/QoS-Funktionen als auch SD-WAN Policy Routing. Zunächst zum QoS: Man kann Bandbreitenreservierungen oder Priorisierungsklassen definieren. Typischerweise wird für Sprache (Audio) die höchste Priorität eingestellt, gefolgt von Video, während Datenverkehr niedrigere Priorität erhält. In einer Tabelle kann ein einfacher QoS-Plan folgendermaßen aussehen:

Verkehrsklasse	DSCP-Markierung	Priorität (relative)	Reservierte Bandbreite	Drop-Policy
Sprache (Audio)	EF (46)	Höchste	z.B. 20% der WAN-Bandbreite garantiert	Keine Drops (Strict Priority)
Video	AF41 (34)	Hoch	z.B. 30% reserviert (für alle Video gesamt)	Bei Engpässen Fair Drop
Teams-Signalisierung	CS3 (24)	Mittel	minimal (Kaum Bandbreitenbedarf)	Keine Drops bevorzugt
Best Effort (Daten)	BE (0)	Normal	keine feste Reservierung	Drops bei Bedarf
Geringe Prio (Bulk)	CS1 (8)	Niedrig	keine	Zuerst Drop bei Überlast

In diesem beispielhaften Plan erhält Audio-Verkehr die höchste Priorität und einen fixen Anteil der Bandbreite, um auch bei Volllast geringe Latenz zu garantieren. Video bekommt ebenfalls eine Reservierung, aber etwas niedriger priorisiert als Audio. Signalisierung ist minimalbandbreitig, sollte aber dennoch nicht verzögert werden (mittlere Priorität). Datenverkehr ohne besondere Markierung läuft als Best Effort und kann bei Engpässen verworfen werden, ebenso niedrig priorisierte Hintergrund-Transfers. Die genaue Ausgestaltung hängt von den Netzbedingungen ab (z.B. verfügbarer Bandbreite, Anzahl gleichzeitiger Calls etc.). Wichtig ist: Die DSCP-Markierungen sollten vom Teams-Client bzw. vom SBC korrekt gesetzt werden (Teams markiert Audio standardmäßig mit DSCP 46). Die Firewall/Router müssen diese Markierungen akzeptieren oder ggf. neu zuweisen, falls das interne QoS anders organisiert ist.

SD-WAN und Pfadsteuerung: In Umgebungen mit mehreren WAN-Verbindungen kann die Sophos XGS mit SD-WAN-Regeln arbeiten, um Echtzeitverkehr über die beste Verbindung zu schicken. Man könnte z.B. definieren: Alle Teams-Audio/Video-Flows sollen primär über den Glasfaseranschluss laufen und nur bei Ausfall über den Backup-Link (LTE o.ä.). Auch Performance-basierte Routing ist denkbar: Die Firewall misst Latenz/Packet Loss auf den Pfaden und schwenkt um, wenn die Qualität unter einen Schwellenwert fällt (Brownout-Erkennung). Für die Telefonie sollte ein solcher Mechanismus mit Vorsicht eingesetzt werden – kurze Umschaltungen können selbst wieder zu Paketverlust führen. Aber als Redundanzstrategie (Failover in < 1 Minute) ist es durchaus sinnvoll, um bei Netzwerkproblemen zumindest Notrufe oder wichtige Gespräche aufrecht zu erhalten.

High Availability (HA) der Firewall

Da wir in diesem Leitfaden Wert auf hohe Verfügbarkeit legen, muss auch die Firewall selbst ausfallsicher sein. Sophos XGS unterstützt ein Active-Passive-Cluster (HA), bei dem zwei Geräte synchron laufen. Fällt die aktive Einheit aus, übernimmt die passive innerhalb von Sekunden den Betrieb. Für VoIP ist das insofern relevant, als bestehende Anrufverbindungen möglichst erhalten bleiben sollen. Mit Stateful Synchronisation der Session-Tabelle zwischen den Firewalls ist gewährleistet, dass UDP-Streams (RTP) und TCP-Verbindungen (SIP/TLS) nahtlos weiterlaufen. In der Praxis empfiehlt sich dennoch, HA während Nebenzeiten zu testen, um sicherzustellen, dass z.B. bei einem Firewall-Failover der SBC nicht neu registrieren muss.

Bei Updates des Firewall-Clusters gilt es einen Zero-Downtime-Ansatz zu verfolgen: Zunächst wird die passive Unit aktualisiert, dann wird ein Failover initiiert, dann die ehemals aktive aktualisiert. So bleibt stets eine Node online, und die Unterbrechung für aktive Calls ist minimal. Man sollte vorab prüfen, ob der SBC und die Teams-Endpoints kurze Paketverluste (<3-5 Sekunden) überstehen oder ob ggf. ein Call neu aufgebaut werden muss – entsprechend sollte das Wartungsfenster geplant werden. Eine sauber dokumentierte HA-Konfiguration umfasst gemeinsame virtuelle IPs, MAC-Adressen, synchronisierte Regeln und einen Heartbeat-Link zwischen den Geräten. Diese Basics sorgen dafür, dass die Firewall nicht zum Single Point of Failure der VoIP-Lösung wird.

Protokollierung und SIEM-Anbindung

Abschließend ist die Protokollierung der Firewall-Aktivitäten wesentlich. Alle relevanten Regeln sollten Logging aktiviert haben (wie in den Beispielen erwähnt), damit im Nachhinein nachvollzogen werden kann, welcher Traffic geblockt oder erlaubt wurde. Die Firewall bietet verschiedene Logs (Verbindungslog, Webfilter-Log, IPS-Log, Authentifizierungs-Log etc.). Für die VoIP-Sicherheit sind insbesondere interessant:
– Blockierte Verbindungsversuche auf SIP-Ports (könnten auf Scan oder Angriff hindeuten).
– Überschrittene DoS-Limits (z.B. Meldung im Log, dass eine IP wegen zu vieler Anfragen gedrosselt wurde).
– Änderungen an Firewall-Regeln oder Objekten (über das Admin-Log, um nachvollziehen zu können, wer evtl. wann eine Sicherheitsausnahme eingetragen hat).

Diese Logs sollten zentral ausgewertet werden. Eine Anbindung an ein SIEM ist Stand der Technik: Die Firewall kann Syslog oder spezielle Connectors nutzen, um Events an Systeme wie Splunk, Elastic oder Azure Sentinel zu schicken. Dort lassen sich Korrelationen durchführen – z.B. erkennt das SIEM, wenn kurz nach einem geblockten SIP-Scan auf der Firewall auch ungewöhnliche Login-Versuche im O365 auftreten. Durch solche Verknüpfung erhält man ein frühzeitiges Bild möglicher Angriffskampagnen.

In der folgenden Tabelle sind exemplarisch ein paar wichtige Ereignisse und Alarmierungswege aufgeführt:

Quelle Log	Ereignis	Schwellwert/Trigger	Empfänger Alarm	Reaktion/Zeitplan
Firewall (IPS-Log)	SIP-Scan/Versuch, Signatur ausgelöst	> 5 Blockierungen in 1 Minute	Security Team (E-Mail/SIEM)	Sofort prüfen (innerhalb 1h)
SBC (Call-Detail-Logs)	Ungewöhnliches Anrufvolumen nachts	> 10 internationale Calls außerhalb Geschäftszeit	VoIP Admin, SOC	Innerhalb 30 min Incident einleiten
Azure AD (Sign-In Log)	Fehlgeschl. Admin-Login Teams	1 kritischer Fehllogin oder MFA-Bypass	SecOps (SIEM Alert)	Sofort (Realtime)
Firewall (Admin-Log)	Regel 40 (Break-Glass) aktiviert	Jede Aktivierung	IT-Leitung, CISO	Sofort telefonische Info
Teams Quality Dashboard	Paketverlust > 5% bei Calls	Tägliche Schwelle	Netzbetrieb	Nächster Arbeitstag analysieren

Diese Tabelle verdeutlicht: Unterschiedliche Systeme tragen Logs bei (Firewall, SBC, Azure AD, Teams selbst) – sie sollten zusammenfließen, und es müssen klare Alarmkriterien definiert sein. Neben Schwellenwerten ist auch die Verantwortlichkeit (wer reagiert) und die gewünschte Reaktionszeit festzulegen. Nur so wird aus reiner Protokollierung auch ein effektives Sicherheitsmonitoring.

9. Provider- und Rufnummern-Sicherheit

Die Schnittstelle zum Telefonie-Provider und der Umgang mit Rufnummern birgt eigene Risiken. In diesem Abschnitt liegt der Fokus auf der Absicherung des SIP-Trunks gegen Missbrauch, der Vermeidung von Gebührenbetrug und dem verantwortungsvollen Umgang mit ausgehenden Rufnummern (CLIP/CLIR).

Authentifizierung und Betrugsschutz beim SIP-Trunk

Je nach Provider wird ein SIP-Trunk entweder via fester IP (die das Unternehmen beim Provider hinterlegt) oder über Registrierung mit Benutzer/Passwort abgesichert. Bei IP-basierten Trunks ist es entscheidend, dass der Provider nur Anfragen von der vereinbarten Firmen-IP akzeptiert – umgekehrt sollte die Firewall nur Verbindungen von den Provider-IP-Ranges an den SBC zulassen (wie in Kapitel 7 und 8 beschrieben). Dies verhindert, dass externe Angreifer sich als Provider ausgeben. Bei Registrierungstrunks müssen die Zugangsdaten genauso geschützt werden wie ein Domain-Admin-Passwort: Sie sollten nur im SBC hinterlegt sein, dort möglichst verschlüsselt gespeichert und auf keinen Fall mehrfach verwendet werden. Ein häufiges Risiko ist, dass Test-SBCs mit denselben Credentials konfiguriert werden – was bei einem Leak der Testumgebung zur Kompromittierung des Produktiv-Trunks führen kann.

Zum Schutz vor Gebührenbetrug (Toll Fraud) sollten, wie bereits erwähnt, ausgehende Anrufe auf riskante Destinationen eingeschränkt werden. In vielen Telefonanlagen/SBCs kann man Wahlrestriktionen einrichten: z.B. Sperren von teuren Mehrwertdienstnummern, oder Auslandstelefonate nur für bestimmte Abteilungen freigeben. Wo das nicht granular möglich ist (weil Teams selbst das nicht anbietet), kann man zumindest über den Provider Limits setzen. Manche Provider erlauben monatliche Kreditlimits oder Benachrichtigungen, wenn ungewöhnlich hohe Verbindungsgebühren auftreten. Zusätzlich sollte das Call Detail Monitoring greifen – im Teams Admin Center bzw. im SBC lässt sich erkennen, wenn ein bestimmtes Muster auftritt (z.B. viele Anrufe nachts auf Ausland). Solche Indikatoren müssen definiert und beobachtet werden.

Auch eingehende Anrufe gilt es im Blick zu haben: Ein Angreifer könnte z.B. durch permanentes Anrufen einer teuren Servicenummer des Unternehmens (falls solche existieren) Kosten oder Belastung verursachen. Hierfür sollten ggf. Traffic-Policing-Mechanismen mit dem Provider abgestimmt werden – etwa dass nur eine bestimmte Anzahl gleichzeitiger Anrufe von extern auf eine Nummer erlaubt ist, oder dass nach X Fehlversuchen (z.B. bei Durchwahl) blockiert wird.

Rufnummern-Missbrauch vermeiden (CLIP, CLIR, no screening)

Unter CLIP (Calling Line Identification Presentation) versteht man die Übermittlung der eigenen Rufnummer an den Angerufenen; CLIR (Restriction) entsprechend die Unterdrückung der Absenderrufnummer. Diese Funktionen sind legitime Features, müssen aber gesteuert eingesetzt werden. Eine generelle Richtlinie sollte festlegen, wer im Unternehmen Nummern unterdrücken darf (meist nur in Ausnahmefällen) und dass standardmäßig die Durchwahl oder Hauptnummer angezeigt wird, um bei Rückrufen erreichbar zu sein. Das Logging solcher Einstellungen ist hilfreich: z.B. wenn ein Benutzer temporär CLIR aktiviert, sollte dies dokumentiert werden (über Teams-Admincenter auslesbar).

Besondere Obacht gilt bei CLIP no screening. Diese Option erlaubt es, eine beliebige Rufnummer als Absender zu signalisieren, sofern der Provider dies gestattet. Üblicherweise wird no-screening genutzt, um bei Umleitungen die ursprüngliche Anrufernummer zu übertragen oder bei bestimmten Dienstnummern (wie Notrufleitungen) eine spezielle Kennung zu senden. Wird dieses Feature jedoch missbraucht, kann ein Angreifer sich am Telefon praktisch als jemand anderes ausgeben (Caller ID Spoofing). Daher sollte no-screening nur aktiviert sein, wenn unbedingt erforderlich, und dann technisch eingehegt: Etwa indem der SBC oder Provider nur bestimmte vorab definierte Nummern als Absender akzeptiert, die dem Unternehmen gehören. Jede Nutzung von no-screening sollte protokolliert werden (wann, welche Nummer angezeigt), um im Missbrauchsfall zurückverfolgen zu können.

Verantwortlichkeiten und Zusammenarbeit mit Providern

Die Sicherheit an der Schnittstelle zum Provider erfordert auch organisatorische Maßnahmen. Im Vertrag mit dem Provider sollten Sicherheitsaspekte festgehalten sein: z.B. ob der Provider 24/7 Monitoring macht, ob er bei Verdacht auf Missbrauch proaktiv informiert, und welche Notfallkontakte existieren. Intern sollte klar sein, wer für die Trunk-Administration zuständig ist (z.B. Zuweisung neuer Nummern, Änderungen am Routing) und wer die Rechnungen kontrolliert (um Auffälligkeiten wie Peaks in den Gebühren zu entdecken). Diese Aufgabenteilung lässt sich in einer RACI-Matrix festhalten (siehe Kapitel 12). Zudem ist es sinnvoll, regelmäßige Meetings mit dem Provider durchzuführen, um Sicherheitsupdates auszutauschen – z.B. ob neue SIP-IPs hinzukommen (wichtig für die Firewall-Regeln) oder ob es bekannte Fraud-Wellen gibt, vor denen gewarnt wird.

10. Endpoint-/Client-Sicherheit

Die beste Infrastruktur bringt wenig, wenn die Endpunkte kompromittiert sind. Deshalb müssen sowohl die Software-Clients (Teams auf PC/Mac, mobile Apps) als auch dedizierte VoIP-Hardware (Telefone, Headsets) entsprechend gehärtet und verwaltet werden.

Härtung und Management der Teams-Clients (PC, Mac, Mobil)

Unternehmen sollten sicherstellen, dass alle Geräte, auf denen Microsoft Teams läuft, den internen Security-Standards entsprechen. Das bedeutet: Aktuelle Betriebssystem-Patches, ein aktiver Malware-Schutz und standardmäßig keine administrativen Rechte für die Benutzer. Microsoft Teams selbst aktualisiert sich regelmäßig über den Benutzerkontext – man sollte daher verhindern, dass Nutzer dies blockieren (z.B. nicht unnötig restriktive Application-Control, die das Update verhindert). Ferner kann über Endpoint Management (etwa Microsoft Intune) sichergestellt werden, dass nur Geräte, die bestimmte Compliance-Richtlinien erfüllen, auf die Teams-Telefonie zugreifen dürfen. Beispiele: Device muss verschlüsselt sein, darf nicht Jailbroken/Rooted sein, und muss einen Passcode bzw. Windows Hello aktiviert haben. Diese Checks lassen sich über bedingten Zugriff koppeln, sodass unsichere Geräte ausgeschlossen werden.

Die Netzwerkkonfiguration der Clients ist ebenfalls relevant: Ist ein PC gleichzeitig im Firmen-LAN und einem unsicheren WLAN, könnten Angreifer via ARP-Spoofing versuchen, den Traffic abzugreifen. Daher sollten Clients wenn möglich immer nur in einem Netzwerk zur Zeit aktiv sein (keine parallelen WLAN/LAN-Verbindungen ohne Bedarf) und VPNs für öffentliche Netze genutzt werden. Zudem kann der Teams-Client via Richtlinie so eingestellt werden, dass er möglichst keine Fallbacks auf unverschlüsselte Protokolle zulässt – standardmäßig macht er das zwar nicht, aber beispielsweise kann man festlegen, dass kein Skype for Business Fallback genutzt wird (sofern das Umfeld hybriden Betrieb hat).

Sichere Nutzung von VoIP-Hardware (Telefone, Adapter, Headsets)

In vielen Unternehmen kommen Teams-zertifizierte Tischtelefone oder Konferenzgeräte zum Einsatz. Diese laufen oft auf Android-Basis und sollten genauso wie PCs regelmäßige Updates erhalten. Die IT sollte einen Prozess einrichten, um Firmware-Updates dieser Geräte zeitnah einzuspielen – entweder automatisiert via Hersteller-Cloud oder manuell, wenn nötig. Wichtig: Standard-Passwörter der Geräte (sofern sie ein Webinterface oder Admin-PIN haben) müssen geändert werden, damit nicht jeder interne Angreifer das Telefon steuern kann. Falls Telefone ins normale LAN integriert sind, empfiehlt sich die Nutzung von 802.1X an den Switchports, sodass kein fremdes Gerät sich als Telefon ausgeben kann. Für WLAN-basierte Geräte gelten analog starke WLAN-Sicherheitsstandards (WPA3 Enterprise, Zertifikatsauthentifizierung etc.).

Analoge Adapter und Spezialhardware: In manchen Umgebungen gibt es ATA-Adapter (Analog Telephone Adapter) oder Faxgeräte, die an VoIP angeschlossen sind. Auch diese müssen ins Sicherheitskonzept einbezogen werden. Wenn ein ATA unsicher konfiguriert ist, kann er als Einfallstor dienen. Daher: Firmware-Updates und Härtung (z.B. nur TLS-SIP zulassen) sind auch dort Pflicht. Bei Fax-over-IP sollte insbesondere darauf geachtet werden, dass T.38 oder ähnliche Protokolle sicher durch die Firewall kommen, aber nicht als Schlupfloch missbraucht werden können.

Headsets und Peripherie: Headsets selbst sind in der Regel keine großen Risikofaktoren, doch es gab Fälle von unsignierten Firmware-Updates bei USB-Geräten. Unternehmen können hier auf etablierte Hersteller setzen, die Sicherheitsupdates anbieten. Ein weiterer Aspekt ist Datenschutz: Smart Speaker oder KI-basierte Meeting Assistenten (die z.B. Transkripte erstellen) müssen im DACH-Raum datenschutzkonform eingesetzt werden. Die Endnutzer sollten geschult sein, keine unbekannten USB-/Bluetooth-Geräte mit ihrem Rechner zu koppeln, um Abhörgeräte auszuschließen.

11. Monitoring, Test & Incident Response

Auch nach der Implementierung muss die VoIP-Lösung kontinuierlich überwacht und regelmäßig getestet werden, um Sicherheit und Qualität zu gewährleisten. Im Ernstfall ist ein klar definierter Incident-Response-Plan notwendig. Dieser Abschnitt behandelt wichtige Monitoring-Kennzahlen, beschreibt empfohlene Testprozesse vor dem Go-Live und skizziert einen Ablauf für die Incident Response samt Übungen.

Laufendes Monitoring und Kennzahlen

Für den operativen Betrieb der Telefonie sollten sowohl Qualitätsmetriken als auch Sicherheitsmetriken regelmäßig erhoben werden. Auf der Qualitätsseite sind typisch:
– Latenz (Verzögerung) – sollte für Gespräche innerhalb der Region unter ~50 ms bleiben, international unter ~150 ms.
– Jitter (Schwankung der Verzögerung) – sollte minimal sein (< 30 ms), da stark schwankende Latenz die Sprachqualität beeinträchtigt.
– Paketverlust – jeder Verlust kann hörbare Lücken verursachen; Zielwert < 1 % Verlust.
– MOS (Mean Opinion Score) – berechneter Wert 1–5 für subjektive Qualität, sollte >4 liegen.
Diese Werte liefert z.B. der Teams Call Quality Dashboard oder SBC-Statistiken. Schwellenüberschreitungen sollten alarmieren (siehe Tabelle Logging/Alarmierung in Kapitel 8).

Bei Sicherheitsmetriken sind z.B. interessant:
– Anzahl blockierter SIP-Angriffsversuche pro Woche (Trend -> abnehmend nach Härtung?).
– Anzahl ausgelöster sicherheitsrelevanter Alarme (z.B. fehlgeschlagene Admin-Logins, Überschreiten von Anruflimits).
– Zeit bis zur Reaktion auf einen Sicherheitsvorfall (im Idealfall < 15 min für kritische Incidents).
Solche KPIs sollte das Security-Team definieren und tracken. Sie können als Grundlage für regelmäßige Reports an die IT-Leitung dienen.

Testplan und Go-Live-Abnahme

Bevor die neue Teams-Telefonie produktiv geschaltet wird, ist eine umfassende Testphase obligatorisch. Dabei sollten nicht nur technische Funktionen, sondern auch Sicherheitsmechanismen validiert werden. Wichtige Testfälle sind unter anderem:
– Ein- und ausgehende Anrufe: Von einem internen Teams-User zu einem externen Telefonanschluss und umgekehrt. Funktioniert die Gesprächsvermittlung in beide Richtungen? Bleibt die Nummernanzeige korrekt (Clip no screening richtig konfiguriert)?
– Notrufe: Ein Testanruf zur Notrufnummer (z.B. 112) aus verschiedenen Standorten. Dieser sollte idealerweise vorher mit der Leitstelle abgesprochen werden (oft gibt es spezielle Test-Rufnummern). Wichtig: Stimmt die Absendernummer/Standortinfo, kommt der Anruf durch?
– Failover: Simulation des Ausfalls eines SBC oder einer Internetleitung. Läuft das Gespräch weiter bzw. bauen neue Gespräche über den redundanten Pfad auf? Hierzu SBC nacheinander deaktivieren und prüfen, ob Teams zum sekundären SBC wechselt.
– Performance-Tests: Belastungstest mit vielen gleichzeitigen Gesprächen (z.B. Mittagspause-Szenario). Eventuell mit Tooling oder in Zusammenarbeit mit Provider, um Netz und SBC unter Last zu beobachten. Überprüfen, ob QoS greift (kein Paketverlust trotz hohem Grundtraffic).
– Sicherheitschecks: Bewusste Versuche, ein nicht vorgesehenes Szenario zu provozieren – z.B. ein Anruf mit einer gespooften Absendernummer, um zu sehen ob SBC/Provider es filtern; ein Scan auf den SIP-Port aus dem Internet (in kontrollierter Weise), um zu prüfen ob die Firewall alles blockt und Alarm schlägt.

Nach Abschluss der Tests sollte eine formelle Go-Live-Abnahme erfolgen, in der alle relevanten Punkte abgehakt werden. Eine Checkliste kann dabei helfen:

• Alle geplanten Firewall-Regeln sind implementiert, getestet und dokumentiert (inkl. NAT-Konfiguration).
• QoS-Einstellungen wurden verifiziert: Markierungen greifen und Priorisierung im Netz funktioniert (QoS-Markierungen sichtbar, kein Jitter unter Last).
• Notruf-Tests durchgeführt und erfolgreich: Richtige Leitstelle erreicht, Standortinformation korrekt übermittelt.
• Monitoring-Dashboards aktiv: Qualität (Latency/Jitter) und Security (Log-Alarme) werden erfasst, Alarmierungswege geprüft.
• Backup/Restore getestet: SBC-Konfiguration gesichert, Wiederherstellung auf Ersatzgerät im Labor verifiziert. Firewall-Config-Backup vorhanden.
• Härtungsmaßnahmen überprüft: Keine Standardpasswörter, alle unnötigen Dienste aus, Admin-Zugänge nur von definierten Hosts, MFA wo möglich.

Erst wenn alle Punkte grün abgehakt sind, sollte das „Go“ für die Produktion gegeben werden. Idealerweise bestätigt dies ein Change Advisory Board oder zumindest die Projektleitung.

Incident Response und Notfallübungen

So sehr man Prävention betreibt – ein Restrisiko für Zwischenfälle bleibt. Daher braucht es einen definierten Incident-Response-Plan für VoIP. Dies kann Teil des allgemeinen IT-Notfallmanagements sein, sollte aber speziell auf Telefonie zugeschnittene Schritte enthalten. Wichtige Aspekte:
– Erkennung und Alarmierung: Wie bemerkt das Team einen Vorfall? (Durch Alarme, Nutzer-Feedback, Provider-Hinweis?) Und wer wird alarmiert? Hier sollten die in Kapitel 8 definierten Schwellwerte zum Tragen kommen.
– Triage und Initialmaßnahmen: Schnell beurteilen, ob es sich um einen sicherheitsrelevanten Vorfall (z.B. Angriff) oder einen technischen Ausfall handelt. Danach Sofortmaßnahmen ergreifen – etwa betroffenen SBC vom Netz nehmen, Admin-Zugänge sperren, oder beim Provider anrufen.
– Isolation und Weiterbetrieb: Im Security-Fall möglicherweise vom kompromittierten System trennen: z.B. Traffic zu/von einem SBC blockieren, um laufenden Angriff zu stoppen, während Notfalltelefonie über Backup-Wege läuft. Im Ausfalls-Fall ggf. auf Backup-Systeme schalten.
– Beweissicherung: Logs sammeln (Firewall, SBC, Teams Admin Center), ggf. forensische Images ziehen (falls z.B. ein SBC gehackt wurde). Diese Daten später analysieren, aber im ersten Schritt sichern, bevor sie überschrieben werden.
– Kommunikation: Intern das Management und betroffene Bereiche informieren (Transparenz, Koordination). Falls Telefonie betroffen ist, Alternativen kommunizieren (z.B. temporär Mobiltelefone nutzen). Auch extern ggf. informieren – z.B. wenn Kundentelefonleitungen ausfallen, sollte eine Ansage geschaltet oder Info auf die Website.
– Wiederherstellung: Nachdem Ursache erkannt und beseitigt (z.B. Malware entfernt, Konfig angepasst, Patch eingespielt), Systeme wieder an das Netz nehmen und genau beobachten.
– Lessons Learned: Nach Abklingen des Vorfalls ein Post-Mortem Meeting: Was war die Ursache, was lief gut/schlecht im Ablauf, welche Maßnahmen verhindern ein erneutes Auftreten? Die Ergebnisse fließen in Anpassungen des Sicherheitskonzepts ein.

Damit in der Hektik eines echten Incidents nichts vergessen wird, ist es ratsam, eine kompakte Erstmaßnahmen-Checkliste griffbereit zu haben. Beispiel:

• Isolation: Betroffene Systeme vom Netz trennen (SBC ausgehend blockieren, Admin-Zugänge sperren) um Schaden zu begrenzen.
• Beweissicherung: Relevante Logs und ggf. Speicherabbilder sofort sichern, bevor sie überschrieben werden. Timestamp aller Aktivitäten notieren.
• Kommunikation: Intern Krisenteam informieren (via festgelegtem Kanal), Entscheidungsträger einbinden. Erste Info an Nutzer/Stakeholder, dass Problem untersucht wird (ohne vorschnelle Details).
• Eskalation: Falls notwendig, externe Stellen einbeziehen (Provider NOC, Microsoft Support bei Teams-Ausfall, ggf. Strafverfolgung bei kriminellem Hintergrund). Firmenrechtliche Schritte klären (Meldepflichten z.B. bei Datenschutzvorfall).
• Wiederherstellung: Nach Eingrenzung und Fix (z.B. Wechsel auf Secondary SBC, Passwortreset, Patch) Dienste schrittweise hochfahren. Tests durchführen (Anruf testen, Qualität prüfen). Engmaschig überwachen.
• Dokumentation: Alle Schritte, Entscheidungen und Beobachtungen dokumentieren. Später für Analyse und evtl. Versicherung/Behörden notwendig.

Solche Checklisten sollten regelmäßig in Übungen durchgegangen werden (z.B. einmal jährlich eine „Trockenübung“ eines VoIP-Incidents), damit im Ernstfall alle wissen, was zu tun ist. Das erhöht die Resilienz enorm – oft entscheidet die Reaktionsgeschwindigkeit über die Schadensbegrenzung.

12. Compliance, Datenschutz & Aufbewahrung (DACH-Kontext)

Unternehmen müssen neben der technischen Sicherheit auch rechtliche und Compliance-Vorgaben im Blick behalten, insbesondere im deutschsprachigen Raum mit strengen Datenschutzgesetzen. In diesem Kapitel geht es um den Umgang mit Gesprächsdaten und Aufzeichnungen, die Einhaltung von Datenschutzrichtlinien und die klare Verteilung von Verantwortlichkeiten (z.B. über eine RACI-Matrix).

Umgang mit Gesprächsdaten, Aufzeichnungen und Protokollen

Bei der Nutzung von Microsoft Teams-Telefonie fallen diverse Daten an: Verbindungsnachweise (wer hat wann wen angerufen, Dauer), ggf. Mitschnitte von Gesprächen (wenn Recording-Funktion genutzt wird), Voicemail-Aufzeichnungen, sowie technische Logs (SBC-/Firewall-Logs mit IP-Adressen, Ports etc.). All diese Daten können personenbezogene Informationen enthalten (z.B. Rufnummern als personenbezogenes Datum, Gesprächsinhalte sowieso). Daher gelten hier die Grundsätze der DSGVO: Datenminimierung, Zweckbindung, Speicherbegrenzung.

Praktisch bedeutet das: Es sollte eine Aufbewahrungsrichtlinie definiert werden, wie lange welche Daten vorgehalten werden. Beispielsweise könnten Verbindungsdaten (CDRs) nach 6 Monaten anonymisiert oder gelöscht werden, sofern keine abrechnungstechnische Notwendigkeit zur längeren Aufbewahrung besteht. Voicemail-Inhalte könnten automatisch nach X Tagen gelöscht werden, außer der Nutzer speichert sie bewusst. Wenn Gespräche aufgezeichnet werden (z.B. im Callcenter zu Schulungszwecken), muss zuvor die Zustimmung der Beteiligten eingeholt werden (opt-in) und es muss nachvollziehbar sein, wer Zugriff auf die Aufnahmen hat. Solche Aufzeichnungen sind i.d.R. spätestens nach einigen Wochen oder Monaten zu löschen, je nach interner Policy und gesetzlichen Vorgaben.

Auch Logs von sicherheitsrelevanten Systemen (Firewall, SBC) sollten nicht unbegrenzt aufgehoben werden, um datenschutzkonform zu bleiben. Oft reicht ein Rolling Log von z.B. 3-6 Monaten, außer bestimmte Incident-bezogene Logs werden für Ermittlungen länger aufbewahrt. Wichtig ist, dass Zugriffe auf diese Logs wiederum nur berechtigten Personen erlaubt sind – idealerweise sind Logs in einem SIEM, auf das nur das Security-Team Zugriff hat. Zugleich verlangt das Telekommunikationsgesetz (in Deutschland z.B. TKG) von Anbietern bestimmte Mindestspeicherfristen für Verbindungsdaten für Abrechnungszwecke – allerdings betrifft das primär die Provider, nicht zwingend das einzelne Unternehmen als Endkunde.

Datenschutz und Richtlinien im DACH-Raum

Im deutschsprachigen Raum gibt es neben der DSGVO teils besondere Regelungen: In Deutschland z.B. das BDSG und sektorale Gesetze (für Gesundheitsdaten, Sozialgeheimnis etc.), in der Schweiz das revDSG. Für die Telefonie heißt das konkret:
– Wenn Gesprächsinhalte personenbezogene Daten enthalten (was fast immer der Fall ist), dürfen sie nur mit entsprechender Rechtsgrundlage verarbeitet werden. Normaler Geschäftsbetrieb deckt das meist ab, aber z.B. das Aufzeichnen eines Kundentelefonats bedarf einer Einwilligung.
– Beschäftigtendatenschutz: Arbeitgeber dürfen Telefoniedaten ihrer Mitarbeiter nur in engen Grenzen auswerten. Z.B. um Missbrauch zu verhindern, aber nicht um Leistungskontrolle zu betreiben ohne Betriebsratsvereinbarung. In größeren Unternehmen sollte daher mit dem Betriebsrat eine Betriebsvereinbarung zur Nutzung von Teams/VoIP geschlossen werden, die auch regelt, welche Auswertungen zulässig sind (z.B. Qualitätsmonitoring ja, aber keine dauerhafte Einzelverbindungsüberwachung einzelner Mitarbeiter ohne Anlass).
– Notrufdaten (Standortinformationen) dürfen nur zum Zweck der Notfallabwicklung genutzt werden und müssen nach definierten Fristen gelöscht werden. Hier kommen Vorschriften aus dem Rettungsdienstbereich ins Spiel, die aber meist den Provider betreffen, der die Daten an die Leitstelle weitergibt.
– Verschwiegenheitspflichten: In Branchen wie Gesundheit oder öffentlicher Dienst gibt es Vorgaben, wer auf welche Gesprächsdaten zugreifen darf. Z.B. in einer Klinik darf nicht jeder Helpdesk-Mitarbeiter die Anruflisten der Ärzte einsehen. Hier sollten Rollen und Berechtigungen in Teams entsprechend gesetzt werden (Least Privilege, wie in Kapitel 4 beschrieben).

Zusammenfassend ist ein enger Schulterschluss zwischen IT, Datenschutzbeauftragtem und ggf. dem Betriebsrat ratsam, um die Telefonie-Lösung compliant zu betreiben.

Rollen, Verantwortlichkeiten und RACI

Die Vielzahl an Aufgaben rund um Betrieb und Sicherheit von VoIP erfordert klare Zuweisungen: Wer ist verantwortlich für welche Tätigkeit, wer wird nur informiert, etc.? Ein probates Mittel ist eine RACI-Matrix (Responsible, Accountable, Consulted, Informed). Nachfolgend ein Auszug für typische Aktivitäten:

Aktivität	Verantwortlich (R)	Rechenschaftspflichtig (A)	Konsultiert (C)	Informiert (I)
Design der VoIP-Sicherheitsarchitektur	Netzwerkarchitekt	IT-Leiter/CIO	Sicherheitsbeauftragter, UC-Lead	Betriebsteam
Umsetzung Firewall & SBC Konfiguration	Network Engineering	Head of Infrastructure	Security Officer bei Ausnahmen	Betriebsteam
Benutzer-Support Telefonie	Service Desk Teamleiter	IT-Operations-Manager	UC-Engineer (2nd Level)	Security bei sicherheitsrelev. Incidents
Incident Response bei VoIP-Angriff	Security Analyst (SOC)	CISO/CSO	Netzwerk- und UC-Team	Management, Datenschutzbeauftragter
Provider Management & Verträge	Voice/Telekom Manager	CFO/ Einkauf	Rechtsabteilung (Compliance)	Security (bei SLA/Problemen)

Hierbei steht jeder Aktivität genau eine hauptverantwortliche Person/Gruppe gegenüber (R), jemand der die letzte Verantwortung trägt (A), einige die eingebunden werden (C) und jene, die zumindest Bescheid wissen müssen (I). Diese Klarheit hilft insbesondere in großen Organisationen (200–10.000 Mitarbeiter, mehrere Standorte), den Überblick zu behalten. Im VoIP-Kontext vermeidet man so, dass z.B. sicherheitsrelevante Änderungen an der Konfiguration vorgenommen werden, ohne dass das Security-Team informiert ist. Zugleich ist klar geregelt, wer im Ernstfall Entscheidungen treffen darf (etwa der CISO bei einem Incident) und wer lediglich beratend hinzugezogen wird.

13. Betrieb, Change & Kontinuierliche Verbesserung

Nach dem erfolgreichen Go-Live beginnt der eigentliche Betrieb der Lösung. Hier sind disziplinierte Change-Prozesse und eine Kultur der kontinuierlichen Verbesserung notwendig, um die Sicherheit langfristig aufrechtzuerhalten. Dieser Abschnitt gibt Hinweise zum Patch- und Upgrademanagement, zu regelmäßigen Sicherheits-Reviews und Übungen.

Patch- und Upgrade-Management

VoIP-Komponenten müssen regelmäßig aktualisiert werden, um Sicherheitslücken zu schließen und Verbesserungen zu erhalten. Ein Patch-/Upgrade-Plan sollte alle relevanten Systeme umfassen:
– Session Border Controller: z.B. vierteljährlich Firmware-Updates einspielen, sofern vom Hersteller als stabil empfohlen. Immer zuerst in einer Testumgebung oder am sekundären SBC ausprobieren, dann im Produktivsystem (z.B. via HA-Failover, siehe Kapitel 8).
– Firewall (Sophos XGS): Sicherheitsupdates zeitnah (innerhalb 1–2 Wochen nach Release) einspielen, insbesondere Critical Fixes. Major Upgrades (z.B. v18 auf v19) im Lab vorab testen. Rollback-Möglichkeit bereit halten (Backup der Config und ggf. alte Firmware parat).
– Microsoft Teams Clients: Diese aktualisieren sich automatisch, aber IT sollte darauf achten, dass Rechner nicht monatelang offline sind ohne Updates. Ggf. per Intune/Endpoint Manager Richtlinien setzen, dass Updates nicht unterbunden werden.
– Teams Phones/Devices: Alle 1–2 Monate prüfen, ob neue Firmware vom Hersteller vorliegt. Updates via Teams Admin Center oder manuell verteilen. In kritischen Umgebungen (z.B. Reception phone) zuerst im Testgerät probieren.
– Zertifikate: Überwachung der Laufzeiten aller Zertifikate (SBC-Zertifikat, ggf. interne TLS-Proxy-Zertifikate). Ein Plan zur rechtzeitigen Erneuerung (z.B. 1 Monat vor Ablauf) und Test des neuen Zertifikats sollte vorhanden sein.

Eine tabellarische Übersicht hilft, nichts zu vergessen (Beispiel):

Komponente	Aktuelle Version	Update-Zyklus	Test/QA-Prozedur	Rollback-Plan
SBC-Software (AudioCodes)	v. 7.20A	Quartalsweise oder dringender bei Security Patch	Test-SBC im Labor patchen, Anruftests durchführen	Vorherige Firmware im Boot-Slot belassen für Revert
Sophos XGS Firmware	SFOS 19.5 MR2	Monatlich (Minor Updates), jährlich Major	Passive Node im HA updaten, dann Failover	Config-Backup vor Update, Downgrade getestet
Teams-Client (Windows)	Automatisch (ver. prüfen)	Kontinuierlich (Cloud gesteuert)	Pilot-Gruppe von Usern überwachen	Notwendig: Zurücksetzen auf Vorgänger via Software Center
Teams-Tischtelefone	Firmware 1449/1.0	Alle 2 Monate prüfen	Einzelgerät im IT-Lab vorab updaten	Falls Problem: Downgrade-Paket vom Hersteller einspielen
Zertifikate (SBC, usw.)	Gültig bis 12/2025	Jährlich erneuern	Neues Zertifikat parallel laden, Switch per Config	Altes Zertifikat bis Verfall als Fallback behalten (wenn unterstützt)

Dieser Plan sollte regelmäßig aktualisiert werden, wenn neue Komponenten hinzukommen oder Hersteller ihre Release-Zyklen ändern. Wichtig: Alle Updates zunächst in einer kontrollierten Umgebung testen, um keine Betriebsstörung zu riskieren. Und stets ein aktuelles Backup parat haben.

Regelmäßige Sicherheits-Reviews

Es ist empfehlenswert, in festen Abständen (z.B. jährlich oder bei größeren Änderungen) ein Audit der VoIP-Sicherheitsmaßnahmen durchzuführen. Ein Security-Team oder externer Prüfer sollte checken, ob Firewall-Regeln noch dem Prinzip der Minimierung entsprechen, ob neue Features (z.B. aus Microsoft Teams Updates) zusätzliche Ports erfordern, ob die IPS-Signaturen aktuell sind, etc. Auch ein Penetrationstest der VoIP-Umgebung (inkl. Social Engineering, Versuch ins Netz zu kommen und Telefonie zu missbrauchen) kann wertvolle Erkenntnisse liefern.

Zum kontinuierlichen Verbessern gehört ebenso, Changes kontrolliert abzuwickeln: Jede Änderung an Routing, am SBC oder an Policies sollte durch ein Change Management mit Risikobetrachtung gehen. Gerade wenn neue Rufnummernkreise oder Provider hinzugefügt werden, darf Security immer mit am Tisch sein. Die Dokumentation (Netzwerkpläne, Firewall-Regelübersicht, Kontaktlisten) ist lebendig zu halten – veraltete Dokumentation kann in der Krise zu Fehlentscheidungen führen.

Schulungen und Übungen

Der Betrieb einer sicheren VoIP-Umgebung erfordert, dass beteiligte Teams informiert und geschult bleiben. Daher sollte es mindestens jährlich eine Awareness-Schulung für das UC/Netzwerk-Team zu neuen Bedrohungen geben. Auch alle Administratoren sollten die Policies kennen (z.B. dass sie keine Änderungen im Teams Tenant ohne Change Request machen). Wie bereits bei Incident Response erwähnt, sind Tabletop-Übungen oder technische Drills extrem hilfreich: z.B. einmal pro Jahr ein simulierter Ausfall oder Angriff, den das Team ohne Vorwarnung bewältigen muss. Daraus ergeben sich oft Verbesserungsmaßnahmen.

Last but not least sollte man den Blick nach vorne richten: Technologien entwickeln sich weiter. Vielleicht kommen neue Sicherheitsfeatures in Teams (z.B. bessere E2EE, neue Analytics gegen Spam-Calls) – diese gilt es zu beobachten und bei Nutzen frühzeitig zu integrieren. Eine Kultur der kontinuierlichen Verbesserung stellt sicher, dass die VoIP-Sicherheit nicht auf einem einmal erreichten Level stehenbleibt, sondern sich dynamisch anpasst.

14. Fazit & Roadmap

Abschließend lässt sich festhalten, dass die sichere Einführung von VoIP mit Microsoft Teams-Telefonie ein ganzheitliches Vorgehen erfordert. Es reicht nicht, nur eine Firewallregel zu setzen oder MFA zu aktivieren – alle Ebenen vom Benutzer bis zur Provideranbindung müssen bedacht werden. Die vorangegangenen Kapitel haben einen Leitfaden geliefert, um schrittweise ein hohes Sicherheitsniveau zu erreichen, ohne die Funktionalität der Telefonie einzuschränken.

Eine Risikoübersicht kann helfen, den aktuellen Stand einzuschätzen. Beispielhaft in Tabelle dargestellt:

Risiko	Wahrscheinlichkeit	Auswirkung	Risikoscore	Gegenmaßnahmen	Verantwortlicher
Gebührenbetrug durch kompromittierten Account	Mittel	Hoch (hohe Kosten, Reputationsschaden)	15 (3×5)	Call-Limits, MFA, Monitoring int. Calls	UC-Teamleiter
Abhören von Gesprächen (Eavesdropping)	Niedrig	Hoch (Vertraulichkeitsverlust)	8 (2×4)	SRTP/TLS durchgängig, Netzsegmentierung	Security Officer
Totalausfall der Telefonie (DoS)	Mittel	Kritisch (Geschäftsunterbrechung)	20 (4×5)	Redundante SBC, DDoS-Schutz, Notfallweg Mobil	IT-Leitung
Kompromittierung SBC (Hackerangriff)	Niedrig	Sehr hoch (Pivot ins Netz, Kontrollverlust)	15 (3×5)	Härtung, Updates, Überwachung (IPS)	Netzwerk/Security Team
Fehlbedienung/ Fehlkonfiguration	Mittel	Mittel (Störung, Lücke)	9 (3×3)	Change Management, 4-Augen-Prinzip, Doku	VoIP-Betriebsteam

Die priorisierten Maßnahmen ergeben sich aus solchen Bewertungen: Welche Risiken haben höchsten Score, wo sind Quick Wins möglich? Zum Abschluss eine Roadmap mit Empfehlung zu kurzfristigen, mittelfristigen und langfristigen Schritten:

• Kurzfristig (0–3 Monate): Fokus auf Essentials: alle Accounts mit MFA absichern; Firewall gemäss Kapitel 8 konfigurieren (Basis-Regeln, TLS-Bypasses einrichten, Logging aktivieren); SBC in Betrieb nehmen und mit Zertifikat ausstatten; grundlegende Schulung des Admin-Teams; Quick-Win Maßnahmen aus Management Summary umsetzen.
• Mittelfristig (3–12 Monate): Ausbau der Monitoring- und Response-Fähigkeiten: SIEM-Anbindung vollständig implementieren, automatisierte Alerts feintunen; zweite SBC-Instanz beschaffen und in Redundanz betreiben; VoIP-spezifisches Incident Response Playbook finalisieren und mind. einen Testdurchlauf durchführen; regelmäßige Security-Reviews (vierteljährlich) etablieren; offene Punkte aus Penetrationstest/Audit umsetzen.
• Langfristig (über 1 Jahr): Kontinuierliche Verbesserung: auf dem Laufenden bleiben über neue Funktionen (z.B. Microsoft Teams Verbesserungen in Sicherheit oder Anrufrouting) und diese bewerten/einführen; Personal weiterbilden (z.B. Zertifizierungen in Teams Voice oder Netzwerksecurity); mögliche Integration von PSTN-Backups wie Mobilfunk-Gateways prüfen, falls Risiko-Assessment es nahelegt; und insgesamt die VoIP-Sicherheit als festen Bestandteil der Unternehmens-Sicherheitsstrategie verankern (inkl. jährlicher Management-Berichte zu VoIP-Risiken und -Massnahmen).

Mit dieser Roadmap und den in diesem Artikel beschriebenen Best Practices können Organisationen ihre Microsoft Teams-Telefonie nicht nur erfolgreich einführen, sondern auch langfristig sicher und stabil betreiben. Die Investition in Security zahlt sich dabei aus – durch weniger Ausfälle, geschützte Vertraulichkeit der Kommunikation und letztlich Vertrauen der Nutzer und Geschäftspartner in die Telefonieplattform des Unternehmens.

 

Weitere Beiträge zum Thema SharePoint und Teams