Woran erkennt man eine professionelle Cloud-Infrastruktur für Unternehmenssoftware?

Eine professionelle Cloud-Infrastruktur erkennt man nicht allein an schnellen Prozessoren, grosszügigem Arbeitsspeicher oder einem modernen Rechenzentrum. Entscheidend ist, ob Unternehmenssoftware unter realistischen Betriebsbedingungen zuverlässig funktioniert, angemessen geschützt ist und sich nach Störungen kontrolliert wiederherstellen lässt.

Für Schweizer Unternehmen betrifft diese Frage sowohl die technische Architektur als auch den laufenden Betrieb. Ein CRM-System, eine Warenwirtschaft oder eine interne Verwaltungsplattform muss erreichbar bleiben, wenn Mitarbeitende darauf angewiesen sind. Gleichzeitig müssen Zugriffsrechte, Datensicherung, Wartung und Verantwortlichkeiten nachvollziehbar geregelt sein.

Bei der Auswahl eines Cloud-Anbieters lohnt sich deshalb ein Blick über die technischen Produktdaten hinaus. Service Level Agreements, Monitoring, Wiederherstellungsverfahren, Sicherheitsnachweise und Supportprozesse zeigen, wie belastbar ein Angebot tatsächlich ist. Dabei gibt es keine Infrastruktur, die für jede Anwendung gleichermassen geeignet wäre: Die Anforderungen ergeben sich aus den Geschäftsprozessen, den verarbeiteten Daten und den Folgen möglicher Unterbrechungen.

Warum reichen schnelle Cloud-Server für geschäftskritische Anwendungen nicht aus?

Schnelle Cloud-Server garantieren keinen zuverlässigen Betrieb geschäftskritischer Anwendungen. Auch leistungsfähige Hardware kann durch Netzwerkstörungen, Softwarefehler, fehlende Überwachung oder unzureichende Datensicherung ausfallen. Eine professionelle Cloud-Infrastruktur muss deshalb Rechenleistung, Verfügbarkeit, Sicherheit und Wiederherstellbarkeit gemeinsam berücksichtigen und diese Eigenschaften im laufenden Betrieb überprüfbar machen.

Die Leistungsfähigkeit einer Unternehmensanwendung hängt von mehreren Komponenten ab. Prozessor und Arbeitsspeicher beeinflussen die Verarbeitung, während Datenbanken, Speichersysteme und Netzwerkverbindungen darüber entscheiden, wie schnell Informationen bereitgestellt werden. Ein Engpass in einer dieser Komponenten kann die gesamte Anwendung verlangsamen.

Hinzu kommt die Unterscheidung zwischen technischer Erreichbarkeit und tatsächlicher Nutzbarkeit. Ein virtueller Server kann ordnungsgemäss laufen, während die Anwendung aufgrund einer blockierten Datenbank oder eines fehlgeschlagenen Hintergrundprozesses nicht mehr funktioniert. Ein aussagekräftiges Monitoring sollte deshalb auch Anwendungsfunktionen und nicht ausschliesslich den Serverzustand erfassen.

Eine weitere Voraussetzung ist die betriebliche Resilienz. Die Cloud Security Alliance behandelt in ihrer Einführung zur Cloud Controls Matrix unter anderem Geschäftskontinuität, Sicherheitsverantwortlichkeiten und Wiederherstellung. Die Version 4.1 umfasst 207 Sicherheits- und Datenschutzkontrollen in 17 Domänen. Diese Kontrollen bilden einen Bewertungsrahmen, sind aber keine Garantie für die Verfügbarkeit eines einzelnen Dienstes.

Für die Bewertung sollten Unternehmen deshalb Lastverhalten, Fehlertoleranz und Betriebsprozesse getrennt untersuchen. Eine schnelle Anwendung im Normalbetrieb kann dennoch unzureichend vorbereitet sein, wenn eine Datenbank ausfällt oder eine Wartung unerwartete Auswirkungen hat.

