Warum regelmässige Backups nutzlos sind, wenn Sie nie 1 Restore testen

Jeden Morgen zeigt die Backup-Konsole einen grünen Status. Die Sicherungsaufträge sind abgeschlossen, der Speicherplatz reicht aus und es liegen keine offensichtlichen Fehlermeldungen vor. Doch als ein wichtiger Server ausfällt, stellt sich heraus: Die Daten sind zwar vorhanden, die Anwendung lässt sich damit aber nicht wieder in Betrieb nehmen.

Genau darin liegt das Risiko ungeprüfter Datensicherungen. Ein erfolgreiches Backup ist noch kein erfolgreicher Restore. Erst ein Wiederherstellungstest zeigt, ob Daten lesbar, vollständig und mit der benötigten Systemumgebung tatsächlich nutzbar sind.

Für IT-Verantwortliche in Schweizer Unternehmen ist deshalb nicht allein entscheidend, wie häufig Daten gesichert werden. Ebenso wichtig sind die zulässige Ausfallzeit, der akzeptable Datenverlust, die Erreichbarkeit geschützter Kopien und ein dokumentierter Wiederanlaufprozess. Auch mit begrenztem Personal und ohne nächtliche Produktionsunterbrechungen lässt sich ein praktikables Testkonzept aufbauen.

Der entscheidende Perspektivwechsel lautet: Nicht die Anzahl gespeicherter Backups bestimmt die Widerstandsfähigkeit eines Unternehmens, sondern dessen nachweisbare Fähigkeit, geschäftskritische Systeme rechtzeitig wiederherzustellen.

Warum Backups oft „grün“ sind und trotzdem im Ernstfall nicht funktionieren?

Ein grüner Backup-Status bedeutet, dass eine Sicherungssoftware ihren Auftrag erfolgreich abgeschlossen hat. Er beweist jedoch nicht, dass sich ein vollständiges, konsistentes und funktionsfähiges System wiederherstellen lässt. Fehlerhafte Anwendungsdaten, fehlende Zugangsdaten oder inkompatible Systemumgebungen bleiben oft unentdeckt, solange niemand einen Restore unter realistischen Bedingungen durchführt.

Backup-Software überwacht in erster Linie den definierten Sicherungsprozess. Ein abgeschlossener Auftrag kann bestätigen, dass ausgewählte Dateien übertragen oder gespeicherte Datenblöcke verarbeitet wurden. Ob die gesicherte Datenbank später korrekt startet, alle Abhängigkeiten verfügbar sind und Benutzer mit der Anwendung arbeiten können, ist damit noch nicht geprüft.

Besonders kritisch wird dies bei Datenbanken und anderen Anwendungen, die während der Sicherung aktiv Daten verändern. Ohne geeignete anwendungskonsistente Sicherungsverfahren können Datenstände entstehen, die sich zwar zurückkopieren lassen, aber nicht zuverlässig zusammenpassen.

Weitere typische Schwachstellen entstehen ausserhalb der eigentlichen Backup-Dateien:

• Fehlende Schlüssel: Das Backup ist verschlüsselt, doch der benötigte Entschlüsselungsschlüssel lässt sich nicht mehr beschaffen.
• Ungültige Berechtigungen: Ein Administratorkonto wurde deaktiviert oder die erforderlichen Zugangsdaten sind nicht verfügbar.
• Nicht erreichbare Speichermedien: Ein externes Laufwerk, Backup-Repository oder Cloud-Konto steht im Störungsfall nicht zur Verfügung.
• Veränderte Infrastruktur: Die gesicherte Anwendung benötigt eine bestimmte Betriebssystemversion, Konfiguration oder zusätzliche Dienste.

Ein wirksamer Restore-Test muss deshalb mehr prüfen als die Lesbarkeit einzelner Dateien. Er muss nachweisen, dass der wiederhergestellte Datenbestand den vorgesehenen Geschäftszweck erfüllt.

Bei der Planung helfen zwei unterschiedliche Kennzahlen. Das Recovery Point Objective (RPO) bezeichnet den maximal tolerierbaren Datenverlust, ausgedrückt als Zeitraum. Das Recovery Time Objective (RTO) definiert die maximal akzeptable Zeit bis zur Wiederaufnahme des Betriebs. Die technische IBM-Dokumentation zu RPO und RTO erläutert beide Grössen als Grundlage der Wiederherstellungsplanung.

