7
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 8141946912
Url: https://administrator.de/contentid/8141946912
Printed on: April 27, 2024 at 11:04 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ß
Mein Ausgangsgedanke war, dass zwischen dem Backupserver und den Agents bzw. seitens der Agents auf den Maschinen bestimmte höhere Rechte erforderlich sind, um die Sicherungen durchführen zu können. Greift ein Backupsystem auf unterschiedliche Tier-Ebenen zu, könnte das ähnlich wie beim Adminzugriff bedenklich sein. Deshalb meine Nachfrage, wie das zu beurteilen ist.
Viele Grüße
HansDampf06
Viele Grüße
HansDampf06
Moin,
wenn das Backup-System es hergibt, arbeitest du mit mehreren Benutzern, für die jeweiligen Tiers.
Das wichtigste ist immer: Das Backup-System holt sich die Daten von den Quellsystemen.
Die Quellsysteme dürfen niemals nie selbst & proaktiv die Daten in das Backup-System schreiben.
wenn das Backup-System es hergibt, arbeitest du mit mehreren Benutzern, für die jeweiligen Tiers.
Das wichtigste ist immer: Das Backup-System holt sich die Daten von den Quellsystemen.
Die Quellsysteme dürfen niemals nie selbst & proaktiv die Daten in das Backup-System schreiben.
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
Ich habe mir die beiden von @commodity verlinkten Diskussionen durchgelesen. Als Quintessenz ziehe ich daraus die Schlussfolgerung, ähnlich wie @commodity, dass man sich hinsichtlich pull oder push dafür entscheiden muss, was ist das vorrangige Angriffsszenario, gegen das man sich schützen möchte. Gefühlt tendiere ich zu pull, was aber am klassischen Backupverständnis liegen mag.
In allen Fällen bleibt irgendwie das Problem, dass der Backupserver dennoch ein zentraler Punkt ist und dass der Angriff auf einen Client immer die Gefahr in sich birgt, ein Sprungbrett zum Backupserver zu sein. Natürlich ist das stark reduziert, wenn der Client bei push den Backupserver lediglich als eine Art Freigabe benutzt. Bei pull kommt es hingegen darauf an, ob beim pull-Zugriff auf den Client eine Kompromittierung auf den Backupserver überspringen kann. Denn ansonsten kann sich der Backupserver völlig isoliert hinter einer Firewall, VLAN etc. befinden, so dass ein direkter Zugriff vom Client auf den Backupserver nicht ohne weiteres möglich ist.
Eigentlich kann man am Ende nur prüfen, welche Fragen das zu verwendende Backupsystem in dieser Hinsicht aufwirft und das gegebenenfalls mit einem alternativen Backupsystem vergleichen. Schön ist, dass das von @commodity verwendete Borg-Backup auf Linux basiert. Die integrierte Deduplikation mittels chunks ist in sehr interessanter Ansatz, um einen Datenbestand selbst bei Änderungen außerordentlich klein zu halten - das muss ich mir noch genauer ansehen.
Bei dieser Gelegenheit noch folgendes: Die Überlegungen von pull und push dürften doch eigentlich immer dann gelten, wenn irgendwelche Daten von mehreren Clients / Servern an einem zentralen Ort zusammengeführt werden sollen. Hier denke ich vor allem an einen SSH-gestützten Datenaustausch. Sehe ich das richtig?
Viele Grüße
HansDampf06
In allen Fällen bleibt irgendwie das Problem, dass der Backupserver dennoch ein zentraler Punkt ist und dass der Angriff auf einen Client immer die Gefahr in sich birgt, ein Sprungbrett zum Backupserver zu sein. Natürlich ist das stark reduziert, wenn der Client bei push den Backupserver lediglich als eine Art Freigabe benutzt. Bei pull kommt es hingegen darauf an, ob beim pull-Zugriff auf den Client eine Kompromittierung auf den Backupserver überspringen kann. Denn ansonsten kann sich der Backupserver völlig isoliert hinter einer Firewall, VLAN etc. befinden, so dass ein direkter Zugriff vom Client auf den Backupserver nicht ohne weiteres möglich ist.
Eigentlich kann man am Ende nur prüfen, welche Fragen das zu verwendende Backupsystem in dieser Hinsicht aufwirft und das gegebenenfalls mit einem alternativen Backupsystem vergleichen. Schön ist, dass das von @commodity verwendete Borg-Backup auf Linux basiert. Die integrierte Deduplikation mittels chunks ist in sehr interessanter Ansatz, um einen Datenbestand selbst bei Änderungen außerordentlich klein zu halten - das muss ich mir noch genauer ansehen.
Bei dieser Gelegenheit noch folgendes: Die Überlegungen von pull und push dürften doch eigentlich immer dann gelten, wenn irgendwelche Daten von mehreren Clients / Servern an einem zentralen Ort zusammengeführt werden sollen. Hier denke ich vor allem an einen SSH-gestützten Datenaustausch. Sehe ich das richtig?
Viele Grüße
HansDampf06
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