Erst wenn die technischen Fähigkeiten mit konkreten Betriebszusagen verbunden sind, lässt sich die Qualität eines Cloud-Angebots zuverlässig einordnen.

Wie bewertet man Verfügbarkeit, Backup und Support eines Cloud-Anbieters?

Verfügbarkeit, Backup und Support sollten anhand konkreter Vertragsbedingungen und überprüfbarer Betriebsnachweise bewertet werden. Entscheidend sind der Geltungsbereich des Service Level Agreements, die Wiederherstellungsziele, die Ergebnisse von Backup-Tests sowie die Erreichbarkeit und Reaktionsfähigkeit des Supports. Wer diese Kriterien getrennt prüft, erkennt Risiken, die allgemeine Verfügbarkeitsversprechen verdecken können.

Ein Service Level Agreement (SLA) beschreibt vereinbarte Leistungen und Serviceziele. Bei einer Verfügbarkeitszusage muss geprüft werden, welcher Dienst tatsächlich erfasst ist, wie die Verfügbarkeit gemessen wird und welche Unterbrechungen ausgeschlossen sind. Eine zugesagte Verfügbarkeit der virtuellen Maschine bedeutet beispielsweise nicht automatisch, dass eine darauf installierte Geschäftsanwendung jederzeit nutzbar bleibt.

Für die Datensicherung sind zwei Grössen besonders relevant: Das Recovery Point Objective (RPO) beschreibt den maximal akzeptierten Datenverlust als Zeitspanne. Das Recovery Time Objective (RTO) beschreibt die angestrebte Zeit bis zur Wiederherstellung eines Dienstes. Beide Ziele müssen zum Geschäftsbedarf passen und mit der vorhandenen Architektur erreichbar sein.

Beim Support genügt die Angabe «24/7» nicht. Wichtig ist, ob rund um die Uhr tatsächlich qualifizierte technische Hilfe erreichbar ist, welche Reaktionszeiten für kritische Vorfälle gelten und wer die Störungsbehebung koordiniert.

Diese Unterlagen sollten nicht nur vor Vertragsabschluss geprüft werden. Änderungen an der Infrastruktur, neue Anwendungen und wachsende Datenbestände können die ursprünglichen Anforderungen verändern.

Für kleinere IT-Teams stellt sich anschliessend die Frage, wer die vereinbarten Leistungen technisch umsetzt und dauerhaft überwacht.

Public Cloud oder Managed Cloud: Welche Infrastruktur passt zu kleinen IT-Teams?

Für kleine IT-Teams kann eine Managed Cloud geeignet sein, wenn laufende Administration, Monitoring und Störungsbehebung nicht vollständig intern abgedeckt werden können. Eine Public Cloud bietet dagegen häufig mehr direkte Steuerungsmöglichkeiten und standardisierte Dienste, erfordert je nach Servicemodell aber eigene Betriebsarbeit. Entscheidend ist die tatsächliche Aufgabenverteilung, nicht allein die Bezeichnung des Angebots.

Public Cloud beschreibt eine Bereitstellungsform, bei der ein Anbieter standardisierte Cloud-Ressourcen bereitstellt. Managed Cloud bezeichnet dagegen vor allem ein Betriebsmodell mit zusätzlichen Verwaltungsleistungen. Beide Begriffe schliessen sich nicht aus: Ein Managed-Service-Anbieter kann beispielsweise Ressourcen einer Public Cloud für Kunden betreiben.

Bei Infrastructure as a Service (IaaS) übernimmt der Cloud-Anbieter typischerweise den Betrieb der zugrunde liegenden Infrastruktur. Das Unternehmen bleibt je nach Vereinbarung für Betriebssysteme, Anwendungen, Konfigurationen und weitere Sicherheitsmassnahmen zuständig. Bei stärker verwalteten Diensten können sich diese Verantwortlichkeiten verschieben.