Eine erste Selbstprüfung benötigt lediglich vier dokumentierte Antworten: Wer hat zuletzt einen vollständigen Restore durchgeführt? Wann fand er statt? Wie lange dauerte die Wiederherstellung? Und konnte die betroffene Anwendung anschliessend tatsächlich genutzt werden?

Fehlt eine dieser Informationen, ist die Wiederherstellbarkeit zumindest nicht ausreichend nachgewiesen.

Erst wenn diese Nachweise vorliegen, lässt sich entscheiden, ob die bestehende Sicherungsstrategie die geschäftlichen Anforderungen erfüllt. Daraus ergeben sich die Vorgaben für einen umsetzbaren Backup-Plan.

Wie erstellen Sie einen Backup-Plan mit 3-2-1-Regel, der wirklich umsetzbar ist?

Ein praktikabler Backup-Plan verbindet die 3-2-1-Regel mit konkreten Sicherungsintervallen, Speicherorten, Zuständigkeiten und Restore-Tests. Für jeden wichtigen Datenbestand muss feststehen, welche Kopien existieren, wann sie erstellt werden, wie lange sie aufbewahrt bleiben und wer sie wiederherstellen kann. Der Plan muss auch bei Personalengpässen funktionieren.

Die 3-2-1-Regel sieht drei Datenkopien einschliesslich Original, zwei unterschiedliche Speichermedien und eine Kopie an einem externen Standort vor. Das Bundesamt für Cybersicherheit empfiehlt zur Datensicherung ausserdem regelmässige, möglichst automatisierte Sicherungen und die Überprüfung der Wiederherstellbarkeit.

Damit aus dieser Grundregel ein betriebsfähiger Plan wird, müssen IT-Verantwortliche zunächst die relevanten Systeme erfassen. Dazu gehören nicht nur Dateiserver, sondern auch Datenbanken, Anwendungsserver, virtuelle Maschinen und die Konfigurationen, ohne die eine Wiederherstellung unvollständig wäre.

Danach werden Sicherungsart und Häufigkeit pro System festgelegt. Vollsicherungen liefern einen definierten Ausgangsbestand. Inkrementelle Sicherungen ergänzen diesen um Änderungen seit der vorherigen Sicherung. Wie sich die Sicherungskette wiederherstellen lässt und wie lange das dauert, muss Bestandteil der Planung sein.

Ein Planungsraster kann so aussehen. Die Werte sind illustrative Beispiele und müssen anhand der eigenen RPO- und RTO-Anforderungen festgelegt werden.

Der Plan muss zudem zum tatsächlichen Betrieb passen. Grössere Sicherungsläufe können ausserhalb geschäftskritischer Zeitfenster stattfinden. Kleinere, häufigere Sicherungen müssen hinsichtlich Netzlast, Speicherkapazität und Anwendungslast geprüft werden. Ein nächtlicher Auftrag ist nur dann eine belastbare Lösung, wenn Fehler erkannt und zeitnah bearbeitet werden.

Verantwortlichkeiten gehören direkt in den Plan. Für jeden Datenbestand sollten eine zuständige Person, eine Stellvertretung und ein klarer Eskalationsweg dokumentiert sein. Bei Abwesenheit darf der Wiederanlauf nicht davon abhängen, dass eine bestimmte Fachperson erreichbar ist.

Ein solcher Plan sollte bei Änderungen an Anwendungen, Infrastruktur und Geschäftsanforderungen überprüft werden. Die dokumentierte Sicherungsfrequenz allein reicht nicht aus, wenn der letzte erfolgreiche Restore längst nicht mehr zur aktuellen Systemumgebung passt.

Mit dieser Struktur wird das Backup vom isolierten IT-Auftrag zu einem überprüfbaren Betriebsprozess. Entscheidend ist anschliessend, ob die vorgesehenen Kopien auch einem Cyberangriff standhalten können.

Cloud-Backup oder Offline-Backup: Was ist besser gegen Ransomware?

Gegen Ransomware ist weder ein Cloud-Backup noch ein Offline-Backup grundsätzlich überlegen. Entscheidend ist, ob Angreifer die Sicherungskopien über kompromittierte Konten oder Systeme erreichen, verändern oder löschen können. Cloud-Speicher mit geeigneter Unveränderbarkeit und getrennten Berechtigungen kann wirksam schützen. Physisch getrennte Offline-Medien bieten eine andere Form der Isolation.

