Die Einfachheitsfalle: Warum Cloud-E-Mail in jede BCP-Diskussion gehört[

Die Einfachheitsfalle: Warum Cloud-E-Mail in jede BCP-Diskussion gehört

Ana NetoTechnical Leave a Comment

Die Cloud sollte alles vereinfachen. Und für die meisten Arbeitslasten hat sie das auch getan. Für diejenigen, die in einer Microsoft-Umgebung arbeiten, versprach Microsoft 365 eine Welt, in der E-Mail, Kalender und Zusammenarbeit einfach funktionieren, ohne dass man an die Server denken muss, die das unterstützen.

Aber die Welt ist im Wandel. Dafür haben Handelsspannungen und Streitigkeiten über die Datenhoheit gesorgt. Und Ausfälle sind keine Einzelfälle mehr.

Im Januar 2026, Microsoft 365 ist weltweit ausgefallen. E-Mail gestoppt. Outlook lässt sich nicht mehr laden. Der Zugriff auf den Kalender verschwand. Der Explosionsradius betraf nicht nur ein Unternehmen. Es war jeder Mieter auf der Plattform, und zwar auf einmal.

Für jede Organisation, die ohne Ausweichmöglichkeit erwischt wurde, war die Geschäftskontinuität gefährdet. Und für Organisationen, die unter Vorschriften wie DORA oder NIS2 fallen, ist dies nicht mehr nur ein betriebliches Problem. Es handelt sich um ein Versagen bei der Einhaltung von Vorschriften, das das Risiko von Geldbußen, Meldepflichten und möglichen aufsichtlichen Eingriffen mit sich bringt.

Der regulatorische Weckruf: "Der Anbieter ist ausgefallen" ist nicht länger eine Antwort

In verschiedenen Rechtsordnungen und Branchen legen die Aufsichtsbehörden die Messlatte für die Bedeutung der Geschäftskontinuität immer höher:

  • DORA (tritt im Januar 2025 vollständig in Kraft): Organisationen des Finanzsektors müssen dokumentierte IKT-Kontinuitätspläne aufrechterhalten und regelmäßig testen, sicherstellen, dass die Systeme bei Unterbrechungen betriebsbereit bleiben, und die Risiken von Cloud-Drittanbietern aktiv mindern. Eine bestehende SLA gilt nicht als ausreichende Risikominderung.

Die Aufsichtsbehörden haben die Befugnis, Sanierungspläne aufzuerlegen, zusätzliche Prüfungen durchzuführen, bestimmte Geschäftstätigkeiten einzuschränken oder die Aufsicht zu verstärken, wenn sich herausstellt, dass Organisationen die Vorschriften nicht einhalten.

  • NIS2: weitet nahezu identische Verpflichtungen auf die Bereiche Energie, Gesundheit, Verkehr, öffentliche Verwaltung und digitale Infrastruktur aus. E-Mail-Systeme sind ausdrücklich in den Geltungsbereich einbezogen. Die Sanktionen reichen 2% des weltweiten Jahresumsatzes. Die Beweislast liegt bei der Organisation, nicht bei der Regulierungsbehörde.

Die Regulierungsbehörden können Abhilfemaßnahmen anordnen, detaillierte Nachweise für die Einhaltung der Vorschriften verlangen und in schwerwiegenden Fällen den Geschäftsbetrieb im Zusammenhang mit wesentlichen oder wichtigen Diensten einschränken oder untersagen, bis die Einhaltung der Vorschriften wiederhergestellt ist.

  • Datenschutz-Grundverordnung und Datenhoheit: E-Mail-Daten, die ausschließlich bei Cloud-Anbietern mit Sitz in den USA gespeichert sind, unterliegen der Offenlegungspflicht des US CLOUD Act, unabhängig davon, wo sich die Server physisch befinden. Für europäische Organisationen in regulierten Sektoren wie dem Gesundheitswesen, der Rechtsberatung und der klinischen Forschung stellt dies ein echtes und ständiges Compliance-Risiko dar.

Die Aufsichtsbehörden erwarten von Unternehmen, dass sie die Kontrolle über die Datenverfügbarkeit und die rechtliche Zuständigkeit nachweisen können - eine Garantie, die kein Hyperscaler im Namen Ihres Unternehmens vollständig übernehmen kann.

 

Dies sind nicht die einzigen Vorschriften, die Geschäftskontinuität erfordern. Je nach Branche und Region gibt es noch viele andere Rahmenregelungen mit ähnlichen Verpflichtungen:

 

Verordnung

Umfang

BCP-Anforderung

HIPAA

US-Gesundheitswesen und Geschäftspartner

Notfallplanung ist eine ausdrückliche Anforderung der Sicherheitsregel; E-Mail-Server werden im Geltungsbereich genannt

FISMA / NIST SP 800-53

US-Bundesbehörden und Auftragnehmer

Vollständige Kontrollfamilie für die Notfallplanung; umfasst alle Informationssysteme, einschließlich der Kommunikationsinfrastruktur

FDA 21 CFR Teil 11 / EU Anhang 11

Pharma, Biotech, Medizinprodukte weltweit

Anhang 11 verlangt ausdrücklich dokumentierte Kontinuitätsvereinbarungen für Systeme, die regulierte Prozesse unterstützen

APRA CPS 230

Australische Banken und Versicherungsgesellschaften

CPS 230, das ab Juli 2025 in Kraft tritt, verlangt einen glaubwürdigen, regelmäßig getesteten BCP, der alle kritischen Vorgänge abdeckt, und weitet die Verpflichtungen ausdrücklich auf Drittanbieter, einschließlich Cloud-Anbieter, aus

SOX

Öffentlich gehandelte US-Unternehmen

Die IT-Kontrollen nach Abschnitt 404 erfordern implizit Verfügbarkeits- und Wiederherstellungsbestimmungen für Systeme, die die Finanzberichterstattung unterstützen, einschließlich E-Mail

GLBA (FTC-Schutzklausel)

US-Finanzinstitute

Die aktualisierte Vorschrift 2023 verlangt ausdrücklich Bestimmungen zur Geschäftskontinuität als Teil des Informationssicherheitsprogramms

NYDFS 23 NYCRR Teil 500

In NY zugelassene Finanzdienstleistungsunternehmen

Verlangt Protokolle zur Geschäftskontinuität und Notfallwiederherstellung, einschließlich jährlicher Tests; betroffene Unternehmen können die Verantwortung für die Einhaltung nicht an Drittanbieter delegieren

 

Der rote Faden in all diesen Rahmenwerken ist derselbe: Das Unternehmen ist für die Kontinuität verantwortlich, nicht der Anbieter. Die Aussage "Unser Cloud-Anbieter ist ausgefallen" stellt keinen Prüfer in einer dieser Rechtsordnungen zufrieden.

Die Lösung: Aufbau einer stabilen Active-Standby-Architektur

Die Antwort ist nicht die Abschaffung von M365. Sie ist eine Erweiterung. Durch die Einführung einer Active-Standby-Architektur können Sie Ausfallsicherheit und Geschäftskontinuität erreichen, ohne Ihre Endbenutzer zu beeinträchtigen.

In einer solchen Architektur wickelt eine Umgebung im Normalzustand 100% des Live-Verkehrs ab. Eine zweite Umgebung hält eine kontinuierliche Parität aufrecht und übernimmt den Verkehr, wenn die primäre Umgebung ausfällt. Natürlich muss der Failover-Flow im Vorfeld geplant und getestet werden, damit er bei Bedarf überprüfbar und umsetzbar ist.

Es gibt drei Hauptaspekte, die die Grundlage einer Active-Standby-Architektur bilden, wie im folgenden Diagramm dargestellt:

1 - Ein automatisches Synchronisierungstoolwie zum Beispiel CB Exchange Server Sync, um die bidirektionale Mail- und Kalenderparität zwischen den Plattformen aufrechtzuerhalten, während Sie die volle Kontrolle über den Speicherort Ihrer Daten behalten.

2 - A Mail-Gateway, wie z. B. Postfix, um einen kontrollierten Puffer bereitzustellen, damit Sie E-Mails während eines Ausfalls an sekundäre Endpunkte weiterleiten können.

3 - Vorgefertigte E-Mail-Client-Profile, um Benutzer schnell zu diesen sekundären Endpunkten zu wechseln. Alle Endbenutzer müssen über vorbereitete Profile für beide Systeme verfügen, um Verzögerungen bei der Erstkonfiguration zu vermeiden. Wir empfehlen, das klassische Outlook als E-Mail-Client zu verwenden oder sicherzustellen, dass alle Benutzer für die Verwendung von OWA als "Zero Setup"-Fallback geschult sind.

Aktiv-Standby-Architekturdiagramm mit M365-Alternative

Diagramm der Aktiv-Standby-Architektur

Für die alternative Umgebung, die Sie im Standby-Modus haben, können Sie je nach den Infrastrukturpräferenzen und den Souveränitätsanforderungen Ihres Unternehmens die beiden folgenden Optionen in Betracht ziehen.

Option 1: M365 + Vor-Ort Exchange

Am besten geeignet für: Unternehmen mit Anforderungen an die Datenhoheit, regulierten Sektoren, in der EU ansässigen Unternehmen oder bestehender Infrastruktur vor Ort.

Wie es funktioniert:

  • On-Premises Exchange wird als alternative Standby-Umgebung verwendet und im eigenen Rechenzentrum des Unternehmens gehostet.
  • CB Exchange Server Sync sorgt für eine kontinuierliche bidirektionale Synchronisierung von E-Mails, Kontakten und Kalendern zwischen Microsoft 365 und Exchange vor Ort. Alle Daten werden in beiden Systemen identisch.
  • Im Normalzustand wird der gesamte Live-Datenverkehr von Microsoft 365 abgewickelt.
  • Bei einem Failover werden die E-Mails automatisch über die Exchange vor Ort geleitet.

Wie der Failover-Fluss für den Endbenutzer aussieht:

  • Outlook Desktop, Mobile und OWA verbinden sich mit der jeweils verfügbaren Umgebung.
  • Die Schnittstelle ist identisch (kein neues System, das erlernt werden muss, kein Notfallverfahren, das befolgt werden muss).
  • Alle während des Ausfalls erstellten E-Mails werden nach der Wiederherstellung automatisch mit Microsoft 365 synchronisiert.

Vorteile der Datenhoheit:

  • Die ruhenden E-Mail-Daten befinden sich im eigenen Rechenzentrum des Unternehmens, in dessen Zuständigkeitsbereich und auf der von ihm kontrollierten Hardware.
  • Vollständige Überwachungskette und Nachprüfbarkeit
  • Direkte, nachweisbare Antwort auf die DORA-Drittrisikobestimmungen

Was die Prüfer sehen: Eine lebendige, laufende, testbare Standby-Umgebung. Kein Grundsatzdokument. Nicht eine SLA-Referenz. Ein Beweis für Kontinuität.

Option 2: M365 + Google Workspace

Am besten geeignet für: Unternehmen, die eine vollständige Cloud-Redundanz bevorzugen, Unternehmen, die bereits eine Anbieterdiversifizierung in Betracht ziehen, oder Unternehmen, die keine lokale Infrastruktur haben (oder kein Team, das eine solche in Betracht zieht).

Wie es funktioniert:

  • Google Workspace wird als alternative Standby-Umgebung verwendet. Es handelt sich um eine separate Anbieterinfrastruktur, eine andere Rechenzentrumsfläche und eine andere Fehlerquelle.
  • Ein Mail-Gateway wie Postfix zentralisiert den Eingang und verwaltet das Routing, wobei der Failover-Fluss unabhängig von der MX-Propagation gesteuert wird.
  • Das CB Exchange Server Sync sorgt für eine kontinuierliche bidirektionale Mail- und Kalenderparität mit Google Workspace im Hintergrund. Sie haben die gleichen Daten in beiden Systemen.
  • Im Normalzustand bewältigt Microsoft 365 100% an Live-Datenverkehr.
  • Bei einem Failover leitet ein halbautomatischer Routing-Flip am Gateway den Datenverkehr zu Google Workspace um.
  • Dadurch wird MX Brain-Split vermieden (der Split-Routing-Konflikt, der auftritt, wenn MX-Eintragsänderungen während eines Live-Übergangs inkonsistent über DNS-Auflöser verbreitet werden).

Wie der Failover-Fluss für den Endbenutzer aussieht:

  • Benutzer, die mit Outlook vertraut sind, können es während des Failover-Zeitraums über Mail-Konnektoren nutzen oder zu den Gmail Web- oder Gmail Mobile-Schnittstellen wechseln.

Anmerkung zur Datenhoheit:

Diese Option ist praktisch, weil sie den Besitz oder die Wartung der Infrastruktur vermeidet, aber sie bietet nicht die gleiche Eigentumsgarantie vor Ort wie Option 1. Die Datenhoheit hängt von der Google Workspace-Bereitstellungskonfiguration und den regionalen Einstellungen ab. Für Unternehmen mit strengen Anforderungen an die Rechtsprechung ist die Option 1 die bessere Wahl.

Was beide Optionen gemeinsam haben

Unabhängig davon, welches Bereitstellungsmuster für das Unternehmen geeignet ist, bietet die zugrunde liegende Architektur die gleichen Garantien:

  • Redundanz die für Endnutzer unsichtbar und für Prüfer sichtbar ist
  • Aktiv-Standby-Architektur mit kontinuierlicher Synchronisierung. Kein Cold Standby, keine Backup-Wiederherstellung, keine manuelle Datenwiederherstellung
  • Ein Failover-Flow die geplant und getestet wird, bevor sie gebraucht wird

Der Gewinn: Von Compliance-Kosten zu wettbewerbsfähiger Architektur

  • Audit-Bereitschaft als StandardzustandWenn ein DORA- oder NIS2-Prüfer fragt, wie die Organisation die Kontinuität der E-Mail sicherstellt, ist die Antwort ein laufendes System und nicht ein Richtliniendokument, das sich auf eine Anbieter-SLA bezieht.
  • Souveränität als kommerzielles Unterscheidungsmerkmal: In der EU erfordern viele Verträge des öffentlichen Sektors und kritischer Infrastrukturen eine Datenverarbeitung im Land oder nur in der EU. In Australien dehnt APRA CPS 230 diese Verantwortlichkeit direkt auf Drittanbieter aus. In den USA verlangen Rahmenwerke wie FBI CJIS und NYDFS von Organisationen - und nicht von ihren Anbietern - eine strenge Kontrolle über sensible Daten. In allen drei Fällen erhalten Unternehmen, die Datenhoheit nachweisen können, den Zuschlag für Aufträge, auf die reine Cloud-Anbieter nicht bieten können.
  • Zero-Trust, operationalisiert für E-MailDie widerstandsfähigste BCP-Position geht davon aus, dass jedes System ausfallen kann, und plant entsprechend. Die oben vorgestellte Active-Standby-Architektur mit kontinuierlicher Synchronisierung zeigt, wie diese Annahme aussieht, wenn sie auf die Arbeitslast angewendet wird, deren Ausfall sich Unternehmen am wenigsten leisten können.
  • Investitionen, die der Zeit voraus sindUnternehmen, die heute in die Ausfallsicherheit von hybriden E-Mail-Systemen investieren, nehmen eine proaktive Haltung ein und positionieren sich vor den gesetzlichen, betrieblichen und Marktanforderungen, anstatt erst im Nachhinein zu reagieren.

Abschließende Überlegungen

Die Cloud sollte alles vereinfachen. Für die meisten Arbeitslasten ist dies auch gelungen. Aber Einfachheit ohne Resilienz ist nur Fragilität mit einem besseren Namen.

Wenn die Aufsichtsbehörden anrufen oder ein größerer Ausfall den Betrieb zum Stillstand bringt, denken Sie dann “wir haben den SLA unseres Anbieters vertraut” eine akzeptierte Antwort sein wird?

Die Zeiten des blinden Vertrauens in die Betriebszeit eines einzelnen Cloud-Anbieters sind vorbei, insbesondere bei kritischen Geschäftssystemen wie E-Mail. E-Mail ist der einzige Kommunikationskanal, der unabhängig davon funktioniert, welche Plattform Ihr Geschäftspartner verwendet. Wahrscheinlich ist das der Grund, warum sie das Herzstück fast jeder geschäftskritischen Interaktion ist. Sie ist entscheidend für jede Kundenbeziehung, jede gesetzliche Verpflichtung und jedes laufende Geschäft. Wenn er versagt, versagt alles, was nachgelagert ist, mit ihm.

Für Unternehmen, die sich bisher ausschließlich auf Microsoft 365 verlassen haben, ist der Aufbau einer livefähigen, testbaren Architektur mit zwei Umgebungen nicht nur eine technische Vorsichtsmaßnahme. Es ist jetzt auch eine Frage des gesunden Menschenverstands. Ob dies nun bedeutet, dass ein Exchange-Standby vor Ort für vollständige Souveränität oder ein Cloud-to-Cloud-Failover mit Google Workspace für Anbietervielfalt hinzugefügt wird, der Punkt ist derselbe.

Die Widerstandsfähigkeit muss von Anfang an so konzipiert sein, dass die Kontinuität nicht auf der Strecke bleibt, wenn die Einfachheit versagt.

Sie möchten mehr über diese Art der Active-Stanby-Architektur erfahren und wie CB Exchange Server Sync in Ihrem Szenario funktionieren könnte? Sichern Sie sich ein kostenloses Beratungsgespräch mit unseren technischen Experten:

Meine Beratung buchen

Glossar 

APRA CPS 230 - Australische Aufsichtsbehörde (Australian Prudential Regulation Authority), Prudential Standard CPS 230

DORA - Digital Operational Resilience Act

FDA 21 CFR Teil 11 - U.S. Food and Drug Administration, Titel 21 Code of Federal Regulations Teil 11

FISMA - Bundesgesetz zur Verwaltung der Informationssicherheit

ICT - Informations- und Kommunikationstechnologie

NIS2 - Europäisch Richtlinie über Netz- und Informationssysteme (NIS)

SLA - Service Level Agreement


Lesen Sie weiter über Google Workspace


Über den Autor

Ana Neto

Durch Ana Neto, Fachberaterin bei Connecting Software.

"Ich bin seit 1997 Software-Ingenieur, und seit kurzem schreibe ich gerne und halte öffentliche Vorträge. Haben Sie Fragen oder Kommentare zu diesem Artikel? Ich würde mich über Ihr Feedback freuen. Hinterlassen Sie unten einen Kommentar!"

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.