Gerade kleine IT-Abteilungen sollten deshalb prüfen, ob das notwendige Fachwissen für Updates, Datenbankbetrieb, Sicherheitskonfiguration, Alarmbearbeitung und Wiederherstellung dauerhaft vorhanden ist.

Ein Managed-Angebot reduziert nicht automatisch sämtliche internen Pflichten. Fachliche Entscheidungen, Berechtigungsfreigaben und die Bewertung geschäftlicher Risiken verbleiben häufig beim Unternehmen. Wichtig sind deshalb schriftlich definierte Zuständigkeiten und nachvollziehbare Übergaben zwischen den beteiligten Parteien.

Bei der Entscheidung sollte deshalb nicht nur der monatliche Infrastrukturpreis betrachtet werden. Interne Arbeitszeit, Bereitschaftsdienst, benötigte Fachkompetenzen und die Folgen längerer Störungen gehören ebenfalls in die Gesamtrechnung.

Unabhängig vom Betriebsmodell bleiben technische Schwachstellen möglich. Ihre frühzeitige Identifikation ist ein wesentlicher Bestandteil einer belastbaren Infrastrukturplanung.

Welche Infrastrukturfehler gefährden die Verfügbarkeit geschäftskritischer Anwendungen?

Besonders kritisch sind einzelne Ausfallpunkte, fehlerhafte Konfigurationen, überlastete Ressourcen, unzureichende Überwachung und nicht getestete Wiederherstellungsverfahren. Solche Schwachstellen können dazu führen, dass bereits ein begrenzter technischer Fehler eine vollständige Betriebsunterbrechung verursacht. Eine systematische Risikoanalyse muss deshalb Abhängigkeiten zwischen Anwendung, Datenbank, Netzwerk und Infrastruktur sichtbar machen.

Ein häufiger Architekturfehler ist der sogenannte Single Point of Failure. Dabei hängt die Funktionsfähigkeit eines Dienstes von einer einzelnen Komponente ab. Fällt beispielsweise die einzige Datenbankinstanz aus, kann die Anwendung trotz verfügbarer Webserver nicht mehr auf benötigte Daten zugreifen.

Weitere Risiken entstehen durch unzureichende Kapazitätsplanung. Wenn Speicherplatz erschöpft ist, Datenbankverbindungen ausgelastet sind oder Hintergrundprozesse übermässig viele Ressourcen beanspruchen, können Antwortzeiten steigen und Funktionen ausfallen.

Auch betriebliche Änderungen verdienen besondere Aufmerksamkeit. Unzureichend getestete Updates, fehlerhafte Zugriffsregeln oder Änderungen an Netzwerkkonfigurationen können funktionierende Systeme beeinträchtigen. Professionelle Betriebsprozesse sehen deshalb kontrollierte Freigaben, nachvollziehbare Änderungen und geeignete Rückfallmöglichkeiten vor.

Für die Sicherheitsorganisation bietet die offizielle ISO-Seite zur Norm ISO/IEC 27001:2022 einen relevanten Bezugspunkt. Die Norm definiert Anforderungen an ein risikobasiertes Informationssicherheitsmanagementsystem und berücksichtigt Vertraulichkeit, Integrität und Verfügbarkeit von Informationen.

Eine Zertifizierung kann die strukturierte Umsetzung eines Informationssicherheitsmanagementsystems belegen. Sie garantiert jedoch weder einen störungsfreien Betrieb noch die Sicherheit jedes einzelnen Cloud-Dienstes. Deshalb muss geprüft werden, ob die betreffende Dienstleistung vom Zertifizierungsumfang erfasst ist.

Eine praktische Risikoanalyse sollte die wesentlichen Abhängigkeiten einer Anwendung dokumentieren und für jede kritische Komponente untersuchen, welche Folgen ihr Ausfall hätte. Daraus lassen sich gezielte Massnahmen ableiten, statt sämtliche Infrastrukturkomponenten ohne Priorisierung mehrfach vorzuhalten.

