Backup-Konzept nach BSI: Vorlage und Anleitung

War­um ein for­ma­les Back­up-Kon­zept wich­tig ist #

Gesetz­li­che Anfor­de­run­gen #

• NIS2UmsuCG: Wesent­li­che und wich­ti­ge Ein­rich­tun­gen müs­sen ein Back­up-Kon­zept haben (§30 BSIG-neu, ​“ange­mes­se­ne Maßnahmen”).
• KRI­TIS-Dach­ge­setz: Betrei­ber kri­ti­scher Infra­struk­tur müs­sen BSI-Vor­ga­ben erfüllen.
• Audit: Bei Com­pli­ance-Audits (ISO 27001, BSI C5) ist ein doku­men­tier­tes Back­up-Kon­zept Pflicht.

Prak­ti­scher Nut­zen #

• Hand­lungs­si­cher­heit: Team weiß, wie Back­ups durch­ge­führt werden.
• Kon­sis­tenz: Alle Sys­te­me fol­gen der glei­chen Strategie.
• Reco­very: Im Not­fall (Ran­som­wa­re, Hard­ware-Aus­fall) weiß jeder, was zu tun ist.
• Haf­tung: Im Scha­dens­fall: ​“Wir fol­gen einem Kon­zept” ist bes­ser als ​“Wir machen Back­ups irgendwie.”

---

8 Pflicht­ab­schnit­te eines BSI-kon­for­men Back­up-Kon­zepts #

Abschnitt 1: Ein­füh­rung und Gel­tungs­be­reich #

Was muss hier stehen?

• Zweck des Dokumentes
• Gel­tungs­be­reich (wel­che Sys­te­me, wel­che Organisationseinheiten?)
• Ver­ant­wort­lich­kei­ten (wer ist Back­up-Admi­nis­tra­tor? Wer ist Geschäftsführer-Sponsor?)
• Glos­sar (Defi­ni­tio­nen: RTO, RPO, Reco­very, etc.)

Bei­spiel:

Dieses Konzept definiert die Datensicherung für alle IT-Systeme 
der Musterfirma GmbH. Geltungsbereich: Produktionssysteme, 
Entwicklungs-Systeme, kritische Datenbanken.

Verantwortlich: IT-Leiter (Sponsor), Backup-Administrator (Umsetzung)

Län­ge: 0,5 – 1 Seite

---

Abschnitt 2: Geschäft­li­che Anfor­de­run­gen #

Was muss hier stehen?

• Kri­ti­k­ali­tät der Daten (hoch­kri­tisch, kri­tisch, normal)
• Busi­ness Impact Ana­ly­sis (BIA): Was kos­tet ein Tag Ausfallzeit?
• RTO pro Sys­tem (wie schnell muss Reco­very sein?)
• RPO pro Sys­tem (wie viel Daten­ver­lust ist akzeptabel?)
• Com­pli­ance-Anfor­de­run­gen (Behör­den, Branchen)

Bei­spiel:

DOMÄNEN-CONTROLLER:
- Kritikalität: hochkritisch (alle User-Login abhängig)
- BIA: 50.000 EUR Verlust pro Stunde
- RTO: 2 Stunden (von Angriff bis System online)
- RPO: 1 Stunde (max. Datenverlust = Transaktionen der letzten Stunde)

FILESERVER:
- Kritikalität: kritisch
- BIA: 10.000 EUR Verlust pro Tag
- RTO: 8 Stunden
- RPO: 1 Tag

Län­ge: 1 – 2 Seiten

---

Abschnitt 3: Back­up-Stra­te­gie #

Was muss hier stehen?

• Wel­che Back­up-Medi­en (NAS, Tape, Cloud, Hard­ware Air Gap)?
• Back­up-Archi­tek­tur (3‑Tier emp­foh­len: Snapshot, Off­line, Cloud)
• Für jedes Sys­tem: Back­up-Fre­quen­cy (täg­lich, wöchentlich?)
• Für jedes Back­up-Ziel: Auf­be­wah­rungs­dau­er (z. B. ​“30 Tage online, 7 Jah­re Tape”)

Bei­spiel:

DOMÄNEN-CONTROLLER: 
- Tier 1: Täglicher Snapshot zu NAS (24h Aufbewahrung)
- Tier 2: Täglich Hardware Air Gap Backup (offline, unbegrenzt)
- Tier 3: Wöchentlich Cloud (90-Tage Aufbewahrung für DR)

FILESERVER:
- Tier 1: Täglicher Snapshot zu NAS (7 Tage)
- Tier 2: Täglich zu Cloud (30 Tage)

Län­ge: 2 – 3 Sei­ten (+ Diagramm)

---

Abschnitt 4: Back­up-Tech­ni­sche Umset­zung #

Was muss hier stehen?

