Libelle

WannaCry ? Non, WannaSwitch et WannaContinue. Laissez Ransomware se perdre.

Rançongiciels (Ransomware) et autres virus

Jusqu’à présent, les sujets tels que les ransomwares, les virus et la fuite involontaire de données étaient principalement réservés aux machines des utilisateurs finaux. Récemment, des virus de type rançongiciels sont apparus en s’attaquant directement aux serveurs de l’entreprise. Tel fut le cas avec les virus WannaCry et Petya. Il est clair que même les plus grands datacenters n’étaient pas en mesure de contrer cette menace avec des contrôles d’accès physiques et logiques ou avec une certaine sécurité réseau.

De nombreuses entreprises dans de nombreux secteurs d’activités ont été victimes de ces attaques, y compris des opérateurs de services essentiels (OSE). On peut donc se demander si les mesures de sécurité jusqu’alors en place sont suffisantes pour parer les attaques des rançongiciels.

Les rançongiciels profitent souvent de vulnérabilités telles que l’absence de patches sur certains serveurs. Or, dans de nombreux cas d’utilisation, les correctifs opérés sur les environnements de production ne sont mis en œuvre qu’après de longs intervalles. Il est donc aisé pour des acteurs malveillants de s’attaquer à ces systèmes. Un département informatique opérant 24h/24 et 7j./7 qui a) réalise une maintenance régulière – par exemple deux fois par an – et b) ne considère pas les correctifs de sécurité actuels comme suffisamment critiques pour interrompre des activités ad hoc, est perméable à ces attaques.

 

Opérations disponibles 24h/24 et 7j/7 vs. patching permanent // suppression des attaques vs. Retour-arrière étendu

La pratique offre une solution simple et, surtout, presque universellement adaptable : la duplication indépendante de
l’architecture et de l’infrastructure au niveau des bases de données et des
applications.

Cette technologie tire profit d’un atout majeur : l’indépendance logique des environnements systèmes sous-jacents. 

Même si l’attaque est réussie, les délinquants se retrouvent à zéro

La solution de duplication des données Libelle BusinessShadow fonctionne de manière totalement indépendante de l’environnement de production, sans serveur ni stockage partagé. En raison de la duplication, les données de production sont constamment présentes physiquement du côté de l’environnement de secours (de réplication). Et les systèmes de secours peuvent être maintenus indépendamment des environnements de production, au dernier niveau de patch.

Si une attaque de ransomware intervient sur le système de Production, par exemple à cause d’une vulnérabilité de patch, il suffit de passer au système de secours hautement patché et de continuer à y travailler en quelques minutes. Par conséquent, l’attaque qui a lieu a été déjouée.

Prévention contre la corruption « classique » des données

La duplication des données décrite ci-dessus est asynchrone. Cela présente plusieurs avantages par rapport à la duplication synchrone, souvent utilisée pour le stockage et les clusters : d’une part, il est possible mettre en œuvre des services de maintenance sur l’environnement miroir de manière étendue, puisqu’il n’y a pas d’engagement sur les deux sites, contrairement à la mise en miroir synchrone.

D’autre part, le département informatique sort lui aussi des problèmes liés à la synchronisation. En effet, si une erreur logique a corrompu la base de données productive, la base de données du miroir est automatiquement corrompue. Ainsi, si un serveur primaire est victime de n’importe quel virus-(encryption des données, ransomware, autres…), d’une mauvaise manipulation sur la couche applicative, d’une importation de données corrompues, d’activités manuelles malveillantes d’utilisateurs internes ou externes, ou de toute autre erreur logique, le datacenter ou serveur de repli sera lui aussi concerné. Pire encore : le département IT pourrait continuer à travailler avec des données corrompues et générer ainsi un effort économique supplémentaire voire nuire à l’image de l’organisation.