Bei besonders hohen Anforderungen führt diese Analyse häufig zur Frage, welche Komponenten redundant ausgelegt werden müssen.

Wann braucht eine Cloud-Anwendung zusätzliche Redundanz und Ausfallsicherung?

Zusätzliche Redundanz ist sinnvoll, wenn der Ausfall einer einzelnen Infrastrukturkomponente zu einer geschäftlich nicht akzeptablen Unterbrechung führen würde. Ausschlaggebend sind die Folgen des Ausfalls, die vereinbarten Wiederherstellungsziele und die vorhandenen technischen Abhängigkeiten. Redundanz muss dabei gezielt geplant und getestet werden, damit sie im Störungsfall tatsächlich wirksam ist.

Redundanz bedeutet, dass eine benötigte Funktion durch mehrere geeignete Komponenten bereitgestellt werden kann. Das betrifft beispielsweise Anwendungsserver, Netzwerkverbindungen, Stromversorgung oder Datenbankdienste. Je nach Architektur können redundante Komponenten gleichzeitig aktiv sein oder erst bei einem Ausfall übernehmen.

Eine zusätzliche Instanz allein genügt allerdings nicht. Beide Instanzen könnten weiterhin dieselbe Datenbank, denselben Speicher oder dieselbe Netzwerkkomponente verwenden. Eine professionelle Architektur betrachtet deshalb nicht nur einzelne Server, sondern die vollständige Abhängigkeitskette.

Auch die geografische Trennung kann relevant sein, wenn Risiken auf Standortebene berücksichtigt werden müssen. Dabei entstehen jedoch zusätzliche Anforderungen an Datenreplikation, Konsistenz, Netzwerkverbindungen und die Steuerung des Wiederanlaufs.

Zusätzliche Ausfallsicherung verursacht Aufwand für Einrichtung, Synchronisation, Monitoring und Tests. Deshalb ist nicht jede Anwendung auf dieselbe Redundanzstufe angewiesen. Eine interne Auswertungsplattform kann beispielsweise andere Anforderungen haben als eine Anwendung, die laufende Kundenaufträge verarbeitet.

Besonders wichtig sind realistische Failover-Tests. Sie zeigen, ob ein Wechsel auf eine Ersatzkomponente funktioniert, welche Unterbrechungen entstehen und ob nach der Umschaltung alle benötigten Funktionen verfügbar sind.

Mit einer belastbaren Ausfallarchitektur ist allerdings noch nicht geklärt, wie die Infrastruktur auf wachsende Nutzung reagieren soll.

Vertikal oder horizontal skalieren: Was passt zu wachsender Unternehmenssoftware?

Vertikale Skalierung eignet sich, wenn eine Anwendung durch zusätzliche Ressourcen auf einem bestehenden System effizienter betrieben werden kann. Horizontale Skalierung verteilt die Last dagegen auf mehrere Instanzen und kann zusätzliche Flexibilität und Fehlertoleranz ermöglichen. Welche Strategie passt, hängt von der Softwarearchitektur, den Datenbankabhängigkeiten und dem erwarteten Wachstum ab.

Bei der vertikalen Skalierung erhält ein Server beispielsweise mehr Arbeitsspeicher oder zusätzliche Rechenleistung. Diese Vorgehensweise kann für Anwendungen mit zentraler Architektur vergleichsweise einfach umzusetzen sein. Sie bleibt jedoch durch die maximal verfügbaren Ressourcen der jeweiligen Plattform begrenzt.

Horizontale Skalierung ergänzt weitere Anwendungsinstanzen. Ein vorgeschalteter Lastverteiler kann Anfragen auf mehrere Systeme verteilen. Damit das zuverlässig funktioniert, muss die Anwendung entsprechend ausgelegt sein. Lokal gespeicherte Sitzungsinformationen, gemeinsam genutzte Dateien oder nicht synchronisierte Zustände können die Verteilung erschweren.

