Trop souvent, le périmètre d’un audit de cloud public se réduit à la sécurité. Certes, cette dernière est un élément clé – voire un pilier fondateur – d’une démarche d’audit, mais elle n’est pas suffisante. La performance, la fiabilité, l’excellence opérationnelle et l’optimisation des coûts doivent également être intégrées.
Point central de ces audits, la sécurité est présente à tous les niveaux, du chiffrement des données aux accès utilisateurs, en passant par l’analyse du code dans les pipelines DevOps. Pièce maîtresse du design applicatif et de la conformité réglementaire, elle constitue un élément incontournable pour les équipes d’auditeurs.
Des performances à la hauteur
Cependant, l’audit ne peut et ne doit pas se limiter à ce seul domaine d’analyse. Les performances des applications, des microservices et des différents composants de l’infrastructure doivent également être prises en considération. Dans un contexte de concurrence exacerbée, dans tous les secteurs, les entreprises doivent en effet pouvoir compter sur un cloud public à la hauteur, quelles que soient les circonstances. Parmi les principaux indicateurs à surveiller, les auditeurs doivent être particulièrement vigilants à la latence et à la disponibilité.
Une question de fiabilité
Corollaire du point précédent, la fiabilité du cloud public ne doit pas non plus être laissée de côté. Pour garantir la pérennité d’une entreprise et la qualité de son expérience utilisateur, l’excellence opérationnelle doit être au rendez-vous, à tout moment. Pour évaluer cette fiabilité, le respect – ou non – des Service Level Objectives (objectifs de niveau de services) donnera aux équipes en charge de l’audit de précieuses indications. Il sera ainsi judicieux d’étudier de près les SLO liés à certains workloads, API ou bases de données…
Une certaine excellence
L’excellence opérationnelle prend en charge les procédures d’entretien, de déploiement et d’automatisation de vos infrastructures et applications. Elles sont ancrées dans ce que nous appelons DevOps ou SRE (Site Reliability Engineering). Un axe d’audit qui révélera votre maturité sur le Cloud.
Ne pas négliger les coûts
Quant aux coûts, ils doivent eux aussi rentrer dans le périmètre d’un audit de cloud public. Le mode pay-as-you-go du cloud, qui a permis à de très nombreuses jeunes pousses de démarrer progressivement leur activité avec des moyens financiers réduits, peut parfois constituer un centre de dépenses important pour certains grands comptes.
C’est notamment vrai lors de projets peu optimisés pour le cloud comme les migrations de masse de type « Lift and shift » qui consistent à déplacer une application et ses données vers une plateforme cloud sans aucune transformation applicative.
Un audit FinOps sera alors un excellent moyen de générer des économies sur une infrastructure mature. Il permettra de s’orienter, par exemple, sur d’autres modes de facturation tels que les instances réservées ou le mode spot. Un changement de technologie, comme le fait de basculer du SQL vers le NoSQL, pourra représenter une source additionnelle de réduction des coûts.
Une méthodologie rigoureuse
Mener l’audit d’un cloud public répond à certaines exigences méthodologiques. Il est tout d’abord fortement conseillé d’utiliser un référentiel des risques, ou de créer le sien. Pour ce qui est de la sécurité, l’existence de nombreux référentiels facilite grandement la tâche. On peut à ce titre citer le CIS (Center for Internet Security), le PCI-DSS (norme de sécurité de l’industrie des cartes de paiement) ou, plus complet encore, l’ISO 27001, qui mène à la certification.
Il est en revanche beaucoup plus compliqué de trouver un référentiel sur l’excellence opérationnelle ou la gestion des coûts. D’où l’intérêt de réfléchir à s’en créer un en propre. Cela permet d’atteindre un haut niveau de qualité, sur tous les plans. À quoi bon en effet posséder une architecture complètement imperméable aux attaques si elle ne répond pas à une montée en charge ou si son coût est un véritable gouffre financier.
Une fois le référentiel en place et la première analyse menée, un certain nombre de risques sont mis en évidence. Bien entendu, il n’est pas possible de tous les résoudre simultanément, dans un délai très court. De plus, les niveaux de criticité vis-à-vis du contexte métier ne sont pas identiques. C’est donc le moment de prioriser ces risques et de planifier la remédiation des anomalies.
La notation des risques doit être basée sur des éléments concrets, comme l’impact financier ou celui perçu par les utilisateurs. A chaque niveau de criticité doit être associée une probabilité d’occurrence, ce qui donne naissance à une échelle de notation permettant de qualifier les différents paliers en se basant sur ses indicateurs métiers.
Lister, analyser et présenter les risques
Mettre en place un tableau de bord des risques permet par la suite de travailler dans de bonnes conditions. C’est un document de référence qui pourra et devra être réutilisé lors des futurs audits. Il est entièrement personnalisable et peut contenir les questions des interviews d’audit, les commandes utilisées ainsi que le rapport des benchmarks.
Cette phase représente le plus gros du travail au cours de laquelle des interviews vont être réalisées, sur le terrain, auprès d’un public pluridisciplinaire, ce qui permettra probablement d’identifier de nouveaux risques et de les ajouter au référentiel.
Le tableur sera un précieux allié lors d’un audit de cloud public. Néanmoins, il n’est pas la meilleure solution pour présenter et visualiser le résultat de cet audit. L’utilisation de matrices est à ce moment-là fortement recommandée. Elles apportent en effet une aide de choix lors des phases de reporting et de présentation des analyses. Elles sont également un excellent moyen de comparer deux audits en un regard.
Rendre accessible au plus grand nombre un audit permet d’accélérer les chantiers qui en découlent. Y joindre une description des risques et un planning des remédiations permet de maximiser les chances de succès. Un audit est avant tout un projet collaboratif. Il ne peut être mené en autarcie et ses conclusions ne peuvent être gardées secrètes.
Par Samuel Bally, Solutions Architect et expert des architectures modernes de Cloud chez Ippon Technologies