Ein häufig unterschätztes Problem besteht darin, dass produktive Systeme und Backup-Infrastruktur dieselben Administratorzugänge verwenden. Erlangt ein Angreifer ausreichende Berechtigungen, können neben den Unternehmensdaten auch erreichbare Sicherungen gefährdet sein.

Das gilt ebenso für externe Festplatten, die dauerhaft an einem infizierten Rechner angeschlossen bleiben. Ein physisches Speichermedium ist nicht automatisch ein Offline-Backup. Erst die tatsächliche Trennung vom produktiven System schafft diese Schutzwirkung.

Bei Cloud-Backups ist die Unveränderbarkeit gespeicherter Sicherungen ein wichtiges Entscheidungskriterium. Entsprechend konfigurierte Immutable Backups verhindern innerhalb ihrer vorgesehenen Schutzfrist eine nachträgliche Änderung oder Löschung. Ihre tatsächliche Wirksamkeit hängt allerdings von den technischen Einstellungen, Berechtigungen und Schutzmechanismen des jeweiligen Angebots ab.

Auch bei einer unveränderlichen Sicherung müssen Zugänge zur Verwaltung, Wiederherstellung und Verschlüsselung geschützt bleiben. Unveränderbarkeit ersetzt weder eine getrennte Identitätsverwaltung noch einen getesteten Restore-Prozess.

Für besonders kritische Daten ist häufig eine kombinierte Strategie sinnvoll: schnell verfügbare Sicherungen für alltägliche Wiederherstellungen und zusätzlich isolierte oder wirksam unveränderliche Kopien für schwerwiegende Sicherheitsvorfälle.

Welche Datenbestände welche Speicherform benötigen, ergibt sich aus ihrer Kritikalität, dem zulässigen Datenverlust, der verfügbaren Wiederherstellungskapazität und den realistischen Kosten des Betriebs.

Selbst hervorragend geschützte Kopien helfen jedoch nur begrenzt, wenn beim Wiederanlauf benötigte Systemkomponenten fehlen. Genau dieser organisatorische Fehler kann eine vermeidbare Verzögerung auslösen.

Der Restore-Fehler, der 48 Stunden Stillstand verursacht, obwohl Daten gesichert sind

Ein Restore kann trotz vorhandener und intakter Backups lange scheitern, wenn niemand die vollständige Wiederanlaufreihenfolge kennt. Fehlende Systemkonfigurationen, Lizenzinformationen, Entschlüsselungsschlüssel oder Anwendungsversionen verhindern den Start produktiver Dienste. Ein Stillstand von 48 Stunden ist dabei ein mögliches hypothetisches Szenario, keine allgemeingültige oder statistisch belegte Wiederherstellungsdauer.

Stellen Sie sich vor, ein zentraler Anwendungsserver fällt vollständig aus. Die Datensicherung liegt auf einem erreichbaren Backup-Speicher und lässt sich ohne Lesefehler zurückspielen. Trotzdem können Mitarbeitende die Anwendung nicht nutzen.

Bei der Fehlersuche stellt sich heraus, dass zunächst eine bestimmte Datenbankversion installiert werden muss. Anschliessend fehlen Konfigurationsdateien und ein benötigter Lizenzschlüssel. Der zuständige externe Dienstleister ist nicht unmittelbar erreichbar.

In diesem hypothetischen Ablauf ist die Datensicherung selbst nicht das Problem. Die Wiederherstellung scheitert an nicht dokumentierten Abhängigkeiten.

Die richtige Gegenmassnahme ist ein Restore-Runbook: eine konkrete Arbeitsanweisung für den Wiederanlauf, die auch von einer qualifizierten Stellvertretung ausgeführt werden kann.

Darin sollten mindestens die folgenden Punkte eindeutig beschrieben sein:

• Benötigte Server, Betriebssysteme, Anwendungsversionen und Infrastrukturkomponenten.
• Reihenfolge, in der Identitätsdienste, Netzwerkkonfigurationen, Datenbanken und Anwendungen wiederhergestellt werden müssen.
• Fundorte und Zugriffsverfahren für Entschlüsselungsschlüssel, Lizenzen und Notfallzugänge.
• Kontaktwege zu internen Verantwortlichen und externen Dienstleistern.
• Technische und fachliche Kriterien für die erfolgreiche Wiederaufnahme des Betriebs.

