Backup im Tier-Konzept
Hallochen Gemeinde!
In der interessanten Diskussion AD Tiering Umsetzung wurde die Gestaltung des Zugriffs im Tier-Konzept anschaulich erörtert. Wie sieht es davon ausgehend mit einem zentralen Backup aus (= Backupserver plus Backupagents auf den jeweiligen zu sichernden Maschinen)? Wie gestaltet ihr das organisatorisch / konzeptionell? Habt ihr pro Tier-Ebene einen Backupserver?
Vielen Dank im Voraus für Eure Rückäußerungen und viele Grüße
HansDampf06
In der interessanten Diskussion AD Tiering Umsetzung wurde die Gestaltung des Zugriffs im Tier-Konzept anschaulich erörtert. Wie sieht es davon ausgehend mit einem zentralen Backup aus (= Backupserver plus Backupagents auf den jeweiligen zu sichernden Maschinen)? Wie gestaltet ihr das organisatorisch / konzeptionell? Habt ihr pro Tier-Ebene einen Backupserver?
Vielen Dank im Voraus für Eure Rückäußerungen und viele Grüße
HansDampf06
Please also mark the comments that contributed to the solution of the article
Content-ID: 8141946912
Url: https://administrator.de/contentid/8141946912
Printed on: October 7, 2024 at 23:10 o'clock
7 Comments
Latest comment
Hallo,
bestenfalls läuft das Backup nicht in der gleichen Domain. Davon abgesehen laufen die meisten Agents als Service.
Bei der Tier Stragie geht es ja um die privilegiertenen Zugriffe der Admin User.
Wo siehst du darin ein Problem?
Ps.: Wir haben die Strategie seit ca 2-3 Jahren im Einsatz und ich konnte da z.B. bei Veeam keine direkten Probleme feststellen.
Gruß
bestenfalls läuft das Backup nicht in der gleichen Domain. Davon abgesehen laufen die meisten Agents als Service.
Bei der Tier Stragie geht es ja um die privilegiertenen Zugriffe der Admin User.
Wo siehst du darin ein Problem?
Ps.: Wir haben die Strategie seit ca 2-3 Jahren im Einsatz und ich konnte da z.B. bei Veeam keine direkten Probleme feststellen.
Gruß
Hi
Wie haben das im Tier Model bei uns so geregelt, dass es für Tier 0 einen AD Benutzer ebenfalls in der Gruppe und OU der Tier 0 gibt, der das AD sichert.
Auf den anderen zu sichernden Systemen gibt es einen lokalen User, welcher pro System Adminrechte hat. Passwort ist auf jedem System ein anderes.
Klar wenn man es von Anfang an so macht ist der Arbeitsaufwand gering. Wenn alles bisher mit nem zentralen Backupuser aus dem AD mit Adminrechten gesichert wird, ist es ne Menge Arbeit, die sich aber lohnt.
Somit besteht bei einer Kompromittierung nicht de Gefahr, dass der Angreifer über den Backup Benutzer zum nächsten System kommt - außer beim AD / den DCs selbst, aber wenn er soweit ist hast du eh verloren.
Backupinfrastruktur ist kein DomainMember und wir nutzen Veeam B&R mit immutable Storages
Usw.
Wie haben das im Tier Model bei uns so geregelt, dass es für Tier 0 einen AD Benutzer ebenfalls in der Gruppe und OU der Tier 0 gibt, der das AD sichert.
Auf den anderen zu sichernden Systemen gibt es einen lokalen User, welcher pro System Adminrechte hat. Passwort ist auf jedem System ein anderes.
Klar wenn man es von Anfang an so macht ist der Arbeitsaufwand gering. Wenn alles bisher mit nem zentralen Backupuser aus dem AD mit Adminrechten gesichert wird, ist es ne Menge Arbeit, die sich aber lohnt.
Somit besteht bei einer Kompromittierung nicht de Gefahr, dass der Angreifer über den Backup Benutzer zum nächsten System kommt - außer beim AD / den DCs selbst, aber wenn er soweit ist hast du eh verloren.
Backupinfrastruktur ist kein DomainMember und wir nutzen Veeam B&R mit immutable Storages
Usw.
Das wichtigste ist immer: Das Backup-System holt sich die Daten von den Quellsystemen.
Das ist IMO nicht mehr (ganz) richtig. Aus mehreren Gründen:1. Hat ein Pull-Backupsystem, das prinzipbedingt selbständig und mit höchsten Rechten auf alle zu sichernden Server und Clients zugreift, die totale Macht über das System, ist also ein bevorzugtes Angriffsziel. Bei erfolgreichem Angriff ist dann alles weg.
2. Gibt es taugliche Mechanismen, die verhindern, dass bereits erstellte Push-Backups überschrieben werden können.
3. Arbeiten moderne Backups snapshot- und/oder datenbankbasiert, so dass die zu sichernde Maschine selbständig (und daher extrem schnell) die geänderten Daten ermitteln und diese an den Backupserver übermitteln kann. Beim klassischen Pull-Backup hingegen müsste erst ein langwieriger Abgleich über die Leitung erfolgen. Dem könnte man allerdings wahrscheinlich mit Agenten und Datenbankabgleich in der ersten Stufe des Backups abhelfen.
Borg-Backup arbeitet vorzugsweise im Push-Modus (und dort mit ausgezeichneten Schutzfunktionen), HyperBackup von Synology sogar ausschließlich (ohne Schutzfunktionen, meine ich) und ich habe es nie untersucht, aber bei Veeam sah es mir ähnlich aus wie bei Borg.
Am Ende gibt es da wahrscheinlich wieder keine Wahrheit, denn es sind schlicht unterschiedliche Angriffsszenarien. Ich halte die Lösung von Borg Backup jedoch für in hohem Maße sicher.
Hier noch ein paar Gedanken zum Thema aus der TrueNAS-Community.
Zur Frage des Kollegen @HansDampf06:
Ich sichere (vorzugsweise) mit Borg und dort hat jedes Gerät (Server/Client) nur Rechte an seinem Backup-Repository. Ein Zugriff auf die Repositories anderer Geräte auf dem Server ist so faktisch ausgeschlossen. Das sichernde Gerät selbst ist wegen der Verwendung des append-only Modus seinerseits nicht in der Lage, seine früheren Backups zu löschen. Ein Tiering ist daher nicht nötig. Der Backupserver befindet sich in einem anderen Netz und ist in dem geschilderten beschränkten Rahmen nur für die sichernden Geräte über SSH erreichbar.
Wenn man richtig paranoid ist, kann man nach einer Sicherung natürlich auch noch Snapshots auf dem Backup-Server machen oder die Repositories woanders hin replizieren. So Paranoid war ich bislang aber noch nicht - kommt sicher auf die Anforderungen der Umgebung an.
Viele Grüße, commodity
Hier denke ich vor allem an einen SSH-gestützten Datenaustausch.
SSH gilt als sicheres Protokoll, das verbreitet direkt im Internet eingesetzt wird. Ich denke nicht, dass, Key-Authentification vorausgesetzt, hier real wahrscheinliche Bedrohungen bestehen. Pull oder Push ist in diesem Zusammenhang wohl egal.ob beim pull-Zugriff auf den Client eine Kompromittierung auf den Backupserver überspringen kann.
Auch das halte ich für extrem unwahrscheinlich. Wie soll das stattfinden? Es genügt ja ggf. nicht nur die Übertragung schädlicher Daten, sie müssten auch noch aktiv eingesetzt werden können. Wenn das Backup lediglich schreibrechte hat, kann es nichts ausführen.Für die immer verbleibenden Restrisiken von Implementierungsfehlern der eingesetzten Programme bzw. verwendeten Konfigurationen hilft IMO nur ein weiteres unabhängiges Backup, das nicht im Netz hängt, aber auch nicht so komfortabel sein muss, weil es nicht der schnellen Rücksicherung dient, sondern nur bei Eintritt eines wirklichen Desasters eingesetzt wird. Dieses muss auch nur den Datenbestand als solchen enthalten, nicht aber z.B. die Luxussicherung ganzer Maschinen. Wenn der Backupserver nicht delokalisiert wurde, ist es sowieso Pflicht, Kopien extern zu lagern. Alles in allem gibt es hier wohl keine pauschalen Lösungen. Das Backup ist immer am erforderlichen Schutzniveau des Kunden zu orientieren.
Mit einem delokalisierten Borg, Veeam o.ä. lässt Du die reale Praxis aber schon weit hinter Dir. In der Realität finde ich bei faktisch jedem neuen Kunden (alles KU) ausschließlich lokale Backups, die zudem ungeschützt und dauerhaft im Netz hängen, gern auch gleich mal im selben Rack. Da sichert dann eine popelige Synology (weil's ja so einfach ist) und das wars. Kein Backup-VLAN, kein Schutzkonzept, kein 1-2-3. Bei Brand/Diebstahl alles futsch. Sicher alles von Kollegen aufgesetzt, die nicht bei Administrator.de mitlesen
Viele Grüße, commodity