• Ver­wen­de­te Soft­ware (z. B. Vee­am Back­up & Repli­ca­ti­on v12)
• Ver­wen­de­te Hard­ware (NAS-Modell, Tape-Lauf­werk, Cloud-Provider)
• Netz­werk-Archi­tek­tur (wo ste­hen Back­up-Ser­ver? VLANs?)
• Encryp­ti­on: wer­den Daten ver­schlüs­selt? Mit wel­chem Standard?
• Dedu­pli­zie­rung: Redu­ziert das Backup-Volumen?

Bei­spiel:

BACKUP-SOFTWARE: Veeam Backup & Replication v12
HARDWARE:
- Backup Server: Dell PowerEdge R750, 64GB RAM, 10Gbps NIC
- NAS: Synology RS3621xs+ mit 48TB (RAID 6)
- Cloud: AWS S3 mit Object Lock (Compliance Mode)
- Hardware Air Gap: Silent Brick Max Air 1PB

ENCRYPTION: AES-256, Keys zentral im HSM gelagert
DEDUPLIZIERUNG: Aktiv (reduziert Backup-Volumen um ~70%)

Län­ge: 2 – 3 Seiten

---

Abschnitt 5: Mel­de­pflich­ten und Daten­schutz #

Was muss hier stehen?

• DSGVO: Wie wird per­so­nen­be­zo­ge­ne Daten geschützt?
• Stand­ort der Back­ups (z. B. ​“EU-DSGVO-kon­form, kei­ne US-Cloud”)
• Zugriffs­kon­trol­le (wer darf Back­ups sehen/​wiederherstellen?)
• Audit-Trail (Zugrif­fe wer­den protokolliert)
• Mel­de­pflich­ten bei Sicher­heits­ver­let­zung (NIS2UmsuCG, 72h Mel­dung an BSI)

Bei­spiel:

DATENSCHUTZ:
- Backups enthalten personenbezogene Daten (Mitarbeiterlisten, Kundendaten)
- Standort: EU (Deutschland, DSGVO-konform)
- Cloud-Backups: AWS EU-Region (Datenschutz-Vereinbarung abgeschlossen)

ZUGRIFFSKONTROLLE:
- Nur Backup-Administrator hat Zugriff
- Restore-Request: Genehmigung durch IT-Leiter erforderlich
- Audit-Log: Alle Backup/Restore-Aktivitäten protokolliert

MELDEPFLICHTEN:
- Bei Ransomware-Angriff: BSI Meldung innerhalb 72h (NIS2UmsuCG)
- Bei Daten-Leak: Datenschutz-Behörde benachrichtigen

Län­ge: 1 – 2 Seiten

---

Abschnitt 6: Reco­very-Pro­ze­du­ren #

Was muss hier stehen?

• Schritt-für-Schritt Pro­zess zum Wie­der­her­stel­len (für jedes kri­ti­sche System)
• Zeit­schät­zung für voll­stän­di­ge Reco­very (muss mit RTO kom­pa­ti­bel sein)
• Vor­/Nach-Check­list (was vor Reco­very zu tun? Was nach Reco­very zu überprüfen?)
• Eska­la­ti­on (wen anru­fen, wenn Reco­very fehlschlägt?)

Bei­spiel: Domä­nen-Con­trol­ler Recovery

SCHRITT 1: Diagnose (15 min)
- Stelle fest, ob DC wirklich infiziert ist
- Prüfe, ob andere DCs noch online sind
- Kontaktiere Geschäftsführung + IT-Team

SCHRITT 2: Backup identifizieren (10 min)
- Letzte saubere Backup auswählen (vor Infektion)
- Hardware Air Gap montieren (falls offline)
- Verifikation: Backup ist lesbar?

SCHRITT 3: Recovery-Umgebung preparieren (30 min)
- Neuen DC-VM starten (oder Recovery-Hardware)
- Netzwerk isolieren (VLAN Backup, nicht Produktion)

SCHRITT 4: Recovery durchführen (60 min)
- Daten aus Backup wiederherstellen
- DC Systemdienste starten (Active Directory, Kerberos)
- Prüfen: AD replikation mit anderen DCs

SCHRITT 5: Validierung (30 min)
- Test: User-Login funktioniert?
- Test: Fileserver Shares verfügbar?
- Test: Mail-System funktioniert?

SCHRITT 6: Production-Cutover (30 min)
- DC ins Produktions-VLAN überführen
- Alte DC abschalten
- User benachrichtigen: System wieder online

TOTAL RTO: ~3 Stunden (Ziel: 2 Stunden)

Län­ge: 3 – 5 Sei­ten (für meh­re­re kri­ti­sche Systeme)

---

Abschnitt 7: Reco­very-Tests und Vali­die­rung #

Was muss hier stehen?

• Wie häu­fig wer­den Reco­very-Tests durch­ge­führt? (BSI emp­fiehlt: mind. jährlich)
• Wel­che Sys­te­me wer­den getes­tet? (Alle kri­ti­schen? Sample?)
• Test-Doku­men­ta­ti­on: Wer führt Test durch? Datum? Ergebnis?
• Feh­ler­be­hand­lung: Was ist, wenn Reco­very fehlschlägt?