Ein Runbook sollte keine ungeschützte Sammlung von Passwörtern enthalten. Besser ist es, gesicherte Fundorte, berechtigte Rollen und Verfahren für den Notfallzugriff zu dokumentieren. Diese Informationen müssen auch verfügbar bleiben, wenn die normale Unternehmensinfrastruktur ausgefallen ist.

Um den eigenen Wiederanlauf realistisch einzuschätzen, lässt sich die benötigte Zeit in nachvollziehbare Arbeitsschritte zerlegen.

1. Bereitstellung einer geeigneten Ersatzinfrastruktur oder Wiederherstellungsumgebung.
2. Zugriff auf Backup-Systeme und benötigte Sicherungskopien.
3. Rücksicherung der Daten und erforderlichen Systemkomponenten.
4. Rekonfiguration, Wiederherstellung von Abhängigkeiten und Start der Anwendungen.
5. Technische Kontrolle, fachliche Abnahme und Freigabe für den Produktivbetrieb.

Jeder Schritt sollte im Test gemessen werden. Werden Aufgaben parallel ausgeführt, müssen die tatsächlichen Abhängigkeiten berücksichtigt werden. Eine einfache Addition theoretischer Einzelzeiten reicht nicht aus, um eine belastbare Gesamtdauer vorherzusagen.

Damit das Runbook zuverlässig bleibt, muss es bei technischen Änderungen aktualisiert und praktisch erprobt werden. Dafür ist nicht zwingend eine Unterbrechung des Produktivsystems erforderlich.

Wie oft sollten Sie Restore-Tests machen, wenn 24/7-Betrieb nicht möglich ist?

Restore-Tests sollten nach dem Risiko der betroffenen Systeme, ihrer Änderungshäufigkeit und den geschäftlichen Wiederherstellungszielen geplant werden. Ein vollständiger Produktivausfall ist dafür nicht erforderlich: Viele Prüfungen lassen sich in einer isolierten Umgebung durchführen. Für kritische Anwendungen ist ein dokumentierter wiederkehrender Testzyklus sinnvoll, ergänzt durch Prüfungen nach wesentlichen Systemänderungen.

Die Annahme, ein Wiederherstellungstest müsse immer den laufenden Betrieb unterbrechen, verhindert in vielen IT-Umgebungen eine systematische Prüfung. Tatsächlich lassen sich unterschiedliche Testtiefen kombinieren.

Ein einfacher Datei-Restore überprüft, ob ein bestimmter Datenbestand aus einer Sicherung zurückgeholt und gelesen werden kann. Ein Anwendungstest geht weiter: Die gesicherte Datenbank oder Anwendung wird in einer getrennten Umgebung gestartet und auf Konsistenz sowie Nutzbarkeit geprüft.

Ein umfassender Wiederanlauftest untersucht zusätzlich die erforderlichen Infrastrukturkomponenten, Benutzerzugriffe, Schnittstellen und Abhängigkeiten.

Die geeignete Testform hängt davon ab, welche Aussage benötigt wird. Ein einzelner wiederhergestellter Ordner kann keine erfolgreiche Wiederherstellung einer komplexen Geschäftsanwendung belegen.

Der NIST-Leitfaden zur Datensicherung in Betriebstechnologie behandelt regelmässige Backups, Wiederherstellungstests und deren Verbindung zum Änderungsmanagement. Seine unmittelbare Ausrichtung liegt auf Operational Technology; die beschriebenen Grundgedanken können auch bei der Planung anderer IT-Wiederherstellungsprozesse helfen.

Eine universelle Testfrequenz gibt es nicht. Als betrieblicher Ausgangspunkt kann ein wiederkehrender Testzyklus für jede zentrale Anwendung definiert werden. Besonders kritische oder häufig geänderte Systeme benötigen entsprechend engere Prüfintervalle.

Zusätzliche Tests sind insbesondere nach folgenden Ereignissen sinnvoll:

• Wechsel der Backup-Software oder des Sicherungsanbieters.
• Grössere Änderungen an Betriebssystemen, Datenbanken oder Anwendungsarchitektur.
• Umstellung von Verschlüsselung, Identitätsverwaltung oder Berechtigungen.
• Einführung neuer geschäftskritischer Anwendungen.
• Längeren Zeiträumen ohne dokumentierten Wiederherstellungsnachweis.

