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
Comment les entreprises peuvent-elles se remettre rapidement d’une attaque par ransomware ?
La sauvegarde des données peut être un moyen efficace de récupérer les données qui ont été verrouillées/cryptées par l’attaque. Mais que faire si vos données de sauvegarde sont également cryptées ou supprimées par une attaque de ransomware ? Comment vous assurer que vos données de sauvegarde ne sont pas vulnérables à ces attaques ?
La clé, ce sont des sauvegardes immuables
Alors que les systèmes de stockage primaires doivent être ouverts et disponibles pour les systèmes clients, vos données de sauvegarde doivent être immuables. Cela signifie qu’une fois écrites, les données ne peuvent pas être lues, modifiées ou supprimées par les clients de votre réseau. C’est le seul moyen de garantir la reprise en cas de compromission des systèmes de production.
Cela va bien au-delà des simples autorisations de fichiers, des ACL de dossiers ou des journaux de stockage. Le concept d’immuabilité doit être intégré dans l’architecture de sauvegarde afin qu’aucune faille de sécurité ne permette d’altérer les sauvegardes.
Rubrik est conçu pour l’immuabilité
Rubrik utilise une architecture immuable en combinant un système de fichiers immuable avec une conception de cluster à confiance zéro où les opérations ne peuvent être effectuées que par des API authentifiées.
L’approche de Rubrik contraste avec d’autres systèmes de gestion de données utilisant un stockage polyvalent, qui utilisent des protocoles standard tels que NFS ou SMB pour offrir leur disponibilité à un large éventail de clients. Il est possible que les solutions de gestion des données qui utilisent un stockage polyvalent aient des capacités limitées ou inefficaces pour transférer les données de manière sécurisée et, dans certains cas, laissent les fichiers dans leur format natif tout en permettant aux clients de lire directement les données de sauvegarde. Cela constitue une violation de la confidentialité et impose au client la charge supplémentaire de sauvegarder le stockage indépendamment de sa solution de gestion des données.
Un système de fichiers distribués immuable
L’une des premières décisions de conception de Rubrik a été de construire Atlas, un système de fichiers immuable en espace utilisateur (FUSE) qui est largement conforme à POSIX. Cela permet de contrôler étroitement les applications qui peuvent échanger des informations, la manière dont chaque échange de données se produit et la manière dont les données sont disposées sur les dispositifs physiques et logiques. Atlas est spécifiquement conçu comme un système de fichiers distribué et immuable pour l’écriture et la lecture de données pour d’autres services de rubriques.
L’immuabilité est assurée sur deux couches : la couche logique (fichiers de correction, blocs de correction) et la couche physique (bandes, morceaux). La dynamique entre ces deux couches est expliquée plus en détail dans les sections suivantes.
La couche logique
Toutes les données relatives aux clients qui sont introduites dans le système sont écrites dans un fichier propriétaire à faible densité, appelé fichier patch. Il s’agit de fichiers append-only (AOF), ce qui signifie que vos données ne peuvent être insérées dans le fichier patch que lorsqu’il est marqué comme ouvert. Toutes les données des instantanés et des journaux des clients sont stockées dans Atlas, ce qui impose l’utilisation de fichiers patch dans la structure de répertoire sous-jacente. Ce système de fichiers puissant refuse les écritures au niveau de l’API. Atlas a un contrôle total sur la façon dont les données des clients sont écrites et où elles le sont.
Si vos données de sauvegarde ont été modifiées, elles sont essentiellement sans valeur. Rubrik a résolu ce problème en s’assurant que les sommes de contrôle sont générées pour chaque bloc de patch dans un fichier de patch. Ces sommes de contrôle sont calculées et écrites dans un fichier d’empreintes digitales qui est stocké avec le fichier de correction. Rubrik effectue toujours une vérification de l’empreinte digitale avant d’effectuer toute transformation de données. Cela garantit que le fichier d’origine reste intact, avec une validation forcée des opérations de lecture.
Pour se défendre contre une attaque par ransomware, les données originales et validées doivent être restaurées à partir de la sauvegarde. Rubrik vérifie régulièrement les blocs de correctifs par rapport à leur somme de contrôle afin de garantir l’intégrité des données au niveau du bloc de correctifs logique. Les fichiers de correctifs ne sont pas accessibles aux systèmes externes ou aux comptes administrateurs des clients. Cela garantit que ce que vous avez sauvegardé à l’origine est restauré.
Une approche traditionnelle accorde un accès administratif au système de fichiers – en particulier lors de l’utilisation d’un stockage polyvalent – ce qui introduit de nouveaux défis en matière de confidentialité et d’intégrité et fournit aux “logiciels de fuite” un autre vecteur d’attaque. En outre, de nombreuses autres solutions se contentent de restaurer les données qui se trouvent dans le dossier ou le volume de sauvegarde sans effectuer de validation ou d’autres contrôles préalables sur les données.
La couche physique
Alors que la couche logique se concentre sur l’intégrité des données au niveau du fichier, la couche physique se concentre sur l’écriture des données du client à travers le cluster immuable pour atteindre l’intégrité et la résilience des données. À cette fin, les fichiers patch sont logiquement divisés en segments de longueur fixe appelés bandes. Lors de l’écriture des bandes, l’AOF calcule une somme de contrôle au niveau de la bande, qu’il stocke dans les métadonnées de la bande.
Les bandes sont ensuite divisées en morceaux physiques qui sont stockés sur des disques physiques au sein du cluster de rubriques. Les activités telles que la réplication et le codage par effacement ont lieu au niveau des morceaux. Comme pour les fichiers patch, une somme de contrôle des morceaux est calculée lors de l’écriture de chaque morceau et stockée dans les métadonnées de la bande avec la liste des morceaux. Ces sommes de contrôle sont recalculées périodiquement dans le cadre du contrôle de fond d’Atlas, en lisant les morceaux physiques et en les comparant aux sommes de contrôle des métadonnées Stripe. En outre, si une récupération des données est nécessaire, le basculement fourni par le codage par effacement est automatiquement utilisé en arrière-plan.
Conception de clusters à confiance zero
Les approches traditionnelles de la sécurité des clusters sont souvent basées sur un modèle de “confiance totale” où tous les membres du cluster peuvent communiquer entre eux. Dans certains cas, cela inclut une autorité au niveau de la racine, aucune vérification d’authentification mutuelle et la possibilité de lire ou de modifier les données du client stockées dans le système de fichiers. Cela crée une vulnérabilité dans la conception d’une architecture de défense en profondeur ; si les données de sauvegarde peuvent être compromises, il n’y a pas de voie de récupération en cas de panne.
Communication sécurisée entre clusters
Chaque grappe comporte un certain nombre de nœuds qui doivent communiquer entre eux. Cela signifie que Rubrik doit valider chaque nœud qui veut échanger des données. Dans de nombreuses solutions, la communication de nœud à nœud est peu ou pas protégée. Avec Rubrik, toutes les communications intra-nœuds et inter-clusters, ainsi que les communications avec des applications externes, utilisent le protocole TLS avec une authentification mutuelle basée sur des certificats.
Rubrik n’utilise pas de protocoles non sécurisés, tels que NFS ou SMB, pour transmettre des informations au sein du cluster ; toutes les communications se font par des canaux sécurisés et de confiance. En fait, toutes les communications internes utilisent le protocole TLS 1.2 avec des suites de chiffrement fortes et le système Perfect Forward Secrecy (PFS).
Chaque cluster rubric livré à un client utilise des mots de passe forts et aléatoires pour chaque nœud. Il n’existe pas de concept d’authentification locale par défaut de type “admin/admin”, facilement consultable sur le web et offrant des possibilités d’incursion.
API authentifiées
Rubrik a adopté une conception API-first dans le cadre de son architecture. Le logiciel nécessite une authentification pour tous les points d’extrémité utilisés pour exécuter la solution. L’authentification peut se faire à l’aide d’informations d’identification ou de jetons sécurisés. Il s’agit notamment des environnements qui utilisent le contrôle d’accès basé sur les rôles (RBAC) ou les fonctions de multi-location pour partitionner logiquement les rôles, les fonctions et les ressources qui sont gérés. Les CLI, SDK et autres outils de Rubrik utilisent l’API et sont soumis aux mêmes exigences de sécurité.
Les points de terminaison API qui contrôlent le comportement sous-jacent du système nécessitent une couche d’autorisation supplémentaire qui ne peut être fournie que par un ingénieur d’assistance technique certifié. Cela empêche un acteur malveillant de pouvoir modifier le comportement d’un cluster Rubrik.
Pour plus de détails sur Rubrik, n’hésitez pas à nous contacter !