Resiliente Videokonferenzen: Business Continuity bei Ausfällen

Wenn ein wichtiges Meeting nicht stattfindet, ist selten nur die Videoplattform betroffen. Anmeldung, Kalender, DNS, Internetzugang, Endgerät, Medienpfad und Telefonie können ebenso die Ursache sein. Business Continuity für Videokonferenzen bedeutet deshalb nicht, einen Dienst als „ausfallsicher“ zu erklären. Es bedeutet, klar definierte Meeting-Fähigkeiten auch unter Einschränkungen arbeitsfähig zu halten.

Für IT-, Sicherheits- und Betriebsverantwortliche ist die Leitfrage: Welche Besprechung muss innerhalb welcher Zeit in welchem Mindestmodus wieder möglich sein? Eine Incident-Bridge kann etwa zunächst per Audio genügen; eine Kundeneskalation braucht möglicherweise zusätzlich Bildschirmfreigabe. Erst diese fachliche Priorisierung macht einen Ersatzweg planbar und testbar.

Vom Tool zur geschäftskritischen Meeting-Fähigkeit

Starten Sie mit drei bis fünf Meeting-Typen, deren Ausfall wirklich Folgen hätte, zum Beispiel Incident-Führung, Kundeneskalation oder Lagebesprechung. Halten Sie je Typ fest:

• Eigentümer und Teilnehmerkreis
• Folgen der Unterbrechung und maximal tolerierbare Unterbrechung
• Mindestmodus: Video, Audio, Telefon oder Chat
• Schutzbedarf für Vertraulichkeit, Integrität und Verfügbarkeit
• benötigte Artefakte wie Einladung, Teilnehmerliste, Chat oder Aufzeichnung

Die Business Impact Analysis liefert damit die Entscheidung, welche Fähigkeiten einen vorbereiteten Ersatzweg benötigen. Ein Recovery Time Objective (RTO) ist dabei keine Verfügbarkeitszusage eines Anbieters. NIST definiert es als die Dauer, die Komponenten in der Wiederherstellung bleiben können, bevor Geschäfts- oder Missionsprozesse negativ betroffen sind. Formulieren Sie es daher als überprüfbare Fähigkeit, etwa: „Incident-Führung per Audio ist innerhalb von 15 Minuten möglich.“ NIST: Recovery Time Objective

Ein Recovery Point Objective (RPO) beantwortet eine andere Frage: Wie groß darf die Datenlücke bei wiederherstellbaren Informationen sein? Bei Live-Meetings betrifft das eher Einladungen, Entscheidungen oder Aufzeichnungen – nicht die fortlaufende Qualität eines Gesprächs. Für die Live-Kommunikation brauchen Sie einen Betriebs- und Ersatzweg, keinen RPO-Wert.

Die Abhängigkeitskarte: Primär- und Ersatzweg gleich kritisch prüfen

Ein zweiter Dienst allein ist noch kein Failover. Zeichnen Sie für den primären und den alternativen Weg die gleichen Abhängigkeiten auf:

Einladung/Kalender → DNS → IdP/SSO/MFA → Client/Endgerät → LAN/WLAN/ISP/VPN → Signalisierung/Plattform → STUN/TURN/Medienpfad → Einwahltelefonie

Ergänzen Sie Admin-Zugriff, Support, Status- und Alarmkanäle. Besonders wichtig sind gemeinsame Abhängigkeiten: Zwei Plattformen helfen nicht, wenn beide am selben Identitätsanbieter, Internetzugang, Resolver, Endgerät oder Mobilfunknetz hängen.

TURN verdient auf dieser Karte einen eigenen Prüfpunkt. Bei bestimmten NAT-Situationen ist keine direkte Verbindung zwischen Hosts möglich; TURN kann dann als Relay dienen. Das heißt nicht, dass jede Videokonferenz gleich funktioniert oder ein TURN-Ausfall immer das gesamte Meeting beendet. Es zeigt aber, warum Signalisierung und Medienpfad getrennt diagnostiziert und unter realistischen Netzbedingungen getestet werden sollten. IETF RFC 8656: TURN

Sieben Ausfallbilder und der vorbereitete Ersatzweg

