Interview de Laurent Besset @ I-TRACING

Interview de Laurent Besset - Directeur Cyberdéfense chez I-TRACING, par Alain Establier

SDBR News : Pensez-vous que l’accident industriel vécu par OVH le 10 mars 2021 puisse être un frein au mouvement des entreprises vers le Cloud ?

Laurent Besset : Lorsqu’on décide d’aller dans le Cloud, il faut tirer parti des fonctionnalités et principes d’architecture qui font sa force, donc en utilisant les modèles et les architectures qui sont propres au Cloud. Il y a deux erreurs que font beaucoup d’entreprises ou d’organisations :

  • la première et la plus compliquée à corriger : se dire que le Cloud est la même chose que ma salle informatique ou mon data center, mais ailleurs… Dans ce cas, l’entreprise se contente de la même architecture avec les mêmes principes, en répliquant ce qu’elle avait en interne mais dans le Cloud.

  • La deuxième, c’est de négliger que la résilience a un coût : les clients d’OVH qui ont perdu toutes leurs données dans l’incendie du data center étaient en fait positionnés sur les offres d’OVH à très bas coût. Peut-être n’avaient-ils pas bien lu les conditions générales de l’offre à laquelle ils avaient souscrit ? Ces conditions générales expliquaient qu’OVH n’avait pas la responsabilité de sauvegarder les données qui étaient sur les machines mises à leur disposition.

Donc se dire « le Cloud c’est magique, c’est un endroit super, le fournisseur va s’occuper de tout et nous n’aurons plus de problèmes » est une grossière erreur… Ce n’est pas comme cela que fonctionne le Cloud.

SDBR News : Alors, comment aborder le Cloud ?

Cloud OVH Google.jpg

Laurent Besset : Dans le Cloud, il y a des offres et des options qui permettent de faire des choix de répartition des données, de redondance, d’équilibrage des charges, etc. En fonction de la sensibilité de son service, l’entreprise ou l’organisation doit construire une architecture cohérente avec le niveau de risque qu’elle est prête à accepter ou à ne pas accepter. Ce qui s’est passé chez OVH n’est pas différent de ce qui se passe lorsque la salle informatique d’une entité est détruite par le feu ou par une inondation. Si l’entité n’a pas choisi une architecture dans laquelle les données ne sont pas toutes au même endroit, que cet endroit soit chez elle, chez OVH, chez Google ou ailleurs, lorsqu’il est détruit les données sont détruites avec lui. Chez les grands fournisseurs de Cloud, on retrouve toujours à peu près le même mécanisme de répartition des architectures sur plusieurs sites. Par exemple, chez Azure existe une notion de zone, une zone pouvant être constituée de un ou plusieurs data center proches, entre lesquels la communication est très rapide du fait de la proximité. Lorsqu’un client choisi son offre, il peut décider de l’endroit de stockage de ses données : par exemple, les données sont stockées sur le disque local de l’ESX de l’hyperviseur sur lequel est la machine du client (comme un hébergement classique dans un data center) avec un accès rapide dans certains cas ; par contre si l’ESX brûle avec le data center les données seront perdues.

SDBR News : Quel est l’autre possibilité ?

Laurent Besset : Vous pouvez choisir aussi d’avoir des données réparties à l’intérieur d’une même zone, sous-entendu il y a des liens à grande vitesse et les données seront réparties entre plusieurs data center proches. De la même manière, vous pouvez choisir d’avoir des réplications de données entre zones au sein d’une région, et même vous pouvez choisir d’avoir une réplication de données entre régions. Le Cloud apporte des solutions plus simples et plus puissantes en termes architecturales à condition de bien les utiliser. Par contre, plus vous éloignez du data center initial, plus la communication sera lente et longue, et la réplication prendra du temps. Il peut y avoir aussi une certaine complexité dans la mise en place de réplications éloignées. Donc répliquer loin c’est bien pour des données qui ne doivent absolument pas être perdues et pour lesquelles la disponibilité est plus importante que la performance. On peut donc accepter de stocker localement sur l’ESX les données de cache, qui sont volatiles et qui ne porteront pas préjudice en cas de perte ou d’incident technique. La question se pose donc pour l’entreprise en analyse de risques, ce qui n’est pas nouveau : étude de disponibilité des données, réponse architecturale à cette demande de disponibilités, équilibrage de charges, redondances, résilience, etc.

SDBR News : Il y avait eu un effet Saint-Gobain pour décider des entreprises à moderniser leurs solutions de cybersécurité. Pensez-vous qu’il y aura un effet OVH pour mieux gérer le recours au Cloud ?

Laurent Besset : Comme toujours, il y a un effet bénéfique aux incidents constatés chez les autres et, en matière de sécurité, c’est souvent un accélérateur de progrès. Le plan de reprise d’activité (PRA) n’est pas un sujet qui fait rêver et pourtant c’est un des piliers de la sécurité. Si, après l’incident OVH, beaucoup plus d’entreprises et d’organisations se demandent où sont leurs données, ce qui se passerait en cas de scénario hautement improbable comparable, en termes de probabilité acceptable, a contrario que doivent-elles faire, etc., alors nous pourrons dire que nous avons progressé.

SDBR News : Quel est votre rôle chez I-TRACING ?

I_Tracing - noir_baseline_uk_2017_1200dpi_smal.png

Laurent Besset : En réunissant toutes les expertises techniques, depuis le conseil et la gouvernance, jusqu’à la surveillance et gestion opérationnelle de la sécurité en passant par l’ingénierie et l’intégration des solutions, I-TRACING accompagne ses clients dans la sécurisation de leur transformation digitale tout en offrant une réponse adaptée en cas d’attaque. I-TRACING est indépendant et compte aujourd’hui 300 collaborateurs. Nous travaillons avec presque toutes les entreprises du CAC40.

  • Chez I-TRACING, j’ai en charge l’ensemble des activités de « réponses à incidents » qui est une activité porteuse. Nous en faisons entre 15 et 25 par mois, dont 5 ou 6 qui sont des ransomwares qui ont tout bloqué. Dans un certain nombre de cas, les sauvegardes étaient sur un serveur de sauvegarde qui a été aussi chiffré. Donc l’entreprise se retrouve dans une situation où les sauvegardes ont disparu alors même qu’elle en a le plus besoin. Si les sauvegardes sont essentielles pour l’entreprise, la bonne pratique est de les externaliser. La clé de la résilience reste la préparation et l’anticipation.

  • J’ai aussi la charge des activités managées de détection (CyberSOC) - nous protégeons aujourd’hui plusieurs dizaines d’entreprises, dont 5 entreprises du CAC40 (1,1 M d’utilisateurs dans 115 pays au total) - ainsi que les activités d’audit SSI.

 https://i-tracing.com

 Crédits photos : I-Tracing; Le Big Data