Icon systeme-informatique-contre-les-ransomwares-et-autres

Comment protéger votre système informatique contre les ransomwares et autres ?

Auteur

Les thèmes tels que les ransomwares, les virus et les fuites de données indésirables sont d'actualité. Ils représentent une menace et un défi sérieux pour les entreprises. Le développement d'une solution de cybersécurité est un "MUST" pour protéger les départements, les données, les processus ou encore les technologies.

Imaginez une entreprise dont les processus sont en grande partie digitalisés. Les processus sont efficaces et hautement productifs, la direction est satisfaite. Cependant, un matin, l'entreprise est victime d'une cyberattaque. Sous le choc, l'entreprise constate l'absence de plans et de mesures permettant de reprendre rapidement le cours normal de ses activités. Dans le pire des cas, l'entreprise est paralysée.

Il y a quelques années, l'attaque par ransomware "WannaCry" a fait beaucoup de bruit. Le 17 mai 2017, une cyberattaque a touché plus de 300 000 appareils dans plus de 150 pays. Parmi les personnes touchées figuraient quelques entreprises de renom.

La vulnérabilité de WannaCry était manifestement basée sur des systèmes d'exploitation non protégés. Or, il existe de nombreux cas d'utilisation dans lesquels les correctifs sur les environnements de production ne peuvent, par définition, être mis en œuvre qu'à de longs intervalles. Dans ce cas, il n'est même pas nécessaire de disposer d'exploits "zero-day" hautement sophistiqués et d'une énergie malveillante à réaction rapide pour que le logiciel correspondant s'empare de ces systèmes.

Une opération informatique fonctionnant 24 heures sur 24 et 7 jours sur 7, qui par exemple ne programme des fenêtres de maintenance régulières que deux fois par an et qui considère que les correctifs de sécurité actuels ne sont pas suffisamment critiques pour interrompre les opérations, est et reste vulnérable à de telles cyberattaques.

Opérations 24/7 vs. correctifs permanent // Défense contre les attaques vs. contre-attaque détendue

En pratique, il existe une solution simple et, surtout, plus ou moins universellement applicable : une indépendante de l'architecture et de l'infrastructure au niveau de la base de données et de l'application.

Cette technologie, souvent considérée comme obsolète à l'époque des machines virtuelles, de la mise en miroir du stockage et d'une grande variété de variantes de clusters, peut ici jouer sur l'un de ses points forts encore existants : L'indépendance logique des environnements système sous-jacents.

Les criminels repartent bredouilles, malgré une attaque de ransomware réussie

La solution de continuité d'activité Libelle BusinessShadow fonctionne de manière totalement indépendante de l'environnement de production, sans serveurs partagés, sans stockage partagé, en bref : Shared Nothing. Grâce à la mise en miroir, les données actuelles sont toujours présentes physiquement dans l'environnement miroir, mais les systèmes peuvent être entretenus et maintenus à jour avec les derniers patchs, indépendamment de l'exploitation de production.

Si une cyberattaque au moyen d'un ransomware réussit dans l'environnement de production et que celle-ci est couronnée de succès en raison du faible niveau de correctif, il suffit de basculer sur le système miroir hautement patché et de continuer à y travailler en seulement quelques minutes.

Résultat : "La cyberattaque n'a pas été repoussée, mais elle est tombée dans le vide".

Prévention également contre la corruption classique des données

La mise en miroir des données décrite ci-dessus est asynchrone. Cela présente plusieurs avantages par rapport à la mise en miroir synchrone, qui est souvent utilisée pour la mise en miroir du stockage et les clusters : D'une part, il est possible d'utiliser les fenêtres de maintenance sur le miroir, car contrairement à la mise en miroir synchrone, aucun Two-Site-Commit n'est nécessaire.

D'autre part, l'entreprise sort du piège de la synchronisation : Si une erreur logique a corrompu le jeu de données de production, le jeu de données sur le miroir est automatiquement corrompu.

Dans le pire des cas, les erreurs logiques suivantes entraînent l'arrêt de tous les processus commerciaux :

  • Cryptages de ransomware exécutés
  • Suppressions des ransomware exécutées
  • Infection par un virus
  • Activités d'application erronées
  • Importations de données erronées
  • Activités manuelles malveillantes d'utilisateurs internes ou externes