In der Praxis werden beide Ansätze häufig kombiniert. Anwendungsserver lassen sich möglicherweise horizontal erweitern, während einzelne Datenbankkomponenten zunächst vertikal skaliert werden. Entscheidend ist, dass die Skalierung dort ansetzt, wo tatsächlich ein Engpass besteht.

Vor einer Erweiterung sollten deshalb Messwerte aus dem Produktivbetrieb ausgewertet werden. Dazu gehören Antwortzeiten, Ressourcenauslastung, Datenbankverhalten und Lastspitzen. Lasttests können zusätzlich zeigen, wie sich die Anwendung unter steigender Nutzung verhält.

Automatische Skalierungsmechanismen benötigen ebenfalls Grenzen und Kontrollen. Andernfalls können zusätzliche Instanzen Kosten erhöhen, ohne einen Engpass in einer gemeinsam genutzten Komponente zu beheben.

Mit zunehmender Datenmenge steigen zugleich die Anforderungen an Datensicherung, Wiederherstellung und Schutz vor einem vollständigen Datenverlust.

Lokales Backup oder Cloud-Backup: Welche Kombination schützt besser vor Ausfällen?

Eine Kombination aus lokalen und extern gespeicherten Backups kann den Schutz vor unterschiedlichen Ausfallszenarien verbessern. Lokale Sicherungen ermöglichen unter geeigneten Bedingungen einen schnellen Zugriff, während getrennte Cloud-Backups zusätzliche Sicherheit bei lokalen Schäden bieten können. Entscheidend sind jedoch die tatsächliche Trennung, der Schutz vor Manipulation und die nachgewiesene Wiederherstellbarkeit der Daten.

Lokale Backups werden beispielsweise auf Speichersystemen innerhalb der eigenen IT-Umgebung abgelegt. Ihr Vorteil liegt häufig in der direkten Verfügbarkeit und der Möglichkeit, grössere Datenmengen ohne externe Internetverbindung zurückzuspielen. Allerdings können sie von denselben physischen oder administrativen Risiken betroffen sein wie das Produktivsystem.

Cloud-Backups speichern Sicherungskopien in einer externen Infrastruktur. Sie können gegen lokale Hardwaredefekte oder Schäden am Unternehmensstandort helfen. Die Wiederherstellung hängt jedoch unter anderem von Netzwerkverbindungen, verfügbaren Zugangsdaten, Datenvolumen und den Eigenschaften des Backup-Dienstes ab.

Eine wirksame Backup-Strategie sollte daher unterschiedliche Fehlerursachen berücksichtigen:

• Hardwaredefekte und versehentliches Löschen von Daten
• Beschädigte Datenbanken oder fehlerhafte Änderungen
• Ransomware und kompromittierte Administrationskonten
• Standortbezogene Schäden und längere Infrastrukturunterbrechungen
• Fehlerhafte oder unvollständige Sicherungsprozesse

Besonders relevant ist die Trennung von Berechtigungen. Wenn Angreifer mit einem einzigen Administrationskonto sowohl Produktivdaten als auch sämtliche Backups löschen können, besteht trotz mehrerer Sicherungskopien ein erhebliches Risiko. Geeignete Zugriffstrennung und unveränderbare oder anderweitig geschützte Sicherungen können dieses Risiko begrenzen.

Ebenso wichtig ist die regelmässige Wiederherstellungsprüfung. Eine erfolgreiche Backup-Meldung bestätigt zunächst nur einen Sicherungsvorgang. Ob eine vollständige Anwendung mit konsistenten Daten wieder betrieben werden kann, zeigt erst ein geeigneter Restore-Test.

Für Schweizer Unternehmen sind bei externen Cloud-Backups ausserdem die Speicherorte, die beteiligten Dienstleister und mögliche internationale Datenflüsse zu prüfen. Diese Fragen sind besonders relevant, wenn personenbezogene Informationen gesichert werden.

