Wie vor Racheaktionen von Admins schützen?

[NM78]

Am Wochenende ging die Meldung durch die Medien, dass ein Ex-Admin sich heimlich eigene Zugänge zu den Servern seines ehemaligen Arbeitgebers eingerichtet und damit die Daten nachträglich gelöscht hat.

Habt Ihr eine praktikable Empfehlung wie man sich vor schweren Folgen solch einer Aktion als "Endkunde" (Nutzer von vServer/Decicated Servern) am besten schützen kann?

Bisher lassen wir Nachts von Plesk inkrementelle Backups erstellen. Die gesamte "Festplatte" wird dann zusätzlich einmal täglich vom Rechenzentrum 1:1 gesichert (also inkl. Plesk Backups). Dieses Backup liegt dann aber auch wieder im Berech des Betreibers des Rechenzentrums.

Unser eigener Internetanschluß ist zu langsam um nächtlich z.B. 50GB Backups herunter zu laden.

Welchen Weg würdet ihr empfehlen um zumindest die Plesk Backups zusätzlich zu sichern? Alles nächtlich zu einem anderen Anbieter kopieren und die schnelle Anbindung der Rechenzentren nutzen?

Ich fänd es schon sehr Vorteilhaft wenn die Backups auch direkt auf dem Server liegen. Aber die Variante alles zu anderen Anbietern zu verschieben, scheint in Hinblick auf "Rache" Admins (unanbhängig von den Vorkehrungen der Rechenzentren) als einzige Sinnvolle Lösung zu bleiben, oder?

 

[Deleted member 11740]

Die Admins haben soviel Macht, da sie die interne Infrastruktur so gut kennen wie kein anderer.

Primär: Zugänge sperren und nach Hintertüren suchen.
Backups: Macht man sowieso. Die Backups müssen auch vor dem exAdmin geschützt sein. Am besten offline.

 

[NM78]

Vielen Dank für Deine schnelle Antwort!

Wie ich schon schrieb, habe ich die Offline Option nicht (Datenmenge zu groß).

Es bleibt somit nur, das regelmäßige Verschieben einer Kopie der Backups in ein anderes Rechenzentrum, oder?

Gibt es da eine Empfehlung/How To wie man das z.B. mit Plesk sicher hinbekommt?

 

[storvi]

Sich gegen Administratoren zu schützen ist nahezu unmöglich. Auditing oder ähnliches kann es aufdecken - aber ein guter / fähiger Admin kann auf jeden Fall erst einmal Schaden anrichten.

Tut mir leid das sagen zu müssen: "unser Internetanschluss ist zu langsam" ist kein Argument.
Entweder du möchtest oder musst dich schützen - dann muss eine Lösung gefunden werden, oder es ist egal.

Lösungen können Richtung Schutz gehen - diesen aber nie zu 100% erreichen. Geld und Zeit kostet es natürlich zusätzlich.

Gruß
Markus

 

[marce]

Eine Kopie in einem anderen RZ nützt auch nichts - an die kommt der böse Admin ja auch. Da helfen auch keine Filesystem-Snapshots oder anderes.

Einigermaßen sicher vor solchen Racheakten sind nur Daten, die "rein offline" zu erreichen sind (sprich z.B. das Band oder die USB-Platte im Tresor) oder irgendeine Art von WORM-Medium darstellen -die also nach dem Schreiben nicht mehr verändert werden können.

Dafür gibt's ja die Desaster-Recovery-Szenarien. Ob die Ursache des kompletten Ausfalls eines RZ nun ein Brand oder ein Amok-Admin war macht ja keinen Unterschied. Weg ist weg.

 

[iffi]

@mace:

Das eine Kopie in einem anderen RZ allgemein nicht schützt ist schlicht falsch. Wie so oft im Leben ist das "wie" der entscheidende Faktor.

@NM78:

Um auf deine Frage und deine Situation zurückzukommen, hier eine mögliche Lösung:
Wenn ein lokales Backup aus Infrastrukturgründen unpraktikabel ist würde ich dir dazu raten, einen zweiten Provider mit eigenem RZ mit ins Boot zu holen.
Ein mögliches Setup wäre ein Backupserver bei Provider2, welcher die Backups, welche auf deinem Produktivsystem erzeugt werden, zyklisch abruft und abspeichert. Dein Produktivsystem darf auf diesen Server nicht/nur lesend zugreifen dürfen, der Backupserver idealerweise auch(obwohl auch schreibend möglich wäre). Hierdurch kann bei Provider1 passieren was will, deine backups sind sicher. (Es sei denn, beide provider haben zeitgleich einen Ausfall/RagingAdmin/Meteoriteneinschlag)

Gruß,

Iffi

 

[marce]

Ok, und wer administriert den externen Backup-Job? Von alleine richtet der sich nicht ein - und auf min. eine der beteiligten Komponenten hat der "böse Admin" ja uneingeschränkten Zugriff - sprich er kann sie manipulieren. Und damit "fliegt" das Konstrukt dann auch wieder auseinander.

 

[nexus]

Die bisherigen Antworten gehen ein wenig an der ursprünglichen Fragestellung vorbei:

Habt Ihr eine praktikable Empfehlung wie man sich vor schweren Folgen solch einer Aktion als "Endkunde" (Nutzer von vServer/Decicated Servern) am besten schützen kann?

Der TE möchte für den Fall, daß ein "böser Admin" bei seinem Hostinganbieter die aktuellen Daten löschen sollte, ein funktionierendes Backup haben. Dafür sucht er eine Backuplösung.

Für diesen Fall wäre z.B. ein Backupserver bei einem zweiten Anbieter sinnvoll, auf dem die Backupdaten ausgelagert werden. So wäre im Worst Case ein Neuaufsetzen der Webpräsenz aus den (hoffentlich aktuellen) Backupdaten möglich.

 

[NM78]

Vielen Dank @marce, @iffi und @nexus für Eure hilfreichen Kommentare. Genau darum geht es, um einen Bösen bzw. Amok Admin bei unserem Provider.

Um die bösen Admins bei uns im Haus können/müssen wir uns natürlich selbst kümmern.

Aber wie stellt man das am besten (als 90% Plesk Nutzer) an, also die Backups aus einem externen Rechenzentrum abrufen lassen. Wir wollen ja wie gesagt die Backups auch direkt auf dem eigentlichen Server liegen haben.

Mit Hilfe von Plesk kann ich nur entweder lokal/oder extern per FTP speichern, oder? Wir bräuchten "sowohl als auch".

 

[Joe User]

scp oder sftp sind hier die richtigen Stichworte.