Ausfallbild	Sofortentscheidung	Vorbereitete Maßnahme
Plattform oder Signalisierung gestört	Ersatz für den betroffenen Meeting-Typ aktivieren	Freigegebene Ersatz-URLs, Einwahlnummern und externe Kontaktliste außerhalb des Primärsystems
ISP, WAN, WLAN, VPN oder Strom betroffen	Betroffene in anderen Netzpfad oder Standort wechseln lassen	Unabhängiger Pfad, etwa Mobilfunk, und realistisch getestete Stromreserve
DNS-Auflösung gestört	Resolver-/DNS-Fehler von Plattformfehler trennen	Kritische Namen und Resolver-Abhängigkeiten dokumentieren; keine ad-hoc Hosts-Dateien verteilen
SSO, IdP oder MFA gestört	Notfallprozess für privilegierte Administration auslösen	Unabhängige, überwachte und regelmäßig getestete Emergency-/Break-glass-Zugänge
Client, Endgerät oder Peripherie gestört	Browser-Join oder Ersatzgerät einsetzen	Geprüfte Mindestkonfiguration, Ersatzgerät und Headset
Join gelingt, Medien fehlen	Signalisierung und Medienpfad getrennt prüfen; Audio-only erwägen	TURN-/ICE-Erreichbarkeit und Kapazität in freigegebenen Netzpfaden testen
Einwahltelefonie gestört	Zweite freigegebene Kommunikationsmethode aktivieren	Provider-, Routing- und Mobilfunk-Abhängigkeiten vorab dokumentieren

Für Notfallzugänge gilt: Sie sind kein Alltagskonto und kein Grund, Sicherheitskontrollen pauschal abzuschalten. Microsoft beschreibt für Entra produktbezogen das Muster unabhängiger, cloud-only Notfallkonten, abweichender starker Authentisierung, Monitoring und regelmäßiger Prüfung. Übertragbar ist das Muster – unabhängig, stark abgesichert, überwacht und getestet –, nicht die konkrete Entra-Konfiguration für jede Organisation. Microsoft Learn: Emergency access admin accounts

Das Runbook entscheidet unter Druck

Ein brauchbares Runbook ist kurz genug, um im Incident gelesen zu werden, und konkret genug, um Entscheidungen zu ermöglichen. Es sollte enthalten:

1. Eintrittskriterien: Welche Symptome lösen die Prüfung aus?
2. Rollen: Wer führt den Incident, wer prüft Technik, wer kommuniziert?
3. Technische Checks: Identität, DNS, Plattformstatus, Netz, Client und Medienpfad in einer festen Reihenfolge.
4. Entscheidungspunkt: Weiter beobachten oder Ersatzweg aktivieren?
5. Kommunikation: unabhängiger Kanal, Zielgruppen, Ersatzlink/-nummer, Datenschutzhinweis und nächstes Update.
6. Rückkehr und Nachbereitung: Wann zurück zum Normalbetrieb, welche Zeiten und Fehlerbilder werden ausgewertet?

Speichern Sie keine Geheimnisse im Runbook. Zugangsdaten gehören in einen kontrollierten, dafür vorgesehenen Zugriffspfad. Und behandeln Sie den Ersatzweg nicht als Freibrief für private oder ungeprüfte Apps: Datenschutz, Informationssicherheit, Beschaffung und Betrieb müssen ihn vorab bewerten.

Tests: Nicht nur den Link, sondern die Fähigkeit testen

Ein Test ist erst aussagekräftig, wenn er den Weg vom Auslöser bis zur arbeitsfähigen Kommunikation abbildet. Kombinieren Sie Tabletop-Übungen mit kontrollierten technischen Tests, etwa für:

• Ausfall von SSO oder MFA
• externes Netz oder eingeschränkte Firewall-/TURN-Erreichbarkeit
• defektes Endgerät
• fehlende Einwahl
• Aktivierung und Kommunikation des Ersatzwegs

Messen Sie Zeit bis zum Mindestmodus, Erfolgsquote und Verständlichkeit der Kommunikation – gegen Ihr selbst festgelegtes RTO.

Datenschutz und Sicherheit: Resilienz ist eine Prüfpflicht, kein Anbieterlabel

Artikel 32 DSGVO verlangt risikoadäquate technische und organisatorische Maßnahmen. Er nennt unter anderem die dauerhafte Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit von Verarbeitungssystemen sowie die zeitnahe Wiederherstellung von Verfügbarkeit und Zugang zu personenbezogenen Daten nach einem Vorfall. Daraus folgt keine Pflicht zu einem bestimmten Videokonferenzanbieter und keine feste RTO-Zahl. DSGVO, Art. 32

Ob ein Ersatzweg personenbezogene Daten verarbeitet, welche Rollen gelten und ob beispielsweise Vertrag, Unterauftragsverarbeitung, Übermittlungen oder eine Datenschutz-Folgenabschätzung zu prüfen sind, hängt vom konkreten Einsatz ab. Prüfen Sie den Ersatzweg deshalb vor dem Incident; pauschale Konformitätszusagen wären irreführend.

Fazit

Resiliente Videokonferenzen entstehen nicht durch ein Versprechen über eine einzelne Plattform. Sie entstehen, wenn priorisierte Meeting-Fähigkeiten, ihre Abhängigkeiten und ihr Mindestmodus feststehen – und wenn Ersatzweg, Kommunikation und Runbook regelmäßig unter realistischen Bedingungen getestet werden. So wird aus einem Ausfall nicht automatisch ein Stillstand der geschäftskritischen Zusammenarbeit.