True IT Stories

Wer die Domäne übernimmt, übernimmt das Backup

Ein Healthcheck bei einem Kunden, wir gehen die Veeam-Umgebung durch. Bevor wir zur Frage kommen, sagt der Admin selbst: „Der Backup-Server ist bei uns in der Domäne. Das ist wahrscheinlich sehr schlecht.“

Er wusste es also. Fast alle wissen es. Und trotzdem ist es einer der Befunde, die wir am häufigsten aufschreiben.

Der Gedanke dahinter passt in einen Satz: Steht der Backup-Server in derselben Domäne wie alles andere, gehört er dem, der die Domäne übernimmt.

Was ein Angreifer dort vorfindet

Wer es bei einem Angriff bis zum Domänen-Admin geschafft hat, muss den Backup-Server nicht mehr angreifen. Er meldet sich an. Die Konten, mit denen er die Dateiserver verschlüsselt, öffnen ihm auch die Veeam-Konsole. Von dort aus löscht er Sicherungen, verkürzt Aufbewahrungen oder schaltet Jobs ab, und zwar in Ruhe, bevor er zuschlägt.

Und er findet mehr als Sicherungen:

  • Eine Landkarte. Der Backup-Server kennt jeden Host, jede VM, jede Freigabe und jeden Speicher. Veeam schreibt dazu im eigenen Leitfaden: „An intruder gaining high privileges on a VBR Server can get information about the infrastructure it protects.“
  • Einen Schlüsselbund. Damit Veeam sichern kann, liegen auf dem Server Zugangsdaten zu vCenter, Hyper-V, Linux-Servern und Speichersystemen. Wer dort Admin ist, kommt an sie heran.
  • Eine Abhängigkeit im Ernstfall. Ist die Domäne verschlüsselt, sind die Domänencontroller es meistens auch. Dann fehlen dem Backup-Server Anmeldung und Namensauflösung, genau in dem Moment, in dem man ihn für den Restore braucht.

Das ist keine Meinung

Der Einwand kommt jedes Mal: Das sei eben unsere Sicht. Ist es nicht. Es ist die Empfehlung des Herstellers, und zwar an mehreren Stellen:

  1. Der Sicherheitsleitfaden von Veeam begründet es grundsätzlich: „a data protection system should not rely on the environment it is meant to protect in any way!“
  2. Die offizielle Dokumentation zu Veeam Backup & Replication empfiehlt für große Umgebungen eine eigene Management-Domäne in einem getrennten Forest. Und für alle anderen: „For medium-sized and small environments, backup infrastructure components can be placed to a separate workgroup.“
  3. Veeams eingebauter Security & Compliance Analyzer prüft den Punkt „Backup server should not be a part of the production domain“. Grün wird er nur, wenn der Backup-Server in gar keiner Domäne ist.

Der dritte Punkt ist der praktischste. Den Analyzer hat jede aktuelle Installation, und er zeigt den Befund ohne Diskussion an.

Grafik: Drei Wege für den Backup-Server. Worst Practice: in der Produktivdomäne, erstes Ziel eines Angreifers. Quick Win: eigene Arbeitsgruppe und eigenes Netz, passt zu kleinen und mittleren Umgebungen, als Empfehlung markiert. Best Practice: Management-Domäne im eigenen Forest, passt zu großen Umgebungen mit eigenem AD-Betrieb.

Veeam nennt drei Wege, nach Sicherheit geordnet. Für die allermeisten KMU ist der mittlere der richtige: eine Arbeitsgruppe im eigenen Netz. Eine zweite Domäne nur für das Backup klingt sauberer, braucht aber eigene Domänencontroller und Leute, die sie pflegen. Wer die Produktivdomäne schon kaum gepflegt bekommt, wird eine zweite nicht besser pflegen.

Was erlaubt bleibt

Raus aus der Domäne heißt nicht raus aus dem Netz. Der Backup-Server darf weiter die DNS-Server der Umgebung fragen und seine Uhrzeit von dort holen. Das stört nicht.

Das Problem ist das Vertrauen zwischen beiden Seiten, nicht die Technik: dass ein Konto aus der Produktion auf dem Backup-Server etwas darf. Deshalb gehören dazu:

  • Eigene Anmeldung. Persönliche, lokale Konten je Admin, keine geteilten, keine Domänenkonten.
  • MFA an der Konsole. Das kann Veeam seit Version 12.
  • Eigenes Netz. Der Backup-Server steht hinter einer Firewall, die nur durchlässt, was die Sicherung braucht. Wie wir Verwaltungsnetze trennen, steht in Ein Management-Netz für alles .
  • Kein RDP aus dem Produktivnetz.

Und ganz unten bleibt das Speicherziel, das selbst der Admin nicht löschen kann. Warum eine Freigabe dafür nicht reicht, steht in Die Freigabe, die jeder löschen darf .

„Dann wird die Verwaltung aufwendiger“

Stimmt. Eigene Konten, eigene Passwörter, kein bequemes Single Sign-on. Genau darin besteht der Schutz: Was für euch umständlicher ist, ist für den Angreifer eine Wand.

Der Aufwand fällt außerdem genau einmal an, beim Aufbau. Einen Backup-Server von Anfang an in eine Arbeitsgruppe zu stellen, kostet eine Stunde. Ihn später aus der Domäne herauszulösen, mit allen Konten, Zugangsdaten und Abhängigkeiten, ist die deutlich schwierigere Aufgabe.

Selbst nachsehen

Ob ein Server in einer Domäne ist, zeigt eine Zeile PowerShell:

Get-CimInstance Win32_ComputerSystem | Select-Object Name, PartOfDomain, Domain

Steht bei PartOfDomain ein True, ist das der Befund. Dann lohnt der Blick in den Security & Compliance Analyzer, denn er listet gleich die übrigen Punkte mit, von MFA bis zur abgeschalteten Fernverwaltung.

Wie es weitergeht

Das ist der erste Teil einer Reihe. Weiter geht es mit den drei Wegen im Detail und warum ein eigener Admin-Forest für 20 Server zu groß ist. Danach: was in der Arbeitsgruppe plötzlich fehlt , vom Zeitdienst bis zum Firewall-Profil. Und die Einwände, die immer kommen .

Quellen