Jeder Test benötigt vorher definierte Erfolgskriterien. Ein Prüfprotokoll sollte Datum, getesteten Datenbestand, verwendeten Wiederherstellungspunkt, gemessene Dauer, Konsistenzprüfung, aufgetretene Fehler und deren Bearbeitungsstatus enthalten.

Für Anwendungen mit personenbezogenen oder vertraulichen Daten muss die Testumgebung angemessen geschützt sein. Isolierung, Zugriffsbeschränkung und gegebenenfalls geeignete Testdatenverfahren verhindern, dass ein Sicherheitstest neue Datenschutzrisiken erzeugt.

Ein dokumentierter Test ist erst abgeschlossen, wenn festgestellte Mängel einer verantwortlichen Person zugeordnet und deren Behebung überprüft wurden.

Welche Anwendung zuerst und in welcher Tiefe getestet werden sollte, lässt sich jedoch nur entscheiden, wenn die geschäftliche Bedeutung der Daten bekannt ist. Dafür braucht es eine praktikable Klassifizierung.

Wie klassifizieren Sie Daten in 4 Stufen, damit Schutzmassnahmen passen?

Eine vierstufige Datenklassifizierung unterscheidet geschäftskritische, wichtige, normale und entbehrliche Daten. Für jede Stufe werden maximal akzeptabler Datenverlust, zulässige Wiederherstellungszeit und notwendige Aufbewahrung bestimmt. Dadurch lassen sich Sicherungsintervalle, Speicherformen und Restore-Testtiefe nach tatsächlichem Geschäftsrisiko festlegen, statt sämtliche Daten mit identischem Aufwand zu schützen.

Die wichtigste Voraussetzung ist die Zusammenarbeit zwischen IT und Fachbereichen. Technische Verantwortliche kennen Speicherorte, Anwendungen und Sicherungsmöglichkeiten. Die Fachabteilungen können beurteilen, welche Folgen ein Datenverlust für Kunden, Aufträge, Finanzen oder die Betriebsfähigkeit hätte.

Ein praktikables Modell könnte so aufgebaut sein. Es handelt sich um ein unternehmensinternes Planungsbeispiel, nicht um eine gesetzlich vorgeschriebene Schweizer Klassifizierung.

Für jede Datenstufe müssen drei Steuergrössen konkret festgelegt werden: RPO, RTO und Aufbewahrungsdauer. Während RPO und RTO die Wiederherstellung bestimmen, richtet sich die Aufbewahrungsdauer zusätzlich nach geschäftlichen, vertraglichen und gesetzlichen Anforderungen.

Im Schweizer Kontext können insbesondere handels- und steuerrechtliche Aufbewahrungspflichten relevant sein. Welche Fristen und Anforderungen tatsächlich gelten, muss für die jeweilige Dokumentenart und den konkreten Betrieb geklärt werden. Eine regelmässige Datensicherung ist zudem nicht automatisch ein geeignetes revisionssicheres Archiv.

Bei Daten mit unterschiedlichen Schutzbedürfnissen kann eine einzige Klassifizierung nach Verfügbarkeit zu kurz greifen. Vertraulichkeit, Integrität und datenschutzrechtliche Anforderungen müssen zusätzlich berücksichtigt werden, etwa bei besonders schützenswerten Personendaten.

Häufige Fehler sind die pauschale Einstufung aller Daten als kritisch und das dauerhafte Festhalten an einmal vergebenen Kategorien. Beides erhöht den Aufwand, ohne die Wiederherstellung zwangsläufig zu verbessern.

Deshalb sollten Datenverantwortliche ihre Einstufungen bei wesentlichen Geschäftsänderungen und in einem festgelegten Überprüfungszyklus neu bewerten. Auch historische Bestände gehören dazu: Daten, die früher unverzichtbar waren, können inzwischen rekonstruierbar oder nicht mehr aufbewahrungspflichtig sein.

Das Ergebnis sollte nicht bloss ein Klassifizierungsdokument sein. Es muss unmittelbar in Sicherungspläne, Berechtigungen, Speicherentscheidungen und Testprioritäten einfliessen.

