Mieux vaut WannaSwitch que WannaCry

Jusqu'à présent, les logiciels malveillants tels que les ransomwares, les virus et les fuites de données involontaires étaient surtout réservés aux terminaux. Mais récemment, des variantes de ransomware comme WannaCry et Petya ont également fait grand bruit dans l'environnement des serveurs d'entreprise, car les contrôles d'accès physiques et logiques ainsi que les protections purement architecturales et techniques du réseau ne suffisent manifestement pas, même pour les classes de centres de données élevées.

La vulnérabilité de WannaCry, Petya et de leurs collègues repose manifestement sur des systèmes d'exploitation non corrigés. Or, il existe de nombreux cas d'utilisation dans lesquels les correctifs ne peuvent être appliqués qu'à intervalles très longs sur des environnements de production.

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 les logiciels correspondants s'emparent de ces systèmes.

Il suffit d'exploiter sans retenue des failles à moitié actuelles (dont les correctifs ne sont disponibles que depuis quelques semaines ou mois). Un centre de calcul fonctionnant 7 jours sur 7 et 24 heures sur 24, qui prévoit peut-être deux fois par an des fenêtres de maintenance régulières et qui considère que les correctifs de sécurité actuels ne sont pas suffisamment critiques pour justifier une interruption de service, est et reste ouvert à de telles attaques.

Les noms des entreprises les plus diverses de l'environnement financier, du secteur chimique et de nombreux autres secteurs économiques, ainsi que des institutions publiques et semi-publiques, circulent dans la presse comme victimes présumées ou confirmées.

Le fait que des exploitants d'infrastructures critiques en fassent partie laisse entrevoir une réponse insuffisante aux exigences actuelles telles que la loi sur la sécurité informatique et autres. La question qui se pose ici est de savoir si les mesures de sécurité prises en toute conscience sont vraiment appropriées pour faire face aux menaces des ransomwares. Il faut résoudre deux problèmes :

• Opération IT 7x24 vs. patching permanent
• Défense d'attaque vs. contre-réaction détendue

Il existe pour cela une approche relativement simple - et surtout plus ou moins universelle : la mise en miroir au niveau de la base de données et de l'application, indépendante de l'architecture et de l'infrastructure.

Cette méthode, que l'on considère volontiers comme dépassée à l'époque des machines virtuelles, des miroirs de stockage et des variantes de clusters les plus diverses, peut justement aussi faire valoir sa force lors d'attaques de ransomware : l'indépendance logique des environnements système sous-jacents.

Les gangsters repartent bredouilles malgré une attaque réussie

Un utilisateur de Libelle ne voulait pas être la victime d'une attaque de ransomware. C'est pourquoi celui-ci s'est entraîné à la situation d'urgence. (L'entreprise est un fabricant de produits alimentaires renommé et ne peut malheureusement pas être nommée, car ce secteur est exposé en permanence à des tentatives d'extorsion et autres attaques).

Le succès de cette entreprise repose sur la qualité de ses produits et sur la disponibilité 7 jours sur 7 et 24 heures sur 24 d'un grand nombre de bases de données MS-SQL. Les patcher en permanence, en interrompant constamment l'exploitation pour cela, n'est pas réalisable dans le quotidien de l'entreprise.

C'est pourquoi on a opté pour une autre voie : Les systèmes de production fonctionnent "en l'état". Les données actuelles sont transférées en permanence de l'environnement productif vers un environnement dit miroir par le biais d'une mise en miroir des données et des applications.

Il est également patché régulièrement et de manière actualisée, non pas dans les environnements de production, mais sur les systèmes miroirs. BusinessShadow fonctionne complètement indépendamment de l'environnement de production, sans serveur partagé, sans stockage partagé, bref : Shared Nothing.

Grâce à la mise en miroir, les données actuelles sont toujours présentes physiquement du côté miroir, mais les systèmes peuvent être entretenus et maintenus à jour avec les derniers patchs, indépendamment de l'exploitation productive.