Bei­spiel:

RECOVERY-TEST-PLAN:

Quartal 1: Domänen-Controller Recovery-Test
- Durchführung: Januar (2 Wochen geplanter Testfenster)
- Verantwortlich: Backup-Administrator
- System: Test-DC (nicht Production!)
- Zeitmessung: Backup-Start bis DC online
- Bestanden: Wenn RTO < 2 Stunden

Quartal 2: Datenbank Recovery-Test
- System: Produktions-Datenbank (mit Downtime-Fenster)
- Veitmessung: Backup-Restore bis Datenbankintegrität OK

Quartal 3: Fileserver Recovery-Test
- System: Produktion (off-hours)

Quartal 4: Vollständiger Ransomware-Drill
- Szenario: Domäne kompromittiert, Recovery alle Systeme
- Zeitmessung: Komplette Ausfallzeit

Län­ge: 1 – 2 Seiten

---

Abschnitt 8: War­tung und Gül­tig­keit #

Was muss hier stehen?

• Ver­si­ons­ge­schich­te (wann wur­de Kon­zept aktualisiert?)
• Gül­tig­keits­dau­er (z. B. ​“Gül­tig bis 31.12.2025, dann Review”)
• Geneh­mi­gung (Geschäfts­füh­rung signiert)
• Review-Pro­zess (jähr­lich oder nach gro­ßen Änderungen)
• Kon­takt (wer ist Ansprechpartner?)

Bei­spiel:

VERSIONSGESCHICHTE:
v1.0 (01.01.2024): Initial version
v1.1 (15.06.2024): Hardware Air Gap hinzugefügt
v2.0 (15.10.2024): NIS2UmsuCG Anforderungen eingearbeitet

GÜLTIG BIS: 31.12.2025
REVIEW: Spätestens 31.10.2025 (3 Monate vorher)

GENEHMIGUNG:
- IT-Leiter: Max Mustermann (Unterschrift) ____ Datum: 15.10.2024
- Geschäftsführer: Petra Beispiel (Unterschrift) ____ Datum: 15.10.2024

KONTAKT:
- Verantwortlich: IT-Leiter ([email protected])
- Fragen: [email protected]

Län­ge: 1 Seite

---

Gesamt­um­fang und Vor­la­ge #

Ein aus­sa­ge­kräf­ti­ges Back­up-Kon­zept hat typi­cal­ly 8 – 15 Sei­ten:

• Einführung/​Scope: 1 Seite
• Anforderungen/​BIA: 2 Seiten
• Stra­te­gie: 3 Seiten
• Tech­ni­sche Umset­zung: 3 Seiten
• Datenschutz/​Compliance: 2 Seiten
• Reco­very-Pro­ze­du­ren: 5 Seiten
• Tests: 2 Seiten
• War­tung: 1 Seite
• Anhang: Pro­zess-Dia­gram­me, Reco­very-Check­lis­ten, Kontaktlisten

---

BSI-Com­pli­ance: Kon­kre­te Vor­ga­ben (CON.3) #

Das BSI defi­niert in CON.3 kon­kre­te Anforderungen:

BSI-Vor­ga­be	Wo doku­men­tiert?
**CON.3.A1** Daten­si­che­rungs­richt­li­nie erstellen	Abschnitt 1 – 2 (Ein­füh­rung, Anforderungen)
**CON.3.A10** Gül­tig­keits­be­reich und Häu­fig­keit definieren	Abschnitt 2 + 3 (RTO/RPO, Strategie)
**CON.3.A11** Auf­be­wah­rungs­dau­er definieren	Abschnitt 3 (Auf­be­wah­rung)
**CON.3.A14** Reco­very-Tests durchführen	Abschnitt 7 (Tests)
**CON.3.A5** Off­line-Back­ups durchführen	Abschnitt 3 + 4 (Stra­te­gie, Umsetzung)
**CON.3.A6** Back­up-Inte­gri­tät testen	Abschnitt 7 (Vali­die­rung)

---

Häu­fi­ge Feh­ler #

❌ Zu all­ge­mein geschrie­ben #

“Wir machen täg­li­che Back­ups” — nicht spe­zi­fisch genug. Muss sein: ​“Täg­lich 22:00, zu NAS Tier 1 und Hard­ware Air Gap Tier 2.”

❌ Kei­ne RTO/RPO defi­niert #

Ohne RTO/RPO ist kein Reco­very-Plan mög­lich. Muss sein: ​“Domä­ne: RTO 2h, RPO 1h.”

❌ Reco­very-Tests nie durch­ge­führt #

Kon­zept exis­tiert, aber nicht getes­tet. Regel: Tests min­des­tens 1x/​Jahr, dokumentiert.

❌ Kei­ne Geneh­mi­gung #

Kon­zept ist eine Richt­li­nie. Ohne Geschäfts­füh­rer-Signa­tur hat es kei­ne Kraft.

---