La duplication asynchrone des données et applications permet de définir le décalage de temps que l’on souhaite (« entonnoir temporel ») entre le système productif et l’application des données sur le système miroir. Les données productives réelles sont stockées sur le système miroir dans l’entonnoir temporel. L’activation logique « réelle » dans les systèmes de gestion de bases de données et de fichier commence après l’expiration du décalage de temps défini. Le système miroir fonctionne donc en permanence avec un décalage dans le temps par rapport au système de production. Le système miroir enregistre le delta entre l’horodatage physique (« maintenant ») et l’horodatage logique (« il y a X minutes/heures »).

Si une erreur logique se produit maintenant dans l’environnement de production, le responsable des opérations de reprise d’activité décide du basculement vers le système miroir. Il peut s’agir du propriétaire de l’application, de la personne en charge du Plan de Continuité et/ou du Plan de Reprise d’Activité (PCA-PRA) ou de la direction informatique.

A présent, le meilleur moment pour la reprise des données est défini et activé sur le système miroir, généralement le dernier moment avant la corruption des données. L’entonnoir de temps est capable d’activer chaque point dans le temps en fonction du décalage de temps défini. La base de données ou les applications du système miroir peuvent être activées et mises en service avec l’ensemble cohérent de données. Les utilisateurs et les autres applications qui accèdent au système se reconnectent et peuvent continuer à travailler avec des données correctes. 

Autres scénarios : défis logiques et défis physiques

Entre autres avantages, la duplication asynchrone offre de faibles temps de latence entre le système de production et le système miroir (PRA). Par conséquent, dans les cas d’une distance conséquente entre le système primaire et le système miroir, la mise en œuvre de concepts de PRA est facilitée y compris lorsque la connexion réseau entre les deux systèmes est de faible qualité.

Cette situation de « longue distance » entre deux sites (primaire et PRA) peut se retrouver dans différentes configurations : la société possède ses propres serveurs de PRA distants (de X kilomètres des serveurs primaires) ou la société fait exploiter ses serveurs de PRA par un fournisseur qui propose un datacenter géographiquement éloigné des serveurs primaires du client.

La distance entre le site de production et le site secondaire n’est plus limitée par la technologie (fibre noire, campus, clusters…), qui dépassait rarement quelques kilomètres. Avec la duplication asynchrone, l’opération peut s’étendre à plusieurs régions du monde en se basant sur les besoins de l’entreprise et son architecture IT. Ainsi, il est possible de repenser les concepts de PRA applicables en cas de catastrophe généralisée et de maintenir les opérations informatiques du pays, de la région ou même du monde entier.

De plus, une duplication des applications (par les données) indépendante de l’architecture résout le problème du « point de défaillance unique » : en plus de répondre à la recommandation « ne rien partager », diverses infrastructures sont supportées dans les environnements concernés.

Outre les intérêts technologiques, il convient aussi de tenir compte des intérêts économiques. Avec des infrastructures homogènes, l’effort de maintenance est moindre mais le risque de défaillance du pilote, des correctifs du firmware ou de l’ordonnanceur concernera tous les environnements. En outre, en cas de défaillance informatique majeure, il convient de tenir compte des enjeux économiques pour l’activité de l’activité de l’entreprise : dans de multiples cas, il est suffisant que seul le système de production soit conçu pour un usage permanent et à haute performance. Le système de reprise d’activité (jusqu’ici appelé système miroir ou de PRA) peut certainement être conçu plus petit : il doit juste être « suffisamment bon » pour le cas qui, espérons-le, ne se produira jamais, ou s’il se produit, seulement de manière temporaire. Dans la pratique, ces considérations conduisent souvent à réaffecter le  » vieux  » système productif comme nouveau système secondaire, en suivant le cycle habituel du matériel.

Ainsi, de nombreuses entreprises optent pour une voie intermédiaire entre architecture homogène et hétérogène, dans laquelle au moins deux normes matérielles sont définies, souvent avec des composants provenants de différents fabricants.