SingleSign On dans l'écosystème TIM :
Mon compte
- Informations exclusives sur les chaînes
- Early Access sur les événements
- Suivi des commandes/projets 24x7, contrats MSP, etc.
LogoutLogin TIM Portal
TIM Partner News
Vous n'avez pas encore de login ? Demander maintenant!
Vous n'êtes pas un partenaire TIM ? S'inscrire ici
Wie können sich Unternehmen schnell von einem Ransomware-Angriff erholen?
Datensicherungen können ein effektiver Weg sein, um Daten wiederherzustellen, die durch den Angriff gesperrt/verschlüsselt wurden. Was aber, wenn Ihre Backup-Daten durch einen Ransomware-Angriff ebenfalls verschlüsselt oder gelöscht werden? Wie stellen Sie sicher, dass Ihre Backup-Daten nicht anfällig für diese Angriffe sind?
Der Schlüssel sind unveränderliche Backups
Während primäre Speichersysteme offen und für Client-Systeme verfügbar sein müssen, sollten Ihre Backup-Daten unveränderbar sein. Das bedeutet, dass einmal geschriebene Daten nicht von Clients in Ihrem Netzwerk gelesen, geändert oder gelöscht werden können. Nur so kann eine Wiederherstellung gewährleistet werden, wenn Produktionssysteme kompromittiert werden.
Dies geht weit über einfache Dateiberechtigungen, Ordner-ACLs oder Speicherprotokolle hinaus. Das Konzept der Unveränderbarkeit muss in die Backup-Architektur integriert werden damit keine Sicherheitslücke die Manipulation der Backups ermöglicht.
Rubrik ist auf Unveränderlichkeit ausgelegt
Rubrik verwendet eine unveränderliche Architektur, indem ein unveränderliches Dateisystem mit einem Zero-Trust-Cluster-Design kombiniert wird, bei dem Operationen nur über authentifizierte APIs durchgeführt werden können.
Der Ansatz von Rubrik steht im Gegensatz zu anderen Datenverwaltungssystemen, die Allzweckspeicher verwenden, weche Standardprotokolle wie NFS oder SMB verwenden, um ihre Verfügbarkeit für ein breites Spektrum von Clients anzubieten. Es ist möglich, dass Datenmanagement-Lösungen, die Allzweckspeicher verwenden, begrenzte oder ineffektive Funktionen für die sichere Übertragung von Daten haben und in einigen Fällen Dateien in ihrem nativen Format belassen, während sie Clients erlauben, die Sicherungsdaten direkt zu lesen.
Ein unveränderliches verteiltes Dateisystem
Eine der ersten Designentscheidungen von Rubrik war die Konstruktion von Atlas, einem unveränderlichen Dateisystem im Userspace (FUSE), das weitgehend POSIX-konform ist. Dies ermöglicht eine strenge Kontrolle darüber, welche Anwendungen Informationen austauschen können, wie jeder Datenaustausch abläuft und wie die Daten über physische und logische Geräte hinweg angeordnet sind. Atlas wurde speziell als verteiltes und unveränderliches Dateisystem zum Schreiben und Lesen von Daten für andere Rubrik-Dienste entwickelt.
Die Unveränderlichkeit wird über zwei Schichten bereitgestellt: die logische Schicht (Patch-Dateien, Patch-Blöcke) und die physikalische Schicht (Stripes, Chunks). Die Dynamik zwischen diesen beiden Schichten wird in den nächsten Abschnitten näher erläutert.
Der logische Layer
Alle Kundendaten, die in das System eingebracht werden, werden in eine proprietäre Sparse-Datei geschrieben, die Patch-Datei genannt wird. Dabei handelt es sich um Append-Only-Dateien (AOFs), was bedeutet, dass Ihre Daten nur in die Patch-Datei eingefügt werden können, solange diese als offen markiert ist. Alle Snapshot- und Journal-Daten des Kunden werden in Atlas gespeichert, das die Verwendung von Patch-Dateien in der zugrundeliegenden Verzeichnisstruktur erzwingt. Dieses leistungsstarke Dateisystem verweigert Schreibvorgänge auf der API-Ebene. Atlas hat die vollständige Kontrolle darüber, wie und wohin Kundendaten geschrieben werden.
Wenn Ihre Sicherungsdaten verändert wurden, sind sie im Grunde wertlos. Rubrik hat dies gelöst, indem sichergestellt wurde, dass für jeden Patch-Block innerhalb einer Patch-Datei Prüfsummen erzeugt werden. Diese Prüfsummen werden berechnet und in eine Fingerprint-Datei geschrieben, die zusammen mit der Patch-Datei gespeichert wird. Rubrik führt immer eine Fingerprint-Prüfung durch, bevor irgendwelche Datentransformationen durchgeführt werden. Dies stellt sicher, dass die Originaldatei intakt bleibt, mit erzwungener Validierung bei Leseoperationen.
Um einen Ransomware-Angriff abzuwehren, müssen die ursprünglichen, validierten Daten aus dem Backup wiederhergestellt werden. Rubrik verifiziert routinemässig die Patch-Blöcke gegen ihre Prüfsummen, um die Datenintegrität auf der logischen Patch-Block-Ebene sicherzustellen. Patch-Dateien sind nicht für externe Systeme oder Kundenadministrator-Konten zugänglich. Dadurch wird sichergestellt, dass genau das wiederhergestellt wird, was Sie ursprünglich in einem Backup gespeichert haben.
Bei einem traditionellen Ansatz wird administrativer Zugriff auf das Dateisystem gewährt – insbesondere bei der Verwendung von Allzweckspeichern – was weitere Herausforderungen für die Vertraulichkeit und Integrität mit sich bringt und “Leakware” einen weiteren Angriffsvektor bietet. Darüber hinaus stellen viele andere Lösungen einfach die Daten wieder her, die sich im Backup-Ordner oder -Volume befinden, ohne eine Validierung und andere Due-Diligence-Prüfungen der Daten durchzuführen.
Der physische Layer
Während sich die logische Schicht auf die Datenintegrität auf Dateiebene konzentriert, liegt der Schwerpunkt der physischen Schicht auf dem Schreiben von Kundendaten über den unveränderlichen Cluster, um Datenintegrität und Datenresilienz zu erreichen. Zu diesem Zweck werden Patch-Dateien logisch in Segmente fester Länge unterteilt, die Stripes genannt werden. Beim Schreiben der Stripes berechnet die AOF eine Prüfsumme auf Stripe-Ebene, die sie in den Stripe-Metadaten speichert.
Stripes werden weiter in physische Chunks unterteilt, die auf physischen Festplatten innerhalb des Rubrik-Clusters gespeichert werden. Aktivitäten wie Replikation und Erasure Coding finden auf der Chunk-Ebene statt. Genau wie bei Patch-Dateien wird beim Schreiben jedes Chunks eine Chunk-Prüfsumme berechnet und in den Stripe-Metadaten neben der Liste der Chunks gespeichert. Diese Prüfsummen werden regelmässig als Teil der Hintergrundprüfung von Atlas neu berechnet, indem die physischen Chunks gelesen und mit den Prüfsummen in den Stripe-Metadaten verglichen werden. Zusätzlich wird im Falle einer notwendigen Wiederherstellung der Daten die durch Erasure Coding bereitgestellte Ausfallsicherheit automatisch im Hintergrund genutzt.
Zero Trust Cluster-Design
Traditionelle Ansätze zur Clustersicherheit basieren oft auf einem “Full Trust”-Modell, bei dem alle Mitglieder des Clusters miteinander kommunizieren können. In einigen Fällen beinhaltet dies Autorität auf Root-Ebene, keine gegenseitigen Authentifizierungsprüfungen und die Möglichkeit, Kundendaten, die im Dateisystem gespeichert sind, zu lesen oder zu ändern. Dies schafft eine Schwachstelle beim Entwurf einer Defense-in-Depth-Architektur; wenn Sicherungsdaten kompromittiert werden können gibt es keinen Weg zur Wiederherstellung, wenn eine Störung auftritt. Rubrik setzt hier auf ein vollständiges Zero-Trust-Modell mit u.a. möglicher mehrstufiger Authetifizierung und rollenbasierten Zugriffsmodellen.
Gesicherte Cluster-Kommunikation
Jeder Cluster hat eine gewisse Anzahl von Knoten, die miteinander kommunizieren müssen. Das bedeutet, dass Rubrik jeden Knoten, der Daten austauschen möchte, validieren muss. Bei vielen Lösungen gibt es wenig bis gar keinen Schutz für die Knoten-zu-Knoten-Kommunikation. Bei Rubrik verwendet die gesamte Intra-Knoten- und Inter-Cluster-Kommunikation sowie die Kommunikation mit externen Anwendungen das TLS-Protokoll mit zertifikatsbasierter gegenseitiger Authentifizierung.
Rubrik verwendet keine unsicheren Protokolle, wie NFS oder SMB, um Informationen innerhalb des Clusters weiterzugeben; die gesamte Kommunikation erfolgt über sichere und vertrauenswürdige Kanäle. Tatsächlich verwendet die gesamte interne Kommunikation TLS 1.2 mit starken Cipher Suites und Perfect Forward Secrecy (PFS).
Jeder Rubrik-Cluster, der an einen Kunden ausgeliefert wird, verwendet starke, randomisierte Passwörter auf einer Pro-Node-Basis. Es gibt kein Konzept einer “admin/admin” Art von standardmässiger lokaler Authentifizierung, die leicht im Web durchsuchbar ist, und Möglichkeiten zum Einfall bietet.
Authentifizierte APIs
Rubrik hat von Anfang an ein API-first Design als Basis der Softwarearchitektur festgelegt. Die Software verlangt eine Authentifizierung für alle Endpunkte, die für den Betrieb der Lösung verwendet werden. Die Authentifizierung kann über Credentials oder Secure Token erfolgen. Dies schliesst Umgebungen ein, die Role-Based Access Control (RBAC) oder Multi-Tenancy Features nutzen, um die Rollen, Features und Ressourcen, die verwaltet werden, logisch aufzuteilen. Die CLI, SDKs und andere Tools von Rubrik nutzen die API und unterliegen den gleichen Sicherheitsanforderungen.
API-Endpunkte, die das zugrundeliegende Verhalten des Systems steuern, erfordern eine zusätzliche Autorisierungsebene, die nur von einem zertifizierten technischen Support-Ingenieur bereitgestellt werden kann. Dies verhindert, dass ein böswilliger Akteur in der Lage ist, das Verhalten eines Rubrik-Clusters zu verändern.
Für weitere Details zu Rubrik sprechen Sie uns gerne an!