Selbst bei richtig priorisierten Systemen bleibt allerdings ein weiterer kritischer Faktor bestehen: Im Notfall müssen die berechtigten Personen auf Sicherungen, Schlüssel und Administrationswerkzeuge zugreifen können.

Wie führen Sie Passwortmanager in 30 Tagen ein, ohne Widerstand zu erzeugen?

Ein Passwortmanager lässt sich innerhalb eines 30-tägigen Einführungsplans schrittweise etablieren, wenn Mitarbeitende zuerst den praktischen Nutzen erleben. Beginnen Sie mit einer freiwilligen Pilotgruppe, beheben Sie typische Einrichtungsprobleme und begleiten Sie den anschliessenden Rollout durch kurze Schulungen. Besonders wichtig sind geregelte Notfallzugriffe und die sichere Verwaltung geschäftskritischer Konten.

Widerstand entsteht häufig dann, wenn Beschäftigte eine neue Sicherheitslösung ausschliesslich als zusätzliche Pflicht wahrnehmen. Ein Passwortmanager sollte deshalb nicht mit einer langen Verbotsliste eingeführt werden, sondern mit konkreten Alltagserleichterungen: weniger Passwörter merken, individuelle Zugangsdaten für verschiedene Dienste und vereinfachtes Anmelden durch geeignete Autofill-Funktionen.

Vor dem Rollout muss die IT eine Lösung auswählen, die zur Unternehmensgrösse und bestehenden Identitätsverwaltung passt. Wesentliche Kriterien sind zentrale Benutzerverwaltung, rollenbasierte Berechtigungen, Team-Funktionen, Mehrfaktor-Authentifizierung, nachvollziehbare administrative Prozesse und ein geeigneter Notfallzugriff.

Für die Einführung bietet sich folgender 30-Tage-Fahrplan als Planungsbeispiel an:

Der Zeitrahmen ist eine organisatorische Orientierung. Abhängig von Unternehmensgrösse, vorhandenen Anwendungen und besonderen Compliance-Anforderungen kann die vollständige Umstellung mehr Zeit beanspruchen.

Für den Backup-Betrieb ist vor allem der geregelte Zugriff auf kritische Konten relevant. Administratorzugänge, Backup-Verwaltungskonten und Wiederherstellungsberechtigungen dürfen nicht ausschliesslich einer Person bekannt sein.

Ein Passwortmanager kann helfen, solche Zugänge kontrolliert zu verwalten. Er ersetzt jedoch keine getrennte Notfallzugriffsstrategie. Muss für den Zugang zum Passwortmanager zuerst eine ausgefallene Unternehmensinfrastruktur wiederhergestellt werden, entsteht eine problematische Abhängigkeit.

Deshalb muss auch für den Ausfall der regulären Identitätsverwaltung ein geprüftes Verfahren existieren. Dazu gehören geeignete, stark geschützte Notfallkonten und die sichere Verfügbarkeit benötigter Wiederherstellungsinformationen.

Besondere Regeln können für Zugangsdaten gelten, die aus technischen oder regulatorischen Gründen nicht zentral abgelegt werden dürfen. Diese Ausnahmen müssen dokumentiert und durch alternative Schutzverfahren abgesichert werden.

Eine kurze praktische Schulung sollte zeigen, wie Mitarbeitende ein neues Passwort speichern, einen Zugang sicher freigeben, verlorene Geräte behandeln und Unterstützung erhalten. So wird die Einführung zu einer nachvollziehbaren Arbeitserleichterung.

Der langfristige Erfolg hängt aber nicht allein vom gewählten Werkzeug ab. Passwortregeln müssen so gestaltet sein, dass sie sicher bleiben und im Alltag tatsächlich eingehalten werden können.

Welche Passwortrichtlinien sind sinnvoll, wenn Mitarbeitende sonst Post-its nutzen?

Sinnvolle Passwortrichtlinien setzen auf ausreichend lange, individuelle Passwörter, geeignete Passwortmanager und Mehrfaktor-Authentifizierung. Starre Wechselintervalle und komplizierte Zeichenvorschriften ohne konkreten Sicherheitsnutzen sollten vermieden werden. Entscheidend ist eine Regelung, die Beschäftigte im Arbeitsalltag umsetzen können und die gleichzeitig zentrale Administrations- und Backup-Zugänge zuverlässig schützt.

