La protection des données, et en particulier celles dans le cloud, est capitale aujourd’hui, d’une part à cause des attaques récurrentes sur lesdites données (cf. l’affaire EquiFax) et d’autre part car de nouvelles régulations telles que le GDPR sont apparues et obligent les entreprises à garantir la confidentialité des données sensibles. Pour en assurer la protection, les entreprises s’orientent vers l’utilisation de la cryptographie et du chiffrement dans (presque) toutes leurs applications. Le cloud n’étant pas une exception.

Clé de chiffrement: Une clé est un paramètre utilisé en entrée d’une opération cryptographique, qui permet de rendre illisibles les données (chiffrement) ou de les rendre lisibles à nouveau (déchiffrement).

En effet, la présence toujours possible de vulnérabilités potentielles dans les systèmes d’information et la sophistication toujours grandissante des cyber-attaques font que la sécurité des clés de chiffrement, point d’entrée vers les données sensibles, est devenue vitale. Les algorithmes cryptographiques modernes deviennent de plus en plus résistants aux attaques mais, malgré tout, une vulnérabilité majeure reste présente: les clés de chiffrement.

C’est ainsi que les clés de chiffrement deviennent les valeurs les plus précieuses de l’entreprise, leur valeur étant équivalente à celle de l’information qu’elle protège : aussi il est indispensable de s’assurer de leur protection par différents moyens

Le HSM (Hardware Security Module) ou BNT (Boîte Noire Transactionnelle) est un dispositif très fortement sécurisé avec des fonctions cryptographiques. Il permet de générer, stocker et protéger des clés de chiffrement.

Mais pour être fiables, ces dispositifs doivent être conformes à des standards de sécurité tel le Le FIPS 140-2 Level 3. Le Federal Information Processing Standard (FIPS), publication 140-2, est un standard de sécurité informatique du gouvernement américain utilisé pour approuver des modules cryptographiques. Ce standard inclut des exigences matérielles et logicielles qui doivent être respectées par le module. Le Level 3 ou niveau 3 ajoute des défenses contre les tentatives d’intrusion physique, telles que la destruction des clés de chiffrement et informations d’identification au module (le niveau 1 contient des exigences de base et le niveau 2 fournit une protection contre des tentatives d’intrusion physique dans le module).

Désormais, les opérateurs Cloud du marché offrent des solutions de gestion des clés cryptographiques (HSM). Ces solutions apportent la flexibilité suffisante pour s’intégrer aux applications à travers les bibliothèques de développement, elles peuvent aussi être gérées à partir du CLI (Command Line Interface), interface de ligne de commande.

AWS CloudHSM, Google Cloud HSM et Microsoft Azure Dedicated HSM sont des modules HSM ou BNT disponibles sur le marché cloud.

Comme il est habituel dans les services cloud, le module HSM est un service géré par le fournisseur mais avec des mises à jour automatiques, une haute disponibilité et des sauvegardes. Le fournisseur cloud n’a pas d’accès ou visibilité des clés de chiffrement qui sont stockées dans le module par le client.

Cependant l’utilisation des HSMs permet aussi d’être conforme à certaines exigences de sécurité telles que la certification PCI HSM qui devient une exigence fondamentale dans les process de paiement, par exemple le traitement des PINs, la production et la vérification de cartes bancaires et la recharge de carte bancaires prépayées.

En conclusion, les clés de chiffrement protègent les informations sensibles de l’entreprise et des clients, et il est indispensable de mettre en place les politiques, procédures et outils nécessaires pour les sécuriser. Les HSMs s’intègrent dans la stratégie de défense de l’information et permettent de mettre en place une défense efficace contre les cyber menaces d’aujourd’hui.

iDNA vous apporte l’expertise en matière d’architecture cloud et sécurité nécessaires à la protection de votre infrastructure et vos données, n’hésitez pas à nous contacter pour une analyse plus approfondie de votre situation.

Les Etats-Unis, eux, se portent mieux avec une diminution du temps moyen qui est passé de 106 jours à 99 jours entre 2016 et 2017.

Ces statistiques montrent que le périmètre de défense traditionnel (firewalls, antivirus, etc.), bien qu’indispensable, ne semble plus être suffisant pour protéger complètement les ressources (informations, données personnelles, etc.) des entreprises.

La prévention se révèle donc indispensable, mais une réaction rapide aux événements est également critique : en effet, il devient indispensable de réduire ce nombre de 175 jours à quelques heures, voire minutes.

Les fournisseurs Cloud offrent un ensemble de services qui permettent de mettre en place de manière automatisée une surveillance réactive du périmètre Cloud, en complément de la défense traditionnelle.

Ainsi, la Sécurité Orientée Événements (Event Driven Security) consiste à réagir aussi rapidement que possible aux événements dans l’infrastructure cloud liés à la sécurité.

Ceci est possible en accédant en temps réel (ou quasi temps réel) à des données fiables, relatives à l’activité du réseau et infrastructure cloud, pour y réagir de manière automatisée.

La plupart des fournisseurs Cloud mettent à disposition dans leurs services les informations et les mécanismes (APIs, interfaces) qui permettent de déclencher ces actions automatisées de surveillances de l’infrastructure.

Les services s’exécutent dans la couche de gestion du Cloud (Management Plane): ils sont au-delà de la portée d’une intrusion ou d’un élément du réseau compromis par une attaque. Si un serveur est compromis, feriez-vous confiance à l’antivirus qui y est installé ?