Si une attaque avec un ransomware réussit sur l'environnement de production et que celle-ci est couronnée de succès en raison du faible niveau de patch, le système bascule simplement sur le système miroir hautement patché et continue à travailler en quelques minutes. Résultat : l'attaque n'a pas été repoussée, mais elle a tourné à 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, comme c'est souvent le cas pour les solutions de stockage et de cluster : D'une part, il est possible d'utiliser en toute tranquillité les fenêtres de maintenance sur le miroir, car contrairement à la mise en miroir synchrone, aucun Two-SiteCommit n'est nécessaire, et d'autre part, l'entreprise sort du piège synchrone.

Si une erreur logique a corrompu le stock de données de production, le stock de données sur le miroir est automatiquement corrompu. Les cryptages ou suppressions de ransomware, les attaques de virus, les activités d'application erronées, les importations de données incorrectes, les activités manuelles malveillantes d'utilisateurs internes ou externes ou autres sont autant d'erreurs logiques qui, dans le pire des cas, entraînent l'arrêt de l'entreprise.

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 pour le public.

Cette mise en miroir asynchrone des données et des applications permet de définir n'importe quel décalage temporel entre le système productif et le système miroir. Les données productives 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 en permanence en retard sur le système de production, mais il dispose déjà du delta des données sur son propre stockage et peut, s'il le souhaite, le reconstituer de manière ad hoc.

Si une erreur logique, quelle qu'elle soit, se produit dans l'environnement de production, c'est l'instance responsable de l'organisation qui décide du cas de commutation, c'est-à-dire, selon la structure et les processus de l'entreprise, par exemple le responsable SAP, le propriétaire de l'application, le responsable DR ou le directeur informatique.

D'un point de vue technique, le meilleur moment possible pour la base 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 à un moment quelconque à l'intérieur de l'horizon temporel, avec une précision transactionnelle et une cohérence des données, les utilisateurs et autres applications d'accès se connectent à nouveau et peuvent continuer à travailler avec des données correctes.

Un autre avantage de cette mise en miroir asynchrone des données et des applications est la réduction significative des temps de latence, puisque le système de production ne doit pas attendre le commit du système miroir.

Ainsi, des concepts DR (Desaster Recovery) pratiques et économiquement intéressants sont possibles sur de grandes distances et avec de faibles exigences en termes de volume et de QoS (Quality of Service) sur les lignes réseau entre les systèmes.

Défis : logiques, physiques, infrastructurels

Les systèmes de secours peuvent être exploités non seulement dans des centres de calcul propres, mais aussi, par exemple, sous forme de service auprès d'une "entreprise amie" ou d'un prestataire de services éloigné à volonté, ce qui est particulièrement fréquent dans les PME.

La distance entre le site de production et le site de panne n'est donc plus limitée par les possibilités offertes par les technologies DarkFibre, Campus ou Metrocluster, qui ne représentent que quelques kilomètres dans le cas le plus courant.

Les miroirs asynchrones peuvent être étendus à volonté en fonction des exigences commerciales et de la structure de l'entreprise, même sur différentes plaques tectoniques. Il est donc possible de mettre en place des concepts de reprise après sinistre qui s'appliquent également en cas de catastrophe à grande échelle et qui permettent de maintenir l'exploitation informatique à l'échelle d'un pays, d'une région ou même du monde entier.

De plus, la mise en miroir des données et des applications indépendamment de l'architecture libère 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 impliqués.

Outre les intérêts technologiques, il faut également tenir compte des intérêts économiques. Dans le cas d'architectures homogènes, les frais de maintenance sont certes moindres, mais le risque lié à des pilotes, des patchs de micrologiciels ou des logiciels de contrôleurs défectueux se répercute non seulement sur certains environnements, mais sur tous.

En outre, les considérations commerciales jouent également un rôle dans les exigences posées aux environnements de production et de secours : Souvent, il suffit que seul le système de production soit conçu pour fonctionner durablement de manière performante.

Le système de défaillance peut tout à fait être conçu de manière plus petite, il doit simplement être "suffisamment bon" pour une utilisation qui, espérons-le, ne se produira jamais, et si elle se produit, elle ne sera que temporaire.

Dans la pratique, ces considérations aboutissent souvent à ce que, dans le cadre du cycle habituel du matériel, l'"ancien" système productif continue à être exploité comme nouveau système de secours. 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.