Dans le pire des cas, le travail se poursuit avec des données erronées, ce qui génère des dépenses économiques supplémentaires ou un préjudice d'image public.
Cette mise en miroir asynchrone des données/applications permet de définir n'importe quel décalage temporel entre le système de production et le système miroir : Les données de production actuelles sont déjà présentes physiquement sur le système miroir, mais elles sont maintenues artificiellement en attente dans un entonnoir temporel et ne sont activées logiquement qu'à l'expiration du décalage temporel défini. D'un point de vue logique, le système miroir est donc constamment en retard sur le système de production, mais il dispose déjà du delta des données sur son propre stockage et peut le récupérer ad hoc si nécessaire.

Si une erreur logique se produit dans l'environnement de production, c'est l'instance responsable de l'organisation qui décide de la commutation, c'est-à-dire, selon la structure et les processus de l'entreprise, le propriétaire de l'application, le responsable DR ou encore la direction informatique. D'un point de vue technique, le meilleur moment possible pour le jeu de données est déterminé et activé sur le système miroir.

La base de données ou l'application sur le système miroir est donc mise à disposition de manière productive à n'importe quel moment dans l'entonnoir temporel, avec une précision transactionnelle et une cohérence des données. Les utilisateurs et les autres applications d'accès se reconnectent et peuvent continuer à travailler avec des données correctes.

Une technologie, plusieurs scénarios d'application : Défis logiques vs. physiques vs. infrastructurels

Un autre avantage de cette mise en miroir asynchrone des données et des applications est que la latence n'est pas un problème car le système de production ne doit pas attendre que le système miroir s'engage. Cela permet également de mettre en place des concepts de reprise après sinistre pratiques et économiquement intéressants avec de longues distances et de faibles exigences en termes de volume et de qualité de service sur les lignes réseau entre les systèmes. En outre, les systèmes de basculement peuvent être exploités non seulement dans les centres de données de l'entreprise, mais aussi, par exemple, en tant que service auprès d'une "entreprise amie" ou d'un prestataire de services situé à n'importe quelle distance, ce qui est particulièrement courant dans les entreprises de taille moyenne. La distance entre le site de production et le site de panne n'est donc plus limitée par les possibilités des technologies DarkFibre, campus ou metrocluster, qui dans le cas habituel ne représentent que quelques kilomètres. La mise en miroir asynchrone peut être étendue à volonté en fonction des exigences commerciales et de la structure de l'entreprise, même sur différentes plaques tectoniques. Cela signifie qu'il est possible de mettre en place des concepts de reprise après sinistre, même en cas de catastrophe de grande ampleur, et de maintenir les opérations informatiques dans plusieurs pays, régions ou même dans le monde entier.

En outre, la mise en miroir des données/applications indépendante de l'architecture permet de s'affranchir du dilemme du "point unique de défaillance" : outre l'architecture "shared-nothing" déjà recommandée, les différentes architectures et infrastructures matérielles sont également prises en charge dans les environnements concernés. Dans ce cas, il faut non seulement tenir compte des intérêts technologiques, mais aussi parfois des intérêts économiques.

Dans le cas d'architectures homogènes, les frais de maintenance sont certes moins élevés, mais le risque lié aux pilotes, aux correctifs de micrologiciels ou aux logiciels de contrôleurs défectueux se répercute sur tous les environnements, et pas seulement sur un seul. De plus, les considérations commerciales jouent également un rôle en ce qui concerne les exigences posées aux environnements de production et de secours : il est souvent suffisant que seul le système de production soit conçu pour un fonctionnement permanent à haute performance. Le système de basculement peut également être conçu de façon plus modeste, celui-ci doit juste être "suffisamment bon" pour qu'il ne se produise jamais, voire qu'il ne soit utilisé que temporairement.Dans la pratique, ces considérations aboutissent souvent à ce que, dans le cadre du cycle habituel du matériel, « l'ancien » système de production continue à fonctionner comme le nouveau système de basculement. Ainsi, de nombreuses entreprises optent pour la voie médiane, entre une architecture homogène et une architecture hétérogène, dans laquelle au moins deux normes matérielles sont définies, souvent avec des composants de différents fabricants.

Vous souhaitez en savoir plus sur différents sujets liés à l'informatique ? Par exemple, que signifient exactement les notions de haute disponibilité et de continuité des activités ? Alors n'hésitez pas à consulter notre glossaire Libelle IT ou à nous suivre sur LinkedIn.

Banner Libelle UserGroup
Vers tous les articles