Datensicherung ist damit ein zentraler Baustein, aber noch kein vollständiges Konzept zum Schutz geschäftlicher Informationen.

Wie schützt man Unternehmensdaten wirksam vor Datenverlust?

Unternehmensdaten lassen sich wirksam schützen, indem Zugriffssicherheit, Datensicherung, Überwachung und Wiederherstellungsplanung miteinander verbunden werden. Eine professionelle Cloud-Infrastruktur benötigt dafür technische Schutzmassnahmen und eindeutig geregelte Verantwortlichkeiten. Für Schweizer Unternehmen kommt die Prüfung datenschutzrechtlicher Anforderungen hinzu, insbesondere bei personenbezogenen Daten und der Einbindung ausländischer Dienstleister.

Der erste Schritt ist die Klassifizierung der Daten. Unternehmen sollten wissen, welche Informationen sie verarbeiten, welche Anwendungen davon abhängen und welche Folgen ein Verlust, eine unberechtigte Offenlegung oder eine Veränderung hätte. Daraus ergeben sich angemessene Anforderungen an Speicherung, Zugriff und Wiederherstellung.

Beim Zugriffsschutz gehören rollenbasierte Berechtigungen, geeignete Authentifizierungsverfahren und die regelmässige Überprüfung privilegierter Konten zu den wichtigen Massnahmen. Verschlüsselung kann Daten während der Übertragung und bei der Speicherung schützen. Ihre Wirksamkeit hängt jedoch auch von der sicheren Verwaltung der zugehörigen Schlüssel ab.

Der EDÖB erläutert die datenschutzrechtlichen Anforderungen an Cloud-Dienste für die Schweiz. Bei der Bearbeitung von Personendaten durch einen Cloud-Anbieter bleibt das beauftragende Unternehmen als Verantwortlicher für die datenschutzkonforme Bearbeitung zuständig. Die Anforderungen an die Auftragsbearbeitung nach Art. 9 DSG müssen geprüft und vertraglich abgesichert werden.

«Als Verantwortlicher trägt der Kunde selbst die Verantwortung dafür, dass die Datenbearbeitungen, die durch die Cloud-Anbieterin im Auftrag durchgeführt werden, datenschutzkonform erfolgen.»

Bei der Auswahl eines Cloud-Dienstes sollten deshalb auch Unterauftragsbearbeiter, Vertraulichkeitsregelungen und technische Sicherheitsmassnahmen geprüft werden. Werden Personendaten ins Ausland bekanntgegeben, müssen die entsprechenden gesetzlichen Voraussetzungen vorab abgeklärt werden. Ein Rechenzentrumsstandort in der Schweiz beantwortet nicht automatisch sämtliche Fragen zu administrativen Zugriffen oder internationalen Datenflüssen.

Zur technischen Vorsorge gehört ausserdem ein dokumentierter Wiederherstellungsplan. Er sollte beschreiben, welche Systeme zuerst wiederhergestellt werden, welche Personen zuständig sind und wie die Funktionsfähigkeit nach einer Störung geprüft wird. Solche Verfahren müssen zur tatsächlichen Infrastruktur passen und regelmässig erprobt werden.

Auch die laufende Überwachung ist wichtig. Sicherheitsrelevante Ereignisse, ungewöhnliche Zugriffe und fehlgeschlagene Sicherungen sollten erkannt und angemessen bearbeitet werden. Dokumentierte Prozesse helfen dabei, bei einem Vorfall schneller zwischen einem technischen Fehler und einem möglichen Sicherheitsereignis zu unterscheiden.

Als nächster Schritt empfiehlt sich eine dokumentierte Bestandsaufnahme der geschäftskritischen Anwendungen, ihrer Datenflüsse und der bestehenden Sicherheits- und Wiederherstellungsnachweise. Daraus lässt sich ableiten, welche Anforderungen bereits erfüllt sind und welche Massnahmen vor einer Cloud-Migration oder Vertragsverlängerung notwendig werden.