Quand un événement arrive dans l’infrastructure Cloud que l’on souhaite surveiller, le service associé déclenche du code spécifiquement écrit pour cet événement (language python parmi d’autres) en lui passant les informations associées, lambda functionschez AWS et Background functions chez Google pour ne nommer que deux fournisseurs. Ces functions sont automatiquement authentifiées dans les services, et les droits d’accès sont configurés en fonction du périmètre d’action du code.

Typiquement, le code est associé à des événements enregistrés dans le système des logs (AWS CloudWatch, CloudWatch Logs and CloudWatch Events, Google Logs), la messagerie (AWS SNS, AWS SQS, Google Messaging), les informations de télémétrie (AWS CloudTrail et Google StackDriver Logging) telles que utilisation CPU, RAM, etc.

Il est aussi possible de s’assurer de la conformité de l’implémentation de certaines règles, présentes dans les procédures de sécurité, en comparant les configurations réelles et en surveillant les changements avec ce qui a été défini dans le système de sécurité.
Par exemple, une surveillance peut être mise sur les droits d’accès pour les utilisateurs d’un groupe qu’uniquement des superutilisateurs autorisés peuvent modifier. Dès qu’un nouvel utilisateur est créé, on déclenche du code qui va vérifier que la personne qui l’a créé appartient bien au groupe autorisé (AWS Config et AWS Config Rules).

A l’aide de ces services et en particulier avec l’utilisation du code Serverless et son grand pouvoir de configuration, les implémentations cloud pourront mettre en place des actions automatiques en réponse à des événements dans leur infrastructure avec pour objectifs la détection d’incidents de sécurité, le renforcement des directives de sécurité, la conformité et l’audit, et finalement la diminution de la probabilité d’une attaque et/ou de son temps de détection.

Alors, il est facile d’oublier que les infrastructures physiques telles que les datacenters, les serveurs et les équipements réseaux sont des rouages indispensables pour le fonctionnement des usines à services.

Les hyperviseurs sont précisément les serveurs-rouages qui soutiennent les machines virtuelles, containers^[1] et services associés. Ils peuvent donc être de sérieux points faibles pour la chaîne de production de services, tant en termes de sécurité que de robustesse.

Passés les premiers moments avec un hyperviseur (n’importe qui^[2] est capable d’en installer un), il apparaît rapidement que les différents mécanismes de fonctionnement nécessitent une maîtrise multifacettes. Celle-ci englobe les systèmes d’exploitation mais aussi les réseaux LAN et le stockage et est requise pour assurer la mise en oeuvre et surtout l’exploitation au quotidien.

En effet, un hyperviseur, bien plus que tout autre système informatique, doit bénéficier d’un suivi régulier comprenant le monitoring, les performances, la gestion des incidents, le « capacity planning », etc.

Il est (relativement) simple de prévoir un changement sur une machine virtuelle ou un conteneur en se protégeant avec les mécanismes de robustesse des différentes technologies (par exemple les snapshots). La modification d’un hyperviseur, cependant, peut être bien plus risquée.

En effet, de multiples problèmes peuvent survenir : des incompatibilités de drivers matériel (cela existe encore !) ou encore, des configurations réseau ou système dysfonctionelles qui affectent l’ensemble des services, même avec la meilleure des préparations.

Dans la vie idéale de la Production Informatique, les mises à jour sont réalisées régulièrement en passant de version mineure en version mineure plutôt que de « sauter » d’un coup à une version majeure pour rattraper le retard.

Dans la vie réelle, maintenir à jour un hyperviseur est une activité risquée nécessitant organisation, compétences et tests complets… Autant dire qu’il s’agit là d’un exercice qui est souvent repoussé au fil des mois, avec un backlog de correctifs qui grossit au fur et à mesure. Ces retards augmentent d’autant les risques de dysfonctionnement en cas de mise à jour et un cercle vicieux s’installe.

Finalement, les rouages de base de votre infrastructure deviennent obsolètes, avec des vulnérabilités non remédiées et des bugs non corrigés. Soit, tous les ingrédients pour un futur incident majeur.

Toutefois, en appliquant avec soin les bonnes pratiques classiques de la production, la mise à jour des hyperviseurs peut être maîtrisée et régulière :

• Tester systématiquement les mises à jour sur les infrastructures de recette ou non critiques pour s’assurer de la non-régression.
• Rédiger, répéter et valider les procédures et chronogrammes de mises à jour.
• Utiliser les mécanismes de déplacement des VM entre plusieurs hyperviseurs pour réaliser les opérations de façon séquentielle.
• Prévoir des plans de retour en arrière et/ou s’assurer de la capacité de réinstaller rapidement en cas de problème.
• Avoir des périodes d’observation post mise en production pour valider le bon fonctionnement et les performances de l’hyperviseur mis à jour.
• Réunir une équipe pluridisciplinaire pour préparer les changements et capable de réagir efficacement en cas de problème.

Enfin, on ne le dira jamais assez : un retour d’expérience (RETEX) avec les équipes doit conclure chaque mise à jour, qu’elle soit réussie ou non, pour mieux mener les prochaines opérations.

Et vous, combien de fois par an mettez-vous à jour vos hyperviseurs ?