Wenn Mitarbeitende Passwörter auf Notizzetteln festhalten, liegt nicht immer ein reines Schulungsproblem vor. Häufig fehlt ein praktikables Verfahren, um zahlreiche unterschiedliche Zugangsdaten sicher zu verwalten.

Eine Richtlinie, die gleichzeitig viele komplexe Passwörter verlangt und deren sichere Verwaltung nicht unterstützt, kann unerwünschte Ausweichlösungen begünstigen. Dazu gehören wiederverwendete Passwörter, vorhersehbare Varianten und ungeschützt gespeicherte Zugangsdaten.

Die NIST-Richtlinie SP 800-63B zur Passwortsicherheit setzt auf Passwortlänge, verzichtet auf vorgeschriebene Kombinationen unterschiedlicher Zeichentypen und sieht keine routinemässigen Passwortwechsel ohne Anlass vor. Die Anforderungen dieser US-amerikanischen technischen Richtlinie gelten nicht automatisch als gesetzliche Vorgaben für Schweizer Unternehmen.

Für eine praktikable Unternehmensrichtlinie ergeben sich daraus mehrere Grundsätze:

• Individuelle Passwörter: Unterschiedliche Dienste erhalten unterschiedliche Zugangsdaten, damit die Kompromittierung eines Kontos nicht unmittelbar weitere Zugänge gefährdet.
• Ausreichende Länge: Lange Passphrasen können besonders für manuell einzugebende zentrale Passwörter sinnvoll sein.
• Passwortmanager: Zufällig erzeugte Zugangsdaten lassen sich verwalten, ohne sie auswendig lernen oder unsicher notieren zu müssen.
• Mehrfaktor-Authentifizierung: Kritische Systeme erhalten einen zusätzlichen Schutz, der über das Passwort hinausgeht.
• Anlassbezogene Änderungen: Passwörter werden insbesondere bei Kompromittierung oder entsprechendem Sicherheitsverdacht geändert, statt ausschliesslich nach einem starren Kalender.

Das Ausscheiden einer Mitarbeiterin oder eines Mitarbeiters verlangt vor allem die zuverlässige Deaktivierung persönlicher Zugänge und die Überprüfung noch bestehender Berechtigungen. Gemeinsam verwendete Zugangsdaten müssen gesondert behandelt und bei Bedarf geändert werden.

Besonders sorgfältig ist mit privilegierten Konten umzugehen. Statt dauerhaft gemeinsam genutzter Administratorpasswörter sollten nach Möglichkeit personenbezogene Administrationskonten mit geeigneten Berechtigungen und Nachvollziehbarkeit eingesetzt werden.

Wo gemeinsame technische Zugangsdaten unvermeidbar sind, braucht es eine kontrollierte Verwaltung. Ihr Austausch per E-Mail oder die Ablage in allgemein zugänglichen Dokumenten ist dafür ungeeignet.

Die Umsetzung der Richtlinie sollte Bestandteil des Onboardings werden. Kurze Schulungen, klare Anleitungen und eine erreichbare Supportstelle helfen, sichere Arbeitsweisen zu etablieren. Führungskräfte sollten dieselben Regeln anwenden wie andere Beschäftigte.

Zur Wirksamkeitsprüfung eignen sich beispielsweise Rückmeldungen aus dem Support, wiederkehrende Passwort-Reset-Probleme, die tatsächliche Nutzung freigegebener Werkzeuge und die dokumentierte Kontrolle privilegierter Zugänge. Solche Indikatoren sollten zur Verbesserung der Abläufe dienen, nicht zu einer unnötigen Überwachung einzelner Mitarbeitender.

Für den Wiederherstellungsfall müssen zudem die Zugänge zu Backup-Speichern, Wiederherstellungssystemen und benötigten Entschlüsselungsschlüsseln geregelt sein. Ein sicherer Zugang, der während eines Totalausfalls nicht verfügbar ist, erfüllt seinen Notfallzweck nicht.

Wählen Sie als nächsten Schritt eine geschäftskritische Anwendung aus, lassen Sie ihren letzten erfolgreichen Restore-Nachweis vorlegen und prüfen Sie gemeinsam mit der verantwortlichen Fachabteilung, ob Datenstand, Wiederherstellungsdauer und Notfallzugänge den tatsächlichen Anforderungen entsprechen. Aus diesem ersten dokumentierten Test lässt sich ein wiederkehrender, risikoorientierter Prüfprozess entwickeln.